CKA — Control Plane Components

3 minute read

Control Plane Overview

The control plane makes global decisions about the cluster — scheduling Pods, detecting failures, and responding to events. All control plane components typically run on dedicated nodes (called master or control plane nodes).

┌─────────────────────────────────────────────────────┐
│                  CONTROL PLANE                       │
│                                                     │
│  ┌─────────────┐  ┌──────────────┐  ┌───────────┐  │
│  │  API Server  │  │  Controller  │  │ Scheduler │  │
│  │  (kube-      │  │  Manager     │  │           │  │
│  │   apiserver) │  │              │  │           │  │
│  └──────┬───────┘  └──────┬───────┘  └─────┬─────┘  │
│         │                 │                │        │
│         └────────┬────────┘────────────────┘        │
│                  │                                  │
│           ┌──────┴───────┐                          │
│           │     etcd     │                          │
│           │  (key-value  │                          │
│           │    store)    │                          │
│           └──────────────┘                          │
└─────────────────────────────────────────────────────┘

kube-apiserver

The API server is the front door to the cluster. Every interaction — whether from kubectl, the dashboard, or internal components — goes through the API server.

Aspect Detail
Port 6443 (HTTPS)
Manifest /etc/kubernetes/manifests/kube-apiserver.yaml
Purpose REST API endpoint for all cluster operations
Authentication Client certificates, bearer tokens, OIDC
Who talks to it kubectl, kubelet, scheduler, controller manager, etcd

Key API Server Flags

# Common kube-apiserver flags (from the static Pod manifest)
--advertise-address=192.168.1.10
--etcd-servers=https://127.0.0.1:2379
--service-cluster-ip-range=10.96.0.0/12
--service-account-key-file=/etc/kubernetes/pki/sa.pub
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key
--authorization-mode=Node,RBAC

Inspecting the API Server

# View the API server Pod
kubectl get pods -n kube-system -l component=kube-apiserver

# View its manifest
sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml

# Check API server logs
kubectl logs -n kube-system kube-apiserver-<node-name>

# Verify API server health
kubectl get --raw /healthz

etcd

etcd is the brain of the cluster — a distributed key-value store that holds all cluster state: Pods, Services, ConfigMaps, Secrets, RBAC rules, and everything else.

Aspect Detail
Port 2379 (client), 2380 (peer)
Manifest /etc/kubernetes/manifests/etcd.yaml
Data directory /var/lib/etcd
Purpose Persistent storage for all cluster data
Backup tool etcdctl snapshot save 
# Check etcd health
kubectl get pods -n kube-system -l component=etcd

# View etcd manifest
sudo cat /etc/kubernetes/manifests/etcd.yaml

# Check etcd member list (requires certificates)
ETCDCTL_API=3 etcdctl member list \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

CKA exam alert: etcd backup and restore is a dedicated exam topic. You must know how to take snapshots and restore them. See etcd Backup & Restore.

kube-scheduler

The scheduler watches for newly created Pods that have no node assigned and selects the best node for them to run on.

Aspect Detail
Manifest /etc/kubernetes/manifests/kube-scheduler.yaml
Scheduling factors Resource requirements, affinity/anti-affinity, taints/tolerations, data locality
Algorithm Filter → Score → Bind

How the Scheduler Decides

  1. Filtering — Eliminates nodes that cannot run the Pod (insufficient resources, taints, nodeSelector mismatch)
  2. Scoring — Ranks remaining nodes based on priorities (resource balance, affinity, spread)
  3. Binding — Assigns the Pod to the highest-scoring node
# Check scheduler health
kubectl get pods -n kube-system -l component=kube-scheduler

# View scheduler logs
kubectl logs -n kube-system kube-scheduler-<node-name>

kube-controller-manager

The controller manager runs controller loops that watch the cluster state and make changes to move the current state toward the desired state.

Controller Purpose
Node Controller Monitors node health, marks nodes NotReady
Replication Controller Ensures correct number of Pod replicas
Endpoints Controller Populates endpoint objects for Services
ServiceAccount Controller Creates default ServiceAccounts in new namespaces
Deployment Controller Manages ReplicaSets for Deployments
Job Controller Creates Pods for Job objects 
# Check controller manager
kubectl get pods -n kube-system -l component=kube-controller-manager

# View its manifest
sudo cat /etc/kubernetes/manifests/kube-controller-manager.yaml

Control Plane Component Summary

Component Port Manifest Location Key Role
kube-apiserver 6443 /etc/kubernetes/manifests/kube-apiserver.yaml REST API gateway
etcd 2379/2380 /etc/kubernetes/manifests/etcd.yaml Cluster state store
kube-scheduler 10259 /etc/kubernetes/manifests/kube-scheduler.yaml Pod placement
kube-controller-manager 10257 /etc/kubernetes/manifests/kube-controller-manager.yaml State reconciliation

Exam tip: All control plane components run as static Pods managed by the kubelet. Their manifests live in /etc/kubernetes/manifests/. If you need to troubleshoot or reconfigure a control plane component, edit its manifest file directly.

Next: Worker Node Components →

Updated:

You may also enjoy