Skip to main content

Create a Managed Kubernetes cluster on a dedicated server

Last update:

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;
  • an increased level of privacy;
  • reserved resources.

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

A dedicated server is already assembled, mounted, and joined to a private L3 network with the Kubernetes Control Plane using a Global Router.

You can create no more than 10 high-availability clusters and 10 basic Managed Kubernetes clusters on dedicated servers within a single project and a single pool.

When selecting 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. Click Create cluster.

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

  4. Select a location where the master nodes will be located. You cannot change the location after the cluster is created.

  5. Select a Kubernetes version.

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

    In the Cilium network plugin, by default:

    • envoy daemonset is enabled – learn more about this setting in the Envoy section of the Cilium documentation;
    • hubble-relay is disabled – learn more about this 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. Note that using the hubble-relay setting requires at least 4 GB of RAM on the node.

  7. Select a cluster type. You cannot change the cluster type after the cluster is created.

  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, which is accessible from the internet. You cannot change the kube API access type after the cluster is created.

  9. Click Continue.

2. Configure the node group

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

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

  2. Select a location where all worker nodes in the group will be located. You cannot change the location after the cluster is created.

  3. Configure the worker node settings in the group:

    3.1. Click Select configuration.

    3.2. Select a pricing plan.

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

    3.4. Click Select.

    You cannot change the node configuration after the cluster is created.

  4. Optional: change the default disk partitioning:

    4.1. In the Disk partitioning field, click Edit.

    4.2. To remove the /storage partition, uncheck the /storage checkbox.

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

    4.4. Click Save.

  5. Configure the quantity of worker nodes:

    5.1. Open the Fixed tab.

    5.2. Specify the number of nodes. For high-availability of system components and the Cilium network plugin, we recommend having at least two worker nodes in the 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 the group's worker nodes.

    The subnet must meet the following conditions:

    • belongs to the private address range 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16;
    • it 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, one will be assigned automatically when the cluster is created.

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

    • NoSchedule — new pods will not be added, and existing ones will continue to run;
    • PreferNoSchedule — new pods will be added if no other free space is available 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 the script with non-Base64-encoded data is 47 KB. You can find script examples and supported formats in the User data guide.

  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 subnet must meet the following conditions:

    • the subnet must be private — belong to the 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. These ranges are used for internal addressing in Managed Kubernetes;
    • the subnet must not overlap with the CIDR of the node group subnet you assigned in step 8.

    If you do not specify a CIDR, one will be assigned automatically when the cluster is created.

  11. Click Continue.

3. Configure automation

  1. Select a cluster maintenance start time — the time when automatic cluster maintenance begins.

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

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

  4. Click Create. Cluster creation takes up to 60 minutes, during this time the cluster will be in the status CREATING. The cluster will be ready for use when it switches to the ACTIVE status.

    A private network <cluster_name>-network, a private subnet, a VLAN, and a global router <cluster_name>-router will be automatically created for communication between master nodes and worker nodes on dedicated servers, 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 the rules in it or assign a different security group. This will help avoid cluster operation failures.