Orchestration: scheduling, self-healing and desired state

Why this matters

Containers on their own are a packaging format. Orchestration is what makes them an operating model: something that places workloads on machines, restarts what fails, replaces what is unhealthy, and rolls out changes without an outage.

CompTIA's verb here is managing containers using orchestration techniques, which sets a clear boundary. You need the vocabulary and the behaviour — desired state, scheduling, probes, rolling updates — and you need to reason about what happens when they interact. You do not need to operate a cluster at a certified-administrator level, and this lesson deliberately stops where the objective stops.

The lesson

Desired state as the idea the whole orchestrator is built around

Everything else in this lesson is a consequence of one idea.

You do not tell an orchestrator what to do. You tell it what you want: five replicas of this image, with this configuration, reachable on this port. A control loop then continuously compares the actual state of the cluster to that declaration and takes whatever action closes the gap.

This is declarative, in exactly the sense objective 2.2 uses for infrastructure as code, and it explains behaviour that is otherwise surprising:

• Delete a running workload by hand and it comes back, because the declaration still says five replicas.
• Kill a machine and its workloads are recreated elsewhere, without anyone being paged.
• To actually remove something you must change the declaration, not the running state.
• The system converges continuously; there is no deployment event after which it stops checking.

The declaration lives in the cluster's own datastore, and that datastore is the cluster's most important thing to back up. Objective 3.2's rules apply to it like anything else.

Pods, services and deployments, and the scheduler's job in placing them

The vocabulary, in the terms the dominant orchestrator uses and the exam expects:

• Pod. The smallest schedulable unit: one or more containers that share a network namespace and storage, always placed together. Most pods are a single container; the multi-container case is a helper alongside the main process. Pods are disposable — they are not repaired, they are replaced, and they get a new address each time.
• ReplicaSet. Maintains a stated number of identical pods.
• Deployment. Manages ReplicaSets to provide versioned, controlled rollouts and rollbacks. This is the object you normally declare.
• Service. A stable name and virtual address in front of a changing set of pods, with load balancing across them. Because pod addresses change constantly, nothing should ever address a pod directly — this is the point of a service and a common exam question.
• Ingress / gateway. Routes external HTTP traffic to services, terminating TLS and routing by host or path.
• ConfigMap and Secret. Configuration and sensitive values injected at run time rather than baked into the image, which is the practical answer to the immutable-layer problem from the previous lesson.

The scheduler decides which node runs each new pod. It filters nodes that cannot run it and scores the rest:

• Resource requests — a node must have enough unreserved CPU and memory. This is the main filter, and it uses requests, not actual usage.
• Node selectors, affinity and anti-affinity — steer workloads toward labelled nodes, or spread replicas across zones so one zone's failure does not take the service down.
• Taints and tolerations — the inverse: a node repels workloads unless they explicitly tolerate the taint. Used to reserve nodes for particular purposes.

The single most common scheduling failure is a pod stuck pending because no node has enough unreserved capacity for its requests — which can happen while the cluster looks lightly loaded, because requests are reservations rather than measurements. That gap between requested and used is also the main source of waste, and objective 1.7 treats it as an optimisation problem.

Health probes, restarts and rescheduling, and the failure they are meant to survive

Self-healing needs a definition of "healthy", and that is what probes provide. Three kinds, with distinct jobs:

• Liveness. Is this still working? Failing it restarts the container. It exists for processes that are running but wedged.
• Readiness. Can it take traffic right now? Failing it removes the pod from the service's endpoints without restarting it. It exists for warm-up and for temporary dependency failures.
• Startup. Has it finished starting? It suppresses the other two until it passes, so slow-starting applications are not killed during boot.

Getting these wrong causes outages of a particular, recognisable shape:

• Liveness probe too aggressive — a slow-starting app is killed repeatedly and never becomes ready. The symptom is a restart loop with no application error, and the fix is a startup probe or a longer initial delay.
• Liveness probe checking a dependency — the database goes down, every replica fails liveness, and the platform restarts the entire fleet, turning a dependency outage into a total one. Liveness should test the process, not its dependencies. Readiness is where a dependency check belongs.
• No readiness probe — traffic is sent to pods that are still starting, so every deployment produces a burst of errors.

At the node level, the platform notices an unresponsive node and reschedules its workloads elsewhere. That is the failure orchestration is really for: a machine dies and the service does not.

Rolling updates, rollbacks and the update that takes the service down anyway

A rolling update replaces pods gradually, governed by two settings: how many extra pods may exist during the rollout (max surge) and how many may be unavailable (max unavailable). The deployment tracks versions, so a rollback returns to the previous one.

The related strategies, which the exam groups with this:

• Recreate — stop all old, start all new. Simple, with downtime.
• Blue-green — run the new version alongside, switch traffic at once, switch back if wrong. Fast rollback, double the resources during the change.
• Canary — send a small share of traffic to the new version, watch, widen. Best early warning, needs traffic-splitting and good observability.

The updates that fail despite being rolling, which is what scenarios describe:

• maxUnavailable set too high on a small deployment, so most of the fleet is replaced at once and capacity drops below demand.
• No readiness probe, so the rollout counts a starting pod as ready, proceeds, and replaces the healthy ones while nothing is serving.
• An incompatible schema or API change. Two versions run simultaneously during any rolling update, so the change must be compatible in both directions. This is the failure a rollback does not fix — the data has already been migrated. Expand-then-contract migrations exist for this reason.
• Insufficient cluster capacity for the surge, so new pods sit pending while old ones have already been removed.

Where Cloud+ stops: managing containers with orchestration, not operating a cluster

It is worth being explicit about depth, because it is easy to over-prepare here and under-prepare on domains worth more marks.

In scope: what an orchestrator does and why; the objects above and what each is for; scheduling, probes, rolling updates and self-healing; why containers are packaged, deployed and scaled the way they are; and the failure modes in this lesson.

Not in scope for CV0-004: writing custom controllers or operators, the internals of the control plane's components, service-mesh configuration, cluster networking plugins, or certification-level cluster administration.

If you want that depth it is a different qualification. What this exam asks is whether you can manage containers with orchestration and reason about what the platform will do — and remember that this entire objective is one bullet inside a domain worth 23%, most of which is not about containers at all.

What to take into the exam

• Orchestration is declarative desired state maintained by a control loop. Deleting a running thing does not remove it; changing the declaration does.
• Pods are disposable and their addresses change. Always address a service, never a pod.
• Scheduling filters on requests, not usage — pods pend on a cluster that looks idle.
• Liveness restarts; readiness removes from load balancing; startup protects slow starts. A liveness probe that tests a dependency turns a dependency outage into a full one.
• Rolling updates run two versions at once, so changes must be backward-compatible — and a rollback does not undo a data migration.
• Blue-green = instant switch, double resources. Canary = gradual, best early warning.