Kubernetes Container Orchestration Architecture

All Kubernetes state lives in etcd — a distributed key-value store with Raft consensus. The API server is the only component that reads/writes etcd directly; all other components talk to the API server. This architecture means etcd becomes the single source of truth, and any component can be restarted without losing state. etcd is typically run with 3 or 5 nodes for quorum.

Every Kubernetes controller runs a reconciliation loop: watch for resource changes, compare desired state to actual state, take action to converge. The Deployment controller watches Deployments and manages ReplicaSets. The ReplicaSet controller watches ReplicaSets and manages Pods. This composable design means adding a new resource type (CRD) just requires writing a new controller.

The Kubernetes scheduler is a two-phase process: filtering (which nodes can run this pod given CPU/memory/taints/affinities?) and scoring (which filtered node is the best fit?). Default scoring prefers spreading pods across nodes for HA and packing to maximize utilization. Custom schedulers can be plugged in for specialized workloads like GPU-intensive ML training jobs.

Kubernetes Services provide stable virtual IPs (ClusterIP) for groups of pods. kube-proxy programs iptables or IPVS rules to DNAT traffic from the VIP to one of the backing pod IPs. A service with 10 pods gets 10 iptables rules with random selection — simple but effective. For production, a service mesh like Istio replaces this with a sidecar proxy per pod for mTLS, circuit breaking, and traffic shaping.

CRDs let you define new resource types (e.g., PostgresCluster, KafkaTopic) with custom schemas. A controller watches for these resources and takes domain-specific action. This operator pattern is how databases (Strimzi Kafka, CloudNativePG) are managed on Kubernetes — users interact with high-level abstractions while the operator handles upgrade sequencing, backup scheduling, and failover.