Managed Kubernetes Service (MKS)¶

The Managed Kubernetes Service (MKS) provides fully managed, production-ready Kubernetes clusters on top of your registered infrastructure. MKS handles the complexity of provisioning, configuring, and maintaining Kubernetes clusters, allowing you to focus on deploying and managing your applications.

Key Features¶

Lifecycle Management: Automated provisioning, scaling, and upgrades of Kubernetes clusters.
Control Plane Options: Choose between Standalone (SCP) and Hosted (HCP) control planes based on your needs.
Node Pools: Organize worker nodes into pools with different configurations (flavors, autoscaling).
Integrated Add-ons: Automatic configuration of CNI (networking), CCM (cloud integration), and CSI (storage).
High Availability: Support for multi-replica control planes for production workloads.

Control Plane Architectures¶

MKS supports two control plane architectures, selected at cluster creation time. This selection is immutable once the cluster is created.

Architecture	Description	Use Case
Standalone (SCP)	The control plane runs on dedicated virtual machines within your infrastructure. You manage the replica count (1 or 3) and flavor.	Standard deployments where you want dedicated resources for the control plane.
Hosted (HCP)	The control plane is hosted by the platform's management layer. No control plane VMs are provisioned in your infrastructure.	Resource-efficient deployments or clusters where you want to minimize infrastructure overhead.

Standalone Control Plane (SCP)¶

When using SCP, you must specify:

Replicas: 1 for development/testing, or 3 for high availability.
Flavor: The compute flavor for the control plane nodes.

Hosted Control Plane (HCP)¶

When using HCP, the control plane is managed automatically. It is always highly available (3 replicas) and does not consume your infrastructure's compute quota for control plane nodes.

Cluster Lifecycle¶

Creation¶

When creating a cluster, you define the target version, infrastructure, and initial node pools. At least one node pool is required. The available Kubernetes versions are offered per infrastructure and may include a platform build suffix (for example 1.32.3-5). MKS will orchestrate the deployment across your infrastructure providers.

Scaling¶

You can scale your cluster by:

Changing the number of replicas in the SCP Control Plane (1 or 3).
Adding or removing nodes in Node Pools (0–20 nodes per pool; scaling to 0 empties the pool).
Enabling the Cluster Autoscaler for automatic scaling based on workload pressure (up to 20 nodes).

Scaling and upgrades require the cluster to be active and healthy.

Upgrades¶

MKS supports non-disruptive upgrades for both the control plane and node pools.

Control Plane Upgrade: Updates the Kubernetes version of the control plane. Upgrades are sequential (e.g., 1.32 to 1.33), and the control plane must be upgraded before its node pools.
Node Pool Upgrade: Brings the worker nodes up to the control plane's version. This replaces all nodes in the pool, is not reversible, and typically takes 15–30 minutes. A pool that already matches the control plane cannot be upgraded.

Node Pools¶

Node Pools allow you to group worker nodes with similar configurations.

Flavors: Assign different compute flavors to different node pools (e.g., memory-optimized for databases, CPU-optimized for web servers).
Autoscaling: Enable the Cluster Autoscaler per node pool to automatically manage the number of nodes between a minimum and maximum range.
Independent Management: Scale or upgrade node pools independently without affecting other pools in the cluster.

Built-in Add-ons¶

Every MKS cluster comes pre-configured with essential Kubernetes components:

Networking (CNI): A CNI (such as Flannel) provides pod networking and network policy support.
Cloud Provider (CCM): Integrates Kubernetes with your infrastructure for load balancer and volume management.
Storage (CSI): A CSI driver (such as Cinder on OpenStack) enables persistent volume support for your stateful applications.
Autoscaler: Manages node pool size automatically when enabled.

Lifecycle States¶

MKS Clusters and Node Pools follow a non-linear lifecycle. Unlike other resources, they can undergo various maintenance operations like scaling or version upgrades after they are active.

Pending: The resource is being prepared for creation.
Creating: The infrastructure is provisioning the cluster or node pool.
Active: The resource is operational and available for use.
Updating: Configuration changes (like flavor changes) are being applied.
Scaling: A request to change the number of nodes or control plane replicas is in progress.
Upgrading: A Kubernetes version upgrade is being applied sequentially.
Degraded: An update or upgrade action failed. The resource is still operational but in a sub-optimal state. This state is usually recoverable by retrying the operation or fixing the underlying configuration.
Deleting: The resource and its associated components are being removed.
Error: A fatal operation failed, and the resource requires manual intervention or deletion.

Each cluster and node pool keeps an action history, from which you can retry (resync) an operation or cancel one that is still in progress.

Getting Started¶

To deploy your first cluster, navigate to the Managed Services > Kubernetes section in the platform dashboard or use the API to create a new MKS resource. You select a project and an infrastructure Service Config; the cluster attaches to the external network defined by that Service Config's MKS network platform (see Infrastructure, Service Configs and Service Platforms).

For more details on infrastructure requirements, see the OpenStack Setup Guide.