容器云平台网络架构设计及优化最佳实践

1、 容器云平台网络架构设计及优化最佳实践 1 Kubernetes网络组件介绍1.1 Kubernetes网络框架CNI基于Docker的Kubernetes平台为什么没有选择CNM作为其网络设计框架？毕竟大部分容器平台肯定会支持Docker的网络组件，为什么不使用相同的组件呢？这就要从Kubernetes平台设计初衷说起，Kubernetes是一个支持多容器的运行环境，而Docker只是其中一个容器而已。Docker网络驱动设计中，做了很多和Kubernetes不兼容的假设。例如，Docker中有“本地”驱动和“全局”驱动概念，“本地”驱动实现单机版，无法实现跨节点协作，“全局”驱动libkv

2、可实现跨节点协作。但是，libkv接口太过于底层，而且架构模式也是Docker内部的量身定制版本，对于Kubernetes的应用会带来性能、可扩展性和安全性方面的问题。CNI（Container Networking Interface）提供了一种Linux的应用容器的插件化网络解决方案。最初是由rkt Networking Proposal发展而来。也就是说，CNI本身并不是完全针对Docker的容器，而是提供一种普适的容器网络解决方案。模型涉及两个概念：容器：拥有独立Linux网络命名空间的独立单元。比如rkt/docker创建出来的容器。网络（Networking）：网络指代了可以相互联

3、系的一组实体。这些实体拥有各自独立唯一的IP。这些实体可以是容器，是物理机，或者是其他网络设备（比如路由器）等。CNI的接口设计非常简洁，不需要守护进程，只有两个接口ADD/DELETE，通过一个简单的shell脚本就可以完成。相对于CNM的复杂设计，CNI更加适合快速开发和迭代。1.2 CNI支持的开源组件1.2.1 FlannelFlannel之所以可以搭建Kubernetes依赖的底层网络，是因为它可以实现以下两点：它给每个node上的docker容器分配相互不想冲突的IP地址；它能给这些IP地址之间建立一个覆盖网络，通过覆盖网络，将数据包原封不动的传递到目标容器内。Flannel是Co

4、reOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且“不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。Flannel实质上是一种

5、“覆盖网络(Overlay Network)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，默认的节点间数据通信方式是UDP转发。Flannel跨节点Pod通信图举个例子，上图是跨节点Pod通信。可以看到，Flannel首先创建了一个名为flannel0的网桥，而且这个网桥的一端连接Docker0网桥，另一端连接一个叫作flanneld的服务进程。flanneld进程并不简单，它上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立了一个Pod节点路由表；它下连Docker0和物理网络，使用内存中的Pod节点路由表，将Do

6、cker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标flanneld上，从而完成Pod到Pod之间的直接地址通信。1.2.2 OVSOpen vSwitch是一个开源的虚拟交换机软件，有点像Linux中的bridge，但是功能要复杂的多。OpenvSwitch的网桥可以直接建立多种通信通道（隧道）。这些通道的简历可以很容易地通过OVS的配置命令实现。在Kubernetes、Docker场景下，主要是建立L3到L3点隧道。如下图所示。OVS with GRE原理图首先，为了避免Docker创建的Docker0地址产生冲突（因为Docker Daemon启动且给Docker0选择

7、子网地址时只有几个备选列表，很容易产生冲突），我们可以将Docker0网桥删除，手动建立一个Linux网桥，然后手动给这个网桥配置IP地址范围。其次，建立Open vSwitch的网桥OVS，使用ovs-vsctl命令给OVS网桥增加GRE端口，在添加GRE端口时要将目标连接的NodeIP地址设置为对端的IP地址。对每一个对端IP地址都需要这么操作（对于大型集群网络，这可是个体力活，要做自动化脚本来完成）。最后，将OVS的网桥作为网络接口，加入Docker的网桥上（Docker0或者自己手工建立的新网桥）。重启OVS网桥和Docker的网桥，并添加一个Docker的地址段到Docker网桥的路

8、由规则项，就可以将两个容器的网络连接起来了。OVS的优势是，作为开源虚拟交换机软件，它相对比较成熟和稳定，而且支持各类网络隧道协议，经过了OpenStack等项目的考验。另一方面，在前面介绍Flannel的时候可知Flannel除了支持建立Overlay网络，保证Pod到Pod的无缝通信，还和Kubernetes、Docker架构体系结合紧密。Flannel能够感知Kubernetes的Service，动态维护自己的路由表，还通过etcd来协助Docker对整个Kubernetes集群中Docker0的子网地址分配。而我们在使用OVS的时候，很多事情就需要手工完成了。无论是OVS还是Flann

9、el，通过Overlay网络提供的Pod到Pod通信都会引入一些额外的通信开销，如果是对网络依赖特别重的应用，则需要评估对业务的影响。1.2.3 CalicoCalico是一个纯三层的数据中心网络方案（不需要Overlay），并且与OpenStack、Kubernetes、AWS、GCE等IaaS和容器平台都有良好的集成。Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播小规模部署可以直接互联，大规模下可通过指定的BGP route re

10、flector来完成。这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。此外，Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。下图是Calico的架构图。Calico架构图在满足系统要求的新配置的Kubernetes集群上，用户可以通过应用单个manifest文件快速部署Calico。如果您对Calico的可选网络

11、策略功能感兴趣，可以向集群应用其他manifest，来启用这些功能。尽管部署Calico所需的操作看起来相当简单，但它创建的网络环境同时具有简单和复杂的属性。与Flannel不同，Calico不使用Overlay网络。相反，Calico配置第3层网络，该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时，不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包，而无需额外在流量层中打包流量。除了性能优势之外，在出现网络问题时，用户还可以用更常规的方法进行故障排除。虽然使用VXLAN等技术进行封装也是一个不错的解决方案，但该过程处理数据包的方式同场难以追踪。使用Ca

