规划大型 GKE 集群

本页面介绍规划和设计规模非常大的集群时可以遵循的最佳实践。

规划大型 GKE 集群的原因

每个计算机系统（包括 Kubernetes）都有一些架构限制。超出限制可能会影响集群的性能，在某些情况下甚至可能导致停机。请遵循最佳实践并执行建议的操作，以确保您的集群可以大规模地可靠运行工作负载。

大型 GKE 集群的限制

当 GKE 将集群扩缩到大量节点时，GKE 会尽力更改可用资源量，以满足您的系统需求，同时保持在服务等级目标 (SLO) 范围内。Google Cloud 支持大型集群。不过，根据您的使用场景，您必须考虑大型集群的限制，以便更好地满足您的基础设施规模要求。

本部分介绍在根据预期节点数量设计大型 GKE 集群时需要注意的限制和注意事项。

最多包含 5,000 个节点的集群

在设计集群架构以扩展到 5,000 个节点时，请考虑以下条件：

如果您预计集群规模会超过 5,000 个节点，请与 Cloud Customer Care 联系，以提高集群规模和配额限制。

节点数超过 5,000 的集群

GKE 支持最多 15,000 个节点的大型 Standard 集群。在 1.31 版及更高版本中，GKE 支持最多 65,000 个节点的大型集群。 65,000 的限制旨在用于运行大规模 AI 工作负载。

如果您预计集群将扩展到 15,000 个或 65,000 个节点，请完成以下任务：

  1. 请考虑以下限制：

    • 不支持集群自动扩缩器。请改用 GKE API 扩缩节点池。
    • 不支持多网络。
    • 具有 100 个以上 Pod 的服务必须是无头服务。
    • 每个 Pod 都应在其自己的节点上运行，系统 DaemonSet 除外。如需在特定节点上定义 Pod 调度，可以使用 Kubernetes Pod 亲和性或反亲和性。
    • 从可用区级集群迁移到区域级集群需要重新创建集群，才能解锁更高的节点配额级别。
    • 迁移到使用 Private Service Connect 的集群需要您重新创建集群，才能解锁更高的节点配额级别。

  2. 请与 Cloud Customer Care 联系，将集群大小和配额限制增加到 15,000 个节点或 65,000 个节点，具体取决于您的伸缩需求。

在多个集群之间拆分工作负载的最佳实践

您可以在单个大型集群上运行工作负载。与管理多个集群相比，这种方法更易于管理、更经济实惠，并可提供更好的资源利用率。但是在某些情况下，您需要考虑将工作负载拆分到多个集群中：

  • 查看多集群用例，详细了解使用多个集群的一般要求和场景。
  • 此外，从可扩缩性角度来看，如果集群可能会超出下一部分所述的某个限制或某个 GKE 配额，请对其进行拆分。降低达到 GKE 限制的风险可以降低停机或其他可靠性问题的风险。

如果您决定拆分集群，请使用舰队管理来简化多集群舰队的管理。

限制和最佳实践

为确保您的架构支持大规模 GKE 集群，请查看以下限制和相关最佳实践。超出这些限制可能会导致集群性能下降或可靠性问题。

这些最佳实践适用于未安装扩展程序的任何默认 Kubernetes 集群。使用 webhook 或自定义资源定义 (CRD) 扩展 Kubernetes 集群很常见，但会限制您扩缩集群的能力。

下表介绍了主要的 GKE 配额和限制。您还应该熟悉大型集群的开源 Kubernetes 限制。

表中提到的 GKE 版本要求同时适用于节点和控制平面。

GKE 限制 说明 最佳做法
etcd 数据库大小 etcd 数据库的大小上限为 6 GB。您应主动监控集群的 etcd 数据库大小，并配置提醒，以便在用量接近此限制时收到通知。超出上限可能会导致控制平面问题。

您可以使用以下资源来帮助监控您的使用情况：

  • 如需查看当前用量，请前往“配额”页面，查看预过滤的 GKE 配额列表。
  • 使用数据分析和建议，可在集群达到 80%、90% 和 95% 的消耗水平时收到提醒。

