beginner35 minby DevFox

Your First App on Kubernetes

The capstone: take the container you built earlier and give it a Deployment, a Service, configuration, storage, probes and an Ingress — then update it and roll it back.

Kubernetes

Fifteen lessons of objects, each solving what the previous one left open. This one puts them together on the notes application from the Docker course: a Deployment behind a Service behind an Ingress, configured from a ConfigMap and a Secret, talking to a Postgres with real storage, with probes and resource requests — then updated, and rolled back.

Follow it end to end on your local cluster. By the finish you will have a directory of manifests you could apply to any cluster, and a checklist to hold new workloads against.

01 — configuration
A ConfigMap and a Secret. First, because everything else reads from them.
02 — the database, with storage
A PersistentVolumeClaim and a Deployment, plus a ClusterIP Service so the application can find it by name.
03 — the cache
Same shape, no storage. Redis loses its data on restart and that is the point of a cache.
04 — the application
A Deployment with probes and resource requests, and a Service in front of it.
05 — the way in
An Ingress, so a hostname outside the cluster reaches the Service inside it.
Then break it, update it, and roll it back
The three steps that turn a working deployment into one you trust.

Numbered filenames, applied in order, so a dependency exists before the thing that needs it

What we are deploying

The same image as the Docker capstone: a small notes API that stores notes in Postgres, counts views in Redis, and exposes /health and a /ready that checks both dependencies.

Nothing about the image changes. That is worth pausing on — the artefact you built with a Dockerfile is exactly what a cluster runs, and this whole lesson is about the layer above it.

Get the image into the cluster. Locally that means loading it, because a kind cluster cannot see your machine's Docker images:

And make a namespace, so the whole thing can be removed in one command:

Step 1: configuration

01-config.yaml. Ordinary settings in a ConfigMap, the password in a Secret:

In a real deployment that Secret is created out of band or by a tool like Sealed Secrets — it is written inline here so the lesson is followable, and a file like this one never belongs in a repository.

Step 2: the database, with storage

02-postgres.yaml. One replica, its own claim, a probe that reports readiness honestly:

Two deliberate choices. strategy: Recreate because two Postgres processes must never hold one data directory — a rolling update would briefly run both. And PGDATA in a subdirectory, because a freshly provisioned volume is not always empty.

Step 3: the cache

03-cache.yaml. Stateless here, so no claim:

Step 4: the application

04-api.yaml. This is where every lesson shows up at once:

Read it against the course. Three replicas so a node failure is survivable, spread across nodes. maxUnavailable: 0 so capacity never drops during a release. Configuration from the ConfigMap and Secret, with no values in the template. Readiness on /ready, which checks the database and cache; liveness on /health, which checks only the process. A startup probe so a slow first connection is not mistaken for a hang. A preStop pause so endpoint removal propagates before shutdown. Requests for the scheduler and a memory limit for safety.

Note the Service's targetPort: http — the container port's name, so moving the port is one edit.

Step 5: the way in

05-ingress.yaml, assuming the ingress-nginx controller from the Ingress lesson:

Step 6: apply it and prove it works

Then check, in the order that isolates a problem to one layer:

Now exercise it properly:

Step 7: break things on purpose

This is the part worth not skipping. Three experiments, each proving one promise the course made.

Delete every application pod

Self-healing.

Three replacements appear and the Service keeps answering, because readiness holds new pods out of the endpoints until they can serve.

Destroy the database pod

Durability.

The note you created is still there afterwards. It was never in the pod — it was in a volume the pod merely mounted.

Change the ConfigMap

Nothing happens.

The value changes, kubectl get configmap confirms it, and the running pods keep the old one until you restart them.

Each takes under a minute, and each is the only way to know the promise actually holds

Self-healing. Delete every application pod:

Three replacements appear and the Service keeps answering, because readiness holds new pods out of the endpoints until they can serve.

Durability. Destroy the database pod and check your note:

The note is still there. It was never in the pod.

Configuration. Change the log level and watch nothing happen:

Environment variables are read once at start-up. The restart is the mechanism, and there is no substitute for it.

Step 8: update, and go back

Change something in the application, build a new tag, load it, and roll it out:

Watch it happen, one pod at a time:

Then rehearse the thing you will one day need in a hurry:

And rehearse a release that fails, which is the more valuable drill:

The new pod never became ready, so it never took traffic, and maxUnavailable: 0 meant the old pods were never removed. A broken release was a non-event.

Cleaning up

Or, for the whole cluster:

The checklist

Hold any new workload against this. Each line is one lesson.

Cheat sheet

Where to go next

You can deploy a real multi-service application to a cluster, keep its data, configure it from outside, get traffic to it, ship a new version without dropping a request, and put the old one back. That is the foundation, and it is most of what day-to-day work needs.

Three directions from here, in the order they usually become urgent. Templating, because copying these manifests for a second environment does not scale — Kustomize is built into kubectl and is the shorter path; Helm is the packaging ecosystem. Observability, because kubectl logs does not survive a pod being replaced — Prometheus for metrics, Loki or a hosted service for logs. And GitOps, where a controller like Argo CD or Flux applies your repository to the cluster continuously, so the cluster and the repository cannot drift apart.

Beyond those: StatefulSets and operators for stateful workloads, NetworkPolicies and RBAC for real isolation, the Gateway API as Ingress's successor, and autoscaling both pods and nodes.

Before any of it, deploy something of your own with the checklist above open. The gap between following a lesson and writing manifests for your own application from scratch is where this actually becomes a skill.