介 绍

网络架构是 Kubernetes 中较为复杂、让很多用户头疼的方面之一。Kubernetes 网络模型本身对某些特定的网络功能有一定要求，但在实现方面也具有一定的灵活性。因此，业界已有不少不同的网络方案，来满足特定的环境和要求。

CNI（Container Network Interface） 意为容器网络通用接口，它是一种标准的设计，为了让用户在容器创建或销毁时都能够更容易地配置容器网络。在本文中，我们将集中探索与对比目前最流行的 CNI 插件 ：Flannel、Calico、Weave 和 Canal（技术上是多个插件的组合）。这些插件既可以确保满足 Kubernetes 的网络要求，又能为 Kubernetes 集群管理员提供他们所需的某些特定的网络功能。

背 景

容器网络是容器选择连接到其他容器、主机和外部网络（如 Internet）的机制。容器的 runtime 提供了各种网络模式，每种模式都会产生不同的体验。例如，Docker 默认情况下可以为容器配置以下网络：

• none：将容器添加到一个容器专门的网络堆栈中，没有对外连接。
• host：将容器添加到主机的网络堆栈中，没有隔离。
• default bridge：默认网络模式。每个容器可以通过IP地址相互连接。
• 自定义网桥：用户定义的网桥，具有更多的灵活性、隔离性和其他便利功能。

Docker 还可以让用户通过其他驱动程序和插件，来配置更高级的网络（包括多主机覆盖网络）。

CNI 的初衷是创建一个框架，用于在配置或销毁容器时动态配置适当的网络配置和资源。下面链接中的 CNI 规范概括了用于配制网络的插件接口，这个接口可以让容器运行时与插件进行协调：

• https://github.com/containernetworking/cni/blob/master/SPEC.md

插件负责为接口配置和管理IP地址，并且通常提供与 IP 管理、每个容器的 IP 分配、以及多主机连接相关的功能。容器运行时会调用网络插件，从而在容器启动时分配 IP 地址并配置网络，并在删除容器时再次调用它以清理这些资源。

运行时或协调器决定了容器应该加入哪个网络以及它需要调用哪个插件。然后，插件会将接口添加到容器网络命名空间中，作为一个 veth 对的一侧。接着，它会在主机上进行更改，包括将 veth 的其他部分连接到网桥。再之后，它会通过调用单独的 IPAM（IP 地址管理）插件来分配 IP 地址并设置路由。

在 Kubernetes 中，kubelet 可以在适当的时间调用它找到的插件，来为通过 kubelet 启动的 Pod 进行自动的网络配置。

术 语

在对 CNI 插件们进行比较之前，我们可以先对网络中会见到的相关术语做一个整体的了解。不论是阅读本文，还是今后接触到其他和 CNI 有关的内容，了解一些常见术语总是非常有用的。

一些最常见的术语包括：

• 第2层网络： OSI（Open Systems Interconnections，开放系统互连）网络模型的“数据链路”层。第2层网络会处理网络上两个相邻节点之间的帧传递。第2层网络的一个值得注意的示例是以太网，其中MAC表示为子层。
• 第3层网络： OSI 网络模型的“网络”层。第3层网络的主要关注点，是在第2层连接之上的主机之间路由数据包。IPv4、IPv6 和 ICMP是第3层网络协议的示例。
• VXLAN：代表“虚拟可扩展 LAN”。首先，VXLAN 用于通过在 UDP 数据报中封装第2层以太网帧来帮助实现大型云部署。VXLAN 虚拟化与 VLAN 类似，但提供更大的灵活性和功能（VLAN 仅限于 4096 个网络 ID）。VXLAN 是一种封装和覆盖协议，可在现有网络上运行。
• Overlay网络：Overlay 网络是建立在现有网络之上的虚拟逻辑网络。Overlay 网络通常用于在现有网络之上提供有用的抽象，并分离和保护不同的逻辑网络。
• 封装：封装是指在附加层中封装网络数据包以提供其他上下文和信息的过程。在 overlay 网络中，封装被用于从虚拟网络转换到底层地址空间，从而能路由到不同的位置（数据包可以被解封装，并继续到其目的地）。
• 网状网络：网状网络（Mesh network）是指每个节点连接到许多其他节点以协作路由、并实现更大连接的网络。网状网络允许通过多个路径进行路由，从而提供更可靠的网络。网状网格的缺点是每个附加节点都会增加大量开销。
• BGP：代表“边界网关协议”，用于管理边缘路由器之间数据包的路由方式。BGP 通过考虑可用路径，路由规则和特定网络策略，帮助弄清楚如何将数据包从一个网络发送到另一个网络。BGP 有时被用作 CNI 插件中的路由机制，而不是封装的覆盖网络。

