迁移到 GKE 时规划 IP 地址

本文档介绍了如何管理 Google Kubernetes Engine (GKE) 上的 IP 地址使用情况，以及如何根据需要在 GKE 中使用替代网络模型。本文档介绍了以下概念：

  • 如何减少 GKE 中 Pod IP 地址的用量，使 GKE 满足大多数组织的 IP 地址需求。
  • 当集群架构不符合您的组织的要求时，如何在 GKE 上实现替代网络模型。

本文档面向计划将 Kubernetes 集群从其他环境迁移到 GKE 的云架构师、运营工程师和网络工程师。当您的组织发现难以为您预期的 GKE 使用情况分配内部 IP 地址时，请参阅本文档中的指导信息。

本文档假定您熟悉 Kubernetes 及其网络模型。您还应该熟悉 IP 寻址、网络地址转换 (NAT)、防火墙和代理等网络概念。

本文档不介绍用于 Service IP 地址的地址范围的相关管理策略。 Service 所需的地址数量要比 Pod 少得多，减少此数量的选项有限。在 GKE 上，Service IP 地址范围在集群的生命周期内是固定的。因此，Service IP 地址范围的大小需要调整到预期的最大 Service 数量。由于 Service IP 地址在集群外部无法访问，因此您可以在其他网络中重复使用这些地址。

本文档还介绍了不同的 Kubernetes 网络模型：完全集成、孤岛模式和隔离。这些模型在如何到达整个网络中的 Pod IP 地址方面有所不同。这些差异会影响可以使用的 IP 地址管理策略。如需详细了解这些模型和 GKE 网络模型，请参阅 GKE 和其他 Kubernetes 实现使用的网络模型比较。

减少 GKE 中的内部 IP 地址用量

GKE 使用完全集成的网络模型，其中集群部署在 VPC 网络中，该网络也可以包含其他应用。GKE 模型具有多种优势。但是，这种类型的模型不允许重复使用 Pod IP 地址。如果不重复使用，您使用的 Pod IP 地址需要在整个 VPC 网络中唯一。因此，您必须仔细考虑您需要多少个唯一的 IP 地址。

您需要的唯一地址数量会影响您是否需要减少 IP 地址用量，如下所示：

  • 如果您有足够的地址空间来满足您的 IP 地址需求，则不一定需要采取措施减少 IP 地址用量。但是，了解如何减少 IP 地址用量有助于确定要使用的 IP 地址数量下限。
  • 如果您没有足够的地址空间，则需要减少 IP 地址用量，才能创建满足地址空间限制的 GKE 集群。

为了减少 GKE 中的 IP 地址用量，请考虑以下选项：

  • 更改“每个节点的 Pod 数量”设置。默认情况下，GKE Standard 集群会为每个节点预留一个 /24 子网范围，最多可以允许每个节点有 110 个 Pod。如果您预计每个节点仅使用 64 个或更少的 Pod，则可以调整每个节点的最大 Pod 数，从而将 Pod IP 地址用量减少一半或以上。 Autopilot 集群允许每个节点 32 个 Pod，并且此设置无法更改。
  • 使用多个 Pod IP 地址范围。使用不连续的多 Pod 无类别域间路由 (CIDR)，您可以向现有集群添加次要 Pod IP 地址范围。您可以选择每个节点池使用的 Pod IP 地址范围。通过选择每个池使用的 IP 地址范围，您可以在分配初始 Pod IP 地址空间时留有余地，同时仍能增加集群。

  • 使用非 RFC 1918 IP 地址。您的企业网络可能没有足够的未分配 RFC 1918 IP 地址用于 Pod IP 地址。如果您没有足够的未分配 RFC 1918 IP 地址，则可以使用非 RFC 1918 地址，例如 RFC 6598 地址空间中的地址 (100.64.0.0/10)。

    如果您已在企业网络中的其他位置使用 RFC 6598 空间，则可以将 Class E/RFC 5735 (240.0.0.0/4) 地址空间用于 Pod IP 地址。但是，来自这些 IP 地址的流量在 Windows 主机和一些本地硬件上会被屏蔽。为避免屏蔽 RFC 5735 地址，请考虑将流量伪装成这些外部目的地，如仅隐藏本地网络中的 Pod IP 地址部分中所述。但是，在将流量伪装成外部目的地时，会丢失一些定向到本地应用的遥测数据。

