本页面介绍 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,这是一种使用 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 控制台中提交增加配额申请:
扩缩信息
本文档中的信息与规划如何对集群进行纵向扩容有关。如需了解详情,请参阅在裸金属集群上对 GKE 进行纵向扩容。
找不到您要查询的内容?点击发送反馈,告诉我们缺少哪些信息。