规划大型 GKE 集群

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

规划大型 GKE 集群的原因

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

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

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

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

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

限制和最佳实践

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

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

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

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

GKE 限制 说明 最佳做法
etcd 数据库大小 etcd 数据库的大小上限为 6 GB。如果您运行的是具有数万个资源的超大型集群，则 etcd 实例可能会超出此限制。您可以在 Google Cloud 控制台中查看集群的利用率水平。 如果超出此限制，GKE 可能会将您的 etcd 实例标记为健康状况不佳。这会导致集群控制平面无响应。

如果您超出此限制，请与 Google Cloud 支持团队联系。
每种类型的 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 中所有端点的数量低于 64,000。

GKE Dataplane V2 是 GKE 的默认数据平面，它依赖的 eBPF 映射目前限制为在所有 Service 中不超过 64,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 和 ConfigMap 创建一个 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 之间，具体取决于负载。您可以通过部署高吞吐量 Logging 代理配置将限制提高到 10 Mbps。超出此限制可能会导致日志条目被丢弃。

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

如需了解详情，请参阅提高 Logging 代理吞吐量。
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 Connector 实例都存在 0.1 个 CPU 请求和 512 MB 内存的限制。因此，它无法很好地针对大量代管资源进行扩容。我们建议每个 Config Connector 实例代管的 Google Cloud 资源不超过 25,000 个。此限制仅供参考，因为使用的内存量取决于资源类型和具体使用情形。

如果需要管理大量代管资源，我们建议您使用命名空间模式来限制每个 Config Connector 实例处理的资源数量。

对 Config Connector 使用命名空间模式时，我们建议最多使用 500 个命名空间。每个 Config Connector 实例都会打开许多个与 kube-apiserver 之间的 watch 连接。其中许多实例可能会导致 GKE 集群控制平面过载，尤其是在控制平面升级期间需要对这些 watch 连接重新初始化的情况下。
在新的 GKE 集群中，可能需要对 500 个命名空间这一数量进一步限制，因为集群控制平面的可用 CPU 和内存最初是取决于集群中的节点数量。集群需要时间来根据利用率调整可用的 CPU 和内存。

如果资源数量无法划分为满足上述限制，我们建议您使用多个 GKE 集群来管理这些资源。

如需了解详情，请参阅 Config Controller 可伸缩性指南。

后续步骤