확장 및 성능

사전 요구 사항

1. 구성하려는 노드 유형의 정적 MachineConfigPool CR와 연관된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.

   1. Machine config pool을 표시합니다.

      $ oc describe machineconfigpool <name>

      예를 들면 다음과 같습니다.

      $ oc describe machineconfigpool worker

      출력 예

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: set-max-pods 1

      1

      라벨이 추가되면 labels 아래에 표시됩니다.

   2. 라벨이 없으면 키/값 쌍을 추가합니다.

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

절차

1. 이 명령은 선택할 수 있는 사용 가능한 머신 구성 오브젝트를 표시합니다.

   $ oc get machineconfig

   기본적으로 두 개의 kubelet 관련 구성은 01-master-kubelet 및 01-worker-kubelet입니다.

2. 노드당 최대 Pod의 현재 값을 확인하려면 다음을 실행합니다.

   $ oc describe node <node_name>

   예를 들어 다음과 같습니다.

   $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

   Allocatable 스탠자에서 value: pods: <value>를 찾습니다.

   출력 예

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

3. 작업자 노드에서 노드당 최대 Pod 수를 설정하려면 kubelet 구성이 포함된 사용자 정의 리소스 파일을 생성합니다.

   중요

   특정 머신 구성 풀을 대상으로 하는 kubelet 구성도 종속 풀에 영향을 미칩니다. 예를 들어 작업자 노드가 포함된 풀에 대한 kubelet 구성을 생성하면 인프라 노드가 포함된 풀을 포함한 모든 하위 집합 풀에도 적용됩니다. 이를 방지하려면 작업자 노드만 포함하는 선택 표현식을 사용하여 새 머신 구성 풀을 생성하고 kubelet 구성이 이 새 풀을 대상으로 지정하도록 해야 합니다.

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

   1

   머신 구성 풀에서 레이블을 입력합니다.

   2

   kubelet 구성을 추가합니다. 이 예에서는 maxPods를 사용하여 노드당 최대 Pod를 설정합니다.

   참고

   kubelet이 API 서버와 통신하는 속도는 QPS(초당 쿼리) 및 버스트 값에 따라 달라집니다. 노드마다 실행되는 Pod 수가 제한된 경우 기본 값인 50(kubeAPIQPS인 경우) 및 100(kubeAPIBurst인 경우)이면 충분합니다. 노드에 CPU 및 메모리 리소스가 충분한 경우 kubelet QPS 및 버스트 속도를 업데이트하는 것이 좋습니다.

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

   1. 라벨을 사용하여 작업자의 머신 구성 풀을 업데이트합니다.

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

   2. KubeletConfig 오브젝트를 생성합니다.

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

   3. KubeletConfig 오브젝트가 생성되었는지 확인합니다.

      $ oc get kubeletconfig

      출력 예

      NAME                AGE
      set-max-pods        15m

      클러스터의 작업자 노드 수에 따라 작업자 노드가 하나씩 재부팅될 때까지 기다립니다. 작업자 노드가 3개인 클러스터의 경우 약 10~15분이 걸릴 수 있습니다.

4. 변경 사항이 노드에 적용되었는지 확인합니다.

   1. 작업자 노드에서 maxPods 값이 변경되었는지 확인합니다.

      $ oc describe node <node_name>

   2. Allocatable 스탠자를 찾습니다.

       ...
      Allocatable:
        attachable-volumes-gce-pd:  127
        cpu:                        3500m
        ephemeral-storage:          123201474766
        hugepages-1Gi:              0
        hugepages-2Mi:              0
        memory:                     14225400Ki
        pods:                       500 1
       ...

      1

      이 예에서 pods 매개변수는 KubeletConfig 오브젝트에 설정한 값을 보고해야 합니다.

5. KubeletConfig 오브젝트에서 변경 사항을 확인합니다.

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

   다음 예와 같이 True 및 type:Success 상태가 표시되어야 합니다.

   spec:
     kubeletConfig:
       maxPods: 500
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
   status:
     conditions:
     - lastTransitionTime: "2021-06-30T17:04:07Z"
       message: Success
       status: "True"
       type: Success

절차

1. worker 머신 구성 풀을 편집합니다.

   $ oc edit machineconfigpool worker

2. maxUnavailable 필드를 추가하고 값을 설정합니다.

   spec:
     maxUnavailable: <node_count>

   중요

   값을 설정하는 경우 클러스터에서 실행 중인 애플리케이션에 영향을 미치지 않고 사용 가능한 상태로 둘 수 있는 작업자 노드 수를 고려하십시오.

절차

1. 새 디스크를 클러스터에 연결하고 디버그 쉘에서 lsblk 명령을 사용하여 노드에서 디스크가 감지되었는지 확인합니다.

   $ oc debug node/<node_name>

   # lsblk

   lsblk 명령에서 보고한 새 디스크의 장치 이름을 확인합니다.

