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. 새 디스크를 클러스터에 연결하고 디버그 쉘에서 lsblk 명령을 실행하여 노드에서 디스크가 감지되었는지 확인합니다.

   $ oc debug node/<node_name>

   # lsblk

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

2. 사용자 환경에 따라 스크립트의 장치 이름을 디코딩하고 교체합니다.

   #!/bin/bash
   set -uo pipefail
   
   for device in <device_type_glob>; do 1
   /usr/sbin/blkid $device &> /dev/null
    if [ $? == 2  ]; then
       echo "secondary device found $device"
       echo "creating filesystem for etcd mount"
       mkfs.xfs -L var-lib-etcd -f $device &> /dev/null
       udevadm settle
       touch /etc/var-lib-etcd-mount
       exit
    fi
   done
   echo "Couldn't find secondary block device!" >&2
   exit 77

   1

   & lt;device_type_glob >를 블록 장치 유형의 쉘 글로 바꿉니다. SCSI 또는 SATA 드라이브의 경우 /dev/sd* 를 사용합니다. 가상 드라이브의 경우 /dev/vd* 를 사용합니다. NVMe 드라이브의 경우 /dev/nvme*[0-9]* 를 사용합니다.

3. 다음과 같은 콘텐츠를 사용하여 etcd-mc.yml 이라는 MachineConfig YAML 파일을 만듭니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.1.0
       storage:
         files:
           - path: /etc/find-secondary-device
             mode: 0755
             contents:
               source: data:text/plain;charset=utf-8;base64,<encoded_etc_find_secondary_device_script> 1
       systemd:
         units:
           - name: find-secondary-device.service
             enabled: true
             contents: |
               [Unit]
               Description=Find secondary device
               DefaultDependencies=false
               After=systemd-udev-settle.service
               Before=local-fs-pre.target
               ConditionPathExists=!/etc/var-lib-etcd-mount
   
               [Service]
               RemainAfterExit=yes
               ExecStart=/etc/find-secondary-device
   
               RestartForceExitStatus=77
   
               [Install]
               WantedBy=multi-user.target
           - name: var-lib-etcd.mount
             enabled: true
             contents: |
               [Unit]
               Before=local-fs.target
   
               [Mount]
               What=/dev/disk/by-label/var-lib-etcd
               Where=/var/lib/etcd
               Type=xfs
               TimeoutSec=120s
   
               [Install]
               RequiredBy=local-fs.target
           - name: sync-var-lib-etcd-to-etcd.service
             enabled: true
             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=/usr/sbin/setsebool -P rsync_full_access 1
               ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
               ExecStart=/usr/sbin/semanage fcontext -a -t container_var_lib_t '/var/lib/etcd(/.*)?'
               ExecStart=/usr/sbin/setsebool -P rsync_full_access 0
               TimeoutSec=0
   
               [Install]
               WantedBy=multi-user.target graphical.target
           - name: restorecon-var-lib-etcd.service
             enabled: true
             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

   1

   이전에 생성한 인코딩된 문자열을 사용하여 이 문자열을 사용자가 지정한 인코딩된 스크립트로 바꿉니다.

1. etcd가 대기 시간에 민감하기 때문에 초당 3000 IOPS 및 125MiB의 기본 성능이 있는 gp3 디스크는 컨트롤 플레인/etcd 노드에 사용됩니다. gp3 볼륨은 버스트 성능을 사용하지 않습니다.
2. 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
3. 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
4. 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
5. 클러스터는 반복적으로 확장되며 성능 및 확장성 테스트는 지정된 노드 수에 따라 실행됩니다.

1. etcd는 I/O 집약적이고 대기 시간에 민감하므로 GiB당 120/10 IOPS가 있는 io1 디스크는 컨트롤 플레인/etcd 노드에 사용됩니다.
2. 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
3. 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
4. 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
5. 클러스터는 반복으로 확장됩니다.

1. etcd는 I/O 집약적이고 대기 시간에 민감하므로 컨트롤 플레인/etcd 노드의 디스크 I/O 로드를 최적화하기 위해 두 개의 LCU(Logical Control Unit) 간에 노드가 배포됩니다. etcd I/O 요구 사항은 다른 워크로드를 방해하지 않아야 합니다.
2. 4개의 컴퓨팅 노드는 동시에 100/250/500개의 Pod가 있는 여러 반복 실행 테스트에 사용됩니다. 먼저 Pod를 유휴 상태로 설정하여 Pod 인스턴스를 평가할 수 있습니다. 다음으로, 과부하에 따른 시스템의 안정성을 평가하는 데 네트워크 및 CPU가 클라이언트/서버 워크로드를 사용했습니다. 클라이언트 및 서버 pod는 쌍으로 배포되었으며 각 쌍이 두 개의 컴퓨팅 노드에 분배되었습니다.
3. 별도의 워크로드 노드가 사용되지 않았습니다. 워크로드는 두 컴퓨팅 노드 간에 마이크로 서비스 워크로드를 시뮬레이션합니다.
4. 사용되는 물리적 프로세서 수는 Linux(IFL)에 대한 통합 6개입니다.
5. 사용된 총 실제 메모리는 512GiB입니다.