如需详细了解在接近限额时如何应对，请参阅确定 etcd 使用量即将达到限额的集群。
每种类型的 etcd 对象的总大小 给定资源类型的所有对象的总大小不应超过 800 MB。例如，您可以创建 750 MB 的 Pod 实例和 750 MB 的 Secret，但无法创建 850 MB 的 Secret。如果您创建的对象超过 800 MB，可能会使 Kubernetes 或自定义控制器无法初始化并导致中断。

将存储在 etcd 中的每种类型的所有对象的总大小保持在 800 MB 以下。这特别适用于使用许多大型 Secret 或 ConfigMap 或大量 CRD 的集群。
未启用 GKE Dataplane V2 的集群的 Service 数量 如果存在以下任一情况，kube-proxy 使用的 iptables 的性能会降低：
  • Service 过多。
  • Service 背后的后端数量很大。

启用 GKE Dataplane V2 后，此限制即会消除。

将集群中的 Service 数量保持在 10,000 以下。

如需了解详情，请参阅使用 Service 公开应用。
每个命名空间的 Service 数 为 Service 生成的环境变量数量可能会超出 shell 限制。这可能会导致 Pod 在启动时崩溃。

将每个命名空间的 Service 数量保持在 5,000 个以下。

您可以选择不填充这些环境变量。请参阅关于如何将 PodSpec 中的 enableServiceLinks 设置为 false的文档。

如需了解详情，请参阅使用 Service 公开应用。
未启用 GKE Dataplane V2 的集群的单个 Service 背后的 Pod 数

每个节点都运行一个 kube-proxy，它使用 watch 来监控任何 Service 更改。集群越大，代理处理的更改相关数据就越多。如果集群中的节点数量超过 500 个，这会尤为明显。

端点的相关信息在单独的 EndpointSlices 之间拆分。此拆分可以减少每次更改时传输的数据量。

端点对象仍可用于组件，但超过 1,000 个 Pod 的任何端点都会自动截断。

将单个 Service 背后的 Pod 数量保持在 10,000 个以下。

如需了解详情，请参阅使用 Service 公开应用。

启用了 GKE Dataplane V2 的集群的单个 Service 背后的 Pod 数

GKE Dataplane V2 包含单个 Service 公开的 Pod 数量限制。

同样的限制适用于 Autopilot 集群，因为它们使用 GKE Dataplane V2。

在 GKE 1.23 及更早版本中，将单个 Service 背后的 Pod 数量保持在 1,000 个以下。

在 GKE 1.24 及更高版本中，将单个 Service 背后的 Pod 数量保持在 10,000 个以下。

如需了解详情，请参阅使用 Service 公开应用。
每个无头 Service 的 DNS 记录数

对于 kube-dns 和 Cloud DNS，每个无头 Service 的 DNS 记录数量有限。

将每个无头 Service 的 DNS 记录数量保持在 1000 个以下（对于 kube-dns）和 3500/2000 (IPv4/IPv6) 个以下（对于 Cloud DNS）。
所有 Service 端点的数量 所有 Service 中的端点数量可能会达到限制。这可能会增加编程延迟时间，或者导致根本无法对新端点进行编程。

确保所有 Service 中所有端点的数量低于 260,000。

GKE Dataplane V2 是 GKE Autopilot 的默认数据平面，它依赖的 eBPF 映射目前限制为在所有 Service 中不超过 260,000 个端点。
每个集群的 Pod 横向自动扩缩器对象数量

系统每 15 秒对每个 Pod 横向自动扩缩器 (HPA) 进行一次处理。

超过 300 个 HPA 对象可能会导致性能呈线性下降。

确保 HPA 对象的数量不超过此限制，否则 HPA 处理频率可能会呈线性下降。例如，假设在 GKE 1.22 中有 2,000 个 HPA，系统将每隔 1 分钟 40 秒对每个 HPA 进行一次重新处理。

如需了解详情，请参阅根据资源利用率进行自动扩缩和 Pod 横向自动扩缩的可扩缩性。
每个节点的 Pod 数 GKE 有一个硬性限制，即每个节点最多 256 个 Pod。此限制假设每个 Pod 的平均容器数为两个或更少。如果增加每个 Pod 的容器数量，则此上限值可能会降低，因为 GKE 会为每个容器分配更多资源。

