When linkerd control plane is not available, does the injected pod mutual calls across the namespace fail?

[eddielishan]

When linkerd control plane is not available, does the injected pod mutual calls across the namespace fail?

emojivoto namespace pod curl books.booksapp
root@web-76b65f6fbc-6dmmb:/usr/local/bin# curl http://books.booksapp:7002/books.json
curl: (56) Recv failure: Connection reset by peer

[olix0r]

There's anything special about whether connections cross namespaces: Linkerd proxies cache clients that are actively receiving traffic and are dropped when there are no active connections for some period of time. If you are attempting to initiate a new connection--i.e., build a new client--while the control plane will down, the proxy is unable to discover information about the destination and fails to proxy the connection because it can't determine whether mTLS should be used, and failing closed is a safer default than failing open. It's akin to the cluster's DNS servers being down.

In production environments, we recommend deploying at least 3 replicas of the control plane components to help ensure availability.

[eddielishan]

@olix0r
Thank you for your reply
I don't know why, I tested not quite the same result as you replied. When linkerd control plane is not available, When the original service is not restarted, the injected pod mutual calls across the namespace is failed, but the same namespace access is normal... Is there any other problems?