프로세스

1. 다음 MCO 샘플 프로필을 YAML 파일에 복사합니다. 예를 들어 enable-rfs.yaml 은 다음과 같습니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 50-enable-rfs
   spec:
     config:
       ignition:
         version: 2.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=US-ASCII,%23%20turn%20on%20Receive%20Flow%20Steering%20%28RFS%29%20for%20all%20network%20interfaces%0ASUBSYSTEM%3D%3D%22net%22%2C%20ACTION%3D%3D%22add%22%2C%20RUN%7Bprogram%7D%2B%3D%22/bin/bash%20-c%20%27for%20x%20in%20/sys/%24DEVPATH/queues/rx-%2A%3B%20do%20echo%208192%20%3E%20%24x/rps_flow_cnt%3B%20%20done%27%22%0A
           filesystem: root
           mode: 0644
           path: /etc/udev/rules.d/70-persistent-net.rules
         - contents:
             source: data:text/plain;charset=US-ASCII,%23%20define%20sock%20flow%20enbtried%20for%20%20Receive%20Flow%20Steering%20%28RFS%29%0Anet.core.rps_sock_flow_entries%3D8192%0A
           filesystem: root
           mode: 0644
           path: /etc/sysctl.d/95-enable-rps.conf

2. MCO 프로필을 생성합니다.

   $ oc create -f enable-rfs.yaml

3. 50-enable-rfs 항목이 나열되어 있는지 확인합니다.

   $ oc get mc

4. 비활성화하려면 다음을 입력합니다.

   $ oc delete mc 50-enable-rfs

프로세스

1. 다음 MCO 샘플 프로필을 컨트롤 플레인 노드의 YAML 파일에 복사합니다. 예를 들어 05-master-kernelarg-hpav.yaml:

   $ cat 05-master-kernelarg-hpav.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 05-master-kernelarg-hpav
   spec:
     config:
       ignition:
         version: 3.1.0
     kernelArguments:
       - rd.dasd=800-805

2. 다음 MCO 샘플 프로필을 컴퓨팅 노드의 YAML 파일에 복사합니다. 예를 들어 05-worker-kernelarg-hpav.yaml:

   $ cat 05-worker-kernelarg-hpav.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 05-worker-kernelarg-hpav
   spec:
     config:
       ignition:
         version: 3.1.0
     kernelArguments:
       - rd.dasd=800-805

   참고

   장치 ID에 맞게 rd.dasd 인수를 수정해야 합니다.

3. MCO 프로필을 생성합니다.

   $ oc create -f 05-master-kernelarg-hpav.yaml

   $ oc create -f 05-worker-kernelarg-hpav.yaml

4. 비활성화하려면 다음을 입력합니다.

   $ oc delete -f 05-master-kernelarg-hpav.yaml

   $ oc delete -f 05-worker-kernelarg-hpav.yaml

프로세스

