Skip to main content

Create a Managed Kubernetes cluster on a dedicated server

You can create a Managed Kubernetes cluster with a node group on a dedicated server.

Dedicated servers are used when you need:

  • consistently high performance;
  • increased confidentiality;
  • reserved capacity.

In Managed Kubernetes, you can use prebuilt dedicated servers with a local port.

The dedicated server is already assembled, mounted, and joined into a private network at the L3 level with the Kubernetes Control Plane using a global router.

In one project and in one pool, you can create up to 10 fault-tolerant clusters and 10 basic Managed Kubernetes clusters on dedicated servers.

When choosing clusters on dedicated servers, consider the limitations.

  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 names of cluster objects: 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 volume name will be kelsie-node-gdc8q-volume.

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

  5. Select the Kubernetes version.

  6. Optional: select a network plugin (CNI). Calico is used in the cluster by default. The CNI cannot be changed after creating the cluster.

    In the Cilium network plugin, by default:

    • the envoy daemonset setting is enabled – for details on configuration, see the Envoy Cilium documentation article;
    • the hubble-relay setting is disabled – for details on configuration, see 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. Note that to use the hubble-relay setting, a node must have at least 4 GB RAM.

  7. Select the cluster type. After creating the cluster, the cluster type cannot be changed.

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

  9. Click Continue.

2. Configure the node group

When creating a cluster, you can add only one node group. You can add additional node groups to an existing cluster.

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

  2. Select the location where all worker nodes in the group will be located. After creating the cluster, the location cannot be changed.

  3. Configure the worker node configuration in the group:

    3.1. Click Select configuration.

    3.2. Select a billing plan.

    3.3. Select a prebuilt configuration of dedicated servers. Disks in all configurations are combined into RAID1 — all data is simultaneously written to two physical disks in a RAID array.

    3.4. Click Select.

    The node configuration cannot be changed after creating the cluster.

  4. Optional: change the default disk partitioning:

    4.1. In the Disk partitioning field, click Edit.

    4.2. To discard the /storage partition, uncheck /storage.

    4.3. To change the size of the root partition /, in the root partition 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).

    4.4. Click Save.

  5. Configure the number of worker nodes:

    5.1. Open the tab Fixed.

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

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

    The subnetwork must meet the conditions:

    • belongs to the private address range 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16;
    • has a size of /24;
    • does 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 internal addressing in Managed Kubernetes.

    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.

  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.

    7.4. Click Add.

  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 the effect:

    • NoSchedule — new pods will not be added, and existing ones will continue to run;
    • PreferNoSchedule — new pods will be added if there is no other free space in the cluster;
    • NoExecute — running pods without tolerations will be evicted.

    8.5. Click Add.

  9. 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 non-Base64 encoded data is 47 KB. For script examples and supported formats, see the instructions in User data.

  10. Optional: in the Cloud network block, in the Cloud infrastructure subnet field, enter the CIDR of the new private subnet that will be used for communication between master nodes and the service global router.

    The subnetwork must meet the conditions:

    • belongs to the network of the project in which you are creating the cluster. You can see 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 ID of the project in which it was created;
    • 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 internal addressing in Managed Kubernetes;
    • the subnet must not overlap with the CIDR of the node group subnet that you specified in step 8.

    If you do not specify a CIDR, it will be assigned automatically when creating the cluster.

  11. Click Continue.

3. Configure automation

  1. Select the cluster maintenance start time — the time when automatic cluster maintenance activities will start.

  2. Optional: to enable audit logs, select the Audit logs checkbox. After creating the cluster, configure export of audit logs.

  3. Check the price of the cluster on a dedicated server.

  4. Click Create. Cluster creation takes up to 60 minutes, during which the cluster will be in the status CREATING. The cluster will be ready for operation when it changes to the status ACTIVE.

    To connect master nodes and worker nodes on dedicated servers, a private network <cluster_name>-network, a private subnet, a VLAN, and a global router <cluster_name>-router will be automatically created, where <cluster_name> is the cluster name. The dedicated server subnet CIDR is assigned automatically. If you did not specify a cloud infrastructure subnet CIDR when configuring node groups, it will also be assigned automatically.

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