了解了技术术语和支持各类插件的各种技术之后，下面我们可以开始探索一些最流行的 CNI 插件了。

CNI 比较

Flannel

• Flannel => 链接：https://github.com/coreos/flannel

由 CoreOS 开发的项目 Flannel，可能是最直接和最受欢迎的 CNI 插件。它是容器编排系统中最成熟的网络结构示例之一，旨在实现更好的容器间和主机间网络。随着 CNI 概念的兴起，Flannel CNI 插件算是早期的入门。

与其他方案相比，Flannel 相对容易安装和配置。它被打包为单个二进制文件 flanneld，许多常见的 Kubernetes 集群部署工具和许多 Kubernetes 发行版都可以默认安装 Flannel。Flannel 可以使用Kubernetes 集群的现有 etcd 集群来使用 API 存储其状态信息，因此不需要专用的数据存储。

Flannel 配置第3层 IPv4 overlay 网络。它会创建一个大型内部网络，跨越集群中每个节点。在此 overlay 网络中，每个节点都有一个子网，用于在内部分配 IP 地址。在配置 pod 时，每个节点上的 Docker 桥接口都会为每个新容器分配一个地址。同一主机中的 Pod 可以使用Docker 桥接进行通信，而不同主机上的 pod 会使用 flanneld 将其流量封装在 UDP 数据包中，以便路由到适当的目标。

Flannel 有几种不同类型的后端可用于封装和路由。默认和推荐的方法是使用 VXLAN，因为 VXLAN 性能更良好并且需要的手动干预更少。

总的来说，Flannel 是大多数用户的不错选择。从管理角度来看，它提供了一个简单的网络模型，用户只需要一些基础知识，就可以设置适合大多数用例的环境。一般来说，在初期使用 Flannel 是一个稳妥安全的选择，直到你开始需要一些它无法提供的东西。

Calico

• Calico => 链接：https://github.com/projectcalico/cni-plugin

Calico 是 Kubernetes 生态系统中另一种流行的网络选择。虽然 Flannel 被公认为是最简单的选择，但 Calico 以其性能、灵活性而闻名。Calico 的功能更为全面，不仅提供主机和 Pod 之间的网络连接，还涉及网络安全和管理。Calico CNI 插件在 CNI 框架内封装了 Calico 的功能。

在满足系统要求的新配置的 Kubernetes 集群上，用户可以通过应用单个 manifest 文件快速部署 Calico。如果您对 Calico 的可选网络策略功能感兴趣，可以向集群应用其他 manifest，来启用这些功能。

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

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

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

如果对你的环境而言，支持网络策略是非常重要的一点，而且你对其他性能和功能也有需求，那么 Calico 会是一个理想的选择。此外，如果您现在或未来有可能希望得到技术支持，那么 Calico 是提供商业支持的。一般来说，当您希望能够长期控制网络，而不是仅仅配置一次并忘记它时，Calico 是一个很好的选择。

Canal

• Canal => 链接：https://github.com/projectcalico/canal

Canal 也是一个有趣的选择，原因有很多。

首先，Canal 是一个项目的名称，它试图将 Flannel 提供的网络层与 Calico 的网络策略功能集成在一起。然而，当贡献者完成细节工作时却发现，很明显，如果 Flannel 和 Calico 这两个项目的标准化和灵活性都已各自确保了话，那集成也就没那么大必要了。结果，这个官方项目变得有些“烂尾”了，不过却实现了将两种技术部署在一起的预期能力。出于这个原因，即使这个项目不复存在，业界还是会习惯性地将 Flannel 和 Calico 的组成称为 “Canal”。

