容器网络系列:第一期

　　伴随云原生技术的落地应用,Kubernetes正在成为云原生时代的操作系统,围绕Kubernetes的技术创新点也是层出不穷。其中,以容器网络举例,现在Kubernetes官网登记在册的 CNI 已经有近30种,可以算得上百家争鸣、各有所长了。

　　但随着企业开始使用Kubernetes承载越来越多的业务,企业对容器网络的要求越来越高,有些甚至已经超出了CNI的范畴。如何缓解企业在落地私有容器云平台时遇到的网络阻力,已经发展成了一个非常重要又急迫的问题。

　　本期我们将重点探讨CNI 的典型场景有哪些?以及如何进行 CNI 选型?

　　一、CNI简介

　　CNI(Container Network Interface)定义了一组规范,用于实现容器网络接口的配置以及IP地址的分配。CNI只关注容器的网络连接以及当容器删除时移除被分配的网络资源,因此CNI得到了广泛的支持,并且规范也易于实现。

　　随着k8s飞速发展,如今涌现出很多优秀的开源CNI,如calico,flannel,cilium。每个CNI都有各自的特点以及应用场景,但是也有各自的不足之处,因此针对不同的场景使用合适的CNI就变得尤为重要。有时为了满足更复杂的网络需求,甚至于需要多种CNI联合使用,这样会使网络模型变得复杂,大大增加维护难度。

　　更详细的CNI讲解请参考:

　　Introduction to CNI

　　CNI deep dive

　　1.1 主流CNI对比

　　综上, 在开源CNI的领域中calico, flannel, cilium都有各自的优势,但是针对企业功能还略显不足。比如calico, flannel基本功能都有,社区也比较活跃,同时二者可以组合使用取长补短,但是组合使用维护成本也会增加。cilium则是通过eBPF实现的独立的数据面,在网络安全,服务转发方面研究较深,但是运维起来比较困难。而fabric则在功能方面比较全面,性能出色且稳定性强,运维也相对简单。

　　二、Fabric简介

　　Fabric是博云自研的CNI插件,旨在提供一个能适应多种场景,功能强大,性能卓越,稳定可靠以及简单易用的容器网络管理平台。

　　Fabric支持underlay/overlay模式,同时支持IPV4/IPV6单栈和双栈,支持容器多网络/多网卡以及集群联邦,EIP,Qos,NetworkPolicy,PodSecurity,Windows等特色功能。同时为了提升运维效率, 开发了对应的debug工具,拥有流量追踪,缓存分析等能力。并且支持Linux/Windows操作系统、支持ARM/X86等CPU架构。

　　从Fabric 2.5+以后的版本还将集成eBPF、智能网卡、流量分析、无感升级等功能,从而提升数据面性能,提升业务稳定性,以及更细粒度的运维调试能力。

　　2.1 整体架构

　　图 1 Fabric Underlay架构

　　图 2 Fabric overlay架构

　　Fabric由四大核心组件组成:

　　ovs:成熟且稳定的软件交换机,用于接入容器接口,以及数据面转发和安全策略控制

　　ovs-controller: 负责ovs数据面的控制,默认流表生成,动态流表下发

　　fabric-ctl:负责集群中pod信息的采集,缓存,以及其他核心功能的控制

　　fabric二进制文件:标准的k8s CNI,用于容器网络接口的配置

　　2.2 设计理念

　　Fabric一直遵循着四大设计原则:

　　(一) 微分段设计: 控制面高稳定性、快速收敛、高性能、低延迟

　　(二) 简单即稳定: 全分布式部署、扩展性强、分布式控制、无单点故障、自动运维

　　(三) 安全隔离: 租户隔离、NetworkPolicy、PodSecurity、隧道加密

　　(四) 功能丰富: IP/MAC固定、Qos、egressIP、集群联邦、网络监控

　　2.3 发展历程

　　Fabric自2018年底开始至今,已累计发布5个稳定版本,在十余个金融客户生产环境中稳定运行多年。

　　图 3 fabric发展历程

　　三、通用场景及选型建议

