配额和限制

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

限制

请注意集群的以下限制和建议。

每个集群的 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 请求延迟时间，这可能会导致集群稳定性问题。我们建议您将固态磁盘 (SSD) 用于 etcd 存储区。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 警告“未能按时发出检测信号”意味着什么？。

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