比较 GKE 中的网络模型

Autopilot Standard

---

本文档描述了 Google Kubernetes Engine (GKE) 使用的网络模型，以及它与其他 Kubernetes 环境中的网络模型有何不同。本文档介绍了以下概念：

• 各种 Kubernetes 实现使用的最常见网络模型。
• 最常见的网络模型的 IP 地址机制。
• 每种网络模型的优缺点。
• GKE 使用的默认网络模型的详细说明。

本文档适用于可能熟悉其他 Kubernetes 实现并计划使用 GKE 的云架构师、运维工程师和网络工程师。本文档假定您熟悉 Kubernetes 及其基本网络模型。您还应该熟悉 IP 寻址、网络地址转换 (NAT)、防火墙和代理等网络概念。

本文档未介绍如何修改默认 GKE 网络模型以满足各种 IP 地址限制条件。如果您在迁移到 GKE 时 IP 地址不足，请参阅迁移到 GKE 时的 IP 地址管理策略。

注意：本文档介绍了其他云环境（例如 Amazon Web Services、Microsoft Azure 和 Oracle® Cloud Infrastructure）中 Kubernetes 网络模型的实现。这些实现可能会发生变化，恕不另行通知。如需了解最新的实现信息，请参阅这些供应商提供的文档。

典型的网络模型实现

您可以通过各种方式实现 Kubernetes 网络模型。但是，任何实现都始终需要满足以下要求：

• 每个 Pod 都需要唯一的 IP 地址。
• Pod 无需使用 NAT 即可与所有节点上的其他 Pod 通信。
• 节点上的代理（例如 kubelet）可以与该节点上的所有 Pod 通信。
• 节点托管网络上的 Pod 可与所有节点上的所有 Pod 通信，而无需使用 NAT。

有 20 多种不同的 Kubernetes 网络模型实现可以满足这些要求。

这些实现可以分为三种类型的网络模型。这三种模型的不同体现在以下方面：

• Pod 如何与公司网络上的非 Kubernetes 服务通信。
• Pod 如何与同一组织中的其他 Kubernetes 集群通信。
• 集群外部的通信是否需要 NAT。
• Pod IP 地址是否可以在其他集群或企业网络中的其他位置重复使用。

每个云服务商都实现了上述一个或多个模型类型。

下表列出了三种常用的模型类型，以及使用这些模型的 Kubernetes 实现：

网络模型名称	用于这些实现
完全集成或平面	GKE Amazon Elastic Kubernetes Service (EKS) 使用 Azure CNI（高级）网络时的 Azure Kubernetes 服务 (AKS)
Island-mode或网桥模式	使用默认的 Kubenet（基本）网络时的 Azure Kubernetes Service (AKS) Oracle Container Engine for Kubernetes (OKE) 许多本地 Kubernetes 实现
隔离或气隙隔离	不常用于 Kubernetes 实现，但当集群部署在单独的网络或虚拟私有云 (VPC) 中时，可用于任何实现

本文档在介绍这些网络模型时会说明其对连接的本地网络的影响。但是，您可以将针对连接的本地网络描述的概念应用于通过虚拟专用网 (VPN) 或专用互连（包括与其他云提供商的连接）连接的网络。对于 GKE，这些连接包括通过 Cloud VPN 或 Cloud Interconnect 的所有连接。

完全集成的网络模型

完全集成的网络（或平面）模型可让您轻松地与 Kubernetes 外部以及其他 Kubernetes 集群中的应用进行通信。主要的云服务提供商通常会实现此模型，因为这些提供商可以将其 Kubernetes 实现与其软件定义网络 (SDN) 紧密集成。

使用完全集成的模型时，用于 Pod 的 IP 地址会在 Kubernetes 集群所在的网络中路由。此外，底层网络知道 Pod IP 地址位于哪个节点上。在许多实现中，同一节点上的 Pod IP 地址来自预先分配的特定 Pod IP 地址范围。但是，此预先分配的地址范围不是必需的。

下图展示了完全集成的网络模型中的 Pod 通信选项：

上面的完全集成的网络模型图表显示了以下通信模式：

• Kubernetes 集群中的 Pod 可以直接相互通信。
• Pod 可以与其他集群中的其他 Pod 通信，前提是这些集群位于同一网络中。
• Pod 不需要 NAT 即可与集群外部的其他应用进行通信，无论这些应用是位于同一网络还是互连的网络中。

该图还显示，不同集群的 Pod IP 地址范围也不同。

完全集成的网络模型可用于以下实现：

