本页面介绍 GKE on Bare Metal 版本 1.16 对 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 |
端点数上限
在 RHEL 和 CentOS 中，存在 100,000 个端点的集群级限制。此数字是一个 Kubernetes 服务引用的所有 pod 的总和。如果两个服务引用同一组 pod，则此情况计为两组单独的端点。RHEL 和 CentOS 中的底层 nftable 实现导致了此限制；这不是 GKE on Bare Metal 的固有限制。
应对措施
对于 RHEL 和 CentOS，没有缓解措施。对于 Ubuntu 和 Debian 系统，我们建议在大规模集群上从默认 nftables 切换为旧版 iptables。
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 控制台中提交增加配额申请：
扩缩问题
本部分介绍了扩缩集群时需要注意的一些问题。
为系统守护程序预留的资源
从 1.14 版开始，GKE on Bare Metal 会自动在节点上为系统守护程序（例如 sshd 或 udev）预留资源。节点上的 CPU 和内存资源为系统守护程序预留，以便这些守护程序具有所需的资源。如果没有此默认启用的功能，Pod 可能会消耗节点上的大部分资源，从而使系统守护程序无法完成其任务。
具体来说，GKE on Bare Metal 会在每个节点上为系统守护程序预留 50 millicore CPU (50 mCPU) 和 280 兆比字节 (280 MiB) 内存。请注意，CPU 单位“mCPU”代表“核心的千分之一”，因此每个节点上的核心的 50/1000 (5%) 会预留给系统守护程序。预留资源量很小，对 Pod 性能没有显著影响。但是，如果 Pod 使用 CPU 或内存的数量超过分配给它们的数量，则节点上的 kubelet 可能会逐出 Pod。
etcd 性能
磁盘速度对 etcd 性能和稳定性至关重要。磁盘速度缓慢会增加 etcd 请求延迟时间，这可能会导致集群稳定性问题。为了提高集群性能，GKE on Bare Metal 将 Event 对象存储在单独的专用 etcd 实例中。标准 etcd 实例使用 /var/lib/etcd 作为其数据目录，并使用端口 2379 处理客户端请求。etcd-events 实例使用 /var/lib/etcd-events 作为其数据目录，并使用端口 2382 处理客户端请求。
我们建议您将固态磁盘 (SSD) 用于 etcd 存储区。为了获得最佳性能，请将单独的磁盘装载到 /var/lib/etcd 和 /var/lib/etcd-events。使用专用磁盘可确保这两个 etcd 实例不会共享磁盘 IO。
etcd 文档提供了其他硬件建议，以确保在生产环境中运行集群时获得最佳 etcd 性能。
如需检查 etcd 和磁盘性能，请在 Metrics Explorer 中使用以下 etcd I/O 延迟时间指标：
etcd_disk_backend_commit_duration_seconds：第 99 百分位 (p99) 的时长应少于 25 毫秒。etcd_disk_wal_fsync_duration_seconds：第 99 百分位 (p99) 的时长应少于 10 毫秒。
如需详细了解 etcd 性能，请参阅 etcd 警告“应用条目时间过长”意味着什么？以及 etcd 警告“未能按时发出检测信号”意味着什么？。
找不到您要查询的内容？点击发送反馈，告诉我们缺少哪些信息。