×

规划 OpenShift Container Platform 集群时,请考虑以下测试的对象最大值。

这些指南基于最大可能的集群。对于较小的集群,最大值较低。许多因素都会影响所述阈值,包括 etcd 版本或存储数据格式。

在大多数情况下,超过这些数字会导致整体性能降低。这并不一定意味着集群会失败。

经历快速变化的集群(例如,具有许多启动和停止 Pod 的集群)可能比文档中记录的实际最大大小更小。

OpenShift Container Platform 测试集群主要版本的最大值

Red Hat 不提供有关调整 OpenShift Container Platform 集群大小的直接指导。这是因为确定您的集群是否在 OpenShift Container Platform 的支持范围内需要仔细考虑所有限制集群规模的多维因素。

OpenShift Container Platform 支持测试的集群最大值,而不是绝对的集群最大值。并非每个 OpenShift Container Platform 版本、控制平面工作负载和网络插件的组合都经过测试,因此下表并不代表所有部署的绝对规模预期。可能无法同时在所有维度上扩展到最大值。该表包含针对特定工作负载和部署配置的测试最大值,并作为类似部署可以预期的规模指南。

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

节点数量

2,000 [1]

Pod 数量[2]

150,000

每个节点的 Pod 数量

2,500 [3]

每个内核的 Pod 数量

没有默认值。

命名空间数量[4]

10,000

构建数量

10,000(默认 Pod RAM 512 Mi) - 源到镜像 (S2I) 构建策略

每个命名空间的 Pod 数量[5]

25,000

每个 Ingress 控制器中的路由和后端数量

每个路由器 2,000 个

密钥数量

80,000

配置映射数量

90,000

服务数量[6]

10,000

每个命名空间的服务数量

5,000

每个服务的后台数量

5,000

每个命名空间中的部署数量[5]

2,000

构建配置数量

12,000

自定义资源定义 (CRD) 数量

1,024 [7]

  1. 暂停 Pod 部署到 OpenShift Container Platform 的控制平面组件,规模为 2000 个节点。能够扩展到类似数量的能力将根据具体的部署和工作负载参数而有所不同。

  2. 此处显示的 Pod 计数是测试 Pod 的数量。实际的 Pod 数量取决于应用程序的内存、CPU 和存储需求。

  3. 这在一个拥有 31 台服务器的集群上进行了测试:3 个控制平面、2 个基础设施节点和 26 个工作节点。如果您需要 2500 个用户 Pod,则需要 hostPrefix20,这将分配一个足够大的网络,以便每个节点可以容纳超过 2000 个 Pod,以及一个自定义 kubelet 配置,其中 maxPods 设置为 2500。有关更多信息,请参阅 在 OCP 4.13 上每个节点运行 2500 个 Pod

  4. 当存在大量活动项目时,如果键空间增长过大并超过空间配额,etcd 可能会出现性能不佳的问题。强烈建议定期维护 etcd,包括碎片整理,以释放 etcd 存储空间。

  5. 系统中存在多个控制循环,这些循环必须迭代给定命名空间中的所有对象,以响应状态的一些更改。在单个命名空间中拥有大量给定类型的对象会使这些循环变得昂贵,并减慢给定状态更改的处理速度。该限制假设系统拥有足够的 CPU、内存和磁盘来满足应用程序需求。

  6. 每个服务端口和每个服务后端在iptables中都有相应的条目。给定服务的后台数量会影响Endpoints对象的大小,进而影响在整个系统中发送的数据量。

  7. 在一个包含29台服务器的集群上进行了测试:3个控制平面节点、2个基础设施节点和24个工作节点。该集群拥有500个命名空间。OpenShift Container Platform 对自定义资源定义 (CRD) 的总数限制为 1024 个,包括 OpenShift Container Platform 自身安装的 CRD、与 OpenShift Container Platform 集成的产品以及用户创建的 CRD。如果创建的 CRD 超过 1024 个,则oc命令请求可能会被限流。

示例场景

例如,我们测试了并支持使用 OpenShift Container Platform 4.17、OVN-Kubernetes 网络插件以及以下工作负载对象的 500 个工作节点 (m5.2xl)

  • 除默认值外,还有200个命名空间

  • 每个节点60个Pod;30个服务器Pod和30个客户端Pod(总共3万个)

  • 每个命名空间57个镜像流(总共1.14万个)

  • 每个命名空间15个由服务器Pod支持的服务(总共3000个)

  • 每个命名空间15个由上述服务支持的路由(总共3000个)

  • 每个命名空间20个密钥(总共4000个)

  • 每个命名空间10个配置映射(总共2000个)

  • 每个命名空间6个网络策略,包括拒绝所有访问、允许来自入口的访问以及命名空间内规则

  • 每个命名空间57个构建

