CDP GUID Race: The Load Balancer Splits Two Connections
CDP needs two connections to the same Chrome process. A load balancer can split them across pods, and more pods make the failure rate worse.
The Problem
CDP needs two connections to the same Chrome process. A load balancer can split them across pods.
kube-proxy picks a pod per connection. Two connections can land on different pods.
Chrome B does not know GUID-A. It returns 404.
With N pods, the chance both calls hit the same pod is 1/N:
- 3 pods = 33% success
- 6 pods = 17% success
- More pods = worse
Retries can succeed by luck, but each attempt has only a 1/N chance. KEDA adds more pods, and the failure rate grows. This is a routing problem, not a capacity problem.
The fix: resolve the Service hostname to a pod IP once, then use that IP for both calls. See Headless Service.
Retry is not a fix. It is a coin flip. More pods make the coin worse.
References:
Related: see the Headless Service fix for this race, the CDP two-phase connection that makes this possible, or go back to the series overview.