Kubernetes architecture: control plane, nodes and pods

The control plane makes cluster-wide decisions, such as scheduling. It also responds to events, for example by starting a new pod when a Deployment has fewer replicas than it asks for.

Every cluster needs at least one worker node to run pods. In production, the control plane usually runs across several machines, and the cluster runs several nodes. That gives it fault tolerance and high availability.

A pod is a group of one or more containers that share network and storage. Worker nodes host the pods, and the scheduler picks the node for each one.

• kube-apiserver: the front end of the control plane, which exposes the Kubernetes API. The nodes, the scheduler, the controllers and kubectl all go through it. It scales by running more instances.
• etcd: the consistent, highly available key-value store that holds all cluster data. The Kubernetes docs advise a backup plan for that data.
• kube-scheduler: watches for new pods that have no node and picks a node for each. It weighs resource requests, hardware and policy constraints, and affinity rules, among other factors.
• kube-controller-manager: runs the built-in controllers, such as the Node, Job, EndpointSlice and ServiceAccount controllers. They’re compiled into one binary and run as one process.
• cloud-controller-manager: links the cluster to your cloud provider’s API. Its Node, Route and Service controllers check for deleted nodes, set up routes and manage load balancers. A cluster on your own premises has none.

How controllers keep the cluster at its desired state

A controller is a control loop, like a thermostat. It watches the state of the cluster, then makes or requests changes that move the current state closer to the desired state.

Built-in controllers act through the API server. The Job controller runs no pods or containers itself. It asks the API server to create or remove pods, then marks the Job finished once the work is done.

• kubelet: the agent on each node. It makes sure the containers in the node’s pods are running and healthy.
• Container runtime: runs the containers. Kubernetes supports containerd, CRI-O and any other runtime that implements the Container Runtime Interface (CRI). AKS uses containerd on Linux node pools running Kubernetes 1.19 and later.
• kube-proxy (optional): a network proxy that maintains each node’s network rules for Services. A network plugin that forwards Service traffic itself can replace it. AKS clusters on Azure CNI powered by Cilium use Cilium instead.

Add-ons are cluster features that run as ordinary workloads, such as DaemonSets and Deployments, in the kube-system namespace. Every cluster should have cluster DNS. On AKS, kube-system holds coredns, konnectivity-agent and metrics-server, among others.

Pods don’t get the whole node. AKS reserves CPU and memory on each node to keep it working, so pods can use less than the node’s total.

1. You run kubectl apply. It sends the Deployment to the API server, which stores it in etcd.

2. Controllers see that the Deployment has fewer pods than it asks for. They ask the API server to create the missing pods.

3. The scheduler sees each new pod with no node. It picks a node and binds the pod to it through the API server.

4. That node’s kubelet sees the pod and has the container runtime start its containers.

How the scheduler picks a node

Filtering comes first. It keeps the feasible nodes, such as those with enough free resources for the pod’s requests. Scoring then ranks them, and the pod binds to the top-scoring node, with a tie picked at random.

The fit check adds up requests, not use. Even on a node with very low CPU and memory use, the scheduler won’t place a pod whose requests don’t fit.

If no node passes filtering, the pod stays unscheduled. A node autoscaler reacts to such pending pods and can add a node with room for their requests.

Kubernetes uses a hub-and-spoke pattern. All API calls from nodes, and from the pods they run, end at the API server. No other control plane part is designed to expose remote services.

In the other direction, the API server calls each node’s kubelet. It does this to fetch pod logs, to attach to running pods and for port-forwarding.

With the Konnectivity service, beta since Kubernetes 1.18, agents on the nodes open the connections to the control plane. All traffic from the control plane to the nodes then goes through them. On AKS, konnectivity-agent pods run in kube-system.

Both follow the same architecture. Azure operates the AKS control plane in Automatic and Standard modes alike, and each EKS cluster gets a control plane of its own.

On AKS, system node pools host critical system pods such as CoreDNS and konnectivity-agent. User node pools host your apps.

On AKS, each node is charged as a standard VM, and VM discounts such as Azure reservations apply automatically. So the number and size of your nodes set that part of your cloud cost.

Node autoscalers add nodes with room for pending pods’ requests, and don’t directly look at the pods’ real use. So a pod that requests far more than it uses still gets a node with room for its full request.

Requests set from measured use fit the same pods on fewer nodes, which is what pod right sizing is for.