Let us begin with what no Kubernetes lesson usually says in its first paragraph: for Tramontana S.L., Kubernetes is disproportionate. One application, one database, three people and five hundred bookings a month do not justify a distributed container orchestrator. Setting it up here would multiply the operational complexity by five in exchange for solving problems Tramontana does not have.

This lesson is going to say so with numbers in section 2, and even so you are going to do the whole of it. For three reasons that do hold up:

1. It is the industry's dominant technology. You are going to run into it in your next job, in most systems administration job adverts and in practically any platform team.
2. Understanding it makes you a better administrator even if you never use it. Kubernetes is a distillation of decades of good practice — health, progressive deployments, resource limits, configuration separated from code — and those ideas apply just the same with systemd.
3. Knowing when NOT to use it is part of knowing how to use it. And that can only be argued having built it.

So you build it on srv-tramontana-test, with k3s, and you deploy Tramontana Bookings for real. At the end you come back to the question knowing exactly what you are talking about.

1. Objective, prerequisites and a warning
2. What problem Kubernetes solves and when NOT to use it
3. Architecture: control plane and worker nodes
4. Distributions: kubeadm, k3s, microk8s and the managed ones
5. Installing k3s with a server and an agent
6. kubectl and the kubeconfig
7. The objects, in dependency order
8. Complete manifests for Tramontana Bookings
9. Rolling deployment and rollback
10. Security: securityContext, NetworkPolicy, RBAC and PSS
11. Diagnosis: reading events and the four common failures
12. Automation with Ansible
13. The real operational complexity

Objective. Bring up a working two-node cluster, deploy Tramontana Bookings with internal high availability, TLS exposure, configuration and secrets separated, health probes and resource limits; carry out a deployment with no interruption and a rollback; and know how to diagnose the common failures.

Prerequisites: containers and Docker (07-05), especially namespaces, cgroups, capabilities and the multi-stage Dockerfile; the virtualisation environment from 07-04; the reverse proxy from 08-01; and the notion of health probes from 07-07.

An operational warning, and it is meant seriously: all of this is done on srv-tramontana-test. Kubernetes is not installed on srv-tramontana. k3s modifies the iptables/nftables rules, manages its own network interfaces and starts a container runtime of its own; on a production server with ufw, nftables, AppArmor and a service running, the interference is real and hard to undo.

And a second VM for the worker node, created with cloud-init as in 07-04:

Kubernetes was born to manage many containers on many machines declaratively. The problems it solves are concrete:

That last row is the central idea. Kubernetes is a reconciliation loop: you declare "I want three replicas of this image with these limits", and a set of controllers continuously compare the real state with the declared one and act to bring them closer together. You do not give orders; you describe an objective. It is the same idempotence principle as Ansible in 07-06, but continuous instead of one-off.

The analysis for Tramontana, with numbers:

The conclusion is unambiguous: Kubernetes would give Tramontana nothing that option B from 07-07 does not already give — two application nodes with a load balancer — and it would add an entire control plane to maintain. The professional recommendation is still the one from 07-07.

And the corollary that is worth internalising: Kubernetes is not the natural evolution of a well-administered system. It is a tool for a specific problem of scale. A well-maintained three-machine system with systemd, Ansible and a load balancer is an excellent architecture, not an immature stage.

The control plane, the four pieces you have to know:

The worker nodes:

Two observations that put the mental model in order:

Everything goes through the apiserver. There is no direct communication between components: the scheduler does not talk to the kubelet, it writes to the apiserver that that Pod goes to that node, and the kubelet reads it. That central-bus architecture is what makes the system extensible and auditable.

If the control plane goes down, the workload carries on working. The kubelets carry on running what they already had and restarting whatever falls over. What is lost is the ability to change things and to react to whole-node failures. It is a valuable design property and it surprises a lot of people.

The choice is k3s, for four concrete reasons:

1. It fits on the test machine. With 3.8 GB and 2 vCPU, kubeadm is a tight squeeze; k3s leaves room to deploy something on top.
2. One binary and one command, without ceasing to be certified Kubernetes: the manifests are identical and what you learn transfers unchanged.
3. It ships the essentials already assembled: Traefik as the Ingress, ServiceLB for LoadBalancer-type Services, local-path as the StorageClass and CoreDNS. With kubeadm you would have to install and configure each piece, which is instructive and here is noise.
4. It is real production, not a toy: it is used in edge deployments, in factories and on devices.

