Managed Kubernetes Product Description

Servercore Managed Kubernetes simplifies the process of deploying, scaling, and maintaining Kubernetes container infrastructure. Servercore is responsible for 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.

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

You can manage your Managed Kubernetes cluster via the control panel and through the Managed Kubernetes API. For clusters on cloud servers, you can also use Terraform.

When choosing clusters on dedicated servers, consider the limitations.

Cluster composition

Managed Kubernetes clusters consist of:

• master nodes—contain the cluster management components, Control Plane. The number of master nodes depends on the cluster type. Master nodes are not displayed in the control panel; Servercore is responsible for them;

• worker node groups—contain user application containers. Worker nodes are displayed in the control panel; the user is responsible for them.

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. The cluster type cannot be changed after the cluster is created.

	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;
• automation: autoscaling and auto-recovery;
• Persistent Volume (PV) connection based on cloud platform network volumes;
• 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.