CNI 这么多，怎么选（| 容器网络系列第 1 期） kubernetes容器

容器网络系列：第一期伴随云原生技术的落地应用，Kubernetes 正在成为云原生时代的操作系统，围绕 Kubernetes 的技术创新点也是层出不穷。其中，以容器网络举例，现在 Kubernetes 官网登记在册的 CNI 已经有近 30 种，可以算得上百家争鸣、各有所长了。
但随着企业开始使用 Kubernetes 承载越来越多的业务，企业对容器网络的要求越来越高，有些甚至已经超出了 CNI 的范畴。如何缓解企业在落地私有容器云平台时遇到的网络阻力，已经发展成了一个非常重要又急迫的问题。
本期我们将重点探讨 CNI 的典型场景有哪些？以及如何进行 CNI 选型？
1. CNI 简介
CNI (Container Network Interface) 定义了一组用于实现容器网络接口的配置以及 IP 地址的分配的规范。CNI 只关注容器的网络连接以及当容器删除时移除被分配的网络资源，因此 CNI 得到了广泛的支持，并且规范也易于实现。
【CNI 这么多，怎么选（| 容器网络系列第 1 期）】
文章图片

随着 kuberntes 飞速发展，如今涌现出很多优秀的开源 CNI，如 calico，flannel，cilium。每个 CNI 都有各自的特点以及应用场景，但是也有各自的不足之处。因此，针对不同的场景使用合适的 CNI 就变得尤为重要。有时为了满足更复杂的网络需求，甚至于需要多种 CNI 联合使用，这样会使网络模型变得更为复杂，大大增加维护难度。
更详细的 CNI 讲解请参考:
Introduction to CNI（https://www.youtube.com/watch...）
CNI deep dive（https://www.youtube.com/watch...）
1.1 主流 CNI 对比

功能	Calico	Flannel	Cilium	Fabric
支持underlay模式	是，依赖BGP	否	是，依赖BGP，beta版	是，不依赖BGP但是需要提供独立业务网络
支持overlay模式	是，vxlan/ipip	是，vxlan	是，vxlan	是，vxlan/gre/geneve/stt
支持IPV4/IPV6单栈	是	是	是	是
支持双栈	是	否	否	是
动态QoS	不支持	不支持	支持，beta版	支持
管理网业务网分离	不支持	不支持	不支持	支持
网络性能损耗	overlay约20%underlay约3%	overlay约20%	overlay约20%underlay约3%	overlay约20%（在虚拟机场景下stt性能损耗更小）underlay3%
DPDK	不支持	不支持	不支持	支持
SmartNIC	不支持	不支持	不支持	支持
固定IP/MAC	仅支持固定IP	不支持	不支持	支持
分布式控制平面，无单点故障	否	否	否	是
单集群Pod IP上限	无限制	无限制	无限制	无限制
网络安全策略	Networkpolicy	无	NetworkPolicy, 基于eBPF的L4/L7安全策略	租户隔离, NetworkPolicy, Pod-Security
可视化	商业版支持	无	Hubble	支持
支持容器多网络平面	否	否	否	是
Service Proxy	依赖kube-proxy	依赖kube-proxy	基于eBPF实现	基于ovs流表实现
集群联邦	商业版支持	不支持	支持	支持
EgresslP	不支持	不支持	支持，beta版	支持
支持Windows	是，有功能限制	是，仅支持overlay	否	是，支持overlay/underlay
运维及Debug工具	无	无	有	有

综上，在开源 CNI 的领域中 calico, flannel, cilium 都有各自的优势，但是针对企业功能还略显不足。比如 calico， flannel 基本功能都有，社区也比较活跃，同时二者可以组合使用达到取长补短，但是组合使用维护成本也会增加。cilium 则是通过 eBPF 实现的独立的数据面，在网络安全，服务转发方面研究较深，但是运维起来比较困难。而 Fabric 则在功能方面比较全面，性能出色且稳定性强，运维也相对简单。
2. 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 年底开始至今，已累计发布 6 个稳定版本，在十余个金融客户生产环境中稳定运行多年。

文章图片

图 3 fabric 发展历程
3. 通用场景及选型建议
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 通信原理相同，不需要额外网关转发，直接使用一层隧道打通，无多余网络损耗。
4. VPC 场景及选型建议
从网络视角，基础设施可以分布到三个层级，大部分业务系统处于第二层和第三层，层级之间或层级之内的网络策略需要配置。