Components in Managed Service for Kubernetes®

This article provides a quick overview of the Managed Service for Kubernetes components, their interactions and functions. A Managed Service for Kubernetes cluster consists of:

• Control plane
• Node components
• Sets of worker VMs (nodes and node groups) that run groups of containerized applications (Pods)

​

Control plane components

Control plane components manage the overall state of the cluster.

​

API server

The API server exposes the Kubernetes API to customers, acting as a frontend for REST operations. To learn more, see the official Kubernetes documentation for kube-apiserver.

​

Scheduler

Scheduler is responsible for determining which node runs a particular Pod with specified containers. When selecting a node to allocate a Pod, the scheduler takes into account quotas, resource requirements, deployments, taints and tolerations and other factors. To learn more, see the official Kubernetes documentation for Kubernetes scheduler.

​

Cluster autoscaler

In Managed Service for Kubernetes, the cluster autoscaler seamlessly adds nodes when there are unschedulable Pods, and removes underutilized nodes as needed. For more information, see Autoscaling in Managed Service for Kubernetes.

​

Controller manager

Controller manager runs controllers to implement Kubernetes API behavior. To reduce complexity, multiple controllers are compiled into one binary and run as a single process. Below are examples of frequently used controllers:

• Node controller ensures that each node is operational. If a node shuts down, node controller tries to restart it or relocate its Pods and containers to other nodes.
• Replication controller ensures that the same Pods are deployed across multiple nodes if required.
• Endpoint controller ensures that containers are accessible to users.

To learn more, see the official Kubernetes documentation for kube-controller-manager.

​

etcd

etcd is a consistent and highly available key-value store for API server data. By default, a Managed Kubernetes cluster is created with three etcd stores. This ensures high availability: The cluster is more reliable; data stored in etcd is more likely to be accessed in case of failures. The enabled high availability does not affect the cost of the cluster. You can find in-depth information on etcd in its official documentation.

​

Node-based control plane components

These components are located not in the control plane itself, but on each node running on the cluster.

​

kubelet

kubelet ensures that Pods and their containers are running. It communicates with the scheduler and controller manager. To learn more, see the official Kubernetes documentation for kubelet.

​

kube-proxy

kube network proxy manages traffic flow, ensuring that network rules work on nodes. To learn more, see the official Kubernetes documentation for kube-proxy.

​

Cilium

Cilium ensures that only specific services and traffic can access certain Pods. For example:

• Some Pods might contain sensitive data, and Cilium enforces rules that only certain internal services or authorized users are allowed to access it.
• If a node requires restricted access, Cilium ensures that only internal services with proper credentials or traffic with specific labels are allowed.

Also, Cilium provides observability into traffic between Pods and nodes to optimize network paths and enforce network security policies. You can find in-depth information on Cilium in its official documentation.

​

Worker components

This section describes the components that run and manage user workloads on your Managed Service for Kubernetes cluster.

​

Node

In Managed Service for Kubernetes, nodes are Compute virtual machines. There must be at least one node in a cluster for applications to function properly. On supported platforms, presets and regions, you can enable local SSD disks for worker nodes. Local SSD disks provide ephemeral storage intended for temporary data. By default, Managed Service for Kubernetes uses them as the node’s local ephemeral storage. To learn more, see the official Kubernetes documentation for nodes.

​

Node group

Node groups in Managed Service for Kubernetes organize nodes that serve a specific purpose. All nodes in a group share the same template. The number of nodes per node group cannot exceed 100. See more details in Creating and modifying Managed Service for Kubernetes® node groups. Node groups can use the cluster autoscaler to seamlessly add or remove nodes as needed. For more information, see Autoscaling in Managed Service for Kubernetes.

​

Pod

Pod is a group of one or more containers with shared storage and network resources. In a Managed Service for Kubernetes cluster, each Pod has a unique IP address so that workloads don’t conflict. To learn more, see the official Kubernetes documentation for Pods.

​

Taints and tolerations

Taints act like restrictions or rules for specific nodes. Tolerations are like clearances or permissions that certain Pods have to be placed on specified nodes. To learn more, see the official Kubernetes documentation for taints and tolerations.

​

DaemonSets

DaemonSets ensure that every node creates a Pod with a certain type of container. In Kubernetes, DaemonSets are used for infrastructure-related workloads, such as logging, monitoring or networking agents that must be deployed on every node. To learn more, see the official Kubernetes documentation for DaemonSets.