第 6 章 根据对象限制规划您的环境

在规划 OpenShift Container Platform 集群时,请考虑以下对象限制。

这些限制基于最大可能的集群。对于较小的集群,最大值限制会较低。很多因素会影响指定的阈值,包括 etcd 版本或者存储数据格式。

在大多数情况下,超过这些限制会降低整体性能。它不一定意味着集群会出现错误。

6.1. 经过 OpenShift Container Platform 主发行版本测试的集群最大值

为 OpenShift Container Platform 3.x 测试的云平台: Red Hat OpenStack、Amazon Web Services 和 Microsoft Azure。为 OpenShift Container Platform 4.x 测试的云平台: Amazon Web Services、Microsoft Azure 和 Google Cloud Platform。

最大类型3.x 测试的最大值4.x 测试的最大值

节点数量

2,000

2,000

Pod 数量 footnote:numberofpodsmajorrelease[这里显示的数量是测试 Pod 的数量。实际的 Pod 数量取决于应用程序的内存、CPU 和存储要求。]

150,000

150,000

每个节点的 pod 数量

250

500 footnote:podspernodemajorrelease[这是在一个有 100 个 worker 节点,每个 worker 节点有 500 个 Pod 的集群中测试的。默认 maxPods 仍为 250。要获得 500 maxPods,集群必须使用 install-config.yaml 文件,且其中的 hostPrefix 被设置为 22 来创建,并通过一个自定义的 KubeletConfig 把 maxPods 设置为 500 。带有 Persistant VolumeClaim (PVC) 的最大 pod 数量取决于分配 PVC 的后端存储。在我们的测试中,只有 OpenShift Container Storage v4 (OCS v4) 能够满足本文档中提到的每个节点的 pod 数量。]

每个内核的 pod 数量

没有默认值。

没有默认值。

命名空间数量 footnote:numberofnamepacesmajorrelease[当有大量活跃的项目时,如果键空间增长过大并超过空间配额,etcd 的性能将会受到影响。强烈建议您定期维护 etcd 存储,包括通过碎片管理释放 etcd 存储。]

10,000

10,000

构建(build)数

10,000(默认 pod RAM 512 Mi)- 管道 (Pipeline) 策略

10,000(默认 pod RAM 512 Mi)- Source-to-Image (S2I) 构建策略

每个命名空间中的 Pod 数量 footnote:objectpernamespacemajorrelease[系统中有多个控制循环,必须迭代给定命名空间中的所有对象作为对一些状态更改的响应。在单一命名空间中有大量给定类型的对象可使这些循环的运行成本变高,并降低对给定状态变化的处理速度。限制假设系统有足够的 CPU 、内存和磁盘来满足应用程序的要求。]

25,000

25,000

服务的数量 footnote:servicesandendpointsmajorrelease[每个服务端口和服务后端在 iptables 中都有一个相应的条目。给定服务的后端数量会影响端点对象的大小,这会影响到整个系统发送的数据大小。]

10,000

10,000

每个命名空间的服务数

5,000

5,000

每个服务中的后端数

5,000

5,000

每个命名空间的部署数量 footnote:objectpernamespacemajorrelease[]

2,000

2,000