Chapter 64 -- Project 3: deploy that application to Kubernetes with health checks

In one sentence

Take the containerized application from Project 2 and deploy it to a real (even if local, via minikube or kind) Kubernetes cluster with correct liveness/readiness probes, resource requests/limits, a Service, and a ConfigMap/Secret for configuration -- then perform a rolling update and a rollback on it.

Why this matters

This is the project that proves you can operate, not just read about, everything in Parts 14-17. It is also close to a literal recreation of the most common first real task given to a new hire on a platform or SRE team: "here's a containerized app someone else wrote, put it on the cluster properly." Doing this once, deliberately and carefully, with your own hands, converts a dozen chapters of reading into something you can discuss concretely in an interview or a design review.

How it actually works

   STEP 1 -- Set up a local cluster:
     minikube start        (or: kind create cluster)
     kubectl get nodes     -- confirm it's up

   STEP 2 -- Write the Kubernetes manifests (or a Helm chart, per
   Chapter 61, if you want the extra practice):
     - a Deployment for your app image, with:
         resources.requests and resources.limits set deliberately,
         not left blank
         a livenessProbe hitting a cheap endpoint
         a readinessProbe hitting an endpoint that actually checks
         the database connection
     - a ConfigMap for non-secret configuration
     - a Secret for the database password / connection string
     - a Service (ClusterIP is fine for this exercise) in front of
       the Deployment
     - if using a database, a separate Deployment (or StatefulSet) +
       Service + PersistentVolumeClaim for it

   STEP 3 -- Deploy and verify with the Chapter 59 debugging sequence,
   even if nothing is actually broken -- practice the habit:
     kubectl apply -f .
     kubectl get pods -w
     kubectl describe pod <name>
     kubectl logs <name>

   STEP 4 -- Perform a real rolling update:
     Change something visible (a response header, a log line) in your
     app, rebuild the image with a new tag, kubectl set image ..., and
     watch `kubectl rollout status` complete cleanly.

   STEP 5 -- Perform a rollback, on purpose, under a manufactured
   failure:
     Deploy a broken version (bad image tag, or a readiness probe
     pointed at a path that 404s) and confirm the rollout correctly
     STALLS rather than replacing every old Pod. Then:
     kubectl rollout undo deployment/<name>
     and confirm service was never actually interrupted for end users
     during either the bad deploy attempt or the rollback.

Real-world example

This project sequence -- deploy, then deliberately break a rollout, then roll back -- is essentially a compressed version of what companies call "chaos engineering" or "game days" (a practice popularized publicly by Netflix's Chaos Monkey and now standard at many companies operating Kubernetes at scale). The entire value of Kubernetes's rolling-update safety mechanism (Chapter 60) is unproven to you personally until you have watched it actually refuse to finish rolling out a broken version, with your own eyes, on your own cluster. Teams that skip this kind of deliberate practice often discover the first time a rollout stalls in production is also the first time anyone on the team has seen what a stalled rollout looks like -- at 2 a.m., under incident pressure, which is a strictly worse time to learn it.

Try it yourself

This chapter's project is the "try it yourself" -- work through Steps 1 through 5 above, on minikube or kind. Budget a real afternoon for this one; rushing it defeats the purpose.

Common mistakes

Leaving resources.requests unset "to get it working first," then never coming back to set it -- which is how clusters end up with unpredictable scheduling and noisy-neighbor problems in real production environments (Chapter 58).
Writing a readiness probe that checks the same thing as the liveness probe (Chapter 60's central lesson), defeating the purpose of having both.
Not actually watching the rollout fail before rolling back -- clicking straight to rollout undo skips the entire learning point of the exercise, which is seeing Kubernetes's safety mechanism work.
Storing the database password in the ConfigMap instead of a Secret -- functionally similar in this toy exercise, but the habit is worth building correctly from the start (Chapter 57).

Check yourself

Why is it important to deliberately deploy a broken version in this exercise rather than only ever deploying working versions?
What's the difference in outcome between a readiness probe failure and a liveness probe failure during a rolling update, and why does that difference matter for user-facing availability?
If resources.requests is left unset entirely, what does the Kubernetes scheduler assume, and what problem can that cause on a busy cluster?