프로세스

1. 유효한 tuned 매니페스트를 포함하는 구성 맵을 생성하고 노드 풀에서 매니페스트를 참조합니다. 다음 예제에서 Tuned 매니페스트는 값이 있는 tuned-1-node-label 노드 라벨이 포함된 노드에서 vm.dirty_ratio 를 55로 설정하는 프로필을 정의합니다. tuned-1.yaml 이라는 파일에 다음 ConfigMap 매니페스트를 저장합니다.

       apiVersion: v1
       kind: ConfigMap
       metadata:
         name: tuned-1
         namespace: clusters
       data:
         tuning: |
           apiVersion: tuned.openshift.io/v1
           kind: Tuned
           metadata:
             name: tuned-1
             namespace: openshift-cluster-node-tuning-operator
           spec:
             profile:
             - data: |
                 [main]
                 summary=Custom OpenShift profile
                 include=openshift-node
                 [sysctl]
                 vm.dirty_ratio="55"
               name: tuned-1-profile
             recommend:
             - priority: 20
               profile: tuned-1-profile

   참고

   Tuned 사양의 spec.recommend 섹션에 있는 항목에 레이블을 추가하지 않으면 노드 풀 기반 일치로 가정하므로 spec.recommend 섹션의 우선 순위 프로필이 풀의 노드에 적용됩니다. Tuned .spec.recommend.match 섹션에서 레이블 값을 설정하여 더 세분화된 node-label-based 일치를 수행할 수 있지만 노드 풀의 .spec.management.upgradeType 값을 InPlace 로 설정하지 않으면 업그레이드 중에 노드 라벨이 유지되지 않습니다.

2. 관리 클러스터에 ConfigMap 오브젝트를 생성합니다.

   $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml

3. 노드 풀을 편집하거나 생성하여 노드 풀의 spec.tuningConfig 필드에서 ConfigMap 오브젝트를 참조합니다. 이 예에서는 2개의 노드가 포함된 nodepool-1 이라는 NodePool 만 있다고 가정합니다.

       apiVersion: hypershift.openshift.io/v1alpha1
       kind: NodePool
       metadata:
         ...
         name: nodepool-1
         namespace: clusters
       ...
       spec:
         ...
         tuningConfig:
         - name: tuned-1
       status:
       ...

   참고

   여러 노드 풀에서 동일한 구성 맵을 참조할 수 있습니다. 호스트 컨트롤 플레인에서 Node Tuning Operator는 노드 풀 이름과 네임스페이스의 해시를 구분하기 위해 Tuned CR의 이름에 추가합니다. 이 경우 동일한 호스팅 클러스터의 Tuned CR에서 동일한 이름의 TuneD 프로필을 여러 개 생성하지 마십시오.

1. 호스팅 클러스터의 Tuned 오브젝트를 나열합니다.

   $ oc --kubeconfig="$HC_KUBECONFIG" get Tuneds -n openshift-cluster-node-tuning-operator

   출력 예

   NAME       AGE
   default    7m36s
   rendered   7m36s
   tuned-1    65s

2. 호스팅된 클러스터의 Profile 오브젝트를 나열합니다.

   $ oc --kubeconfig="$HC_KUBECONFIG" get Profiles -n openshift-cluster-node-tuning-operator

   출력 예

   NAME                           TUNED            APPLIED   DEGRADED   AGE
   nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
   nodepool-1-worker-2            tuned-1-profile  True      False      7m14s

   참고

   사용자 정의 프로필이 생성되지 않으면 openshift-node 프로필이 기본적으로 적용됩니다.

3. 튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고 sysctl 값을 확인합니다.

   $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio

   출력 예

   vm.dirty_ratio = 55

프로세스