Its trade-off: SQLite instead of etcd by default, which means a single control-plane node. For learning and for many real cases, that is plenty; for high availability of the control plane you have to move to embedded etcd with three nodes.

About the managed services (EKS, GKE, AKS): the provider maintains the control plane — upgrades, certificates, etcd, backups — and you only supply worker nodes. It costs about 70-100 € a month per cluster, and for a small company that genuinely needs Kubernetes it is usually the sensible option: most of the operational complexity of section 13 stops being your problem.

Pinning the version with INSTALL_K3S_VERSION is not optional. Without it the latest one is installed, and a machine rebuilt six months later would get a different version: exactly the problem Ansible came to solve in 07-06. It is the same pinning policy as 05-03.

Resources consumed by the empty cluster, which is an honest figure worth having:

812 MiB of RAM and 7 % of CPU without deploying anything. With kubeadm it would be 1.5-2 GB. That is the entry price of orchestration, and it is part of the argument in section 2.

The kubeconfig is a YAML file with three lists — clusters, users and contexts — and an active context. It contains cluster administrator credentials, so it goes with 600 permissions and never into a repository:

The commands used 95 % of the time:

--previous deserves a note: when a container restarts in a loop, kubectl logs shows those of the current attempt, which is usually empty because it has just started. The ones that explain the failure are those of the previous attempt, and they can only be seen with --previous. It is the first genuinely useful diagnostic trick in Kubernetes.

A Pod is one or more containers that share network space (the same IP, the same localhost), storage and life cycle. It is the smallest unit Kubernetes schedules.

It has gone and it does not come back. That is the reason not to create Pods directly: a Pod is ephemeral and nobody watches it. If the node dies, the Pod dies with it. What you create is a higher-level object that guarantees that N Pods exist, whatever happens.

A ReplicaSet maintains N identical replicas. It is not created by hand either: it is managed by a Deployment, which on top of that knows how to do rolling deployments and rollbacks.

When the image changes, the Deployment creates a new ReplicaSet and reduces the old one while it increases the new one. The old ones are kept with zero replicas, which is what makes kubectl rollout undo possible.

maxUnavailable: 0 with maxSurge: 1 is the no-interruption deployment configuration: first a new one starts, and only when it is ready is an old one withdrawn. It is exactly the connection draining from 07-07, automated.

Pods have IPs and they change constantly. A Service gives a stable name and a virtual IP to a set of Pods, selected by labels.

How the internal DNS works, which is one of the most elegant things about Kubernetes: CoreDNS automatically creates a record per Service with the pattern

From a Pod in the same namespace, tramontana is enough; from another one, tramontana.tramontana. An IP is never hard-coded: you use the name, and the cluster takes care of it.

And what happens underneath: kube-proxy programs rules on each node that rewrite the destination towards one of the Pod IPs behind the Service. There is no load-balancing process; it is the kernel itself.

A LoadBalancer-type Service per application means one public IP per application. An Ingress acts as a shared HTTP reverse proxy: it routes by domain name and by path towards different Services, and it terminates TLS.

An Ingress is only a declaration; a controller is needed to implement it. k3s ships Traefik.

And here is the connection with 08-01, which is the natural question: an Ingress does exactly what you did with Nginx — terminate TLS, route by domain, add headers, rate-limit — with two differences:

In fact, the most widely used controller is ingress-nginx, which is Nginx underneath generating its configuration from cluster objects. What you learned in 08-01 applies literally; only who writes the file changes.

A Kubernetes Secret is base64, NOT encryption. Base64 is an encoding, not cryptography: it is undone with one command and without any key.

There it is, in the clear, with one command and no additional credential. The practical consequences, linking directly back to 06-05:

• Never push a Secret to Git. A YAML file with data: in base64 is a file with the password in it.
• By default it is stored unencrypted in etcd. Whoever reads the etcd file or its backup has every secret in the cluster.
• RBAC is what really protects them: only somebody with read permission on Secrets sees them.

The three real solutions, in increasing order of rigour:

It is the same conclusion as 06-05 in a different wrapper: secrets do not live next to the code, and pass with systemd-creds solved exactly this problem outside Kubernetes.

A container is ephemeral: what it writes to its file system disappears when it restarts. A PersistentVolumeClaim (PVC) is a request for persistent storage; a StorageClass defines how it is provisioned.

A warning about local-path: it creates a directory on the node's disk. It is fast and it has one serious limitation: the Pod becomes tied to that node. If the node dies, the data is nowhere else. For genuinely distributed storage you need Longhorn, Ceph or the cloud provider's storage.

