Cluster deployment status
Status block on the cluster dashboard before deployment is completed.
Cluster deployment contains several steps, see the illustration below.
After starting creating a client cluster or installing a management cluster, the progress of work is displayed in the “Cluster deployment status” block. Data is updated automatically.
The block is available until deployment is complete. The stages are shown at the top, and below is the “State” block with details of the selected stage. The stages are not necessarily performed strictly sequentially: some checks and operations can occur in parallel.
Screenshots: changing the cluster deployment status
Cluster deployment steps, see the illustration below.
For detailed information, click on the step icon. Detailed information will be displayed under the status feed. An example of the step taken, see the illustration below.
Example of a stage in the process, see the illustration below.
| Stage | What is displayed on the dashboard |
|---|---|
| Resources created | The initial stage of preparing cluster resources |
| Cluster infrastructure is ready | Readiness of cluster infrastructure resources |
| Control Plane nodes initialized | List of Control Plane nodes and their states |
| Worker nodes created | List of Worker nodes by groups and their states |
| NCI applied | Application of node configurations (NCI) and count of nodes where configuration is applied |
| System services installed | List of Shturval repository services and their installation status |
| Cluster ready | Final Deployment Status |
Color indication of stages
The color indication of the stages shows the current status:
| Stage status | Indication |
|---|---|
| Stage successfully completed | Green color |
| Stage in progress | Yellow color |
| Stage not yet launched | Gray color |
| The stage ended with an error | Red color |
Deployment steps
Resources created
At this stage, the namespace of the client cluster in the management cluster and the ClusterInfo object are created.
Cluster infrastructure is ready
At this stage, Cluster Manager waits for condition InfrastructureReady:true to appear in the Cluster API controller. This means that the controller has successfully contacted the infrastructure provider.
Control Plane nodes are initialized
At the “Initializing Control Plane Nodes” stage the Control Plane nodes table is displayed.
| Column | Description |
|---|---|
| Name | Node name. Filtering is available by column. |
| IP address | The host’s IP address, if it has already been obtained. |
| State Cluster API Machine | Conditions of the Cluster API Machine resource. |
| Node State | Conditions Kubernetes node. When clicked, additional information opens. |
| Status | Node Status |
The number of raised Control Plane nodes and the total number are displayed.
Cluster API Machine objects are located in the management cluster; the Node object appears in the target cluster after successfully raising the bootstrap machine and registering the kubelet.
Worker nodes created
At the “Creating Worker nodes in groups” stage, Worker nodes are displayed by node groups.
| Column | Description |
|---|---|
| Name | Node name. Filtering is available by column. |
| IP address | The host’s IP address, if it has already been obtained. |
| State Cluster API Machine | Conditions of the Cluster API Machine resource. |
| Node State | Conditions Kubernetes node. When clicked, additional information opens. |
| Status | Node Status |
The number of raised and total number of Worker nodes is displayed.
NCI applied
At the “Applying NCI to nodes” stage (in the stage table - NCI applied), a list of default node configurations (NodeConfigItem, NCI) is displayed for use by the operator shturval-node-config.
| Column | Description |
|---|---|
| Name | NCI object name (for example, controlplane-init-config, controlplane-oidc-nci, generic-init-config). |
| Customized sections | List of configured configuration sections within NCI: Files, Users, KubeAPIServer, Packages, RuntimeCfg, Sysctl, SystemdUnits and other configuration sections. |
| Node selector | Labels by which nodes are selected to apply the configuration. |
| Applied on nodes | The ratio of the number of nodes on which the configuration has already been applied to the number planned for application, in the format successful/total (for example, 1/1, 4/4). |
After deployment is completed, the list of NCIs is available in the Administration section →Node Configuration (see Node Configuration (NCI)).
System services installed
Two installation steps
Cluster Manager installs the ShturvalServiceCofings and ShturvalServicePatches objects according to the service selection and features provided in the ClusterProfile.
Installation of services is carried out in two stages:
- Critical services are installed first. They cannot be disabled. For the management cluster, this is, in particular: shturval-backend, shturval-frontend, shturval-auth, network components, shturval-local-csi and other services from the “Critical Services” group.
- Selected at the “Select services” step - installed after critical ones.
The “Installing Shturval repository services” stage is considered completed only after installing the critical ones and those selected at the “Selecting services” step.
Services not selected during creation
Some CRD services that were not selected for automatic inclusion:
- Installed into the cluster during the deployment process;
- Remains disabled;
- Available in the Services and repositories section → Installed services.
This is how the preliminary configuration is performed. The next time you enable the service, you will not need to manually configure it—just enable it in the GUI. After deploying the cluster, you can install additional services. More details in the instructions how to deploy a new service.
Parameters of selected services
The selected services are installed with:
- Version — latest (for this platform version);
- Mode — automatic control (auto);
- Instance name takes the Russian-language name of the service instance specified in the chart annotation.
The composition, versions and grouping of services depend on the version of the Shturval platform. The current list of Shturval repository services, their quick installation groups and roles is given on the page “Shturval Repository Services”.
If an error occurs when installing or updating a service, a message is displayed in the conditions phase of the deployment status.
After deployment
At the “Installing Shturval repository services” stage a list of services is displayed.
| Column | Description |
|---|---|
| Service name | Service name (for example, shturval-auth, shturval-capi, shturval-capi-crds). |
| Chart name | The name of the Helm chart that you for the service is being shut down. |
| Namespace | Namespace in which the service is installed (for example, shturval-backend, capi-system). |
| Status | Service installation status in the platform. |
| State | Conditions for installing the service. Clicking opens detailed information on condition. |
| Critical | Indicates whether the service is critical to the operation of the platform. Shturval repository services |
Possible values in the “Status” column:
| Status label | Description | Value in data |
|---|---|---|
Installed | The service is installed and running | working |
Not started | Installation not yet started | notstarted |
Not installed | The service is not installed; an installation error occurred | undefined |
Under the hood
Creating nodes
Between clicking Create Cluster and the cluster becoming Ready, the platform gets the cluster nodes: infrastructure machine or host, then installs Kubernetes. For step-by-step wizard fields, see details of installation wizard steps.
The Shturval platform has two models for preparing nodes:
For virtualization and cloud providers, the platform, through the appropriate CAPI provider, requests the environment to create a host infrastructure from the specified template or image (in provider-specific terms). The platform does not prepare templates itself: preparation of the OS and the stc utility, association of the Kubernetes version with the template and adding the template to the instance are described on the page Preparing the provider template.
When creating a VM from a template, the platform autonomously installs Kubernetes of the selected version. The VM template stores the OS and associated disk limits, but **does not store the CPU/RAM resources of the original VM, i.e. when creating a VM from a template, the Cluster API provider requests resources from the infrastructure provider in the amount specified by the administrator when initializing the cluster.
After the cluster is deployed, the administrator can also override the node template settings using the InfraMachineTemplate resource. This resource is stored in the management cluster and does not create a template (image) on the virtualization (or cloud) side.
Custom resources
Cluster API (CAPI) and infrastructure provider objects describe the desired and actual state of the cluster and nodes; these custom resources are located in the management cluster. The Node object appears in the target cluster after the bootstrap machine is raised and the kubelet is registered.
View in GUI: Custom resources in the platform. The hierarchy and roles of the main types are in the tables below. For owner/dependent relationships in CAPI terms, see Cluster API (owner references) documentation.
Infrastructure machine templates by provider: InfraMachineTemplate. Self-healing of nodes: MachineHealthCheck.
CAPI core in the platform: Cluster API Provider (shturval-capi). Infrastructure providers: vSphere (shturval-capvs), oVirt (shturval-capov), OpenStack (shturval-capos), Shturval v2 (shturval-capsm), Basis Dynamix (shturval-capbd), Yandex Cloud (shturval-capy), vCloud Director (shturval-capvcd). Setting up provider instances in the UI: How to work with providers.
Listed below are the API and Kind groups used for the node lifecycle.
cluster.x-k8s.io
| Custom resource | Purpose | Role in the node life cycle | Where more details |
|---|---|---|---|
| Cluster | Root CAPI object representing the client Kubernetes cluster | Stores links to the infrastructure cluster, Control Plane and groups of Worker nodes | Cluster API |
| ClusterClass | Template model for describing clusters of the same type | Not used in the Shturval platform | Cluster API documentation |
| Machine | Representation of a single machine/node in a CAPI model | Links the bootstrap configuration and the infrastructure machine; after bootstrap gets a connection with Kubernetes Node | Cluster API |
| MachineDeployment | Declarative management of a group of Worker nodes | Sets the desired number of Worker nodes and templates for creating Machine, BootstrapConfig and InfraMachine | Cluster API |
| MachineDrainRule | Rules for draining machines during maintenance or removal | Affects the order of evacuation of workloads from the node; details depend on CAPI version | Cluster API documentation |
| MachineHealthCheck | Policy for automatic recovery of inoperative Machine | Monitors the status of nodes and can initiate replacement Machine | MachineHealthChecks |
| MachinePool | Model of a group of machines as a single pool | Not used in the Shturval platform | Cluster API documentation |
| MachineSet | Set of similar Machines according to template | MachineDeployment is created and supports the required number of Worker Machines | Cluster API |
controlplane.cluster.x-k8s.io
| Custom resource | Purpose | Role in the node life cycle | Where more details |
|---|---|---|---|
| KubeadmControlPlane | Control Plane control object based on kubeadm | Creates and maintains Machine for Control Plane nodes | Cluster API |
| KubeadmControlPlaneTemplate | KubeadmControlPlane Template | Used to create a KubeadmControlPlane from a template | Cluster API documentation |
bootstrap.cluster.x-k8s.io
| Custom resource | Purpose | Role in the node life cycle | Where more details |
|---|---|---|---|
| KubeadmConfig | Bootstrap configuration for one Machine | Generates data for kubeadm init / kubeadm join and a secret that is used when preparing the node | Cluster API |
| KubeadmConfigTemplate | Bootstrap configuration template | Used by MachineDeployment and other objects to create KubeadmConfig when new Machine | Cluster API |
infrastructure.cluster.x-k8s.io
Below are infrastructure CRs for the providers supplied in the platform. Detailed help on oVirt and Shturval v2 is provided on the service pages shturval-capov and shturval-capsm.
Basis Dynamix
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| BasisProvider | Basis Dynamix Connection/Provider Configuration | Used to work with a specific environment Basis Dynamix | shturval-capbd |
| BasisCluster | Cluster infrastructure object in Basis Dynamix | Associates a Cluster object with a provider infrastructure context | shturval-capbd |
| BasisMachine | One VM/machine in Basis Dynamix | Infrastructure part Machine; the provider creates or maintains a VM on it | shturval-capbd, InfraMachineTemplate |
| BasisMachineTemplate | BasisMachine Parameter Template | Used CAPI to create new BasisMachines in node groups | InfraMachineTemplate |
oVirt
Also relevant for zVirt, oVirt, HostVM, RED Virtualization, ROSA Virtualization
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| OVirtProvider | Connection parameters to oVirt Engine | Gives access to the oVirt API for creating and maintaining VMs | shturval-capov (CRD directory) |
| OVirtCluster | Cluster infrastructure object in oVirt | Stores the endpoint control plane and connects the Cluster with the oVirt infrastructure | shturval-capov |
| OVirtMachine | One VM in oVirt | Infrastructure part Machine; creates a VM from a template and sets ProviderID | shturval-capov |
| OVirtMachineTemplate | OVirtMachine Parameter Template | Used by MachineDeployment or KubeadmControlPlane to create OVirtMachine | InfraMachineTemplate |
OpenStack
Also relevant for VK Cloud, Selectel
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| OpenStackCluster | Cluster infrastructure object in OpenStack | Associates CAPI Cluster with project, network and endpoint in OpenStack | shturval-capos |
| OpenStackClusterTemplate | OpenStackCluster Template | Used when creating a template infrastructure cluster | shturval-capos |
| OpenStackMachine | One VM in OpenStack | Infrastructure part Machine; the provider creates and maintains the instance | shturval-capos |
| OpenStackMachineTemplate | OpenStackMachine Options Template | Used CAPI to create new OpenStackMachines in node groups | InfraMachineTemplate |
| OpenStackFloatingIPPool | Floating IP pool in the OpenStack provider model | Can be used by the provider to manage external addresses; details depend on CAPOS version | shturval-capos |
| OpenStackServer | OpenStack server/instance object in the provider model | Reflects the infrastructure essence of the provider; details - in the CRD of the specific version of CAPOS | shturval-capos |
Shturval v2
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| ShturvalProvider | Global SSH host configuration, version, registry and credentials | Creates and maintains ShturvalHost for addresses from the provider’s configuration | shturval-capsm |
| ShturvalHost | Description of the physical host or existing VM | Validated and provisioned via SSH, then can be linked to ShturvalMachine | shturval-capsm |
| ShturvalCluster | Cluster infrastructure object for Shturval v2 | Associates CAPI Cluster with provider configuration and cluster endpoint | shturval-capsm |
| ShturvalMachine | Infrastructure machine Shturval v2 | Selects the appropriate ShturvalHost, executes bootstrap and sets ProviderID | shturval-capsm |
| ShturvalMachineTemplate | ShturvalMachine Parameter Template | Describes a host selector for a group of hosts | InfraMachineTemplate |
| ShturvalManualCluster | Reinfrastructure provider resource Shturval v2 | The purpose depends on the CRD version; use the provider’s service help | shturval-capsm |
| ShturvalManualMachine | Infrastructure provider resource Shturval v2 | The purpose depends on the CRD version; use the provider’s service help | shturval-capsm |
VMware vCloud Director
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| VCDCluster | Cluster infrastructure object in vCloud Director | Associates CAPI Cluster with vCD context | shturval-capvcd |
| VCDClusterTemplate | VCDCluster Template | Used when creating a template infrastructure cluster | shturval-capvcd |
| VCDMachine | One VM in vCloud Director | Infrastructure part Machine; the provider creates and maintains the VM | shturval-capvcd |
| VCDMachineTemplate | VCDMachine Parameters Template | Used CAPI to create new VCDMachines in node groups | InfraMachineTemplate |
VMware vSphere
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| VSphereCluster | Cluster Infrastructure Object in vSphere | Links CAPI Cluster to VMware vSphere infrastructure | shturval-capvs |
| VSphereClusterIdentity | Credentials or identity for accessing VMware vSphere | Used by the provider for authentication in vCenter | shturval-capvs |
| VSphereClusterTemplate | VSphereCluster Template | Used when creating a template infrastructure cluster | shturval-capvs |
| VSphereDeploymentZone | Placement area in the CAPVS model | Helps describe where to place machines; details depend on CRD provider | shturval-capvs |
| VSphereFailureDomain | Failure Domain in the CAPVS Model | Used to distribute machines across fault-tolerant domains, if configured | shturval-capvs |
| VSphereMachine | One VM in VMware vSphere | Infrastructure part Machine; the provider creates and maintains the VM | shturval-capvs |
| VSphereMachineTemplate | VSphereMachine Options Template | Used CAPI to create new VSphereMachines in node groups | InfraMachineTemplate |
| VSphereVM | VM objectin the CAPVS model | Reflects VMware vSphere VMs at the provider level; details - in the CRD of the specific CAPV version | shturval-capvs |
Yandex Cloud
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| YandexCluster | Cluster infrastructure object in Yandex Cloud | Links CAPI Cluster to cloud infrastructure | shturval-capy |
| YandexIdentity | Account/identification data for Yandex Cloud | Used by the provider to access the cloud | shturval-capy |
| YandexMachine | One VM in Yandex Cloud | Infrastructure part Machine; the provider creates and maintains the VM | shturval-capy |
| YandexMachineTemplate | YandexMachine parameters template | Used CAPI to create new YandexMachines in node groups | InfraMachineTemplate |
IPAM (CAPI)
| Custom resource | Purpose | Role | Where more details |
|---|---|---|---|
| IPAddress | Individual IP Address Object in the IPAM CAPI Model | Can be used by CAPI/providers to keep track of issued addresses; details depend on IPAM provider | Cluster API Provider, Cluster API documentation |
| IPPool | IP address pool in the IPAM CAPI model | Source of addresses for IPAddress objects, if the corresponding IPAM provider is used | Cluster API Provider |
Built-in resources Kubernetes
| API group | Resource | Purpose | Role | Where more details |
|---|---|---|---|---|
core | Node | Built-in Kubernetes registered node object | Appears in the target cluster after bootstrap; CAPI Machine receives a link to Node | Cluster API (Machine ↔ Node connection) |
node.k8s.io | RuntimeClass | Built-in Kubernetes selection object container runtime handler | Not used in the Shturval platform | Kubernetes documentation |
Deployment errors
If an error occurs during the installation or cluster creation stage, the corresponding stage goes into error state (red indicatorand I). Details are in the conditions of the stage. Typical causes of errors:
- Troubleshooting client cluster creation;
- What to do if there is an error (client cluster).