2. 다음과 같은 내용이 포함된 etcd-mc.yml 이라는 MachineConfig YAML 파일을 생성하여 < new_disk_name >의 인스턴스를 지정된 장치 이름으로 교체합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Make File System on /dev/<new_disk_name>
             DefaultDependencies=no
             BindsTo=dev-<new_disk_name>.device
             After=dev-<new_disk_name>.device var.mount
             Before=systemd-fsck@dev-<new_disk_name>.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecStart=/usr/lib/systemd/systemd-makefs xfs /dev/<new_disk_name>
             TimeoutSec=0
   
             [Install]
             WantedBy=var-lib-containers.mount
           enabled: true
           name: systemd-mkfs@dev-<new_disk_name>.service
         - contents: |
             [Unit]
             Description=Mount /dev/<new_disk_name> to /var/lib/etcd
             Before=local-fs.target
             Requires=systemd-mkfs@dev-<new_disk_name>.service
             After=systemd-mkfs@dev-<new_disk_name>.service var.mount
   
             [Mount]
             What=/dev/<new_disk_name>
             Where=/var/lib/etcd
             Type=xfs
             Options=defaults,prjquota
   
             [Install]
             WantedBy=local-fs.target
           enabled: true
           name: var-lib-etcd.mount
         - contents: |
             [Unit]
             Description=Sync etcd data if new mount is empty
             DefaultDependencies=no
             After=var-lib-etcd.mount var.mount
             Before=crio.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecCondition=/usr/bin/test ! -d /var/lib/etcd/member
             ExecStart=semanage fcontext -a -e /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
             ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
             TimeoutSec=0
   
             [Install]
             WantedBy=multi-user.target graphical.target
           enabled: true
           name: sync-var-lib-etcd-to-etcd.service
         - contents: |
             [Unit]
             Description=Restore recursive SELinux security contexts
             DefaultDependencies=no
             After=var-lib-etcd.mount
             Before=crio.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecStart=/sbin/restorecon -R /var/lib/etcd/
             TimeoutSec=0
   
             [Install]
             WantedBy=multi-user.target graphical.target
           enabled: true
           name: restorecon-var-lib-etcd.service

3. cluster-admin 권한이 있는 사용자로 클러스터에 로그인하고 머신 구성을 생성합니다.

   $ oc login -u <username> -p <password>

   $ oc create -f etcd-mc.yml

   노드가 업데이트 및 재부팅됩니다. 재부팅이 완료되면 다음 이벤트가 수행됩니다.

   • XFS 파일 시스템이 지정된 디스크에 생성됩니다.
   • 디스크가 /var/lib/etcd 에 마운트되어 있습니다.
   • /sysroot/ostree/deploy/rhcos/var/lib/etcd 의 콘텐츠와 /var/lib/etcd 입니다.
   • /var/lib/etcd 에 대해 SELinux 레이블 복원이 강제 적용됩니다.
   • 이전 콘텐츠는 제거되지 않습니다.

4. 노드가 별도의 디스크에 있는 후 etcd-mc.yml 파일을 다음과 같은 내용으로 업데이트하여 < new_disk_name >의 인스턴스를 지정된 장치 이름으로 교체합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Mount /dev/<new_disk_name> to /var/lib/etcd
             Before=local-fs.target
             Requires=systemd-mkfs@dev-<new_disk_name>.service
             After=systemd-mkfs@dev-<new_disk_name>.service var.mount
   
             [Mount]
             What=/dev/<new_disk_name>
             Where=/var/lib/etcd
             Type=xfs
             Options=defaults,prjquota
   
             [Install]
             WantedBy=local-fs.target
           enabled: true
           name: var-lib-etcd.mount

5. 노드가 재부팅되지 않도록 장치를 생성하고 동기화하는 논리를 제거하는 수정된 버전을 적용합니다.

   $ oc replace -f etcd-mc.yml

프로세스

1. cluster-monitoring-config 구성 맵을 편집하고 infra 레이블을 사용하도록 nodeSelector 를 변경합니다.

   $ oc edit configmap cluster-monitoring-config -n openshift-monitoring

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute

   1 1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.

2. 모니터링 pod가 새 머신으로 이동하는 것을 확인합니다.

   $ watch 'oc get pod -n openshift-monitoring -o wide'

3. 구성 요소가 infra 노드로 이동하지 않은 경우 이 구성 요소가 있는 pod를 제거합니다.

   $ oc delete pod -n openshift-monitoring <pod>

   삭제된 pod의 구성 요소가 infra 노드에 다시 생성됩니다.

프로세스

1. config/instance 개체를 표시합니다.

   $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

   출력 예

   apiVersion: imageregistry.operator.openshift.io/v1
   kind: Config
   metadata:
     creationTimestamp: 2019-02-05T13:52:05Z
     finalizers:
     - imageregistry.operator.openshift.io/finalizer
     generation: 1
     name: cluster
     resourceVersion: "56174"
     selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
     uid: 36fd3724-294d-11e9-a524-12ffeee2931b
   spec:
     httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
     logging: 2
     managementState: Managed
     proxy: {}
     replicas: 1
     requests:
       read: {}
       write: {}
     storage:
       s3:
         bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
         region: us-east-1
   status:
   ...

2. config/instance 개체를 편집합니다.

   $ oc edit configs.imageregistry.operator.openshift.io/cluster

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector: 1
       node-role.kubernetes.io/infra: ""
     tolerations:
     - effect: NoSchedule
       key: node-role.kubernetes.io/infra
       value: reserved
     - effect: NoExecute
       key: node-role.kubernetes.io/infra
       value: reserved

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.

