Why Your Kubernetes Readiness Probes Are Lying During Rolling Updates
Cloud Native Now, Wednesday, September 16th, 2026
HTTP readiness checks pass before non-HTTP workloads finish registering upstream, so traffic arrives at pods that cannot serve it.
During a rolling update across a Kubernetes-based 5G signaling service every readiness probe passed, new pods came up, old pods drained cleanly, and from Kubernetes' perspective the update was textbook.
The new pods were running but not ready, and nothing in the standard probe configuration knew the difference.
Most readiness probes are HTTP GET checks returning 200, which works for stateless web services where responding to HTTP and being able to handle requests are effectively the same claim.
That assumption cracks for workloads speaking SIP, Diameter or GTP, which must register with upstream systems, complete protocol handshakes and establish peer relationships with gateways and session management functions.