已知以下因素会对集群工作负载扩展产生积极或消极的影响,在规划部署时应将这些因素纳入规模计算中。有关更多信息和指导,请联系您的销售代表或Red Hat 支持

  • 每个节点的 Pod 数量

  • 每个Pod的容器数量

  • 使用的探针类型(例如,存活/就绪探针,exec/http探针)

  • 网络策略的数量

  • 项目或命名空间的数量

  • 每个项目镜像流的数量

  • 每个项目构建的数量

  • 服务/端点数量及类型

  • 路由的数量

  • 分片数量

  • 密钥数量

  • 配置映射数量

  • API调用速率,或集群“波动率”,这是对集群配置变化速度的估计。

    • Prometheus 查询,用于获取 5 分钟窗口内每秒的 Pod 创建请求数:sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m]))

    • Prometheus 查询,用于获取 5 分钟窗口内每秒的所有 API 请求数:sum(irate(apiserver_request_count{}[5m]))

  • 集群节点的 CPU 资源消耗

  • 集群节点的内存资源消耗

测试集群最大值所使用的 OpenShift Container Platform 环境和配置

AWS 云平台

节点 规格 vCPU RAM(GiB) 磁盘类型 磁盘大小(GiB)/IOPS 数量 区域

控制平面/etcd [1]

r5.4xlarge

16

128

gp3

220

3

us-west-2

基础设施[2]

m5.12xlarge

48

192

gp3

100

3

us-west-2

工作负载[3]

m5.4xlarge

16

64

gp3

500 [4]

1

us-west-2

计算

m5.2xlarge

8

32

gp3

100

3/25/250/500 [5]

us-west-2

  1. 控制平面/etcd 节点使用具有 3000 IOPS 和每秒 125 MiB 基准性能的 gp3 磁盘,因为 etcd 对延迟敏感。gp3 卷不使用突发性能。

  2. 使用基础设施节点托管监控、入口和注册表组件,以确保它们拥有足够的资源来大规模运行。

  3. 工作负载节点专门用于运行性能和可扩展性工作负载生成器。

  4. 使用更大的磁盘大小是为了有足够的空间存储在性能和可扩展性测试运行期间收集的大量数据。

  5. 集群按迭代方式扩展,并在指定的节点数量下执行性能和可扩展性测试。

IBM Power 平台

节点 vCPU RAM(GiB) 磁盘类型 磁盘大小(GiB)/IOPS 数量

控制平面/etcd [1]

16

32

io1

120 / 每 GiB 10 IOPS

3

基础设施[2]

16

64

gp2

120

2

工作负载[3]

16

256

gp2

120 [4]

1

计算

16

64

gp2

120

2 到 100 [5]

  1. 控制平面/etcd 节点使用每 GiB 120/10 IOPS 的 io1 磁盘,因为 etcd 是 I/O 密集型且对延迟敏感的。

  2. 使用基础设施节点托管监控、入口和注册表组件,以确保它们拥有足够的资源来大规模运行。

  3. 工作负载节点专门用于运行性能和可扩展性工作负载生成器。

  4. 使用更大的磁盘大小是为了有足够的空间存储在性能和可扩展性测试运行期间收集的大量数据。

  5. 集群按迭代方式扩展。

IBM Z 平台

节点 vCPU [4] RAM(GiB)[5] 磁盘类型 磁盘大小(GiB)/IOPS 数量

控制平面/etcd [1,2]

8

32

ds8k

300 / LCU 1

3

计算[1,3]

8

32

ds8k

150 / LCU 2

4 个节点(扩展到每个节点 100/250/500 个 Pod)

  1. 节点分布在两个逻辑控制单元 (LCU) 之间,以优化控制平面/etcd 节点的磁盘 I/O 负载,因为 etcd 是 I/O 密集型且对延迟敏感的。Etcd 的 I/O 需求不应干扰其他工作负载。

  2. 测试使用四个计算节点,同时运行多个迭代,每个节点有 100/250/500 个 Pod。首先,使用空闲 Pod 来评估是否可以实例化 Pod。接下来,使用网络和 CPU 密集型客户端/服务器工作负载来评估系统在压力下的稳定性。客户端和服务器 Pod 成对部署,每对分布在两个计算节点上。

  3. 未使用单独的工作负载节点。工作负载模拟两个计算节点之间的微服务工作负载。

  4. 使用的物理处理器数量为六个集成 Linux 设施 (IFL)。

  5. 使用的物理内存总量为 512 GiB。

