Kubernetes 集群网络从懵圈到熟悉
点击此处查看最新的网赚项目教程
默认情况下，通过network namespace限制的容器进程，本质上是通过Veth peer设备和宿主机网桥的方式，实现了不同network namespace的数据交换。
与之类似地，当你在一台宿主机上，访问该宿主机上的容器的IP地址时，这个请求的数据包，也是先根据路由规则到达docker0网桥，然后被转发到对应的Veth Pair设备，最后出现在容器里。
跨主机网络通信
在Docker的默认配置下，不同宿主机上的容器通过IP地址进行互相访问是根本做不到的。为了解决这个问题，社区中出现了很多网络方案。同时Kubernetes为了更好的控制网络的接入，推出了CNI即容器网络的API接口。它是Kubernetes中标准的一个调用网络实现的接口，kubelet通过这个API来调用不同的网络插件以实现不同的网络配置，实现了这个接口的就是CNI插件，它实现了一系列的CNI API接口。目前已经有的包括Flannel、Calico、Weave、Contiv等等。
实际上CNI的容器网络通信流程跟前面的基础网络一样，只是CNI维护了一个单独的网桥来代替 docker0。这个网桥的名字就叫作：CNI 网桥，它在宿主机上的设备名称默认是：cni0。cni的设计思想，就是：Kubernetes在启动Infra容器之后，就可以直接调用CNI网络插件，为这个Infra容器的Network Namespace，配置符合预期的网络栈。
CNI插件三种网络实现模式：
我们看下路由模式的一种实现flannel Host-gw：
如图可以看到当node1上container-1要发数据给node2上的container2时,会匹配到如下的路由表规则：
10.244.1.0/24 via 10.168.0.3 dev eth0
表示前往目标网段10.244.1.0/24的IP包，需要经过本机eth0出去发往的下一跳IP地址为10.168.0.3(node2)，然后到达10.168.0.3以后再通过路由表转发CNI网桥，进而进入到container2。
以上可以看到host-gw工作原理，其实就是在每个Node节点配置到每个Pod网段的下一跳为Pod网段所在的Node节点IP，Pod网段和Node节点IP的映射关系，Flannel保存在etcd或者Kubernetes中。Flannel只需要watch这些数据的变化来动态更新路由表即可。
这种网络模式最大的好处就是避免了额外的封包和解包带来的网络性能损耗。缺点我们也能看见主要就是容器IP包通过下一跳出去时，必须要二层通信封装成数据帧发送到下一跳。如果不在同个二层局域网，那么就要交给三层网关，而此时网关是不知道目标容器网络的（也可以静态在每个网关配置Pod网段路由）。所以flannel host-gw必须要求集群宿主机是二层互通的。
而为了解决二层互通的限制性，Calico提供的网络方案就可以更好的实现，Calico大三层网络模式与Flannel提供的类似，也会在每台宿主机添加如下格式的路由规则：
via dev eth0
其中网关的IP地址不通场景有不同的意思，如果宿主机是二层可达那么就是目的容器所在的宿主机的IP地址，如果是三层不同局域网那么就是本机宿主机的网关IP（交换机或者路由器地址）。
不同于Flannel通过Kubernetes或者etcd存储的数据来维护本机路由信息的做法，Calico是通过BGP动态路由协议来分发整个集群路由信息。
BGP全称是Border Gateway Protocol边界网关协议，Linxu原生支持的、专门用于在大规模数据中心为不同的自治系统之间传递路由信息。只要记住BGP简单理解其实就是实现大规模网络中节点路由信息同步共享的一种协议。而BGP这种协议就能代替Flannel维护主机路由表功能。
Calico主要由三个部分组成：
除此之外，Calico还和flannel host-gw不同之处在于，它不会创建网桥设备，而是通过路由表来维护每个Pod的通信，如下图所示：
可以看到Calico的CNI插件会为每个容器设置一个veth pair设备，然后把另一端接入到宿主机网络空间，由于没有网桥，CNI插件还需要在宿主机上为每个容器的veth pair设备配置一条路由规则，用于接收传入的IP包，路由规则如下：
10.92.77.163 dev cali93a8a799fe1 scope link
以上表示发送10.92.77.163的IP包应该发给cali93a8a799fe1设备，然后到达另外一段容器中。
有了这样的veth pair设备以后，容器发出的IP包就会通过veth pair设备到达宿主机，然后宿主机根据路有规则的下一条地址，发送给正确的网关（10.100.1.3），然后到达目标宿主机，在到达目标容器。
10.92.160.0/23 via 10.106.65.2 dev bond0 proto bird
这些路由规则都是Felix维护配置的，而路由信息则是calico bird组件基于BGP分发而来。Calico实际上是将集群里所有的节点都当做边界路由器来处理，他们一起组成了一个全互联的网络，彼此之间通过BGP交换路由，这些节点我们叫做BGP Peer。
需要注意的是Calico维护网络的默认模式是node-to-node mesh，这种模式下，每台宿主机的BGP client都会跟集群所有的节点BGP client进行通信交换路由。这样一来，随着节点规模数量N的增加，连接会以N的2次方增长，会集群网络本身带来巨大压力。
所以一般这种模式推荐的集群规模在50节点左右，超过50节点推荐使用另外一种RR（Router Reflector）模式，这种模式下，Calico可以指定几个节点作为RR，他们负责跟所有节点BGP client建立通信来学习集群所有的路由，其他节点只需要跟RR节点交换路由即可。这样大大降低了连接数量，同时为了集群网络稳定性，建议RR>=2。
以上的工作原理依然是在二层通信，当我们有两台宿主机，一台是10.100.0.2/24，节点上容器网络是10.92.204.0/24；另外一台是10.100.1.2/24，节点上容器网络是10.92.203.0/24，此时两台机器因为不在同个二层所以需要三层路由通信，这时Calico就会在节点上生成如下路由表：
10.92.203.0/23 via 10.100.1.2 dev eth0 proto bird
这时候问题就来了，因为10.100.1.2跟我们10.100.0.2不在同个子网，是不能二层通信的。这之后就需要使用Calico IPIP模式，当宿主机不在同个二层网络时就是用Overlay网络封装以后再发出去。如下图所示：
IPIP模式下在非二层通信时，Calico会在Node节点添加如下路由规则：
10.92.203.0/24 via 10.100.1.2 dev tunnel0
可以看到尽管下一条仍然是Node的IP地址，但是出口设备却是tunnel0，其是一个IP隧道设备，主要有Linux内核的IPIP驱动实现。会将容器的IP包直接封装宿主机网络的IP包中，这样到达node2以后再经过IPIP驱动拆包拿到原始容器IP包，然后通过路由规则发送给veth pair设备到达目标容器。
以上尽管可以解决非二层网络通信，但是仍然会因为封包和解包导致性能下降。如果Calico能够让宿主机之间的router设备也学习到容器路由规则，这样就可以直接三层通信了。比如在路由器添加如下的路由表：
10.92.203.0/24 via 10.100.1.2 dev interface1
而node1添加如下的路由表：
10.92.203.0/24 via 10.100.1.1 dev tunnel0
那么node1上的容器发出的IP包，基于本地路由表发送给10.100.1.1网关路由器，然后路由器收到IP包查看目的IP，通过本地路由表找到下一跳地址发送到node2，最终到达目的容器。这种方案，我们是可以基于underlay 网络来实现，只要底层支持BGP网络，可以和我们RR节点建立EBGP关系来交换集群内的路由信息。
以上就是Kubernetes常用的几种网络方案了，在公有云场景下一般用云厂商提供的或者使用flannel host-gw这种更简单，而私有物理机房环境中，Calico项目更加适合。根据自己的实际场景，再选择合适的网络方案。
- END -
后台回复“加群”，带你进入高手如云交流群
推荐阅读：
10大高性能开发利器
▼ 喜欢，就给我一个“在看”
10T 技术资源大放送！包括但不限于：云计算、虚拟化、微服务、大数据、网络、Linux、Docker、Kubernetes、Python、Go、C/C++、Shell、PPT 等。在公众号内回复「1024」，即可免费获取！！
———END———
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： qs62318888
主题授权提示：请在后台主题设置-主题授权-激活主题的正版授权，授权购买：RiTheme官网
