FIT5225 · Cloud Computing And Security
Container Orchestration
One container is easy; hundreds across many machines is the problem orchestration solves. Container Orchestration automates scheduling, scaling, self-healing and networking for containers across a cluster. FIT5225 contrasts the two orchestrators: Docker Swarm (simpler, Docker-native, uses Raft consensus to elect one leader and agree one truth) and Kubernetes (the industry standard, far more powerful and more complex). The central Kubernetes diagram splits a cluster into a control plane (the brain: API server, scheduler, controller-manager, etcd) and worker nodes (where containers actually run), and its core objects climb a ladder: Pod → ReplicaSet → Deployment → Service. The load-bearing idea is declarative desired state: you declare what you want and a reconciliation loop continuously makes reality match. The quizzes test which orchestrator to pick, which component does what, and reading a cluster diagram.
What this chapter covers
- 01Why orchestration — from one container to a cluster
- 02Docker Swarm & Raft consensus — one leader, one agreed truth
- 03Kubernetes architecture — control plane vs worker nodes
- 04Kubernetes objects: Pod → ReplicaSet → Deployment → Service
- 05Declarative desired state & the reconciliation loop
- 06Scaling: replicas, self-healing and rolling updates
Worked example: read a Kubernetes failure and name the fix
replicas: 3. One worker node crashes, killing the Pod that ran on it, so only two Pods are live. (a) What does Kubernetes do automatically, and which control-plane idea drives it? (b) Which object guarantees the replica count — the Pod, the ReplicaSet or the Service? (c) Users never noticed any outage — which object kept a stable address in front of the changing Pods?- +2(a) Self-healing: the control plane sees actual state (2 Pods) diverge from declared desired state (3) and the reconciliation loop schedules a replacement Pod on a healthy node — this is declarative desired state at work.
- +1(b) The ReplicaSet owns the replica count: it keeps exactly the declared number of Pod copies running, creating or deleting Pods to match. (A Deployment manages ReplicaSets to enable rolling updates.)
- +1(c) The Service kept a stable virtual IP / DNS name and load-balanced across whichever Pods are healthy, so clients never addressed the dead Pod directly.
- +1Conclude: you declared the end state once; Kubernetes — not you — restored it. That is the difference between declarative orchestration and manual operations.
Key terms
- Container orchestration
- Automated management of containers across a cluster of machines — scheduling them onto nodes, scaling replicas up and down, restarting failed ones (self-healing) and wiring up networking. Docker Swarm and Kubernetes are the two orchestrators FIT5225 contrasts.
- Control plane vs worker node
- In Kubernetes the control plane is the brain (API server, scheduler, controller-manager and the etcd datastore) that decides what should run where; worker nodes are the machines that actually run the containers (via a kubelet and a container runtime). Quizzes ask which component does which job.
- Pod / ReplicaSet / Deployment / Service
- The core Kubernetes object ladder. A Pod is the smallest unit (one or more co-located containers); a ReplicaSet keeps a desired number of Pod copies running; a Deployment manages ReplicaSets to enable rolling updates and rollbacks; a Service gives a stable network address and load-balances across the changing set of Pods.
- Declarative desired state
- You describe the end state you want (e.g. three replicas of this image) rather than the steps to get there, and a control loop continuously reconciles actual state to match. This is what makes Kubernetes self-healing and idempotent — re-applying the same declaration is safe and converges to the same result.
- Raft consensus
- The algorithm Docker Swarm (and etcd, under Kubernetes) uses so a set of manager nodes elect a single leader and agree on one consistent copy of cluster state. A majority quorum must agree, which is why an odd number of managers is recommended for high availability.
Container Orchestration FAQ
Swarm or Kubernetes — how do I answer 'which orchestrator'?
Match power to need. Docker Swarm is simpler, Docker-native and quick to stand up — good for small or simple deployments. Kubernetes is the more powerful, more complex industry standard with a rich object model, large ecosystem and fine-grained control — the default for serious, scalable, multi-team workloads. The quiz wants the trade-off (simplicity vs power), not a one-size answer.
What's the difference between a Pod, a Deployment and a Service?
They sit at different jobs. A Pod runs your container(s). A Deployment declares how many replicas you want and manages rolling updates and rollbacks (via ReplicaSets). A Service gives those Pods one stable address and load-balances across them, because individual Pods are ephemeral and their IPs change. A common trap is expecting a Pod to be durable — it is not; the higher objects provide durability.
What does 'declarative desired state' actually mean in practice?
You hand Kubernetes a description of the end state (this image, three replicas, this port) and a reconciliation loop keeps reality matching it — if a Pod dies it is replaced, if you change the replica count the cluster adjusts. You manage the what, not the how. It is why the same manifest can be re-applied safely (idempotent) and why the cluster self-heals.
Why does Raft need a majority / odd number of managers?
Raft elects one leader and commits changes only when a majority (quorum) of managers agree, which prevents split-brain (two leaders) during network partitions. With an even number you can lose quorum on a tie; an odd number (3, 5) maximises the failures you can tolerate while still reaching a majority, so it is the recommended high-availability setup.
Exam move
Lead with the one-line mental model: orchestration manages many containers across a cluster so you declare the desired state and the system maintains it. Memorise the Kubernetes split — control plane (API server, scheduler, controller-manager, etcd) vs worker nodes — and be able to say which component does which job, the single most common diagram-reading quiz. Climb the object ladder Pod → ReplicaSet → Deployment → Service and know what each adds. For the 'which orchestrator' question, give the Swarm-vs-Kubernetes trade-off (simplicity vs power), and for Raft, be ready to explain leader election, quorum and why an odd manager count is recommended. Practise reading a small cluster diagram and spotting what is mismanaged.