如果您的组织具有大型公共 IP 地址空间，您还可以使用以非公开方式使用的公共 IP (PUPI) 地址。使用 PUPI 地址时，您必须在 nonMasqueradeCIDRs 列表中添加 PUPI 地址才能不使用 NAT 在集群外部进行连接。

在 GKE 中选择网络模型

GKE 网络模型上的文档讨论了 Standard 集群在 GKE 中的工作原理，包括所涉及的 Pod IP 地址。在本文档中，减少 GKE 中的内部 IP 地址用量部分介绍了如何减少这些集群中所需的内部 IP 地址数量。了解 GKE 网络模型的工作原理以及如何减少内部 IP 地址是 GKE 中使用的任何网络模型的基础。

但是，仅仅知道和应用这些概念可能无法为您提供满足需求的网络实现。您可以借助以下决策树来确定如何实现最适合您的 GKE 网络模型：

GKE 中 IP 地址缓解策略的决策树。

决策树始终从创建基于完全集成网络模型的 GKE Standard 集群开始。 树中的下一步是应用本文档中所述的所有选项，以减少 IP 地址用量。

如果您尽可能减少 IP 地址用量，但仍没有足够的 GKE 集群地址空间，则需要替代网络模型。决策树可帮助您确定使用以下哪种可选网络模型：

请注意，此决策树仅供参考。根据具体用例，您可能仍会根据每个模型的优缺点来选择另一个模型。通常，多个模型都可用，您可以选择更适合组织的方法。

在极少数情况下，决策树中提供的备用模型无法满足您的需求。对于这些罕见的情况，您可以使用使用多 NIC 实例来隐藏集群地址中所述的模型。

模拟替代网络模型

为充分利用完全集成的网络模型的优势，我们建议您将 GKE 集群与其他云资源置于同一逻辑网络中。但是，您可能无法遵循此建议。您的 IP 地址空间可能不足，或者您可能需要从组织的较大网络中隐藏 Pod IP 地址。

本部分通过描述模仿 GKE 上各种替代网络模型的不同架构模式，提供使用完全集成网络模型的选项。这些替代架构模式为 GKE 创建了一个类似于孤岛模式网络模型或隔离模式网络模型的操作模式。

每个替代架构模式都包含以下信息：

仅隐藏来自本地网络的 Pod IP 地址

向本地网络隐藏 IP 地址所用的架构模式使用了以下路由目标组合：

  • 让 Google Cloud 上的 GKE 集群分配在整个 Google Cloud 部署中路由的 Pod IP 地址。
  • 防止这些 IP 地址在没有 NAT 的情况下路由到本地资源或者通过 Cloud VPN 或 Cloud Interconnect 路由到其他云环境。

此架构模式通常与 Class E/RFC 5735 IP 地址空间一起使用，因为此空间包含许多 IP 地址。有太多可用 IP 地址有助于满足为每个 Pod 提供唯一 IP 地址的需求。但是，Class E/RFC 5735 IP 地址无法轻松路由到本地资源，因为许多网络硬件供应商会屏蔽此流量。

您可以使用 RFC 1918 IP 地址或内部非 RFC 1918 IP 地址集，而不是使用 Class E/RFC 5735 IP 地址空间。如果您使用其他一组 IP 地址，请确定用于 Pod 的 IP 地址与本地网络中使用的 IP 地址之间是否存在 IP 地址重叠。如果存在重叠，请确保使用这些地址的集群与使用相同地址的本地应用之间不存在任何通信。

