How to fix waiting for ordinal not yet ready in Kubernetes

List all pods in the StatefulSet:

kubectl get pods -n <namespace> -l app=<statefulset-name>

Look for the pod with the highest ordinal that is not Ready. Check its status in detail:

kubectl describe pod <statefulset-name>-<ordinal> -n <namespace>

Note the conditions section and recent events. The "Waiting for ordinal" message comes from a later pod; find the actual pod that cannot transition to Ready by looking at earlier ordinals.

Examine the logs of the pod preventing others from starting:

kubectl logs <statefulset-name>-0 -n <namespace>  # Check pod-0 if it's blocking
kubectl logs <statefulset-name>-0 -n <namespace> --all-containers=true  # Include init containers
kubectl logs <statefulset-name>-0 -n <namespace> --previous  # If pod crashed and restarted

Look for error messages, exceptions, or timeouts. Common patterns:
- "Connection refused" (service not ready)
- "Timeout" (waiting for dependency)
- Application startup errors
- "OOMKilled" or "Evicted" (resource issues)

Check the StatefulSet definition for readiness probes:

kubectl get statefulset <statefulset-name> -n <namespace> -o yaml | grep -A 10 "readinessProbe"

Common issues:
- initialDelaySeconds too short for app startup time
- Wrong path, port, or scheme for the probe endpoint
- timeoutSeconds too aggressive (default 1s)
- Readiness endpoint returning error due to missing dependencies

Example fix in StatefulSet manifest:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Give app time to start
  periodSeconds: 5
  timeoutSeconds: 2

Apply changes:

kubectl apply -f statefulset.yaml

Get the full pod status:

kubectl get pod <statefulset-name>-0 -n <namespace> -o wide
kubectl get pod <statefulset-name>-0 -n <namespace> -o jsonpath="{.status}"

Look for:
- Container ready: "ContainerReady=True" vs "False"
- Ready condition: "Ready=True" vs "False"
- Actual error in containerStatuses section

Test the readiness endpoint manually if pod is running:

kubectl exec -it <statefulset-name>-0 -n <namespace> -- curl -v http://localhost:8080/health

If this fails, the application isn't responding correctly to readiness checks.

If the StatefulSet uses init containers, check their status:

kubectl describe pod <statefulset-name>-0 -n <namespace>

Look for "Init Containers" section. Each must show "State: Terminated" with "Exit Code: 0". If stuck:

kubectl logs <statefulset-name>-0 -n <namespace> -c <init-container-name>

Common init container issues:
- Downloading configuration files that don't exist
- Waiting for DNS names that haven't resolved
- Network calls timing out

Increase timeouts or fix the network issue, then delete the pod to restart:

kubectl delete pod <statefulset-name>-0 -n <namespace>

Verify the pod can be scheduled:

kubectl describe pod <statefulset-name>-0 -n <namespace> | grep -A 5 "Events"

If you see "Pending" with event "insufficient cpu" or "insufficient memory", check resource requests:

kubectl describe statefulset <statefulset-name> -n <namespace> | grep -A 20 "Limits\|Requests"

Check node capacity:

kubectl describe nodes
kubectl top nodes  # Requires metrics-server

If resource-constrained, either add more nodes or reduce pod requests:

resources:
  requests:
    memory: "256Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"
    cpu: "500m"

If pods need to communicate (e.g., database cluster setup), verify connectivity:

kubectl exec -it <statefulset-name>-1 -n <namespace> -- /bin/bash
# Inside pod, test connection to earlier pod:
nslookup <statefulset-name>-0.<headless-service-name>.<namespace>.svc.cluster.local
telnet <statefulset-name>-0.<headless-service-name>.<namespace>.svc.cluster.local 5432  # For database

Verify headless Service exists and targets the StatefulSet:

kubectl get svc <headless-service-name> -n <namespace> -o yaml
kubectl get endpoints <headless-service-name> -n <namespace>

If DNS or connectivity fails, check CNI plugin and network policies:

kubectl get pods -n kube-system -l tier=cni  # Check CNI pods
kubectl get networkpolicies -n <namespace>

If the blocking pod is slow but eventually becomes healthy, temporarily relax readiness requirements:

kubectl patch statefulset <statefulset-name> -n <namespace> -p '{"spec": {"template": {"spec": {"containers": [{"name": "<container-name>", "readinessProbe": {"initialDelaySeconds": 60, "timeoutSeconds": 5, "periodSeconds": 10}}]}}}}'

Or edit directly:

kubectl edit statefulset <statefulset-name> -n <namespace>

Increase initialDelaySeconds and timeoutSeconds. This is temporary; investigate root cause in parallel.

If strict pod ordering isn't necessary for your application, change to Parallel policy:

kubectl patch statefulset <statefulset-name> -n <namespace> -p '{"spec": {"podManagementPolicy": "Parallel"}}'

With Parallel, all pods start simultaneously regardless of Ready state. Useful for stateless workloads or when pod dependencies are handled by the application, not Kubernetes.

Modify manifest:

spec:
  podManagementPolicy: Parallel
  # ... rest of spec

Warning: Use only if your application doesn't require strict initialization ordering. Most stateful databases (MySQL, PostgreSQL, Cassandra, etc.) require OrderedReady.