05.04 · Concept
Orchestration
Say what a scheduler does for you and what operational complexity Kubernetes charges in return.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Orchestration moves container operation from per-machine babysitting to a control plane that places workloads, replaces failed instances, rolls out changes, and gives services stable names. The trade-off is a larger operational system: Kubernetes brings schedulers, controllers, storage, networking rules, resource declarations, upgrades, and failure modes you must understand.
What this lesson answers
- what does a container scheduler do
- when is Kubernetes worth the operational cost
- why does docker run differ from Kubernetes deployment
Notes
Orchestration — Orchestration exists to let a scheduler place, restart, scale, and connect containers across many machines automatically; without it, node failures, port conflicts, uneven load, and manual rollouts break services quickly.
Key Concepts: - A scheduler chooses where work runs by matching requested resources such as and against node capacity. - Kubernetes represents desired state declaratively, for example in a Deployment means the control plane continually tries to keep 3 Pods running.
References
Common questions
- What does a scheduler do in Kubernetes?
- A scheduler decides which machine should run each Pod. It compares the Pod’s requested CPU, memory, and constraints with available node capacity, then assigns the Pod to a suitable node. After that, other Kubernetes components keep reconciling the declared target state, such as keeping the intended replica count running.
- What operational complexity does Kubernetes add?
- Kubernetes adds a control plane, persistent cluster state, controllers, networking objects, access control, secrets, resource policy, and upgrade work. A simple web service often becomes several Kubernetes resources rather than one container command. You also inherit new failure modes, especially around cluster state, scheduling assumptions, and service exposure.
- Does Kubernetes automatically make a service highly available?
- No. Replicas help, but availability still depends on placement, resource requests, health checks, rollout settings, network exposure, and failure domains. Kubernetes can replace failed Pods and spread work when configured correctly, but it will not infer every resilience requirement from a container image alone.
Short definition: what is Orchestration?