可伸缩性和性能

流程

1. 运行：

   $ oc get machineconfig

   这个命令显示了可选择的可用机器配置对象列表。默认情况下，与 kubelet 相关的配置为 01-master-kubelet 和 01-worker-kubelet。

2. 要检查每个节点中最大 Pod 数量的当前设置，请运行：

   # oc describe node <node-ip> | grep Allocatable -A6

   找到 value: pods: <value>.

   例如：

   # oc describe node ip-172-31-128-158.us-east-2.compute.internal | grep Allocatable -A6

   输出示例

   Allocatable:
    attachable-volumes-aws-ebs:  25
    cpu:                         3500m
    hugepages-1Gi:               0
    hugepages-2Mi:               0
    memory:                      15341844Ki
    pods:                        250

3. 要设置 worker 节点上的每个节点的最大 Pod，请创建一个包含 kubelet 配置的自定义资源文件。例如: change-maxPods-cr.yaml：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: large-pods
     kubeletConfig:
       maxPods: 500

   kubelet 与 API 服务器进行交互的频率取决于每秒的查询数量 (QPS) 和 burst 值。如果每个节点上运行的 pod 数量有限，使用默认值（kubeAPIQPS 为 50，kubeAPIBurst 为 100）就可以。如果节点上有足够 CPU 和内存资源，则建议更新 kubelet QPS 和 burst 率：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: large-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

   1. 运行：

      $ oc label machineconfigpool worker custom-kubelet=large-pods

   2. 运行：

      $ oc create -f change-maxPods-cr.yaml

   3. 运行：

      $ oc get kubeletconfig

      这个命令会返回 set-max-pods。

      根据集群中的 worker 节点数量，等待每个 worker 节点被逐个重启。对于有 3 个 worker 节点的集群，这个过程可能需要大约 10 到 15 分钟。

4. 查看 worker 节点的 maxPods 的变化 ：

   $ oc describe node

   1. 运行以下命令验证更改：

      $ oc get kubeletconfigs set-max-pods -o yaml

      这个命令会显示 True 状态和 type:Success

1. 运行：

   $ oc edit machineconfigpool worker

2. 将 maxUnavailable 设为所需值。

   spec:
     maxUnavailable: <node_count>

   重要

   当设置该值时，请考虑无法使用的 worker 节点数量，而不影响在集群中运行的应用程序。

流程

1. 编辑 MachineSet：

   $ oc edit machineset <machineset> -n openshift-machine-api

2. 将 MachineSet 缩减为 0：

   $ oc scale --replicas=0 machineset <machineset> -n openshift-machine-api

   或者：

   $ oc edit machineset <machineset> -n openshift-machine-api

   等待机器被删除。

3. 根据需要扩展 MachineSet：

   $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

   或者：

   $ oc edit machineset <machineset> -n openshift-machine-api

   等待机器启动。新 Machine 包含您对 MachineSet 所做的更改。

流程

1. 创建一个 healthcheck.yml 文件，其包含 MachineHealthCheck 的定义。

2. 将 healthcheck.yml 文件应用到您的集群：

   $ oc apply -f healthcheck.yml

流程

1. 运行：

   $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

流程

1. 检查每个节点上运行的 Tuned Pod:

   $ oc get pods -n openshift-cluster-node-tuning-operator -o wide

   输出示例

   NAME                                            READY   STATUS    RESTARTS   AGE    IP             NODE                                         NOMINATED NODE   READINESS GATES
   cluster-node-tuning-operator-599489d4f7-k4hw4   1/1     Running   0          6d2h   10.129.0.76    ip-10-0-145-113.eu-west-3.compute.internal   <none>           <none>
   tuned-2jkzp                                     1/1     Running   1          6d3h   10.0.145.113   ip-10-0-145-113.eu-west-3.compute.internal   <none>           <none>
   tuned-g9mkx                                     1/1     Running   1          6d3h   10.0.147.108   ip-10-0-147-108.eu-west-3.compute.internal   <none>           <none>
   tuned-kbxsh                                     1/1     Running   1          6d3h   10.0.132.143   ip-10-0-132-143.eu-west-3.compute.internal   <none>           <none>
   tuned-kn9x6                                     1/1     Running   1          6d3h   10.0.163.177   ip-10-0-163-177.eu-west-3.compute.internal   <none>           <none>
   tuned-vvxwx                                     1/1     Running   1          6d3h   10.0.131.87    ip-10-0-131-87.eu-west-3.compute.internal    <none>           <none>
   tuned-zqrwq                                     1/1     Running   1          6d3h   10.0.161.51    ip-10-0-161-51.eu-west-3.compute.internal    <none>           <none>

