Kubernetes网络解决方案技术原理深刻剖析-Kubernetes商业环境实战

本套技术专栏是做者（秦凯新）平时工做的总结和升华，经过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。QQ邮箱地址：1120746959@qq.com，若有任何学术交流，可随时联系。

1 Dokcer网络模型

2 Kubernetes网络模型

2.1 Flannel如何控制同一水平网络

• Flannel是如何作到为不一样Node上的Pod分配IP且不产生冲突的？由于Flannel使用集中的etcd服务管理这些地址资源信息，它每次分配的地址段都在同一个公共区域获取，这样天然能随时协调，避免冲突了。在Flannel分配好地址段后，接下来的工做就转交给Docker完成了。Flannel经过修改Docker的启动参数将分配给它的地址段传递进去。

  --bip=172.17.18.1/24
  复制代码

  经过这些操做，Flannel就控制了每一个Node节点上的docker0地址段的地址，也能保障全部Pod的IP地址在同一水平的网络中且不产生冲突了

2.1.1 Flannel内核原理

• flannel利用Kubernetes API或者etcd用于存储整个集群的网络配置，其中最主要的功能为:设置整个集群的网络地址空间段。例如，设定整个集群内全部容器的IP都取自网段“10.1.0.0/16”。
• flannel在每一个物理主机中运行flanneld做为agent，它会为所在主机从集群的网络地址空间中（网段“10.1.0.0/16”），获取一个小的网段subnet，本主机内全部容器的IP地址都将从中分配（如：分配主机1网段：10.1.1.0/24，主机2网段：10.1.2.0/24）
• flanneld再将本主机获取的subnet以及用于主机间通讯的Public IP，一样经过kubernetes API或者etcd存储起来。
• flannel利用各类backend mechanism，例如udp，vxlan，hostgw等等，跨主机转发容器间的网络流量，完成容器间的跨主机通讯。

2.1.2 Flannel使用VXLAN协议网络原理

• 每台物理主机都安装有flannel，假设k8s定义的flannel网络为10.0.0.0/16，各主机的flannel从这个网络申请一个子网。pod1所在的主机的flannel子网为10.0.13.1/24，pod2所在主机的flannel子网为10.0.14.1/24。

• 每台主机有cni0和flannel.1虚拟网卡。cni0为在同一主机pod共用的网桥，当kubelet建立容器时，将为此容器建立虚拟网卡vethxxx，并桥接到cni0网桥。flannel.1是一个tun虚拟网卡，接收不在同一主机的POD的数据，而后将收到的数据转发给flanneld进程。

2.1.3 Pod1与Pod2不在同一台主机网络传输过程数据包流向：

• 1. pod1(10.0.14.15)向pod2(10.0.5.150)发送ping，查找pod1路由表，把数据包发送到cni0(10.0.14.1)
• 2. cni0查找host1路由，把数据包转发到flannel.1
• 3. flannel.1虚拟网卡再把数据包转发到它的驱动程序flannel
• 4. flannel程序使用VXLAN协议封装这个数据包，向api-server查询目的IP所在的主机IP,称为host2(不清楚何时查询)
• 5. flannel向查找到的host2 IP的UDP端口8472传输数据包
• 6. host2的flannel收到数据包后，解包，而后转发给flannel.1虚拟网卡
• 7. flannel.1虚拟网卡查找host2路由表，把数据包转发给cni0网桥，cni0网桥再把数据包转发给pod2

2.2 Calico 工做原理

• Calico把每一个操做系统的协议栈认为是一个路由器，而后把全部的容器认为是连在这个路由器上的网络终端，在路由器之间跑标准的路由协议——BGP的协议，而后让它们本身去学习这个网络拓扑该如何转发。因此Calico方案实际上是一个纯三层的方案，也就是说让每台机器的协议栈的三层去确保两个容器，跨主机容器之间的三层连通性。

• 对于控制平面，它每一个节点上会运行两个主要的程序，一个是Felix，它会监听ECTD中心的存储，从它获取事件，好比说用户在这台机器上加了一个IP，或者是分配了一个容器等。接着会在这台机器上建立出一个容器，并将其网卡、IP、MAC都设置好，而后在内核的路由表里面写一条，注明这个IP应该到这张网卡。绿色部分是一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，而后经过标准BGP的路由协议扩散到整个其余的宿主机上，让外界都知道这个IP在这里，大家路由的时候获得这里来。

• 因为Calico是一种纯三层的实现，所以能够避免与二层方案相关的数据包封装的操做，中间没有任何的NAT，没有任何的overlay，因此它的转发效率多是全部方案中最高的，由于它的包直接走原生TCP/IP的协议栈，它的隔离也由于这个栈而变得好作。由于TCP/IP的协议栈提供了一整套的防火墙的规则，因此它能够经过IPTABLES的规则达到比较复杂的隔离逻辑。

• 每一个主机上都部署了calico/node做为虚拟路由器，而且能够经过calico将宿主机组织成任意的拓扑集群。当集群中的容器须要与外界通讯时，就能够经过BGP协议将网关物理路由器加入到集群中，使外界能够直接访问容器IP，而不须要作任何NAT之类的复杂操做。

• 从上图能够看出，当容器建立时，calico为容器生成veth pair，一端做为容器网卡加入到容器的网络命名空间，并设置IP和掩码，一端直接暴露在宿主机上，并经过设置路由规则，将容器IP暴露到宿主机的通讯路由上。于此同时，calico为每一个主机分配了一段子网做为容器可分配的IP范围，这样就能够根据子网的CIDR为每一个主机生成比较固定的路由规则。

  当容器须要跨主机通讯时，主要通过下面的简单步骤：

  • 容器流量经过veth pair到达宿主机的网络命名空间上。
  • 根据容器要访问的IP所在的子网CIDR和主机上的路由规则，找到下一跳要到达的宿主机IP。 流量到达下一跳的宿主机后，根据当前宿主机上的路由规则，直接到达对端容器的veth pair插在宿主机的一端，最终进入容器。
  • 跨主机通讯时，整个通讯路径彻底没有使用NAT或者UDP封装，性能上的损耗确实比较低。

• calico目前只支持TCP、UDP、ICMP、ICMPv6协议，若是使用其余四层协议（例如NetBIOS协议），建议使用weave、原生overlay等其余overlay网络实现。 基于三层实现通讯，在二层上没有任何加密包装，所以只能在私有的可靠网络上使用。 流量隔离基于iptables实现，而且从etcd中获取须要生成的隔离规则，有一些性能上的隐患

总结

Kubernetes网络解决方案为大规模集群部署提供化多为一的网络，本文结合做者在大规模IOT物联网大数据支撑平台的实践经验，进行总结，此文尚不完善，请持续关注凯新云技术社区

秦凯新