Page plan · 13 pages

Written for: Developers and operations staff new to cluster computing

1. 1

   Inside a container cluster

   • A container cluster joins many machines so they run containers as one system.
   • This walkthrough goes from the control side to scheduling, workers and self-healing.
   • It is written for developers and operations staff new to clusters.
   • Each page adds one layer to an isometric picture of the whole cluster.
2. 2

   Two planes: control and work

   • The control plane decides what should run and where it should run.
   • The worker plane is the set of machines that actually run the containers.
   • You tell the cluster the desired state; it works out the steps to reach it.
   • Keeping the two planes apart lets each one grow or fail on its own.
3. 3

   Parts of the control plane

   • An API server is the front door that accepts and validates every request.
   • A state store keeps the record of desired and current cluster state.
   • A scheduler picks a machine for each workload that has no home yet.
   • Controllers watch the state and act when reality differs from the plan.
4. 4

   How work gets scheduled

   • New workloads wait in a queue until the scheduler assigns them a machine.
   • Filtering first removes machines that lack enough CPU, memory or required labels.
   • Scoring then ranks the remaining machines and the best one wins.
   • The scheduler only records its choice; the chosen worker starts the container.
5. 5

   The reconcile loop

   • A controller compares desired state with observed state, again and again.
   • When the two differ, it takes a small step to bring them closer.
   • Example: you ask for 3 copies (illustrative) and only 2 are running, so it starts one.
   • This repeating loop is why clusters correct drift without human action.
6. 6

   Inside a worker machine

   • Each worker runs an agent that talks to the control plane and reports status.
   • A container runtime on the worker pulls images and starts the containers.
   • Workloads are grouped into small units that share a network address and storage.
   • The worker reports resource use so the scheduler knows how much room is left.
7. 7

   Life of a workload

   • You submit a workload description to the API server.
   • The description is stored, then the scheduler assigns it to a worker.
   • The worker's agent pulls the image and starts the container.
   • Status flows back to the control plane so you can see it is running.
8. 8

   Reaching services on the network

   • Workloads can be replaced at any time, so their addresses change.
   • A service gives a group of workloads one stable name and address.
   • Traffic sent to the service is spread across the healthy copies behind it.
   • Outside traffic enters through a load balancer or gateway at the cluster edge.
9. 9

   Storage for workloads

   • Container storage is temporary and disappears when the container is replaced.
   • Persistent volumes keep data beyond the life of a single container.
   • A workload requests storage by size and type, and the cluster provides it.
   • Databases and other stateful apps need this so data survives a restart.
10. 10

    Highly available layout

    • Run several control plane machines so one failure does not stop management.
    • The state store keeps copies and needs a majority to agree, so use an odd count such as 3 (illustrative).
    • Spread control machines and workers across separate failure zones.
    • Put a load balancer in front of the API servers to share requests.
11. 11

    How the cluster heals itself

    • If a container crashes, the worker restarts it automatically.
    • If a worker machine stops reporting, the control plane marks it unhealthy.
    • Its workloads are rescheduled onto other machines with spare capacity.
    • Health checks stop traffic going to copies that are not ready.
12. 12

    The API at the centre

    • Every component talks through the API server rather than to each other directly.
    • Users, tools and automation all use the same API to read and change state.
    • Access rules at the API decide who may do what.
    • This single path makes cluster changes consistent and easy to audit.
13. 13

    What to remember about how clusters run

    • You declare what you want; the cluster works to make it true.
    • The control plane decides, and workers do the running.
    • Scheduling matches workloads to machines that have room.
    • Reconcile loops and redundancy let the cluster heal itself.