Problem Statement: Kubernetes as the Control Plane for Microservices
Frames Kubernetes not as a deployment tool but as a distributed reconciliation system that continuously drives cluster state toward declared intent.
Problem statement
Design a container orchestration platform that runs hundreds to thousands of microservices: it schedules pods onto nodes, exposes them through stable DNS and load-balanced Services, routes external traffic through Ingress or Gateway API, performs zero-downtime rolling updates, heals failed replicas, and scales workloads horizontally from metrics. The platform is multi-team, so isolation, quotas, RBAC, and network policy are first-class requirements, not afterthoughts.
The defining insight for a strong interview answer is that Kubernetes is a set of control loops, not a command runner. A Deployment declares intent (for example three replicas of image v2); controllers observe actual state through the API server and etcd, compute the diff, and actuate changes (create ReplicaSets, scale pods, update endpoints) until observed state converges to declared state. Every design decision—scheduling, service discovery, rollout, autoscaling, tenancy—should be explained as a control loop with an owner, a feedback signal, and a failure behavior.
Why this problem is distinctive
A naive answer draws boxes: nodes, pods, load balancer. A staff-level answer separates four planes. The control plane (API server, etcd, scheduler, controller manager, cloud controller manager) owns cluster truth and decisions. The node plane (kubelet, container runtime, CNI agent, kube-proxy or eBPF datapath) owns execution on each machine. The exposure plane (Services, EndpointSlices, Ingress controllers, Gateway API, optional service mesh) owns how traffic reaches workloads. The platform plane (GitOps controllers, admission webhooks, policy engines, secrets operators, observability) owns how hundreds of developers safely share one fleet of clusters.
Public operating baseline versus design assumptions
Kubernetes descends directly from Google's Borg; the Borg paper describes clusters of tens of thousands of machines scheduling billions of container-weeks of work, and Omega documented optimistic concurrency scheduling at that scale. OpenAI published a post-mortem of scaling a single Kubernetes cluster to 7,500 nodes, detailing etcd and API-server pressure from heavy pod churn. Niantic ran Pokémon GO on GKE and absorbed launch traffic far above forecast by leaning on managed cluster autoscaling. These are cited public signals; every capacity number in this answer that is not cited is an explicit design assumption for a fictional platform team running one business-critical fleet.
Key Highlights
- •Kubernetes is a reconciliation engine: declared intent in etcd, controllers converge actual state toward it.
- •Four planes: control plane, node plane, exposure plane, platform plane—each with distinct failure modes.
- •Lineage is real: Borg and Omega at Google inform the scheduler and etcd-backed API design.
- •OpenAI publicly documented single-cluster scaling pain at 7,500 nodes; upstream caps nodes at 5,000.
- •Multi-tenancy makes RBAC, quotas, and network policy architecture requirements, not configuration.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate the control plane, node plane, exposure plane, and platform plane before choosing any component."
- "I will explain each capability as a control loop: who owns it, what signal it reads, and how it fails."