以下步骤概述了如何设置此架构模式：

  1. 为 Pod 子网创建次要 IP 地址范围。如本部分前面所述，您可以使用 Class E/RFC 5735 类、RFC 1918 空间或一组内部非 RFC 1918 IP 地址创建此地址范围。通常使用 Class E/RFC 5735 空间。
  2. 使用自定义通告路由，并从 Cloud Router 上的通告中移除 Pod IP 地址范围。移除这些地址有助于确保没有通过边界网关协议 (BGP) 向您的本地路由器公布 Pod IP 范围。
  3. 使用次要 IP 地址范围作为 Pod 的无类别域间路由 (CIDR) 来创建 GKE 集群。您可以使用减少 GKE 中的内部 IP 地址用量中描述的策略来减少 IP 地址用量。

  4. 将以下 IP 地址添加到伪装代理中的 nonMasqueradeCIDRs 列表：

    • 用于 Pod 的 IP 地址范围。
    • 用于节点的 IP 地址范围。
    • 仅在 Google Cloud 上使用的其他 IP 地址，例如 Google Cloud 上使用的主要 IP 地址范围。

    请勿添加本地环境或其他云环境中使用的内部 IP 地址范围。如果您在 Google Cloud 中具有 Windows 工作负载，请将这些工作负载保存在单独的子网中，请勿包含这些范围。

使用上述步骤设置此模式时，您可以将集群配置为具有以下行为：

  • 充当 Google Cloud 中完全集成的网络模型。
  • 与本地网络交互时，充当孤岛模式网络模型。

如需让此备用模式完全模拟孤岛模式网络模型，您需要将伪装代理中的 nonMasqueradeCIDRs 列表更改为仅包含集群的节点和 Pod IP 地址范围。创建此类列表始终会将集群外部的流量伪装成节点 IP 地址，即使在 Google Cloud 内部也是如此。但是，执行此更改后，您无法在 VPC 网络中收集 Pod 级遥测数据。

下图展示了此架构模式的实现：

显示仅从本地网络隐藏 IP 地址的网络图。

上图展示了如何对外部网络隐藏 Pod IP 地址。如图所示，Google Cloud 中的 Pod 可以直接相互通信，甚至可以在集群之间通信。此 Pod 通信类似于 GKE 模型。请注意，该图还展示了 Pod 使用 Class E/RFC 5735 空间中的地址。

对于发送到集群外部的流量，该图显示了来源 NAT (SNAT) 在流量离开节点时如何应用于该流量。无论该流量通过 Cloud VPN 路由到本地应用，还是通过 Cloud NAT 路由到外部应用，系统都会使用 SNAT。

此架构模式使用 Pod IP 地址在 Google Cloud 内进行通信。仅在定向到本地应用或其他云环境时才会伪装流量。虽然您无法直接从本地应用连接到 Pod，但可以连接到通过内部负载均衡公开的服务。

向本地网络隐藏 Pod IP 地址具有以下优势：

  • 您仍然可以利用 Google Cloud 中完全集成的网络模型，例如使用防火墙和基于 Pod IP 地址收集遥测数据。此外，您还可以直接从 Google Cloud 连接到 Pod 以进行调试。
  • 您仍然可以在 Google Cloud 中使用具有 Pod IP 地址的多集群服务网格。

但是，向外部网络隐藏 Pod IP 地址具有以下缺点：

  • 您不能对 Google Cloud 中的不同集群重复使用 Pod 或 Service IP 地址范围。
  • 您可能需要管理两组不同的防火墙规则：一组针对本地网络之间的流量，另一组针对完全在 Google Cloud 中的流量。
  • 您不能在跨 Google Cloud 和本地或其他云服务提供商环境的多集群服务网格中进行直接 Pod 到 Pod 通信。例如，使用 Istio 时，所有通信都必须在 Istio 网关之间进行。

使用 Private Service Connect 隐藏 Pod IP 地址

此架构模式使用 Private Service Connect 隐藏 Pod IP 地址。如果您有以下需求，请使用此架构模式：

  • 您只需要从 GKE 集群中公开有限数量的 Service。
  • 您的 GKE 集群可以独立工作，不需要与公司网络中的许多应用进行出站通信。

Private Service Connect 提供了发布要从其他网络使用的服务的方法。您可以使用内部直通网络负载均衡器和服务连接公开 GKE Service，并使用其他 VPC 网络中的端点使用这些服务。

以下步骤概述了如何设置此架构模式：

  1. 在单独的 VPC 网络中，创建一个 GKE 集群。VPC 网络应仅包含该集群。
  2. 对于集群中需要从其他 VPC 网络中的其他集群或应用访问的每个 GKE Service，请使用 Private Service Connect 创建内部直通网络负载均衡器。

  3. （可选）如果您的 GKE 集群需要与公司网络中的某些应用进行出站通信，请通过 Private Service Connect 发布服务以公开这些应用。

    下图展示了此架构模式的实现：