1. 선택한 편집기에서 /etc/libvirt/qemu.conf 를 엽니다.
2. cgroup_controllers 행으로 이동합니다.
3. 전체 행을 복제하고 복사에서 선행 숫자 기호(#)를 제거합니다.

4. 다음과 같이 cpuset 항목을 제거합니다.

   cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuacct" ]

5. 새 설정을 적용하려면 libvirtd 데몬을 다시 시작해야 합니다.

   1. 모든 가상 머신을 중지합니다.

   2. 다음 명령을 실행합니다.

      # systemctl restart libvirtd

   3. 가상 머신을 재시작합니다.

프로세스

1. NUMA Resources Operator의 네임스페이스를 생성합니다.

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-numaresources

   2. 다음 명령을 실행하여 네임스페이스 CR을 생성합니다.

      $ oc create -f nro-namespace.yaml

2. NUMA Resources Operator에 대한 Operator 그룹을 생성합니다.

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

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: numaresources-operator
        namespace: openshift-numaresources
      spec:
        targetNamespaces:
        - openshift-numaresources

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

      $ oc create -f nro-operatorgroup.yaml

3. NUMA Resources Operator에 대한 서브스크립션을 생성합니다.

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: numaresources-operator
        namespace: openshift-numaresources
      spec:
        channel: "4.15"
        name: numaresources-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다.

      $ oc create -f nro-sub.yaml

검증

1. openshift-numaresources 네임스페이스에서 CSV 리소스를 검사하여 설치에 성공했는지 확인합니다. 다음 명령을 실행합니다.

   $ oc get csv -n openshift-numaresources

   출력 예

   NAME                             DISPLAY                  VERSION   REPLACES   PHASE
   numaresources-operator.v4.15.2   numaresources-operator   4.15.2               Succeeded

프로세스

1. NUMA Resources Operator의 네임스페이스를 생성합니다.

   1. OpenShift Container Platform 웹 콘솔에서 관리 → 네임스페이스를 클릭합니다.
   2. 네임스페이스 생성을 클릭하고 이름 필드에 openshift-numaresources 를 입력한 다음 생성 을 클릭합니다.

2. NUMA Resources Operator를 설치합니다.

   1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
   2. 사용 가능한 Operator 목록에서 NUMA Resources Operator 를 선택한 다음 설치를 클릭합니다.
   3. 설치된 네임스페이스 필드에서 openshift-numaresources 네임스페이스를 선택한 다음 설치를 클릭합니다.

3. 선택 사항: NUMA Resources Operator가 성공적으로 설치되었는지 확인합니다.

   1. Operator → 설치된 Operator 페이지로 전환합니다.

   2. NUMA Resources Operator 가 openshift-numaresources 네임스페이스에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.

      • Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • 워크로드 → Pod 페이지로 이동하여 기본 프로젝트에서 Pod 로그를 확인합니다.

프로세스

1. NUMAResourcesOperator 사용자 지정 리소스를 만듭니다.

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

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

   2. 다음 명령을 실행하여 NUMAResourcesOperator CR을 만듭니다.

      $ oc create -f nrop.yaml

프로세스

1. PerformanceProfile CR(사용자 정의 리소스)을 생성합니다.

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

      apiVersion: performance.openshift.io/v2
      kind: PerformanceProfile
      metadata:
        name: perfprof-nrop
      spec:
        cpu: 1
          isolated: "4-51,56-103"
          reserved: "0,1,2,3,52,53,54,55"
        nodeSelector:
          node-role.kubernetes.io/worker: ""
        numa:
          topologyPolicy: single-numa-node

      1

      cpu.isolated 및 cpu.reserved 사양은 분리된 CPU 및 예약된 CPU의 범위를 정의합니다. CPU 구성에 유효한 값을 입력합니다. 성능 프로필 구성에 대한 자세한 내용은 추가 리소스 섹션을 참조하십시오.

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

      $ oc create -f nro-perfprof.yaml

      출력 예

      performanceprofile.performance.openshift.io/perfprof-nrop created

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

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

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.15"
        cacheResyncPeriod: "5s" 1

      1

      스케줄러 캐시의 동기화를 위해 간격 값을 초 단위로 입력합니다. 값 5s 는 대부분의 구현에 일반적인 값입니다.

      참고

      • cacheResyncPeriod 사양을 활성화하여 노드에서 보류 중인 리소스를 모니터링하고 이 정보를 정의된 간격으로 스케줄러 캐시에서 동기화하여 NUMA 리소스 가용성을 보다 정확하게 보고할 수 있습니다. 또한 최적의 스케줄링 결정으로 인해 토폴로지 선호도 오류 오류를 최소화하는 데 도움이 됩니다. 간격을 줄이는 경우 네트워크를 더 많이 로드할 수 있습니다. cacheResyncPeriod 사양은 기본적으로 비활성화되어 있습니다.
      • NUMAResourcesOperator CR의 podsFingerprinting 사양에 대해 Enabled 값을 설정하는 것은 cacheResyncPeriod 사양을 구현하기 위한 요구 사항입니다.

   2. 다음 명령을 실행하여 NUMAResourcesScheduler CR을 만듭니다.

      $ oc create -f nro-scheduler.yaml

검증

1. 다음 명령을 실행하여 성능 프로필이 적용되었는지 확인합니다.

   $ oc describe performanceprofile <performance-profile-name>

2. 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인합니다.

   $ oc get all -n openshift-numaresources

   출력 예

   NAME                                                    READY   STATUS    RESTARTS   AGE
   pod/numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          13m
   pod/numaresourcesoperator-worker-dvj4n                  2/2     Running   0          16m
   pod/numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16m
   pod/secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          16m
   NAME                                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
   daemonset.apps/numaresourcesoperator-worker   2         2         2       2            2           node-role.kubernetes.io/worker=   16m
   NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/numaresources-controller-manager   1/1     1            1           13m
   deployment.apps/secondary-scheduler                1/1     1            1           16m
   NAME                                                          DESIRED   CURRENT   READY   AGE
   replicaset.apps/numaresources-controller-manager-7575848485   1         1         1       13m
   replicaset.apps/secondary-scheduler-56994cf6cf                1         1         1       16m

프로세스

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. 예상되는 할당된 리소스가 노드에 대해 나열되어 있는지 확인합니다.

   1. 다음 명령을 실행하여 배포 Pod를 실행 중인 노드를 확인하고 <namespace>를 Deployment CR에 지정한 네임스페이스로 교체합니다.

      $ oc get pods -n <namespace> -o wide

      출력 예

      NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
      numa-deployment-1-65684f8fcc-bw4bw   0/2     Running   0          82m   10.128.2.50   worker-0   <none>  <none>

   2. 다음 명령을 실행하여 <node_name>을 배포 Pod를 실행 중인 해당 노드의 이름으로 바꿉니다.

      $ oc describe noderesourcetopologies.topology.node.k8s.io <node_name>

      출력 예

      ...
      
      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 QoS(qosClass)가 있는 Pod의 리소스 할당은 noderesourcetopologies.topology.node.k8s.io 의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 사용한 리소스가 노드 리소스 계산에 반영되지 않은 경우 Pod에 Guaranteed 가 있고 CPU 요청이 10진수 값이 아닌 정수 값이 있는지 확인합니다. 다음 명령을 실행하여 Pod에 보장된 qosClass 가 있는지 확인할 수 있습니다.

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

   출력 예

   Guaranteed

프로세스

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

   참고

   기본적으로 OpenShift Container Platform은 클러스터의 작업자 노드에 대한 MachineConfigPool 리소스를 생성합니다. 필요한 경우 사용자 지정 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. 다음 YAML을 nrop.yaml 파일에 저장합니다.

      apiVersion: nodetopology.openshift.io/v1
      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"
          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. nro-scheduler.yaml 파일에 다음 YAML을 저장합니다.

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.15"
        cacheResyncPeriod: "5s" 1

      1

      스케줄러 캐시의 동기화를 위해 간격 값을 초 단위로 입력합니다. 값 5s 는 대부분의 구현에 일반적인 값입니다.

      참고

      • cacheResyncPeriod 사양을 활성화하여 노드에서 보류 중인 리소스를 모니터링하고 이 정보를 정의된 간격으로 스케줄러 캐시에서 동기화하여 NUMA 리소스 가용성을 보다 정확하게 보고할 수 있습니다. 또한 최적의 스케줄링 결정으로 인해 토폴로지 선호도 오류 오류를 최소화하는 데 도움이 됩니다. 간격을 줄이는 경우 네트워크를 더 많이 로드할 수 있습니다. cacheResyncPeriod 사양은 기본적으로 비활성화되어 있습니다.
      • NUMAResourcesOperator CR의 podsFingerprinting 사양에 대해 Enabled 값을 설정하는 것은 cacheResyncPeriod 사양을 구현하기 위한 요구 사항입니다.

   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. 예상되는 할당된 리소스가 노드에 대해 나열되어 있는지 확인합니다.

   1. 다음 명령을 실행하여 배포 Pod를 실행 중인 노드를 확인하고 <namespace>를 Deployment CR에 지정한 네임스페이스로 교체합니다.

      $ oc get pods -n <namespace> -o wide

      출력 예

      NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
      numa-deployment-1-65684f8fcc-bw4bw   0/2     Running   0          82m   10.128.2.50   worker-0   <none>  <none>

   2. 다음 명령을 실행하여 <node_name>을 배포 Pod를 실행 중인 해당 노드의 이름으로 교체합니다.

      $ oc describe noderesourcetopologies.topology.node.k8s.io <node_name>

      출력 예

      ...
      
      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 QoS(qosClass)가 있는 Pod의 리소스 할당은 noderesourcetopologies.topology.node.k8s.io 의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 사용한 리소스가 노드 리소스 계산에 반영되지 않은 경우 Pod에 Guaranteed 가 있고 CPU 요청이 10진수 값이 아닌 정수 값이 있는지 확인합니다. 다음 명령을 실행하여 Pod에 보장된 qosClass 가 있는지 확인할 수 있습니다.

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

   출력 예

   Guaranteed

프로세스

1. 현재 실행 중인 NUMAResourcesScheduler 리소스를 삭제합니다.

   1. 다음 명령을 실행하여 활성 NUMAResourcesScheduler 를 가져옵니다.

      $ oc get NUMAResourcesScheduler

      출력 예

      NAME                     AGE
      numaresourcesscheduler   90m

   2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      출력 예

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

2. nro-scheduler-debug.yaml 파일에 다음 YAML을 저장합니다. 이 예에서는 로그 수준을 Debug 로 변경합니다.

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

3. 다음 명령을 실행하여 업데이트된 Debug logging NUMAResourcesScheduler 리소스를 만듭니다.

   $ oc create -f nro-scheduler-debug.yaml

   출력 예

   numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

검증 단계

1. NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

   1. 다음 명령을 실행하여 CRD가 정상적으로 생성되었는지 확인합니다.

      $ oc get crd | grep numaresourcesschedulers

      출력 예

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

   2. 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      출력 예

      NAME                     AGE
      numaresourcesscheduler   3h26m

2. 스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.

   1. 다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-numaresources

      출력 예

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m

   2. 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      출력 예

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

프로세스

1. NUMA Resources Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는 NUMAResourcesOperator CR에 해당 nodeGroup 이 있습니다. 다음 명령을 실행합니다.

   $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"

   출력 예

   {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}

2. 이전 단계의 name 에 대한 값을 사용하여 관심 있는 데몬 세트의 레이블을 가져옵니다.

   $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

   출력 예

   {"name":"resource-topology"}

3. 다음 명령을 실행하여 resource-topology 레이블을 사용하여 Pod를 가져옵니다.

   $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

   출력 예

   NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
   numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
   numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com

4. 문제 해결 중인 노드에 해당하는 작업자 Pod에서 실행 중인 resource-topology-exporter 컨테이너의 로그를 검사합니다. 다음 명령을 실행합니다.

   $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

   출력 예

   I0221 13:38:18.334140       1 main.go:206] using sysinfo:
   reservedCpus: 0,1
   reservedMemory:
     "0": 1178599424
   I0221 13:38:18.334370       1 main.go:67] === System information ===
   I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
   I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
   I0221 13:38:18.546750       1 main.go:72]
   cpus: allocatable "2-103"
   hugepages-1Gi:
     numa cell 0 -> 6
     numa cell 1 -> 1
   hugepages-2Mi:
     numa cell 0 -> 64
     numa cell 1 -> 128
   memory:
     numa cell 0 -> 45758Mi
     numa cell 1 -> 48372Mi

