-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Expose /healthz on a different port to allow binding SERVER_HOST to localhost #131
Comments
thank you for raising this incompatibility! 🙂 the provider was designed/released before the official helm chart was finished/released. i'll see to get compatibility w.r.t. the official chart as soon as i get some more time. |
Thank you! No problem, I'm using a workaround for now. I’ve been using the provider for a few months already, and it’s been working great. Thank you for your hard work :) |
i have separated the healthz endpoint now, and also introduced a the functionality is:
the change breaks backwards-compatibility! |
Thanks for quickly fixing it. Just deployed it and it works as expected, thank you! fyi: the |
By design, the external-dns webhook implementation expects that the webhook is available on port 8888. For security reasons, this port should be bound only to localhost to avoid access from other pods.
This will result that the kubelet won't be able to reach /healthz on port 8888. Therefor it would make sense to expose /healthz on port 8080 to be compatible with the offical helm-chart.
Here is the ref from the offical docs:
https://kubernetes-sigs.github.io/external-dns/latest/docs/tutorials/webhook-provider/#implementation-requirements
Additionally:
https://kubernetes-sigs.github.io/external-dns/latest/docs/tutorials/webhook-provider/#metrics-support
Background: As of now, this provider is incompatible with the external-dns helm chart. I did raise an issue to potentially fix this incompatibility, but the non-compatible helm-chart is by design. Hence, this provider needs to be adapted.
kubernetes-sigs/external-dns#4764 (comment)
The text was updated successfully, but these errors were encountered: