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. Select a billing plan.

  4. Select a pre-configured dedicated server configuration. To filter configurations, you can use the search bar and the With GPU only checkbox.

    After the cluster is created, the node configuration cannot be changed.

  5. Optional: change the default disk partitioning:

    5.1. In the Disk partitioning field, click Edit.

    5.2. To resize 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).

    5.3. To opt out of the /storage partition, uncheck the /storage checkbox.

    5.4. Click Save.

  6. Configure the number of worker nodes:

    6.1. Go to the Fixed tab.

    6.2. Specify the number of nodes. For fault tolerance 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.

  7. Optional: in the Node group subnet field, enter the CIDR of a new private subnet to be used for the group worker nodes.

    The subnet must meet the following conditions:

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

    The subnet will be created in a dedicated VLAN. If you do not specify a CIDR, it will be assigned automatically upon cluster creation.

  8. Optional: add node group labels:

    8.1. In the Labels field, click Add.

    8.2. Enter the label key.

    8.3. Enter the label value.

    8.4. To add another label, repeat steps 8.1–8.3.

  9. Optional: add node group taints:

    9.1. In the Taints field, click Add.

    9.2. Enter the taint key.

    9.3. Enter the taint value.

    9.4. Select the 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 spots in the cluster;
    • NoExecute — running pods without tolerations will be evicted.

    9.5. To add another taint, repeat steps 9.1–9.4.

  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 non-Base64-encoded data is 47 KB. You can find script examples and supported formats in the User data instructions.

  11. Optional: in the Cloud network section, 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 subnet must meet the following conditions:

    • belong to the network of the project where 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 → Private networks tab → 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 in Managed Kubernetes internal addressing;
    • the subnet must not overlap with the node group subnet CIDR that you assigned in step 8.

    If you do not specify a CIDR, it will be assigned automatically upon cluster creation.

  12. Click Continue.

3. Configure automation

  1. Select the maintenance start time of the cluster — the time when automated cluster maintenance actions will start.

  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 once it transitions to the status ACTIVE.

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

    The default security group will be assigned to node ports. Do not change rules in it and do not assign another security group. This will prevent cluster malfunctions.