我们建议您使用每 10 个 Pod 至少有一个 vCPU 的工作器节点。

如需了解详情，请参阅手动升级集群或节点池。
Pod 更改速率

Kubernetes 具有内部限制，会影响为了响应扩缩请求而创建或删除 Pod（停止使用 Pod）的速率。删除 Service 中的 pod 等其他因素也会影响此 Pod 的流失率。

对于最多具有 500 个节点的集群，系统平均每秒会创建 20 个 Pod，每秒删除 20 个 Pod。

对于超过 500 个节点的集群，系统平均每秒创建 100 个 Pod，每秒删除 100 个 Pod。

在规划如何扩缩工作负载时，请考虑 Pod 创建和删除速率限制。

Pod 与其他资源类型（例如 EndpointSlice）共享相同的删除吞吐量。如果将 Pod 定义为 Service 的一部分，则可以降低删除吞吐量。

如需允许集群自动扩缩器从利用率过低的节点中移除 Pod，请避免过于严格的 PodDisruptionBudgets 和较长的终止宽限期。

我们也不建议您使用通配符容忍，因为它们可能会导致系统在移除中的节点上安排工作负载。
打开的 watch 数

节点会针对您为 Pod 配置的每个 Secret 和 ConfigMaps 创建一个 watch。所有节点创建的 watch 数量的总和可能会在集群控制平面上产生大量负载。

每个集群超过 20 万个 watch 可能会影响集群的初始化时间。此问题可能会导致控制平面频繁重启。

定义更大的节点以降低由大量 watch 导致的问题的可能性和严重性。较高的 Pod 密度（大型节点较少）可能会减少 watch 数量，并缓解问题的严重程度。

如需了解详情，请参阅机器系列比较。
如果启用了应用层 Secret 加密，则为每个集群的 Secret 数 启用应用层 Secret 加密时，集群必须在集群启动期间解密所有 Secret。如果存储超过 30,000 个 Secret，则您的集群在启动或升级期间可能会不稳定，从而导致工作负载服务中断。

使用应用层 Secret 加密时，可以存储不到 30,000 个 Secret。

如需了解详情，请参阅在应用层对 Secret 进行加密。
每个节点的日志带宽

每个节点发送到 Cloud Logging API 的日志数量存在上限。默认限制在 100 Kbps 到 500 Kbps 之间，具体取决于负载。对于 Standard 集群，您可以通过部署高吞吐量 Logging 代理配置将限制提高到 10 MiB。超出此限制可能会导致日志条目被丢弃。

将 Logging 配置为默认限制之内或配置高吞吐量 Logging 代理。

如需了解详情，请参阅调整日志吞吐量。
节点池 节点池数量过多可能会影响基础设施自动扩缩延迟时间，因为这会增加可添加到集群的潜在节点集。工作负载分离或自定义计算类等功能会增加节点池的数量。 将节点池的数量保持在 200 个以下。
Backup for GKE 限制

您可以使用 Backup for GKE 备份和恢复 GKE 工作负载。

Backup for GKE 存在一些限制，您在定义备份方案时需要注意这些限制。

查看 Backup for GKE 的限制。

如果您的工作负载可能超出这些限制，我们建议您创建多个备份方案，对备份进行分区并保持在限制范围内。
Config Connector 限制

您可以使用 Config Connector 通过 Kubernetes 管理 Google Cloud 资源。Config Connector 有两种操作模式：

  • 集群模式，其中每个 GKE 集群有一个 Config Connector 实例。

    在此模式下，这一个 Config Connector 实例会加载集群中的所有资源。

  • 命名空间模式，其中集群内的每个命名空间都有一个单独的 Config Connector 实例。

    在此模式下，您可以通过各命名空间对代管资源进行分区。此设置可减少单个 Config Connector 实例需要代管的资源量，从而降低其 CPU 和内存用量。

每种模式都有不同的扩缩特性和限制。

如需详细了解资源限制，请参阅 Config Controller 可伸缩性指南。如需了解如何管理大量资源，请参阅 Config Connector 最佳实践。

后续步骤