Hi all,
We’ve noticed that sometimes the linked proxy is not injected and it seems to be correlated with linkerd-proxy-injector not running at the time application was started. Reading Automatic Proxy Injection | Linkerd seems to indicate it’s configured via a k8s admission hook. I’d like to understand the expected behavior on our side and if we need to change how we deploy.
Thanks,
Arun
Correct, the injector is a mutating webhook. Along with the injector workload itself, there’s linkerd-proxy-injector-webhook-config which is a MutatingWebhookConfiguration resource that binds any pod creation event with the triggering of the webhook. By default, if the injector is not running then the proxy won’t get injected. But you can change that behavior by toggling the webhookFailurePolicy setting from Ignore to Fail, in which case Kubernetes would refuse the creation of Pods if the proxy couldn’t be injected. When Linkerd is installed in high-availability mode it uses this setting. You can read more about it here
Awesome, thank you for clarifying!
@alpeb clarification on this mode - how does this work when bringing up a fresh cluster? I see errors like Failed calling webhook, failing closed linkerd-proxy-injector.linkerd.io: failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=30s": no endpoints available for service "linkerd-proxy-injector" from cloud watch logs. Our EC2 nodes themselves don’t come up Ready
What do you mean your EC2 nodes don’t come up Ready? What do you get from running linkerd check?
I read through the documentation more clearly and excluding the kube-system namespace solved the issue for me. Thank you!