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

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

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

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

   $ oc create -f etcd-mc.yml

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

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

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

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

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

   $ oc replace -f etcd-mc.yml

1. 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. 노드는 두 개의 LUN(Logical Control Unit) 간에 분산되어 etcd가 I/O 집약적이고 지연 시간에 민감하므로 컨트롤 플레인/etcd 노드의 디스크 I/O 부하를 최적화합니다. etcd I/O 수요가 다른 워크로드를 방해하지 않아야 합니다.
2. 4개의 컴퓨팅 노드는 동시에 100/250/500개의 Pod를 사용하여 여러 번 반복하는 테스트에 사용됩니다. 먼저 Pod를 인스턴스에 사용할 수 있는지 평가하는 데 Pod를 유휴 상태로 설정합니다. 다음으로 네트워크 및 CPU 까다로운 클라이언트/서버 워크로드가 스트레스를 받고 시스템의 안정성을 평가하는 데 사용되었습니다. 클라이언트 및 서버 포드는 쌍으로 배포되었으며 각 쌍은 두 개의 계산 노드에 분산되었습니다.
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. nro-namespace.yaml 파일에 다음 YAML을 저장합니다.

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

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

      $ oc create -f nro-namespace.yaml

2. NUMA 리소스 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 리소스 Operator에 대한 서브스크립션을 생성합니다.

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

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

   2. 다음 명령을 실행하여 Subscription 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.12.2   numaresources-operator   4.12.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 리소스 Operator가 설치되었는지 확인합니다.

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

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

      참고

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

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

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

절차

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: registry.access.redhat.com/rhel:latest
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args: [ "while true; do sleep 1h; done;" ]
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "8"
                requests:
                  memory: "100Mi"
                  cpu: "8"

      1

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

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

      $ oc create -f nro-deployment.yaml

검증

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

   $ oc get pods -n openshift-numaresources

   출력 예

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

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

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

   출력 예

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

   참고

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

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

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

   출력 예

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

   1

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

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

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

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

   출력 예

   Guaranteed

절차