如何根据测试的集群最大值规划您的环境

在节点上超额订阅物理资源会影响 Kubernetes 调度程序在 Pod 部署期间做出的资源保证。了解您可以采取哪些措施来避免内存交换。

一些测试的最大值只在一个维度上被扩展。当许多对象在集群上运行时,它们会有所不同。

本文件中提到的数字基于 Red Hat 的测试方法、设置、配置和调整。这些数字可能会根据您自己的个人设置和环境而有所不同。

在规划您的环境时,确定预期每个节点可以容纳多少个 Pod。

required pods per cluster / pods per node = total number of nodes needed

每个节点的默认最大 Pod 数为 250。但是,节点上可以容纳的 Pod 数量取决于应用程序本身。请考虑应用程序的内存、CPU 和存储需求,如“如何根据应用程序需求规划您的环境”中所述。

示例场景

如果您想将集群的范围扩大到每个集群 2200 个 Pod,则假设每个节点最多有 500 个 Pod,则至少需要五个节点。

2200 / 500 = 4.4

如果您将节点数量增加到 20 个,则 Pod 分布将变为每个节点 110 个 Pod。

2200 / 20 = 110

其中

required pods per cluster / total number of nodes = expected pods per node

OpenShift Container Platform 带有几个系统 Pod,例如 OVN-Kubernetes、DNS、Operators 等,这些 Pod 默认情况下会在每个工作节点上运行。因此,上述公式的结果可能会有所不同。

如何根据应用程序需求规划您的环境

考虑一个示例应用程序环境

Pod 类型 Pod 数量 最大内存 CPU 核心数 持久性存储

apache

100

500 MB

0.5

1 GB

node.js

200

1 GB

1

1 GB

postgresql

100

1 GB

2

10 GB

JBoss EAP

100

1 GB

1

1 GB

推断的需求:550 个 CPU 核心、450 GB RAM 和 1.4 TB 存储。

节点的实例大小可以根据您的偏好进行上调或下调。节点通常会超额使用资源。在此部署方案中,您可以选择运行更多较小的节点或较少的较大节点以提供相同数量的资源。应考虑诸如运营敏捷性和每实例成本之类的因素。

节点类型 数量 CPU RAM (GB)

节点(选项 1)

100

4

16

节点(选项 2)

50

8

32

节点(选项 3)

25

16

64

某些应用程序适合超额使用环境,而某些应用程序则不适合。大多数 Java 应用程序和使用巨型页面的应用程序都是不允许超额使用的应用程序示例。该内存不能用于其他应用程序。在上面的示例中,环境大约超额使用了 30%,这是一个常见的比率。

应用 Pod 可以通过环境变量或 DNS 访问服务。如果使用环境变量,则对于每个活动服务,kubelet 在 Pod 在节点上运行时会注入变量。一个集群感知的 DNS 服务器监视 Kubernetes API 中的新服务,并为每个服务创建一组 DNS 记录。如果在整个集群中启用了 DNS,则所有 Pod 都应该能够自动通过其 DNS 名称解析服务。如果必须超过 5000 个服务,可以使用 DNS 进行服务发现。当使用环境变量进行服务发现时,如果命名空间中超过 5000 个服务,参数列表会超过允许的长度,那么 Pod 和 Deployment 将开始失败。禁用 deployment 服务规范文件中的服务链接可以解决此问题。

---
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: apps.openshift.io/v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    clusterIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template

可以在命名空间中运行的应用程序 Pod 数量取决于服务数量以及使用环境变量进行服务发现时服务名称的长度。系统上的ARG_MAX定义了新进程的最大参数长度,默认为 2097152 字节 (2 MiB)。Kubelet 会将环境变量注入到计划在命名空间中运行的每个 Pod 中,包括:

  • <SERVICE_NAME>_SERVICE_HOST=<IP>

  • <SERVICE_NAME>_SERVICE_PORT=<PORT>

  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>

  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>

  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp

  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>

  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

如果参数长度超过允许值,命名空间中的 Pod 将开始失败,并且服务名称中的字符数会影响它。例如,在一个拥有 5000 个服务的命名空间中,服务名称的限制为 33 个字符,这使得您可以在命名空间中运行 5000 个 Pod。