网络图表显示如何使用 Private Service Connect 实现隐藏 IP 地址。

上图展示了 Private Service Connect 模型中的群集内部和之间的通信类似于隔离网络模型。但是，允许的通信通过 Private Service Connect 端点进行，而不是通过公共 IP 地址。如图所示，每个集群都有自己的单独 VPC 网络。此外，每个 VPC 网络可以共享同一 IP 地址，每个集群可以共享同一 IP 地址空间。只有集群中的 Pod 才能彼此直接通信。

对于来自集群外部的通信，该图展示了外部应用如何通过 Private Service Connect 端点访问集群。该端点连接到集群 VPC 网络中服务提供方提供的服务连接。集群之间的通信也通过 Private Service Connect 端点和服务提供方的服务连接进行。

使用 Private Service Connect 隐藏 Pod IP 地址具有以下优势：

  • 您无需规划 IP 地址，因为 GKE 集群的 IP 地址空间对网络的其余部分隐藏。此方法仅向使用中的 VPC 网络公开每个服务的单一 IP 地址。
  • 保护集群更容易，因为此模型明确定义了公开的服务，并且只能从 VPC 网络的其余部分访问这些公开的服务。

但是，使用 Private Service Connect 隐藏 Pod IP 地址具有以下缺点：

  • 集群内的 Pod 无法在集群外部建立私密通信。Pod 只能与公共服务（当 Pod 具有互联网连接时）或 Google API（通过使用专用 Google 访问通道）通信。如果集群外部的服务通过 Private Service Connect 公开，则 Pod 也可以访问这些服务。但是，并非所有内部服务提供商都会创建服务连接。因此，只有在这些服务的数量受实际提供连接的提供商的限制时，才能使用 Private Service Connect。
  • 只能从服务所在的区域访问端点。此外，这些端点只能从连接的 VPC 网络本身访问，而不能从对等互连的 VPC 网络或通过 Cloud VPN 或 Cloud Interconnect 连接的网络访问。

使用 Cloud VPN 隐藏 Pod IP 地址

此架构模式使用 Cloud VPN 在 GKE 集群和主 VPC 网络之间实现隔离。创建这种隔离时，生成的网络的功能类似于孤岛模式网络模型。与孤岛模式模型一样，此模式可为您提供在集群之间重复使用 Pod 和 Service IP 地址范围的优势。可以重复使用，因为与集群外部的应用通信使用 SNAT。节点在流量退出节点之前，使用 SNAT 将 Pod IP 地址映射到自己的节点 IP 地址。

以下步骤概述了如何设置此模型：

  1. 在单独的 VPC 网络中，创建一个 GKE 集群。VPC 网络应仅包含该集群。

    对于集群，请使用公共 IP 地址分配的未使用部分来定义两个 IP 地址范围：一个用于 Pod，另一个用于 Service。根据您预期使用的最大 GKE 集群的需求调整这些 IP 地址范围的大小。请保留每个范围，以便在 GKE 中独占使用。您还可以将这些范围重复用于组织中的所有 GKE 集群。

    有时，预留此类较大范围的 IP 地址是无法实现的。您的组织可能已经为其他应用使用了 Pod 和/或 Service IP 地址范围。如果该 IP 地址范围正在使用中且无法预留，请确保使用这些 IP 地址的应用无需与 GKE 集群通信。

  2. 对于您刚刚创建的集群，请将伪装代理中的 nonMasqueradeCIDRs 列表配置为包含集群节点和 Pod IP 地址范围的列表。此列表会导致 GKE 始终伪装离开集群前往节点 IP 地址的流量，即使在 Google Cloud 内部也是如此。

  3. 使用 Cloud VPN 将包含 GKE 集群的 VPC 网络连接到现有（主）VPC 网络。

  4. 使用自定义通告路由会阻止集群的 VPC 网络通告定向到您的主 VPC 网络的 Pod 和 Service IP 地址范围。

  5. 对所需的其他 GKE 集群重复第 1-4 步。对于所有集群，请为 Pod 和 Service 使用相同的 IP 地址范围。但是，请为每个节点使用不同的 IP 地址。

  6. 如果您通过 Cloud VPN 或 Cloud Interconnect 连接到本地网络，请使用自定义通告路由手动通告节点 IP 地址范围。

  7. 如果您已通过 VPC 网络对等互连将其他网络连接到主 VPC 网络，请在这些对等互连上导出自定义路由，以确保 GKE 集群节点可以访问对等互连网络。

