A container is running but fails health checks, so Kubernetes removes it from service endpoints. Traffic doesn't route to the pod but the container isn't restarted. Fix by increasing initialDelaySeconds, using startup probes, tuning timeouts, or ensuring the application's health endpoint works correctly.
A readiness probe checks if a container is ready to accept traffic. Unlike liveness probes that trigger restarts, failed readiness probes simply remove the pod from service endpoints, stopping traffic from reaching it. This is useful for graceful degradation—the container keeps running but doesn't receive requests. The pod stays in Running state but shows NotReady. Readiness probes should check if the application has finished initialization and external dependencies are available.
Verify the pod is running but not ready:
kubectl get pods -n <namespace> | grep <pod-name>
kubectl describe pod <pod-name> -n <namespace>Expect STATUS=Running but READY=0/1 (or similar).
Check the probe spec:
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A15 readinessProbeGive application more time to start:
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 60 # Increased from default
periodSeconds: 10
failureThreshold: 3Startup probe runs once, allowing extended initialization:
startupProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 5
failureThreshold: 30 # ~150 seconds total
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 10Test the endpoint manually:
kubectl exec -it <pod-name> -n <namespace> -- curl -v http://localhost:8080/readyOr from outside:
kubectl port-forward <pod-name> 8080:8080
curl -v http://localhost:8080/readyApplication may be failing initialization:
kubectl logs <pod-name> -n <namespace> --tail=50Look for database connection errors, dependency failures, or initialization timeouts.
Readiness may fail if databases, caches, or APIs are unavailable:
# Check if database is reachable
kubectl exec <pod-name> -n <namespace> -- \
nc -zv <db-host> <db-port>
# Check DNS resolution
kubectl exec <pod-name> -n <namespace> -- \
nslookup <service-name>Adjust for slow environments:
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 60
timeoutSeconds: 5 # Increased from default 1
periodSeconds: 15 # Increased from default 10
failureThreshold: 5 # Allow more blips before marking not-readyReadiness probes control traffic routing, not container lifecycle. Use /ready endpoint for readiness (checks dependencies) and /health for liveness (checks if still alive). Implement lightweight readiness checks—expensive operations slow down traffic restoration. For stateful apps, ensure state synchronization before declaring readiness. For Deployments without readiness probes, all pods receive traffic immediately; this can cause user-visible errors if startup is slow. Best practice: use both startup and readiness probes for slow-starting apps. Monitor readiness failure rates; persistent failures indicate infrastructure or application issues, not misconfiguration.
No subnets found for EKS cluster
How to fix "eks subnet not found" in Kubernetes
unable to compute replica count
How to fix "unable to compute replica count" in Kubernetes HPA
error: context not found
How to fix "error: context not found" in Kubernetes
default backend - 404
How to fix "default backend - 404" in Kubernetes Ingress
serviceaccount cannot list resource
How to fix "serviceaccount cannot list resource" in Kubernetes