Container Orchestration
Scheduling and lifecycle
Orchestration is about placing workloads and keeping them healthy. The scheduler filters nodes (resources, taints/tolerations, node selectors, affinity) then scores survivors. Requests drive scheduling; limits drive runtime enforcement. A pod exceeding its memory limit is OOM-killed; exceeding CPU limit is throttled, not killed - a classic trap.
Probes and rollout control
Liveness probes restart containers; readiness probes remove pods from Service endpoints without restarting; startup probes protect slow-booting apps from premature liveness failures. Deployments offer RollingUpdate (default) and Recreate strategies, with maxSurge and maxUnavailable governing disruption. Readiness gates and PodDisruptionBudgets protect availability during voluntary disruptions like drains.
Scaling and self-healing
HorizontalPodAutoscaler scales replica counts from metrics; VerticalPodAutoscaler adjusts requests/limits; cluster autoscaling adds nodes. The ReplicaSet controller recreates deleted pods, but a pod stuck in CrashLoopBackOff is running-but-failing - the controller will not replace it, because the pod still exists.
Traps to watch
- Taints repel pods; tolerations allow but do not force placement. Affinity is the forcing mechanism.
- A failing readiness probe does not restart a container; only liveness (or startup) failures do.
kubectl drainevicts pods but respects PDBs; DaemonSet pods need--ignore-daemonsets.- Resource requests are scheduling guarantees; limits are runtime ceilings.
Rule of thumb
Diagnose in order: is the pod scheduled (Pending → resources/taints), is the image pullable (ImagePullBackOff), is it starting (CrashLoopBackOff → logs), is it ready (readiness probe)?
Worked example: A pod is Pending. Check kubectl describe pod events: "0/3 nodes available: 3 Insufficient cpu." The fix is lowering requests or adding capacity - not a liveness probe tweak.