Kubernetes网络组件介绍

Kubernetes网络框架CNI

基于Docker的Kubernetes平台为什么没有选择CNM作为其网络设计框架？毕竟大部分容器平台肯定会支持Docker的网络组件，为什么不使用相同的组件呢？这就要从Kubernetes平台设计初衷说起，Kubernetes是一个支持多容器的运行环境，而Docker只是其中一个容器而已。Docker网络驱动设计中，做了很多和Kubernetes不兼容的假设。

例如，Docker中有“本地”驱动和“全局”驱动概念，“本地”驱动实现单机版，无法实现跨节点协作，“全局”驱动libkv可实现跨节点协作。但是，libkv接口太过于底层，而且架构模式也是Docker内部的量身定制版本，对于Kubernetes的应用会带来性能、可扩展性和安全性方面的问题。

CNI（Container Networking Interface）提供了一种Linux的应用容器的插件化网络解决方案。最初是由rkt Networking Proposal发展而来。也就是说，CNI本身并不是完全针对Docker的容器，而是提供一种普适的容器网络解决方案。模型涉及两个概念：

容器：拥有独立Linux网络命名空间的独立单元。比如rkt/docker创建出来的容器。

网络（Networking）：网络指代了可以相互联系的一组实体。这些实体拥有各自独立唯一的IP。这些实体可以是容器，是物理机，或者是其他网络设备（比如路由器）等。

CNI的接口设计非常简洁，不需要守护进程，只有两个接口ADD/DELETE，通过一个简单的shell脚本就可以完成。相对于CNM的复杂设计，CNI更加适合快速开发和迭代。

CNI支持的开源组件

Flannel

Flannel之所以可以搭建Kubernetes依赖的底层网络，是因为它可以实现以下两点：

• 它给每个node上的docker容器分配相互不相冲突的IP地址；

• 它能给这些IP地址之间建立一个覆盖网络，通过覆盖网络，将数据包原封不动的传递到目标容器内。

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。

这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够通过IP地址相互找到，也就是相互ping通。

Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且“不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。

Flannel实质上是一种“覆盖网络(Overlay Network)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，默认的节点间数据通信方式是UDP转发。

举个例子，上图是跨节点Pod通信。

可以看到，Flannel首先创建了一个名为flannel0的网桥，而且这个网桥的一端连接Docker0网桥，另一端连接一个叫做flanneld的服务进程。flanneld进程并不简单，它上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立了一个Pod节点路由表；它下连Docker0和物理网络，使用内存中的Pod节点路由表，将Docker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标flanneld上，从而完成Pod到Pod之间的直接地址通信。

OVS

Open vSwitch是一个开源的虚拟交换机软件，有点像Linux中的bridge，但是功能要复杂的多。OpenvSwitch的网桥可以直接建立多种通信通道（隧道）。这些通道的建立可以很容易地通过OVS的配置命令实现。在Kubernetes、Docker场景下，主要是建立L3到L3点隧道。如下图所示。

首先，为了避免Docker创建的Docker0地址产生冲突（因为Docker Daemon启动且给Docker0选择子网地址时只有几个备选列表，很容易产生冲突），我们可以将Docker0网桥删除，手动建立一个Linux网桥，然后手动给这个网桥配置IP地址范围。

其次，建立Open vSwitch的网桥OVS，使用ovs-vsctl命令给OVS网桥增加GRE端口，在添加GRE端口时要将目标连接的NodeIP地址设置为对端的IP地址。对每一个对端IP地址都需要这么操作（对于大型集群网络，这可是个体力活，要做自动化脚本来完成）。最后，将OVS的网桥作为网络接口，加入Docker的网桥上（Docker0或者自己手工建立的新网桥）。

重启OVS网桥和Docker的网桥，并添加一个Docker的地址段到Docker网桥的路由规则项，就可以将两个容器的网络连接起来了。

OVS的优势是，作为开源虚拟交换机软件，它相对比较成熟和稳定，而且支持各类网络隧道协议，经过了OpenStack等项目的考验。另一方面，在前面介绍Flannel的时候可知Flannel除了支持建立Overlay网络，保证Pod到Pod的无缝通信，还和Kubernetes、Docker架构体系结合紧密。Flannel能够感知Kubernetes的Service，动态维护自己的路由表，还通过etcd来协助Docker对整个Kubernetes集群中Docker0的子网地址分配。而我们在使用OVS的时候，很多事情就需要手工完成了。无论是OVS还是Flannel，通过Overlay网络提供的Pod到Pod通信都会引入一些额外的通信开销，如果是对网络依赖特别重的应用，则需要评估对业务的影响。

Calico

Calico是一个纯三层的数据中心网络方案（不需要Overlay），并且与OpenStack、Kubernetes、AWS、GCE等IaaS和容器平台都有良好的集成。Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息向整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGP route reflector来完成。这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。此外，Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。下图是Calico的架构图。

在满足系统要求的新配置的Kubernetes集群上，用户可以通过应用单个manifest文件快速部署Calico。

如果您对Calico的可选网络策略功能感兴趣，可以向集群应用其他manifest，来启用这些功能。

尽管部署Calico所需的操作看起来相当简单，但它创建的网络环境同时具有简单和复杂的属性。与Flannel不同，Calico不使用Overlay网络。相反，Calico配置第3层网络，该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时，不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包，而无需额外在流量层中打包流量。

除了性能优势之外，在出现网络问题时，用户还可以用更常规的方法进行故障排除。虽然使用VXLAN等技术进行封装也是一个不错的解决方案，但该过程处理数据包的方式同场难以追踪。使用Calico，标准调试工具可以访问与简单环境中相同的信息，从而使更多开发人员和管理员更容易理解行为。

除了网络连接外，Calico还以其先进的网络功能而闻名。网络策略是其最受追捧的功能之一。此外，Calico还可以与服务网格Istio集成，以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的策略。这意味着用户可以配置强大的规则，描述Pod应如何发送和接受流量，提高安全性并控制网络环境。

如果对你的环境而言，支持网络策略是非常重要的一点，而且你对其他性能和功能也有需求，那么Calico会是一个理想的选择。此外，如果您现在或未来有可能希望得到技术支持，那么Calico是提供商业支持的。一般来说，当您希望能够长期控制网络，而不是仅仅配置一次并忘记它时，Calico是一个很好的选择。

Calico主要由Felix、etcd、BGP client以及BGP Route Reflector组成：

• Felix，Calico Agent，跑在每台需要运行Workload的节点上，主要负责配置路由及ACLs等信息来确保Endpoint的连通状态；

• etcd，分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性；

• BGP Client（BIRD）,主要负责把Felix写入Kernel的路由信息分发到当前Calico网络，确保Workload间的通信的有效性；

• BGP Route Reflector（BIRD），大规模部署时使用，摒弃所有节点互联的mesh模式，通过一个或者多个BGP Route Reflector来完成集中式的路由分发。

• calico/calico-ipam，主要用作Kubernetes的CNI插件。