　　k8s是支持混合部署的,在很多生产环境下为了最大化利用集群资源,可以将k8s master节点部署在小规格虚拟机上,同时将计算节点部署在物理机或者大规格虚拟机上。甚至于, 一个集群中可以同时存在异构CPU节点或者不同操作系统(Linux/Windows)节点。不管是选用Fabric哪种模式,其核心功能都是完美支持的,如多网络、多IP、QoS、租户隔离、Network Policy等。

　　3.1 Underlay双网卡模式

　　该模式用最简单的方式打通了集群内外主机访问集群内业务的需求, 同时集群内的所有流量都能在外部交换机、路由器、防火墙等其他网络设备上追踪,方便了网络运维人员对集群内流量的控制以及其他审计能力。在该模式下也能最大程度的保证业务网络的性能几乎等于业务网所提供的最大带宽。但是,该模式消耗的是业务网真实的IP地址,这在一定程度上限制了集群规模。

　　3.1.1 环境要求

　　(一) 每个节点至少包含两张网卡,分别用于管理网和业务网

　　(二) 管理网和业务网不能重合,业务网IP不能被集群外的其他机器占用

　　(三) 业务网卡根据需要将上联口配置成access/trunk,且开启混杂模式

　　3.1.2 适用场景

　　(一) 集群外的机器有直接访问集群内业务的需求,如注册中心在集群外部

　　(二) 集群内业务对网络性能有较高的要求

　　(三) 集群内的业务流量能够被防火墙等安全设备控制

　　(四) 中小规模集群,因为集群里的pod消耗的是真实的IP地址,该场景下IP地址都是较为珍贵的,集群规模过大可能导致业务网IP地址池被用尽

　　3.1.3 业务网规划建议

　　由于underlay消耗的是现有IP资源,所以业务网的规划就显得十分重要。如果单个业务网过大,可能导致广播域过大从而使交换机性能下降,所以在规划业务网络时我们可以划分为多个C类网络,不同的C类网络可以给不同的租户使用这样也能保证租户间的隔离性。

　　3.2 Overlay模式

　　该模式部署简单,环境依赖少。甚至于不关心节点所处位置,只要集群内节点间能相互访问理论上就能使用overlay模式。另外,该模式消耗的是虚拟的IP地址,能支持大规模的业务集群。

　　3.2.1 环境要求

　　(一) 节点至少一张网卡,且每个节点之间能进行通信

　　(二) 如果节点上多张网卡需要保证管理网卡索引最小

　　(三) 节点之间放行对应的隧道协议端口,如vxlan需放行UDP 4789端口,geneve需放行 UDP 6081端口

　　3.2.2 适用场景

　　(一) 集群外集群没有直接访问集群业务的需求

　　(二) 集群业务对网络性能要求不是很高

　　(三) 私有地址池,支持大规模集群

　　(四) 外部网络依赖少,除了放开对应的隧道协议策略之外,无需其他配置

　　3.2.3 Overlay联邦

　　为了打通Fabric集群间业务Pod的通信,Fabric从2.3开始就支持了集群联邦能力。相较于开源社区提供的网络联邦方案,Fabric联邦无需建立多重隧道,跨集群的Pod通信和同集群跨节点的Pod通信原理相同,不需要额外网关转发,直接使用一层隧道打通,无多余网络损耗。

　　四、VPC场景及选型建议

　　从网络视角,基础设施可以分布到三个层级,大部分业务系统处于第二层和第三层,层级之间或层级之内的网络策略需要配置

　　4.1 基于VPC的多集群管理

　　根据不同的业务需求,我们可以构建多个集群,按需包含underlay和overlay等部署模式, 虚拟机可以跟underlay集群中的Pod直接通信,同一个VPC内的overlay集群之间可以利用联邦进行跨集群间业务通信。

　　五、未来展望

　　现如今Fabric已经拥有丰富且强大的功能,并且能适用于各种环境。在未来我们将在控制面和数据面上不断进行性能优化,同时会提供更加丰富的网络能力、监控分析能力以及运维能力, 旨在打造一个更稳定,更强大的企业级容器网络平台。