3. 레지스트리 pod가 인프라 노드로 이동되었는지 검증합니다.

   1. 다음 명령을 실행하여 레지스트리 pod가 있는 노드를 식별합니다.

      $ oc get pods -o wide -n openshift-image-registry

   2. 노드에 지정된 레이블이 있는지 확인합니다.

      $ oc describe node <node_name>

      명령 출력을 확인하고 node-role.kubernetes.io/infra가 LABELS 목록에 있는지 확인합니다.

프로세스

1. 라우터 Operator의 IngressController 사용자 정의 리소스를 표시합니다.

   $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

   명령 출력은 다음 예제와 유사합니다.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     creationTimestamp: 2019-04-18T12:35:39Z
     finalizers:
     - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
     generation: 1
     name: default
     namespace: openshift-ingress-operator
     resourceVersion: "11341"
     selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a
   spec: {}
   status:
     availableReplicas: 2
     conditions:
     - lastTransitionTime: 2019-04-18T12:36:15Z
       status: "True"
       type: Available
     domain: apps.<cluster>.example.com
     endpointPublishingStrategy:
       type: LoadBalancerService
     selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

2. ingresscontroller 리소스를 편집하고 infra 레이블을 사용하도록 nodeSelector를 변경합니다.

   $ oc edit ingresscontroller default -n openshift-ingress-operator

     spec:
       nodePlacement:
         nodeSelector: 1
           matchLabels:
             node-role.kubernetes.io/infra: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 허용 오차도 추가합니다.

3. 라우터 pod가 infra 노드에서 실행되고 있는지 확인합니다.

   1. 라우터 pod 목록을 표시하고 실행중인 pod의 노드 이름을 기록해 둡니다.

      $ oc get pod -n openshift-ingress -o wide

      출력 예

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      이 예에서 실행중인 pod는 ip-10-0-217-226.ec2.internal 노드에 있습니다.

   2. 실행중인 pod의 노드 상태를 표시합니다.

      $ oc get node <node_name> 1

      1

      pod 목록에서 얻은 <node_name>을 지정합니다.

      출력 예

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.24.0

      역할 목록에 infra가 포함되어 있으므로 pod가 올바른 노드에서 실행됩니다.

프로세스

1. 머신 세트를 편집합니다.

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

2. 변경 사항을 적용하기 위해 머신 세트를 스케일링할 때 필요하므로 spec.replicas 필드의 값을 확인합니다.

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machine_set_name>
     namespace: openshift-machine-api
   spec:
     replicas: 2 1
   # ...

   1

   이 절차의 예제에서는 replicas 값이 2 인 머신 세트를 보여줍니다.

3. 원하는 구성 옵션으로 머신 세트 CR을 업데이트하고 변경 사항을 저장합니다.

4. 다음 명령을 실행하여 업데이트된 머신 세트에서 관리하는 머신을 나열합니다.

   $ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name>

   출력 예

   NAME                        PHASE     TYPE         REGION      ZONE         AGE
   <machine_name_original_1>   Running   m6i.xlarge   us-west-1   us-west-1a   4h
   <machine_name_original_2>   Running   m6i.xlarge   us-west-1   us-west-1a   4h

5. 업데이트된 머신 세트에서 관리하는 각 머신에 대해 다음 명령을 실행하여 삭제 주석을 설정합니다.

   $ oc annotate machine/<machine_name_original_1> \
     -n openshift-machine-api \
     machine.openshift.io/delete-machine="true"

6. 다음 명령을 실행하여 머신 세트를 복제본 수의 두 배로 스케일링합니다.

   $ oc scale --replicas=4 \1
     machineset <machine_set_name> \
     -n openshift-machine-api

   1

   원래 예제 값 2 는 4 로 두 배가됩니다.

7. 다음 명령을 실행하여 업데이트된 머신 세트에서 관리하는 머신을 나열합니다.

   $ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name>

   출력 예

   NAME                        PHASE          TYPE         REGION      ZONE         AGE
   <machine_name_original_1>   Running        m6i.xlarge   us-west-1   us-west-1a   4h
   <machine_name_original_2>   Running        m6i.xlarge   us-west-1   us-west-1a   4h
   <machine_name_updated_1>    Provisioned    m6i.xlarge   us-west-1   us-west-1a   55s
   <machine_name_updated_2>    Provisioning   m6i.xlarge   us-west-1   us-west-1a   55s

   새 머신이 Running 단계에 있는 경우 머신 세트를 원래 복제본 수로 확장할 수 있습니다.

8. 다음 명령을 실행하여 머신 세트를 원래 복제본 수로 확장합니다.

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

   1

   원래 예제 값인 2 입니다.

프로세스

1. 머신 상태 점검 정의가 포함된 healthcheck.yml 파일을 생성합니다.

2. healthcheck.yml 파일을 클러스터에 적용합니다.

   $ oc apply -f healthcheck.yml

프로세스

1. 선택사항: 노드에 레이블을 지정합니다.

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

2. CPU 관리자를 활성화해야 하는 노드의 MachineConfigPool을 편집합니다. 이 예에서는 모든 작업자의 CPU 관리자가 활성화됩니다.

   # oc edit machineconfigpool worker

3. 작업자 머신 구성 풀에 레이블을 추가합니다.

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

