确定最佳网络选项
了解 Calico 支持的不同网络选项,以便您可以选择最适合您需求的选项。Calico 灵活的模块化架构支持广泛的部署选项,因此您可以选择适合您的特定环境和需求的最佳网络方法。这包括能够以非覆盖或覆盖模式、带或不带 BGP 运行各种 CNI 和 IPAM 插件以及底层网络类型。
如果您想完全了解可用的网络选择,我们建议您确保熟悉并理解以下概念。如果您想跳过学习并直接了解选择和建议,您可以跳至网络选项。
Kubernetes 网络基础知识
Kubernetes 网络模型定义了一个“扁平”网络,其中:
- 每个 Pod 都有自己的 IP 地址。
- 任何节点上的 Pod 都可以与所有其他节点上的所有 Pod 通信,无需 NAT。
这创建了一个干净的、向后兼容的模型,从端口分配、命名、服务发现、负载平衡、应用程序配置和迁移的角度来看,可以像虚拟机或物理主机一样对待 Pod。可以使用网络策略来定义网络分段,以限制这些基本网络功能内的流量。
在这个模型中,有很大的灵活性来支持不同的网络方法和环境。网络具体实现方式的细节取决于所使用的 CNI、网络和云提供商插件的组合。
CNI 插件
CNI(容器网络接口)是一个标准 API,允许不同的网络实现插入 Kubernetes。每当创建或销毁 Pod 时,Kubernetes 都会调用该 API。 CNI 插件有两种类型:
- CNI 网络插件:负责向 Kubernetes Pod 网络添加或删除 Pod。这包括创建/删除每个 Pod 的网络接口以及将其连接/断开与网络实现的其余部分的连接。
- CNI IPAM 插件:负责在创建或删除 Pod 时为其分配和释放 IP 地址。根据插件的不同,这可能包括为每个节点分配一个或多个 IP 地址范围 (CIDR),或者从底层公共云网络获取 IP 地址以分配给 Pod。
云提供商集成
Kubernetes 云提供商集成是特定于云的控制器,可以配置底层云网络以帮助提供 Kubernetes 网络。根据云提供商的不同,这可能包括自动将路由编程到底层云网络中,以便它本身知道如何路由 Pod 流量。
Kubenet
Kubenet 是 Kubernetes 内置的一个非常基本的网络插件。它不实现跨节点网络或网络策略。它通常与云提供商集成一起使用,该集成在云提供商网络中设置路由,以便在节点之间或单节点环境中进行通信。 Kubenet 与 Calico 不兼容。
覆盖网络
覆盖网络是分层在另一个网络之上的网络。在 Kubernetes 环境中,覆盖网络可用于处理底层网络顶部节点之间的 pod 到 pod 流量,该网络不知道 pod IP 地址或哪些 pod 正在哪些节点上运行。覆盖网络的工作原理是将底层网络不知道如何处理(例如使用 Pod IP 地址)的网络数据包封装在底层网络知道如何处理(例如节点 IP 地址)的外部数据包中。用于封装的两种常见网络协议是 VXLAN 和 IP-in-IP。
使用覆盖网络的主要优点是它减少了对底层网络的依赖。例如,您可以在几乎任何底层网络之上运行 VXLAN 覆盖,而无需与底层网络集成或对其进行任何更改。
使用覆盖网络的主要缺点是:
- 对性能有轻微影响。封装数据包的过程需要占用少量 CPU,并且数据包中需要额外的字节来对封装进行编码(VXLAN 或 IP-in-IP 标头),从而减少了可发送的内部数据包的最大大小,从而可以减少内部数据包的大小。意味着需要为相同数量的总数据发送更多数据包。
- Pod IP 地址在集群外部不可路由。下面详细介绍这一点!
跨子网覆盖
除了标准 VXLAN 或 IP-in-IP 覆盖之外,Calico 还支持 VXLAN 和 IP-in-IP 的“跨子网”模式。在此模式下,在每个子网内,底层网络充当 L2 网络。在单个子网内发送的数据包不会被封装,因此您可以获得非覆盖网络的性能。跨子网发送的数据包被封装,就像普通的覆盖网络一样,减少了对底层网络的依赖(无需与底层网络集成或对其进行任何更改)。
就像标准覆盖网络一样,底层网络不知道 Pod IP 地址,并且 Pod IP 地址在集群外部不可路由。
Pod IP 在集群外部的可路由性
不同 Kubernetes 网络实现的一个重要区别特征是 Pod IP 地址是否可以通过更广泛的网络在集群外部路由。
不可路由
如果 Pod IP 地址在集群外部不可路由,那么当 Pod 尝试与集群外部的 IP 地址建立网络连接时,Kubernetes 将使用一种称为 SNAT(源网络地址转换)的技术来更改源 IP地址从 Pod 的 IP 地址到托管 Pod 的节点的 IP 地址。连接上的任何返回数据包都会自动映射回 pod IP 地址。因此,Pod 不知道 SNAT 正在发生,连接的目的地将该节点视为连接的源,而底层更广泛的网络永远不会看到 Pod IP 地址。
对于相反方向的连接,即集群外部的东西需要连接到 Pod,这只能通过 Kubernetes 服务或 Kubernetes 入口来完成。集群外部的任何内容都无法直接连接到 Pod IP 地址,因为更广泛的网络不知道如何将数据包路由到 Pod IP 地址。
可路由
如果 Pod IP 地址在集群外部可路由,则 Pod 可以在没有 SNAT 的情况下连接到外部世界,并且外部世界可以直接连接到 Pod,而无需通过 Kubernetes 服务或 Kubernetes 入口。
可在集群外部路由的 pod IP 地址的优点是:
- 避免出站连接的 SNAT 对于集成现有的更广泛的安全要求可能至关重要。它还可以简化调试和操作日志的理解。
- 如果您有专门的工作负载,这意味着需要直接访问某些 pod,而无需通过 Kubernetes 服务或 Kubernetes 入口,那么可路由 pod IP 在操作上可能比使用主机联网 pod 的替代方案更简单。
可在集群外部路由的 Pod IP 地址的主要缺点是 Pod IP 在更广泛的网络中必须是唯一的。例如,如果运行多个集群,您将需要为每个集群中的 Pod 使用不同的 IP 地址范围 (CIDR)。当大规模运行时,或者企业对 IP 地址空间存在其他重大需求时,这反过来可能会导致 IP 地址范围耗尽的挑战。
什么决定了可路由性?
如果您的集群使用覆盖网络,则 Pod IP 通常无法在集群外部路由。
如果您不使用覆盖网络,那么 Pod IP 是否可在集群外部路由取决于所使用的 CNI 插件、云提供商集成或(对于本地)与物理网络对等的 BGP 的组合。
BGP
BGP(边界网关协议)是一种基于标准的网络协议,用于跨网络共享路由。它是互联网的基本构建模块之一,具有卓越的扩展特性。
Calico 内置了对 BGP 的支持。在本地部署中,这允许 Calico 与物理网络(通常是架顶式路由器)对等以交换路由,从而形成一个非覆盖网络,其中 pod IP 地址可在更广泛的网络中路由,就像附加的任何其他工作负载一样到网络。
关于 Calico Networking
Calico 灵活的网络模块化架构包括以下内容。
Calico CNI 网络插件
Calico CNI 网络插件使用一对虚拟以太网设备(veth 对)将 Pod 连接到主机网络命名空间的 L3 路由。这种 L3 架构避免了许多其他 Kubernetes 网络解决方案中额外的 L2 桥带来的不必要的复杂性和性能开销。
Calico CNI IPAM 插件
Calico CNI IPAM 插件从一个或多个可配置的 IP 地址范围中为 Pod 分配 IP 地址,根据需要动态为每个节点分配小块 IP。与许多其他 CNI IPAM 插件(包括许多网络解决方案中使用的主机本地 IPAM 插件)相比,IP 地址空间使用效率更高。
覆盖网络模式
Calico 可以提供 VXLAN 或 IP-in-IP 覆盖网络,包括仅跨子网模式。
非覆盖网络模式
Calico 可以提供在任何底层 L2 网络或 L3 网络之上运行的非覆盖网络,该网络可以是具有适当云提供商集成的公共云网络,也可以是支持 BGP 的网络(通常是具有标准 Top-of 的本地网络) - 机架路由器)
网络策略执行
Calico 的网络策略执行引擎实现了全方位的 Kubernetes 网络策略功能,以及 Calico 网络策略的扩展功能。这与 Calico 的内置网络模式或任何其他 Calico 兼容的网络插件和云提供商集成结合使用。
Calico 兼容的 CNI 插件和云提供商集成
除了 Calico CNI 插件和内置网络模式之外,Calico 还与许多第三方 CNI 插件和云提供商集成兼容。
亚马逊 VPC CNI
Amazon VPC CNI 插件从底层 AWS VPC 分配 Pod IP,并使用 AWS 弹性网络接口提供 VPC 本机 Pod 网络(可在集群外部路由的 Pod IP)。它是 Amazon EKS 中使用的默认网络,并使用 Calico 执行网络策略。
Azure CNI
Azure CNI 插件从底层 Azure VNET 分配 Pod IP,配置 Azure 虚拟网络以提供 VNET 本机 Pod 网络(可在群集外部路由的 Pod IP)。它是 Microsoft AKS 中使用的默认网络,并使用 Calico 来实施网络策略。
Azure 云提供商
Azure 云提供商集成可用作 Azure CNI 插件的替代方案。它使用主机本地 IPAM CNI 插件来分配 Pod IP,并使用相应的路由对底层 Azure VNET 子网进行编程。 Pod IP 只能在 VNET 子网内路由(这通常意味着它们在集群外部不可路由)。
谷歌云提供商
Google 云提供商集成使用主机本地 IPAM CNI 插件来分配 Pod IP,并对 Google 云网络别名 IP 范围进行编程,以在 Google 云上提供 VPC 本机 Pod 网络(可在集群外部路由的 Pod IP)。它是 Google Kubernetes Engine (GKE) 的默认设置,并使用 Calico 执行网络策略。
主机本地 IPAM
主机本地 CNI IPAM 插件是常用的 IP 地址管理 CNI 插件,它为每个节点分配固定大小的 IP 地址范围(CIDR),然后从该范围内分配 pod IP 地址。默认地址范围大小为 256 个 IP 地址 (a /24),但其中两个 IP 地址保留用于特殊用途且未分配给 Pod。主机本地 CNI IPAM 插件的简单性使其易于理解,但与 Calico CNI IPAM 插件相比,会导致 IP 地址空间使用效率较低。
Flannel
Flannel 使用从主机本地 IPAM CNI 插件获取的静态每节点 CIDR 路由 pod 流量。 Flannel 提供了许多网络后端,但主要与其 VXLAN 覆盖后端一起使用。 Calico CNI 和 Calico 网络策略可以与 flannel 和主机本地 IPAM 插件相结合,为 VXLAN 网络提供策略实施。这种组合有时被称为“运河”。
Calico 现在内置了对 VXLAN 的支持,为了简单起见,我们通常建议优先使用 Calico+Flannel 组合。
组网选项
组网分为5个大类,包括:Policy、IPAM、CNI、是否Overlay、Routing,每个云厂商都有自己实现,列出如下
选项 | 备注 |
---|---|
Policy(calico) | Kubernetes 网络策略是通过网络插件而不是 Kubernetes 本身来实现的。简单地创建网络策略资源而不使用网络插件来实现它,不会对网络流量产生影响。 Calico 插件实现了全套 Kubernetes 网络策略功能。此外,Calico 支持 Calico 网络策略,提供 Kubernetes 网络策略之外的附加特性和功能。 Kubernetes 和 Calico 网络策略无缝协作,因此您可以选择最适合您的策略,并根据需要进行混合和匹配。 |
IPAM(calico) | Kubernetes 如何为 Pod 分配 IP 地址由所使用的 IPAM(IP 地址管理)插件决定。 Calico IPAM 插件根据需要动态地将小块 IP 地址分配给节点,以有效地整体利用可用的 IP 地址空间。此外,Calico IPAM 支持高级功能,例如多个 IP 池、指定命名空间或 Pod 应使用的特定 IP 地址范围的能力,甚至是 Pod 应使用的特定 IP 地址。 |
CNI(calico) | Kubernetes 使用的 CNI(容器网络接口)插件决定了 Pod 如何连接到底层网络的详细信息。 Calico CNI 插件使用 L3 路由将 Pod 连接到主机网络,而不需要 L2 桥接器。这简单易懂,并且比 kubenet 或 flannel 等其他常见替代方案更高效。 |
CNI(calico) | Kubernetes 使用的 CNI(容器网络接口)插件决定了 Pod 如何连接到底层网络的详细信息。 Calico CNI 插件使用 L3 路由将 Pod 连接到主机网络,而不需要 L2 桥接器。这简单易懂,并且比 kubenet 或 flannel 等其他常见替代方案更高效。 |
Overlay(NO) | 在不使用覆盖的情况下运行可提供最高性能的网络。离开 Pod 的数据包是通过网络传输的数据包。 相反,为了完整起见,在覆盖网络中,不同节点上的 Pod 之间的数据包使用 VXLAN 或 IPIP 等协议进行封装,将每个原始数据包包装在使用节点 IP 的外部数据包中,并隐藏内部数据包的 Pod IP 。 Linux 内核可以非常有效地完成此操作,但它仍然会产生很小的开销,如果运行特别网络密集型工作负载,您可能希望避免这种情况。 |
Routing(BGP) | BGP(边界网关协议)用于动态规划节点之间 Pod 流量的路由。 BGP 是用于构建互联网的基于标准的路由协议。它的扩展性非常好,与 BGP 可以处理的负载相比,即使是最大的 Kubernetes 集群也只代表很小的负载。 Calico 可以以三种模式运行 BGP:全网状 - 每个节点在底层 L2 网络之上或使用 IPIP 覆盖相互通信 BGP,轻松扩展到 100 个节点 - 使用路由反射器 - 每个节点与一个或多个 BGP 路由反射器通信,可扩展到 100 个以上节点,位于底层 L2 网络之上或使用 IPIP 覆盖 - 与 TOR(机架顶部)路由器对等 - 在物理数据中心中,每个节点与相应机架顶部的路由器进行通信,从而扩展到物理数据中心的限制。 |
cross-subnet(vxlan) | 使用 Calico 的跨子网 VXLAN 模式,同一子网上的 Pod 之间的流量不使用 Overlay,而不同子网上的 Pod 之间的流量将通过 VXLAN Overlay。 同一子网内节点上的 Pod 之间的数据包在不使用覆盖的情况下发送,以提供最佳的网络性能。 不同子网的节点上的 Pod 之间的数据包使用 IPIP 进行封装,将每个原始数据包包装在使用节点 IP 的外部数据包中,并隐藏内部数据包的 Pod IP。 Linux 内核可以非常有效地完成此操作,但与非覆盖流量相比,它仍然表示很小的开销。 |
cross-subnet(ipip) | 使用 Calico 的跨子网 IPIP 模式,同一子网上的 Pod 之间的流量不使用 Overlay,而不同子网上的 Pod 之间的流量将通过 IPIP Overlay。 同一子网内节点上的 Pod 之间的数据包在不使用覆盖的情况下发送,以提供最佳的网络性能。 不同子网的节点上的 Pod 之间的数据包使用 IPIP 进行封装,将每个原始数据包包装在使用节点 IP 的外部数据包中,并隐藏内部数据包的 Pod IP。 Linux 内核可以非常有效地完成此操作,但与非覆盖流量相比,它仍然表示很小的开销。 |
IPAM(aws) | Kubernetes 如何为 Pod 分配 IP 地址由所使用的 IPAM(IP 地址管理)插件决定。 AWS IPAM 插件使用底层 VPC(虚拟私有云)的 IP 地址,根据需要动态地将小块 IP 地址分配给节点。 AWS IPAM 插件与 Amazon VPC CNI 插件结合使用,以提供 VPC 本机 Pod 网络。 |
CNI(aws) | Kubernetes 使用的 CNI(容器网络接口)插件决定了 Pod 如何连接到底层网络的详细信息。 AWS Amazon VPC CNI 和 IPAM 插件为 Pod 提供来自底层 VPC(虚拟私有云)的 IP 地址,以提供 VPC 原生 Pod 网络。 AWS VPC 用于在节点之间路由 Pod 流量,并了解哪个 Pod IP 地址位于哪些节点上。这避免了对覆盖的需要,并且通常具有良好的网络性能特征。 此外,Pod IP 可以被更广泛的 AWS 网络所理解,因此,例如,如果需要,集群外部的虚拟机可以直接连接到任何 Pod,而无需通过 Kubernetes 服务。 |
Routing(calico) | Calico 路由使用其数据存储来分配和编程节点之间 pod 流量的路由,而无需 BGP。 Calico 路由支持单个子网内的未封装流量,以及跨多个子网的集群的选择性 VXLAN 封装。 |
IPAM(Azure) | Kubernetes 如何为 Pod 分配 IP 地址由所使用的 IPAM(IP 地址管理)插件决定。 Azure IPAM 插件使用来自底层 VNET(虚拟网络)的 IP 地址,根据需要动态地将小块 IP 地址分配给节点。 Azure IPAM 插件与 Azure CNI 插件结合使用,提供 VPC 本机 Pod 网络。 |
CNI (Azure) | Kubernetes 使用的 CNI(容器网络接口)插件决定了 Pod 如何连接到底层网络的详细信息。 Azure CNI 和 IPAM 插件为 Pod 提供来自底层 Azure VNET(虚拟网络)的 IP 地址,以提供 VPC 本机 Pod 网络。 Azure VNET 用于在节点之间路由 Pod 流量,并了解哪个 Pod IP 地址位于哪些节点上。这避免了对覆盖的需要,并且通常具有良好的网络性能特征。 此外,Pod IP 可以被更广泛的 AWS 网络所理解,因此,例如,如果需要,集群外部的虚拟机可以直接连接到任何 Pod,而无需通过 Kubernetes 服务。 |
Routing (VPC Native) | 底层云VPC(虚拟私有云)用于路由节点之间的Pod流量,并了解哪些Pod IP地址位于哪些节点上。这避免了对覆盖的需要,并且通常具有良好的性能特征。 此外,Pod IP 可以被更广泛的云网络所理解,因此,例如,如果需要,集群外部的虚拟机可以直接连接到任何 Pod,而无需通过 Kubernetes 服务。 |
本地部署
Calico on-prem 最常见的网络设置是非覆盖模式,使用 BGP 与物理网络(通常是架顶式路由器)对等,以使 Pod IP 在集群外部可路由。 (当然,如果需要,您可以配置本地网络的其余部分,以限制集群外部 pod IP 路由的范围。)此设置提供了丰富的高级 Calico 功能,包括通告 Kubernetes 服务 IP 的能力(集群 IP 或外部 IP),以及在 Pod、命名空间或节点级别控制 IP 地址管理的能力,以支持与现有企业网络和安全要求集成的各种可能性。
如果无法将 BGP 与物理网络对等互连,并且集群位于单个 L2 网络内,则您还可以运行非覆盖模式,而 Calico 仅在集群中的节点之间对等 BGP。尽管这不是严格意义上的覆盖网络,但 Pod IP 无法在集群外部路由,因为更广泛的网络没有 Pod IP 的路由。
或者,您可以在 VXLAN 或 IP-in-IP 覆盖模式下运行 Calico,并使用跨子网覆盖模式来优化每个 L2 子网内的性能。
推荐:
AWS
如果您希望 Pod IP 地址可在集群外部路由,则必须使用 Amazon VPC CNI 插件。这是 EKS 的默认网络模式,使用 Calico 进行网络策略。 Pod IP 地址是从底层 VPC 分配的,每个节点的最大 Pod 数量取决于实例类型。
如果您希望避免对特定云提供商的依赖,或者由于 IP 地址范围耗尽的挑战,从底层 VPC 分配 Pod IP 会出现问题,或者 Amazon VPC CNI 插件支持的每个节点的最大 Pod 数量不足以满足根据您的需求,我们建议在跨子网覆盖模式下使用 Calico 网络。 Pod IP 无法在集群外部路由,但您可以将集群扩展到 Kubernetes 的限制,而不依赖于底层云网络。
Azure
如果您希望 Pod IP 地址可在集群外部路由,则必须使用 Azure CNI 插件。这是由 AKS 支持的,并使用 Calico 进行网络策略。 Pod IP 地址是从底层 VNET 分配的。
如果想要使用 AKS,但由于 IP 地址范围耗尽的挑战,从底层 VNET 分配 Pod IP 会出现问题,则可以将 Calico 与 Azure 云提供商集成结合使用。这使用主机本地 IPAM 为每个节点分配 /24,并在集群的底层 VNET 子网内为这些 /24 编程路由。 Pod IP 在集群/VNET 子网之外不可路由,因此如果需要,可以跨多个集群使用相同的 Pod IP 地址范围 (CIDR)。
在一些 AKS 文档中,这被称为 kubenet + Calico,但它实际上是 Azure 云提供商的 Calico CNI,并且不使用 kubenet 插件。
Google Cloud
如果您希望 Pod IP 地址可在集群外部路由,则必须将 Google 云提供商集成与主机本地 IPAM CNI 插件结合使用。这由 GKE 支持,并使用 Calico 进行网络策略。 Pod IP 地址是从底层 VPC 分配的,相应的 Alias IP 地址会自动分配给节点。
如果您希望避免依赖于特定云提供商,或者由于 IP 地址范围耗尽的挑战,从底层 VPC 分配 Pod IP 会出现问题,我们建议在覆盖模式下使用 Calico 网络。由于Google云网络是纯L3网络,不支持跨子网模式。 Pod IP 无法在集群外部路由,但您可以将集群扩展到 Kubernetes 的限制,而不依赖于底层云网络。
IBM Cloud
如果您使用 IBM Cloud,那么我们建议使用 IKS,它内置了 Calico 以提供跨子网 IP-in-IP 覆盖。除了为 Pod 提供网络策略之外,IKS 还使用 Calico 网络策略来保护集群内的主机节点。
任何地方
上面的环境列表显然并不详尽。了解本指南中的概念和解释有望帮助您找出适合您环境的内容。如果您仍然不确定,可以通过 Calico 用户的 Slack 或 Discourse 论坛寻求建议。
请记住,如果您想开始使用而不必太担心不同的选项,那么您几乎可以在任何环境中以 VXLAN 覆盖模式运行 Calico。