Revision · Orchestration with Kubernetes

This part built Kubernetes up from first principles around one idea: stop telling machines what to do step by step, and declare what you want to be true, letting controllers keep reality matching forever. Every feature turned out to be a variation on that reconciliation loop.

What this part covered

• Why orchestration — at scale, scheduling, healing, scaling, rollouts, and networking are too much to script by hand; a Deployment with replicas: 4 absorbs the whole “keep four healthy forever” problem for you.
• Architecture — a control plane (API server, etcd, scheduler, controller-manager) decides what should be true and worker nodes (kubelet, kube-proxy, runtime) make it real, with etcd as the one source of truth and the API server as the one authenticated door.
• Pods and workloads — the Pod, not the container, is the schedulable unit sharing a network namespace; ReplicaSets keep N alive, Deployments do safe rolling updates, DaemonSets run one per node, and Jobs/CronJobs run to completion.
• The reconciliation loop — controllers observe actual state, compare it to desired, and take the smallest action to close the gap, level-triggered so they survive crashes and dropped events — which is why Kubernetes self-heals rather than merely self-installs.
• Services and networking — a Service gives a stable ClusterIP and DNS name over churning Pod IPs, kube-proxy programs kernel rules to load-balance, and a CNI plugin provides the flat Pod-to-Pod network.
• Ingress and controllers — an Ingress resource is inert YAML declaring host/path routing; an Ingress controller (NGINX, Traefik) reconciles a real L7 proxy to match, handling TLS termination and cert renewal.
• Config and secrets — ConfigMaps and Secrets decouple configuration from the immutable image so one artifact runs everywhere, with the crucial caveat that Secrets are only base64-encoded and need encryption at rest or an external manager.
• Storage and stateful workloads — PersistentVolumes and claims decouple disks from Pod lifecycle, StorageClasses provision dynamically via CSI, and StatefulSets give stable names and per-Pod storage — though the honest default is stateless in the cluster, stateful outside it.
• Scaling and scheduling — requests and limits are the contract that lets the scheduler place Pods, taints/tolerations/affinity steer placement, and the HPA scales replicas against a metric — but only when requests are set honestly.
• Helm and packaging — charts template manifests filled from a values file so one release is a reviewable, repeatable command, with helm rollback making a bad deploy one atomic step back.

The takeaway

The manual step Kubernetes removes is the 3am toil of SSHing in to restart, reschedule, and reroute by hand; the safety dividend is routine recovery done the same correct way every time by software that never tires. The reconciliation loop you learned here is not a Kubernetes quirk — it reappears in IaC, in autoscaling, and most directly in GitOps, where Git becomes the desired state a controller drives the cluster toward.