Home/handbooks/Kubernetes
Lab · Manual of Kubernetes

Kubernetes

The helmsman of the digital fleet.

28 exercises6 Parts4 appendices
The colour code shows the level:FoundationalIntermediateAdvancedCloud Architect
● On sale on AmazonPaperback →396 pages · ISBN 9798172530678
get the exercises
git clone --filter=blob:none --sparse https://github.com/calmict/book_labs.git
cd book_labs
git sparse-checkout set kubernetes/ed1
calm@calmict:~$ cat kubernetes/topics
Part 1

The Linux foundations

  • 01A container is just a processFoundational
  • 02A container by hand, without DockerFoundational
  • 03Limiting CPU and RAM by handFoundational
  • 04Dissect an image by handFoundational
  • 05Climb the runtime chainFoundational
  • 06Wire two network namespaces by handFoundational
Part 2

Control Plane architecture

  • 07First contact: kill a Pod and watch who resurrects itFoundational
  • 08Kill the leader: quorum and elections in etcdFoundational
  • 09Knock at the four gates: the API server bare-handedFoundational
  • 10Write your controller in twenty linesFoundational
  • 11Steer the scheduler, then bypass itFoundational
  • 12The ship's doctor: probes, restarts, and resurrectionFoundational
Part 3

The core objects

  • 13The Investigation: Who Touched My Pod?Intermediate
  • 14The Condo Pod: Two Tenants, One Invisible JanitorIntermediate
  • 15The Release, the Disaster and the Comeback (Rollout and Rollback)Intermediate
  • 16The Registry Office: Names, Order and Disks That SurviveIntermediate
  • 17The Three Trades: One per Node, Until Done, On ScheduleIntermediate
Part 4

Networking and storage

  • 18The Address That Does Not Exist (Services and kube-proxy)Intermediate
  • 19The Door and the DoormanIntermediate
  • 20The Arranged MarriageCloud Architect
Part 5

Security

  • 21The Intern and the RobotAdvanced
  • 22The Vault and the CorridorAdvanced
  • 23The Cardboard KingCloud Architect
Part 6

Ecosystem and production

  • 24The Mould and the CastsCloud Architect
  • 25The Meter ReaderCloud Architect
  • 26The Ledger and the AuditorCloud Architect
  • 27The EscortCloud Architect
  • 28The Doorman's PassportCloud Architect
calm@calmict:~$ ls kubernetes/exercises/
01A container is just a processFoundational›

What you build

The journey starts below Kubernetes: you observe a real process through the two views that make a container look like a separate machine.

Objectives

  • Observe the same process from the host and the container (1.2).
  • Compare its PID, hostname and process list (1.2, 1.3).
  • Distinguish process isolation from hardware virtualisation (1.3).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap01/solution
./run.sh

Expected result

  • The process has an ordinary host PID and PID 1 in the container.
  • The hostname and process list show isolated views.
  • run.sh prints OK 1..4 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
02A container by hand, without DockerFoundational›

What you build

After observing two views in chapter 1, you build the illusion yourself using only Linux kernel tools.

Objectives

  • Create PID, mount, UTS, IPC, NET and USER namespaces with unshare (2.2, 2.3).
  • Obtain PID 1, a private hostname and isolated networking (2.2, 2.4).
  • Compare the inodes exposed by /proc/[pid]/ns (2.5).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap02/solution
./run.sh

Expected result

  • The shell is PID 1, the hostname is private and the network shows only loopback.
  • The pid, uts, net and user inodes differ from the host values.
  • run.sh prints OK 1..5 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
03Limiting CPU and RAM by handFoundational›

What you build

Namespaces decide what a process sees; now you directly observe the counters that decide how much it may consume.