1. 크기가 2MB인 10개의 대규모 페이지를 생성하기 위한 Tuned 오브젝트 매니페스트가 포함된 ConfigMap 오브젝트를 생성합니다. tuned-hugepages.yaml 이라는 파일에 이 ConfigMap 매니페스트를 저장합니다.

       apiVersion: v1
       kind: ConfigMap
       metadata:
         name: tuned-hugepages
         namespace: clusters
       data:
         tuning: |
           apiVersion: tuned.openshift.io/v1
           kind: Tuned
           metadata:
             name: hugepages
             namespace: openshift-cluster-node-tuning-operator
           spec:
             profile:
             - data: |
                 [main]
                 summary=Boot time configuration for hugepages
                 include=openshift-node
                 [bootloader]
                 cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
               name: openshift-node-hugepages
             recommend:
             - priority: 20
               profile: openshift-node-hugepages

   참고

   .spec.recommend.match 필드는 의도적으로 비어 있습니다. 이 경우 이 Tuned 오브젝트는 이 ConfigMap 오브젝트가 참조되는 노드 풀의 모든 노드에 적용됩니다. 동일한 하드웨어 구성을 가진 노드를 동일한 노드 풀로 그룹화합니다. 그렇지 않으면 TuneD 피연산자가 동일한 노드 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.

2. 관리 클러스터에 ConfigMap 오브젝트를 생성합니다.

   $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-hugepages.yaml

3. NodePool 매니페스트 YAML 파일을 생성하고 NodePool 의 업그레이드 유형을 사용자 지정하고 spec.tuningConfig 섹션에서 생성한 ConfigMap 오브젝트를 참조합니다. NodePool 매니페스트를 생성하고 hypershift CLI를 사용하여 hugepages-nodepool.yaml 이라는 파일에 저장합니다.

       NODEPOOL_NAME=hugepages-example
       INSTANCE_TYPE=m5.2xlarge
       NODEPOOL_REPLICAS=2
   
       hypershift create nodepool aws \
         --cluster-name $CLUSTER_NAME \
         --name $NODEPOOL_NAME \
         --node-count $NODEPOOL_REPLICAS \
         --instance-type $INSTANCE_TYPE \
         --render > hugepages-nodepool.yaml

4. hugepages-nodepool.yaml 파일에서 .spec.management.upgradeType 을 InPlace.Place .spec.tuningConfig 로 설정하고 생성한 tuned-hugepages ConfigMap 오브젝트를 참조하도록 .spec.tuningConfig를 설정합니다.

       apiVersion: hypershift.openshift.io/v1alpha1
       kind: NodePool
       metadata:
         name: hugepages-nodepool
         namespace: clusters
         ...
       spec:
         management:
           ...
           upgradeType: InPlace
         ...
         tuningConfig:
         - name: tuned-hugepages

   참고

   새 MachineConfig 개체를 적용할 때 노드의 불필요한 재생성을 방지하려면 .spec.management.upgradeType 을 InPlace 로 설정합니다. Replace 업그레이드 유형을 사용하는 경우 TuneD 피연산자가 계산된 새 커널 부팅 매개변수를 적용하면 노드가 완전히 삭제되고 새 노드가 교체될 수 있습니다.

5. 관리 클러스터에 NodePool 을 생성합니다.

   $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f hugepages-nodepool.yaml

1. 호스팅 클러스터의 Tuned 오브젝트를 나열합니다.

   $ oc --kubeconfig="$HC_KUBECONFIG" get Tuneds -n openshift-cluster-node-tuning-operator

   출력 예

   NAME                 AGE
   default              123m
   hugepages-8dfb1fed   1m23s
   rendered             123m

2. 호스팅된 클러스터의 Profile 오브젝트를 나열합니다.

   $ oc --kubeconfig="$HC_KUBECONFIG" get Profiles -n openshift-cluster-node-tuning-operator

   출력 예

   NAME                           TUNED                      APPLIED   DEGRADED   AGE
   nodepool-1-worker-1            openshift-node             True      False      132m
   nodepool-1-worker-2            openshift-node             True      False      131m
   hugepages-nodepool-worker-1    openshift-node-hugepages   True      False      4m8s
   hugepages-nodepool-worker-2    openshift-node-hugepages   True      False      3m57s

   새 NodePool 의 두 작업자 노드에는 openshift-node-hugepages 프로필이 적용됩니다.

