Functions and Roles of the Components

• 1 Router
  It is responsible for routing user Http request traffic to its destination. The main destination will be the Cloud Controller or Garden Container running the application. Router's router information receives the application instance information that Diego is servicing from Nats and is updated through Route-emitter. The route-emitter module has been integrated into Diego-Cell.
  Git source : https://github.com/cloudfoundry/gorouter
• 2 Tcp-Router
  It serves to route user Tcp request traffic to the destination. The main destination will be the Garden Container running the application.The router information of the router receives the application instance information that Diego is servicing from Nats and is updated through the route-emitter. The route-emitter module has been integrated into Diego-Cell.
  Git source : https://github.com/cloudfoundry/cf-tcp-router/
• 3 API(Cloud Controller)
  Provides APIs for staging and running applications. Responsible for overall management of the application, such as build pack selection, service and binding, and access authorization processing. When a developer sends an application to Cloud Foundry via CLI, the Cloud Controller receives it, which stores the application binary, creates a record of application metadata, and communicates with Diego to instruct Stage state preparation and application execution. For services, Cloud Controller maintains a database for holding information such as organizations, spaces, services, service instances, user roles, and blob storage for storing application code and buildpacks, etc.
  Git source : https://github.com/cloudfoundry/cloud_controller_ng
• 4 UAA
  It acts as an OAuth2 server and login server to provide user authentication management.
  Git source : https://github.com/cloudfoundry/uaa
• 5 CC-Worker
  Execute task (App LifeCycle, etc.) requested by API in BackGround.
  Git source : https://github.com/cloudfoundry/cloud_controller_ng
• 6 Scheduler(Auctioneer)
  It is a VM with existing Auction and decides which cell to deploy the App Container.
  Git source : https://github.com/cloudfoundry-incubator/auctioneer
• 7 Database
  It is a database storage where K-PaaS's Tennant, App, and authentication information are stored, and it is composed of Postgres/MySql.
• 8 Diego-cell(Rep)
  It represents Cell and performs various services through BBS. In other words, it checks whether the task and ActualLRP information of the BBS matches the actual container in the cell, and maintains the cell in the BBS to exist. If a particular Cell fails, Converger automatically transfers that instance to another Cell. In addition, it participates in Auction to receive Tasks/LRP, makes a request to the Executor, executes Tasks/LRPs to create a container, and executes the action to be performed within the container.
  Git source : https://github.com/cloudfoundry-incubator/rep
• 9 Diego-cell(Executor)
  It provides HTTP APIs for creating containers, performing actions within containers, and deleting containers. It does not distinguish between Task and LRP, and implements Action API for performing actions. Executor sends Stdout and Stderr streams to metro-agent running in Cell, and the streams are passed to Loggregator.
  Git source : https://github.com/cloudfoundry-incubator/executor
• 10 Diego-cell(Garden)
  It provides platform-independent server and client interfaces for container management. The interface defines methods for performing the following actions
  - Creation and deletion of containers
  - Applying resource constraints of containers
  - Connecting and developing network ports to containers
  - Copy files into/out of container
  - Process execution in container and handling Stdout and Stderr data streaming
  - Arbitrary meta data in the container
  - Create container snapshots for redeployment without downtime
  Currently, Garden-linux is provided as a Linux implementation that implements the Garden interface.
  Git source : https://github.com/cloudfoundry-incubator/garden
• 11 Diego-cell(route-emitter)
  It monitors the actual LRP (ActualLRP) status from the rep, compares it with the target LRP (DesiredLRP) , and sends a request message to register/remove route information to the Router through nats if a change occurs. Periodically sends the entire routing table to the Router.
  Git source : https://github.com/cloudfoundry-incubator/route-emitter
• 12 Nats
  App domain information running in K-PaaS is received from route-emitter and delivered to router.
  Git source : https://github.com/apcera/gnatsd
• 13 Doppler
  Doppler provides application logs to developers as a stream.
  Git source : https://github.com/cloudfoundry/loggregator/
• 14 Diego-api
  It is a VM running the existing BBS and checks the running state of the container.
  Git source : https://github.com/cloudfoundry/bbs
• 15 singleton-blobstore
  An object repository that stores K-PaaS's application packages, staged application droplets, and buildpack caches. It can be configured as internal or external .
  Git source : https://github.com/cloudfoundry/capi-release/tree/develop/jobs/blobstore
• 16 log-api
  Each component of the application platform generates a system log, and a deployed application generates an app log.
  The Loggregator system structures and collects each component's metrics and app logs into Firehose, and all outputs from Firehose are available and can be exported for specific purposes, such as monitoring systems, triggering alert systems, and analyzing user behavior.
  https://docs.cloudfoundry.org/loggregator/architecture.html
• 17 credhub
  CredHub is a component designed for centralized credential management for application platforms. At the highest level, CredHub centralizes and secures credential creation, storage, lifecycle management, and access.
  https://docs.cloudfoundry.org/credhub/
• 18 log-chace
  Logs and metrics can be shown for the specified period using the log cache. The log cache includes API endpoints and CLI plugins that query and filter logs and metrics.
  https://github.com/cloudfoundry/log-cache