1. 선택 사항: 작업자 노드에 사용자 정의 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. nrop.yaml 파일에 다음 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. 다음 YAML을 nro-scheduler.yaml 파일에 저장합니다.

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"
        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 서비스 품질(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. 다음 YAML을 nro-scheduler-debug.yaml 파일에 저장합니다. 이 예제에서는 로그 수준을 Debug 로 변경합니다.

   apiVersion: nodetopology.openshift.io/v1alpha1
   kind: NUMAResourcesScheduler
   metadata:
     name: numaresourcesscheduler
   spec:
     imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"
     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 리소스 Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는 NUMAResourcesOperator CR에 해당 nodeGroup 이 있습니다. 다음 명령을 실행합니다.

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

   출력 예

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

2. 이전 단계의 이름 값을 사용하여 관심 있는 daemonset의 레이블을 가져옵니다.

   $ 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. 다음 명령을 사용하여 kubeletconfig 의 spec.machineConfigPoolSelector.matchLabels 값과 MachineConfigPool (mcp) worker CR의 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.12 이상에서는 베어 메탈 이벤트에 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. 선택사항: OpenShift Container Platform 클러스터에 노드를 추가합니다. 시스템 튜닝을 위한 BIOS 매개변수 설정을 참조하십시오.
2. oc 명령을 사용하여 실시간 기능이 필요한 작업자 노드에 worker-rt 레이블을 추가합니다.

3. 실시간 노드에 사용할 새 머신 구성 풀을 생성합니다.

   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 가 생성됩니다.

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

   참고

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

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

6. 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

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

   $ oc describe mcp/worker-rt

   출력 예

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

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

프로세스

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. 성능 프로필에 오프라인 CPU를 설정하고 YAML 파일의 내용을 저장합니다.

   오프라인 CPU가 있는 성능 프로파일의 예

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: performance
   spec:
     additionalKernelArgs:
     - nmi_watchdog=0
     - audit=0
     - mce=off
     - processor.max_cstate=1
     - intel_idle.max_cstate=0
     - idle=poll
     cpu:
       isolated: "2-23,26-47"
       reserved: "0,1,24,25"
       offlined: "48-59" 1
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""
     numa:
       topologyPolicy: single-numa-node
     realTimeKernel:
       enabled: true

   1

   선택 사항: 오프라인 필드에서 CPU를 나열하여 지정된 CPU를 오프라인으로 가져올 수 있습니다.

2. 다음 명령을 실행하여 업데이트된 프로필을 적용합니다.

   $ oc apply -f my-performance-profile.yaml

절차

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.12 \
   --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

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

   perPodPowerManagement가 있는 PerformanceProfile 의 예

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

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

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

   1

   그러나 schedutil governor를 사용하는 것이 좋습니다. 그러나 ondemand 또는 powersave governors와 같은 다른 governors를 사용할 수 있습니다.

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/cpu0/cpufreq/cpuinfo_max_freq 에서 지원되는 최대 빈도를 확인할 수 있습니다. 시작점으로 모든 코어 s의 frequency에서 모든 CPU를 제한하는 백분율을 사용할 수 있습니다. 모든 코어sECDHE 빈도는 코어가 모두 완전히 사용 중인 경우 모든 코어가 실행되는 빈도입니다.

4. 높은 우선 순위 워크로드 Pod에 원하는 주석을 추가합니다. 주석은 기본 설정을 재정의합니다.

   우선 순위가 높은 워크로드 주석 예

   apiVersion: v1
   kind: Pod
   metadata:
     ...
     annotations:
       ...
       cpu-c-states.crio.io: "disable"
       cpu-freq-governor.crio.io: "<governor>"
       ...
     ...
   spec:
     ...
     runtimeClassName: performance-<profile_name>
     ...

5. Pod를 다시 시작합니다.

절차

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: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12"
       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. 노드 구성이 올바르게 적용되었는지 확인합니다. 노드에 로그인하여 구성을 확인합니다.

    $ 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 풀은 중복되지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

절차

1. "Works workload hints"의 표에 설명된 대로 환경의 하드웨어 및 토폴로지에 적합한 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. 환경의 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.

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. cluster-admin 권한이 있는 사용자로 Node Tuning Operator를 실행하는 OpenShift Container Platform 클러스터에 로그인합니다.
2. 하드웨어 및 토폴로지에 적합한 성능 프로파일을 만들고 적용합니다. 프로파일 생성에 대한 지침은 "성능 프로파일 생성" 섹션을 참조하십시오.

3. 생성된 성능 프로파일을 편집합니다.

   $ oc edit -f <your_profile_name>.yaml

4. spec 필드를 net 오브젝트로 채웁니다. 오브젝트 목록에는 다음 두 개의 필드가 포함될 수 있습니다.

   • userLevelNetworking은 부울 플래그로 지정된 필수 필드입니다. userLevelNetworking이 true인 경우 지원되는 모든 장치에 대해 대기열 수가 예약된 CPU 수로 설정됩니다. 기본값은 false입니다.

   • devices는 예약된 CPU 수로 큐를 설정할 장치 목록을 지정하는 선택적 필드입니다. 장치 목록이 비어 있으면 구성이 모든 네트워크 장치에 적용됩니다. 구성은 다음과 같습니다.

     • interfacename: 이 필드는 인터페이스 이름을 지정하고, 양수 또는 음수일 수 있는 쉘 스타일 와일드카드를 지원합니다.

       • 와일드카드 구문의 예는 다음과 같습니다. <string> .*
       • 음수 규칙 앞에는 느낌표가 붙습니다. 제외된 목록이 아닌 모든 장치에 넷 큐 변경 사항을 적용하려면 !<device>를 사용합니다(예: !eno1).
     • vendorID: 접두사가 0x인 16비트 16진수로 표시되는 네트워크 장치 공급업체 ID입니다.

     • deviceID: 0x 접두사가 있는 16비트 16진수로 표시되는 네트워크 장치 ID(모델)입니다.

       참고

       deviceID가 지정되어 있는 경우 vendorID도 정의해야 합니다. 장치 항목 interfaceName, vendorID, vendorID 및 deviceID의 쌍에 지정된 모든 장치 식별자와 일치하는 장치는 네트워크 장치로 간주됩니다. 그러면 이 네트워크 장치의 네트워크 대기열 수가 예약된 CPU 수로 설정됩니다.

       두 개 이상의 장치가 지정되면 네트워크 대기열 수가 해당 장치 중 하나와 일치하는 모든 네트워크 장치로 설정됩니다.

5. 다음 예제 성능 프로필을 사용하여 대기열 수를 모든 장치에 예약된 CPU 수로 설정합니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

6. 다음 예제 성능 프로필을 사용하여 정의된 장치 식별자와 일치하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "eth0"
       - interfaceName: "eth1"
       - vendorID: "0x1af4"
         deviceID: "0x1000"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

7. 다음 예제 성능 프로필을 사용하여 인터페이스 이름 eth로 시작하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "eth*"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

8. 이 예제 성능 프로필을 사용하여 이름이 eno1 이외의 인터페이스가 있는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "!eno1"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

9. 인터페이스 이름 eth0, 0x1af4의 vendorID 및 0x1000의 deviceID는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다. 성능 프로파일 예는 다음과 같습니다.

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: manual
   spec:
     cpu:
       isolated: 3-51,55-103
       reserved: 0-2,52-54
     net:
       userLevelNetworking: true
       devices:
       - interfaceName: "eth0"
       - vendorID: "0x1af4"
         deviceID: "0x1000"
     nodeSelector:
       node-role.kubernetes.io/worker-cnf: ""

10. 업데이트된 성능 프로필을 적용합니다.

    $ oc apply -f <your_profile_name>.yaml

1. 연관 머신 구성 풀이 성능 저하 상태입니다.

   # oc get mcp

   출력 예

   NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master       rendered-master-2ee57a93fa6c9181b546ca46e1571d2d       True      False      False      3              3                   3                     0                      2d21h
   worker       rendered-worker-d6b2bdc07d9f5a59a6b68950acf25e5f       True      False      False      2              2                   2                     0                      2d21h
   worker-cnf   rendered-worker-cnf-6c838641b8a08fff08dbd8b02fb63f7c   False     True       True       2              1                   1                     1                      2d20h

2. MCP의 describe 섹션은 이유를 보여줍니다.

   # oc describe mcp worker-cnf

   출력 예

     Message:               Node node-worker-cnf is reporting: "prepping update:
     machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not
     found"
       Reason:                1 nodes are reporting degraded status on sync

3. degraded = true로 표시된 성능 프로필 status 필드 아래에도 성능 저하 상태가 표시되어야 합니다.

   # oc describe performanceprofiles performance

   출력 예

   Message: Machine config pool worker-cnf Degraded Reason: 1 nodes are reporting degraded status on sync.
   Machine config pool worker-cnf Degraded Message: Node yquinn-q8s5v-w-b-z5lqn.c.openshift-gce-devel.internal is
   reporting: "prepping update: machineconfig.machineconfiguration.openshift.io
   \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found".    Reason:  MCPDegraded
      Status:  True
      Type:    Degraded

프로세스

1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.

2. --image 또는 --image-stream 인수를 하나 이상 사용하여 oc adm must-gather 명령을 실행합니다. 예를 들어 다음 명령은 기본 클러스터 데이터와 Node Tuning Operator 관련 정보를 모두 수집합니다.

   $ oc adm must-gather \
    --image-stream=openshift/must-gather \ 1
   
    --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.12 2

   1

   기본 OpenShift Container Platform must-gather 이미지입니다.

   2

   짧은 대기 시간 튜닝 진단을 위한 must-gather 이미지입니다.

3. 작업 디렉터리에 생성된 must-gather 디렉터리의 압축 파일을 생성합니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

    $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1

   1

   must-gather-local.5421342344627712289/를 실제 디렉터리 이름으로 바꿉니다.

4. Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.