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

Posted 2021-04-10 twt企业IT社区

【导读】本文重点分享了容器云平台实践中网络架构的设计，以及优化实践的经验总结，为读者今后的容器云网络架构实践提供了参考。

【作者】顾文俊，某互联网公司，金融行业架构师。2008年南京邮电大学电路与系统专业研究生毕业，12+年职业生涯主要从事IT基础设施、云计算、容器、大数据、AI、金融科技相关领域的解决方案工作。

1 Kubernetes网络组件介绍

1.1 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更加适合快速开发和迭代。

1.2 CNI支持的开源组件

1.2.1 Flannel

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

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

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

▲Flannel跨节点Pod通信图

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

1.2.2 OVS

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

▲OVS with GRE原理图

1.2.3 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的架构图。

▲Calico架构图

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

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

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

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

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

如果对你的环境而言，支持网络策略是非常重要的一点，而且你对其他性能和功能也有需求，那么Calico会是一个理想的选择。此外，如果您现在或未来有可能希望得到技术支持，那么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插件。

1.3 总结对比

Calico BGP方案最好，不能用BGP也可以考虑Calico IPIP Tunnel方案；如果是CoreOS系又能开UDPOffload，Flannel是不错的选择；Docker原生Overlay还有很多需要改进的地方。

2 容器平台的网络架构实践

2.1 某金融企业使用OpenShift（基于Kubernetes的商业版本）实现其业务上云

2.1.1 整体网络架构图

▲整体网络架构图

在DMZ和内网分别部署彼此独立的2套OpenShift，分别为内网和DMZ区两个网段，两套环境彼此隔离。

DMZ区的OpenShift部署对外发布的应用，负责处理外网的访问。内网的OpenShift部署针对内网的应用，仅负责处理内网的访问。

2.1.2 传统应用访问策略

方案推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。

在集群的所有节点的这个端口都会预留给该应用所用。在F5VS的Pool Member中配置所有节点，通过Kee-palived来实现HA。应用系统和用户不用改变现有的访问方式。

2.1.3 数据库访问方案及防火墙策略

内网计算节点可以直接访问数据库，DMZ区计算节点访问数据库有2种方案：

（1）计算节点直接通过内网防火墙访问该应用数据库内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期方案中应用仅使用2个节点，则防火墙仅开通这2个节点访问数据库的权限。

▲计算节点直接通过内网防火墙访问该应用数据库

（2）计算节点经Outbound路由通过内网防火墙访问内网数据

这Outbound路由在OpenShift中称之为Egress Router

▲经Outbound路由通过内网防火墙访问内网数据

因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限。

▲通过OutBound Router访问数据库

2.2 某金融企业两地三中心容器云网络架构

▲某企业两地三中心容器云架构

平台基于多集群管理和联邦集群特性，对两地三中心、同城双活、异地灾备等业务场景提供了原生的支持。平台以统一多集群管理为核心，可对接稳定快速的物理机服务器、资源利用率高的虚拟机、不同云环境下的云主机创建Kubernetes集群。支持运行多集群，保证集群的高可用。提供跨云的多集群统一管理，解决多云灾备问题，实现统一部署、统一发布以及统一运维。通过mirror联邦集群，为已经存在的集群进行组件联邦集群。可以在联邦内选择在一个或多个集群创建。

3 优化实践

网络优化是一个非常复杂的话题，现实场景中，如果出现服务不可用的情况，往往都会怀疑到网络上面——网络不可达，网络拥塞，网络设备失效等等。一个容器平台网络的高效稳定安全，涉及方方面面的设计考量。这里将我们在实践中的一些优化措施作了一些总结：

（1）主节点优化

在集群中，除了Pod之间的网络通信外，最大的开销就是master和etcd之间的通信了，因此：

Master侧可以优化：

• Master和etcd尽量部署在一起

• 高可用集群中，Master尽量部署在低延迟的网络里

• 确保**/etc/origin/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调度效率

• 加大了OOM的风险

• 分配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网卡在容器中创建，避免了使用NodePort带来的性能损耗。具体参见下图：

▲使用指定的Underlay IP优化

（5）cgroup实现资源隔离

在cgroup提供的能力之上，实现了网络出入带宽、资源隔离的能力，并提供所有硬件资源的可弹性配置，使得容器硬件资源全维度可弹性配置，大度提升了应用的隔离性与稳定性。在实际的运营过程中，我们发现，用户往往不能很好的预先设置最急limit值，设置过大会导致资源浪费，设置过小又会导致业务性能损失甚至业务进程频繁OOM，弹性的优势在于，用户不需要配置limit值，系统可以自动将空闲资源交给业务容器使用。使得容器的稳定性、集群资源利用率均得到提升。

▲cgroup对网络资源的优化

如上图，某个cgroup网络繁忙时，能保证其设定配额不会被其他cgroup挤占；某个cgroup没有用满其配额时，其他cgroup可以自动使用其空闲的部分带宽；多个cgroup分享空闲带宽时，优先级高的优先占用，优先级相同时，配额大的占用多，配额小的占用少，减少为了流控而主动丢包。

（6）基于DPDK技术实现对DDos攻击防护

（7）网络带宽QoS相关

网络带宽QoS主要是为了保证用户所申请的带宽资源，以及有效利用空闲的网络资源，尽可能提升用户带宽体验。那么我们可以做的事：

基于Linux Traffic Control并修改OVS，实现保证速率，最大速率；

将小包按照MPU（Minimum Packet Unit）大小来处理

同时，针对VXLAN小包处理性能不好，网络小包过多导致宿主机CPU过载，影响网络性能和稳定性的问题，通过限制容器网络的PPS（Packet Per Second）来处理。

本文是容器云大赛架构师岗课程之《容器云平台网络架构设计及优化》中的部分内容，完整课程从容器网络相关的基础概念入题，介绍了容器网络的协议栈、穿越方式和隔离方式，以及Kubernetes网络的各种场景，包括容器之间、Pod之间、Pod到Service、外部到内部的这4种场景下，不同的通信模式。最后通过两个容器云平台实践中网络架构的设计，以及优化实践的总结，为读者今后的容器云网络架构实践指明了一条道路。由于篇幅关系上面选取了课程后半，如希望系统学习容器网络基础知识，可点击阅读原文到社区免费下载完整课程。

觉得本文有用，请 转发、点赞 或点击 “在看” ，让更多同行看到

 资料/文章推荐：

• 
  

https://www.talkwithtrend.com/Topic/98447

下载 twt 社区客户端 APP

或到应用商店搜索“twt”