Container Orchestration
From containers to orchestration
Containers package an application and its dependencies, but orchestration supplies scheduling, networking, service discovery, scaling, health management, and reconciliation across many nodes. Kubernetes is the reference orchestrator: you declare a desired state, and controllers recreate failed Pods, reschedule workloads, and roll out changes. Understanding why orchestration exists helps answer scenario questions about self-healing and elasticity.
Workload selection
Choose the controller by behavior. A Deployment suits stateless services needing rolling updates. A StatefulSet provides stable network identities and ordered, persistent storage for databases and clustered systems. A DaemonSet places one Pod on every eligible node for agents such as log shippers. Jobs and CronJobs handle batch and scheduled tasks. Horizontal Pod Autoscaling adjusts replicas from observed metrics; cluster autoscaling adds nodes when Pods cannot be scheduled.
Traps
Do not confuse orchestration with containerization. Do not claim a Deployment guarantees Pod identity or persistent storage ordering. Do not assume HPA works without a metrics source. Remember that readiness gates traffic while liveness restarts containers, and that a Pod is ephemeral even when its data is persistent.
Worked example
A stateless API needs zero-downtime releases and variable traffic. Use a Deployment with readiness probes, a Service for stable access, and an HPA for replica scaling. A database with stable identity instead needs a StatefulSet and PersistentVolumeClaims. Rule of thumb: stateless and replaceable → Deployment; stable identity or ordered storage → StatefulSet; one per node → DaemonSet; finite work → Job.