参考

• 《深入剖析 Kubernetes（张磊）》

• 补充 详解 Calico 三种模式（与 Fannel 网络对比学习）_calico vxlan-CSDN博客

容器网络

容器的网络栈

• 每个容器有自己的 net namespace

  • net namespace 可以称之为网络栈
  • 所谓“网络栈”，就包括了：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则。对于一个进程来说，这些要素，其实就构成了它发起和响应网络请求的基本环境。

• 直接使用宿主机的网络栈（–net=host），即：不开启 Network Namespace

  • $ docker run –d –net=host --name nginx-host nginx
    

  • 这个容器启动后，直接监听的就是宿主机的 80 端口。

  • 可能带来的问题 —— 容器需要的端口与宿主机的㐰冲突

    • 像这样直接使用宿主机网络栈的方式，虽然可以为容器提供良好的网络性能，但也会不可避免地引入共享网络资源的问题，比如端口冲突。所以，在大多数情况下，我们都希望容器进程能使用自己 Network Namespace 里的网络栈，即：拥有属于自己的 IP 地址和端口。

• 这个被隔离的容器进程，该如何跟其他 Network Namespace 里的容器进程进行交互呢？

  • 在 Linux 中，能够起到虚拟交换机作用的网络设备，是网桥（Bridge）。它是一个工作在数据链路层（Data Link）的设备，主要功能是根据 MAC 地址学习来将数据包转发到网桥的不同端口（Port）上。
  • 可以把容器视为独立的主机，网桥视为交换机
  • Docker 项目会默认在宿主机上创建一个名叫 docker0 的网桥，凡是连接在 docker0 网桥上的容器，就可以通过它来进行通信。
  • 如何把这些容器“连接”到 docker0 网桥上呢？ —— 如何把这些容器“连接”到 docker0 网桥上呢？
  • veth-pair 可以视为网线
    • 它被创建出来后，总是以两张虚拟网卡（Veth Peer）的形式成对出现的。并且，从其中一个“网卡”发出的数据包，可以直接出现在与它对应的另一张“网卡”上，哪怕这两个“网卡”在不同的 Network Namespace 里。
    • Veth Pair 常常被用作连接不同 Network Namespace 的“网线”。

不同容器间的通信

• 不同容器之间如何通信？

  • docker 为 container-1 创建的 veth pair，一端插在容器 net namespace 内，名称为 eth0；另一端插在宿主机 net namespace 内的 docker0 网桥上，名称为 vethXXXXXX —— 分为在容器内和宿主机内执行ifconfig命令可查看到这些设备

  • container-1 想要发送数据给 container-2，该怎么走？

    1. 首先 container-1 会查自己容器 net namespace 内的本地路由表 —— 通过route命令可查看

    2. container-1 根据路由表的匹配规则，知道要通过 eth0 设备，发送到网关 0.0.0.0

       • $ route
         Kernel IP routing table
         Destination Gateway Genmask Flags Metric Ref Use Ifacedefault 
         172.17.0.1 0.0.0.0 UG 0 0 0 eth0
         172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
         

       • 【网关0.0.0.0】意味着这是一条直连规则

         • 即：凡是匹配到这条规则的 IP 包，应该经过本机的 eth0 网卡，通过二层网络直接发往目的主机。

    3. 而目前 container-1 只知道目的 container-2 的 ip 地址，但不知道其对应的 mac 地址

       • 因此便通过自身的 eth0 设备发送一个 ARP 查询包（查询 container-2 ip 对应的 mac 地址）

    4. 发出的 ARP 包，通过 veth 设备，传输到了 docker0 网桥上，docker0 会将其广播到所有插到自身网桥上的 veth 设备，此时 container-2 发现查询是自身，因此相应了自身的 mac 地址

       • 一旦一张虚拟网卡被“插”在网桥上，它就会变成该网桥的“从设备”。从设备会被“剥夺”调用网络协议栈处理数据包的资格，从而“降级”成为网桥上的一个端口。而这个端口唯一的作用，就是接收流入的数据包，然后把这些数据包的“生杀大权”（比如转发或者丢弃），全部交给对应的网桥。
       • 在收到这些 ARP 请求之后，docker0 网桥就会扮演二层交换机的角色，把 ARP 广播转发到其他被“插”在 docker0 上的虚拟网卡（vethxxx）上。

    5. 有了目标 container-2 的 mac 地址后，container-1 便可以正常封包将数据发给 container-2 了

       • docker0 处理转发的过程，则继续扮演二层交换机的角色。此时，docker0 网桥根据数据包的目的 MAC 地址，在它的 CAM 表（即交换机通过 MAC 地址学习维护的端口和 MAC 地址的对应表）里查到对应的端口（Port）为：vethb4963f3，然后把数据包发往这个端口。

       • 需要注意的是，在实际的数据传递时，上述数据的传递过程在网络协议栈的不同层次，都有 Linux 内核 Netfilter 参与其中。所以，如果感兴趣的话，你可以通过打开 iptables 的 TRACE 功能查看到数据包的传输过程，具体方法如下所示：

       • # 在宿主机上执行
         $ iptables -t raw -A OUTPUT -p icmp -j TRACE
         $ iptables -t raw -A PREROUTING -p icmp -j TRACE
         

  • 

