Creating and Configuring a Kubernetes Cluster

A Kubernetes cluster (K8s cluster) is a group of servers (nodes) that are grouped together to run and manage containerized applications. For more information on how a cluster works, see the article “Kubernetes Basics”.

To create a cluster, go to the “Cloud” section of the control panel, click “Create Service”, and select “Kubernetes Cluster”.

Name and Region

Enter the cluster name and select the region. Currently, only one region is available: Russia, Saint Petersburg.

Control Plane

The control plane consists of Kubernetes components in the cloud infrastructure that are responsible for coordinating the cluster and are deployed on dedicated master nodes. You need to select the number of master nodes and the Kubernetes version.

Number of master nodes

This parameter determines the cluster's fault tolerance:

1 master node – for development and testing.

• Minimum cost
• If a master node fails, applications that are already running continue to operate normally, but the cluster’s internal functions become unavailable: you cannot create or modify resources, schedule new pods, or execute kubectl commands
• Any maintenance (updates, restarts) results in the temporary unavailability of cluster management

3 master nodes – for production environments.

• If one master node fails, cluster management continues to operate without interruption
• Updates and maintenance are possible without loss of control
• The cluster state is replicated across nodes (etcd quorum – a majority of nodes is sufficient for decision-making)
• The cost is higher, but it ensures the fault tolerance of the control loop

How to choose: if uninterrupted cluster management is important to you (deploying, scaling, responding to incidents), choose 3 master nodes. For dev/test environments, where brief periods of management unavailability are acceptable, one is sufficient.

Kubernetes Version

Select a Kubernetes version for the cluster.

• The latest stable version is selected by default
• The version determines the available APIs and component behavior
• Use the latest stable version unless you have specific compatibility requirements

You can upgrade to a newer version after deploying the cluster. For more details, see the “Cluster Management” article.

Configuring the Cluster Network

Network settings determine how IP addresses are assigned to cluster components. These settings affect scalability, the number of pods, nodes, and services that can be in the cluster.

Service Address Range

IP addresses for internal Kubernetes services (kube-dns, API server, and others).

• Default starting address: 10.96.0.0
• Allowed networks: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• CIDR: from /16 to /24

All internal services in the cluster receive an address from this range.

Pod Address Range (Pod CIDR)

IP addresses assigned to pods.

• Default starting address: 10.244.0.0
• Allowed networks: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• CIDR: from /16 to /24

Each pod in the cluster receives a unique IP address from this range.

Node subnet mask

Determines how many pods can be hosted on a single node.

• Value: from /22 to /28

Each worker node receives its own subrange of addresses from the Pod CIDR. The size of this subrange is determined by the node subnet mask.

How the parameters are related

The pod range, node subnet mask, and maximum number of pods per node are interrelated parameters. The platform automatically calculates:

• Maximum number of pods per node – based on the node subnet mask
• Maximum number of nodes in the cluster – based on the pod range and node subnet mask

Example with default parameters:

• Pod range – 10.244.0.0/16
• Node subnet mask – /24
• Maximum pods per node – 256
• Maximum nodes in a cluster – 256

How to choose: The default values are suitable for most tasks. Increase the ranges if you plan to deploy a large cluster (hundreds of nodes) or a large number of pods per node. Keep in mind that these settings cannot be changed after creation. For more information on limitations when deploying a Kubernetes cluster, see the article “Limits, quotas, and constraints”.

Worker Groups

A worker group is a set of nodes with the same configuration on which your applications run. A cluster can contain multiple worker groups with different settings.

Why Use Multiple Worker Groups

Different applications may have different resource requirements:

• Web servers – many pods with low CPU and RAM usage
• ML tasks – few pods, but with large amounts of RAM or GPUs
• Background tasks – lower-cost nodes with no performance requirements

You can create a separate worker group for each type of workload and select the appropriate configuration for it. You can route pods to the desired group using labels and selectors.

Group parameters

Group name – any name. Can be set manually or generated automatically.

Number of nodes – how many servers will be in the group. Minimum – 1. Maximum – 500.