2. 提取从每个 Pod 应用的配置集，并将它们与上一个列表中匹配：

   $ for p in `oc get pods -n openshift-cluster-node-tuning-operator -l openshift-app=tuned -o=jsonpath='{range .items[*]}{.metadata.name} {end}'`; do printf "\n*** $p ***\n" ; oc logs pod/$p -n openshift-cluster-node-tuning-operator | grep applied; done

   输出示例

   *** tuned-2jkzp ***
   2020-07-10 13:53:35,368 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied
   
   *** tuned-g9mkx ***
   2020-07-10 14:07:17,089 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
   2020-07-10 15:56:29,005 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
   2020-07-10 16:00:19,006 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
   2020-07-10 16:00:48,989 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
   
   *** tuned-kbxsh ***
   2020-07-10 13:53:30,565 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
   2020-07-10 15:56:30,199 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
   
   *** tuned-kn9x6 ***
   2020-07-10 14:10:57,123 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node' applied
   2020-07-10 15:56:28,757 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-node-es' applied
   
   *** tuned-vvxwx ***
   2020-07-10 14:11:44,932 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied
   
   *** tuned-zqrwq ***
   2020-07-10 14:07:40,246 INFO     tuned.daemon.daemon: static tuning from profile 'openshift-control-plane' applied

流程

1. 要拉取容器镜像，请运行：

   $ sudo podman pull quay.io/openshift/origin-tests:4.3

流程

1. 使用内置的测试配置执行 Cluster Loader，它会部署五个模板构建并等待它们完成：

   $ sudo podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z -i \
   quay.io/openshift/origin-tests:4.3 /bin/bash -c 'export KUBECONFIG=/root/.kube/config && \
   openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
   should populate the cluster [Slow][Serial] [Suite:openshift]"'

   或者，通过设置 VIPERCONFIG 环境变量来执行带有用户定义的配置的 Cluster Loader：

   $ sudo podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z \
   -v ${LOCAL_CONFIG_FILE_PATH}:/root/configs/:z \
   -i quay.io/openshift/origin-tests:4.3 \
   /bin/bash -c 'KUBECONFIG=/root/.kube/config VIPERCONFIG=/root/configs/test.yaml \
   openshift-tests run-test "[sig-scalability][Feature:Performance] Load cluster \
   should populate the cluster [Slow][Serial] [Suite:openshift]"'

   在这个示例中，${LOCAL_KUBECONFIG} 代表 kubeconfig 在本地文件系统中的路径。另外，还有一个名为 ${LOCAL_CONFIG_FILE_PATH}的目录，它被挂载到包含名为 test.yaml的配置文件的容器中。另外，如果 test.yaml 引用了任何外部模板文件或 podspec 文件，则也应该被挂载到容器中。

流程

1. 可选：标记节点：

   # oc label node perf-node.example.com cpumanager=true

2. 编辑启用 CPU Manager 的节点的 MachineConfigPool 。在这个示例中，所有 worker 都启用了 CPU Manager：

   # oc edit machineconfigpool worker

3. 在 worker MachineConfigPool 中添加一个标签：

   metadata:
     creationTimestamp: 2019-xx-xxx
     generation: 3
     labels:
       custom-kubelet: cpumanager-enabled

4. 创建 KubeletConfig，cpumanager-kubeletconfig.yaml，自定义资源 (CR) 。使用上一步中创建的标签，以新的 KubeletConfig更新正确的节点。请参见 MachineConfigPoolSelector 部分：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static
        cpuManagerReconcilePeriod: 5s

5. 创建动态 KubeletConfig：

   # oc create -f cpumanager-kubeletconfig.yaml

   这会在 KubeletConfig 中添加 CPU Manager 功能。如果需要，Machine Config Operator (MCO) 将重启节点。要启用 CPU Manager，则不需要重启。

6. 检查合并的 KubeletConfig：

   # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
   
          "ownerReferences": [
               {
                   "apiVersion": "machineconfiguration.openshift.io/v1",
                   "kind": "KubeletConfig",
                   "name": "cpumanager-enabled",
                   "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
               }
           ],

7. 检查 worker 是否有更新的 kubelet.conf：

   # oc debug node/perf-node.example.com
   sh-4.4# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager
   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1 2

   当创建 KubeletConfig CR 时会定义这些设置。

8. 创建请求一个或多个内核的 Pod。限制和请求都必须将其 CPU 值设置为一个整数。这是专用于这个 Pod 的内核数：

   # cat cpumanager-pod.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause-amd64:3.0
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
     nodeSelector:
       cpumanager: "true"

9. 创建 Pod：

   # oc create -f cpumanager-pod.yaml

10. 确定为您标记的节点调度了 Pod：

    # oc describe pod cpumanager
    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

