Kubernetes 网络插件详解 - Calico 篇 - 概述

2022 年 7 月 25 日
本文字数：3945 字
阅读完需：约 13 分钟

1.1. 容器网络及策略

Kubernetes 本身并没有自己实现容器网络，而是借助 CNI 标准，通过插件化的方式来集成各种网络插件，实现集群内部网络相互通信。任何人都可以编写 CNI 插件，只要实现 CNI 标准中定义的核心接口操作（ADD，将容器添加到网络；DEL，从网络中删除一个容器；CHECK，检查容器的网络是否符合预期等）。CNI 插件通常聚焦在容器到容器的网络通信，Kubernetes 构造的 Services 网络服务仍然是由 kube-proxy 处理，通过主机的 IPtables 确定 Service 后端的 Pod 服务，通过 CNI 插件将网络报文转发到目标 Pod，如下图所示：

CNI 的接口并不是指 HTTP，gRPC 这种接口，CNI 接口是指对可执行程序的调用（exec）可执行程序，Kubernetes 节点默认的 CNI 插件路径为/opt/cni/bin。

CNI 通过 JSON 格式的配置文件来描述网络配置，当需要设置容器网络时，由容器运行时负责执行 CNI 插件，并通过 CNI 插件的标准输入（stdin）来传递配置文件信息，通过标准输出（stdout）接收插件的执行结果。从网络插件功能可以分为五类：

（一）Main 插件，创建具体网络设备（bridge：网桥设备，连接 container 和 host；ipvlan：为容器增加 ipvlan 网卡；loopback：IO 设备；macvlan：为容器创建一个 MAC 地址；ptp：创建一对 Veth Pair；vlan：分配一个 vlan 设备；host-device：将已存在的设备移入容器内）。

（二）IPAM 插件：负责分配 IP 地址（dhcp：容器向 DHCP 服务器发起请求，给 Pod 发放或回收 IP 地址；host-local：使用预先配置的 IP 地址段来进行分配；static：为容器分配一个静态 IPv4/IPv6 地址，主要用于 debug）。

（三）META 插件：其他功能的插件（tuning：通过 sysctl 调整网络设备参数；portmap：通过 iptables 配置端口映射；bandwidth：使用 Token Bucket Filter 来限流；sbr：为网卡设置 source based routing；firewall：通过 iptables 给容器网络的进出流量进行限制）。

（四）Windows 插件：专门用于 Windows 平台的 CNI 插件（win-bridge 与 win-overlay 网络插件）

（五）第三方网络插件：第三方开源的网络插件众多，每个组件都有各自的优点及适应的场景，难以形成统一的标准组件，常用有 Flannel、Calico、Cilium、OVN 网络插件。

大部分的 CNI 插件功能设计上遵守功能职责单一原则，比如 Bridge 插件负责网桥的相关配置，Firewall 插件负责防火墙相关配置，Portmap 插件负责端口映射相关配置。因此，当网络设置比较复杂时，通常通过调用多个插件来完成。CNI 通过链式调（NetworkConfigList）用多个插件，将多个插件组合起来按顺序调用，比如前面文章提到的 Flannel 网络插件 CNI 插件配置 POD 网络时的链式调用。

Kubernetes 底层是通过 Linux 的 Cgroup 与 Namesapce 来实现底层基础资源隔离，每个命名空间（namespace）都有自己网络堆栈，包括接口、路由表、套接字和 IPTABLE 规则等。一个接口只能属于一个网络命名空间，这样多个容器就需要多个接口，一般情况是通过虚拟化技术来实现硬件资源共享，通过将虚拟化设备连接到真实的物理设备上，具体分为三种实现：

（一）虚拟网桥（Virtual bridge）：创建一个虚拟网卡对（veth pair），一端在容器内一头端宿主机的 root namespace 内，并且使用 Linux bridge（网桥）或者 OpenvSwitch（OVS）来连接两个不同 namespace 内的网卡对。这样一来，容器内发出的网络数据包，可以通过网桥进入宿主机网络栈，而发往容器的网络数据包也可以经过网桥进入容器。