下图展示了如何实现使用 Cloud VPN 隐藏 Pod IP 地址：

网络图表展示如何使用 Cloud VPN 隐藏 IP 地址。

上图展示了如何使用 Cloud VPN 隐藏 Pod IP 地址，这会创建一个类似于孤岛模式网络模型的方法。如图所示，每个 GKE 集群都有自己单独的 VPC 网络。每个网络都有一个不同的节点 IP 地址空间，但使用相同的 Pod IP 地址空间。Cloud VPN 隧道将这些 VPC 网络相互连接并连接到公司网络，并且不会从包含集群的 VPC 网络通告 Pod IP 地址空间。

请注意，在该图中，只有集群中的 Pod 可以直接相互通信。节点在集群外部与其他集群、公司网络或连接的本地网络通信时，使用 SNAT 伪装 Pod IP 地址空间。您无法直接从其他集群或公司网络访问 Pod。通过 Cloud VPN 连接，只能访问使用内部负载均衡器公开的集群 Service。

使用 Cloud VPN 隐藏 Pod IP 地址具有以下优势：

  • 如孤岛模式网络模型中所述，您可以在集群之间重复使用 Pod 和 Service IP 地址范围。
  • 防火墙需要的配置可能较少，因为无法直接从主 VPC 网络和连接的网络访问 Pod IP 地址。因此，您无需配置显式防火墙规则即可阻止与 Pod 的通信。

但是，使用 Cloud VPN 隐藏 Pod IP 地址具有以下缺点：

  • 孤岛模式网络模型中提到的相同缺点适用。例如，您无法在 Pod 级层设置防火墙规则。您无法在主 VPC 网络或连接的网络中在 Pod 级层收集遥测数据。
  • 与默认 GKE 网络模型相比，此模式会产生额外的费用：与 Cloud VPN 隧道相关的费用和数据传输费用。
  • Cloud VPN 对每个 VPN 隧道具有带宽限制。如果达到此带宽限制，您可以使用等价多路径 (ECMP) 配置多个 Cloud VPN 隧道并分配流量。但是，执行这些操作会增加设置和维护 GKE 实现的复杂性。
  • 路由通告保持同步会增加集群创建的复杂性。每当创建新的 GKE 集群时，您都需要设置 Cloud VPN 隧道，并在这些隧道上和向本地应用创建自定义通告路由。

通过内部使用的公共 IP 地址和 VPC 网络对等互连来隐藏 Pod IP 地址

如果您的组织拥有未使用的公共 IP 地址，则可以使用此类似于孤岛模式网络模型的架构模式，但需要专用此公共 IP 地址空间。此架构与使用 Cloud VPN 的模型类似，但使用 VPC 网络对等互连在 GKE 集群和主网络之间创建隔离。

以下步骤概述了如何设置此架构模式：

  1. 在单独的 VPC 网络中，创建一个 GKE 集群。VPC 网络应仅包含该集群。

    对于集群，请使用公共 IP 地址分配的未使用部分来定义两个 IP 地址范围：一个用于 Pod，另一个用于 Service。根据您预期使用的最大 GKE 集群的需求调整这些 IP 地址范围的大小。请保留每个范围，以便在 GKE 中独占使用。您还可以将这些范围重复用于组织中的所有 GKE 集群。

    从理论上讲，可以使用第三方拥有的较大、未使用的公共 IP 地址块，而不是使用公共 IP 地址分配。但是，我们强烈建议不要使用此类设置，因为此类 IP 地址可能随时被公开销售或使用。地址的销售或使用会导致在互联网上使用公共服务时出现安全和连接问题。

  2. 对于您刚刚创建的集群，请将伪装代理中的 nonMasqueradeCIDRs 列表配置为包含集群节点和 Pod IP 地址范围的列表。此列表会导致 GKE 始终伪装离开集群前往节点 IP 地址的流量，即使在 Google Cloud 内部也是如此。

  3. 使用 VPC 网络对等互连将包含 GKE 集群的 VPC 网络连接到现有（主）VPC 网络。由于您不希望在此模型中交换 PUPI 地址，因此请在配置对等互连时设置 --no-export-subnet-routes-with-public-ip 标志。

  4. 对所需的其他 GKE 集群重复第 1-3 步。对于所有集群，请为 Pod 和 Service 使用相同的 IP 地址范围。但是，请为每个节点使用不同的 IP 地址。

  5. 如果您通过 Cloud VPN 或 Cloud Interconnect 连接到本地网络，请使用自定义路由通告手动通告节点 IP 地址范围。

