Stage 5 · Platform
Kubernetes Architecture Deep Dive
Control Plane Components
API server, controller manager, scheduler, etcd — roles and HA.
Control Plane Overview
The Kubernetes control plane is the brain of the cluster. It makes global decisions about the cluster (scheduling, scaling) and detects and responds to cluster events (pod crashes, node failures). Understanding each component and its responsibilities is essential for operating Kubernetes in production.
The control plane runs management components (API server, scheduler, controllers, etcd). The data plane consists of worker nodes running kubelet and kube-proxy. Separating these planes is critical for security and reliability.
kube-apiserver
The API server is the front door to the entire cluster. Every component — kubectl, kubelet, controller-manager, scheduler — communicates through it. It authenticates requests, authorizes them, validates objects, and persists them to etcd. It also emits watch events that drive all controllers.
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
namespace: kube-system
spec:
containers:
- name: kube-apiserver
image: k8s.gcr.io/kube-apiserver:v1.30.0
command:
- kube-apiserver
- --etcd-servers=https://127.0.0.1:2379
- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
- --service-account-key-file=/etc/kubernetes/pki/sa.pub
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
- --admission-control=NodeRestriction,ServiceAccount
- --authorization-mode=Node,RBACThe API server runs as a static pod managed by kubelet. It authenticates with client TLS certs, connects to etcd with its own TLS pair, and enables admission controllers for request validation.
Controller Manager
The controller manager runs multiple controllers in a single process. Each controller watches a specific resource type and reconciles the desired state (from the API server) with the actual state. For example, the Deployment controller watches Deployments and creates ReplicaSets; the Node controller watches nodes and marks them unhealthy after timeout.
apiVersion: v1
kind: Pod
metadata:
name: kube-controller-manager
namespace: kube-system
spec:
containers:
- name: kube-controller-manager
image: k8s.gcr.io/kube-controller-manager:v1.30.0
command:
- kube-controller-manager
- --leader-elect=true
- --leader-elect-namespace=kube-system
- --leader-elect-lease-duration=15s
- --leader-elect-retry-period=2s
- --profiling=false
- --use-service-account-credentials=trueLeader election ensures only one controller-manager is active in HA setups. The --leader-elect flag coordinates a distributed lock via etcd. The --use-service-account-credentials flag gives each controller its own identity instead of sharing the controller-manager's SA.
In production, always keep --leader-elect=true. Disabling it causes split-brain behavior where multiple controller instances compete to reconcile the same resources, causing flapping and inconsistent state.
kube-scheduler
The scheduler watches for unscheduled pods and assigns them to nodes. It runs a two-phase process: filtering (eliminating nodes that can't run the pod) and scoring (ranking remaining nodes to pick the best one). It respects node affinity, taints/tolerations, resource requests, and topology constraints.
apiVersion: v1
kind: Pod
metadata:
name: kube-scheduler
namespace: kube-system
spec:
containers:
- name: kube-scheduler
image: k8s.gcr.io/kube-scheduler:v1.30.0
command:
- kube-scheduler
- --leader-elect=true
- --leader-elect-namespace=kube-system
- --config=/etc/kubernetes/scheduler-config.yaml
- --v=2The scheduler uses a configuration file for pluggable framework. Plugins like NodeResourcesFit, PodTopologySpread, and InterPodAffinity are configured through the scheduler config API.
etcd Cluster
etcd is the distributed key-value store that holds all cluster state. Every API object — Pods, Services, ConfigMaps, CRDs — is stored in etcd. It uses the Raft consensus protocol to replicate data across nodes. Without etcd, the control plane cannot function.
apiVersion: v1
kind: Pod
metadata:
name: etcd
namespace: kube-system
spec:
containers:
- name: etcd
image: k8s.gcr.io/etcd:3.5.12-0
command:
- etcd
- --data-dir=/var/lib/etcd
- --listen-client-urls=https://127.0.0.1:2379
- --advertise-client-urls=https://127.0.0.1:2379
- --listen-peer-urls=https://127.0.0.1:2380
- --initial-cluster=etcd=https://127.0.0.1:2380
- --initial-advertise-peer-urls=https://127.0.0.1:2380
- --client-cert-auth=true
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
- --cert-file=/etc/kubernetes/pki/etcd/server.crt
- --key-file=/etc/kubernetes/pki/etcd/server.keyetcd listens on localhost only. The API server connects to it via TLS. For multi-node etcd clusters, each member listens on its own IP and the --initial-cluster flag lists all members for initial bootstrapping.
High Availability Topology
Production clusters run multiple control plane nodes for fault tolerance. Two common approaches: stacked etcd (etcd runs on each control plane node) and external etcd (dedicated etcd cluster). External etcd is more resilient but more complex.
| Topology | Pros | Cons |
|---|---|---|
| Stacked etcd | Simpler, fewer nodes | Coupled failure domains |
| External etcd | Independent failure domain | More infrastructure, more certs |
Run kubectl get componentstatuses (or kubectl get cs) to check API server, etcd, and scheduler health. Also check pod status with kubectl get pods -n kube-system to see all control plane components at once.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.