配额和限制

本页面介绍 GKE on Bare Metal 版本 1.28 针对 Google Cloud 项目、集群和节点的配额和限制。

限制

以下部分概述了集群的一些基本限制。在设计要在 GKE on Bare Metal 上运行的应用时,请考虑这些限制。

每个管理员集群的用户集群数上限

管理员集群管理用户集群及其关联节点的生命周期。管理员集群用于控制关键的用户集群操作,例如集群创建、集群或节点重置、集群升级和集群更新。用户集群节点的总数是限制性能和可靠性的主要因素之一。

根据持续测试,管理员集群最多可以可靠地支持 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 数和每个用户集群的节点数建议。

每个用户集群的节点数上限

我们测试 GKE on Bare Metal,以运行具有多达 500 个节点的工作负载。不过,为了确保最佳的性能和可靠性,我们建议您在生产环境中运行工作负载时每个集群不超过 200 个节点。

集群类型 节点数下限 建议的节点数上限 绝对节点数上限
用户、独立或混合 1 200 500

对于单节点集群,您必须移除 node-role.kubernetes.io/master:NoSchedule 污点才能在节点上运行工作负载。如需了解详情,请参阅 Kubernetes 污点和容忍

每个节点的 pod 数上限

GKE on Bare Metal 支持在集群配置文件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 实现会导致此限制;它不是 GKE on Bare Metal 的固有限制。

应对措施

对于 RHEL,没有缓解措施。对于 Ubuntu 和 Debian 系统,我们建议在大型集群上从默认的 nftables 切换到旧版 iptables

GKE Dataplane V2

适用于 Bare Metal 的 GDCV 使用 GKE Dataplane V2,这是一种使用 CiliumeBPF 实现的集群数据平面,针对 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 端口限制

LoadBalancerNodePort Service 的端口限制为 2,768。默认端口范围为 30000-32767。如果超出限制,您将无法创建新的 LoadBalancerNodePort 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 控制台中提交增加配额申请:

转到“配额”

扩缩信息

本文档中的信息与规划如何对集群进行纵向扩容有关。如需了解详情,请参阅在裸金属集群上对 GKE 进行纵向扩容

找不到您要查询的内容?点击发送反馈,告诉我们缺少哪些信息。