由于 Canal 是 Flannel 和 Calico 的组合，因此它的优点也在于这两种技术的交叉。网络层用的是Flannel提供的简单 overlay，可以在许多不同的部署环境中运行且无需额外的配置。在网络策略方面，Calico 强大的网络规则评估，为基础网络提供了更多补充，从而提供了更多的安全性和控制。

确保集群满足必要的系统要求（https://docs.projectcalico.org/v3.6/getting-started/kubernetes/requirements）后，用户需要应用两个 manifest 才能部署 Canal，这使得其配置比单独的任何一个项目都困难。如果企业的 IT 团队计划改变他们的网络方案，且希望在实施改变之前能先对网络策略进行一些实验并获取一些经验，那么 Canal 是一个不错的选择。

一般来说，如果你喜欢 Flannel 提供的网络模型，但发现 Calico 的一些功能很诱人，那么不妨尝试一下 Canal。从安全角度来看，定义网络策略规则的能力是一个巨大的优势，并且在许多方面是 Calico 的杀手级功能。能够将该技术应用到熟悉的网络层，意味着您可以获得更强大的环境，且可以省掉大部分的过渡过程。

Weave

• Weave => 链接：https://www.weave.works/oss/net/

Weave 是由 Weaveworks 提供的一种 Kubernetes CNI 网络选项，它提供的模式和我们目前为止讨论的所有网络方案都不同。Weave 在集群中的每个节点之间创建网状 overlay 网络，参与者之间可以灵活路由。这一特性再结合其他一些独特的功能，在某些可能导致问题的情况下，Weave 可以智能地路由。

为了创建网络，Weave 依赖于网络中每台主机上安装的路由组件。然后，这些路由器交换拓扑信息，以维护可用网络环境的最新视图。当需要将流量发送到位于不同节点上的 pod 时，Weave 路由组件会自动决定是通过“快速数据路径”发送，还是回退到 “sleeve” 分组转发的方法。

快速数据路径依靠内核的本机 Open vSwitch 数据路径模块，将数据包转发到适当的 pod，而无需多次移入和移出用户空间。Weave 路由器会更新 Open vSwitch 配置，以确保内核层具有有关如何路由传入数据包的准确信息。相反，当网络拓扑不适合快速数据路径路由时，sleeve 模式可用作备份。它是一种较慢的封装模式，在快速数据路径缺少必要的路由信息或连接的情况下，它可以来路由数据包。当流量通过路由器时，它们会了解哪些对等体与哪些 MAC 地址相关联，从而允许它们以更少的跳数、更智能地路由后续流量。当网络更改导致可用路由改变时，这一相同的机制可以帮助每个节点进行自行更正。

与 Calico 一样，Weave 也为 Kubernetes 集群提供网络策略功能。设置 Weave 时，网络策略会自动安装和配置，因此除了添加网络规则之外，用户无需进行其他配置。一个其他网络方案都没有、Weave 独有的功能，是对整个网络的简单加密。虽然这会增加相当多的网络开销，但 Weave 可以使用 NaCl 加密（http://nacl.cr.yp.to）来为 sleeve 流量自动加密所有路由流量，而对于快速数据路径流量，因为它需要加密内核中的 VXLAN 流量，Weave 会使用 IPsec ESP 来加密快速数据路径流量。

对于那些寻求功能丰富的网络、同时希望不要增加大量复杂性或管理难度的人来说，Weave 是一个很好的选择。它设置起来相对容易，提供了许多内置和自动配置的功能，并且可以在其他解决方案可能出现故障的场景下提供智能路由。网状拓扑结构确实会限制可以合理容纳的网络的大小，不过对于大多数用户来说，这也不是一个大问题。此外，Weave 也提供收费的技术支持，可以为企业用户提供故障排除等等技术服务。

结 语

Kubernetes 采用的 CNI 标准，让 Kubernetes 生态系统中的网络解决方案百花齐放。更多样的选择，意味着大多数用户将能够找到适合其当前需求和部署环境的 CNI 插件，同时还可以在环境发生变化时也能找到新的解决方案。

不同企业之间的运营要求差异很大，因此拥有一系列具有不同复杂程度和功能丰富性的成熟解决方案，大大有助于 Kubernetes 在满足不同用户独特需求的前提下，仍然能够提供一致的用户体验。