Skip to main content

Create a Managed Kubernetes cluster on a cloud server

You can create no more than 10 high-availability clusters and 10 basic Managed Kubernetes clusters on cloud servers in one project and one pool.

  1. Configure the cluster.
  2. Configure the node group.
  3. Configure automation.

1. Configure the cluster

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

  2. In the Clusters section, click Create cluster.

  3. Enter a cluster name. The name will be displayed in the cluster object names: node groups, nodes, load balancers, networks, and disks. For example, if the cluster name is kelsie, the node group name will be kelsie-node-gdc8q, and the boot disk name will be kelsie-node-gdc8q-volume.

  4. Select a location where the master nodes will be located. After the cluster is created, the location cannot be changed.

  5. Select a Kubernetes version. After the cluster is created, you can upgrade the Kubernetes version.

  6. Optional: select a network plugin (CNI). By default, Calico is used in the cluster. You cannot change the CNI after the cluster is created.

    In the Cilium network plugin, by default:

    • the envoy daemonset setting is enabled – learn more about the setting in the Envoy section of the Cilium documentation;
    • the hubble-relay setting is disabled – learn more about the setting in the Hubble Relay subsection of the Hubble internals article in the Cilium documentation.

    If you want to change these settings, create a cluster using the Managed Kubernetes API. Keep in mind that using the hubble-relay setting requires at least 4 GB of RAM on the node.

  7. Select a cluster type. After the cluster is created, the cluster type cannot be changed.

  8. Optional: to make the cluster accessible via a private network and inaccessible from the internet, select the Private kube API checkbox. By default, a cluster is created in a public network and is automatically assigned a public kube API IP address, which is accessible from the internet. After the cluster is created, the kube API access type cannot be changed.

  9. Click Continue.

2. Configure a node group

  1. In the Server type field, select Cloud server.

  2. Select a location where all working nodes in the group will be located. After the cluster is created, the location cannot be changed.

  3. Configure the worker node settings in the group:

    3.1. Click Select configuration and choose the configuration of the working nodes in the group:

    • custom — any resource ratio can be specified;
    • or fixed with GPU — ready-made node configurations with graphics processors and a predefined resource ratio.

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

    3.2. If you have selected a custom configuration, specify the number of vCPUs, RAM, and select a boot disk. Specify the disk size.

    3.3. If you have selected a fixed configuration with GPU, choose a ready-made configuration of nodes with graphics processors, a boot disk, and specify the disk size. To install GPU drivers yourself, turn off the GPU drivers toggle. By default, the GPU drivers toggle is turned on, and preinstalled drivers are used in the cluster.

    3.4. Click Save.

  4. 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; nodes can be located in different groups:

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

    4.2. To use autoscaling with Cluster Autoscaler in the node group, open the With autoscaling 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 unavailable for GPU node groups without drivers.

  5. Optional: to make a node group preemptible, select the Preemptible node group checkbox. Preemptible node groups are available in the regions of St. Petersburg, Moscow, and Novosibirsk.

  6. Optional: add node group labels:

    6.1. In the Labels field, click Add.

    6.2. Enter the label key.

    6.3. Enter the label value.

    6.4. Click Add.

  7. Optional: add node group taints:

    7.1. In the Taints field, click Add.

    7.2. Enter the taint key.

    7.3. Enter the taint value.

    7.4. Select an effect:

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

    7.5. Click Add.

  8. Optional: add a script with custom parameters for configuring the Managed Kubernetes cluster:

    8.1. In the User data field, click Add.

    8.2. Paste the script. The maximum size of the script with data that is not Base64 encoded is 47 KB. Script examples and supported formats can be found in the User data guide.

  9. Optional: to add an additional worker node group to the cluster, click Add node group. You can create a cluster with worker node groups in different segments of the same pool. This will increase fault tolerance and help keep the application available if an incident occurs in one of the segments.

  10. In the Cloud network block, configure a private subnet without internet access in which all cluster nodes will be grouped.

    10.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 the rules in it and do not assign a different security group. This will prevent cluster malfunctions.

    10.2. If a private subnet has already been created, in the Subnet for nodes field, select the existing subnet. The subnet must meet the following conditions:

    • Belongs to the project network in which you are creating the cluster. You can check which project a network belongs to in the Control panel: in the top menu, click Products → Managed Kubernetes → Network → the Private networks tab → the network card. If the network belongs to another project, the network card will have a Cross-project tag and information about the ID of the project 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 the ports. Do not change the rules in it and do not assign a different security group. This will prevent cluster malfunctions. You can view security groups on ports.

  11. Click Continue.

3. Configure automation

  1. Optional: to enable node auto-recovery, select the Node auto-recovery checkbox. If the cluster has only one worker node, auto-recovery is unavailable.

  2. Optional: to enable patch version auto-upgrades, select the Patch version auto-upgrade checkbox. If the cluster has only one master node (basic cluster) or one worker node, Kubernetes patch version auto-upgrades are unavailable.

  3. Select the cluster maintenance start time — the time when automatic cluster maintenance will begin.

  4. Optional: to enable audit logs, select the Audit logs checkbox. After the cluster is created, configure integration with a log storage and analysis system.

  5. Check the cluster price on the cloud server.

  6. Click Create. Cluster creation takes a few minutes, during which time the cluster will be in the status CREATING. The cluster will be ready to use when it switches to the ACTIVE status.