• 不同主机的容器如何通信？

  • 答 —— overlay 网络
  • 简单来说，就是在现在【源container ip，目的container ip】上，通过 SNAT、DNAT、路由表等，进行封装，使其能在真正的物理网络上通行
  • 简单理解为，ip 头为【源container ip，目的container ip】的容器包视为数据段，进行再次 ip 头封装等，实现可以到达对面的宿主机
  • 此部分简单了解就行，不看也行，后面也有详解
  • 在 Docker 的默认配置下，不同宿主机上的容器通过 IP 地址进行互相访问是根本做不到的。
    • 在 Docker 的默认配置下，不同宿主机上的容器通过 IP 地址进行互相访问是根本做不到的。（flannel、calico 等）

常用网络命令

• 常用命令总结

# 可以看到当前 net namespace 下的所有网络设备，veth pair 、bridge、宿主机网卡 eth0 等
$ ifconfig
# 推荐使用ip link show来看veth-eth映射关系
# 查看 bridge 上插入的 veth pair 设备
$ brctl show
# 查看路由表
$ route

# 在宿主机上
$ docker exec -it nginx-1 /bin/bash
# 在容器里
root@2b3c181aecf1:/# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.2  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::42:acff:fe11:2  prefixlen 64  scopeid 0x20<link>
        ether 02:42:ac:11:00:02  txqueuelen 0  (Ethernet)
        RX packets 364  bytes 8137175 (7.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 281  bytes 21161 (20.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0

• 找 docker 和 宿主机上 veth 设备的关系

#看到有位同学问怎么找 docker 和 宿主机上 veth 设备的关系，学完后我也有这个疑问，查了一下，
# 结论是没有命令可以直接查到。但是可以查看 container 里的 eth0 网卡的 iflink 找到对应关系。
# 方法1
# 宿主机上
$ ip link 
......
9: veth0e9cd8d@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether 6a:fb:59:e5:7e:da brd ff:ff:ff:ff:ff:ff link-netnsid 1

# 容器内
$ sudo docker exec -it e151 bash
root@e1517e9d9e1a:/# cat /sys/class/net/eth0/iflink 
9

# 这样就可以确定 container e1517e9d9e1a 在物理机上对应的 veth pair 是 veth0e9cd8d 了。

# 这种方式需要登录到 docker 里执行命令，不是所有的容器都能这么做，不过 github 上有人专门做了个脚本来用实现这个功能，可以参考一下：
# https://github.com/micahculpepper/dockerveth

# 方法2
容器内执行 ethtool -S eth0 | grep peer_ifindex, 可以看到对端序列号，
然后宿主机上 ip link | grep 那个序列号也可以找到

总结

设备	非专业术语	作用
Docker0	网桥	理解为二层交换机，处理包头为 mac 的数据包
net namespace	网络栈	存储用于通信的网络设备和规则等（网卡、路由表、iptables规则等）
		一个 net namespace 可以简单理解为，一个主机
		–net=host，表示容器共享宿主机的网络栈（此时可理解为两个人共用一套设备），此时可提高通信效率，但可能会端口冲突
		docker run –d –net=host --name nginx-host nginx
veth pair	网线	用于联通不同的 net namespace，可以理解为连接两个主机间的网线
		veth-pair 会生成两个 veth 设备，其可以理解为两个虚拟网卡
		其中一个，一般放在宿主机 net namespace 内，插在 docker0 网桥上，名称为 vethXXXX
		另一个，一般放在容器 net namespace 内，也就是插在容器内，名称为 eth0（一般表示这是容器的主网卡）
本机通信路径		container-1 发包给 container-2：首先 container-1 不知道 container-2，通过路由表查询， 需要通过 eth0 网卡（也就是veth pair 设备的一端）发包，之后container-1 发送 ARP 数据包 （用于查询container-2 mac 地址），通过 veth 转发到 docker0 网桥上，网桥会广播给所有插在自身的 veth 网卡， 匹配的 container-2 会进行相应，返回 mac地址；之后 container-1 封装二层数据包（包头为 mac 地址），然后通过 veth 发送到 docker0 上，docker0 网桥将其转发到 container-2

flannel

udp 模式

Flannel0	Tunnel设备 （网络设备）	在 Linux 中，TUN 设备是一种工作在三层（Network Layer）的虚拟网络设备。TUN 设备的功能非常简单，即：在操作系统内核和用户应用程序之间传递 IP 包
		以 flannel0 设备为例：像上面提到的情况，当操作系统将一个 IP 包发送给 flannel0 设备之后，flannel0 就会把这个 IP 包，交给创建这个设备的应用程序，也就是 Flannel 进程。这是一个从内核态（Linux 操作系统）向用户态（Flannel 进程）的流动方向。
		以 flannel0 设备为例：像上面提到的情况，当操作系统将一个 IP 包发送给 flannel0 设备之后，flannel0 就会把这个 IP 包，交给创建这个设备的应用程序，也就是 Flannel 进程。这是一个从内核态（Linux 操作系统）向用户态（Flannel 进程）的流动方向。
flanneld	守护程序（用户态程序，是个进程）	维护容器 IP 子网范围和 Node 的对应关系，保存在 etcd 中
		事实上，在由 Flannel 管理的容器网络里，一台宿主机上的所有容器，都属于该宿主机被分配的一个“子网”。在我们的例子中，Node 1 的子网是 100.96.1.0/24，container-1 的 IP 地址是 100.96.1.2。Node 2 的子网是 100.96.2.0/24，container-2 的 IP 地址是 100.96.2.3。
		flanneld 进程在处理由 flannel0 传入的 IP 包时，就可以根据目的 IP 的地址（比如 100.96.2.3），匹配到对应的子网（比如 100.96.2.0/24），从 Etcd 中找到这个子网对应的宿主机的 IP 地址是 10.168.0.3
		每台宿主机上的 flanneld，都监听着一个 8285 端口，所以 Node1 flanneld 只要把 UDP 包发往 Node 2 的 8285 端口即可 （涉及到端口通信，当然需要用到传输层协议，此处用的就是 UDP）
docker0	网桥	docker0 网桥的地址范围必须是 Flannel 为宿主机分配的子网。这个很容易实现，以 Node 1 为例，你只需要给它上面的 Docker Daemon 启动时配置如下所示的 bip 参数即可：
		$ FLANNEL_SUBNET=100.96.1.1/24 $ dockerd --bip=$FLANNEL_SUBNET …
通信过程		Container-1 向 container-2 发包【源container-1 ip，目的container-2 ip】
		1. 首先 container-1 通过 veth-pair，将数据包从 container（容器） net namespace 传输到 host（宿主机） net namespace 中，也就是数据包到达了 docker0 网桥上【这是一个从用户态（容器内应用程序）向内核态（Linux操作系统的流动方向】
		2. 接下来根据 host net namespace 中的路由表，发现 container-2 ip 不在当前 node 的 docker0 网桥上，因此匹配了另一条路由规则，发送给 flannel0 设备
		3. fannel0 设备就会把这个 IP 包，交给创建这个设备的应用程序，也就是 flanneld 进程。【这是一个从内核态（Linux 操作系统）向用户态（flanneld 进程）的流动方向。
		4. flanneld 通过查询 etcd 知道，该 container-2 ip 属于 Node2 的管辖范围，因此发送到 Node2 的 flanneld 程序（也就是8285端口），才能顺利的完成解包，所以又进行 UDP 封包（可指定端口），并通过宿主机 eth0 端口发出【这是一个从用户态（flanneld 进程）向内核态（Linux 操作系统）的流动方向。】
		5. 最后变为如下形式【mac包头（源node1，目的node2】【ip头（源node1，目的node2）】【udp头（源端口8285，目的端口8285】【udp数据帧（也就是容器包【源container-1 ip，目的container-2 ip】【要发送的数据】）
TUN 设备工作原理	也是 udp 模式废弃原因	UDP 模式有严重的性能问题，所以已经被废弃了。通过我上面的讲述，你有没有发现性能问题出现在了哪里呢？
		实际上，相比于两台宿主机之间的直接通信，基于 Flannel UDP 模式的容器通信多了一个额外的步骤，即 flanneld 的处理过程。而这个过程，由于使用到了 flannel0 这个 TUN 设备，仅在发出 IP 包的过程中，就需要经过三次用户态与内核态之间的数据拷贝
		第一次，用户态的容器进程发出的 IP 包经过 docker0 网桥进入内核态； 第二次，IP 包根据路由表进入 TUN（flannel0）设备，从而回到用户态的 flanneld 进程； 第三次，flanneld 进行 UDP 封包之后重新进入内核态，将 UDP 包通过宿主机的 eth0 发出去。
		可以看到，Flannel 进行 UDP 封装（Encapsulation）和解封装（Decapsulation）的过程，也都是在用户态完成的。在 Linux 操作系统中，上述这些上下文切换和用户态操作的代价其实是比较高的，这也正是造成 Flannel UDP 模式性能不好的主要原因。
		在进行系统级编程的时候，有一个非常重要的优化原则，就是要减少用户态到内核态的切换次数，并且把核心的处理逻辑都放在内核态进行。这也是为什么，Flannel 后来支持的VXLAN 模式，逐渐成为了主流的容器网络方案的原因。

• flannel UDP 模式通信
  • Flannel UDP 模式提供的其实是一个三层的 Overlay 网络，即：它首先对发出端的 IP 包进行 UDP 封装，然后在接收端进行解封装拿到原始的 IP 包，进而把这个 IP 包转发给目标容器。这就好比，Flannel 在不同宿主机上的两个容器之间打通了一条“隧道”，使得这两个容器可以直接使用 IP 地址进行通信，而无需关心容器和宿主机的分布情况。

• TUN 设备工作原理
  • 相比于两台宿主机之间的直接通信，基于 Flannel UDP 模式的容器通信多了一个额外的步骤，即 flanneld 的处理过程。而这个过程，由于使用到了 flannel0 这个 TUN 设备，仅在发出 IP 包的过程中，就需要经过三次用户态与内核态之间的数据拷贝
  • 我们在进行系统级编程的时候，有一个非常重要的优化原则，就是要减少用户态到内核态的切换次数，并且把核心的处理逻辑都放在内核态进行。这也是为什么，Flannel 后来支持的VXLAN 模式，逐渐成为了主流的容器网络方案的原因。

vxlan 模式

首先简单了解
隧道通信		就是交给隧道通信设备，自动完成了数据包的跨Node传输，类似覆盖一层“网桥”似的，连接两个Node 所以这个“覆盖的虚拟网桥”，也就是在虚拟的容器网络上覆盖一层网络，称之为 Overlay 网络
		我们知道，容器的 IP 是“虚拟IP”，也就是只限本机上使用（同一 Node 上内的容器通信） 出了所在 Node 到真实物理网络中，所有Node 都不认识，也就是不能到其他网络
		而在不同 Node 上“覆盖的虚拟网桥”，可将容器 IP 包，传输到不同 Node 上，实现了跨节点通信
flannel UDP 模式	三层 Overlay	传输的是 IP 包，也就是传给隧道设备的是 IP 包，关注 IP地址
flannel VXLAN 模式	二层 Overlay	传输的是 MAC 包，也就是传给隧道设备的是 MAC 包，关注 MAC 地址
Fannel VXLAN 模式	引入原因	Flannel 进行 UDP 封装（Encapsulation）和解封装（Decapsulation）的过程，也都是在用户态完成的。 在 Linux 操作系统中，上述这些上下文切换和用户态操作的代价其实是比较高的，这也正是造成 Flannel UDP 模式性能不好的主要原因
		VXLAN 可以完全在内核态实现上述封装和解封装的工作，从而通过与前面相似的“隧道”机制，构建出覆盖网络（Overlay Network）。
VXLAN		VXLAN 的覆盖网络的设计思想是：在现有的三层网络之上，“覆盖”一层虚拟的、由内核 VXLAN 模块负责维护的二层网络， 使得连接在这个 VXLAN 二层网络上的“主机”（虚拟机或者容器都可以）之间，可以像在同一个局域网（LAN）里那样自由通信。当然，实际上，这些“主机”可能分布在不同的宿主机上，甚至是分布在不同的物理机房里。
		为了能够在二层网络上打通“隧道”，VXLAN 会在宿主机上设置一个特殊的网络设备作为“隧道”的两端。这个设备就叫作 VTEP，即：VXLAN Tunnel End Point（虚拟隧道端点）。
		VTEP 设备的作用，其实跟前面的 flanneld 进程非常相似。只不过，它进行封装和解封装的对象，是二层数据帧（Ethernet frame）；而且这个工作的执行流程，全部是在内核里完成的（因为 VXLAN 本身就是 Linux 内核中的一个模块）。
		宿主机上的 VTEP 设备都叫作 flannel.1
通信过程		Container-1 向 container-2 发包【源container-1 ip，目的container-2 ip】
		1. 首先容器 IP 包，会通过 veth 到达 host net namespace，之后根据路由表，交由给 flannel.1 VTEP 设备处理 【源container-1 ip，目的container-2 ip】
		2. 之后 flannel.1 设备会根据容器的目的 ip，为其添加上目的 VTEP 设备的 MAC 地址（该信息由 fanneld 进程维护，是个 ARP 表） 每新增一个 Node VTEP 设备，Flannel 网络会将该 Node VTEP 对应的 ARP 记录下放到所有其他 Node 上 【目标 VTEP Mac地址，源 MAC 地址（是变动的）】【源container-1 ip，目的container-2 ip】
		3. 再上面基础上，加上一个特殊的 VXLAN 头，用来表示这个“乘客”实际上是一个 VXLAN 要使用的数据帧。 而这个 VXLAN 头里有一个重要的标志叫作 VNI，它是 VTEP 设备识别某个数据帧是不是应该归自己处理的重要标识。而在 Flannel 中，VNI 的默认值是 1，这也是为何，宿主机上的 VTEP 设备都叫作 flannel.1 的原因，这里的“1”，其实就是 VNI 的值。
		4. Linux 内核会把这个数据帧封装进一个 UDP 包里发出去。 那如何知道，对面 Node IP 地址呢？
		答：FDB（Forwarding Database）的转发数据库，该数据库维护【 目标 VTEP 设备 MAC 地址 — 所在 Node IP】的对应关系。 不难想到，这个 flannel.1“网桥”对应的 FDB 信息，也是 flanneld 进程负责维护的。它的内容可以通过 bridge fdb 命令查看到
		5. 对面 Node 收到包后，根据 VXLAN 头和 VNI 号，知道要转给自己的 flannel.1 设备，从解包后发到目标容器

• flannel vxlan 通信模式

  

• 封帧

  

calico-ipip

在了解了 BGP 之后，Calico 项目的架构就非常容易理解了。它由三个部分组成：

1. Calico 的 CNI 插件。这是 Calico 与 Kubernetes 对接的部分。
2. Felix。它是一个 DaemonSet，负责在宿主机上插入路由规则（即：写入 Linux 内核的 FIB 转发信息库），以及维护 Calico 所需的网络设备等工作。
3. BIRD。它就是 BGP 的客户端，专门负责在集群里分发路由规则信息。

• 除了对路由信息的维护方式之外，Calico 项目与 Flannel 的 host-gw 模式的另一个不同之处，就是它不会在宿主机上创建任何网桥设备。

• 可以看出与 flannel vxlan 的差异

  • 没有网桥
  • 隧道设备不一致
    • flannel 隧道是 TUN 设备类型，是个（Mac 层 tunnel）设备
    • calico 隧道是 tunl0 设备类型，是一个 IP 隧道（IP 层 tunnel）设备
    • 这两个设备类型很相似，但是不同功能
  • 从封包差异可以看出来
    • flannel 需要封装 VTEP 设备 MAC 地址
    • calico 直接在容器 ip 外层，封装一层 Node ip 层，容器数据作为 Node ip 包的 Payload（负载），容器 ip 与 node ip 的映射关系由本地的 Felix 组件负责，不需要 UDP 封包
      • IP 包进入 IP 隧道设备之后，就会被 Linux 内核的 IPIP 驱动接管。IPIP 驱动会将这个 IP 包直接封装在一个宿主机网络的 IP 包中
      • 查本地路由表，可知 目的容器 ip 对应的目的 Node ip
      • 【目的 Node ip、源 tunl0 设备 ip】（【目的容器ip、源容器 ip】【数据】 此部分可视为 Payload）
      • 目的 Node 网络内核栈会使用 IPIP 驱动进行解包，从而拿到原始的 IP 包。然后，原始 IP 包就会经过路由规则和 Veth Pair 设备到达目的容器内部。
      • 在实际测试中，Calico IPIP 模式与 Flannel VXLAN 模式的性能大致相当。

• 封包

host-gw

• 必须二层连通
• Pod 通信时相当于，把对方的宿主机当做网关
  • 本机上会有路由规则： 【对方 Pod IP 段】 —— 【对方主机 MAC 地址】
  • 这样本机 Pod 要发送给对方 Pod，就会直接发给对方主机，对方主机上当然会有自己所有 Pod 的路由信息，这样完成了通信
  • 同样，对方需要发回数据时，也是直接将数据发到本宿主机上，然后转发给对应的 Pod
  • 封装的数据包为 【对方主机mac地址】【Pod IP 地址】【端口】 【数据信息】
    • 因此这样要求必须二层连通，直接可以到达对方宿主机
    • 若是三层，中间的路由器不认识【Pod IP 地址】，也无法解析到【下一跳】，因此【不知道该发到哪】，所以只能二层连通
    • 不过 Calico BGP 解决了此问题，支持 BGP 的路由器中也会存储着 【Pod IP】—— 【宿主机MAC地址】的映射信息
      • 因此知道该如何转发
      • 这个信息的分发和维护，是BGP的内在机制 （好像是 Brid 组件）

flannel

• flannel
  • 

calico

• calico
  • Calico 项目的架构就非常容易理解了。它由三个部分组成
    • Calico 的 CNI 插件。这是 Calico 与 Kubernetes 对接的部分。
    • Felix。它是一个 DaemonSet，负责在宿主机上插入路由规则（即：写入 Linux 内核的 FIB 转发信息库），以及维护 Calico 所需的网络设备等工作。
      • 这里最核心的“下一跳”路由规则，就是由 Calico 的 Felix 进程负责维护的
    • BIRD。它就是 BGP 的客户端，专门负责在集群里分发路由规则信息。
      • 两种模式 Node-to-Node Mesh 和 BGP Route Reflector
      • Calico 维护的网络在默认配置下，是一个被称为“Node-to-Node Mesh”的模式。
      • Node-to-Node Mesh 每台宿主机上的 BGP Client 都需要跟其他所有节点的 BGP Client 进行通信以便交换路由信息。但是，随着节点数量 N 的增加，这些连接的数量就会以 N²的规模快速增长，从而给集群本身的网络带来巨大的压力。就是每个 Node 都要连接其他 N-1 个 Node
      • Node-to-Node Mesh 模式一般推荐用在少于 100 个节点的集群里。而在更大规模的集群中，你需要用到的是一个叫作 Route Reflector 的模式。
      • 在这种模式下，Calico 会指定一个或者几个专门的节点，来负责跟所有节点建立 BGP 连接从而学习到全局的路由规则。而其他节点，只需要跟这几个专门的节点交换路由信息，就可以获得整个集群的路由规则信息了。
    • felix 和 bird 在部署时候，其实统一部署在一个组件内，叫做 calico-node
    • 除了对路由信息的维护方式之外，Calico 项目与 Flannel 的 host-gw 模式的另一个不同之处，就是它不会在宿主机上创建任何网桥设备。
  • 

cni 插件

• 在 k8s 中

  • Kubernetes 是通过一个叫作 CNI 的接口，维护了一个单独的网桥来代替 docker0。这个网桥的名字就叫作：CNI 网桥，它在宿主机上的设备名称默认是：cni0。
  • 以 Flannel 的 VXLAN 模式为例，在 Kubernetes 环境里，它的工作方式跟我们在上一篇文章中讲解的没有任何不同。只不过，docker0 网桥被替换成了 CNI 网桥而已
  • 

• 分类

设备创建类	Main	第一类，叫作 Main 插件，它是用来创建具体网络设备的二进制文件。比如，bridge（网桥设备）、ipvlan、loopback（lo 设备）、macvlan、ptp（Veth Pair 设备），以及 vlan。
ip 分配类	IPAM	第二类，叫作 IPAM（IP Address Management）插件，它是负责分配 IP 地址的二进制文件。 比如，dhcp，这个文件会向 DHCP 服务器发起请求；host-local，则会使用预先配置的 IP 地址段来进行分配。
网络管控类		第三类，是由 CNI 社区维护的内置 CNI 插件。比如：flannel，就是专门为 Flannel 项目提供的 CNI 插件； tuning，是一个通过 sysctl 调整网络设备参数的二进制文件； portmap，是一个通过 iptables 配置端口映射的二进制文件； bandwidth，是一个使用 Token Bucket Filter (TBF) 来进行限流的二进制文件。
		从这些二进制文件中，我们可以看到，如果要实现一个给 Kubernetes 用的容器网络方案，其实需要做两部分工作，以 Flannel 项目为例：
基础网络构建		首先，实现这个网络方案本身。这一部分需要编写的，其实就是 flanneld 进程里的主要逻辑。比如，创建和配置 flannel.1 设备、配置宿主机路由、配置 ARP 和 FDB 表里的信息等等。
容器网络构建		然后，实现该网络方案对应的 CNI 插件。这一部分主要需要做的，就是配置 Infra 容器里面的网络栈，并把它连接在 CNI 网桥上。
cni插件放置		由于 Flannel 项目对应的 CNI 插件已经被内置了，所以它无需再单独安装。 而对于 Weave、Calico 等其他项目来说，我们就必须在安装插件的时候，把对应的 CNI 插件的可执行文件放在 /opt/cni/bin/ 目录下。
cni插件配置文件		flanneld 启动后会在每台宿主机上生成它对应的 CNI 配置文件（它其实是一个 ConfigMap），从而告诉 Kubernetes，这个集群要使用 Flannel 作为容器网络方案。路径 /etc/cni/net.d/
cni配置文件加载		需要注意的是，在 Kubernetes 中，处理容器网络相关的逻辑并不会在 kubelet 主干代码里执行， 而是会在具体的 CRI（Container Runtime Interface，容器运行时接口）实现里完成。对于 Docker 项目来说，它的 CRI 实现叫作 dockershim，你可以在 kubelet 的代码里找到它。
		所以，接下来 dockershim 会加载上述的 CNI 配置文件。
	多个配置文件	需要注意，Kubernetes 目前不支持多个 CNI 插件混用。如果你在 CNI 配置目录（/etc/cni/net.d）里放置了多个 CNI 配置文件的话，dockershim 只会加载按字母顺序排序的第一个 cni 配置文件。
	多个配置插件	另一方面，CNI 允许你在一个 CNI 配置文件里，通过 plugins 字段，定义多个插件进行协作
		比如，在我们上面这个例子里，Flannel 项目就指定了 flannel 和 portmap 这两个插件。 这时候，dockershim 会把这个 CNI 配置文件加载起来，并且把列表里的第一个插件、也就是 flannel 插件，设置为默认插件。而在后面的执行过程中，flannel 和 portmap 插件会按照定义顺序被调用，从而依次完成“配置容器网络”和“配置端口映射”这两步操作。
CNI 插件的工作原理		当 kubelet 组件需要创建 Pod 的时候，它第一个创建的一定是 Infra 容器。 所以在这一步，dockershim 就会先调用 Docker API 创建并启动 Infra 容器，紧接着执行一个叫作 SetUpPod 的方法。 这个方法的作用就是：为 CNI 插件准备参数，然后调用 CNI 插件为 Infra 容器配置网络。
		这里要调用的 CNI 插件，就是 /opt/cni/bin/flannel；而调用它所需要的参数，分为两部分。
	指定动作（创建or删除）	第一部分，是由 dockershim 设置的一组 CNI 环境变量。其中，最重要的环境变量参数叫作：CNI_COMMAND。 它的取值只有两种：ADD 和 DEL。这个 ADD 和 DEL 操作，就是 CNI 插件唯一需要实现的两个方法。 其中 ADD 操作的含义是：把容器添加到 CNI 网络里； DEL 操作的含义则是：把容器从 CNI 网络里移除掉。 而对于网桥类型的 CNI 插件来说，这两个操作意味着把容器以 Veth Pair 的方式“插”到 CNI 网桥上，或者从网桥上“拔”掉。
		接下来，我以 ADD 操作为重点进行讲解。CNI 的 ADD 操作需要的参数包括：容器里网卡的名字 eth0（CNI_IFNAME）、Pod 的 Network Namespace 文件的路径（CNI_NETNS）、容器的 ID（CNI_CONTAINERID）等。这些参数都属于上述环境变量里的内容。其中，Pod（Infra 容器）的 Network Namespace 文件的路径，我在前面讲解容器基础的时候提到过，即：/proc/< 容器进程的 PID>/ns/net。
		除此之外，在 CNI 环境变量里，还有一个叫作 CNI_ARGS 的参数。通过这个参数，CRI 实现（比如 dockershim）就可以以 Key-Value 的格式，传递自定义信息给网络插件。这是用户将来自定义 CNI 协议的一个重要方法。
	补充配置文件（执行哪些cni插件）	第二部分，则是 dockershim 从 CNI 配置文件里加载到的、默认插件的配置信息。
		这个配置信息在 CNI 中被叫作 Network Configuration，它的完整定义你可以参考这个文档。dockershim 会把 Network Configuration 以 JSON 数据的格式，通过标准输入（stdin）的方式传递给 Flannel CNI 插件。
		dockershim 对 Flannel CNI 插件的调用，其实就是走了个过场。Flannel CNI 插件唯一需要做的，就是对 dockershim 传来的 Network Configuration 进行补充。比如，将 Delegate 的 Type 字段设置为 bridge，将 Delegate 的 IPAM 字段设置为 host-local 等。
		Delegate 字段的意思是，这个 CNI 插件并不会自己做事儿，而是会调用 Delegate 指定的某种 CNI 内置插件来完成。

• cni 配置文件

$ cat /etc/cni/net.d/10-flannel.conflist 
{
  "name": "cbr0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

k8s service

• Service 是由 kube-proxy 组件，加上 iptables 来共同实现的。

• Kube-proxy 通过监听 Service 对象的创建，创建出相应的 iptables 规则

  • 如创建一个 3副本的 deployment，并暴露该 deployment 为一个 k8s Service
  • kube-proxy 监听到该 Service 的创建，首先会创建一个 iptables，过滤 IP 包（目的 ip 是该 Service IP，目的端口是该 Service 端口），然后跳转到另一个 iptables 链 A
  • 该 iptables 链有一组 iptables 规则（共三条，对应3个副本），进行随机跳转（各1/3概率选中），选中一条规则，跳转到另一条 iptables链（B 或 C 或 D）
  • 假如上面选中了 iptables 链 B，该链对应了 Pod-1，包含一组操作，进行 DNAT，将上面的 Service IP + Port 替换为 Pod-1 IP + Pod-1 Port，实现真正的流量导向

• 在 Kubernetes 中，Service 和 Pod 都会被分配对应的 DNS A 记录（从域名解析 IP 的记录）。

  • 对于 ClusterIP 模式的 Service 来说（比如我们上面的例子），它的 A 记录的格式是：…svc.cluster.local。当你访问这条 A 记录的时候，它解析到的就是该 Service 的 VIP 地址。
  • 而对于指定了 clusterIP=None 的 Headless Service 来说，它的 A 记录的格式也是：…svc.cluster.local。但是，当你访问这条 A 记录的时候，它返回的是所有被代理的 Pod 的 IP 地址的集合。当然，如果你的客户端没办法解析这个集合的话，它可能会只会拿到第一个 Pod 的 IP 地址。
  • 此外，对于 ClusterIP 模式的 Service 来说，它代理的 Pod 被自动分配的 A 记录的格式是：…pod.cluster.local。这条记录指向 Pod 的 IP 地址。
  • 而对 Headless Service 来说，它代理的 Pod 被自动分配的 A 记录的格式是：…svc.cluster.local。这条记录也指向 Pod 的 IP 地址。
  • 但如果你为 Pod 指定了 Headless Service，并且 Pod 本身声明了 hostname 和 subdomain 字段，那么这时候 Pod 的 A 记录就会变成：pod 的 hostname…svc.cluster.local