kubernetes容器底层网络要求

       容器可能部署在云上（公有云或者私有云），也可能部署在数据中心物理宿主机上。云的场景涉及到虚拟网络，数据中心场景就是传统的物理网络，这些环境的网络架构以及底层技术有着很大的差异，这一节分析下。

      不管是云的场景还是传统的数据中心场景，部署容器的宿主机之间的网络，抽象归纳起来需要具备下面的两个条件：

• 可以通过二层交换机、或者三层路由器互相访问。
• 源容器的“原始IP包”，经过中间的各个虚拟的还是物理的设备（veth、bridge、tun等）、节点（交换机、路由器等），不会因为一些原因被修改、丢弃，及时的送到目的容器。

     那么，如何满足这两个条件，即本节所讨论的：容器对底层网络环境的要求。

 

     这第一个条件，比较容易满足：

• 二层互通，宿主机在同一物理网络VLAN、或者同一虚拟网络VXLAN。通过mac地址+vlanID，或者mac地址+vniID寻址转发。
• 三层互通，宿主机在不同网络。物理网络的路由器，云平台虚拟网络的SDN，通过路由、或者流表转发互通。

   

    这第二个条件，“原始IP包”不能被丢弃、修改，及时送到目的地（这里就不要求可靠性吗?），咋看起来真有点挑战性。

我们先来具体分析下不同的容器网络方案中，这个“原始IP”包经过中间网络过程中，是如何一层层封装的。

                                                                   Figure -- 1

       如图Figure -- 1所示，“原始IP包”，经过veth-pair到达宿主机协议栈，再经过udp、vxlan、Ip-tunnel封装路由，最后由宿主机的物理设备eth0发出。

                                              Figure -- 2

        Figure--2是一个EthernetII数据报文格式，数据帧的有效长度在：64-1518字节之间，Payload的有效长度在：46-1500字节之间。容器网络各种方案可能的Payload：

• Fannel udp：74-1528字节
• Fannel host-gw：46-1500字节
• Fannel vxlan：96-1550字节
• Calico IPinip：66-1520字节
• Calico directip：46-1500字节

 

显然封装的报文payload可能的最大长度已经超出了以太网数据帧最大payload值1500，由此可能会产生两个问题：

• “原始IP包”被分片，目的容器收到分片的报文。
• 路径MTU装不下封装后的报文，报文被丢弃。

怎么来避免和处理这个由path mtu引起的问题呢？

                                        Figure -- 3

      如图Figure -- 3，给出了三种可能的解决方案：

1.  设置容器网卡的MTU值  

如图，容器eth0的mtu值是1440，比1500少了60个字节，这种方式，由容器的TCP/IP来处理将应用程序的报文分片。

2. 功能模块自己切片、加序列号

fanneld进程，内核的vxlan，iptunnel模块，发送和收包过程中，处理分片和组包。（有这么做的吗？）

3. 宿主机IP分片

宿主机的IP层执行分片和组包，这种方式下，可能的情况就是，容器的一个TCP segment还会在宿主机被拆成两个IP包，等于执行了两次分拆，效率是个问题。

后面继续结合不同的网络方案以及代码来讲讲，哈哈。