프로세스

1. 다음 명령을 사용하여 MachineConfigPool (mcp) 작업자 CR의 spec.machineConfigPoolSelector.matchLabels 값과 kubeletconfig 및 metadata.labels 의 값을 비교합니다.

   1. 다음 명령을 실행하여 kubeletconfig 레이블을 확인합니다.

      $ oc get kubeletconfig -o yaml

      출력 예

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled

   2. 다음 명령을 실행하여 mcp 레이블을 확인합니다.

      $ oc get mcp worker -o yaml

      출력 예

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""

      cnf-worker-tuning: enabled 레이블은 MachineConfigPool 오브젝트에 없습니다.

2. 누락된 라벨을 포함하도록 MachineConfigPool CR을 편집합니다. 예를 들면 다음과 같습니다.

   $ oc edit mcp worker -o yaml

   출력 예

   labels:
     machineconfiguration.openshift.io/mco-built-in: ""
     pools.operator.machineconfiguration.openshift.io/worker: ""
     cnf-worker-tuning: enabled

3. 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.

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. 웹 콘솔에서 Compute → Bare Metal Hosts로 이동합니다.
2. Add Host → New with Dialog를 선택합니다.
3. 새 베어 메탈 호스트의 고유 이름을 지정합니다.
4. Boot MAC address를 설정합니다.
5. Baseboard Management Console (BMC) Address를 설정합니다.
6. 호스트의 BMC(Baseboard Management Controller)에 대한 사용자 인증 정보를 입력합니다.
7. 생성 후 호스트 전원을 켜도록선택하고 Create를 선택합니다.
8. 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. Compute → MachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count을 선택하여 클러스터에서 머신 복제본 수를 늘립니다.