A Namespace is a logical division of the cluster: it separates names, allows resource quotas and is the natural unit of RBAC and NetworkPolicy.

That --dry-run=client -o yaml | kubectl apply -f - is the idiomatic pattern for creating or updating a Secret without it ending up in the history or on disk.

The replicas have landed on different nodes thanks to topologySpreadConstraints, and the Service already has its two endpoints.

The three probes deserve a summary table, because confusing them is the most expensive mistake in this section:

And the classic mistake, which turns up in real production systems with serious consequences: putting the same failureThreshold and periodSeconds on readiness and liveness. Under load the application answers a little more slowly, both fail, and the kubelet restarts Pods that were only busy — which reduces capacity, increases the load on the remaining ones and causes a cascading outage. Liveness always looser than readiness.

Zero requests lost, and the mechanism is the one you already know from 07-07: maxUnavailable: 0 guarantees that there is never less capacity than declared, and the readinessProbe guarantees that a Pod receives no traffic until it answers. The draining you did in 07-07 with socat against HAProxy's socket is, here, a property of the system.

The rollback took eleven seconds, against the minutes of the deploy.sh from 04-07 with its ln -sfn. It is the strongest argument in favour of Kubernetes: reversibility is a property of the system, not a script you have to remember to write correctly.

With the caveat that always has to be stated: rollout undo reverts the code, not the data. If version 3.3.0 ran a schema migration, going back to 3.2.1 leaves the old application against a new database. It is the same problem as in 04-07, and the solution is the same: backwards-compatible migrations. Kubernetes does not solve it.

Kubernetes' defaults are permissive: without a securityContext, a container runs as root with a broad set of capabilities. Everything from 07-05 applies here declaratively:

readOnlyRootFilesystem: true is the one that frustrates the most attacks in practice: most exploits need to write something to disk in order to persist or to download the next stage.

By default, every Pod in the cluster can talk to every other one. It is a flat network, and in a cluster with several applications that means a compromised Pod reaches any other.

Forgetting the DNS rule is the number one mistake with NetworkPolicy. The policy is applied, everything stops working, and the symptom — "the name cannot be resolved" — does not point at the firewall. With policyTypes: [Egress], traffic to CoreDNS is blocked too.

An important warning for k3s: the default CNI (Flannel) does not implement NetworkPolicy, so these objects are accepted and do nothing. You have to install k3s with --flannel-backend=none and deploy Calico, or use --disable-network-policy=false depending on the version. Checking it is essential: believing you have segmentation when you do not is worse than not having it.

Role-based access control uses four objects:

kubectl auth can-i is the RBAC verification tool, and it is the way to check that what is forbidden is forbidden, just as you did with the PostgreSQL roles in 08-02.

They replace PodSecurityPolicy, withdrawn in 1.25. They are three profiles applied per namespace with labels:

The namespace's enforce: restricted makes the apiserver reject any Pod that does not comply. It is a safety net that does not depend on remembering to add the securityContext:

The first command for any problem is kubectl describe, and what matters is at the bottom, in Events.

That last line explains the whole problem: the application is not listening on 8080 yet.

1. CrashLoopBackOff — the container starts, dies, and Kubernetes waits longer and longer before retrying (10 s, 20 s, 40 s... up to 5 min).

There it is: the Secret has the manifest's placeholder, not the real password.

2. ImagePullBackOff / ErrImagePull

3. Pending — the Pod exists and no node accepts it.

The scheduler reserves according to requests, not to actual usage. A node with 20 % of its CPU in use can reject Pods if its requests add up to 95 %. It is the most common confusion with Pending, and it is why setting generous requests "just in case" wastes the whole cluster.

Other causes of Pending: a PVC that cannot be provisioned, a nodeSelector that matches no node, or taints without the corresponding toleration.

4. OOMKilled — the kernel killed the container for exceeding the memory limit.

It is the same cgroups mechanism as 07-05. Exit Code: 137 is the unmistakable signature. And the decision is not automatic: you have to work out whether the limit is too low or whether there is a memory leak in the application — raising the limit without looking only delays the problem.

port-forward is the most used day-to-day tool: it lets you reach an internal service from your laptop without creating an Ingress or a NodePort.

There is an obvious temptation here and it is worth avoiding: Ansible must not replace kubectl apply. The manifests are already declarative and idempotent; wrapping them in Ansible adds a layer without gaining anything. The correct division:

