Season 7: It Worked on My Laptop · Episode 5 of 8
Three Pods Are Not Ready
You play: Junior AI Developer
Included with Core programme and Certification prep
The situation
The new Assist release, version 2.0, is out on the cluster. It loads a language model when it starts, which takes a while, and it was deployed to three replicas. The team dashboard says the release is green: three pods, all Running. Support is getting errors from the chat anyway, and every time someone looks, three pods are not ready.
What you'll learn
- Kubernetes workload health: readiness, liveness and startup probes and what each one does when it fails, reading Running versus Ready, restart counts and exit codes, container logs and pod events, environment configuration errors, labels and selectors, Services and endpoints, and diagnosing in layers without disabling health checks.
- Pod Security Standards (privileged, baseline, restricted), securityContext and runAsNonRoot, why Secrets are only base64-encoded, and NetworkPolicy.
Who you work with
Kabelo Mokoena
Platform and DevOps Engineer
Maya Chen
Senior AI Engineer · Your mentor
8-BIT
Code Nexus Internal AI Assistant
Scenes
- 1.Green, and wrong
- 2.Three questions, three consequences
- 3.Running, but not ready
- 4.Why does it keep restarting?
- 5.Write the probes
- 6.Two faults, one green dashboard
- 7.Write it up
- 8.Workload health check
What you leave with
The fixture release had two faults: an invalid MODEL_DIR caused startup failure, and the readiness path /healthz returned 404 after that was repaired. Logs, events and backend output separated them. The repair retained the probes and verified ready counts, restarts and a Service request. Running and Ready are useful signals, but neither guarantees application correctness. Startup success enables the other probes; exhausting its failure threshold terminates the container. These simulator checks cover a limited request path, not a full production health or security review.