3. 튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고 /proc/cmdline 을 확인합니다.

   $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline

   출력 예

   BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50

프로세스

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. cpumanager-enabled CR(사용자 정의 리소스)에서 토폴로지 관리자 할당 정책을 구성합니다.

   $ 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.12"

   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: gcr.io/google_containers/pause-amd64:3.0
              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_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 같은 2의 거듭제곱을 사용할 수도 있습니다.

   5

   일반적인 값은 ALERTMANAGER_STORAGE_SIZE=20Gi입니다. 스토리지 값은 일반 정수일 수도 있고 E, P, T, G, M, K 접미사 중 하나를 사용하는 고정 소수점 정수일 수도 있습니다. Ei, Pi, Ti, Gi, Mi, Ki 같은 2의 거듭제곱을 사용할 수도 있습니다.

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가 할당된 스토리지 백엔드에 따라 달라집니다. 이 테스트에서는 OCS v4(OpenShift Data Foundation 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. 다음 YAML을 사용하여 mount_namespace_config.yaml 이라는 파일을 생성합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 99-kubens-master
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - enabled: true
           name: kubens.service
   ---
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 99-kubens-worker
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - enabled: true
           name: kubens.service

2. 다음 명령을 실행하여 마운트 네임스페이스 MachineConfig CR을 적용합니다.

   $ oc apply -f mount_namespace_config.yaml

   출력 예

   machineconfig.machineconfiguration.openshift.io/99-kubens-master created
   machineconfig.machineconfiguration.openshift.io/99-kubens-worker created

3. MachineConfig CR을 클러스터에 적용하는 데 최대 30분이 걸릴 수 있습니다. 다음 명령을 실행하여 MachineConfig CR의 상태를 확인할 수 있습니다.

   $ oc get mcp

   출력 예

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-03d4bc4befb0f4ed3566a2c8f7636751   False     True       False      3              0                   0                     0                      45m
   worker   rendered-worker-10577f6ab0117ed1825f8af2ac687ddf   False     True       False      3              1                   1

4. 다음 명령을 실행한 후 모든 컨트롤 플레인 및 작업자 노드에 MachineConfig CR이 성공적으로 적용될 때까지 기다립니다.

   $ oc wait --for=condition=Updated mcp --all --timeout=30m

   출력 예

   machineconfigpool.machineconfiguration.openshift.io/master condition met
   machineconfigpool.machineconfiguration.openshift.io/worker condition met

1. 클러스터 호스트에 대한 디버그 쉘을 엽니다.

   $ oc debug node/<node_name>

2. chroot 세션을 엽니다.

   sh-4.4# chroot /host

3. systemd 마운트 네임스페이스를 확인합니다.

   sh-4.4# readlink /proc/1/ns/mnt

   출력 예

   mnt:[4026531953]

4. kubelet 마운트 네임스페이스를 확인합니다.

   sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt

   출력 예

   mnt:[4026531840]

5. CRI-O 마운트 네임스페이스를 확인합니다.

   sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt

   출력 예

   mnt:[4026531840]

절차

1. 클러스터 호스트에 대한 원격 SSH 쉘을 엽니다. 예를 들면 다음과 같습니다.

   $ ssh core@<node_name>

2. 제공된 kubensenter 스크립트를 root 사용자로 사용하여 명령을 실행합니다. Kubernetes 네임스페이스 내에서 단일 명령을 실행하려면 명령과 kubensenter 스크립트에 인수를 제공합니다. 예를 들어 Kubernetes 네임스페이스 내에서 findmnt 명령을 실행하려면 다음 명령을 실행합니다.

   [core@control-plane-1 ~]$ sudo kubensenter findmnt

   출력 예

   kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
   TARGET                                SOURCE                 FSTYPE     OPTIONS
   /                                     /dev/sda4[/ostree/deploy/rhcos/deploy/32074f0e8e5ec453e56f5a8a7bc9347eaa4172349ceab9c22b709d9d71a3f4b0.0]
   |                                                            xfs        rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota
                                         shm                    tmpfs
   ...

3. Kubernetes 네임스페이스 내에서 새 대화형 쉘을 시작하려면 인수 없이 kubensenter 스크립트를 실행합니다.

   [core@control-plane-1 ~]$ sudo kubensenter

   출력 예

   kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt

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

절차

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.12 \
   /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.12 \
   /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.12 \
   /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.12" \
   /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.12 \
   /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.12"
       }
   ]

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

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