That initial assert is the literal application of the warning in section 1, turned into code that cannot be ignored by carelessness. And backing up the cluster state is not optional: without etcd or its SQLite, the cluster does not exist.

Here is the part Kubernetes presentations leave out, and the one that really answers the question in section 2.

1. The upgrades are constant. Kubernetes releases three minor versions a year and each one gets around fourteen months of support. That forces you to upgrade the cluster at least twice a year, indefinitely. Each upgrade means reading the release notes looking for breaking changes, upgrading the control plane and then the nodes, and verifying that the workloads still work.

2. API versions get withdrawn, and they break manifests that used to work.

A manifest written two years ago can fail after an upgrade. There are tools (pluto, kubent) to detect it beforehand, and using them is mandatory.

3. etcd is delicate. It is a distributed database with quorum: it needs 3 or 5 nodes (an odd number), it is sensitive to disk latency, and it requires periodic compaction and defragmentation. A corrupted etcd with no backup is a lost cluster. And everything about quorum from 07-07 applies.

4. The internal certificates expire. Kubernetes uses mutual TLS between all of its components, with a PKI of its own and certificates that expire after a year. kubeadm renews them on upgrade, but a cluster that has not been touched for fourteen months stops working all at once, with baffling authentication errors.

5. The ecosystem moves very fast. Docker Shim withdrawn in 1.24, PSP replaced by PSS, Ingress evolving towards the Gateway API. What you learn goes out of date faster than in any other area of the system.

6. Diagnosing demands understanding more layers. A failure can be in the application, the container, the Pod, the Service, the CNI, the Ingress, the DNS, the scheduler or the kubelet. Everything from Module 7 is still necessary; Kubernetes adds layers, it does not replace them.

The estimated annual cost, in hours, which is the figure you have to take into a decision:

Between two and four weeks of work a year, just to keep the cluster alive, without counting deploying applications. With a managed service, half that. With systemd and Ansible on three machines, practically zero.

That number is the final answer to the question in section 2, and it also explains why managed Kubernetes is so successful: for most companies, 100 € a month is cheaper than 100 hours a year.

• Using :latest for the image. Two Pods of the same "version" can run different code, and rollout undo rolls back to nowhere. Immutable tags, always.
• Creating loose Pods instead of Deployments. Nobody watches them: if they die, they do not come back.
• A livenessProbe equal to or stricter than the readinessProbe. Under load, healthy Pods get restarted and the service falls over in a cascade. Liveness always looser.
• Not putting a startupProbe on slow-starting applications. Liveness kills the container before it finishes starting, in a loop.
• Believing a Secret is encrypted. It is base64. kubectl get secret -o jsonpath | base64 -d and there it is.
• Pushing Secrets to Git. The YAML with data: is the file with the password. Sealed Secrets or an external store.
• Forgetting the DNS rule in an Egress NetworkPolicy. Everything stops working and the symptom does not point at the firewall.
• Applying NetworkPolicy with a CNI that does not implement it. Flannel in k3s accepts them and ignores them: you think you have segmentation and you do not.
• requests equal to limits and very generous. The scheduler reserves by requests: you waste the cluster and cause Pending with empty nodes.
• Raising the memory limit on seeing an OOMKilled without investigating. It could be a leak, and you are only delaying the problem.
• kubectl logs without --previous on a CrashLoopBackOff. You see the logs of the current attempt, which is empty.
• Not backing up etcd or the SQLite. Without it, the cluster cannot be rebuilt.
• Ignoring the expiry of the internal certificates. A cluster untouched for fourteen months stops working all at once.
• Installing Kubernetes on an existing production server. It rewrites network rules and starts its own runtime. A dedicated machine.
• Setting up Kubernetes for three services. It is the architectural mistake of this entire lesson: 70-130 h/year to solve problems you do not have.
• A tip on method. Faced with any failure: kubectl describe and read the Events from the bottom up. It solves most problems before you touch anything.

After deploying version 3.3.0, the Pods go into CrashLoopBackOff and the service goes down. Diagnose the problem methodically, restore the service and explain what would have prevented the incident.

Compare, for Tramontana's case, the Kubernetes architecture from this lesson with option B recommended in 07-07, using objective criteria, and issue a recommendation.

Write a CronJob manifest that runs the database backup inside the cluster, with the same guarantees as tramontana-backup.timer from 05-05, and explain what is gained and what is lost compared with the systemd timer.

