You have the concepts and a kind cluster with a standalone Redis. Now comes the whole platform: Aurora Libros' four services with real manifests, the probes from 06-01, the hardening from 05-03 and the image your pipeline published in 06-02. By the end, /books will return the nine titles from inside the cluster.

1. Organizing k8s/ and the Namespace
2. aurora-cache: Deployment and Service
3. Why aurora-db is a StatefulSet
4. The StatefulSet with volumeClaimTemplates
5. The headless Service and the ConfigMap with init.sql
6. aurora-api: image by digest and imagePullSecrets
7. The three probes in the manifest
8. requests, limits and the QoS classes
9. Pod-level and container-level securityContext
10. Configuration with ConfigMap and Secret
11. aurora-web: Deployment, Service and Ingress
12. TLS with cert-manager
13. Kustomize: bases and per-environment overlays
14. Bringing it up and verifying it
15. Debugging: the states of a Pod
16. Helm as an alternative

One file per service, with all its objects together separated by ---. It is more practical than one file per object: to understand aurora-api you open a single file and see its Deployment, its Service and its configuration. The first one is the Namespace, a five-line object (apiVersion: v1, kind: Namespace, metadata.name: aurora) that creates the partition everything else will live in.

Two patterns that will repeat across every manifest. The first: ports are named (name: redis) and then referenced by name in the Service and in the probes; if one day you change the number, you change it in a single place. The second: the app.kubernetes.io/name label is the only one that appears in the selector, and the rest stay out of it, because the selector is immutable and it is unwise to tie it to anything that will change. And notice that Redis here is a disposable cache: no volume and no persistence, because if the Pod dies the API goes back to serving with source: db until it warms up again, which is exactly what you decided in the readiness probe in 06-01.

A Deployment with a volume for PostgreSQL fails for two reasons. First, the default strategy starts the new Pod before killing the old one: for a few seconds there would be two PostgreSQL instances writing over the same files, which corrupts the data. Second, if you scaled to two replicas, both would share the same PVC —or fight over it— with no coordination whatsoever.

Warning. Running a database in Kubernetes is feasible, but in production it demands an operator (CloudNativePG, Zalando Postgres Operator, Crunchy) to handle failover, backups, replication and version upgrades, or else a managed service outside the cluster altogether. A bare StatefulSet like the one in this lesson is fine for learning and for development environments, but it does not cover disaster recovery. Validate this decision with the infrastructure and data officer in your organization before putting real data in it.

Putting PGDATA in a subdirectory is not a whim: many provisioners create a lost+found at the root of the volume and PostgreSQL refuses to initialize in a directory that is not empty. Using /data/pgdata avoids that failure, which is one of those that cost you a whole afternoon. As for volumeClaimTemplates, it generates a PVC named data-aurora-db-0, with one deliberate property: deleting the StatefulSet does not delete its PVCs. That is a safety net —the data survives an accidental deletion— and also a source of surprises, because recreating the StatefulSet reattaches the previous volume with everything that was inside it.

A normal Service spreads traffic across Pods, which is exactly what you do not want with a database: every replica is different and you have to be able to address a specific one. With clusterIP: None, DNS returns the Pods' addresses directly, and each one additionally gets its stable name: aurora-db-0.aurora-db.aurora.svc.cluster.local. With read replicas, that name is what lets you point the writes at the primary.

The init.sql with the nine titles comes in as a ConfigMap generated from the file, with kubectl create configmap aurora-init-sql --from-file=init.sql=db/init.sql -n aurora. One limit worth knowing: a ConfigMap cannot exceed 1 MiB, because it lives in etcd. For an init.sql with nine books that is plenty, but a real dump will not fit; in that case you use an initContainer that downloads it from object storage.

Pinning the digest alongside the tag is what makes the deployment genuinely immutable: the tag documents which version it is and the digest guarantees which bytes run, even if somebody has moved 2.0.0 in the registry. It is the practice any serious admission policy requires. On imagePullPolicy there is a classic trap: with the latest tag the default value is Always, and with any other one it is IfNotPresent; once the digest is pinned, IfNotPresent is correct and avoids needless downloads, because a digest always identifies the same content.

The numbers were chosen with a logic behind them: readiness reacts fast (10 s) because its consequence is cheap and reversible —stop sending traffic—, while liveness reacts slowly (45 s) because its consequence is expensive and disruptive —kill the process. Inverting those timings is the recipe for cascading restarts under load. And the preStop with sleep 5 plays the same role here as the five-second wait you programmed in 06-01: when Kubernetes decides to terminate a Pod, it removes its endpoint and sends SIGTERM at the same time, and those two things propagate at different rates across every kube-proxy in the cluster. The sleep delays the SIGTERM just long enough for the routing tables to update first.

