# TiDB Cloud Create a Cluster Workflow


![left](./student-guide/diagram/TiDBCloudCreateClusterWorkflow_aa_001_20220524.png)


------------------------------------------------------------
This is a very complex process. In this introductory class we will not go into full detail about every component.

Some of the components that are a part of the TIDB Cloud solution include:


Basic connect to a cluster scenario
User – Uses the UI to connect to a cluster

    - The API for creating a cluster writes a cluster record ( MetaDB ) to source code ( table structure ) 
    - Start the cluster creation logic ( source code ) when the worker periodically sweeps to the cluster that needs to be created 
    - Worker calls Infra API to create a new Network or replicate an existing Network (depending on Platform layer multi-tenant isolation logic) ( source code ) 
    - After Network Ready, Worker calls Infra API to create Cluster and waits for Cluster Ready ( source code ) 
    - After Cluster Ready, the worker performs business layer initialization operations, such as setting the initial password given by the user ( source code ) 
    - The UA (browser) on the user side will poll the cluster status. After the user finds that the cluster is Ready, use the connection string returned by the API to connect to the TiDB cluster ( source code ) 

Core: Responsibilities: Central will pass the lifetime management of TiDB related products to Core Service through grpc , and Core Service will be responsible for management TiDB cluster, BR, lighting, cdc, replication, models and other DBaaS core entities . 

    - Core Service is a service that strips off the business logic of platforms such as Identity and Billing, and focuses on the operation of TiDB products. Responsible for the Central side's understanding of the products provided by Infra. 

MetaDB Responsibilities: Platform backend database, used to store the main business data of the cloud platform, running on the TiDB cluster of the Prod environment. 

    - Worker Responsibilities: The background asynchronous logic worker of the Platform reads tasks from the task queue in MetaDB, and gradually digests the queue. At present, the write logic related to the Infra API is generally written to the Meta DB on the Platform side, and then synchronized to the Infra API by the worker. 
    Related code: https://github.com/tidbcloud/dbaas/blob/7b11c7c9c55cbad9d762d7eaf622386d0c643786/central/worker/manager.go#L51-L52 

    - InfraAPI Responsibilities: Infra API Server provides a kube-apiserver + etcd based CRD storage for Infra Provider of Dedicated Tier, aws-shared-provider/shared-provider of Dev Tier/Shared Tier 
    Related code: https://github.com/tidbcloud/infra-cd/blob/main/apiserver.ts currently Pulumi deployed via 

    - Infra Provider Responsibilities: Provide the main lifetime management of Dedicated Tier, mainly used for cluster management under the Gardener system, including Network, Cluster, Backup, Restore, Import, NetworkPeer and other Controllers 
    Related code: https://github.com/tidbcloud/infra-api/blob/main/cmd/infra-provider/main.go 

Crossplane provider-aws
Responsibilities: Crossplane's AWS Provider implementation, responsible for handling the management of CRDs for AWS-related resources. 
Related code: https://github.com/tidbcloud/provider-aws 

Gardner Gardener Control-plane
Responsibilities: The control side of Gardener , Gardener is a set of managed services used to create Kubernetes clusters used by users , including 
Gardener ApiServer: provide Gardener API 
ETCD: Storage for Gardener ApiServer 
Scheduler: Dispatch a set of k8s clusters to the corresponding Seed (Region) 
Repo: https://github.com/tidbcloud/gardener 

Gardener Agents
Responsibilities: Gardener 's data plane, each set of Seed clusters runs a set of Gardener Agents. When the Gardener control plane schedules a set of k8s clusters to the current Seed, the Gardener Agents will be responsible for creating the VPC, nodes and control planes of this set of k8s clusters ( TiDB K8S Control-plane ) 

TiDB K8s TiDB Kubernetes Cluster:

machine-controller-manager
Responsibilities: Call Cloud API, manage VMs in k8s cluster 
Repo: https://github.com/tidbcloud/machine-controller-manager 

cloud-controller-manager
Responsibilities: Kubernetes the components responsible for Cloud interaction in the control plane, call Cloud API, manage Cloud Disk and Cloud k8s cluster LB in the 
Repo: https://github.com/kubernetes/kubernetes 

agg prometheus
Responsibilities: Collect metrics exposed by TiDB within TiDB VPC through Metrics Exporters and TiDB Prometheus VPC's VPN (Prometheus pull Prometheus is called Federate ), and push to Thanos. At the same time, the Prometheus will also calculate some alarm rules and push the alarm to Alertmanager; 
Risk point: In fact, agg prometheus is redundant (because the metrics collection points of each end point can push metrics to the central Thanos by themselves without going through a layer of relay), which comes from the inheritance of the Gardener architecture and can be refactored in the future Remove, reduce complexity, and improve metrics link stability; 


Config Service Cloud Responsibilities: config-service is currently the core component of GitOPS . Responsibilities include: 
    - Provide the external image (which controls the component version) and configuration that the current TiDB/PD/TiKV/TiFlash/TiCDC/BR/Lightning should use. For example, the infrastructure-provider will request config-service when creating a cluster; 
    - Patrol all clusters and upgrade clusters whose current image/configuration does not match the expected value to a new image/configuration; 
    Repo: https://github.com/tidbcloud/config-service 
Additional note: config-service is currently only suitable for dedicated clusters , and does not support configuration online updates. Improvements are planned in TiDB Configuration Management on DBaaS 

TiDB