11. 确认正确配置了 cgroups。获取 pause 进程的进程 ID（PID）：

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    服务质量（QoS）等级为 Guaranteed 的 pod 被放置到 kubepods.slice 中。其它 QoS 等级的 pod 会位于 kubepods 的子 cgroups 中：

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done
    cpuset.cpus 1
    tasks 32706

12. 检查任务允许的 CPU 列表：

    # grep ^Cpus_allowed_list /proc/32706/status
     Cpus_allowed_list:    1

13. 确认系统中的另一个 pod（在这个示例中，QoS 等级为 burstable 的 pod）不能在为等级为Guaranteed 的 pod 分配的内核中运行：

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    
    0

    # oc describe node perf-node.example.com
    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    这个 VM 有两个 CPU 内核。将 kube-reserved 设定为 500 毫秒，这意味着，一个内核的一半被从节点的总容量中减小，以达到 Node Allocatable 的数量。您可以看到 Allocatable CPU 是 1500 毫秒。这意味着您可以运行一个 CPU Manager pod，因为每个 pod 需要一个完整的内核。一个完整的内核等于 1000 毫秒。如果您尝试调度第二个 pod，系统将接受该 pod，但不会调度它：

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

流程

1. 启用 LatencySensitive FeatureGate

   # oc edit featuregate/cluster

2. 添加 Feature Set: LatencySensitive 到 spec：

   # oc describe featuregate/cluster
   
   Name:         cluster
   Namespace:
   Labels:       <none>
   Annotations:  release.openshift.io/create-only: true
   API Version:  config.openshift.io/v1
   Kind:         FeatureGate
   Metadata:
     Creation Timestamp:  2019-10-30T15:06:41Z
     Generation:          2
     Resource Version:    7773803
     Self Link:           /apis/config.openshift.io/v1/featuregates/cluster
     UID:                 b00204ab-cc5e-4ca5-ad93-b9bdd738c1de
   Spec:
     Feature Set:  LatencySensitive
   Events:         <none>

3. 使用 KubeletConfig 配置 Topology Manager 策略。

   以下 YAML 文件示例显示了一个指定的 single-numa-node 策略。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static
        cpuManagerReconcilePeriod: 5s
        topologyManagerPolicy: single-numa-node 1

   1

   指定所选的拓扑管理器策略。

   # oc create -f topologymanager-kubeletconfig.yaml

1. 创建 YAML 配置文件 cluster-monitoring-config.yml。例如：

   apiVersion: v1
   kind: ConfigMap
   data:
     config.yaml: |
       prometheusOperator:
         baseImage: quay.io/coreos/prometheus-operator
         prometheusConfigReloaderBaseImage: quay.io/coreos/prometheus-config-reloader
         configReloaderBaseImage: quay.io/coreos/configmap-reload
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       prometheusK8s:
         retention: {{PROMETHEUS_RETENTION_PERIOD}} 1
         baseImage: openshift/prometheus
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: gp2
             resources:
               requests:
                 storage: {{PROMETHEUS_STORAGE_SIZE}} 2
       alertmanagerMain:
         baseImage: openshift/prometheus-alertmanager
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: gp2
             resources:
               requests:
                 storage: {{ALERTMANAGER_STORAGE_SIZE}} 3
       nodeExporter:
         baseImage: openshift/prometheus-node-exporter
       kubeRbacProxy:
         baseImage: quay.io/coreos/kube-rbac-proxy
       kubeStateMetrics:
         baseImage: quay.io/coreos/kube-state-metrics
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       grafana:
         baseImage: grafana/grafana
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       auth:
         baseImage: openshift/oauth-proxy
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
   metadata:
     name: cluster-monitoring-config
   namespace: openshift-monitoring

   1

   一个典型的值是 PROMETHEUS_retention_PERIOD=15d。时间单位使用以下后缀之一 : s 、m 、h 、d。

   2

   一个典型的值是 PROMETHEUS_STORAGE_SIZE=2000Gi。存储值可以是一个纯整数，也可以是带有以下后缀之一的整数: E 、P 、T 、G 、M 、K。您也可以使用以下效果相同的后缀：Ei 、Pi 、Ti 、Gi 、Mi 、Ki。

   3

   一个典型的值 是 alertmanager_STORAGE_SIZE=20Gi。存储值可以是一个纯整数，也可以是带有以下后缀之一的整数: E 、P 、T 、G 、M 、K。您也可以使用以下效果相同的后缀：Ei 、Pi 、Ti 、Gi 、Mi 、Ki。

2. 设置值，如保留周期和存储大小。

3. 运行以下命令应用这些更改：

   $ oc create -f cluster-monitoring-config.yml