下图展示了此架构模式的实现：

网络图表展示如何实现使用 PUPI 和 VPC 网络对等互连隐藏 IP 地址。

上图展示了如何使用 VPC 网络对等互连隐藏 IP 地址。如图所示，每个 GKE 集群都有自己单独的 VPC 网络。每个节点具有不同的节点 IP 地址空间，但使用的 Pod IP 地址空间由组织的 PUPI 地址空间定义。VPC 网络通过 VPC 网络对等互连相互连接并连接到 Google Cloud 中的非 Kubernetes 应用。对等互连之间不会通告 PUPI 地址空间。VPC 网络通过 Cloud VPN 隧道连接到公司网络。

只有集群中的 Pod 才能彼此直接通信。节点在集群外部与其他集群、公司网络或连接的本地网络通信时，使用 SNAT 伪装 Pod IP 空间。您无法直接从其他集群或公司网络访问 Pod。通过 VPC 网络对等互连连接只能访问使用内部负载均衡器公开的 Service。

此架构模式类似于上述 Cloud VPN 方法，但比该模式具有以下优势：

  • 与 Cloud VPN 架构模式不同，VPC 网络对等互连不会因 Cloud VPN 隧道或环境之间的带宽产生任何额外费用。
  • VPC 网络对等互连没有带宽限制，并完全集成到 Google 的软件定义网络中。因此，VPC 网络对等互连提供的延迟时间可能略低于 Cloud VPN，因为对等互连不需要 Cloud VPN 所需的网关和处理。

但是，VPC 网络对等互连模型与 Cloud VPN 模型相比具有以下缺点：

  • 您的组织需要这样一个公共 IP 地址空间，该空间既未使用，又足够大，可满足您预期的最大 GKE 集群所需的 Pod IP 地址空间。
  • VPC 网络对等互连不具有传递性。因此，通过 VPC 网络对等互连连接到主 VPC 网络的 GKE 集群无法直接相互通信，也无法与与主 VPC 对等互连的 VPC 网络中的应用直接通信。您必须通过 VPC 网络对等互连直接连接这些网络，才能启用此类通信，或者使用主 VPC 网络中的代理虚拟机。

使用多 NIC 实例隐藏集群地址

此架构模式包含以下组件和技术，用于创建类似于孤岛模式网络模型的模型：

  • 它使用具有多个网络接口卡（多 NIC）的 Compute Engine 实例在 GKE 集群和主 VPC 网络之间创建隔离层。
  • 它对在这些环境之间发送的 IP 地址使用 NAT。

如果您需要检查、转换或过滤进入或退出 GKE 集群的特定流量，则可以使用此模式。如果您需要执行此类检查、转换或过滤，请使用已部署的 Compute Engine 实例执行这些任务。

使用多 NIC 实例隐藏集群地址具有以下优势：

  • GKE 集群的 IP 地址空间对网络的其余部分隐藏。每项服务只有一个 IP 地址会公开给使用中的 VPC 网络。
  • 服务可在全球范围内访问，也可从连接的本地网络和对等互连网络访问。

但是，使用多 NIC 实例隐藏集群地址具有以下缺点：

  • 此模型的实现比其他方法更复杂，因为它不仅需要实现模型，而且还需要为多 NIC 实例设置监控和日志记录。
  • 多 NIC 实例具有带宽限制，并受虚拟机实例价格约束。
  • 您需要管理和升级多 NIC 实例。

后续步骤