add hostNetwork option

[bbotte]

What does this PR do?

Motivation

More

• [* ] change examples config

Additional Notes

I am in the kubernetes 1.13.3 cluster, the configuration test is https://github.com/containous/traefik/tree/master/examples/k8s. Since the node is not bound to port 80 and 8080, DNS resolves to this node and Can't access. I don't know if it belongs to the correct configuration.

[dduportal]

Hi @bbotte , thank you for this proposal.

Kubernetes uses the concept of "Services" to expose pod's port. It's also the case for Traefik (even as an Ingress controller). In the examples you are trying to use, the "Service" is a kind of "NodePort": https://github.com/containous/traefik/blob/master/examples/k8s/traefik-deployment.yaml#L56 , which binds the ports 80 and 8080 of each Kubernetes "node" to the 8080 and 80 of the "Service". Then, the service takes care of forwarding the requests into Traefik's Pod.

Alternatively, the service of type "LoadBalancer" could be used, depending on the Kubernetes distribution (in Amazon, it would automatically spawn and ELB outside the cluster).

As these are Kubernetes specifics concepts, you should check https://kubernetes.io/docs/tutorials/kubernetes-basics/ which explains better than me these concepts. I would also recommend this great writing from my @geraldcroes : https://medium.com/@geraldcroes/kubernetes-traefik-101-when-simplicity-matters-957eeede2cf8 , which give a good high level cover of the concepts involved in Traefik + Kubernetes.

Unless I'm misunderstanding something, I vote against this change, because it's Kubernetes compliant.

[dtomcej]

Kubernetes "Configuration best practices" state very clearly that using hostports or hostnetworks are to be avoided at all costs. (https://kubernetes.io/docs/concepts/configuration/overview/#services)

If your environment requires them, and you are able to accept the risks involved, you can enable them on your end.

However, we should not be enabling them for the general examples that are going to be widely used.

For these reasons, I am declining this PR, but thank you @bbotte for the contribution!