1. 这里的 pod 数量是测试 pod 的数量。实际的 pod 数量取决于应用程序的内存、CPU 和存储要求。
2. 这在一个有 100 个 work 节点，每个 worker 节点有 500 个 pod 的集群中测试。默认 maxPods 仍为 250。要获得 500 maxPods，则必须使用自定义 KubeletConfig 将 maxPods 设置为 500 来创建集群。如果需要 500 个用户 Pod，您需要一个 hostPrefix 为 22，因为节点上已经运行了 10-15 个系统 Pod。带有 Persistent VolumeClaim (PVC) 的最大 pod 数量取决于分配 PVC 的后端存储。在我们的测试中，只有 OpenShift Container Storage v4 (OCS v4) 能够满足本文档中提到的每个节点的 pod 数量。
3. 当有大量活跃的项目时，如果键空间增长过大并超过空间配额，etcd 的性能将会受到影响。强烈建议您定期维护 etcd 存储，包括通过碎片管理释放 etcd 存储。
4. 系统中有一些控制循环，它们必须对给定命名空间中的所有对象进行迭代，以作为对一些状态更改的响应。在单一命名空间中有大量给定类型的对象可使这些循环的运行成本变高，并降低对给定状态变化的处理速度。限制假设系统有足够的 CPU 、内存和磁盘来满足应用程序的要求。
5. 每个服务端口和每个服务后端在 iptables 中都有对应条目。给定服务的后端数量会影响端点对象的大小，这会影响到整个系统发送的数据大小。

1. 这里的 pod 数量是测试 pod 的数量。实际的 pod 数量取决于应用程序的内存、CPU 和存储要求。
2. 当有大量活跃的项目时，如果键空间增长过大并超过空间配额，etcd 的性能将会受到影响。强烈建议您定期维护 etcd 存储，包括通过碎片管理释放 etcd 存储。
3. 系统中有一些控制循环，它们必须对给定命名空间中的所有对象进行迭代，以作为对一些状态更改的响应。在单一命名空间中有大量给定类型的对象可使这些循环的运行成本变高，并降低对给定状态变化的处理速度。限制假设系统有足够的 CPU 、内存和磁盘来满足应用程序的要求。
4. 每个服务端口和每个服务后端在 iptables 中都有对应条目。给定服务的后端数量会影响端点对象的大小，这会影响到整个系统发送的数据大小。

1. 带有 3000 个 IOPS 的 io1 磁盘用于 master/etcd 节点，因为 etcd 非常大，且敏感延迟。
2. Infra 节点用于托管 Monitoring、Ingress 和 Registry 组件，以确保它们有足够资源可大规模运行。
3. 工作负载节点专用于运行性能和可扩展工作负载生成器。
4. 使用更大的磁盘，以便有足够的空间存储在运行性能和可扩展性测试期间收集的大量数据。
5. 在迭代中扩展了集群，且性能和可扩展性测试是在指定节点数中执行的。

1. 对于高 iops 且流量会封顶，1024GB 磁盘用于 master/etcd 节点，因为 etcd 非常大，且敏感延迟。
2. Infra 节点用于托管 Monitoring、Ingress 和 Registry 组件，以确保它们有足够资源可大规模运行。
3. 在迭代中扩展了集群，且性能和可扩展性测试是在指定节点数中执行的。

流程

1. 为相关节点添加标签，以便 Node Tuning Operator 知道要应用 tuned 配置集的节点。tuned 配置集规定了要分配的巨页数量：

   $ oc label node <node_using_hugepages> hugepages=true

2. 创建一个包含以下内容的名为 hugepages_tuning.yaml 的文件：

   apiVersion: tuned.openshift.io/v1
   kind: Tuned
   metadata:
     name: hugepages 1
     namespace: openshift-cluster-node-tuning-operator
   spec:
     profile: 2
     - data: |
         [main]
         summary=Configuration for hugepages
         include=openshift-node
   
         [vm]
         transparent_hugepages=never
   
         [sysctl]
         vm.nr_hugepages=1024
       name: node-hugepages
     recommend:
     - match: 3
       - label: hugepages
       priority: 30
       profile: node-hugepages

   1

   将 name 参数的值设置为 hugepages。

   2

   将 profile 部分设置为分配巨页。

   3

   将 match 部分设置为将配置集与带有 hugepages 标签的节点相关联。

3. 使用 hugepages_tuning.yaml 文件创建定制的 hugepages tuned 配置集：

   $ oc create -f hugepages_tuning.yaml

4. 在创建配置集后，Operator 会将新配置集应用到正确的节点中，并分配巨页。在使用巨页的节点中检查 tuned pod 的日志以确认：

   $ oc logs <tuned_pod_on_node_using_hugepages> \
       -n openshift-cluster-node-tuning-operator | grep 'applied$' | tail -n1
   
   2019-08-08 07:20:41,286 INFO     tuned.daemon.daemon: static tuning from profile 'node-hugepages' applied