红帽全球峰会第 11 章 测试每个集群的最大值
在规划 OpenShift Container Platform 集群时，请考虑以下测试的集群对象限制。
这些限制基于最大可能的集群。对于较小的集群，最大值会按比例减小。很多因素会影响指定的阈值，包括 etcd 版本或者存储数据格式。
在大多数情况下，超过这些限制会降低整体性能。它不一定意味着集群会出现错误。
为 OpenShift Container Platform 3.x 测试的云平台：Red Hat OpenStack、Amazon Web Services 和 Microsoft Azure。
11.1. OpenShift Container Platform 为主版本测试的集群最大限制
| 最大类型 | 3.x 测试的最大值 |
|---|---|
| 节点数量 | 2,000 |
| Pod 数 [1] | 150,000 |
| 每个节点的 pod 数量 | 250 |
| 每个内核的 pod 数量 | 没有默认值。 |
| 命名空间的数量 | 10,000 |
| 构建(build)数：管道策略 | 10,000（默认 pod RAM 512Mi） |
| 每个命名空间的 pod 数量 [2] | 25,000 |
| 服务数 [3] | 10,000 |
| 每个命名空间的服务数 | 5,000 |
| 每个服务中的后端数 | 5,000 |
| 每个命名空间的部署数量 [2] | 2,000 |
- 这里的 pod 数量是测试 pod 的数量。实际的 pod 数量取决于应用程序的内存、CPU 和存储要求。
- 系统中有一些控制循环需要迭代给定命名空间中的所有对象，作为对一些状态更改的响应。在单一命名空间中有大量给定类型的对象可使这些循环的运行成本变高，并降低对给定状态变化的处理速度。最大值假设系统有足够的 CPU、内存和磁盘来满足应用程序要求。
- 每个服务端口和每个服务后端在 iptables 中都有对应条目。给定服务的后端数量会影响端点对象的大小，这会影响到整个系统发送的数据大小。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}