With the database Ready, every Pod still failing is failing for its own reason. Each one is a family you met in Chapter 13, and each one needs exactly one change.
Read, change, verify
kubectl get pods
kubectl describe pod -l app=market-api | grep -A1 "Failed to pull"
kubectl set image deploy/market-api api=stackmonsters/monster-market-api:v2
kubectl rollout status deploy/market-apiThe loop is the same for every Deployment: read the symptom, make the one change that answers it, wait for rollout status, confirm the READY column. Then the next Deployment.
| Symptom | Family | One change |
|---|---|---|
ImagePullBackOff | image | kubectl set image with the right reference |
Running 0/1, no restarts | readiness | the probe's port or path |
Pending, Insufficient cpu | resources | kubectl set resources --requests= |
CrashLoopBackOff | application | the variable or Secret its logs ask for |
CreateContainerConfigError | config | the ConfigMap, Secret or key it names |
Probes that lie
A Pod that is Running with zero restarts and clean logs, yet never 1/1, has a readiness probe checking the wrong thing. Compare the probe with what the container actually serves:
kubectl get deploy market-web -o jsonpath='{.spec.template.spec.containers[0].readinessProbe.httpGet}'
kubectl logs deploy/market-web --tail=1A probe on port 8080 against a server listening on 80 will fail forever without a single error in the application's own output.
Count before you continue
kubectl get deploy
kubectl get pods --field-selector status.phase=RunningEvery Deployment at N/N and every Pod Running is the exit condition for this stage. The network stage depends on it: an Ingress in front of Pods that are not Ready returns errors you cannot tell apart from a routing fault.