17.4. 실시간 및 짧은 대기 시간 워크로드 프로비저닝

1. 클러스터에 Performance Addon Operator를 설치합니다.
2. 선택 사항: OpenShift Container Platform 클러스터에 노드를 추가합니다. BIOS 매개변수 설정을 참조하십시오.
3. oc 명령을 사용하여 실시간 기능이 필요한 작업자 노드에 worker-rt 레이블을 추가합니다.

4. 실시간 노드에 대한 새 머신 구성 풀을 생성합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     name: worker-rt
     labels:
       machineconfiguration.openshift.io/role: worker-rt
   spec:
     machineConfigSelector:
       matchExpressions:
         - {
              key: machineconfiguration.openshift.io/role,
              operator: In,
              values: [worker, worker-rt],
           }
     paused: false
     nodeSelector:
       matchLabels:
         node-role.kubernetes.io/worker-rt: ""

   worker-rt 레이블이 있는 노드 그룹에 대해 머신 구성 풀 worker-rt 가 생성됩니다.

5. 노드 역할 레이블을 사용하여 적절한 머신 구성 풀에 노드를 추가합니다.

   참고

   실시간 워크로드로 구성된 노드를 결정해야 합니다. 클러스터의 모든 노드 또는 노드의 하위 집합을 구성할 수 있습니다. 모든 노드를 예상하는 Performance Addon Operator는 전용 머신 구성 풀의 일부입니다. 모든 노드를 사용하는 경우 작업자 노드 역할 레이블을 Performance Addon Operator를 가리켜야 합니다. 서브 세트를 사용하는 경우 해당 노드를 새 머신 구성 풀로 그룹화해야 합니다.

6. 적절한 하우스키핑 코어 세트와 realTimeKernel: enabled: true를 사용하여 PerformanceProfile을 생성합니다.

7. PerformanceProfile 에서 machineConfigPoolSelector 를 설정해야 합니다.

     apiVersion: performance.openshift.io/v2
     kind: PerformanceProfile
     metadata:
      name: example-performanceprofile
     spec:
     ...
       realTimeKernel:
         enabled: true
       nodeSelector:
          node-role.kubernetes.io/worker-rt: ""
       machineConfigPoolSelector:
          machineconfiguration.openshift.io/role: worker-rt

8. 레이블과 일치하는 머신 구성 풀이 있는지 검증합니다.

   $ oc describe mcp/worker-rt

   출력 예

   Name:         worker-rt
   Namespace:
   Labels:       machineconfiguration.openshift.io/role=worker-rt

9. OpenShift Container Platform에서 노드 구성을 시작합니다. 이 작업에서는 여러 번 재부팅이 수행될 수 있습니다. 노드가 설정될 때까지 기다리십시오. 사용하는 하드웨어에 따라 시간이 오래 걸릴 수 있으며 노드당 20분으로 예상됩니다.
10. 모든 요소가 예상대로 작동하는지 검증하십시오.

프로세스

1. QoS 클래스가 Guaranteed인 Pod를 생성합니다.
2. 선택 사항: DPDK의 CPU 로드 밸런싱을 비활성화합니다.
3. 적절한 노드 선택기를 할당합니다.

1. Pod를 생성합니다.

   $ oc  apply -f qos-pod.yaml --namespace=qos-example

2. Pod에 대한 자세한 정보를 봅니다.

   $ oc get pod qos-demo --namespace=qos-example --output=yaml

   출력 예

   spec:
     containers:
       ...
   status:
     qosClass: Guaranteed

   참고

   컨테이너가 자체 메모리 제한은 지정하지만 메모리 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 메모리 요청을 자동으로 할당합니다. 마찬가지로, 컨테이너가 자체 CPU 제한은 지정하지만 CPU 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 CPU 요청을 자동으로 할당합니다.

1. cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
2. performance.openshift.io/v2를 사용하도록 성능 프로파일의 apiVersion을 설정합니다.
3. globallyDisableIrqLoadBalancing 필드를 삭제제거하거나 false로 설정합니다.

4. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 CPU를 예약하는 프로파일을 보여줍니다. isolated CPU 세트에서 실행되는 Pod에 대해 IRQ 로드 밸런싱이 활성화됩니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: dynamic-irq-profile
   spec:
     cpu:
       isolated: 2-5
       reserved: 0-1
   ...

   참고

   예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

5. 전용 CPU를 사용하는 pod를 생성하고 irq-load-balancing.crio.io 및 cpu-quota.crio.io 주석을 disable로 설정합니다. 예를 들면 다음과 같습니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: dynamic-irq-pod
     annotations:
        irq-load-balancing.crio.io: "disable"
        cpu-quota.crio.io: "disable"
   spec:
     containers:
     - name: dynamic-irq-pod
       image: "quay.io/openshift-kni/cnf-tests:4.8"
       command: ["sleep", "10h"]
       resources:
         requests:
           cpu: 2
           memory: "200M"
         limits:
           cpu: 2
           memory: "200M"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""
     runtimeClassName: performance-dynamic-irq-profile
   ...

