网络桥`docker0`在法兰绒的k8s中起什么作用

时间：2019-01-09 03:34:52

标签： kubernetes 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
它显示vethXXX绑定在名为cni0的网桥上，但是当我使用命令`ip addr`时，它显示： 
[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
这些veth都绑定在`if3`上，但是`if3`不是cni0。它是`docker0`。 
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN

看来网桥docker0是无用的，但是ip addr显示所有veth设备都已绑定在其上。网桥docker0在带有法兰绒的k8中扮演什么角色？谢谢

2 个答案:

答案 0 :(得分：1)

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

Docker模型

  

默认情况下，Docker使用主机-专用网络。它创建一个虚拟网桥，默认情况下称为docker0，并从RFC1918中定义的专用地址块之一为该网桥分配一个子网。对于Docker创建的每个容器，它都会分配一个虚拟以太网设备（称为veth），该设备连接到网桥。使用Linux名称空间，veth映射为在容器中显示为eth0。容器内eth0界面从网桥的地址范围获得了一个IP地址。

     

结果是Docker容器只能在其他容器位于同一台机器上（也就是同一虚拟网桥）时才能与其他容器通信。 不同计算机上的容器无法互相访​​问-实际上，它们最终可能具有完全相同的网络范围和IP地址。

Kubernetes模型

  

Kubernetes对任何网络实施都施加以下基本要求（除非有任何故意的网络分段策略）：

     
      
  • 所有容器无需NAT即可与所有其他容器通信
    •   
  • 所有节点都可以在不使用NAT的情况下与所有容器通信（反之亦然）
    •   
  • 容器所看到的IP与其他人所看到的IP
    •   
     

Kubernetes在Pod范围内应用IP地址-Pod中的容器共享其网络名称空间-包括其IP地址。这意味着Pod中的容器可以全部到达localhost上彼此的端口。这确实意味着Pod中的容器必须协调端口使用，但这与VM中的进程没有什么不同。这称为“每脚IP”模型。这是使用Docker作为“ pod容器”实现的，该容器使网络名称空间保持打开状态，而“应用容器”（用户指定的内容）通过Docker的--net=container:<id>函数加入该名称空间。

     

与Docker一样，可以请求主机端口，但这被简化为利基操作。在这种情况下，将在主机Node上分配端口，并将流量转发到Pod。 Pod本身看不到主机端口的存在或不存在。

为了将平台与基础网络基础架构集成，Kubernetes提供了一个名为Container Networking Interface (CNI)的插件规范。如果满足Kubernetes的基本要求，则供应商可以根据需要使用网络堆栈，通常使用覆盖网络来支持多子网和多Az 集群。

下方显示了如何通过Flannel（一种流行的CNI）实现重叠式网络。

flannel

您可以阅读有关其他CNI here的更多信息。 Cluster Networking文档中介绍了Kubernetes方法。我还建议您阅读Kubernetes Is Hard: Why EKS Makes It Easier for Network and Security Architects，其中介绍了Flannel的工作原理，以及另外一个article from Medium

希望这能回答您的问题。

答案 1 :(得分：0)

veth接口中的@ if3是在veth对另一端的对等接口索引。在这种情况下，它是Pod网络名称空间内的接口3。如果您执行进入pod并执行ip addr，则可以看到接口3通常是pod内部的eth0。

因此，此接口索引3与本地接口索引无关，在您的情况下，该接口恰好是docker0。

7：veth591ea0bf @ if3：<广播，多播，上，下_UP> mtu 1450 qdisc noqueue master cni0 状态为UP

master cni0显示第ve个接口已连接到主机/根名称空间中的网桥cni0。

相关问题
最新问题