For aurora-api, requests: { memory: 128Mi, cpu: 100m } and limits: { memory: 512Mi, cpu: "1" }. The two fields do different things:

aurora-api ends up as Burstable, which is right for an API: it reserves little so many replicas fit per node and it can climb to the limit during peaks. aurora-db, on the other hand, is a candidate for Guaranteed in production, because you do not want the kernel picking your database when something has to be evicted. The numbers come straight from the docker stats table in 06-01: a 214 MiB peak → a 512 MiB limit.

This is, line by line, the translation of the hardening in the compose.prod.yaml from 05-03. The only new item is runAsNonRoot: true, which deserves attention: it does not change the user, it verifies that the image does not start as root, and if it does the Pod fails to be created with CreateContainerConfigError. It is a cheap check that stops a badly built image from ever running. And fsGroup solves the classic permissions problem with volumes: Kubernetes changes the owning group of the mounted content to that GID, so an unprivileged process can write to its PVC.

The API needs not one line of change: the same variable names you defined in config.js in 06-01 now arrive from a ConfigMap instead of from Compose, which is the payoff for having taken all the configuration out of the image. You could also mount the secret as a file and use DB_PASSWORD_FILE, which is safer for the reasons you saw in 06-03 about inheritance by subprocesses; secretKeyRef is used here for brevity, but in production the volume is preferable and your code already supports it.

One important operational detail: changing a ConfigMap does not restart the Pods. To apply the change you have to force it with kubectl rollout restart deployment/aurora-api, or let Kustomize generate the ConfigMap with a hash suffix, which is what we will do.

Notice the architectural change: in Compose, aurora-web acted as a reverse proxy towards the API. Here that job belongs to the Ingress, and Nginx is reduced to serving static files. That is the natural arrangement in Kubernetes: routing is the platform's responsibility, not your container's, and that way you can scale the front end and the API separately.

With cert-manager installed and a ClusterIssuer configured, those five lines are enough: the operator sees the annotation, requests the certificate from Let's Encrypt, solves the ACME challenge, stores the result in the aurora-tls Secret and renews it automatically before it expires. It is the canonical example of an operator and of what Kubernetes adds over Swarm: a recurring task somebody used to do by hand becomes one more controller. The issuer's configuration —Let's Encrypt production or staging, DNS-01 versus HTTP-01— is a platform decision worth agreeing on with your infrastructure team.

Kustomize is the same idea as the Compose overrides from 04-06, with the difference that here it is part of kubectl: a shared base and overlays that patch it per environment, without duplicating a single file or using templates.

The configMapGenerator solves the problem from the end of section 10: it generates the ConfigMap with a suffix derived from the hash of the content (aurora-init-sql-7f9c2d) and automatically updates the reference in the Deployments. Because the name changes, the Pod template changes, and the rolling update fires by itself when you edit the configuration. It is exactly the behavior you want and one that never happens by hand.

The aurora-db-0 with its ordinal and the CLUSTER-IP None on the headless Service confirm the StatefulSet is set up correctly.

The nine titles are there, and the second call returns source: cache: the cache-aside works exactly as it did on your laptop, now spread across three API Pods that talk to a Redis and a PostgreSQL through their Services. The application has not changed a single line since module 4.

kubectl debug solves the problem you had with the minimal images from 05-03: it attaches an ephemeral container with every tool to the already running Pod, sharing its network and its namespaces, without restarting anything and without the image needing to contain a sh. It is the netshoot from module 3, applied to the Kubernetes world.

The usual combination is to use Helm for third-party software —ingress-nginx, cert-manager, Prometheus— and Kustomize for your own, which is what Aurora Libros does. Helm shines when you want to distribute your application to third parties who need to parameterize it; for an in-house application with two environments, Kustomize saves you from turning your manifests into unreadable templates.

• A database in a Deployment. During the update two Pods coexist writing to the same disk. StatefulSet with stop-first, and an operator in production.
• Forgetting imagePullSecrets. ImagePullBackOff on every Pod with a private registry. The secret is per namespace.
• PGDATA at the root of the volume. The provisioner's lost+found prevents PostgreSQL from initializing.
• Liveness pointing at /health/ready. Cascading restarts whenever the database coughs. Liveness only looks at the process.
• A short initialDelaySeconds with no startupProbe. The Pod restarts before it has finished starting, forever.
• Editing a ConfigMap and expecting it to be applied. It restarts nothing: rollout restart or configMapGenerator.
• Tip: kubectl apply -k --dry-run=server in the pipeline validates the manifests against the real API before touching the cluster, and kubectl rollout restart deployment/... is the correct way to "restart" (not delete pod).
• Tip: kubectl get events --sort-by=.lastTimestamp is the most useful view when something fails and you do not even know which object to look at.

