Add a node group to a Managed Kubernetes cluster

You can add a node group on a cloud server or dedicated server to a Managed Kubernetes cluster. You cannot simultaneously use node groups on dedicated servers and node groups on cloud servers in the same cluster.

Learn more about configurations in the Managed Kubernetes node configurations instructions.

Add a node group on a cloud server

Control panel

1. In the Control panel, in the top menu, click Products and select Managed Kubernetes.

2. In the Clusters section, open the cluster page → Cluster topology tab.

3. Click Add node group.

4. Select the location where all worker nodes in the group will be located. After adding the node group, the location cannot be changed.

5. Configure the worker nodes in the group:

   5.1. Select the configuration of the worker nodes in the group:

   • Standard — you can specify any resource ratio;
   • or GPU — pre-configured node configurations with GPUs and a fixed resource ratio.

   If these configurations do not suit your needs, after creating the cluster, you can add a node group with a fixed cloud server configuration using the Managed Kubernetes API or Terraform.

   5.2. If you selected the Standard configuration, specify the number of vCPUs, RAM, and select a boot drive. Specify the disk size.

   5.3. If you selected the GPU configuration, select the GPU model and node configuration. To install GPU drivers yourself, turn off the GPU Drivers toggle switch. By default, the GPU Drivers toggle switch is on, and preinstalled drivers are used in the cluster. Select a boot disk and specify the disk size.

6. Configure the number of worker nodes. For fault-tolerant operation of system components and the Cilium network plugin, we recommend having at least two worker nodes in the cluster; the nodes can be in different groups:

   6.1. To set a fixed number of nodes in the node group, open the Fixed tab and specify the number of nodes.

   6.2. To use autoscaling with Cluster Autoscaler in the node group, open the Autoscaled tab and set the minimum and maximum number of nodes in the group — the number of nodes will change only within this range. Autoscaling is not available for GPU node groups without drivers.

7. Optional: add node group labels:

   7.1. In the Labels field, click Add.

   7.2. Enter the label key.

   7.3. Enter the label value.

8. Optional: add node group taints:

   8.1. In the Taints field, click Add.

   8.2. Enter the taint key.

   8.3. Enter the taint value.

   8.4. Select an effect:

   • NoSchedule — new pods will not be scheduled, and existing ones will continue running;
   • PreferNoSchedule — new pods will be scheduled if there are no other available places in the cluster;
   • NoExecute — running pods without matching tolerations will be evicted.

9. Optional: to make the node group preemptible, in the Additional settings field, select the Preemptible node group checkbox. Preemptible node groups are available in the regions of Saint Petersburg, Moscow, and Novosibirsk.

10. Optional: add a script with custom parameters to configure the Managed Kubernetes cluster:

    10.1. In the User data field, click Add.

    10.2. Paste the script. The maximum size of a script with data not encoded in Base64 is 47 KB. For script examples and supported formats, see the User data instructions.

11. In the Cloud network block, configure a private subnet without internet access that will unite all cluster nodes.

    11.1. To create a private subnet, in the Subnet for nodes field, select New private subnet.

    A private network <cluster_name>-network, a private subnet, and a router <cluster_name>-router will be created automatically, where <cluster_name> is the cluster name. The CIDR is assigned automatically.

    The default security group will be assigned to node ports. Do not change its rules or assign another security group. This will help avoid cluster malfunctions.

    11.2. If a private subnet is already created, in the Subnet for nodes field, select an existing subnet. The subnet must meet the following conditions:

    • belongs to the network of the project where you are creating the cluster. You can check which project the network belongs to in the Control panel: in the top menu, click Products → Managed Kubernetes → Network → Private networks tab → network card. If the network belongs to another project, the network card will have the Cross-project tag and information about the project ID in which it was created;
    • connected to a cloud router;
    • does not overlap with the 10.10.0.0/16, 10.96.0.0/12, 10.250.0.0/16, and 10.251.0.0/24 ranges. These ranges are used for Managed Kubernetes internal addressing;
    • DHCP is disabled;
    • only the default security group is assigned to ports. Do not change its rules or assign another security group. This will help avoid cluster malfunctions. You can view security groups on ports.

12. Click Add. You can view all created nodes in the Control panel: in the top menu, click Products and select Cloud Servers.

API

1. View the list of fixed configuration flavors in a specific pool.
2. In the flavor line, copy the value from the ID column.
3. Using the Managed Kubernetes API methods, create a cluster with a node group having the desired configuration or add a node group to an existing cluster. In the request, for the flavor_id parameter, specify the fixed configuration ID value that you copied in step 2.

Terraform

Follow the instructions in the Terraform documentation:

• Create a basic Managed Kubernetes cluster;
• Create a high-availability Managed Kubernetes cluster.

View the list of flavors in a specific pool⁠

Flavors correspond to cloud server configurations and determine the number of vCPUs, RAM, and the server's local disk size (optional). You can view all pre-made cloud server flavors and custom flavors created on request.

1. Open the OpenStack CLI.