프로세스

1. 웹 콘솔에서 Compute → Bare Metal Hosts로 이동합니다.
2. Add Host → New from YAML을 선택합니다.

3. 아래 YAML을 복사하고 붙여넣고 호스트의 세부 정보로 관련 필드를 수정합니다.

   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   metadata:
     name: <bare_metal_host_name>
   spec:
     online: true
     bmc:
       address: <bmc_address>
       credentialsName: <secret_credentials_name>  1
       disableCertificateVerification: True 2
     bootMACAddress: <host_boot_mac_address>

   1

   credentialsName은 유효한 Secret CR을 참조해야 합니다. baremetal-operator는 credentialsName에서 참조되는 유효한 Secret 없이 베어 메탈 호스트를 관리할 수 없습니다. 시크릿 및 시크릿 생성 방법에 대한 자세한 내용은 시크릿 이해 를 참조하십시오.

   2

   disableCertificateVerification 을 true 로 설정하면 클러스터와 BMC(Baseboard Management Controller) 간의 TLS 호스트 유효성 검사가 비활성화됩니다.

4. Create를 선택하여 YAML을 저장하고 새 베어 메탈 호스트를 생성합니다.

5. 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. Compute → MachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count를 선택하여 클러스터의 머신 수를 늘립니다.

   참고

   oc scale 명령 및 적절한 베어 메탈 컴퓨팅 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.

