网桥“docker0”在 k8s 和 flannel 中扮演什么角色

k8s版本：v1.10.4
法兰绒版本：v0.10.0
docker版本v1.12.6

当我使用命令时brctl show在节点上，如下所示：

[root@node03 tmp]# brctl show
bridge name bridge id       STP enabled interfaces
cni0        8000.0a580af40501   no      veth39711246
                                        veth591ea0bf
                                        veth5b889fed
                                        veth61dfc48a
                                        veth6ef58804
                                        veth75f5ef36
                                        vethc162dc8a
docker0     8000.0242dfd605c0   no

it shows that the vethXXX are binding on network bridge named cni0, but when i use command `ip addr`,it shows :

[root@node03 tmp]# ip addr |grep veth
6: veth61dfc48a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
7: veth591ea0bf@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
9: veth6ef58804@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
46: vethc162dc8a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
55: veth5b889fed@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
61: veth75f5ef36@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
78: veth39711246@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP

these veth are all binding on `if3` ,but `if3` is not cni0.it is `docker0`

3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 

好像是网桥docker0是没用的，但是ip addr显示所有 veth 设备都绑定在其上。网桥起什么作用docker0用 flannel 在 k8s 中玩？谢谢

这里有Docker和Kubernetes两种网络模型。

Docker模型

默认情况下，Docker 使用主机专用网络。它创建了一个虚拟桥，称为docker0默认情况下，并从定义的私有地址块之一分配子网RFC1918 https://www.rfc-editor.org/rfc/rfc1918为了那座桥。对于 Docker 创建的每个容器，它都会分配一个虚拟以太网设备（称为veth）连接到桥上。 veth 被映射为显示为eth0在容器中，使用 Linux 命名空间。集装箱内的eth0接口被赋予网桥地址范围内的 IP 地址。

结果是 Docker 容器只有在同一台机器上的情况下才能与其他容器通信（因此是相同的虚拟桥）。不同机器上的容器不能互相访问- 事实上，它们最终可能会获得完全相同的网络范围和 IP 地址。

库伯内特模型

Kubernetes 对任何网络实现都提出以下基本要求（禁止任何有意的网络分段策略）：

• 所有容器无需 NAT 即可与所有其他容器通信
• 所有节点都可以与所有容器通信（反之亦然），无需 NAT
• 容器将自己视为的 IP 与其他容器将其视为的 IP 相同

Kubernetes 在以下位置应用 IP 地址Pod范围 - 范围内的容器Pod共享他们的网络命名空间 - 包括他们的 IP 地址。这意味着容器内Pod都可以到达彼此的端口localhost。这确实意味着容器内Pod必须协调端口使用，但这与虚拟机中的进程没有什么不同。这称为“每个 Pod 的 IP”模型。这是使用 Docker 实现的，作为一个“pod 容器”，它保持网络命名空间开放，而“应用程序容器”（用户指定的东西）将该命名空间与 Docker 的连接起来--net=container:<id>功能。

与 Docker 一样，可以请求主机端口，但这被简化为非常小众的操作。在这种情况下，将在主机上分配一个端口Node并且流量将被转发到Pod. The Pod它本身不知道主机端口是否存在。

为了将平台与底层网络基础设施集成，Kubernetes 提供了一个插件规范，称为容器网络接口 (CNI) https://kubernetes.io/docs/concepts/cluster-administration/networking/。如果满足 Kubernetes 的基本要求，供应商可以随意使用网络堆栈，通常使用覆盖网络来支持多子网 and multi-az集群。

下面显示了覆盖网络是如何通过以下方式实现的Flannel https://github.com/coreos/flannel这是一个流行的CNI https://kubernetes.io/docs/concepts/cluster-administration/networking/.

您可以阅读有关其他 CNI 的更多信息here https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model。 Kubernetes 方法的解释见集群组网 https://kubernetes.io/docs/concepts/cluster-administration/networking/文档。我也推荐阅读Kubernetes 很难：为什么 EKS 使网络和安全架构师变得更容易 https://www.contino.io/insights/kubernetes-is-hard-why-eks-makes-it-easier-for-network-and-security-architects这解释了如何Flannel https://github.com/coreos/flannel作品，还有另一个文章来自Medium https://medium.com/all-things-about-docker/setup-hyperd-with-flannel-network-1c31a9f5f52e

希望这能回答您的问题。