Design Kubernetes

Problem Statement: Kubernetes Platform Design

Design Kubernetes for microservices means architecting a container orchestration platform that schedules workloads, maintains desired state, exposes services, and enforces policy across many teams. Interviewers expect you to reason about the control plane (API server, etcd, scheduler, controllers) separately from the data plane (kubelet, CNI, CSI, ingress). A strong answer defines who operates the cluster (platform team vs product teams), how releases flow (GitOps vs imperative kubectl), and what "done" looks like: 99.95% API availability, sub-minute rollout for stateless apps, and bounded blast radius when a tenant misbehaves.

Interview Focus

• Tie every decision to schedulability, blast radius, and recovery time
• Quantify API server QPS, etcd write rate, and pod churn before picking tools
• Explain how multi-tenant isolation is enforced at network, RBAC, and quota layers
• Describe rollback and degradation paths before ideal-state autoscaling

How to open this one

The opening that signals depth on Kubernetes is to frame it as a control loop, not a list of objects: the API server is the single source of truth, controllers continuously reconcile observed state toward declared state, and the scheduler and kubelet are two of those reconcilers. Lead with the reconciliation loop and the failure story that proves it — a node dies, the controller notices its pods are missing, and replacements are scheduled elsewhere with no human in the loop — and you have shown you understand why Kubernetes is declarative rather than imperative.