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 fixed configuration dedicated servers with a local port.

The dedicated server is already assembled, mounted, and connected to a private network at L3 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, in the top menu, click Products and select Managed Kubernetes.

  2. In the Clusters section, click Create cluster.

  3. Enter the 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 disk 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, see the Envoy article in the Cilium documentation;
    • the hubble-relay setting is disabled — for details, 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 via 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 kube API access type cannot be changed.

  9. Click Next.

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 opt out of the /storage partition, clear the /storage checkbox.

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

    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 a new private subnet to be used for the 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 ranges 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. These ranges are used for Managed Kubernetes internal addressing.

    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. You can find script examples and supported formats in the User data instructions.

  10. Optional: in the Cloud network block, in the Cloud infrastructure subnet field, enter the CIDR of a new private subnet to 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 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 → 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 where 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 ranges 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. These ranges are used for Managed Kubernetes internal addressing;
    • 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 Next.

3. Configure automation

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

  2. Optional: to enable audit logs, select the Audit logs checkbox. After creating the cluster, configure integration with the log storage and analysis system.

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

  4. Click Create. Creating the cluster takes up to 60 minutes, during which time the cluster will be in the status CREATING. The cluster will be ready to work when it switches to the ACTIVE status.

    To connect master nodes and worker nodes on dedicated servers, the private network <cluster_name>-network, a private subnet, a VLAN, and the global router <cluster_name>-router will be created automatically, where <cluster_name> is the cluster name. The dedicated servers subnet CIDR is assigned automatically. If you did not specify the 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 prevent cluster malfunction.