Kubernetes: Scheduling, Health and Autoscaling
Kubernetes orchestrates containers through declarative desired state, controllers and a cluster scheduler.
Kubernetes: Scheduling, Health and Autoscaling
Kubernetes orchestrates containers through declarative desired state, controllers and a cluster scheduler. Pods are the smallest scheduling unit; Deployments manage replicas and rollout; Services provide stable discovery; Ingress or Gateway API exposes HTTP routes. Readiness removes an instance from traffic, liveness can restart it, and startup probes protect slow initialization. Requests/limits influence scheduling and resource enforcement. HPA scales from metrics but cannot create downstream capacity.
Mechanism and worked example
A deployment requests three API replicas. Readiness succeeds only after configuration, dependencies and warm-up are complete. A rolling update keeps a minimum available replica count and uses a disruption budget, while HPA adds replicas only when the database and connection pool can sustain them.
| Primitive | Purpose | Failure boundary |
|---|---|---|
| Pod | Scheduled workload unit | Ephemeral; local state may disappear |
| Deployment | Replica and rollout control | Readiness and rollout policy must be correct |
| Service | Stable endpoint discovery | Not a guarantee of application health |
| HPA | Adjust replica count | Cannot create downstream capacity |
| PDB | Limit voluntary disruption | Not a guarantee against all failures |
Failure modes and operations
Bad liveness probes can restart healthy but slow services. Missing readiness lets traffic hit unready pods. CPU-only autoscaling misses queue age or dependency saturation. A rollout can deadlock when maxUnavailable and maxSurge conflict with cluster capacity. Pod disruption budgets do not guarantee protection from every node or zone failure.
Trade-offs and design boundary
Kubernetes standardizes deployment and reconciliation but adds control-plane, networking, storage, resource and security complexity. It does not automatically provide application-level durability, exactly-once processing or safe database migrations.
Interview transfer exercise
An API deployment scales from 4 to 40 pods while PostgreSQL has a fixed connection budget. Explain how to prevent the rollout from overwhelming the database: cap per-pod pools, use a proxy, bound concurrency and scale on queue/dependency signals.
Read the diagram
Desired state declares replicas → Scheduler places pods using resources and constraints → Readiness controls traffic eligibility → Controllers reconcile drift and rollout state