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 hostnetwork option #49
expose hostnetwork option #49
Conversation
Hi @rbtr Thanks for your contribution.
Regarding the hostNetwork, what is your use case? I am closing this PR because affinity and env have already been implemented. Could you please open an issue to start a discussion about the hostNetwork. We need to understand the use case behind the needs to bind traefik to node ports 80/443. Thanks |
@rbtr After a discussion with the Traefik team we have decided to reopen this PR. |
@rbtr Could you please rebase your PR |
adds hostNetwork, affinity, and env customization to the values.yaml in the deployment template, adds hostNetwork, affinity (more on this below) and env templates hooks. in the deployment template, adds logic that checks if: - the pod is running in the host network - the deployment has >1 replica specified - there are no antiaffinity rules specified and injects a default pod anti-affinity that will schedule traefik pods on individual nodes (kind of like daemonset behavior, except only on as many nodes as replicas requested)
@mmatur rebased and cleaned up per review comments! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rbtr Thanks
Could you please update the Chart version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
What:
adds hostNetwork and an example anti-affinity for hostnetwork compatibility.
Why:
I want traefik to bind to the node ports 80/443, but a NodePort service can only bind to ports >3000 (unless k8s is specifically configured to allow a different NodePort range which is not recommended). The only option in this situation is to run the pod in the host network namespace...
But if the pod is running in the host network, we can't schedule more than one per node, because the port will become in-use as soon as the first pod starts, so it is necessary to spread them out among the nodes when we have more than one pod replica.
Closes #99