Architecture: control plane and worker nodes
Architecture: control plane and worker nodes
The one big idea
Desired state vs current state. You declare what you want; controllers compare it with reality and act until the two match.
Components
graph TB
subgraph control01 [Control plane]
API[kube-apiserver]
ETCD[(etcd)]
SCH[kube-scheduler]
CM[kube-controller-manager]
end
subgraph worker0X [Worker node]
KL[kubelet]
KP[kube-proxy]
CRI[containerd]
end
API --- ETCD
SCH --- API
CM --- API
KL --- API
KP --- API
KL --- CRI
| Component | Where | Job |
|---|---|---|
| kube-apiserver | control plane | the only door to the cluster; authN, authZ, validation |
| etcd | control plane | key-value store of all objects |
| kube-scheduler | control plane | picks a node for each new Pod |
| kube-controller-manager | control plane | runs the reconciliation loops |
| kubelet | every node | starts containers, reports status |
| kube-proxy | every node | Service routing (iptables / IPVS) |
| containerd | every node | container runtime (CRI) |
| CoreDNS | Pods in kube-system | cluster DNS |
Only the API server talks to etcd. Every other component - including kubectl - talks only to the API server.
What happens on kubectl apply
sequenceDiagram
participant U as kubectl
participant A as API server
participant E as etcd
participant C as controllers
participant S as scheduler
participant K as kubelet
U->>A: POST Deployment
A->>E: store
C->>A: watch - create ReplicaSet, Pods
S->>A: watch - bind Pod to worker02
K->>A: watch - my Pod!
K->>K: pull image, start container
K->>A: status Running
Nobody calls anybody directly - everyone watches the API server.
How kubeadm runs the control plane
The control plane components are static Pods: manifests in
/etc/kubernetes/manifests/ on control01, started by the kubelet itself. That
is why they appear in kube-system as kube-apiserver-control01 and so on.
The control plane node carries a taint
(node-role.kubernetes.io/control-plane:NoSchedule), so your workloads land
on the workers.
Pluggable by standard
- CRI - container runtime (containerd). Docker is not a CRI runtime.
- CNI - Pod networking. This cluster runs Calico (overlays and policy engines: Day 2 and Day 4).
- CSI - storage drivers.