第 3 章 根据对象限制规划您的环境
在规划 OpenShift Container Platform 集群时，请考虑以下对象限制。
这些限制基于最大可能的集群。对于较小的集群，最大值限制会较低。很多因素会影响指定的阈值，包括 etcd 版本或者存储数据格式。
在大多数情况下，超过这些限制会降低整体性能。它不一定意味着集群会出现错误。
对于快速变化的集群（如集群中包括多个启动和停止的 pod）可能会有比记录中小的实际最大大小。
3.1. OpenShift Container Platform 为主发行版本测试了集群最大值
红帽不提供针对 OpenShift Container Platform 集群大小调整的直接指导。这是因为，判断集群是否在 OpenShift Container Platform 支持的边界内，需要仔细考虑限制集群扩展的所有多维因素。
OpenShift Container Platform 支持测试的集群最大值，而不是绝对集群最大值。并非所有 OpenShift Container Platform 版本、control plane 工作负载和网络插件的组合都会被测试，因此下表并不表示所有部署的扩展绝对预期。可能无法同时扩展到所有维度上的最大值。表包含特定工作负载和部署配置的测试的最大值，并充当扩展指南，如类似部署的预期内容。
| 最大类型 | 4.x 测试的最大值 |
|---|---|
| 节点数 | 2,000 [1] |
| pod 数量 [2] | 150,000 |
| 每个节点的 pod 数量 | 2,500 [3][4] |
| 每个内核的 pod 数量 | 没有默认值。 |
| 命名空间数量 [5] | 10,000 |
| 构建（build）数 | 10,000（默认 pod RAM 512 Mi）- Source-to-Image (S2I) 构建策略 |
| 每个命名空间的 pod 数量 [6] | 25,000 |
| 每个 Ingress Controller 的路由和后端数量 | 每个路由器 2,000 个 |
| secret 的数量 | 80,000 |
| 配置映射数量 | 90,000 |
| 服务数量 [7] | 10,000 |
| 每个命名空间的服务数 | 5,000 |
| 每个服务中的后端数 | 5,000 |
| 每个命名空间的部署数量 [6] | 2,000 |
| 构建配置数 | 12,000 |
| 自定义资源定义 (CRD) 的数量 | 1,024 [8] |
- 部署暂停 Pod 以在 2000 个节点规模下对 OpenShift Container Platform 的 control plane 组件进行压力测试。扩展至类似数量的功能会根据特定的部署和工作负载参数而有所不同。
- 这里的 pod 数量是 test pod 的数量。实际的 pod 数量取决于应用程序的内存、CPU 和存储要求。
-
在具有 31 个服务器的集群中测试：3 个 control plane、2 个基础架构节点和 26 个 worker 节点。如果您需要 2,500 个用户 pod，则需要
hostPrefix为20，它为每个节点分配一个足够大的网络，以便每个节点包含 2000 个 pod，并将maxPods设置为2500的自定义 kubelet 配置。如需更多信息，请参阅在 OCP 4.13 上每个节点运行 2500 个 pod。 -
使用
OVNKubernetes网络插件的集群测试的最大 pod 为 2,500。OpenShiftSDN网络插件的每个节点测试的最大 pod 是 500 个 pod。 - 当有大量活跃的项目时，如果键空间增长过大并超过空间配额，etcd 的性能将会受到影响。强烈建议您定期维护 etcd 存储（包括整理碎片）来释放 etcd 存储。
- 系统中有一些控制循环必须迭代给定命名空间中的所有对象，作为对一些状态更改的响应。在单一命名空间中有大量给定类型的对象可使这些循环的运行成本变高，并降低对给定状态变化的处理速度。限制假设系统有足够的 CPU 、内存和磁盘来满足应用程序的要求。
-
每个服务端口和每个服务后端在
iptables中都有对应条目。给定服务的后端数量会影响端点对象的大小，这会影响到整个系统发送的数据大小。 -
在具有 29 个服务器的集群中测试：3 个 control plane、2 个基础架构节点和 24 个 worker 节点。集群有 500 个命名空间。OpenShift Container Platform 的限制是 1,024 个总自定义资源定义(CRD)，其中包括由 OpenShift Container Platform 安装的产品、与 OpenShift Container Platform 集成并创建了 CRD 的产品。如果创建超过 1,024 CRD，则
oc命令请求可能会节流。
3.1.1. 示例情境
例如，500 个 worker 节点(m5.2xl)经过测试，并被支持，使用 OpenShift Container Platform 4.15、OVN-Kubernetes 网络插件和以下工作负载对象：
- 除默认值外，200 个命名空间
- 每个节点 60 个 pod；30 个服务器和 30 个客户端 pod （总计 30k）
- 57 镜像流/ns (11.4k 总计)
- 15 services/ns 被服务器 pod 支持 (共 3k)
- 15 routes/ns 被以前的服务支持 (共 3k)
- 20 secrets/ns (共 4k)
- 10 config maps/ns (共 2k)
- 6 个网络策略/ns，包括 deny-all、allow-from ingress 和 in-namespace 规则
- 57 builds/ns
以下因素已知会对集群工作负载扩展有影响（正面的影响或负面的影响），在规划部署时应进行考虑。如需其他信息和指导，请联络您的销售代表或 红帽支持。
- 每个节点的 pod 数量
- 每个 pod 的容器数量
- 使用的探测类型（如 liveness/readiness、exec/http）
- 网络策略数量
- 项目或命名空间数量
- 每个项目的镜像流数
- 项目的构建数
- 服务/日期和类型数
- 路由数
- 分片数量
- secret 的数量
- 配置映射数量
API 调用率或集群 "churn"，这是集群配置中快速变化的估算。
-
Prometheus 查询每秒 5 分钟窗口的 pod 创建请求：
sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m])) -
在 5 分钟的时间内 Prometheus 每秒查询所有 API 请求：
sum(irate(apiserver_request_count{}[5m]))
-
Prometheus 查询每秒 5 分钟窗口的 pod 创建请求：
- CPU 的集群节点资源消耗
- 集群节点资源消耗
