Kubernetes

Kubernetes is an open-source container orchestration system originally developed by Google and now maintained by the CNCF. It automates deploying, scaling, and managing containerized applications across clusters of machines, replacing the need to manually manage where and how containers run.

Imagine you have a restaurant with many kitchen stations, each capable of preparing dishes. You need to manage which station prepares what, what to do when a station breaks down, how to scale up when there's a rush, and how to update the menu without shutting everything down. Kubernetes is that manager for software. Instead of kitchen stations, it manages containers (packaged, self-contained pieces of software). It decides which server runs which container, restarts them if they crash, adds more when traffic increases, and rolls out updates without downtime. You describe what you want ("run 3 copies of this service, restart if it crashes, expose it to the internet") and Kubernetes makes it happen — and keeps making it happen, continuously.

The problem Containers (popularized by Docker) made it easy to package and run software reliably. But when you have dozens or hundreds of containers across many servers, manually managing them is a nightmare: which container runs on which server? What happens when a server fails? How do you update software without downtime? What Kubernetes does Kubernetes (abbreviated K8s) is a system that manages containers at scale. You tell Kubernetes what you want — "I need 5 replicas of my web service running" — and it figures out where to run them, monitors their health, and maintains that state automatically. Core concepts - Pod: The smallest deployable unit. Usually one container, sometimes a few tightly coupled ones - Deployment: Describes how many pods to run and manages updates - Service: A stable network endpoint for a set of pods (even as pods come and go) - Node: A machine (VM or physical) in the cluster - Cluster: The group of nodes Kubernetes manages - Control Plane: The Kubernetes management layer (API server, scheduler, controllers) What Kubernetes handles automatically - Scheduling: Placing pods on nodes with available resources - Self-healing: Restarting failed containers; replacing nodes that fail - Scaling: Adding/removing pods based on load (Horizontal Pod Autoscaler) - Rolling updates: Updating software with zero downtime - Load balancing: Distributing traffic across healthy pods

Architecture Kubernetes has a control plane + worker node architecture: Control plane components: - kube-apiserver: The central API gateway. All other components communicate through it. Stateless; horizontally scalable - etcd: Distributed key-value store. The source of truth for all cluster state - kube-scheduler: Assigns pods to nodes based on resource requests, affinity rules, and node capacity - kube-controller-manager: Runs controllers (Deployment, ReplicaSet, Node, Endpoints, etc.) that reconcile desired state with actual state - cloud-controller-manager: Cloud-specific controllers (load balancers, storage volumes) Worker node components: - kubelet: Agent on each node; communicates with the API server; manages pod lifecycle - kube-proxy: Manages network rules on nodes for Service routing - Container runtime: Runs containers (containerd, CRI-O) The control loop pattern All Kubernetes controllers use the same pattern: ``` observe current state compare to desired state act to reconcile the difference ``` This is eventually consistent: Kubernetes continuously drives toward the desired state. Key abstractions - Deployment + ReplicaSet: Manages stateless workloads; rolling updates; rollback - StatefulSet: Stateful workloads with stable network IDs and persistent volumes - DaemonSet: Run one pod per node (logging, monitoring agents) - ConfigMap / Secret: Externalize configuration and credentials from container images - PersistentVolume / PVC: Abstract storage provisioning - Ingress: Layer 7 HTTP routing; SSL termination - HorizontalPodAutoscaler: Auto-scale replicas based on CPU/memory or custom metrics Networking model Every pod gets a unique IP. Pods communicate directly (flat network). Services provide stable virtual IPs backed by kube-proxy rules (iptables or eBPF). CNI plugins (Calico, Cilium, Flannel) implement the network.

Operational complexity is the primary trade-off Kubernetes is powerful but operationally heavy. Running a self-managed cluster requires deep expertise in networking, storage, upgrades, and incident response. Managed Kubernetes (GKE, EKS, AKS) reduces but does not eliminate this burden. When Kubernetes is the wrong choice - Single-server deployments: Docker Compose or a simple process manager is sufficient - Simple scheduled tasks: A cron job or serverless function is cheaper to operate - Small teams without Kubernetes expertise: The learning curve is steep and operational mistakes are costly - Latency-critical workloads where cold starts are unacceptable: Serverless (Lambda, Cloud Run) may be preferable Multi-tenancy security Kubernetes was not designed for hard multi-tenancy (untrusted tenants). Network policies, RBAC, and Pod Security Standards provide isolation within a cluster, but for strict tenant isolation, separate clusters are safer. Key security practices: - Use RBAC (never give workloads cluster-admin) - Restrict pod capabilities (no privileged containers, no hostPath mounts) - Use Pod Security Admission (PSA) to enforce baseline/restricted profiles - Scan container images in CI before deployment - Use Network Policies to restrict pod-to-pod traffic Resource management and cost - Always set resource requests and limits on containers; without them, the scheduler cannot make good placement decisions - Use Vertical Pod Autoscaler to right-size request/limit settings based on historical usage - Use node auto-provisioning (Karpenter, GKE Autopilot) to dynamically match node capacity to workload demand Failure modes - etcd degradation: Cluster control plane becomes unavailable; no new scheduling, no updates - Node failure cascade: If autoscaler is too slow, pending pods queue up; use PodDisruptionBudgets to maintain availability during node drains - Version skew: API server, kubelet, and kubectl versions must stay within supported skew; upgrades require planning GitOps and deployment Store all Kubernetes manifests in Git. Apply via Argo CD or Flux for audit trail, rollback, and drift detection. Never apply manifests directly in production without version control.