6. performance-<profile_name> 형식으로 pod runtimeClassName을 입력합니다. 여기서<profile_name>은 PerformanceProfile YAML의 name입니다 (예: performance- dynamic-irq-profile).
7. 노드 선택기를 cnf-worker 을 대상으로 설정합니다.

8. Pod가 올바르게 실행되고 있는지 확인합니다. 상태가 running이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.

   $ oc get pod -o wide

   예상 출력

   NAME              READY   STATUS    RESTARTS   AGE     IP             NODE          NOMINATED NODE   READINESS GATES
   dynamic-irq-pod   1/1     Running   0          5h33m   <ip-address>   <node-name>   <none>           <none>

9. IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.

   $ oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

   예상 출력

   Cpus_allowed_list:  2-3

10. 노드 구성이 올바르게 적용되었는지 확인합니다. 구성을 확인하려면 노드에 SSH를 실행합니다.

    $ oc debug node/<node-name>

    예상 출력

    Starting pod/<node-name>-debug ...
    To use host binaries, run `chroot /host`
    
    Pod IP: <ip-address>
    If you don't see a command prompt, try pressing enter.
    
    sh-4.4#

11. 노드 파일 시스템을 사용할 수 있는지 확인합니다.

    sh-4.4# chroot /host

    예상 출력

    sh-4.4#

12. 기본 시스템 CPU 선호도 마스크에 dynamic-irq-pod CPU (예: CPU 2 및 3)가 포함되지 않도록 합니다.

    $ cat /proc/irq/default_smp_affinity

    출력 예

    33

13. IRQ가 dynamic-irq-pod CPU에서 실행되도록 구성되어 있지 않은지 확인합니다.

    find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    출력 예

    /proc/irq/0/smp_affinity_list: 0-5
    /proc/irq/1/smp_affinity_list: 5
    /proc/irq/2/smp_affinity_list: 0-5
    /proc/irq/3/smp_affinity_list: 0-5
    /proc/irq/4/smp_affinity_list: 0
    /proc/irq/5/smp_affinity_list: 0-5
    /proc/irq/6/smp_affinity_list: 0-5
    /proc/irq/7/smp_affinity_list: 0-5
    /proc/irq/8/smp_affinity_list: 4
    /proc/irq/9/smp_affinity_list: 4
    /proc/irq/10/smp_affinity_list: 0-5
    /proc/irq/11/smp_affinity_list: 0
    /proc/irq/12/smp_affinity_list: 1
    /proc/irq/13/smp_affinity_list: 0-5
    /proc/irq/14/smp_affinity_list: 1
    /proc/irq/15/smp_affinity_list: 0
    /proc/irq/24/smp_affinity_list: 1
    /proc/irq/25/smp_affinity_list: 1
    /proc/irq/26/smp_affinity_list: 1
    /proc/irq/27/smp_affinity_list: 5
    /proc/irq/28/smp_affinity_list: 1
    /proc/irq/29/smp_affinity_list: 0
    /proc/irq/30/smp_affinity_list: 0-5

절차

1. 구성할 호스트의 모든 CPU에서 실행중인 스레드를 확인합니다.

   클러스터에 로그인하고 다음 명령을 실행하여 호스트 CPU에서 실행중인 스레드를 볼 수 있습니다.

   $ lscpu --all --extended

   출력 예

   CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
   0   0    0      0    0:0:0:0       yes    4800.0000 400.0000
   1   0    0      1    1:1:1:0       yes    4800.0000 400.0000
   2   0    0      2    2:2:2:0       yes    4800.0000 400.0000
   3   0    0      3    3:3:3:0       yes    4800.0000 400.0000
   4   0    0      0    0:0:0:0       yes    4800.0000 400.0000
   5   0    0      1    1:1:1:0       yes    4800.0000 400.0000
   6   0    0      2    2:2:2:0       yes    4800.0000 400.0000
   7   0    0      3    3:3:3:0       yes    4800.0000 400.0000

   이 예에서는 4개의 물리적 CPU 코어에서 실행 중인 논리 CPU 코어가 8개 있습니다. CPU0 및 CPU4는 물리적 Core0에서 실행되고 CPU1 및 CPU5는 물리적 Core 1에서 실행되고 있습니다.

   또는 특정 물리적 CPU 코어(다음 예에서는cpu0)에 설정된 스레드를 보려면 명령 프롬프트를 열고 다음을 실행합니다.

   $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

   출력 예

   0-4

2. PerformanceProfile YAML에서 분리 및 예약된 CPU를 적용합니다. 예를 들어 논리 코어 CPU0 및 CPU4를 분리하여 논리 코어 CPU1을 CPU3 으로, CPU5를 예약 된 대로 CPU7로 설정할 수 있습니다. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

   ...
     cpu:
       isolated: 0,4
       reserved: 1-3,5-7
   ...

   참고

   예약된 CPU 풀과 분리된 CPU 풀은 중복되지 않아야 하며 함께 작업자 노드의 사용 가능한 모든 코어에 걸쳐 있어야 합니다.