4. KubeletConfig, cpumanager-kubeletconfig.yaml, CR(사용자 정의 리소스)을 생성합니다. 이전 단계에서 생성한 레이블을 참조하여 올바른 노드가 새 kubelet 구성으로 업데이트되도록 합니다. machineConfigPoolSelector 섹션을 참조하십시오.

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

   1

   정책을 지정합니다.

   • none. 이 정책은 기존 기본 CPU 선호도 체계를 명시적으로 활성화하여 스케줄러가 자동으로 수행하는 것 이상으로 선호도를 제공하지 않도록 합니다. 이는 기본 정책입니다.
   • static. 이 정책을 사용하면 정수 CPU 요청이 있는 보장된 Pod의 컨테이너를 사용할 수 있습니다. 또한 노드의 전용 CPU에 대한 액세스 권한을 제한합니다. 정 적인 경우 소문자 s 를 사용해야 합니다.

   2

   선택사항입니다. CPU 관리자 조정 빈도를 지정합니다. 기본값은 5s입니다.

5. 동적 kubelet 구성을 생성합니다.

   # oc create -f cpumanager-kubeletconfig.yaml

   그러면 kubelet 구성에 CPU 관리자 기능이 추가되고 필요한 경우 MCO(Machine Config Operator)가 노드를 재부팅합니다. CPU 관리자를 활성화하는 데는 재부팅이 필요하지 않습니다.

6. 병합된 kubelet 구성을 확인합니다.

   # 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. 작업자에서 업데이트된 kubelet.conf를 확인합니다.

   # oc debug node/perf-node.example.com
   sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

   출력 예

   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1

   cpuManagerPolicy 는 KubeletConfig CR을 생성할 때 정의됩니다.

   2

   cpuManagerReconcilePeriod 는 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 프로세스의 PID(프로세스 ID)를 가져옵니다.

    # ├─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(Quality of Service) 계층 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. Guaranteed Pod용으로 할당된 코어에서는 시스템의 다른 Pod(이 경우 burstable QoS 계층의 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 코어가 있습니다. system-reserved 설정은 500밀리코어로 설정되었습니다. 즉, Node Allocatable 양이 되는 노드의 전체 용량에서 한 코어의 절반이 감산되었습니다. Allocatable CPU는 1500 밀리코어임을 확인할 수 있습니다. 즉, Pod마다 하나의 전체 코어를 사용하므로 CPU 관리자 Pod 중 하나를 실행할 수 있습니다. 전체 코어는 1000밀리코어에 해당합니다. 두 번째 Pod를 예약하려고 하면 시스템에서 해당 Pod를 수락하지만 Pod가 예약되지 않습니다.

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

1. 사용자 정의 리소스에서 토폴로지 관리자 할당 정책을 구성합니다.

   $ oc edit KubeletConfig cpumanager-enabled

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

   1

   이 매개변수는 소문자 s 가 있는 static 이어야 합니다.

   2

   선택한 토폴로지 관리자 할당 정책을 지정합니다. 여기서는 정책이 single-numa-node입니다. 허용 가능한 값은 default, best-effort, restricted, single-numa-node입니다.

절차

1. 작업자 노드에 대한 사용자 정의 kubelet 구성을 활성화하는 MachineConfigPool 사용자 정의 리소스를 생성합니다.

   1. 다음 YAML을 nro-machineconfig.yaml 파일에 저장합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        labels:
          cnf-worker-tuning: enabled
          machineconfiguration.openshift.io/mco-built-in: ""
          pools.operator.machineconfiguration.openshift.io/worker: ""
        name: worker
      spec:
        machineConfigSelector:
          matchLabels:
            machineconfiguration.openshift.io/role: worker
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""

   2. 다음 명령을 실행하여 MachineConfigPool CR을 생성합니다.

      $ oc create -f nro-machineconfig.yaml

2. NUMAResourcesOperator 사용자 정의 리소스를 생성합니다.

   1. nrop.yaml 파일에 다음 YAML을 저장합니다.

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesOperator
      metadata:
        name: numaresourcesoperator
      spec:
        nodeGroups:
        - machineConfigPoolSelector:
            matchLabels:
              pools.operator.machineconfiguration.openshift.io/worker: "" 1

      1

      관련 MachineConfigPool CR의 작업자 노드에 적용되는 레이블과 일치해야 합니다.

   2. 다음 명령을 실행하여 NUMAResourcesOperator CR을 생성합니다.

      $ oc create -f nrop.yaml

절차

1. 머신 프로필에 대한 Pod 허용 정책을 구성하는 KubeletConfig 사용자 정의 리소스를 생성합니다.

   1. 다음 YAML을 nro-kubeletconfig.yaml 파일에 저장합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      metadata:
        name: cnf-worker-tuning
      spec:
        machineConfigPoolSelector:
          matchLabels:
            cnf-worker-tuning: enabled
        kubeletConfig:
          cpuManagerPolicy: "static" 1
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1"
          memoryManagerPolicy: "Static" 2
          evictionHard:
            memory.available: "100Mi"
          kubeReserved:
            memory: "512Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node" 3
          topologyManagerScope: "pod"

      1

      cpuManagerPolicy 의 경우static 은 소문자 s 를 사용해야 합니다.

      2

      memoryManagerPolicy 의 경우정적 에서는 대문자 S 를 사용해야 합니다.

      3

      topologyManagerPolicy 를 single-numa-node 로 설정해야 합니다.

   2. 다음 명령을 실행하여 KubeletConfig CR(사용자 정의 리소스)을 생성합니다.

      $ oc create -f nro-kubeletconfig.yaml