1. 중간 작업자 대기 시간 프로파일로 이동합니다.

   1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile 추가: MediumUpdateAverageReaction:

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
       ...

      1

      중간 작업자 대기 시간 정책을 지정합니다.

      변경 사항이 적용되므로 각 작업자 노드에서 예약이 비활성화됩니다.

      모든 노드가 Ready 상태로 돌아 오면 다음 명령을 사용하여 Kubernetes 컨트롤러 관리자를 확인하여 적용되었는지 확인할 수 있습니다.

      $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

      출력 예

       ...
          - lastTransitionTime: "2022-07-11T19:47:10Z"
            reason: ProfileUpdated
            status: "False"
            type: WorkerLatencyProfileProgressing
          - lastTransitionTime: "2022-07-11T19:47:10Z" 1
            message: all static pod revision(s) have updated latency profile
            reason: ProfileUpdated
            status: "True"
            type: WorkerLatencyProfileComplete
          - lastTransitionTime: "2022-07-11T19:20:11Z"
            reason: AsExpected
            status: "False"
            type: WorkerLatencyProfileDegraded
          - lastTransitionTime: "2022-07-11T19:20:36Z"
            status: "False"
       ...

      1

      프로필이 적용되고 활성 상태가 되도록 지정합니다.

2. 선택 사항: 작업자 대기 시간이 짧은 프로필로 이동합니다.

   1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile 값을 LowUpdateSlowReaction 으로 변경합니다.

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
       ...

      1

      낮은 작업자 대기 시간 정책을 사용하도록 지정합니다.

      변경 사항이 적용되므로 각 작업자 노드에서 예약이 비활성화됩니다.

절차

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub로 이동합니다.
2. 사용 가능한 Operator 목록에서 Topology Aware Lifecycle Manager 를 검색한 다음 설치를 클릭합니다.
3. 기본 설치 모드 ["All namespaces on the cluster (default)"] 및 Installed Namespace ("openshift-operators")를 선택하여 Operator가 올바르게 설치되었는지 확인합니다.
4. 설치를 클릭합니다.

1. Operator → 설치된 Operator 페이지로 이동합니다.
2. Operator가 All Namespaces 네임스페이스에 설치되어 있고 해당 상태는 Succeeded 인지 확인합니다.

1. Operator → 설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
2. Workloads → Pod 페이지로 이동하여 문제를 보고하는 cluster-group-upgrades-controller-manager Pod의 컨테이너에서 로그를 확인합니다.

절차

1. 서브스크립션 CR을 생성합니다.

   1. Subscription CR을 정의하고 YAML 파일을 저장합니다(예: talm-subscription.yaml ).

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-topology-aware-lifecycle-manager-subscription
        namespace: openshift-operators
      spec:
        channel: "stable"
        name: topology-aware-lifecycle-manager
        source: redhat-operators
        sourceNamespace: openshift-marketplace

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

      $ oc create -f talm-subscription.yaml

검증

1. CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.

   $ oc get csv -n openshift-operators

   출력 예

   NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
   topology-aware-lifecycle-manager.4.12.x   Topology Aware Lifecycle Manager   4.12.x                                      Succeeded

2. TALM이 실행 중인지 확인합니다.

   $ oc get deploy -n openshift-operators

   출력 예

   NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
   openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s