• 默认情况下，GKE 会实现此模型。如需详细了解此实现，请参阅本文档后面的 GKE 网络模型。
• 默认情况下，Amazon EKS 会实现此模型。在此实现中，Amazon EKS 使用适用于 Kubernetes 的 Amazon VPC Container Networking 接口 (CNI) 插件直接从 VPC 地址空间分配 Pod IP 地址。CNI 插件从节点所在的默认子网或自定义子网分配 IP 地址。Pod IP 地址并非来自每个节点的专用 Pod IP 地址范围。
• 在 Azure 中，AKS 在使用 Azure CNI（高级网络）时实现此模型。此实现不是默认配置。在此实现中，每个 Pod 都会从子网获取 IP 地址。您还可以配置每个节点的最大 Pod 数量。因此，该节点上 Pod 的预留 IP 地址数量与每个节点的最大 Pod 数量相同。

使用完全集成的网络模型有以下优势：

• 更好的遥测数据。Pod IP 地址在网络中可见。这种可见性使遥测数据比其他模型中的数据更有用，因为即使在从集群外部收集的遥测数据中，也可以识别 Pod。
• 更容易的防火墙配置。设置防火墙规则时，完全集成的网络模型比其他模型更容易区分节点和 Pod 流量。
• 更好的兼容性。Pod 可以使用不支持 NAT 的协议进行通信。
• 更好的调试功能。如果防火墙允许，集群外部的资源可以在调试过程中直接访问 Pod。
• 与服务网格的兼容性。Istio 或 Cloud Service Mesh 等服务网格可以轻松跨集群进行通信，因为 Pod 可以直接相互通信。某些服务网格实现仅支持多集群服务网格的 Pod 到 Pod 连接。

使用完全集成的网络模型有以下缺点：

• IP 地址使用。您无法重复使用网络中的 Pod IP 地址，并且每个 IP 地址必须是唯一的。这些要求可能会导致大量 IP 地址需要为 Pod 预留。
• SDN 要求。完全集成的网络模型需要与底层网络的深度集成，因为 Kubernetes 实现需要直接对 SDN 进行编程。SDN 编程对用户来说是透明的，不会产生任何面向用户的缺点。但是，此类深度集成的网络模型无法在自行管理的本地环境中轻松实现。

孤岛模式网络模型

孤岛模式网络模型（或网桥模式）通常用于无法与底层网络进行深度集成的本地 Kubernetes 实现。使用孤岛模式网络模型时，Kubernetes 集群中的 Pod 可以通过某种网关或代理与集群外部的资源进行通信。

下图展示了孤岛模式网络模型中的 Pod 通信选项：

上面的孤岛模式网络模型示意图展示了 Kubernetes 集群中的 Pod 如何直接相互通信。该图还显示，在与集群外部的应用或其他集群中的 Pod 通信时，集群中的 Pod 需要使用网关或代理。集群和外部应用之间的通信需要单个网关，而集群到集群的通信需要两个网关。两个集群之间的流量在离开第一个集群时通过网关，在进入另一个集群时通过另一个网关。

在隔离的网络模型中实现网关或代理有不同的方法。以下实现是两种最常见的网关或代理：

• 使用节点作为网关。当集群中的节点是现有网络的一部分，并且其 IP 地址在此网络中原生可路由时，通常使用此实现。在这种情况下，节点本身就是网关，这些网关提供从集群内部到更大的网络的连接。从 Pod 到集群外部的出站流量可以定向到其他集群或非 Kubernetes 应用，例如调用公司网络上的本地 API。对于此出站流量，包含 Pod 的节点使用来源 NAT (SNAT) 将 Pod 的 IP 地址映射到节点 IP 地址。如需允许集群外部的应用与集群中的 Service 通信，您可以将 NodePort 服务类型用于大多数实现。在某些实现中，您可以使用 LoadBalancer 服务类型来公开 Service。使用 LoadBalancer 服务类型时，您可以为这些 Service 提供一个虚拟 IP 地址，该地址在节点之间负载均衡并路由到作为 Service 一部分的 Pod。

  下图展示了将节点用作网关时的实现模式：

  

  上图显示将节点用作网关对集群内的 Pod 间通信没有影响。集群中的 Pod 仍会直接相互通信。但是，该图还显示了集群外部的以下通信模式：

  • Pod 如何在离开节点时使用 SNAT 与其他集群或非 Kubernetes 应用进行通信。
  • 来自其他集群或非 Kubernetes 应用的外部 Service 的流量如何通过 NodePort Service 进入集群，然后再转发到集群中的正确 Pod。

