Why don't use host network in docker since docker and kubernetes network is so complex

1/5/2019

Using docker can simplify CI/CD but also introduce the complexity, not everybody able to hold the docker network though selecting open source solutions like Flannel, Calico. So why don't use host network in docker, or what lost if use host network in docker. I know the port conflict is one point, any others?

-- Simon
docker
kubernetes

1 Answer

1/5/2019

There are two parts to an answer to your question:

  1. Pods must have individual, cluster-routable, IP addresses and one should be very cautious about recycling them
  2. You can, if you wish, not use any software defined network (SDN)

So with the first part, it is usually a huge hassle to provision a big enough CIDR to house the address range required for supporting every Pod that is running across every Namespace, and have the space be big enough to avoid recycling addresses for a very long time. Thus, having an SDN allows using "fake" addresses that one need not bother the "real" network with knowing about. No routers need to be updated, no firewalls, no DHCP, whatever.

That said, as with the second part, you don't have to use an SDN: that's exactly what the container network interface (CNI) is designed to paper over. You can use the CNI provider that makes you the happiest, including using static IP addresses or the outer network's DHCP server.

But your comment about port collisions is pretty high up the list of reasons one wouldn't just want to hostNetwork: true and be done with it; I'm actually not certain if the default kubernetes scheduler is aware of hostNetwork: true and the declared ports: on the containers: in order to avoid co-scheduling two containers that would conflict. I guess try it and see, or, better yet, don't try it -- use CNI so the next poor person who tries to interact with your cluster doesn't find a snowflake setup.

-- mdaniel
Source: StackOverflow