프로세스

1. metal3.io/autoscale-to-hosts 주석을 추가하여 자동 스케일링을 구성할 컴퓨팅 머신 세트에 주석을 답니다. & lt;machineset >를 컴퓨팅 머신 세트의 이름으로 바꿉니다.

   $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'

   새로 확장된 머신이 시작될 때까지 기다립니다.

프로세스

1. baremetalhost.metal3.io/detached 주석을 추가하여 프로비저너 노드에서 제거할 컴퓨팅 머신 세트에 주석을 답니다.

   $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'

   새 머신이 시작될 때까지 기다립니다.

   참고

   BareMetalHost 오브젝트를 사용하여 클러스터에 머신을 생성하고 레이블 또는 선택기가 BareMetalHost에서 변경되면 Machine 오브젝트가 생성된 MachineSet에 대해 BareMetalHost 오브젝트가 계속 계산됩니다.

2. 프로비저닝 사용 사례에서 다음 명령을 사용하여 재부팅이 완료된 후 주석을 제거합니다.

   $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'

프로세스

1. 베어 메탈 이벤트 릴레이의 네임스페이스를 생성합니다.

   1. 다음 YAML을 베어 메탈-events-namespace.yaml 파일에 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-bare-metal-events
        labels:
          name: openshift-bare-metal-events
          openshift.io/cluster-monitoring: "true"

   2. Namespace CR을 생성합니다.

      $ oc create -f bare-metal-events-namespace.yaml

2. Bare Metal Event Relay Operator에 대한 Operator 그룹을 생성합니다.

   1. 다음 YAML을 bare-metal-events-operatorgroup.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: bare-metal-event-relay-group
        namespace: openshift-bare-metal-events
      spec:
        targetNamespaces:
        - openshift-bare-metal-events

   2. OperatorGroup CR을 생성합니다.

      $ oc create -f bare-metal-events-operatorgroup.yaml

3. 베어 메탈 이벤트 릴레이를 구독합니다.

   1. 다음 YAML을 bare-metal-events-sub.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bare-metal-event-relay-subscription
        namespace: openshift-bare-metal-events
      spec:
        channel: "stable"
        name: bare-metal-event-relay
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. Subscription CR을 생성합니다.

      $ oc create -f bare-metal-events-sub.yaml

프로세스

1. OpenShift Container Platform 웹 콘솔을 사용하여 Bare Metal Event Relay를 설치합니다.

   1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
   2. 사용 가능한 Operator 목록에서 Bare Metal Event Relay 를 선택한 다음 설치를 클릭합니다.
   3. Operator 설치 페이지에서 네임스페이스 를 선택하거나 생성한 후 openshift-bare-metal-events 를 선택한 다음 설치를 클릭합니다.

1. Operator → 설치된 Operator 페이지로 전환합니다.

2. InstallSucceeded 상태로 프로젝트에 Bare Metal Event Relay 가 나열되어 있는지 확인합니다.

   참고

   설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

프로세스

1. 다음 curl 명령을 실행하여 노드 하드웨어에 Redfish EventService 가 활성화되어 있는지 확인합니다.

   $ curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"

   다음과 같습니다.

   bmc_ip_address

   Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

   출력 예

   {
      "@odata.context": "/redfish/v1/$metadata#EventService.EventService",
      "@odata.id": "/redfish/v1/EventService",
      "@odata.type": "#EventService.v1_0_2.EventService",
      "Actions": {
         "#EventService.SubmitTestEvent": {
            "EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
            "target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
         }
      },
      "DeliveryRetryAttempts": 3,
      "DeliveryRetryIntervalSeconds": 30,
      "Description": "Event Service represents the properties for the service",
      "EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
      "EventTypesForSubscription@odata.count": 5,
      "Id": "EventService",
      "Name": "Event Service",
      "ServiceEnabled": true,
      "Status": {
         "Health": "OK",
         "HealthRollup": "OK",
         "State": "Enabled"
      },
      "Subscriptions": {
         "@odata.id": "/redfish/v1/EventService/Subscriptions"
      }
   }

2. 다음 명령을 실행하여 클러스터의 Bare Metal Event Relay 서비스 경로를 가져옵니다.

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

   출력 예

   NAME            HOST/PORT   PATH                                                                    SERVICES                 PORT   TERMINATION   WILDCARD
   hw-event-proxy              hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com   hw-event-proxy-service   9087   edge          None

