How it works
The control plane manages cluster state. Clients submit resource objects to the API server, which handles authentication, authorization, admission, and persistence in etcd. etcd is a replicated key-value store that uses Raft consensus; it stores cluster configuration and state, not your application's business data.
Controllers watch API objects and reconcile desired state with observed state. A Deployment controller manages ReplicaSets, and a ReplicaSet controller creates or removes Pods to maintain a replica count. Reconciliation is asynchronous, so an accepted API update does not mean the requested workload is already running.
The scheduler assigns unscheduled Pods to nodes based on resource requests, placement constraints, and other policies. Each node runs a kubelet, which coordinates with a container runtime to start containers and report status. A Pod is the scheduling unit: its containers share a network namespace and can share volumes.
The data plane connects workloads. A CNI networking implementation provides Pod networking, while Services expose a stable virtual address and select backend Pods through EndpointSlices. kube-proxy or an alternative networking implementation programs forwarding rules; traffic normally does not pass through the API server. Ingress or Gateway API resources require a controller to implement external routing.
Storage integrations use PersistentVolumes, PersistentVolumeClaims, and commonly CSI drivers to attach or mount storage. StatefulSets provide stable Pod identities and storage associations, but do not implement database replication, leader election, or fencing. Those behaviors belong to the application or a specialized operator.
What it gives you in a design
- Declarative reconciliation
- Declare the desired workload configuration and let controllers repeatedly work toward it. Custom resources and operators extend this model, but their reconciliation must handle retries, partial completion, and stale observations.
- Resource-aware scheduling
- CPU and memory requests guide placement, while limits constrain runtime resource use. CPU limits can cause throttling, and exceeding a memory limit can trigger an out-of-memory kill.
- Service discovery and routing
- Services and cluster DNS give clients stable names despite Pod replacement. Readiness controls whether a Pod is eligible for normal Service traffic, but does not by itself guarantee that existing connections are drained.
- Controlled rollouts
- Deployments support rolling updates with configurable surge capacity and unavailability. Safe releases still require readiness checks, graceful shutdown, and compatibility between old and new application versions.
- Autoscaling
- The Horizontal Pod Autoscaler adjusts replica counts using resource or custom metrics. Node autoscaling is a separate mechanism, and both react with delays rather than providing instant burst capacity.
- Workload recovery and isolation
- Controllers replace failed Pods, while namespaces, RBAC, quotas, and NetworkPolicies support administrative and resource boundaries. Strong isolation requires deliberate configuration, and NetworkPolicy enforcement depends on the networking implementation.
Scaling, replication and failure
Scale stateless services by adding Pod replicas behind a Service. Kubernetes does not automatically shard application data or distribute hot keys, and adding replicas can overload a shared database. Size resource requests realistically and choose autoscaling signals that reflect demand, such as queue backlog or concurrent requests.
For control-plane availability, run redundant API servers and controllers with an appropriately deployed etcd cluster. etcd needs a voting majority to commit writes. During a control-plane outage, existing workloads and already-programmed networking can often continue, but scheduling, reconciliation, and endpoint updates are impaired.
Spread replicas across nodes and availability zones using topology constraints or anti-affinity. Recovery after node failure is not instantaneous: detection, eviction, scheduling, image pulls, and volume attachment all take time. Persistent storage topology can prevent a replacement Pod from starting in another zone.
Separate application replication from Kubernetes replica counts. Multiple database Pods are not automatically a consistent database cluster, and a replacement Pod does not prove the old process has stopped during a partition. Use application-aware failover and fencing where concurrent writers would corrupt data.
Limits and defaults worth knowing
Check the current documentation before relying on an exact value; many of these are configurable.
| Pod termination grace period | terminationGracePeriodSeconds defaults to 30 seconds and is configurable. Shutdown hooks consume this grace period; applications must stop accepting work and finish or safely abandon in-flight operations. |
|---|---|
| Deployment rolling-update defaults | For a RollingUpdate Deployment, maxSurge and maxUnavailable each default to 25%. Percentage surge rounds up, while percentage unavailability rounds down. |
| Horizontal Pod Autoscaler control interval | The HPA controller's sync period defaults to 15 seconds and is configurable. Metric collection, stabilization policies, and Pod startup add further scaling delay. |
| Secret size | An individual Secret is limited to 1 MiB. Secrets are intended for small sensitive configuration values, not large files or general object storage. |
| Pods per node | The kubelet maxPods setting defaults to 110 and is configurable. Managed-service settings, available Pod IP addresses, and node resources can impose different practical limits. |
Use it when
- You need to run many containerized services with independent deployments, health checks, and resource allocation.
- Stateless API replicas or background worker pools need scheduling, recovery, and metric-driven scaling.
- The design needs explicit placement across nodes or zones and controlled disruption during maintenance.
- A platform or control-plane problem benefits from declarative resources and continuous reconciliation.
Avoid it when
- A small application can meet its requirements with a managed container service, serverless functions, or a few virtual machines at lower operational cost.
- You are choosing it to solve database consistency, durable job dispatch, or exactly-once execution without additional application mechanisms.
- The design assumes new capacity appears instantly during a flash crowd instead of planning headroom, admission control, and load shedding.
- You need hostile-tenant isolation but plan to rely on namespaces alone rather than stronger security boundaries.
What interviewers ask about it
Follow-ups you can expect once Kubernetes is on your whiteboard, and the core of a strong answer.
- What happens when a worker node fails?
- The control plane detects missing node heartbeats, and workload controllers can eventually create replacement Pods after the applicable eviction behavior. Recovery depends on spare capacity, placement constraints, startup time, and storage availability. A network partition also requires care because the old process may still be running.
- What is the difference between readiness, liveness, and startup probes?
- Readiness determines whether a Pod should receive normal Service traffic, while repeated liveness failures cause a container restart. A startup probe delays readiness and liveness probing until startup succeeds. Do not make liveness depend on a shared downstream service, or its outage can trigger a restart storm.
- Does Kubernetes keep the application available if the control plane is down?
- Existing containers and already-programmed Service forwarding can often continue operating. However, new scheduling, controller-driven replacements, and routing updates depend on control-plane components. Redundant application replicas and a highly available control plane address different failure modes.
- How would you scale queue consumers?
- Use queue depth, oldest-message age, or another workload signal rather than assuming CPU utilization represents demand. Bound concurrency to protect downstream systems, and account for node provisioning and worker startup time. Consumers still need safe acknowledgement and idempotency because shutdowns and retries can duplicate work.
- Does a StatefulSet make a database highly available?
- No: it provides stable identities, ordered lifecycle behavior by default, and persistent storage associations. The database or its operator must manage replication, leader selection, safe promotion, backups, and fencing. Storage availability and zone placement remain separate concerns.
- How do you deploy without dropping requests?
- Combine sufficient replica capacity, readiness checks, rolling-update settings, and graceful connection draining. Routing changes are not instantaneous, so account for propagation and in-flight requests during termination. Database and API changes must also remain compatible while old and new versions coexist.
Common mistakes
- Saying 'Kubernetes handles scaling' without defining the scaling metric, resource requests, downstream limits, and time needed to add capacity.
- Treating Pod replacement as instant failover or proof that the previous process is no longer executing.
- Assuming a Service balances every request evenly; forwarding commonly selects backends per connection, so long-lived connections can produce uneven load.
- Treating PodDisruptionBudgets as protection against all outages; they constrain supported voluntary evictions, not node crashes or every workload update.
Alternatives
- Managed container platforms
- Win when you need container deployment and autoscaling without managing a general-purpose cluster platform, and can accept the provider's networking and scheduling model.
- Serverless functions
- Win for event-driven, bounded executions with variable demand when runtime limits, cold starts, and the provider's execution model are acceptable.
- Virtual machines with autoscaling groups
- Win for a small number of services, legacy workloads, or specialized host requirements where container orchestration adds little value.
Where it comes up
Interview questions where Kubernetes is a natural fit, and why.
- Design a control plane for a distributed databaseKubernetes controllers and operators illustrate durable reconciliation, while database promotion and fencing require application-aware safety checks.
- Design a notification systemIndependent worker deployments can scale and isolate delivery channels, while durable queues and idempotency preserve work across Pod restarts.
- Design a video streaming service like YouTubeTranscoding workers benefit from resource-aware scheduling and autoscaling, but pipeline dependencies and durable task state need separate orchestration.
- Design a distributed job schedulerKubernetes can execute worker Pods, but durable occurrence tracking, dispatch, leases, and duplicate-side-effect protection remain scheduler responsibilities.
Questions people ask
What are the main components of Kubernetes architecture?
The control plane includes the API server, etcd, scheduler, and controller manager, with cloud integration where applicable. Worker nodes run kubelet, a container runtime, and networking components. DNS, ingress controllers, storage drivers, and monitoring are commonly deployed as additional cluster components.
What is the difference between a Pod, a Deployment, and a Service?
A Pod is a group of containers scheduled together on one node. A Deployment manages replicated Pods through ReplicaSets and coordinates updates. A Service provides a stable network endpoint for a changing set of backend Pods.
What is the difference between Kubernetes and Docker?
Docker provides tools for building and running containers. Kubernetes orchestrates containerized workloads across machines using a compatible container runtime, commonly containerd or CRI-O. Images built with Docker can run on Kubernetes without requiring Docker Engine on each node.