Kubernetes probe defaults treat a 40-second tool call as a hang

A liveness probe is a loop in the kubelet. It opens a connection to /health every periodSeconds, waits timeoutSeconds, and counts consecutive failures. At the defaults the dev.to post quotes, periodSeconds: 10 with failureThreshold: 3, three misses inside roughly 30 seconds restart the container ^[9]. Whether that fires depends on what your /health handler does while the process is awaiting a tool call. If it blocks behind the in-flight call, the kubelet cannot tell a busy agent from a dead one, and it kills the container in the middle of a 40-second tool call ^[2].

Raising the cadence buys less than it looks like it does. The post's suggested liveness block, periodSeconds: 15 with failureThreshold: 3, tolerates about 45 seconds of true unresponsiveness ^[10], fifteen seconds more than the default ^[17]. The 40-second call in its own example clears 45 and fails 30 ^[20]. Two of them in sequence fail both. So the fix sits in the handler. /health should confirm only that the event loop is running and never block on the status of an in-progress tool call, while /ready answers whether the pod can accept new work right now ^[11]. At periodSeconds: 5 and failureThreshold: 2, a pod that flips /ready to failing leaves the endpoint list in about ten seconds ^[18].

Scaling fails on units. A CPU-driven autoscaler compares average utilisation across pods against a target, and one agent request calling six tools in sequence presents as load; the post describes five replicas arriving in response ^[3]. The conversation context is carried in the pod handling that chain ^[7], so the new replicas serve only new requests ^[19].

Any comparison like the post's is a claim about a particular request shape ^[5]. For its numbers to transfer, your agent request has to look like its second diagram: duration in seconds to minutes, compute proportional to reasoning depth and tool fan-out, context carried across the whole chain ^[7]. A single completion call that returns in two seconds has the first shape, bounded latency and no state between requests ^[6], and the defaults are fine on it. The outcome signal breaks either way. An agent that loops on a tool, calls the wrong one, or returns a plausible but incorrect result still answers HTTP 200, and the infrastructure layer cannot tell a correct run from an incorrect one ^[8].

I would act on the session change first. MCP's original design required persistent sessions pinned between a client and a specific server instance, which forced teams into sticky routing and shared session stores just to keep a conversation coherent across requests ^[13]. The July 2026 specification revision removed the protocol-level session. Any request can land on any server instance, and an application that needs to carry state mints an explicit handle and passes it back as an ordinary argument ^[14]. The post calls that the removal of an entire category of infrastructure workaround ^[15]. Something in the application now issues that handle, checks it, and expires it.

The post gives no failure rate and no deployment name, and it does not say what crossed between the two sessions that shared a Kubernetes Service ^[21][4]. Its argument runs off shipped defaults, which any team can check against its own manifests. A2A reached v1.0 in early 2026, and the post's design point about it is that agents calling each other have different routing, identity and isolation requirements than a single orchestrator calling tools over MCP, with both patterns in production ^[16].