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

2022-03-14 510

容器网络系列：第一期

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

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

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

1. CNI 简介

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

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

更详细的CNI讲解请参考:

Introduction to CNI（https://www.youtube.com/watch?v=YjjrQiJOyME）
CNI deep dive（https://www.youtube.com/watch?v=zChkx-AB5Xc）

1.1 主流CNI对比

综上，在开源 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场景及选型建议

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

4.1 基于VPC的多集群管理

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

5. 未来展望

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

微信关注我们

原文链接：https://my.oschina.net/u/3736871/blog/5486697

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

周下载量百万的 node-ipc 包以反战为名进行供应链投毒

vue-cli 的依赖项 node-ipc 包正在以反战为名进行供应链投毒，该包在 npm 每周有上百万下载量。知名技术网站 V2ex 的一条帖子爆出了这个问题，用户simbaCheng在使用npm 构建前端项目时，启动项目后桌面自动创建了一个《 WITH-LOVE-FROM-AMERICA.txt 》文件，点开之后发现内容是空的。 simbaCheng 被吓一跳，以为自己电脑中毒了。在网友的热心帮助下，发现该 txt 文件是 vue-cli 的依赖项 node-ipc 包的作者 RIAEvangelist 在投毒，该作者是个反战人士，还特意新建了一个 peacenotwar 仓库来宣传他的反战理念。然而网友继续深扒后，发现该作者还有更恶毒的投毒行为。如果说往用户桌面写 txt 文件属于激进的反战行为，那么知乎用户 @贺师俊所介绍的这个 Issue 中的举动则是彻底的恶意攻击：攻击源码在仓库中仍可找到。源码经过压缩，简单地将一些关键字符串进行了 base64 编码。其行为是利用第三方服务探测用户 IP，针对俄罗斯和白俄罗斯 IP，会尝试覆盖当前目录、父目录和根目录的所有文件，...

2022-03-16

1053

@[toc] 今天想和大家聊一聊 MySQL 中的 redo log，其实最早我是想聊两阶段提交的，后来想想可能有小伙伴还不了解 binlog，所以就先整了一篇 binlog：手把手教你玩 MySQL 删库不跑路，直接把 MySQL 的 binlog 玩溜！ MySQL删库不跑路（视频版） binlog 大家懂了之后，接下来还差个 redo log，redo log 大家也懂了，那么再讲两阶段提交相信小伙伴们就很容易懂了，咱们一步一步来。 1. 谁的 redo log 学习 redo log，我觉得首先要搞明白一个问题，就是是谁的 redo log？我们知道，MySQL 架构整体上分为两层：Server 层和存储引擎层，如下图：前面松哥文章+视频跟大家聊的 binlog，是 MySQL 自己提供的 binlog，而 redo log 则不是 MySQL 提供的，而是存储引擎 InnoDB 自己提供的。所以在 MySQL 中就存在两类日志 binlog 和 redo log，存在两类日志既有历史原因（InnoDB 最早不是 MySQL 官方存储引擎）也有技术原因，这个咱们以后再细聊...

2022-03-15

495

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。