网络桥`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上分配端口,并将流量转发到PodPod本身看不到主机端口的存在或不存在。

为了将平台与基础网络基础架构集成,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。