Objectives

  • Create a cgroup v2 and read its available controllers (3.1, 3.2).
  • Observe the different outcomes of CPU and memory limits: throttling and an OOM kill (3.3).
  • Verify the process limit and connect the controllers to Kubernetes limits (3.3, 3.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap03/solution
./run.sh

Expected result

  • The delegated cgroup is created and exposes memory and pids.
  • The limited process dies with exit 137, while the same unrestricted allocation succeeds.
  • TasksMax genuinely rejects a fork beyond the limit.
  • run.sh prints OK 1, SKIP 2, OK 3, OK 4, and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
04Dissect an image by handFoundational›

What you build

After namespaces and cgroups, one last piece of the anatomy is missing: the filesystem. In this lab you open an image, follow the references between its objects, and measure how - and in what sense - container root differs from host root: in its powers, yes; in its identity, no.

Objectives

  • Recognise the manifest, config, and layers of an OCI image (4.2).
  • Observe copy-up, whiteouts, and lower-layer immutability with OverlayFS (4.1).
  • Compare capabilities and the kernel inside and outside the container (4.3, 4.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap04/solution
./run.sh

Expected result

  • The three TODOs are complete and the generated files identify real objects.
  • The lower layer remains unchanged after the modification and deletion in the merged view.
  • The attempt to change the clock is refused and the kernels match.
  • The uid seen by the node matches what the container's uid_map predicts.
  • run.sh prints OK 1..6 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
05Climb the runtime chainFoundational›

What you build

You built a container's pieces by hand; now follow who assembles them. Start from the live process, climb to the shim, query containerd, and finally hand a bundle directly to runc.

Objectives

  • Trace the real chain between workload, shim, and init (5.2).
  • Query containerd without going through the Docker CLI (5.1, 5.3).
  • Read namespaces, cgroups, capabilities, and rootfs in the OCI bundle (5.3).
  • Start a process with runc alone (5.2, 5.3).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap05/solution
./run.sh

Expected result

  • The chain shows the workload, containerd-shim, and then init.
  • ctr lists the same ID and config.json contains the ingredients from chapters 2-4.
  • The process started by runc alone appears as PID 1.
  • run.sh prints OK 1..5 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
06Wire two network namespaces by handFoundational›

What you build

The namespaces from chapter 2 were sealed rooms. Now you lay the cables: two veth pairs and a bridge turn two isolated network views into a small network without ever changing the host network.

Objectives

  • Create namespaces, veth pairs, and a bridge as a runtime would (6.1).
  • Follow a ping and read ARP resolution in the neighbour table (6.1).
  • Read the forwarding learned by the bridge in its FDB (6.1).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap06/solution
./run.sh

Expected result

  • The ping crosses the bridge without final packet loss.
  • The neighbour table and FDB contain red's MAC.
  • Both outside peers are br-lab ports.
  • run.sh prints OK 1..5 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
07First contact: kill a Pod and watch who resurrects itFoundational›

What you build

Containers now enter the cluster. In this lab you distinguish the brain from the arms and watch the declarative model correct real sabotage.

Objectives

  • Recognise the control-plane components and the workers' role (7.1).
  • Declare two replicas and observe the reconciliation loop (7.2).
  • Read spec and status in the same API object (7.3).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap07/solution
./run.sh

Expected result

  • You identified the four control-plane components.
  • Spec and status converge on two replicas and the deleted Pod is replaced.
  • run.sh prints OK 1..5 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
08Kill the leader: quorum and elections in etcdFoundational›

What you build

Chapter 7's desired state must survive failures. Here you find it as a replicated key and measure the difference between losing a leader and losing the majority.

Objectives

  • Query three etcd members and find an object as a key (8.1).
  • Force a Raft election without changing member addresses (8.2).
  • Lose and restore quorum in a three-member cluster (8.3-8.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap08/solution
./run.sh

Expected result

  • You saw three members, one leader, and the namespace key.
  • After the first pause the API answers with a new leader; after the second it cannot read.
  • run.sh prints OK 1..6 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
09Knock at the four gates: the API server bare-handedFoundational›

What you build

Etcd stores the truth, but only the API server may touch it. Here you use curl to see the gates a request crosses and the stream that reports every change.

Objectives

  • Explore REST groups, versions, and resources without kubectl interpretation (9.1).
  • Distinguish authentication, authorization, and admission by their responses (9.2-9.3).
  • Observe ADDED and DELETED events over one watch connection (9.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap09/solution
./run.sh

Expected result

  • You explored /api and /apis with curl.
  • You distinguished authentication 401, certificate access, RBAC Forbidden, and exceeded quota.
  • run.sh prints OK 1..7 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
10Write your controller in twenty linesFoundational›

What you build

After LIST and WATCH, build the loop that receives state, measures the gap, and acts.

Objectives

  • Recognise the leader-election heartbeat in Lease objects (10.4).
  • Write an observe-diff-act controller and watch it repair and prune Pods (10.1).
  • Connect polling, informers, caches, and the duel between copies (10.3-10.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap10/solution
./run.sh

Expected result

  • You read the Lease renewal, or the distribution produced a reasoned SKIP.
  • The controller repairs one deletion and prunes one excess Pod.
  • run.sh prints OK 1..7, or a reasoned SKIP 1, and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
11Steer the scheduler, then bypass itFoundational›

What you build

The loop now has one precise job: choose the node, without executing the Pod.

Objectives

  • Separate the scheduler's decision from kubelet execution (11.1).
  • See filtering and scoring through a Pending Pod and its events (11.2).
  • Steer placement with nodeSelector, anti-affinity, taints, and tolerations (11.3-11.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap11/solution
./run.sh

Expected result

  • You compared a scheduled Pod with one assigned directly.
  • You observed both Pending states and their FailedScheduling reasons.
  • run.sh prints OK 1..9 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
12The ship's doctor: probes, restarts, and resurrectionFoundational›

What you build

After the scheduler's choice, observe the kubelet keeping the Pod healthy and ready on its node.

Objectives

  • Watch failed liveness restart the container and produce back-off (12.2).
  • Watch readiness remove and restore traffic without a restart (12.2).
  • Create a static Pod and prove its resurrection by the kubelet (12.1).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap12/solution
./run.sh

Expected result

  • You distinguished a liveness restart from readiness traffic removal.
  • You saw the static Pod return with a new UID.
  • run.sh prints OK 1..9 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
13The Investigation: Who Touched My Pod?Intermediate›

What you build

> Exercise for Chapter 13 — The Life of a Pod: From kubectl apply to the Running Container of the > *Kubernetes Manual* (Calm ICT series — [calmict.com](https://calmict.com)).

Objectives

  • reconstruct the whole relay race of a kubectl apply from the evidence: four different signatures on the events (deployment-controller, replicaset-controller, default-scheduler, kubelet);
  • follow the chain of ownership Deployment → ReplicaSet → Pod written in the ownerReferences, and descend below the API down to the Linux process — meeting the namespaces and cgroups of Phases 1-2 again;
  • tell the two cures apart: the kubelet restarting a dead container (same Pod, RESTARTS climbing) and the controller replacing a deleted Pod (new name).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap13/solution
./run.sh

Expected result

  • [ ] You have the timeline with the four signatures and the reconstructed logical order.
  • [ ] You have the chain Pod → ReplicaSet → Deployment read from the ownerReferences.
  • [ ] You found the PID on the node and its kubepods cgroup with the QoS class in the path.
  • [ ] You observed both cures: RESTARTS at 1 after the kill -9, a new name after the delete.
  • [ ] answers.md answers the three questions and the Deployment has been removed.
Folder on GitHub ↗Full README ↗
14The Condo Pod: Two Tenants, One Invisible JanitorIntermediate›

What you build

> Exercise for Chapter 14 — The Pod in Depth of the > *Kubernetes Manual* (Calm ICT series — [calmict.com](https://calmict.com)).

Objectives

  • demonstrate why the unit is the Pod and not the container: two containers talking over localhost and passing files on a shared volume;
  • unmask the pause container: first from the namespace inodes on the node, then — turning the condo into glass — watching it appear as PID 1 inside the Pod;
  • watch an init container play gatekeeper (the Init:0/1 phase live) and read the QoS class of three Pods from their resources — finding it again in chapter 3's cgroup hierarchy.

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap14/solution
./run.sh

Expected result

  • [ ] The wget from the writer returns the date written by the other container (shared localhost + volume).
  • [ ] You have the inodes: identical net between the two containers, different pid, and you found the /pause process on the node.
  • [ ] In condo-glass you saw /pause as PID 1 from inside the Pod.
  • [ ] You observed the Init:0/1 phase and the three QoS verdicts (BestEffort, Burstable, Guaranteed).
  • [ ] answers.md answers the three questions and the six Pods have been removed.
Folder on GitHub ↗Full README ↗
15The Release, the Disaster and the Comeback (Rollout and Rollback)Intermediate›

What you build

> Exercise for Chapter 15 — ReplicaSet and Deployment of the > *Kubernetes Manual* (Calm ICT series — [calmict.com](https://calmict.com)).

Objectives

  • read the division of labour: the ReplicaSet as guardian of the count, the Deployment as orchestrator of ReplicaSets — with the old ReplicaSets kept at zero as historical memory;
  • perform a zero-downtime rolling update and watch it pod by pod (maxSurge 1, maxUnavailable 0);
  • survive a broken release: the rollout gets stuck but the service stays up, and kubectl rollout undo brings you back in an instant — understanding it is no magic, just the reconciliation loop again.

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap15/solution
./run.sh

Expected result

  • [ ] You watched the rolling update pod by pod, never below 3 active.
  • [ ] After the release you have two ReplicaSets (3 and 0) and the history with the change-causes.
  • [ ] In the disaster: rollout stuck in ImagePullBackOff while the 3 pods of the previous version kept Running.
  • [ ] After the undo the image is back to alpine:3.20 and the revision was reborn with a new number.
  • [ ] answers.md answers the three questions and the Deployment has been removed.
Folder on GitHub ↗Full README ↗
16The Registry Office: Names, Order and Disks That SurviveIntermediate›

What you build

> Exercise for Chapter 16 — StatefulSet and State Management of the > *Kubernetes Manual* (Calm ICT series — [calmict.com](https://calmict.com)).

Objectives

  • distinguish fungible Pods from stable identities (§16.1);
  • observe ordinals, ordering, and predictable DNS through a headless Service (§16.2);
  • verify one personal disk per replica and its lifecycle (§16.3).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap16/solution
./run.sh

Expected result

  • [ ] You have the name contrast: random in the crowd, diary-N in the registry, born in 0→1→2 order.
  • [ ] diary-1 was reborn as diary-1 and its diary held the line from its previous life.
  • [ ] You saw the 3 personal PVCs, still alive after the StatefulSet's deletion, and the full diary after the recreation.
  • [ ] The nslookup of the stable name resolves from inside.
  • [ ] answers.md answers the three questions and the cleanup includes the PVCs.
Folder on GitHub ↗Full README ↗
17The Three Trades: One per Node, Until Done, On ScheduleIntermediate›

What you build

> Exercise for Chapter 17 — DaemonSet, Job and CronJob of the > *Kubernetes Manual* (Calm ICT series — [calmict.com](https://calmict.com)).

Objectives

  • read the DaemonSet as a geographic contract (§17.1);
  • distinguish Job completion, container restart, and Pod retry (§17.2);
  • follow the CronJob → Job → Pod chain (§17.3).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap17/solution
./run.sh

Expected result

  • [ ] watchman: 2 watchmen before the toleration, 3 after, and the same-node rebirth.
  • [ ] countdown Completed with the counting logs; flaky Failed with BackoffLimitExceeded after 3 pods.
  • [ ] The CronJob's first punch: a tick-<timestamp> Job with the date in its logs.
  • [ ] answers.md answers the three questions (trades table included).
  • [ ] The book-labs-crew cluster has been deleted.
Folder on GitHub ↗Full README ↗
18The Address That Does Not Exist (Services and kube-proxy)Intermediate›

What you build

> Exercise for Chapter 18 — Services and the Magic of kube-proxy of the > *Kubernetes Manual* (Calm ICT series — [calmict.com](https://calmict.com)).

Objectives

  • observe the changing addresses of ephemeral Pods (§18.1);
  • use a ClusterIP and identify its dataplane implementation (§18.2–18.3);
  • follow EndpointSlice and stable CoreDNS resolution (§18.4–18.5).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap18/solution
./run.sh

Expected result

  • [ ] You experienced the death of the direct number (pod IP changed after the rebirth).
  • [ ] The switchboard answers with both voices (balancing seen through repeated wgets).
  • [ ] You have proof that the ClusterIP exists on no interface and have observed the detected backend's signatures.
  • [ ] You watched the EndpointSlices chase the scale, and DNS resolve the name to the ClusterIP.
  • [ ] answers.md answers the three questions and the lab is torn down.
Folder on GitHub ↗Full README ↗
19The Door and the DoormanIntermediate›

What you build

After chapter 18's Services, the building has many entrances but still cannot read the name written inside an HTTP request. Here you separate declarative rules from their executor and observe L7 routing.

Objectives

  • Distinguish Service L4 load balancing from Ingress host and path routing (19.1).
  • Declare two Ingress rules and prove they remain inert without a controller (19.2, 19.3).
  • Install Traefik and follow a request to the correct Service and Pod (19.3, 19.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap19/solution
./run.sh

Expected result

  • [ ] The three TODOs in start/ingress.yaml are complete.
  • [ ] Without a controller the rule is inert; with it, the two hosts reach different applications.
  • [ ] run.sh prints OK 1..6 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
20The Arranged MarriageCloud Architect›

What you build

After routing requests, you assign storage without tying the application to a particular disk: the PVC asks, the PV offers, and the binder arranges the marriage.

Objectives

  • Bind a PVC to a compatible static PV and observe the one-to-one constraint (20.1).
  • Trigger dynamic provisioning through the default StorageClass (20.2).
  • Compare the Retain and Delete reclaim policies in operation (20.3).
  • Recognize the provisioner as a controller and connect it to the CSI interface (20.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap20/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete and the manifests describe both provisioning forms.
  • [ ] spinster remains Pending while bride occupies the static PV.
  • [ ] run.sh prints OK 1..6 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
21The Intern and the RobotAdvanced›

What you build

Storage separated request from implementation; now you separate authentication from authorization. You hire a person with a certificate and give a workload an identity of its own.

Objectives

  • Create a user identity with a key, CSR, certificate, and dedicated kubeconfig (21.1).
  • Give a Pod a ServiceAccount and use its mounted token to call the API (21.2).
  • Apply least-privilege Role and RoleBinding objects and verify their boundaries (21.3, 21.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap21/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete.
  • [ ] The intern is recognized and remains confined to her job description.
  • [ ] The robot changes from 403 to PodList only after the binding.
  • [ ] run.sh prints OK 1..6 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
22The Vault and the CorridorAdvanced›

What you build

RBAC closed the API boundary; now you close the paths between workloads with a network contract.

Objectives

  • Observe default allow and invert it with a default deny (22.1, 22.2).
  • Allow only a labelled client on TCP 8080 (22.3).
  • Deny egress and verify that the CNI enforces the policy (22.3, 22.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap22/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete.
  • [ ] Default allow, ingress deny, labelled allow, and egress deny behave as described.
  • [ ] run.sh prints OK 1..4 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
23The Cardboard KingCloud Architect›

What you build

The network boundary is closed; now you reduce what a process may do through the kernel shared with its host.

Objectives

  • Inspect uid, capabilities, seccomp mode, and filesystem writability (23.1, 23.2).
  • Apply a restricted SecurityContext and verify each defence (23.2, 23.3).
  • Enforce Pod Security Standards across a namespace (23.5).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap23/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete.
  • [ ] Every process-level defence is observed in the running Pod.
  • [ ] run.sh prints OK 1..5 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
24The Mould and the CastsCloud Architect›

What you build

You have coordinated Kubernetes objects by hand; now one chart turns their shared shape into a versioned release.

Objectives

  • Contrast repeated static manifests with a reusable chart (24.1).
  • Render templates with release data and values (24.2).
  • Install, upgrade, inspect, and roll back a release (24.3, 24.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap24/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete and the chart renders cleanly.
  • [ ] Upgrade changes replicas and message through a deterministic Pod rollout.
  • [ ] Rollback restores revision one and preserves three history entries.
  • [ ] run.sh prints OK 1..4 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
25The Meter ReaderCloud Architect›

What you build

After packaging the platform with Helm, you give it eyes: a reader visits meters and turns raw measurements into verifiable questions.

Objectives

  • Observe the pull model and metrics exposed by node-exporter (25.1, 25.2).
  • Declare a static scrape and its ServiceMonitor equivalent (25.3).
  • Query gauges and counters with PromQL and connect them to alerts and Grafana (25.4, 25.5).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap25/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete.
  • [ ] node-exporter exposes real metrics and Prometheus sees both targets.
  • [ ] All three PromQL queries return results.
  • [ ] run.sh prints OK 1..4 and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
26The Ledger and the AuditorCloud Architect›

What you build

You have learned to observe the cluster; now you hand ArgoCD a ledger and ask it to correct every divergence.

Objectives

  • Use Git as the single source of declarative truth (26.1).
  • Define the source, destination, and policy of an ArgoCD Application (26.2).
  • Observe sync, drift, self-heal, and rollback with git revert (26.3, 26.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap26/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete and the Application is Synced and Healthy.
  • [ ] Manual drift is undone.
  • [ ] The commit and revert produce five and then one replica.
  • [ ] run.sh prints OK 1..4 — or a reasoned SKIP 1 — and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
27The EscortCloud Architect›

What you build

After entrusting state to an auditor, you entrust every call to an escort that applies identity, encryption, and routing without changing the application.

Objectives

  • Observe sidecars, the data plane, and the control plane (27.1, 27.2).
  • Enforce automatic mTLS and workload identity (27.3).
  • Direct an 80/20 canary and connect the mesh to observability (27.4, 27.5).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap27/solution
./run.sh

Expected result

  • [ ] The three TODOs are complete and every workload has a sidecar.
  • [ ] STRICT rejects plaintext but permits in-mesh traffic.
  • [ ] The canary reaches both versions.
  • [ ] run.sh prints OK 1..4 — or a reasoned SKIP 1 — and ALL CHECKS PASSED.
Folder on GitHub ↗Full README ↗
28The Doorman's PassportCloud Architect›

What you build

The journey ends by giving the doorman hired in chapter 19 a verifiable identity. In this lab you build a local CA, ask Cert-Manager to issue a certificate, and prove that Traefik serves the shop over HTTPS without any hand-made keys or certificates.

Objectives

  • Frame TLS certificate acquisition, expiry, and renewal (28.2).
  • Observe the SelfSigned, CA, and leaf-certificate chain managed by Cert-Manager (28.3).
  • Obtain automatic HTTPS through the Ingress annotation and tls section (28.4).
  • Verify the issuer, SAN, and application response through Traefik (28.1, 28.4).

How to test it

Fill in the TODOs in the starter files, then run the solution's test:

cd kubernetes/ed1/cap28/solution
./run.sh

Expected result

  • TODOs 1..3 describe the authority, TLS hostname, and Secret.
  • The local CA and the shop-tls Certificate are Ready.
  • The HTTPS call validated against the local CA returns secure shop.
  • run.sh prints OK 1..5 and ALL CHECKS PASSED, including the contrast without the annotation and tls section.
Folder on GitHub ↗Full README ↗