2. If the pool you specified when configuring OpenStack CLI does not match the pool whose flavors you want to view, change the authorization credentials in the OpenStack API.

3. View the list of available flavors:

   openstack flavor list

   Example response for the ru-9 pool (truncated):

   +------------+-----------------------+--------+------+-----------+-------+-----------+
   | ID         | Name                  |    RAM | Disk | Ephemeral | VCPUs | Is Public |
   +------------+-----------------------+--------+------+-----------+-------+-----------+
   | 1          | m1.tiny               |    512 |    0 |         0 |     1 | True      |
   | 1011       | SL1.1-1024            |   1024 |    0 |         0 |     1 | True      |
   | 3021       | GL2.6-24576-0-1GPU    |  24576 |    0 |         0 |     6 | True      |
   | 9011       | PRC10.1-512           |    512 |    0 |         0 |     1 | True      |
   | 9021       | PRC20.1-512           |    512 |    0 |         0 |     1 | True      |
   | 9051       | PRC50.1-512           |    512 |    0 |         0 |     1 | True      |
   | 8301       | HFL1.1-2048-30        |   2048 |   30 |         0 |     1 | True      |
   +------------+-----------------------+--------+------+-----------+-------+-----------+

   Where:

   • ID — ID of the cloud server flavor;

   • Name — flavor name corresponding to the configuration:

     • m1.XX — basic OpenStack configurations, similar to custom configurations;
     • SLX.XX — fixed configurations of the Standard line;
     • GLX.XX — fixed configurations of the GPU line;
     • PRC10.XX — fixed configurations of the Shared line with a 10% vCPU share;
     • PRC20.XX — fixed configurations of the Shared line with a 20% vCPU share;
     • PRC50.XX — fixed configurations of the Shared line with a 50% vCPU share;
     • HFLX.XX — fixed configurations of the HighFreq line;

   • RAM — RAM size in MB;

   • Disk — local drive size in GB;

   • VCPUs — number of vCPUs;

   • Is Public — flavor scope:

     • True — public pre-made flavors;
     • False — private flavors.

Add a node group on a dedicated server

1. In the Control panel, in the top menu, click Products and select Managed Kubernetes.

2. In the Clusters section, open the cluster page → Cluster topology tab.

3. Click Add node group.

4. Select the pool where all worker nodes in the group will be located. Worker nodes must be in a pool from the same availability zone as the master nodes. After creating the node group, the pool cannot be changed.

5. Configure the worker nodes in the group:

   5.1. Click Select configuration.

   5.2. Select a billing plan.

   5.3. If you need a configuration with GPU, select the GPU only checkbox.

   5.4. Select a pre-configured dedicated server configuration.

   5.5. Click Select.

   After creating the cluster, the node configuration cannot be changed.

6. Optional: change the default disk partitioning:

   6.1. Click Edit.

   6.2. To opt out of the /storage partition, clear the /storage checkbox.

   6.3. To resize the /root partition, in the /root line, change the number of gigabytes allocated for this partition. The minimum size is 30 GB. The maximum size is 2 GB less than the disk size (1 GB for the /boot partition and 1 GB for the /storage partition).

   6.4. Click Save.

7. Configure the number of worker nodes:

   7.1. Open the Fixed tab.

   7.2. Specify the number of nodes. The minimum number of nodes is one. For fault-tolerant operation of system components, we recommend having at least two worker nodes in the cluster; the nodes can be in different groups.

8. Optional: in the Node group subnet CIDR field, enter the CIDR of the new private subnet that will be used for the worker nodes in the group.

   The subnet must meet the following conditions:

   • the subnet must be private — belong to the range 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16;
   • the subnet size must be /24;
   • the subnet must not overlap with the 10.10.0.0/16, 10.222.0.0/16, 10.250.0.0/16, 10.251.0.0/24, and 172.250.0.0/14 ranges. These ranges are used for Managed Kubernetes internal addressing;
   • the subnet must not overlap with the subnet CIDR of another node group and the cloud network CIDR used for communication between master nodes and the service global router.

   The subnet will be created in a separate VLAN. If you do not specify a CIDR, it will be assigned automatically when creating the cluster.

9. Optional: add node group labels:

   8.1. In the Labels field, click Add.

   8.2. Enter the label key and value.

   8.3. Click Add.

10. Optional: add node group taints:

    9.1. In the Taints field, click Add.

    9.2. Enter the taint key and value.

    9.3. Select an effect:

    • NoSchedule — new pods will not be scheduled, and existing ones will continue running;
    • PreferNoSchedule — new pods will be scheduled if there are no other available places in the cluster;
    • NoExecute — running pods without matching tolerations will be evicted.

    9.4. Click Add.

11. Optional: add a script with custom parameters to configure the Managed Kubernetes cluster:

    9.1. In the User data field, click Add.

    9.2. Paste the script. The maximum size of a script with data not encoded in Base64 is 47 KB. For script examples and supported formats, see the User data instructions.

12. Click Add. You can view all created nodes in the Control panel: in the top menu, click Products → Dedicated Servers.