跨主机容器通信

简介

阅读本文前，建议事先了解下

程序猿视角看网络

《深入剖析kubernetes》笔记

《Container-Networking-Docker-Kubernetes》笔记

计算机发送数据包的基本过程

1. 如果要访问的目标IP跟自己是一个网段的（根据CIDR就可以判断出目标端IP和自己是否在一个网段内了），就不用经过网关了，先通过ARP协议获取目标端的MAC地址，源IP直接发送数据给目标端IP即可。

   |A mac|B mac|A ip|B ip|body| |—|—|—|—|—|

2. 如果访问的不是跟自己一个网段的，就会先发给网关，然后再由网关发送出去，网关就是路由器的一个网口，网关一般跟自己是在一个网段内的，通过ARP获得网关的mac地址，就可以发送出去了

   |A mac|gateway mac|A ip|B ip|body| |—|—|—|—|—|

主机路由对上述过程的影响

$ ip route
...
10.244.1.0/24 via 10.168.0.3 dev eth0

目的 IP 地址属于 10.244.1.0/24 网段的 IP 包，应该经过本机的 eth0 设备发出去（即：dev eth0）；并且，它下一跳地址（next-hop）是 10.168.0.3（即：via 10.168.0.3）。

所谓下一跳地址就是：如果 IP 包从主机 A 发到主机 B，需要经过路由设备 X 的中转。那么 X 的 IP 地址就应该配置为主机 A 的下一跳地址。一旦A配置了下一跳地址，那么接下来，当 IP 包从网络层进入链路层封装成帧的时候，eth0 设备就会使用下一跳地址X_IP对应的 MAC 地址，作为该数据帧的目的 MAC 地址。

|A mac|X mac|A ip|B ip|body| |—|—|—|—|—|

程序猿视角看网络提到：在一个网络数据包传输的过程中（跨网络+路由器），都是源/目标mac在变，源/目标ip都没变。

跨主机通信

there are two ways for Containers or VMs to communicate to each other.

1. In Underlay network approach, VMs or Containers are directly exposed to host network. Bridge, macvlan and ipvlan network drivers are examples of this approach.
2. In Overlay network approach, there is an additional level of encapsulation like VXLAN, NVGRE

overlay 网络

建议参考下 《Container-Networking-Docker-Kubernetes》笔记 一起学习

Flannel 支持三种后端实现，分别是： VXLAN；host-gw； UDP。而 UDP 模式，是 Flannel 项目最早支持的一种方式，却也是性能最差的一种方式。所以，这个模式目前已经被弃用。

我们在进行系统级编程的时候，有一个非常重要的优化原则， 就是要减少用户态到内核态的切换次数，并且把核心的处理逻辑都放在内核态进行 。这也是为什么，Flannel 后来支持的VXLAN 模式，逐渐成为了主流的容器网络方案的原因。用户态内核态的切换成本参见os->c->java 多线程

Network是一组可以相互通信的Endpoints，网络提供connectivity and discoverability（这句话是容器网络的纲，纲举目张）.ip/mac 不是物理机独有的，主机内网络配置 （网卡 + iptables + 路由表 ）加上网关，加上协议，就可以进行网络通信。

我们找一下覆盖网络的感觉

1. 容器网卡不能直接发送/接收数据，而要通过宿主机网卡发送/接收数据
2. 根据第一点，无论overlay 网络的所有方案，交换机都无法感知到容器的mac地址

基于上述两点，容器内数据包从发送方的角度看，无法直接用目标容器mac发送，便需要先发到目标容器所在的宿主机上。于是：

1. overlay 网络主要有隧道 和 路由两种方式，无论哪种方式，“容器在哪个主机上“ 这个信息都必须专门维护
2. 容器内数据包必须先发送目标容器所在的宿主机上，那么容器内原生的数据包便要进行改造（解封包或根据路由更改目标mac）
3. 数据包到达目标宿主机上之后，目标宿主机要进行一定的操作转发到目标容器。

覆盖网络如何解决connectivity and discoverability？connectivity由物理机之间解决，discoverability由veth 与 宿主机eth 之间解决，将上图细化一下

隧道

隧道一般用到了解封包，那么问题来了，谁来解封包？怎么解封包？

flannel + udp 和flannel + vxlan 有一个共性，那就是用户的容器都连接在 docker 0网桥上。而网络插件则在宿主机上创建了一个特殊的设备（UDP 模式创建的是 TUN 设备，VXLAN 模式创建的则是 VTEP 设备），docker0 与这个设备之间，通过 IP 转发（路由表）进行协作。然后， 网络插件真正要做的事情，则是通过某种方法，把不同宿主机上的特殊设备连通，从而达到容器跨主机通信的目的。

VTEP 等内核实现的设备 ，包括vlan、vxlan 等内核实现的机制、协议，其实与一般的网卡、网络协议栈、arp等是一样一样的，只是前者太基础了，进了课本，后者还比较新而已。

路由

路由方案的关键是谁来路由？路由信息怎么感知？

1. flannel + udp

   |host1 mac|host2mac|host1 ip|host2 ip|container1 mac|container2 mac|container1 ip|container2 ip|body| |—|—|—|—|—|—|—|—|—|

2. flannel + vxlan

   |host2mac|host2 ip|container1 mac|container2 mac|container1 ip|container2 ip|body| |—|—|—|—|—|—|—|

3. flannel + host-gw/calico

   |container1 mac|host2 mac|container1 ip|container2 ip|body| |—|—|—|—|—|

underlay 网络

容器网络：盘点，解释与分析

这个归类不好做，有好几个方面：

1. 支持量级的大小
2. 拆封包还是路由
3. 交换机是否有感知
4. 容器所在物理机/宿主机处于一个什么样的角色
5. 是一个L3方案（只要物理机来通就行）还是L2方案，L3网络扩展和提供在过滤和隔离网络流量方面的细粒度控制。
6. 选择网络时，IP地址管理IPAM，组播，广播，IPv6，负载均衡，服务发现，策略，服务质量，高级过滤和性能都是需要额外考虑的。问题是这些能力是否受到支持。即使您的runtime，编排引擎或插件支持容器网络功能，您的基础架构也可能不支持该功能

个人微信订阅号