Linkerd Blog
The Proxy Died First: How Kubernetes Native Sidecars Solve the Service Mesh Shutdown Problem
If you’ve ever operated a service mesh on Kubernetes, you’ve probably seen something like this during a rolling deployment:
Unexpected error occurred: Client 'http://my-api:8080/': Connect Error:
Connection refused: my-api/100.20.100.200:8080
One second your pod is humming along, serving traffic, and talking to its
upstream dependencies through the mesh. The next second it enters Terminating
state, the sidecar proxy exits, and every in-flight request to a dependent
service gets a cold Connection refused in response.
Deep Dive: How linkerd-destination works in the Linkerd Service Mesh
This blog post was originally published on Bezaleel Silva’s Medium blog.
Recently, in our daily operations, we took a deep dive into the inner workings of linkerd-destination, one of the most critical components of the Linkerd control plane.
The motivation was simple: as our cluster grew and traffic increased, the question shifted from “Does Linkerd work?” to “How exactly does it react when everything changes at once?”. Frequent deployments, production scaling, security policies being applied — and at the center of all this, the destination service.