KLCP: Kubernetes Fundamentals

The control plane and the node

Every cluster splits into a control plane (API server, etcd, scheduler, controller manager) and worker nodes running the kubelet, container runtime, and kube-proxy. The API server is the single front door: every component reads and writes cluster state through it, and etcd is the only persistent store. A useful mental model is declarative reconciliation - you POST a desired state, controllers loop until actual state matches it.

Core objects

Know the workload primitives cold: Pod (smallest schedulable unit, one or more containers sharing a network namespace and volumes), ReplicaSet (maintains a pod count), Deployment (manages ReplicaSets for rolling updates and rollback), StatefulSet (stable identity and ordered rollout), DaemonSet (one pod per node), Job and CronJob (run-to-completion). Services give stable virtual IPs and load balancing; ConfigMaps and Secrets inject configuration; Namespaces partition names.

Traps to watch

• A bare Pod is not rescheduled by a controller if its node dies; only controller-managed pods are replaced.
• Labels select; annotations do not. Selectors must match exactly for a Service to route traffic.
• kubectl apply is declarative and idempotent; create fails if the object exists; replace overwrites.
• Namespace scoping: most objects are namespaced, but Nodes, PersistentVolumes, and StorageClasses are cluster-scoped.

Rule of thumb

If a question asks "what guarantees N replicas," the answer is a controller (ReplicaSet/Deployment), never a Pod spec. If it asks "what survives a node loss," think about where state lives - etcd for desired state, PersistentVolumes for data.

Worked example: You scale a Deployment from 3 to 5. The Deployment updates its ReplicaSet's replica count; the ReplicaSet controller creates two Pods; the scheduler binds them to nodes; kubelets pull images and start containers. You never touch Pods directly.