Course page
Log in

You are watching a free preview. Enroll to open all 26 lessons, track progress and ask the course tutor.

Enroll for $79.99

Section 1: Foundations of reliable workloads

What production ready means on Kubernetes

Video 9 min Lesson 1 of 26 Sample clip Preview

"Production ready" is vague until you write it down. For a workload on Kubernetes, I use a checklist of questions. If you can answer each with evidence, the service is ready. If not, you know what to work on.

The questions

  1. Resources: are requests based on measured usage, and are memory limits set? What happens when usage spikes?
  2. Health: does readiness reflect whether the Pod can serve traffic right now? Could liveness restart healthy Pods during a dependency outage?
  3. Shutdown: does the app stop accepting traffic and finish in flight requests when it receives SIGTERM?
  4. Disruption: can a node be drained without taking the service down? Is there a PodDisruptionBudget?
  5. Spread: are replicas spread across nodes and zones, or could one failure take them all?
  6. Scaling: what scales the service when load grows, and what scales the nodes?
  7. Observability: can you see request rate, errors and latency, and find the logs for a single failing request?
  8. Security: does the Pod run as non root, with only the permissions and network access it needs?
  9. Rollback: how fast can you return to the previous version, and is the database compatible with it?

Why failures compound

Kubernetes is built from cooperating controllers, and their interactions create surprising failures. A memory limit that is too low causes OOM kills; restarts make the remaining Pods busier; their latency rises; a strict liveness probe times out and restarts them too. One wrong number becomes an outage. Most of this course is about breaking those chains.

Our lab

We use a three node kind cluster and a sample service with an API, a worker and a dependency we can make slow or unavailable on demand. Each section introduces a failure, lets you observe it with kubectl, metrics and logs, and then fixes it.

kind create cluster --name prod-lab --config lab/kind-3-nodes.yaml
kubectl apply -k lab/base
kubectl get pods -o wide

The lab also installs metrics server and a small Prometheus stack, so you can watch resource usage and request metrics as experiments run.

By the end of the course you will have answered all nine questions for the sample service, and you can use the same checklist for your own.

← → switch lessons