<p>I have a kubernetes cluster created using kubadm with 1 master and 2 worker. flannel is being used as the network plugin. Noticed that the docker0 bridge is down on all the worker node and master node but the cluster networking is working fine. Is it by design that the docker0 bridge will be down if we are using any network plugin like flannel in kubernetes cluster?</p>

<pre><code>docker0: &lt;NO-CARRIER,BROADCAST,MULTICAST,UP&gt; mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:ad:8f:3a:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
</code></pre>

Lijo
<p>I am posting a community wiki answer from <a href="https://stackoverflow.com/questions/54102888/what-role-does-network-bridge-docker0-play-in-k8s-with-flannel">this</a> SO thread as I believe it answers your question.</p>
<hr />
<p>There are two network models here Docker and Kubernetes.</p>
<p>Docker model</p>
<blockquote>
<p>By default, Docker uses host-private networking. It creates a virtual bridge, called <code>docker0</code> by default, and allocates a subnet from one of the private address blocks defined in <a href="https://www.rfc-editor.org/rfc/rfc1918" rel="nofollow noreferrer">RFC1918</a> for that bridge. For each container that Docker creates, it allocates a virtual Ethernet device (called <code>veth</code>) which is attached to the bridge. The veth is mapped to appear as <code>eth0</code> in the container, using Linux namespaces. The in-container <code>eth0</code> interface is given an IP address from the bridge’s address range.</p>
<p><strong>The result is that Docker containers can talk to other containers only if they are on the same machine</strong> (and thus the same virtual bridge). <strong>Containers on different machines can not reach each other</strong> - in fact they may end up with the exact same network ranges and IP addresses.</p>
</blockquote>
<p>Kubernetes model</p>
<blockquote>
<p>Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):</p>
</blockquote>
<ul>
<li>all containers can communicate with all other containers without NAT</li>
<li>all nodes can communicate with all containers (and vice-versa) without NAT</li>
<li>the IP that a container sees itself as is the same IP that others see it as</li>
</ul>
<blockquote>
<p>Kubernetes applies IP addresses at the  <code>Pod</code>  scope - containers within a  <code>Pod</code>  share their network namespaces - including their IP address. This means that containers within a  <code>Pod</code>  can all reach each other’s ports on  <code>localhost</code>. This does imply that containers within a  <code>Pod</code>  must coordinate port usage, but this is no different than processes in a VM. This is called the “IP-per-pod” model. This is implemented, using Docker, as a “pod container” which holds the network namespace open while “app containers” (the things the user specified) join that namespace with Docker’s  <code>--net=container:&lt;id&gt;</code>  function.</p>
<p>As with Docker, it is possible to request host ports, but this is reduced to a very niche operation. In this case a port will be allocated on the host  <code>Node</code>  and traffic will be forwarded to the  <code>Pod</code>. The  <code>Pod</code>  itself is blind to the existence or non-existence of host ports.</p>
</blockquote>
<p>In order to integrate the platform with the underlying network infrastructure Kubernetes provide a plugin specification called <a href="https://kubernetes.io/docs/concepts/cluster-administration/networking/" rel="nofollow noreferrer">Container Networking Interface (CNI)</a>. If the Kubernetes fundamental requirements are met vendors can use network stack as they like, typically using overlay networks to support <strong>multi-subnet</strong> and <strong>multi-az</strong> clusters.</p>
<p>Bellow is shown how overlay networks are implemented through <a href="https://github.com/coreos/flannel" rel="nofollow noreferrer">Flannel</a> which is a popular <a href="https://kubernetes.io/docs/concepts/cluster-administration/networking/" rel="nofollow noreferrer">CNI</a>.</p>
<p><a href="https://i.stack.imgur.com/DOxTE.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/DOxTE.png" alt="flannel" /></a></p>
<p>You can read more about other CNI's <a href="https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model" rel="nofollow noreferrer">here</a>. The Kubernetes approach is explained in <a href="https://kubernetes.io/docs/concepts/cluster-administration/networking/" rel="nofollow noreferrer">Cluster Networking</a> docs. I also recommend reading <a href="https://www.contino.io/insights/kubernetes-is-hard-why-eks-makes-it-easier-for-network-and-security-architects" rel="nofollow noreferrer">Kubernetes Is Hard: Why EKS Makes It Easier for Network and Security Architects</a> which explains how <a href="https://github.com/coreos/flannel" rel="nofollow noreferrer">Flannel</a> works, also another <a href="https://medium.com/all-things-about-docker/setup-hyperd-with-flannel-network-1c31a9f5f52e" rel="nofollow noreferrer">article from Medium</a></p>
<p>Hope this answers your question.</p>