2. NUMA 인식 사용자 정의 Pod 스케줄러를 배포하는 NUMAResourcesScheduler 사용자 정의 리소스를 생성합니다.

   1. 다음 YAML을 nro-scheduler.yaml 파일에 저장합니다.

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.11"

   2. 다음 명령을 실행하여 NUMAResourcesScheduler CR을 생성합니다.

      $ oc create -f nro-scheduler.yaml

절차

1. 다음 명령을 실행하여 클러스터에 배포된 NUMA 인식 스케줄러의 이름을 가져옵니다.

   $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

   출력 예

   topo-aware-scheduler

2. topo-aware-scheduler 라는 스케줄러를 사용하는 Deployment CR을 생성합니다. 예를 들면 다음과 같습니다.

   1. 다음 YAML을 nro-deployment.yaml 파일에 저장합니다.

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: numa-deployment-1
        namespace: openshift-numaresources
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: test
        template:
          metadata:
            labels:
              app: test
          spec:
            schedulerName: topo-aware-scheduler 1
            containers:
            - name: ctnr
              image: quay.io/openshifttest/hello-openshift:openshift
              imagePullPolicy: IfNotPresent
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "10"
                requests:
                  memory: "100Mi"
                  cpu: "10"
            - name: ctnr2
              image: registry.access.redhat.com/rhel:latest
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args: [ "while true; do sleep 1h; done;" ]
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "8"
                requests:
                  memory: "100Mi"
                  cpu: "8"

      1

      schedulerName 은 클러스터에 배포된 NUMA 인식 스케줄러의 이름과 일치해야 합니다(예: topo-aware-scheduler ).

   2. 다음 명령을 실행하여 Deployment CR을 생성합니다.

      $ oc create -f nro-deployment.yaml

검증

1. 배포에 성공했는지 확인합니다.

   $ oc get pods -n openshift-numaresources

   출력 예

   NAME                                                READY   STATUS    RESTARTS   AGE
   numa-deployment-1-56954b7b46-pfgw8                  2/2     Running   0          129m
   numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          15h
   numaresourcesoperator-worker-dvj4n                  2/2     Running   0          18h
   numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16h
   secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          18h

2. 다음 명령을 실행하여 topo-aware-scheduler 에서 배포된 Pod를 예약하고 있는지 확인합니다.

   $ oc describe pod numa-deployment-1-56954b7b46-pfgw8 -n openshift-numaresources

   출력 예

   Events:
     Type    Reason          Age   From                  Message
     ----    ------          ----  ----                  -------
     Normal  Scheduled       130m  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-56954b7b46-pfgw8 to compute-0.example.com

   참고

   예약할 수 있는 것보다 더 많은 리소스를 요청하는 배포는 MinimumReplicasUnavailable 오류로 실패합니다. 필요한 리소스를 사용할 수 있게 되면 배포가 성공합니다. 필요한 리소스를 사용할 수 있을 때까지 Pod는 Pending 상태로 유지됩니다.

3. 예상 할당된 리소스가 노드에 나열되어 있는지 확인합니다. 다음 명령을 실행합니다.

   $ oc describe noderesourcetopologies.topology.node.k8s.io

   출력 예

   ...
   
   Zones:
     Costs:
       Name:   node-0
       Value:  10
       Name:   node-1
       Value:  21
     Name:     node-0
     Resources:
       Allocatable:  39
       Available:    21 1
       Capacity:     40
       Name:         cpu
       Allocatable:  6442450944
       Available:    6442450944
       Capacity:     6442450944
       Name:         hugepages-1Gi
       Allocatable:  134217728
       Available:    134217728
       Capacity:     134217728
       Name:         hugepages-2Mi
       Allocatable:  262415904768
       Available:    262206189568
       Capacity:     270146007040
       Name:         memory
     Type:           Node

   1

   보장된 Pod에 할당된 리소스로 인해 사용 가능한 용량이 줄어듭니다.

   보장된 Pod에서 사용하는 리소스는 noderesourcetopologies.topology.node.k8s.io 아래에 나열된 사용 가능한 노드 리소스에서 제거됩니다.

4. Best-effort 또는 Burstable 서비스 품질(qosClass)이 있는 Pod에 대한 리소스 할당은 noderesourcetopologies.topology.node.k8s.io 의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 소비 리소스가 노드 리소스 계산에 반영되지 않는 경우 다음 명령을 실행하여 Pod에 Guaranteed qosClass 가 있는지 확인합니다.

   $ oc get pod <pod_name> -n <pod_namespace> -o jsonpath="{ .status.qosClass }"

   출력 예

   Guaranteed

절차

1. 다음 명령을 실행하여 noderesourcetopologies CRD가 클러스터에 배포되었는지 확인합니다.

   $ oc get crd | grep noderesourcetopologies

   출력 예

   NAME                                                              CREATED AT
   noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

2. NUMA 인식 스케줄러 이름이 다음 명령을 실행하여 NUMA 인식 워크로드에 지정된 이름과 일치하는지 확인합니다.

   $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

   출력 예

   topo-aware-scheduler

3. NUMA가 인식 가능한 노드에 noderesourcetopologies CR이 적용되는지 확인합니다. 다음 명령을 실행합니다.

   $ oc get noderesourcetopologies.topology.node.k8s.io

   출력 예

   NAME                    AGE
   compute-0.example.com   17h
   compute-1.example.com   17h

   참고

   노드 수는 머신 구성 풀(mcp) 작업자 정의로 구성된 작업자 노드 수와 같아야 합니다.