3. BMCEventSubscription 리소스를 생성하여 Redfish 이벤트를 구독합니다.

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

      apiVersion: metal3.io/v1alpha1
      kind: BMCEventSubscription
      metadata:
        name: sub-01
        namespace: openshift-machine-api
      spec:
         hostName: <hostname> 1
         destination: <proxy_service_url> 2
         context: ''

      1

      Redfish 이벤트가 생성되는 작업자 노드의 이름 또는 UUID를 지정합니다.

      2

      베어 메탈 이벤트 프록시 서비스를 지정합니다(예: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook ).

   2. BMCEventSubscription CR을 생성합니다.

      $ oc create -f bmc_sub.yaml

4. 선택 사항: BMC 이벤트 서브스크립션을 삭제하려면 다음 명령을 실행합니다.

   $ oc delete -f bmc_sub.yaml

5. 선택 사항: BMCEventSubscription CR을 생성하지 않고 Redfish 이벤트 서브스크립션을 수동으로 생성하려면 BMC 사용자 이름과 암호를 지정하여 다음 curl 명령을 실행합니다.

   $ curl -i -k -X POST -H "Content-Type: application/json"  -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v

   다음과 같습니다.

   proxy_service_url

   베어 메탈 이벤트 프록시 서비스(예: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook )입니다.

   bmc_ip_address

   Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

   출력 예

   HTTP/1.1 201 Created
   Server: AMI MegaRAC Redfish Service
   Location: /redfish/v1/EventService/Subscriptions/1
   Allow: GET, POST
   Access-Control-Allow-Origin: *
   Access-Control-Expose-Headers: X-Auth-Token
   Access-Control-Allow-Headers: X-Auth-Token
   Access-Control-Allow-Credentials: true
   Cache-Control: no-cache, must-revalidate
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
   Link: </redfish/v1/EventService/Subscriptions>; path=
   ETag: "1651135676"
   Content-Type: application/json; charset=UTF-8
   OData-Version: 4.0
   Content-Length: 614
   Date: Thu, 28 Apr 2022 08:47:57 GMT

프로세스

1. 다음 curl 명령을 실행하여 BMC의 현재 서브스크립션을 확인합니다.

   $ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions

   다음과 같습니다.

   bmc_ip_address

   Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

   출력 예

   % Total % Received % Xferd Average Speed Time Time Time Current
   Dload Upload Total Spent Left Speed
   100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
   {
     "@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
     "@odata.etag": ""
     1651137375 "",
     "@odata.id": "/redfish/v1/EventService/Subscriptions",
     "@odata.type": "#EventDestinationCollection.EventDestinationCollection",
     "Description": "Collection for Event Subscriptions",
     "Members": [
     {
       "@odata.id": "/redfish/v1/EventService/Subscriptions/1"
     }],
     "Members@odata.count": 1,
     "Name": "Event Subscriptions Collection"
   }

   이 예에서 단일 서브스크립션이 /redfish/v1/EventService/Subscriptions/1 로 구성되어 있습니다.

2. 선택 사항: curl 을 사용하여 /redfish/v1/EventService/Subscriptions/1 서브스크립션을 제거하려면 BMC 사용자 이름과 암호를 지정하여 다음 명령을 실행합니다.

   $ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1

   다음과 같습니다.

   bmc_ip_address

   Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

프로세스

1. HardwareEvent CR(사용자 정의 리소스)을 생성합니다.

   참고

   여러 HardwareEvent 리소스가 허용되지 않습니다.

   1. 다음 YAML을 hw-event.yaml 파일에 저장합니다.

      apiVersion: "event.redhat-cne.org/v1alpha1"
      kind: "HardwareEvent"
      metadata:
        name: "hardware-event"
      spec:
        nodeSelector:
          node-role.kubernetes.io/hw-event: "" 1
        logLevel: "debug" 2
        msgParserTimeout: "10" 3

      1

      필수 항목입니다. nodeSelector 필드를 사용하여 지정된 레이블이 있는 노드를 대상으로 지정합니다(예: node-role.kubernetes.io/hw-event: "" ).

      참고

      OpenShift Container Platform 4.13 이상에서는 베어 메탈 이벤트에 HTTP 전송을 사용할 때 HardwareEvent 리소스에서 spec.transportHost 필드를 설정할 필요가 없습니다. 베어 메탈 이벤트에 AMQP 전송을 사용하는 경우에만 transportHost 를 설정합니다.

      2

      선택 사항: 기본값은 debug 입니다. hw-event-proxy 로그에서 로그 수준을 설정합니다. 다음과 같은 로그 수준을 사용할 수 있습니다. fatal,error,warning,info,debug,trace.

      3

      선택 사항: Message Parser의 시간 초과 값을 밀리초로 설정합니다. 메시지 구문 분석 요청이 시간 초과 내에 응답하지 않으면 원래 하드웨어 이벤트 메시지가 클라우드 네이티브 이벤트 프레임워크에 전달됩니다. 기본값은 10입니다.

   2. 클러스터에 HardwareEvent CR을 적용합니다.

      $ oc create -f hardware-event.yaml