• 使用具有多个网络接口的代理虚拟机 (VM)。此实现模式使用代理访问包含 Kubernetes 集群的网络。代理必须有权访问 Pod 和节点 IP 地址空间。在此模式中，每个代理虚拟机有两个网络接口：一个接口位于较大的企业网络中，另一个接口位于包含 Kubernetes 集群的网络中。

  下图显示了使用代理虚拟机时的实现模式：

  

  上图显示，在孤岛模式下使用代理不会影响集群内的通信。集群中的 Pod 仍然可以彼此直接通信。但是，该图还显示了从 Pod 到其他集群或非 Kubernetes 应用的通信如何通过可访问集群网络和目标网络的代理。此外，从外部进入集群的通信也会通过相同类型的代理。

孤岛模式网络模型可用于以下实现：

• 默认情况下，当使用 Kubenet（基本）网络时，Azure Kubernetes Service (AKS) 使用孤岛模式网络。当 AKS 使用孤岛模式网络时，包含集群的虚拟网络仅包含节点 IP 地址。Pod IP 地址不属于虚拟网络。相反，Pod 会从其他逻辑空间接收 IP 地址。AKS 使用的孤岛模式模型还通过使用用户定义的路由并在节点接口上激活 IP 转发来路由节点之间的 Pod 到 Pod 流量。对于 Pod 与集群外部资源的通信，在出站流量离开节点之前，节点会使用 SNAT 将 Pod IP 地址映射到节点 IP 地址。
• 在 Oracle Container Engine for Kubernetes (OKE) 中，Pod 到 Pod 通信使用 VXLAN 叠加网络。此外，从 Pod 到集群外部的应用的流量使用 SNAT 将 Pod IP 地址映射到节点 IP 地址。

使用孤岛模式网络模型有以下优势：

• IP 地址使用。集群中的 Pod IP 地址可以在其他集群中重复使用。但是，如果 Pod 与企业网络中的外部服务之间需要进行通信，则已被这些服务使用 IP 地址不能用于 Pod。因此，孤岛模式网络的最佳实践是预留网络中唯一的 Pod IP 地址空间，并对所有集群使用此 IP 地址空间。
• 更轻松的安全设置。由于 Pod 不会直接公开到企业网络的其余部分，因此您无需保护 Pod 免受来自企业网络其余部分的入站流量的影响。

使用孤岛模式网络模型有以下缺点：

• 遥测数据不精确。从集群外部收集的遥测数据仅包含节点 IP 地址，不包含 Pod IP 地址。如果缺少 Pod IP 地址，则很难识别流量来源和目的地。
• 调试更困难。调试时，您无法从集群外部直接连接到 Pod。
• 防火墙的配置更困难。只有在配置防火墙时，才能使用节点 IP 地址。因此，生成的防火墙设置允许节点上的所有 Pod 以及节点本身访问外部服务，或者不允许它们访问外部服务。

• 与服务网格的兼容性。使用孤岛模式时，跨服务网格（例如 Istio 或 Cloud Service Mesh）中集群的直接 Pod 到 Pod 通信无法实现。

  某些服务网格实现还存在进一步限制。对 Google Cloud 上的 GKE 集群的 Cloud Service Mesh 多集群支持仅对同一网络上的集群有效。对于支持多网络模型的 Istio 实现，必须通过 Istio 网关进行通信，从而使多集群服务网格部署变得更复杂。

隔离网络模型

隔离（或网闸隔离）网络模型最常用于不需要访问更大的公司网络的集群（除非通过面向公众的 API）。使用隔离网络模型时，每个 Kubernetes 集群都是独立的，并且无法使用内部 IP 地址与网络的其余部分通信。集群位于其专用网络上。如果集群中的任何 Pod 需要与集群外部的服务进行通信，则此通信需要为入站流量和出站流量使用公共 IP 地址。

下图展示了隔离网络模型中的 Pod 通信选项：

上面的隔离网络模型示意图展示了 Kubernetes 集群中的 Pod 可以直接相互通信。该图还显示，Pod 无法使用内部 IP 地址与其他集群中的 Pod 通信。此外，Pod 只有在满足以下条件时才能与集群外部的应用通信：

• 有一个将集群连接到外部的互联网网关。
• 外部应用使用外部 IP 地址进行通信。

最后，上图显示了如何在不同的环境之间重复使用 Pod 和节点的同一 IP 地址空间。

Kubernetes 实现通常不使用隔离网络模型。但是，您可以在任何实现中实施隔离网络模型。您只需在单独的网络或 VPC 中部署 Kubernetes 集群，而无需连接到其他服务或企业网络。生成的实现具有与隔离网络模型相同的优缺点。

使用隔离网络模式有以下优势：

• IP 地址使用。您可以重复使用集群中的所有内部 IP 地址：节点 IP 地址、Service IP 地址和 Pod IP 地址。可以重复使用内部 IP 地址是因为每个集群都有自己的专用网络，并且与集群外部资源的通信只能通过公共 IP 地址进行。
• 控制。集群管理员可以完全控制集群中的 IP 地址，并且无需执行任何 IP 地址管理任务。例如，管理员可以将完整的 10.0.0.0/8 地址空间分配给集群中的 Pod 和 Service，即使这些地址已在组织中使用也是如此。
• 安全性。集群外部的通信受到严格控制，并在允许的情况下使用明确定义的外部接口和 NAT。