4. 다음 명령을 실행하여 모든 측정 가능한 노드에 대한 NUMA 영역 세분성을 확인합니다.

   $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

   출력 예

   apiVersion: v1
   items:
   - apiVersion: topology.node.k8s.io/v1alpha1
     kind: NodeResourceTopology
     metadata:
       annotations:
         k8stopoawareschedwg/rte-update: periodic
       creationTimestamp: "2022-06-16T08:55:38Z"
       generation: 63760
       name: worker-0
       resourceVersion: "8450223"
       uid: 8b77be46-08c0-4074-927b-d49361471590
     topologyPolicies:
     - SingleNUMANodeContainerLevel
     zones:
     - costs:
       - name: node-0
         value: 10
       - name: node-1
         value: 21
       name: node-0
       resources:
       - allocatable: "38"
         available: "38"
         capacity: "40"
         name: cpu
       - allocatable: "134217728"
         available: "134217728"
         capacity: "134217728"
         name: hugepages-2Mi
       - allocatable: "262352048128"
         available: "262352048128"
         capacity: "270107316224"
         name: memory
       - allocatable: "6442450944"
         available: "6442450944"
         capacity: "6442450944"
         name: hugepages-1Gi
       type: Node
     - costs:
       - name: node-0
         value: 21
       - name: node-1
         value: 10
       name: node-1
       resources:
       - allocatable: "268435456"
         available: "268435456"
         capacity: "268435456"
         name: hugepages-2Mi
       - allocatable: "269231067136"
         available: "269231067136"
         capacity: "270573244416"
         name: memory
       - allocatable: "40"
         available: "40"
         capacity: "40"
         name: cpu
       - allocatable: "1073741824"
         available: "1073741824"
         capacity: "1073741824"
         name: hugepages-1Gi
       type: Node
   - apiVersion: topology.node.k8s.io/v1alpha1
     kind: NodeResourceTopology
     metadata:
       annotations:
         k8stopoawareschedwg/rte-update: periodic
       creationTimestamp: "2022-06-16T08:55:37Z"
       generation: 62061
       name: worker-1
       resourceVersion: "8450129"
       uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
     topologyPolicies:
     - SingleNUMANodeContainerLevel
     zones: 1
     - costs:
       - name: node-0
         value: 10
       - name: node-1
         value: 21
       name: node-0
       resources: 2
       - allocatable: "38"
         available: "38"
         capacity: "40"
         name: cpu
       - allocatable: "6442450944"
         available: "6442450944"
         capacity: "6442450944"
         name: hugepages-1Gi
       - allocatable: "134217728"
         available: "134217728"
         capacity: "134217728"
         name: hugepages-2Mi
       - allocatable: "262391033856"
         available: "262391033856"
         capacity: "270146301952"
         name: memory
       type: Node
     - costs:
       - name: node-0
         value: 21
       - name: node-1
         value: 10
       name: node-1
       resources:
       - allocatable: "40"
         available: "40"
         capacity: "40"
         name: cpu
       - allocatable: "1073741824"
         available: "1073741824"
         capacity: "1073741824"
         name: hugepages-1Gi
       - allocatable: "268435456"
         available: "268435456"
         capacity: "268435456"
         name: hugepages-2Mi
       - allocatable: "269192085504"
         available: "269192085504"
         capacity: "270534262784"
         name: memory
       type: Node
   kind: List
   metadata:
     resourceVersion: ""
     selfLink: ""

   1

   영역 의 각 스탠자는 단일 NUMA 영역의 리소스를 설명합니다.

   2

   리소스 는 NUMA 영역 리소스의 현재 상태를 설명합니다. items.zones.resources.available 에 나열된 리소스가 각 보장된 pod에 할당된 독점 NUMA 영역 리소스와 일치하는지 확인합니다.

1. YAML 구성 파일 cluster-monitoring-config.yaml 을 생성합니다. 예를 들어 다음과 같습니다.

   apiVersion: v1
   kind: ConfigMap
   data:
     config.yaml: |
       prometheusK8s:
         retention: {{PROMETHEUS_RETENTION_PERIOD}} 1
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: {{STORAGE_CLASS}} 2
             resources:
               requests:
                 storage: {{PROMETHEUS_STORAGE_SIZE}} 3
       alertmanagerMain:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: {{STORAGE_CLASS}} 4
             resources:
               requests:
                 storage: {{ALERTMANAGER_STORAGE_SIZE}} 5
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring

   1

   Prometheus 보존의 기본값은 PROMETHEUS_RETENTION_PERIOD=15d 입니다. 단위는 s, m, h, d 접미사 중 하나를 사용하는 시간으로 측정됩니다.

   2 4

   클러스터의 스토리지 클래스입니다.

   3

   일반적인 값은 PROMETHEUS_STORAGE_SIZE=2000Gi입니다. 스토리지 값은 일반 정수 또는 E, P, T, G, M, K 접미사 중 하나를 사용하는 고정 지점 정수일 수 있습니다. Ei, Pi, Ti, Gi, Mi, Ki의 power-of-two를 사용할 수도 있습니다.

   5

   일반적인 값은 ALERTMANAGER_STORAGE_SIZE=20Gi입니다. 스토리지 값은 일반 정수 또는 E, P, T, G, M, K 접미사 중 하나를 사용하는 고정 지점 정수일 수 있습니다. Ei, Pi, Ti, Gi, Mi, Ki의 power-of-two를 사용할 수도 있습니다.