2. 하드웨어 이벤트 프록시가 베어 메탈 호스트의 Redfish 메시지 레지스트리에 액세스할 수 있는 BMC 사용자 이름 및 암호 Secret CR을 생성합니다.

   1. hw-event-bmc-secret.yaml 파일에 다음 YAML을 저장합니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: redfish-basic-auth
      type: Opaque
      stringData: 1
        username: <bmc_username>
        password: <bmc_password>
        # BMC host DNS or IP address
        hostaddr: <bmc_host_ip_address>

      1

      stringData 아래에 다양한 항목의 일반 텍스트 값을 입력합니다.

   2. Secret CR을 생성합니다.

      $ oc create -f hw-event-bmc-secret.yaml

프로세스

1. "워크로드 힌트 이해"의 표에 설명된 대로 환경의 하드웨어 및 토폴로지에 적합한 PerformanceProfile 을 생성합니다. 예상 워크로드와 일치하도록 프로필을 조정합니다. 이 예제에서는 가능한 가장 낮은 대기 시간을 위해 튜닝합니다.

2. highPowerConsumption 및 realTime 워크로드 힌트를 추가합니다. 둘 다 여기에서 true 로 설정됩니다.

       apiVersion: performance.openshift.io/v2
       kind: PerformanceProfile
       metadata:
         name: workload-hints
       spec:
         ...
         workloadHints:
           highPowerConsumption: true 1
           realTime: true 2

   1

   highPowerConsumption 이 true 인 경우 노드의 전력 소비 증가에 따라 대기 시간이 매우 짧은 시간에 맞게 노드가 조정됩니다.

   2

   시스템 대기 시간에 영향을 줄 수 있는 일부 디버깅 및 모니터링 기능을 비활성화합니다.

프로세스

1. per-pod-power-management 인수가 true 로 설정된 PerformanceProfile 을 생성합니다.

   $ podman run --entrypoint performance-profile-creator -v \
   /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.15 \
   --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \
   --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \
   --must-gather-dir-path /must-gather --power-consumption-mode=low-latency \ 1
   --per-pod-power-management=true > my-performance-profile.yaml

   1

   per-pod-power-management 인수가 true 로 설정된 경우 power-consumption-mode 인수는 default 또는 low-latency 여야 합니다.

   perPodPowerManagement가 있는 PerformanceProfile 의 예

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
        name: performance
   spec:
       [.....]
       workloadHints:
           realTime: true
           highPowerConsumption: false
           perPodPowerManagement: true

2. PerformanceProfile CR(사용자 정의 리소스)에서 기본 cpufreq governor를 추가 커널 인수로 설정합니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
        name: performance
   spec:
       ...
       additionalKernelArgs:
       - cpufreq.default_governor=schedutil 1

   1

   그러나 schedutil governor를 사용하는 것이 좋습니다. 그러나 온디맨드 또는 전원 세이저와 같은 다른 governor를 사용할 수 있습니다.

3. TunedPerformancePatch CR에서 최대 CPU 빈도를 설정합니다.

   spec:
     profile:
     - data: |
         [sysfs]
         /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x> 1

   1

   max_perf_pct 는 cpufreq 드라이버가 지원되는 최대 cpu 빈도의 백분율로 설정할 수 있는 최대 빈도를 제어합니다. 이 값은 모든 CPU에 적용됩니다. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 에서 지원되는 최대 빈도를 확인할 수 있습니다. 시작점으로 모든 CPU를 모든 코어 frequency로 제한하는 백분율로 사용할 수 있습니다. 모든 코어의 frequency는 코어가 완전히 비어 있을 때 모든 코어가 실행되는 빈도입니다.

프로세스

1. 환경의 하드웨어 및 토폴로지에 적합한 성능 프로필을 만듭니다.

2. 인프라 및 애플리케이션 컨테이너에 대해 reserved 및 isolated하려는 CPU와 함께 예약 및 격리된 매개변수를 추가합니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: infra-cpus
   spec:
     cpu:
       reserved: "0-4,9" 1
       isolated: "5-8" 2
     nodeSelector: 3
       node-role.kubernetes.io/worker: ""

   1

   클러스터 및 운영 체제 하우스키핑 작업을 수행하기 위해 인프라 컨테이너의 CPU를 지정합니다.

   2

   애플리케이션 컨테이너가 워크로드를 실행하는 CPU를 지정합니다.

   3

   선택 사항: 노드 선택기를 지정하여 특정 노드에 성능 프로파일을 적용합니다.

프로세스

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를 isolated 로, 논리 코어 CPU1을 CPU3으로, CPU5를 예약된 CPU7으로 설정할 수 있습니다. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

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

   참고

   예약 및 격리된 CPU 풀은 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.