（二）多路复用（Multiplexing）：使用一个中间网络设备，暴露多个虚拟网卡接口，容器网卡都可以接入这个中间设备，并通过 mac 地址/IP 地址来区分 packet 应该转发给具体的容器设备。

（三）硬件交换（Hardware switching）：为每个 Pod 分配一个虚拟网卡，这样一来 Pod 与 Pod 之间的连接关系就会变的非常清晰，因为近乎物理机之间的通信基础。如今大多数网卡都支持 SR-IOV 功能，该功能将单一的物理网卡虚拟成多个 VF 接口，每个 VF 接口都有单独的虚拟 PCIe 通道，这些虚拟的 PCIe 通道共用物理网卡的 PCIe 通道。

对于 Kubernetes 网络，网络策略也是非常重要的能力；网络策略能力比较依赖 CNI 插件的具体实现，比如 Flannel 插件，根本不执行策略；但大多数插件都会强制执行策略，为 Pod 的入口流量和 Pod 的出口流量设置策略，Kubernetes 网络策略是属于命名空间范围的。

1.2. Calico 容器网络插件

Calico 是 Tigera 开源，基于 Apache 2.0 协议的网络与网络安全解决方案，适用于容器、虚拟机、以及物理机等场景。Calico 支持包含 Kubernetes、OpenShift 以及 OpenStack 等主流平台。在 Kubernetes 云原生容器网络方面，Calico 完全遵循 CNI 的标准，Flannel 的简单成为初始用户的首选，Calico 则是以性能及灵活性成为另一个不错的选择。当前 Flannel 与 Calico 两大插件占据容器网络插件 90%以上的份额。相比 Flannel 插件，Calico 的功能更为全面，不仅提供主机和 Pod 之间的网络连接，还涉及网络安全和管理。从 Calico 3.x 版本开始，Calico 默认的模式从 BGP 调整为 IPIP，一种更加高效的 Overlay 模式。Calico 特点如下：

一、高效的可视化管理：Calico 提供完善的可视化管理，包括原生 Linux eBPF 管理、标准 Linux 网络管理、以及 Windows HNS 管理。Calico 通过将基础网络、网络策略和 IP 地址等功能抽象统一，提供简单易用且操作一致的管理平面。

二、网络安全策略：Calico 提供丰富的网络策略模型，可以轻松的实现网络流量治理，同时结合内置的 Wireguard 加密功能，可以快速实现 Pod 间的数据传输。还有 Calico 策略引擎可以在主机网络及服务网络执行相同的策略模型，实现基础设施与上层服务的网络数据风险隔离。

三、高性能及可扩展性：Calico 采用前沿的 eBPF 技术，以及深度调优操作系统内核网络管道，以此来提高网络性能。Calico 支持网络配置较多，大部分场景可以不使用 Overlay，避免数据包封装/解封的大开销操作。同时 Calico 遵守云原生设计模式，底层都是采用标准的网络协议，具备出色可扩展性。

四、大规模生产运行实践：Calico 有大规模生产环境运行实践，包括 SaaS 提供商、金融服务公司和制造商；在公有云方面，包含 Amazon EKS、Azure AKS、Google GKE 和 IBM IKS，都有集成开箱即用的 Calico 网络安全能力。

1.3. Calico 核心组件

Calico 灵活的网络模块化架构，包括 CNI 网络插件，CNI IPAM 插件，网络模式，网络策略四个方面：

（一）CNI 网络插件：Calico CNI 网络插件通过一对虚拟以太网设备（vethpair），将 Pod 连接到主机网络命名空间的三层路由上，避免了许多其他 Kubernetes 网络解决方案中的二层网桥的性能开销。