2. 보존 기간, 스토리지 클래스 및 스토리지 크기에 대한 값을 추가합니다.
3. 파일을 저장합니다.

4. 다음을 실행하여 변경사항을 적용합니다.

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

1. 2000개의 노드 규모에서 OpenShift Container Platform의 컨트롤 플레인 구성 요소를 강조하기 위해 일시 정지 Pod가 배포되었습니다.
2. 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
3. 이 테스트는 작업자 노드가 100개이며 작업자 노드당 Pod가 500개인 클러스터에서 수행되었습니다. 기본 maxPods는 계속 250입니다. maxPods가 500이 되도록 하려면 사용자 정의 kubelet 구성을 사용하여 500으로 설정된 maxPods가 포함된 클러스터를 생성해야 합니다. 500개의 사용자 Pod가 필요한 경우 노드에서 이미 실행되고 있는 시스템 Pod가 10~15개가 있으므로 hostPrefix 22가 필요합니다. 연결된 PVC(영구 볼륨 클레임)가 있는 Pod의 최대 수는 PVC가 할당된 스토리지 백엔드에 따라 달라집니다. 이 테스트에서는 OpenShift Data Foundation v4(OCS v4)만 이 문서에서 설명하는 노드당 Pod 수를 충족할 수 있었습니다.
4. 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 확보하려면 조각 모음을 포함하여 etcd를 정기적으로 유지 관리하는 것이 좋습니다.
5. 시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트에서 반복해야 하는 컨트롤 루프가 많습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
6. 각 서비스 포트와 각 서비스 백엔드는 iptables에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
7. OpenShift Container Platform에는 OpenShift Container Platform에 의해 설치된 제품, OpenShift Container Platform 및 사용자 생성 CRD와 통합되는 제품을 포함한 512개 총 CRD(사용자 정의 리소스 정의) 제한이 있습니다. 512개 이상의 CRD가 생성된 경우 oc 명령 요청이 제한될 수 있습니다.

1. NetApp NFS는 Trident 플러그인을 사용할 때 동적 PV 프로비저닝을 지원합니다.

1. cluster.k8s.io/delete-machine: true를 사용하여 베어 메탈 호스트 CR에 주석을 답니다.
2. 관련 머신 세트를 축소합니다.

검증

1. AMQ Interconnect Operator를 사용할 수 있고 필요한 Pod가 실행 중인지 확인합니다.

   $ oc get pods -n amq-interconnect

   출력 예

   NAME                                    READY   STATUS    RESTARTS   AGE
   amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
   interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

2. 필요한 bare-metal-event-relay 베어 메탈 이벤트 생산자 Pod가 openshift-bare-metal-events 네임스페이스에서 실행 중인지 확인합니다.

   $ oc get pods -n openshift-bare-metal-events

   출력 예

   NAME                                                            READY   STATUS    RESTARTS   AGE
   hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl     2/2     Running   0          25s

절차

1. 다음 예와 유사한 hugepages-volume-pod.yaml 파일을 생성합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: hugepages-volume-
     labels:
       app: hugepages-example
   spec:
     containers:
     - securityContext:
         capabilities:
           add: [ "IPC_LOCK" ]
       image: rhel7:latest
       command:
       - sleep
       - inf
       name: example
       volumeMounts:
       - mountPath: /dev/hugepages
         name: hugepage
       - mountPath: /etc/podinfo
         name: podinfo
       resources:
         limits:
           hugepages-1Gi: 2Gi
           memory: "1Gi"
           cpu: "1"
         requests:
           hugepages-1Gi: 2Gi
       env:
       - name: REQUESTS_HUGEPAGES_1GI <.>
         valueFrom:
           resourceFieldRef:
             containerName: example
             resource: requests.hugepages-1Gi
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages
     - name: podinfo
       downwardAPI:
         items:
           - path: "hugepages_1G_request" <.>
             resourceFieldRef:
               containerName: example
               resource: requests.hugepages-1Gi
               divisor: 1Gi

   <.> requests.hugepages-1Gi에서 리소스 사용을 읽고 값을 REQUESTS_HUGEPAGES_1GI 환경 변수로 표시하도록 지정합니다. <.>는 requests.hugepages-1Gi에서 리소스 사용을 읽고 값을 파일 /etc/podinfo/hugepages_1G_request로 표시하도록 지정합니다.

2. volume-pod.yaml 파일에서 Pod를 생성합니다.

   $ oc create -f hugepages-volume-pod.yaml

검증

1. REQUESTS_HUGEPAGES_1GI 환경 변수 값을 확인합니다.

   $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
        -- env | grep REQUESTS_HUGEPAGES_1GI

   출력 예

   REQUESTS_HUGEPAGES_1GI=2147483648

2. /etc/podinfo/hugepages_1G_request 파일의 값을 확인합니다.

   $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
        -- cat /etc/podinfo/hugepages_1G_request

   출력 예

   2

프로세스