Node configuration – resources for each server (CPU, RAM, disk). Two options are available:

• Configurator for standard servers – flexible selection of parameters
• Pre-configured settings for high-frequency servers

All nodes in a single group have the same configuration.

Auto-healing

Auto-healing automatically checks the health of nodes in a worker group and restores them. If a node stays unhealthy for too long, the platform deletes it and creates a new one with the same configuration. This keeps the specified number of nodes in the group, so you don't have to recreate nodes manually.

Auto-healing is configured separately for each worker group:

• Auto-healing is disabled by default.
• You can enable it with the Auto-healing toggle when creating a cluster or a worker group.
• You can enable or disable auto-healing at any time in the worker group settings. The change is applied without recreating nodes and without interrupting the group.

How recovery works

New nodes. Auto-healing starts working as soon as the group is created. If a new node fails to start within 6 minutes, the platform retries creating it. Attempts continue until the node reaches the Running status.

Running nodes:

1. The node stops responding. Kubernetes marks it as NotReady and stops scheduling new pods on it.
2. After 5 minutes, the pods from this node are moved to other nodes in the group.
3. If the node remains unavailable for more than 15 minutes, the platform deletes it and creates a new one with the same configuration.
4. The new node joins the cluster, and a node with a new name appears in the node list.

The time thresholds are set by the platform and cannot be changed.

Without auto-healing, a faulty node remains in the cluster. You can restore it manually using the “Recreate node” button or by contacting technical support.

Limitations

• Auto-healing restores only worker nodes. Master nodes of the control plane are not covered.
• You cannot exclude an individual node from auto-healing. The feature can only be enabled or disabled for the entire worker group. If you need to troubleshoot a specific node, disable auto-healing for its group.

Labels

Labels are key-value pairs assigned to nodes. 

Labels do not restrict pod deployment, but they allow you to:

• Select nodes for pod placement using selectors (NodeSelector, affinity)
• Organize nodes by role, environment, or other criteria

Format:

node-role.kubernetes.io/<key>=<value>

Example: You can label a group with the label workload=gpu and specify in the pod manifest that it should only run on nodes with this label:

spec:
  nodeSelector:
    workload: gpu

Taints

Taints are a mechanism that prevents pods from running on specific nodes if the pods do not have the corresponding Toleration.

Format:

<key>=<value>:<effect>

Effects:

• NoSchedule – Pods without a Toleration will not be scheduled on this node
• PreferNoSchedule – Kubernetes will avoid scheduling pods without a Toleration, but may schedule them if resources are scarce
• NoExecute – Pods without a Toleration will be evicted from the node if they are already running

Example: You can assign the taint dedicated=critical:NoSchedule to a group of nodes so that only critical services run on them. To do this, specify the corresponding toleration in the pod manifest:

spec:
  tolerations:
    key: dedicated
    value: critical
    effect: NoSchedule

Authentication

SSH keys are used to connect directly to the worker group nodes via SSH. You can select one of the existing keys or add a new one.

Project

You can associate the cluster with a project for convenient resource management. An option to pin the cluster is also available in the main menu.

Cost and Creation

Before installing and creating a Kubernetes cluster, the page displays the total cost, both daily and monthly. The cost is calculated based on master node and worker group resources.

Click “Create Kubernetes Cluster” to start the creation process.

All articles in this section

1. Kubernetes (K8s) – An Overview of the Managed Kubernetes Service
2. Kubernetes Basics – Key Concepts: Cluster, Nodes, Pods, Services
3. Creating and Configuring a Cluster – You are here
4. Connecting to the Cluster and Working with kubectl – kubeconfig, Connectivity, and Core Kubernetes Tools
5. Cluster management – adding nodes, changing configuration, updating, and deleting
6. Networking and load balancers – network model, external and internal load balancers
7. Limits, quotas, and constraints – platform constraints, what can and cannot be changed

If you have any questions, please submit a ticket via the account dashboard (under “Help and Support”). And if you’d like to discuss this article or our products, we’d love to see you in our Telegram community.