Kubernetes网络模型

由于在企业中部署私有云的场景会更普遍，所以在私有云中运行Kubernetes + Docker集群之前，就需要自己搭建符合Kubernetes要求的网络环境。现在的开源世界里，有很多开源组件可以帮助我们打通Docker容器和容器之间的网络，实现Kubernetes要求的网络模型。当然每种方案都有自己适合的场景，我们要根据自己的实际需要进行选择。

Flannel网络插件(只通信，无策略)

Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes假定这个网络已经存在。而在私有云里搭建Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问先打通，然后运行Kubernetes。

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。

下面是一张它的网络原理图：

可以看到，Flannel首先创建了一个名为flannel0的网桥，而且这个网桥的一端连接docker0的网桥，另一端连接一个名为flanneld的服务进程。

Flanneld进程并不简单，它首先上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立了一个Pod节点路由表；然后下连docker0和物理网络，使用内存中的Pod节点路由表，将docker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标flanneld上，从而完成pod到pod之间的直接的地址通信。

Flannel之间的底层通信协议的可选余地有很多，比如UDP、VXlan、AWS VPC等等。只要能通到对端的Flannel就可以了。源Flannel封包，目标Flannel解包，最终docker0看到的就是原始的数据，非常透明，根本感觉不到中间Flannel的存在。

在这里注意一点，就是flannel使用etcd作为数据库，所以需要预先安装好etcd。

同一Pod内的网络通信

在同一个Pod内的容器共享同一个网络命名空间，共享同一个Linux协议栈。所以对于网络的各类操作，就和它们在同一台机器上一样，它们可以用localhost地址直接访问彼此的端口。其实这和传统的一组普通程序运行的环境是完全一样的，传统的程序不需要针对网络做特别的修改就可以移植了。这样做的结果是简单、安全和高效，也能减少将已经存在的程序从物理机或者虚拟机移植到容器下运行的难度。

Pod1到Pod2的网络

Pod1与Pod2在同一台主机

Pod1和Pod2在同一台主机的话，由Docker0网桥直接转发请求到Pod2，不需要经过Flannel。

Pod1与Pod2不在同一台主机

Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。

Calico网络插件(通信和策略)

Calico 是一种容器之间互通的网络方案。在虚拟化平台中，比如 OpenStack、Docker 等都需要实现 workloads 之间互连，但同时也需要对容器做隔离控制，就像在 Internet 中的服务仅开放80端口、公有云的多租户一样，提供隔离和管控机制。而在多数的虚拟化平台实现中，通常都使用二层隔离技术来实现容器的网络，这些二层的技术有一些弊端，比如需要依赖 VLAN、bridge 和隧道等技术，其中 bridge 带来了复杂性，vlan 隔离和 tunnel 隧道则消耗更多的资源并对物理环境有要求，随着网络规模的增大，整体会变得越加复杂。我们尝试把 Host 当作 Internet 中的路由器，同样使用 BGP 同步路由，并使用 iptables 来做安全访问策略，最终设计出了 Calico 方案。

适用场景：k8s环境中的pod之间需要隔离

设计思想：Calico 不使用隧道或 NAT 来实现转发，而是巧妙的把所有二三层流量转换成三层流量，并通过 host 上路由配置完成跨 Host 转发。

对比

flannel在进行路由转发的基础上进行了封包解包的操作（UDP Overlay 、VXlan等），这样浪费了CPU的计算资源。

Calico 是一个纯三层的方案，不需要 Overlay，基于 Etcd 维护网络准确性，也基于 Iptables 增加了策略配置Cilium 就厉害了，基于 eBPF 和 XDP 的方案，eBPF/XDP 处理数据包的速度可以和 DPDK 媲美，零拷贝直接内核态处理，缺点就是用户不太容易进行配置。