Exercise 1. Deploy the whole of Aurora Libros on your kind cluster and verify it end to end: that aurora-db-0 has its PVC bound, that /books returns the nine titles and that the second call comes from the cache.

Exercise 2. Diagnose three deliberately triggered failures without looking at the manifests: a Pending caused by impossible requests, an ImagePullBackOff and a CrashLoopBackOff caused by a missing required variable. State in each case which command reveals it.

Exercise 3. Demonstrate that the StatefulSet preserves identity and data: write a record into the database, delete the aurora-db-0 Pod and check what survives and what does not.

Solution 1.

The name data-aurora-db-0 is the signature of volumeClaimTemplates: <template-name>-<statefulset-name>-<ordinal>. If you scaled to two replicas, data-aurora-db-1 would appear, with its own disk, which is precisely what a Deployment cannot give you.

The end-to-end verification is complete: the ConfigMap with init.sql ran while PostgreSQL was initializing, the nine titles are in the table, and the API serves them from the database the first time and from Redis the second. But it is worth pausing on what was not needed. You did not touch the application code, or the Dockerfile, or the variables it expects. The image the cluster runs is the same one the pipeline built in 06-02 and the same one that ran in your Compose: the contract you established in 06-01 —configuration per environment, separate probes, graceful shutdown— is what made changing platforms nothing more than changing who injects the variables.

Solution 2.

The diagnostic rule the table boils down to is the one that saves the most time in Kubernetes: if the container never managed to start, the answer is in the events; if it started and died, it is in the logs. In the first two cases kubectl logs returns nothing, and not because it fails, but because no process ever wrote anything. In the third, describe only says Back-off restarting failed container, which explains nothing; the --previous is essential because the current container has only just been born and the one that failed no longer exists. And look at the quality of that third message: it says exactly which variable is missing, which is the config.js from 06-01 paying off in an environment where debugging is far more awkward.

Solution 3.

The contrast with exercise 2 in 06-04 is the point of the lesson. There, deleting a Pod belonging to a Deployment brought back a different Pod with a different name; here aurora-db-0 comes back, the same name, the same DNS and, above all, the same disk, with the tenth book inside it. That the IP changes and nothing breaks demonstrates why the database is always referenced by its DNS name and never by address: aurora-db in the ConfigMap still resolves, so the three API replicas reconnected on their own —with the retry-with-backoff from 04-04— without you touching a thing.

Now the warning this exercise does not demonstrate and that is worth remembering: you have survived the death of a Pod, not that of a node or a disk. With ReadWriteOnce, if the node hosting the PVC becomes unreachable, the Pod can sit in Pending until the volume is released. That, along with the absence of automatic failover, is exactly what a PostgreSQL operator brings and what has to be solved before putting customer data here.

The whole of Aurora Libros lives in Kubernetes. You have written the manifests for the four services with judgment: aurora-cache as a disposable Deployment with named ports, aurora-db as a StatefulSet —with the reason made explicit: two PostgreSQL instances over the same files corrupt the data— with its volumeClaimTemplates, its headless Service, its ConfigMap with the nine titles and PGDATA in a subdirectory to dodge the lost+found. And with the warning in place: this is fine for learning, but production calls for an operator or a managed database, validated with your infrastructure team.

The aurora-api Deployment gathers up everything in the module: the pipeline's image pinned by digest with its imagePullSecrets, the three probes from 06-01 pointing at /health/started, /health/live and /health/ready with deliberately asymmetric timings —fast readiness because it is cheap, slow liveness because it kills—, the preStop that buys the seconds the kube-proxy needs, the requests and limits taken from real measurements with their QoS class, and the securityContext that translates the hardening from 05-03 line by line. Configuration comes in through ConfigMap and Secret without touching a line of the application, which is the payoff for having taken it out of the image. aurora-web is reduced to a static server and the routing moves to the Ingress, with cert-manager renewing TLS on its own.

Everything is applied with kubectl apply -k and Kustomize, with one base and per-environment overlays, and the configMapGenerator that fires the rolling update whenever the configuration changes. You have verified that /books returns the nine titles with source: db and cache on the second call, you can read the table of Pod states with the rule that saves the most time —if it never started, look at the events; if it started and died, look at the logs with --previous—, you have kubectl debug for inspecting images with no shell, and you know when to use Helm and when to use Kustomize.

In the next lesson, Scaling and Load Balancing, the platform learns how to grow. You will see why the API scales by replicating and the database does not, how kube-proxy and the Ingress really balance traffic, and you will set up a HorizontalPodAutoscaler over aurora-api that creates replicas only while you generate real load against /books, measuring latency before and after to find out where the bottleneck actually is.