容器网络
本文学习总结自极客时间 深入剖析Kubernetes。
单宿主机容器网络互通
容器通过Veth Pair连接到docker0网桥上，实现了容器与容器之间，容器与宿主机之间的网络互通。
- Veth: virtual Ethernet devices
- Veth Pair: 一对虚拟以太网设备，可以看作现实生活中的网线，能在不同namespace下传输流量
YouTube视频：Linux VETH Pair - Virtual Ethernet Pair
2个容器之间直接通过Veth Pair可以实现网络互通，但如果有n个容器之间需要互通的话，就可能需要创建n(n-1)/2个Veth Pair，就跟现实生活中需要把很多台计算机实现网络互通一样。
在现实生活中，通常是采用网桥，只需要将每台计算机通过一根网线连接在网桥上，那么计算机之间就可以实现网络互通了。
所以可以通过在操作系统上虚拟出一个网桥设备，将容器通过Veth Pair连接到网桥上，实现容器之间网络互通。
YouTube视频：Docker Advanced Networking
使用bridge网络的容器，路由表类似这样子：
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
对于172.17.0.0/16网段的路由是一条直连规则，凡是匹配到这条规则的IP包，应该经过eth0网卡，通过二层网络直接发往目的主机，因为当前主机和目的主机连接在同一个网桥上。而对于其他IP包，则需要发给网关，网关会根据自己的路由信息对数据包进行转发。
跨宿主机容器网络互通
Overlay Network（覆盖网络）：通过软件构建一个覆盖宿主机网络之上的、可以把所有容器连通在一起的虚拟网络。
Flannel UDP
flannel0：Tunnel设备，一种工作在三层的虚拟网络设备，在操作系统内核和用户应用程序之间传递IP包。
每台宿主机上的所有容器会被分配到一个子网中。
flanneld进程在处理fannel0传入的IP包时，就可以根据目的IP地址，匹配到对应的子网，找到这个子网对应的宿主机的IP地址，将IP包直接封装在UDP包里，发给对应的宿主机。
该模式的性能问题在于多了4次用户态和内核态之间的数据拷贝：
Flannel VXLAN
VXLAN：Virtual Extensible LAN（虚拟可扩展局域网），是 Linux 内核本身就支持的一种网络虚似化技术。VXLAN 可以完全在内核态实现UDP模式的封装和解封装的工作。
VTEP: VXLAN Tunnel End Point（虚拟隧道端点），在内核态进行封装和解封装，对象是二层数据帧。
VXLAN 模式组建的覆盖网络，其实就是一个由不同宿主机上的 VTEP 设备，也就是 flannel.1 设备组成的虚拟二层网络。对于 VTEP 设备来说，它发出的“内部数据帧”就仿佛是一直在这个虚拟的二层网络上流动。这，也正是覆盖网络的含义。
Flannel host-gw
在宿主机路由表里，将每个 Flannel 子网的“下一跳”，设置成了该子网对应的宿主机的 IP 地址。该模式要求集群宿主机之间是二层连通的。
Calico
不同于 Flannel 通过 Etcd 和宿主机上的 flanneld 来维护路由信息的做法，Calico 项目使用了BGP来自动地在整个集群中分发路由信息。
BGP 的全称是 Border Gateway Protocol，即：边界网关协议。它是一个 Linux 内核原生就支持的、专门用在大规模数据中心里维护不同的“自治系统”之间路由信息的、无中心的路由协议。
自治系统，指的是一个组织管辖下的所有 IP 网络和路由器的全体。两个自治系统里的主机，要通过 IP 地址直接进行通信，我们就必须使用路由器把这两个自治系统连接起来。
边界网关：把自治系统连接在一起的路由器。它跟普通路由器的不同之处在于，它的路由表里拥有其他自治系统里的主机路由信息。
在使用了 BGP 之后，你可以认为，在每个边界网关上都会运行着一个小程序，它们会将各自的路由表信息，通过 TCP 传输给其他的边界网关。而其他边界网关上的这个小程序，则会对收到的这些数据进行分析，然后将需要的信息添加到自己的路由表里。
除了对路由信息的维护方式之外，Calico 项目与 Flannel 的 host-gw 模式的另一个不同之处，就是它不会在宿主机上创建任何网桥设备。
Calico 维护的网络在默认配置下，是一个被称为“Node-to-Node Mesh”的模式。这时候，每台宿主机上的 BGP Client 都需要跟其他所有节点的 BGP Client 进行通信以便交换路由信息。但是，随着节点数量 N 的增加，这些连接的数量就会以 N²的规模快速增长，从而给集群本身的网络带来巨大的压力。
所以，Node-to-Node Mesh 模式一般推荐用在少于 100 个节点的集群里。而在更大规模的集群中，你需要用到的是一个叫作 Route Reflector 的模式。
在这种模式下，Calico 会指定一个或者几个专门的节点，来负责跟所有节点建立 BGP 连接从而学习到全局的路由规则。而其他节点，只需要跟这几个专门的节点交换路由信息，就可以获得整个集群的路由规则信息了。
这些专门的节点，就是所谓的 Route Reflector 节点，它们实际上扮演了“中间代理”的角色，从而把 BGP 连接的规模控制在 N 的数量级上。
Calico 要求集群宿主机之间是二层连通的，如果要实现三层连通的宿主机之间的容器网络互联，就需要打开Calico IPIP模式。
Calico 使用的这个 tunl0 设备，是一个 IP 隧道（IP tunnel）设备。
在上面的例子中，IP 包进入 IP 隧道设备之后，就会被 Linux 内核的 IPIP 驱动接管。IPIP 驱动会将这个 IP 包直接封装在一个宿主机网络的 IP 包中，如下所示：
当 Calico 使用 IPIP 模式的时候，集群的网络性能会因为额外的封包和解包工作而下降。在实际测试中，Calico IPIP 模式与 Flannel VXLAN 模式的性能大致相当。所以，在实际使用时，如非硬性需求，建议将所有宿主机节点放在一个子网里，避免使用 IPIP。
避免使用 Calico IPIP 模式的方案：
- 所有宿主机都跟宿主机网关建立 BGP Peer 关系，要求宿主机网关必须支持一种叫作 Dynamic Neighbors 的 BGP 配置方式。这是因为，在常规的路由器 BGP 配置里，运维人员必须明确给出所有 BGP Peer 的 IP 地址。考虑到 Kubernetes 集群可能会有成百上千个宿主机，而且还会动态地添加和删除节点，这时候再手动管理路由器的 BGP 配置就非常麻烦了。而 Dynamic Neighbors 则允许你给路由器配置一个网段，然后路由器就会自动跟该网段里的主机建立起 BGP Peer 关系。
- 使用一个或多个独立组件负责搜集整个集群里的所有路由信息，然后通过 BGP 协议同步给网关。在大规模集群中，Calico 本身就推荐使用 Route Reflector 节点的方式进行组网。所以，这里负责跟宿主机网关进行沟通的独立组件，直接由 Route Reflector 兼任即可。这种情况下网关的 BGP Peer 个数是有限并且固定的。所以我们就可以直接把这些独立组件配置成路由器的 BGP Peer，而无需 Dynamic Neighbors 的支持。这些独立组件的工作原理也很简单：它们只需要 WATCH Etcd 里的宿主机和对应网段的变化信息，然后把这些信息通过 BGP 协议分发给网关即可。
三层网络方案和”隧道模式”方案的异同
- 相同：都实现了跨宿主机容器的三层连通。
- 不同：三层网络方案通过配置下一跳主机的路由规则来实现连通，”隧道模式”方案通过在IP包外再封装一层UDP包来实现连通。
- 三层网络方案：Flannel host-gw、Calico
- 优点：少了封包和解包的过程，性能高
- 缺点：需要想办法维护路由规则
- “隧道模式”方案：Flannel UDP、Flannel VXLAN、Calico IPIP
- 优点：简单，大部分工作可以由Linux 内核的模块实现
- 缺点：性能低