12、lico，标准调试工具可以访问与简单环境中相同的信息，从而使更多开发人员和管理员更容易理解行为。除了网络连接外，Calico还以其先进的网络功能而闻名。网络策略是其最受追捧的功能之一。此外，Calico还可以与服务网格Istio集成，以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的策略。这意味着用户可以配置强大的规则，描述Pod应如何发送和接受流量，提高安全性并控制网络环境。如果对你的环境而言，支持网络策略是非常重要的一点，而且你对其他性能和功能也有需求，那么Calico会是一个理想的选择。此外，如果您现在或未来有可能希望得到技术支持，那么Calico是提供商业支持的。一般来说，当

13、您希望能够长期控制网络，而不是仅仅配置一次并忘记它时，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

14、Route Reflector（BIRD），大规模部署时使用，摒弃所有节点互联的mesh模式，通过一个或者多个BGP Route Reflector来完成集中式的路由分发。calico/calico-ipam，主要用作Kubernetes的CNI插件。1.3 总结对比Calico BGP方案最好，不能用BGP也可以考虑Calico IPIP Tunnel方案；如果是CoreOS系又能开UDPOffload，Flannel是不错的选择；Docker原生Overlay还有很多需要改进的地方。2 容器平台的网络架构实践2.1 某金融企业使用OpenShift（基于Kubernetes的商业版本）实现

15、其业务上云2.1.1 整体网络架构图整体网络架构图在DMZ和内网分别部署彼此独立的2套OpenShift，分别为内网和DMZ区两个网段，两套环境彼此隔离。DMZ区的OpenShift部署对外发布的应用，负责处理外网的访问。内网的OpenShift部署针对内网的应用，仅负责处理内网的访问。2.1.2 传统应用访问策略方案推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。在F5VS的Pool

16、Member中配置所有节点，通过Kee-palived来实现HA。应用系统和用户不用改变现有的访问方式。2.1.3 数据库访问方案及防火墙策略内网计算节点可以直接访问数据库，DMZ区计算节点访问数据库有2种方案：（1）计算节点直接通过内网防火墙访问该应用数据库内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期方案中应用仅使用2个节点，则防火墙仅开通这2个节点访问数据库的权限。计算节点直接通过内网防火墙访问该应用数据库（2）计算节点经Outbound路由通过内网防火墙访问内网数据这Outbound路由在OpenShift中称之为Egress Router经Outbound路由通过内网防火

17、墙访问内网数据因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限。通过OutBound Router访问数据库2.2 某金融企业两地三中心容器云网络架构某企业两地三中心容器云架构平台基于多集群管理和联邦集群特性，对两地三中心、同城双活、异地灾备等业务场景提供了原生的支持。平台以统一多集群管理为核心，可对接稳定快速的物理机服务器、资源利用率高的虚拟机、不同云环境下的云主机创建Kubernetes集群。支持运行多集群，保证集群的高可用。提供跨云的多集群统一管理，解决多云灾备问题，实现统一部署、统一发布以

18、及统一运维。通过mirror联邦集群，为已经存在的集群进行组件联邦集群。可以在联邦内选择在一个或多个集群创建。3 优化实践网络优化是一个非常复杂的话题，现实场景中，如果出现服务不可用的情况，往往都会怀疑到网络上面网络不可达，网络拥塞，网络设备失效等等。一个容器平台网络的高效稳定安全，涉及方方面面的设计考量。这里将我们在实践中的一些优化措施作了一些总结：（1）主节点优化在集群中，除了Pod之间的网络通信外，最大的开销就是master和etcd之间的通信了，因此：Master侧可以优化：Master和etcd尽量部署在一起高可用集群中，Master尽量部署在低延迟的网络里确保*/etc/origi

19、n/master/master-config.yaml*里的etcds，第一个是本地的etcd实例Node侧可以优化：Node节点的配置主要在*/etc/origin/node/node-config.yaml*里，可以优化：iptables,synchronization period,MTU值，代理模式。配合自文件里还可以配置Kubelet的启动参数，主要关注亮点pods-per-core和max-pods，这两个决定了Node节点的Pod数，两者不一致时，取小。如果数值过大（严重超读）会导致：增加CPU消耗，主要是Docker和OpenShift自身管理消耗的降低Pod调度效率加大了OO

20、M的风险分配Pod IP出现异常影响应用性能etcd节点：尽量和Master部署在一起，或者提供专网连接。（2）主机节点万兆网卡性能优化如果主机用万兆或者40Gbps，那么可以优化的方面：通过直接路由，负责Pod间通信，不过需要手动维护Node节点添加删除时的路由变化条件允许的话，可以考虑BGP的Calico网络方案购置支持UDP Offload的网卡，需要注意的是，使用了UDP Offload网卡和非Overlay网络相比，延迟是不会减少的，只是减少了CPU开销，提到带宽吞吐。（3）IPIP模式的Flannel性能提升汲取了Flannel/Calico容器网络开源项目的优点，实现了基于IPIP和Host Gateway的Overlay网络，具体性能短链接VXLAN比host差33%，IPIP比host差23%，Gateway比host只差6%。具体参见下图：IPIP模式Flannel性能提升（4）使用指定的Underlay IP优化FloatingIP指定宿主机提供的IP，将IP直接配置到容器中，有别于OpenStack（将Floating IP配置到宿主机的网络空间再通过NAT转发）的实现，其性能更好，容器与物理机可以直接路由。Tunnel网卡在容器中创建，