-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[injector] TLS handshake error from masters #351
Comments
Hey @rrondeau Thanks for this issue! Could you share some additional info with us:
Are you running two instances of the connect injector? or is one of them an old instance? |
Is it also possible that there's some health checker hitting this endpoint? |
Also, do you know what has the IP |
Yep this is the ip address of the k8s master api of my GKE cluster.
Nope i dont think so
We are using the last helm version, 0.24.1, and we always had 2 injectors. My values looks like this : https://gist.github.com/rrondeau/cee35a97152737632b0541f56b2648c5 |
Running two injectors is likely the issue here, and I'm surprised you haven't seen problems with it in the past. We don't allow setting The reason that running two or more injectors is not supported is because each instance generates a CA and a cert for the connect-inject webhook. It also makes a call to Kubernetes API to update the configuration for the webhook to set the CA. When you run two instances, each of them will generate its own CA and each will call Kubernetes API to update the config. In this case, only one of the instances will be healthy - the one that called the Kubernetes API last. If you check the logs for the other instance, you will likely see no errors there. There is a workaround though if you want to run two instances: you can provide your own certs to the connect injector by setting the |
ok i dont know how it worked but it did ! Thanks for the help ! |
Sorry about that! We've discovered it recently ourselves and didn't update the docs 😞 Let us know if running only one instance or using the workaround fixes this for you.
Thanks for this PR! We'll likely use it as a base, but we'll also need to fix cert issue. We've already added a separate webhook cert manager (hasn't been merged to master or released yet), but we'll need to hook it up to the injector. No need to update your PR though! sorry again for the incovenience and this requirement not being very clear! |
@ishustava Thanks for all the info and the help, I dont have any TLS error now. Thanks again for all your hard work ! |
Hey @ishustava, I realized that the option to set the number of replicas for the injector has already been implemented.
However, is the support for +1 replicas already ok? Errors like Sorry for sending the message in an issue closed so long ago. I would appreciate it if you could clarify. |
Hi Jean, yes it should be fixed. Are you still seeing that? If so can you please open up a new issue with the relevant fields set and we can look into it! |
@lkysow I have not noticed this error anymore. I just wanted to confirm it. Thanks for the fast response! |
Hi
I upgrade my gke cluster to k8s 1.16 from 1.15 on monday.
The cluster version is the only thing i change from last week.
I never had these logs/problems, we are using consul injection for more than a year.
Since this upgrade, i'm seeing a lot of TLS handshake error in my consul injector logs.
Sample of logs :
My injectors status :
We are using consul 1.8.4 deployed with hashicorp consul-helm chart in a GKE cluster.
Do you have any idea how to resolve this ?
The text was updated successfully, but these errors were encountered: