Managed Kubernetes Product Description

Servercore Managed Kubernetes simplifies the process of deploying, scaling, and maintaining your Kubernetes container infrastructure. Servercore handles version updates, security, and the health of the Kubernetes Control Plane.

The product supports user types and roles, projects, and project limits and quotas.

Logs of operations with Managed Kubernetes clusters are saved in audit logs.

Versions

Managed Kubernetes clusters support versions 1.34.x, 1.35.x, and 1.36.x.

How Managed Kubernetes works

A Managed Kubernetes cluster can run on:

• on cloud servers — uses cloud platform resources;
• or on dedicated servers — dedicated servers, dedicated server networks, and cloud platform resources are used (load balancers, public subnets, public floating IP addresses).

Learn more about the resources used in the Projects guide.

CRI is used as the container runtime environment (containerd). As a network plugin (CNI) in Managed Kubernetes clusters, you can use Calico or Cilium.

You can manage your Managed Kubernetes cluster in the Control Panel or via the Managed Kubernetes API. You can also interact with a cluster on a cloud server using Terraform.

When choosing clusters on dedicated servers, consider the limitations.

Cluster composition

Managed Kubernetes clusters consist of:

• master nodes — contain the cluster management components, the Control Plane. The number of master nodes depends on the cluster type. Master nodes are not visible in the Control Panel; they are maintained by Servercore;

• worker node groups — contain your user application containers. Worker nodes are visible in the Control Panel and are maintained by the user.

Cluster types

Servercore provides three types of Managed Kubernetes clusters: fault-tolerant multi-zonal, fault-tolerant, and basic.

You can only select the cluster type when creating a cluster. After a cluster is created, its type cannot be changed.

	Fault-tolerant multi-zonal	Fault-tolerant	Basic
Number of master nodes	3	3	1
Fault tolerance	Master nodes are located in different segments of a multi-zonal pool. Each segment is in a separate data center. If one of the data centers is unavailable, the Control Plane will continue to operate	Master nodes are located: in different segments of a single-zonal pool — if the pool has multiple segments; or in one segment of a single-zonal pool on different hosts — if the pool has only one segment If one of the three master nodes is unavailable, the Control Plane will continue to operate	A master node is located in one segment of a single-zonal pool. If the master node is unavailable, the Control Plane will not work
SLA	✓ (99.98%)	✓ (99.98%)	✗
Functionality	Full functionality available	Full functionality available	Patch version auto-update unavailable
Suitable for	For production environment (production)	For production environment (production)	for development environment (development); testing environment (testing and staging); pet projects

Limits

Cloud server

Maximum number of fault-tolerant Kubernetes clusters in one pool for one project	10
Maximum number of basic Kubernetes clusters in one pool for one project	10
Maximum number of node groups in one pool for one project	100
Maximum number of nodes in one node group	15
Maximum number of vCPUs per node	32 *
Maximum amount of RAM per node	256 * GB
Maximum boot disk size per node	1.2 TB
Maximum number of pods per node	100
Maximum number of Persistent Volumes (PV) per node	256
Minimum size of one Persistent Volume (PV)	1 GB

* You can create nodes with more vCPUs and RAM — use fixed cloud server configurations.

Dedicated server

Maximum number of fault-tolerant Kubernetes clusters in one pool for one project	10
Maximum number of basic Kubernetes clusters in one pool for one project	10
Maximum number of node groups in one pool for one project	100
Maximum number of nodes in one node group	15

Cluster limitations on dedicated servers

Managed Kubernetes clusters on dedicated servers do not support:

• use of custom dedicated server configurations;
• adding existing dedicated servers to a cluster;
• adding multiple node groups when creating a cluster;
• Kubernetes minor version updates;
• automation: patch version auto-updates, autoscaling, and auto-recovery;
• connecting a Persistent Volume (PV) based on cloud platform network volumes;
• using user data;
• using Terraform.

Areas of responsibility

Servercore provides

• creation and availability of master nodes;
• creation of worker nodes;
• Managed Kubernetes cluster version updates;
• master node monitoring;
• node autoscaling capability;
• node auto-recovery capability;
• integration with Servercore services;
• technical support.

Servercore is not responsible

• for Managed Kubernetes cluster management;
• worker node management;
• application creation;
• initiating scaling and updates.