1. 다음 콘텐츠를 사용하여 파일을 생성하고 이름을 thp-disable-tuned.yaml 로 지정합니다.

   apiVersion: tuned.openshift.io/v1
   kind: Tuned
   metadata:
     name: thp-workers-profile
     namespace: openshift-cluster-node-tuning-operator
   spec:
     profile:
     - data: |
         [main]
         summary=Custom tuned profile for OpenShift to turn off THP on worker nodes
         include=openshift-node
   
         [vm]
         transparent_hugepages=never
       name: openshift-thp-never-worker
   
     recommend:
     - match:
       - label: node-role.kubernetes.io/worker
       priority: 25
       profile: openshift-thp-never-worker

2. Tuned 오브젝트를 생성합니다.

   $ oc create -f thp-disable-tuned.yaml

3. 활성 프로필 목록을 확인합니다.

   $ oc get profile -n openshift-cluster-node-tuning-operator

1. Node Tuning Operator를 사용하여 성능 프로필을 구성했습니다.
2. 클러스터에 필요한 모든 CNF 구성을 적용했습니다.
3. 클러스터에 기존 MachineConfigPool CR이 적용되어 있습니다. 기본 작업자 풀은 worker-cnf 입니다.

절차

1. kubeconfig 파일이 포함된 디렉터리에서 쉘 프롬프트를 엽니다.

   테스트 이미지에 현재 디렉터리에 kubeconfig 파일 및 볼륨을 통해 마운트된 관련 $KUBECONFIG 환경 변수를 제공합니다. 이를 통해 실행 중인 컨테이너에서 컨테이너 내부에서 kubeconfig 파일을 사용할 수 있습니다.

2. 다음 명령을 입력하여 대기 시간 테스트를 실행합니다.

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance registry.redhat.io/openshift4/cnf-tests-rhel8:v4.11 \
   /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

3. 선택 사항: Append -ginkgo.dryRun 을 사용하여 시험 실행 모드에서 대기 시간 테스트를 실행합니다. 이 명령은 테스트 실행을 확인하는 데 유용합니다.
4. 선택 사항: Append -ginkgo.v 를 사용하여 향상된 동사를 사용하여 테스트를 실행합니다.

5. 선택 사항: 특정 성능 프로필에 대해 대기 시간 테스트를 실행하려면 다음 명령을 실행하여 적절한 값을 대체합니다.

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e LATENCY_TEST_RUN=true -e FEATURES=performance -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
   -e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.11 \
   /usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"

   다음과 같습니다.

   <performance_profile>

   는 대기 시간 테스트를 실행할 성능 프로필의 이름입니다.

   중요

   유효한 대기 시간 테스트 결과의 경우 최소 12 시간 동안 테스트를 실행합니다.

1. cnf-tests 이미지를 사용자 연결 해제된 레지스트리에 미러링합니다.
2. 사용자 연결 해제된 레지스트리의 이미지를 사용하도록 테스트에 지시합니다.

1. 클러스터에 액세스할 수 있는 임시 머신에서 다음 명령을 실행합니다. registry.redhat.io:

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   registry.redhat.io/openshift4/cnf-tests-rhel8:v4.11 \
   /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

   다음과 같습니다.

   <disconnected_registry>

   구성한 연결이 끊긴 미러 레지스트리(예: my.local.registry:5000/ )입니다.

2. cnf-tests 이미지를 연결이 끊긴 레지스트리에 미러링한 경우 테스트를 실행할 때 이미지를 가져오는 데 사용되는 원래 레지스트리를 재정의해야 합니다. 예를 들면 다음과 같습니다.

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY="<disconnected_registry>" \
   -e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.11" \
   /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

절차

1. 경로를 통해 레지스트리를 공개하여 레지스트리에 대한 외부 액세스 권한을 얻습니다.

   $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge

2. 다음 명령을 실행하여 레지스트리 끝점을 가져옵니다.

   $ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')

3. 이미지를 공개하는 데 사용할 네임스페이스를 생성합니다.

   $ oc create ns cnftests

4. 테스트에 사용되는 모든 네임스페이스에서 이미지 스트림을 사용할 수 있도록 설정합니다. 테스트 네임스페이스가 cnf-tests 이미지 스트림에서 이미지를 가져올 수 있도록 하는 데 필요합니다. 다음 명령을 실행합니다.

   $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests

   $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests

5. 다음 명령을 실행하여 Docker 보안 이름 및 인증 토큰을 검색합니다.

   $ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}

   $ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')

6. dockerauth.json 파일을 생성합니다. 예를 들면 다음과 같습니다.

   $ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json

7. 이미지 미러링을 수행합니다.

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   registry.redhat.io/openshift4/cnf-tests-rhel8:4.11 \
   /usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
   -a=$(pwd)/dockerauth.json -f -

8. 테스트를 실행합니다.

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests \
   cnf-tests-local:latest /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

절차

1. mirror 명령은 기본적으로 업스트림 이미지를 미러링합니다. 다음 형식의 파일을 이미지에 전달하여 재정의할 수 있습니다.

   [
       {
           "registry": "public.registry.io:5000",
           "image": "imageforcnftests:4.11"
       }
   ]

2. 파일을 mirror 명령에 전달합니다. 예를 들어 images.json 으로 로컬로 저장합니다. 다음 명령을 사용하면 로컬 경로가 컨테이너 내 /kubeconfig에 마운트되어 mirror 명령에 전달될 수 있습니다.

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   registry.redhat.io/openshift4/cnf-tests-rhel8:v4.11 /usr/bin/mirror \
   --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
   |  oc image mirror -f -