本页面介绍 Google Distributed Cloud 1.29 版针对 Google Cloud 项目、集群和节点的配额和限制。
限制
以下部分概述了集群的一些基本限制。在设计在 Google Distributed Cloud 上运行的应用时，请考虑这些限制。
每个管理员集群的用户集群数上限
管理员集群管理用户集群及其关联节点的生命周期。管理员集群用于控制关键的用户集群操作，例如集群创建、集群或节点重置、集群升级和集群更新。用户集群节点的总数是限制性能和可靠性的主要因素之一。
根据持续测试，管理员集群最多可以可靠地支持 100 个用户集群，每个节点具有 10 个节点，总计 1,000 个节点。
每个用户集群的 Pod 数上限
我们建议您将每个用户集群的 Pod 数量限制为 15,000 个以内。例如，如果您的集群有 200 个节点，则应将每个节点的 Pod 数限制为 75 个以内。同样，如果您希望每个节点运行 110 个 Pod，则应将集群中的节点数限制为 136 个以内。下表提供了建议和不建议的配置示例。
| 每个节点的 Pod 数。 | 每个集群的节点数 | 每个集群的 Pod 数 | 结果 |
|---|---|---|---|
| 110 | 200 | 22,000 | pod 过多，不建议 |
| 110 | 136 | 14,960 | 在限制范围内 |
| 100 | 150 | 15000 | 在限制范围内 |
| 75 | 200 | 15000 | 在限制范围内 |
以下各部分中每个用户集群的 Pod 数上限建议优先于每个节点的 Pod 数和每个用户集群的节点数建议。
每个用户集群的节点数上限
我们测试了 Google Distributed Cloud，它支持运行多达 500 个节点的工作负载。不过，为了确保最佳的性能和可靠性，我们建议您在生产环境中运行工作负载时每个集群不超过 200 个节点。
| 集群类型 | 节点数下限 | 建议的节点数上限 | 绝对节点数上限 |
|---|---|---|---|
| 用户、独立或混合 | 1 | 200 | 500 |
对于单节点集群，您必须移除 node-role.kubernetes.io/master:NoSchedule 污点才能在节点上运行工作负载。如需了解详情，请参阅 Kubernetes 污点和容忍。
每个节点的 pod 数上限
Google Distributed Cloud 支持在集群配置文件的 nodeConfig.PodDensity.MaxPodsPerNode 设置中配置每个节点的最大 Pod 数量。下表展示了 MaxPodsPerNode 支持的最小值和最大值，其中包括运行插件服务的 pod：
| 集群类型 | 允许的最小值 | 建议的最大值 | 允许的最大值 |
|---|---|---|---|
| 所有 HA 集群和非 HA 用户集群 | 32 | 110 | 250 |
| 所有其他非 HA 集群 | 64 | 110 | 250 |
端点数上限
在 Red Hat Enterprise Linux (RHEL) 上，集群级别的端点数量上限为 10 万个。此数字是一个 Kubernetes Service 引用的所有 pod 的总和。如果两个服务引用了同一组 Pod，则这种情况会计为两组独立的端点。RHEL 上的底层 nftable 实现会导致此限制；它不是 Google Distributed Cloud 的固有限制。
应对措施
对于 RHEL，没有缓解措施。对于 Ubuntu 和 Debian 系统，我们建议在大型集群上从默认的 nftables 切换到旧版 iptables。
GKE Dataplane V2
Google Distributed Cloud 使用 GKE Dataplane V2，这是一种使用 Cilium 和 eBPF 实现的集群数据平面，针对 Kubernetes 网络进行了优化。
GKE Dataplane V2 NetworkPolicy 限制
GKE Dataplane V2 使用 Cilium 管理 Kubernetes NetworkPolicy 资源。以下限制适用于 GKE on Bare Metal 集群：
| 维度 | 支持的限制 |
|---|---|
| 命名空间标签的更改速率上限 | 每个命名空间每小时最多更改一次。
在大多数情况下，此限制不是必要的。只要不频繁地更改（例如每秒更改一次），或者 Cilium 身份（唯一标签集）的数量不接近上限：16000 个标签集和全部允许网络政策，或每个集群 65535 个标签集。 |
| 每个集群的 Service 端点数量上限 | 经过测试和建议的上限是 100,000 个端点。Service 端点的硬编码限制为 262,000。 |
| 网络政策和规则数量上限 | 最多 4 万条网络政策和 8 万条规则。例如，您可以指定 4 万项网络政策（每项政策包含两条规则），也可以指定 2 万项政策（每项政策包含 4 条规则）。 |
| 网络政策更改速率上限 | 每秒最多 20 次更改（创建或删除）。 |
| 唯一广告连播标签集的数量上限 | 65,535 (216-1)。这是 Cilium 安全身份限制。 |
| 政策选择器选择的唯一 Pod 标签集的数量上限 | 16,000（固定 eBPF 映射大小）。给定的政策选择器映射条目由以下内容组成：安全身份、端口和协议。 |
GKE Dataplane V2 eBPF 限制
BPF lbmap 中 Dataplane V2 的条目数上限为 65,536。以下方面的增加可能会导致条目总数增加：
- 服务数
- 每项服务的端口数
- 每项服务的后端数
我们建议您监控集群使用的实际条目数，以确保不超出限制。使用以下命令获取当前条目：
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
我们还建议您使用自己的监控流水线从 anetd DaemonSet 中收集指标。监控以下条件以确定条目数何时导致问题：
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
LoadBalancer 和 NodePort Service 端口限制
LoadBalancer 和 NodePort Service 的端口限制为 2,768。默认端口范围为 30000-32767。如果超出限制，您将无法创建新的 LoadBalancer 或 NodePort Service，也无法为现有服务添加新的节点端口。
默认情况下，Kubernetes 会将节点端口分配给类型为 LoadBalancer 的 Service。这些分配可以快速耗尽分配给集群的 2,768 个可用节点端口。为了节省节点端口，请通过将 LoadBalancer Service 规范中的 allocateLoadBalancerNodePorts 字段设置为 false 来停用负载均衡器节点端口分配。此设置会阻止 Kubernetes 将节点端口分配给 LoadBalancer Service。如需了解详情，请参阅 Kubernetes 文档中的停用负载均衡器 NodePort 分配。
使用以下命令检查分配的端口数：
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
捆绑式负载均衡器节点连接限制
用于捆绑式负载均衡 (MetalLB) 的每个节点允许的连接数为 28,000。这些连接的默认临时端口范围为 32768-60999。如果超出连接限制，则对 LoadBalancer Service 的请求可能会失败。
如果您需要公开能够处理大量连接（例如针对 Ingress）的负载均衡器服务，我们建议您考虑替代负载均衡方法，以避开 MetalLB 存在的此限制。
集群配额
默认情况下，您最多可以注册 15 个集群。如需在 GKE Hub 中注册更多集群，您可以在 Google Cloud 控制台中提交增加配额申请：
扩缩信息
本文档中的信息与规划如何对集群进行纵向扩容有关。如需了解详情，请参阅对 Google Distributed Cloud 集群进行纵向扩容。
找不到您要查询的内容？点击发送反馈，告诉我们缺少哪些信息。