Solution 1

Step 1: the overall picture, before touching anything.

First important and reassuring fact: thanks to maxUnavailable: 0, the version 3.2.1 Pod is still running and serving traffic. The deployment is blocked, not down. That takes the pressure off and allows you to diagnose without rushing.

A single endpoint: the new Pod has never reached Ready, so the Service has never sent it traffic. The readinessProbe has done exactly its job.

Step 2: the logs of the previous attempt.

The root cause in four lines. Version 3.3.0 introduces a new configuration variable — TRAMONTANA_CACHE_URL, for the report cache — that is not in the ConfigMap. The application fails fast and clearly, which is the correct behaviour.

Step 3: confirm and rule out other causes.

Exit Code: 1 with the start and the stop in the same second rules out OOMKilled (137), badly calibrated probes (it would have reached Running for a while) and network problems (it never got as far as connecting to anything). And the ConfigMap confirms the missing key.

Step 4: decide. And the correct decision is to roll back first.

Why roll back before fixing, even though the fix looks trivial: the Deployment is in an inconsistent state, with a new ReplicaSet trying to start in a loop every few seconds. Each retry generates events, consumes resources and pollutes the diagnosis. Leaving the system in a known, stable state before correcting it is the discipline that stops you making things worse — and it is the same logic as the decision tree in the recovery runbook from 07-06.

Step 5: the fix, tested before applying it.

One detail worth knowing: changing a ConfigMap does not restart the Pods that use it as environment variables. If that had been needed:

What would have prevented the incident, which is the question that really matters:

And the three lessons of method:

1. maxUnavailable: 0 turned an outage into a blocked deployment. It is the line of configuration with the best benefit/cost ratio in the whole manifest, and it deserves to be in any production Deployment.
2. The readinessProbe stopped the Service sending traffic to a broken Pod. Without it, half the requests would have failed for three minutes.
3. --previous was what gave the answer. Without that option, kubectl logs returned a freshly started, empty container, and the diagnosis would have taken far longer.

Solution 2

A comparison with objective criteria, on Tramontana's real case: a monolithic application, one database, ~500 bookings a month, two technical people.

The four points where Kubernetes genuinely wins, without exaggerating:

1. Deployment and rollback. Eleven seconds against two minutes, and with no script of your own to maintain. It is a real difference.
2. Relocation when a node goes down. HAProxy takes the failed node out of the rotation but does not recover the capacity; Kubernetes starts the missing replicas on the surviving node.
3. Scaling. One command against an hour of work. It only matters if scaling is frequent, and at Tramontana it is not.
4. Employability. It is a legitimate personal argument but it is not an architectural argument for the company, and they have to be separated honestly.

The five where it loses:

1. 812 MiB of RAM before deploying anything, on 3.8 GB machines. That is more than 20 % of the server devoted to orchestration.
2. 70-130 hours a year of indefinite maintenance, against about 15.
3. Three to six months before you can resolve incidents fluently. During that period, reliability goes down.
4. More failure modes. It is the same argument as 07-07: a system with more pieces has more ways of breaking, and Kubernetes adds a lot of them.
5. The database is still outside. The hard problem from 07-07 — state — is not solved by Kubernetes. PostgreSQL would still be on srv-tramontana, with its manual promotion and its RPO.

The analysis that settles the question, and it is the same reasoning as in 07-07: both options reach roughly the same availability, around 99.8 %, because most of Tramontana's interruptions do not come from a machine failing but from deployments and maintenance, and both of them solve those. Kubernetes does it more elegantly and automatically; option B does it with tools the team already masters.

When two options give the same result, the simpler one wins. And the difference in maintenance — between 55 and 115 hours a year — is equivalent to two or three weeks of work that would not be spent improving the product.

Recommendation: keep option B from 07-07 for production.

And keep the k3s cluster on srv-tramontana-test as a learning lab, at zero marginal cost, because the machine already exists. It is where to practise without risk and where to be ready for the scenario that would change the recommendation.

The three circumstances that would change it, written down in advance so that they can be recognised:

And a final warning worth putting in writing: today's correct decision may not be correct in two years, and that does not mean it is badly taken today. Setting an annual review is more professional than choosing the architecture you might need one day.

Solution 3

What is gained and what is lost, which is the central part of the exercise:

What is genuinely gained is two things, and only two:

1. Resistance to a node failure. It is the strong argument: tramontana-backup.timer lives on srv-tramontana and if that machine is switched off at 02:30, there is no backup that night and nobody finds out until check_backup.sh detects it at 08:00. The CronJob runs on any available node.
2. Real isolation and limits, just as easily. Although systemd also gives them with MemoryMax, here they come as standard.

What is lost, and it carries weight:

1. The secrets get worse. systemd-creds from 06-05 stores them encrypted with the TPM or a host key; a Kubernetes Secret is base64 in etcd. It is an objective step backwards, unless encryption at rest or Vault is added.
2. Failure notification stops being native. OnFailure= in systemd sends the alert directly; with a CronJob you have to monitor kube_job_status_failed from Prometheus (08-06). One more piece.
3. Reaching the host's disk gets complicated, and rightly so: mounting /srv/tramontana/backups in a Pod requires a hostPath, which the restricted Pod Security Standards forbid. The flow would have to be rewritten so that the backup goes straight to restic without passing through the local disk, which is cleaner but is work.
4. An image has to be built and published with the script, pg_dump, restic and their dependencies — and kept up to date. The timer uses what is already installed.

A recommendation consistent with solution 2:

Keep tramontana-backup.timer in systemd. The only real benefit — resistance to a node failure — can be achieved without Kubernetes: by running the timer on the second application node too with a shared lock, or by launching it from a machine other than the one being backed up, which is also better design because the backup does not depend on the backed-up server being alive.

And there is one additional argument: the backup must carry on working when the cluster fails. A backup mechanism that depends on the infrastructure it backs up is exactly the kind of coupling that has to be avoided. It is the same principle by which the runbook from 05-08 lives outside the server and the AIDE database outside the machine.

You have built a two-node Kubernetes cluster, you have deployed Tramontana Bookings on top of it with complete manifests, you have carried out a rolling deployment without losing a single request and a rollback in eleven seconds. And you know what is underneath: the apiserver as the only way in, etcd holding all the state, the scheduler choosing a node according to requests, the controllers tirelessly reconciling the real with the declared, and the kubelet running on each node whatever it is given. You know that if the control plane goes down, the workload carries on working — and why.

You understand the objects in their dependency order and why each one exists. That nobody watches a loose Pod. That the Deployment manages ReplicaSets and that rollout undo lives there. That a Service gives a stable name and IP to a moving target, and that the internal DNS makes it transparent. That an Ingress is the Nginx from 08-01 written as a declarative object — in fact, the most widely used controller is Nginx underneath. And you know that a Secret is base64, not encryption, which links directly to pass and systemd-creds from 06-05 and explains why Sealed Secrets and Vault exist.

You have mastered the three probes and the difference that separates them, which is what causes the most incidents in real production systems: readiness takes you out of the rotation, liveness kills and restarts, startup gives the start-up headroom — and liveness always looser than readiness, or cascading restarts under load are only a matter of time. You know that requests is what the scheduler reserves and limits what the cgroup imposes, with the key asymmetry: exceeding the memory kills the container, exceeding the CPU only throttles it. And you know how to read a CrashLoopBackOff with --previous, a Pending by looking at the node's committed requests, and an Exit Code: 137 as the OOM killer's signature.

But the most valuable thing in this lesson is the conclusion it started with: for Tramontana, Kubernetes is disproportionate, and now you can defend that with numbers — 812 MiB of RAM before deploying anything, 70 to 130 hours of maintenance a year, three to six months of learning curve — instead of with an intuition. That the professional answer to "should we use Kubernetes?" can be "no, and here is why" is exactly the same criterion with which you answered Marta about high availability in 07-07. When two options give the same result, the simpler one wins. And the test cluster stays, because a lab where you can practise without risk is worth far more than the decision not to use it in production.

In 08-06 the course closes. You are going to take everything built across eight modules into a going-to-production checklist of some thirty rows, each with its verifiable evidence — and that is where the encryption-in-transit debt that 08-01 resolved is formally closed. You will finally set up the monitoring with Prometheus and Grafana that was postponed in 05-07, with the four golden signals, the essential PromQL and metrics of your own: the age of the last backup, the days until the certificate expires, the replica's lag. You will configure alerts that are actionable, which is the opposite of what almost everybody does. You will write the daily operations procedure, the duty log and the blameless post-incident review. You will turn the 99.8 % proposed in 07-07 into an error budget that decides whether you deploy or stabilise. And you will close the three debts still open since Module 5: the off-site backup that is not append-only, the authorized_keys2 that nobody has explained, and the availability objective that was never formalised.