Overview of the deployment workflow¶

Management cluster deployment consists of several sequential stages. Each stage finishes when a specific condition is met or specific configuration applies to a cluster or its machines.

In case of issues at any deployment stage, you can identify the problem and adjust it on the fly. The cluster deployment does not abort until all stages complete by means of the infinite-timeout option enabled by default in Bootstrap v2.

Infinite timeout prevents the bootstrap failure due to timeout. This option is useful in the following cases:

The network speed is slow for artifacts downloading
An infrastructure configuration does not allow booting fast
A bare-metal node inspecting presupposes more than two HDDSATA disks to attach to a machine

You can track the status of each stage in the bootstrapStatus section of the Cluster object that is updated by the Bootstrap Controller.

The Bootstrap Controller starts deploying the cluster after you approve the BootstrapRegion configuration.

The following table describes deployment states of a management cluster that apply in the strict order.

Deployment states of a management cluster¶
Step	State	Description
1	`ProxySettingsHandled`	Verifies proxy configuration in the `Cluster` object. If the bootstrap cluster was created without a proxy, no actions are applied to the cluster.
2	`ClusterSSHConfigured`	Verifies SSH configuration for the cluster and machines. You can provide any number of SSH public keys, which are added to cluster machines. But the Bootstrap Controller always adds the `bootstrap-key` SSH public key to the cluster configuration. The Bootstrap Controller uses this SSH key to manage the `lcm-agent` configuration on cluster machines. The `bootstrap-key` SSH key is copied to a `bootstrap-key-<clusterName>` object containing the cluster name in its name.
3	`ProviderUpdatedInBootstrap`	Synchronizes the provider and settings of its components between the `Cluster` object and bootstrap Helm bundle. Settings provided in the cluster configuration have higher priority than the default settings of the bootstrap cluster, except CDN.
4	`ProviderEnabledInBootstrap`	Enables the provider and its components if any were disabled by the Bootstrap Controller during preparation of the bootstrap region. A cluster and machines deployment starts after the provider enablement.
5	Nodes readiness	Waits for the provider to complete nodes deployment that comprises VMs creation and MKE installation.
6	`ObjectsCreated`	Creates required namespaces and IAM secrets.
7	`ProviderConfigured`	Verifies the provider configuration in the provisioned cluster.
8	`HelmBundleReady`	Verifies the Helm bundle readiness for the provisioned cluster.
9	`ControllersDisabledBeforePivot`	Collects the list of deployment controllers and disables them to prepare for pivot.
10	`PivotDone`	Moves all cluster-related objects from the bootstrap cluster to the provisioned cluster. The copies of `Cluster` and `Machine` objects remain in the bootstrap cluster to provide the status information to the user. About every minute, the Bootstrap Controller reconciles the status of the `Cluster` and `Machine` objects of the provisioned cluster to the bootstrap cluster.
11	`ControllersEnabledAfterPivot`	Enables controllers in the provisioned cluster.
12	`MachinesLCMAgentUpdated`	Updates the `lcm-agent` configuration on machines to target LCM agents to the provisioned cluster.
13	`HelmControllerDisabledBeforeConfig`	Disables the Helm Controller before reconfiguration.
14	`HelmControllerConfigUpdated`	Updates the Helm Controller configuration for the provisioned cluster.
15	Cluster readiness	Contains information about the global cluster status. The Bootstrap Controller verifies that OIDC, Helm releases, and all Deployments are ready. Once the cluster is ready, the Bootstrap Controller stops managing the cluster.