（二）CNI IPAM 插件：Calico CNI IPAM 插件从一个或多个可配置的 IP 地址范围内为 Pod 分配 IP 地址，并根据需要为每个节点动态分配小块 IP。与其他 CNI IPAM 插件相比，Calico CNI IPAM 插的 IP 地址空间使用效率更高。

（三）网络模式：Calico 支持的网络模式分为 Overlay 与 Non-overlay 两种：Overlay 模式，Calico 提供 VXLAN 或 IP-in-IP 网络模式，包括限制跨子网模式（cross-subnet）。Non-overlay 模式，Calico 提供在 L2 网络或 L3 网络之上运行的 Non-overlay 网络。

（四）网络策略：Calico 的网络策略执行引擎实现了 Kubernetes 网络策略的全部功能，并且增加额外的扩展功能。

Calico 最优先的网络设置是使用 BGP 与物理网络对等的 Non-overlay 网络模式，实现 Pod IP 可在集群外部路由。如果无法将 BGP 对等连接到物理网络，但集群位于独立的 L2 网络中，也可以运行 Non-overlay 模式，只是在集群中的节点之间对等 BGP，应用外部缺少 Pod IP 的路由，无法在集群外路由。或者设置为 Overlay 模式下的 VXLAN 或 IP-in-IP，并使用跨子网 Overlay 模式来优化 L2 子网内的性能。

上图是一个完整 Calico 网络及策略架构图，包含了必须与可选的所有组件，包含 Calico API server、Felix、BIRD、confd、Dikastes、CNI plugin、Datastore plugin、IPAM plugin、kube-controllers、Typha、calicoctl：

Calico API server：支持通过 kubectl 管理 Calico 资源。
Felix：以守护进程的方式运行在集群的每个节点上，主要提供四个关键能力：接口管理（Interface management）、编程式路由（Route programming），编程式权限（ACL programming），状态报告（State reporting）。
BIRD：从 Felix 获取路由并分发给网络上的 BGP 对端，用于主机间路由。与 Felix 一样都是运行在集群的每个节点。主要提供两个关键能力：路由分发（Route distribution）、路由映射配置（BGP route reflector configuration）
Confd：开源、轻量级的配置管理工具，存储 BGP 配置和全局默认值，监听数据变化动态生成 BIRD 配置文件，会触发 BIRD 重新加载配置信息。
CNI plugin：为 Kubernetes 集群提供 Calico 网络能力。
IPAM plugin：是 Calico CNI 插件之一，使用 Calico 的 IP 池资源，来控制 IP 地址分配给集群内的 Pod。
kube-controllers：Kubernetes 的控制器，包含 Policy controller、Namespace controller、Serviceaccount controller、Workloadendpoint controller、Node controller。
calicoctl：创建、读取、更新和删除 Calico 对象的命令行界面。
Datastore plugin：通过减少每个节点对数据存储的影响来增加规模，是 Calico CNI 插件之一。
Typha：通过减少每个节点对数据存储的影响来扩大规模。在数据存储和 Felix 实例之间作为守护进程运行。
Dikastes：增强 Istio 服务网格的网络策略，作为 Istio Envoy 的 sidecar 代理方式运行。

1.4. 总结

Kubernetes 容器网络比较复杂，需要与底层基础设施及上层业务来确定容器网络方案，同时很多网络插件又支持多种模式，需要大量的网络的基础知识支撑才能了解清楚。选择合适的 CNI 插件，需要综合考虑底层网络网络拓扑，结合应用需要的网络功能，以及网络路由协议的需求。Calico 是比较成熟的容器网络插件，功能上比较丰富，性能上也在不断优化。所以将 Calico 网络插件规划成一系列文章，从网络网络基础，Calico 架构原理，到 Calico 实战操作总共八篇，抽丝剥茧，将 Calico 网络插件做深入的理解，从而彻底掌握容器网络相关知识。