使用隔离网络模型有以下缺点：

• 无私密通信。不允许使用内部 IP 地址与网络中的其他集群或其他服务进行通信。

GKE 网络模型

GKE 使用完全集成的网络模型，在该模型中，集群部署在虚拟私有云 (VPC) 网络中，该网络也可以包含其他应用。

我们建议您为 GKE 环境使用 VPC 原生集群。您可以在 Standard 或 Autopilot 模式下创建 VPC 原生集群。如果您选择 Autopilot 模式，VPC 原生模式始终开启，且无法关闭。以下段落介绍了 Standard 模式下的 GKE 网络模型，以及有关 Autopilot 差异的说明。

VPC 原生集群中的 IP 地址管理

使用 VPC 原生集群时，Pod IP 地址是每个节点上的次要 IP 地址。每个节点都分配有一个 Pod IP 地址范围的特定子网，该子网是您在创建集群时从内部 IP 地址空间中选择的。默认情况下，VPC 原生集群会为每个节点分配一个 /24 子网，以用作 Pod IP 地址。/24 子网对应于 256 个 IP 地址。在 Autopilot 模式下，集群使用对应于 64 个地址的 /26 子网，您无法更改此子网设置。

GKE 网络模型不允许在整个网络中重复使用 IP 地址。迁移到 GKE 时，您必须规划 IP 地址分配，以减少 GKE 中的内部 IP 地址用量。

由于 Pod IP 地址在 VPC 网络中可路由，因此默认情况下 Pod 可以从以下资源接收流量：

• VPC 网络中的其他服务。
• 通过 VPC 网络对等互连连接的 VPC 网络。
• 通过 Cloud VPN 或 Cloud Interconnect 连接的本地网络。

使用 IP 伪装代理管理外部流量通信

从 Pod 与集群外部的服务进行通信时，IP 地址伪装代理会控制流量对这些服务的显示方式。IP 地址伪装代理处理专用和外部 IP 地址的方式不同，如以下项目符号列表所述：

• 默认情况下，IP 地址伪装代理不会伪装流向内部 IP 地址（包括 RFC 1918 IP 地址以及内部常用的非 RFC 1918 IP 地址）的流量。如需了解详情，请参阅默认非伪装目标的列表。由于内部 IP 地址未被伪装，因此节点不会对这些地址使用 NAT。
• 对于外部 IP 地址，IP 地址伪装代理会将这些地址伪装成节点 IP 地址。因此，这些伪装的地址会被 Cloud NAT 转换为外部 IP 地址，或者转换为虚拟机 (VM) 实例的外部 IP 地址。

您还可以在 VPC 网络或连接的网络中使用以非公开方式使用的公共 IP (PUPI) 地址。如果您使用 PUPI 地址，您仍然可以从完全集成的网络模型中受益，并直接将 Pod IP 地址视为来源。如需实现这两个目标，您必须在 nonMasqueradeCIDRs 列表中添加 PUPI 地址。

了解 GKE 网络中的 Pod 流量

下图展示了 Pod 如何在 GKE 网络模型中进行通信：

上图显示了 GKE 环境中的 Pod 如何使用内部 IP 地址直接与以下资源进行通信：

• 同一集群中的其他 Pod。
• 同一 VPC 网络中其他 GKE 集群的 Pod。
• 同一 VPC 网络中的其他 Google Cloud 应用。
• 通过 Cloud VPN 连接的本地应用。

该图还显示了当 Pod 需要使用外部 IP 地址与应用通信时会发生什么情况。当流量离开节点时，Pod 所在的节点会使用 SNAT 将 Pod 的 IP 地址映射到节点的 IP 地址。流量离开节点后，Cloud NAT 会将节点的 IP 地址转换为外部 IP 地址。

为了获得本文档前面介绍的优势（尤其是使 Pod IP 地址在所有遥测数据中可见的优势），Google 选择了完全集成的网络模型。在 GKE 中，Pod IP 地址在 VPC 流日志（包括元数据中的 Pod 名称）、数据包镜像、防火墙规则日志记录以及您自己的应用日志中对非伪装目标公开。

后续步骤

• 了解迁移到 GKE 时的 IP 地址管理策略
• 了解 GKE 网络最佳实践
• 比较 AWS 和 Azure 服务和 Google Cloud
• 阅读将容器迁移到 Google Cloud：将 Kubernetes 迁移到 GKE