1. YAML 設定ファイル cluster-monitoring-config.yml を作成します。以下に例を示します。

   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 のいずれかを使用した単純な整数または固定小数点整数を使用できます。 また、2 のべき乗の値 (Ei、Pi、Ti、Gi、Mi、Ki) を使用することもできます。

   5

   標準の値は ALERTMANAGER_STORAGE_SIZE=20Gi です。ストレージの値には、接尾辞 E、P、T、G、M、K のいずれかを使用した単純な整数または固定小数点整数を使用できます。 また、2 のべき乗の値 (Ei、Pi、Ti、Gi、Mi、Ki) を使用することもできます。

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

   <device_type_glob> は、ブロックデバイスタイプのシェル glob に置き換えます。SCSI または SATA ドライブの場合は /dev/sd* を使用し、仮想ドライブの場合は /dev/vd* を使用し、NVMe ドライブの場合は /dev/nvme*[0-9]*n* を使用します。

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 で毎秒 125 MiB の gp3 ディスクがコントロールプレーン/etcd ノードに使用されます。gp3 ボリュームはバーストパフォーマンスを使用しません。
2. インフラストラクチャーノードは、モニタリング、Ingress およびレジストリーコンポーネントをホストするために使用され、これにより、それらが大規模に実行する場合に必要とするリソースを十分に確保することができます。
3. ワークロードノードは、パフォーマンスとスケーラビリティーのワークロードジェネレーターを実行するための専用ノードです。
4. パフォーマンスおよびスケーラビリティーのテストの実行中に収集される大容量のデータを保存するのに十分な領域を確保できるように、大きなディスクサイズが使用されます。
5. クラスターは反復的にスケーリングされ、パフォーマンスおよびスケーラビリティーテストは指定されたノード数で実行されます。

1. GiB あたり 120/10 IOPS の io1 ディスクがコントロールプレーン/etcd ノードに使用されます。
2. インフラストラクチャーノードは、モニタリング、Ingress およびレジストリーコンポーネントをホストするために使用され、これにより、それらが大規模に実行する場合に必要とするリソースを十分に確保することができます。
3. ワークロードノードは、パフォーマンスとスケーラビリティーのワークロードジェネレーターを実行するための専用ノードです。
4. パフォーマンスおよびスケーラビリティーのテストの実行中に収集される大容量のデータを保存するのに十分な領域を確保できるように、大きなディスクサイズが使用されます。
5. クラスターは反復でスケーリングされます。

1. ノードは 2 つの論理制御ユニット (LCU) 間で分散され、コントロールプレーン/etcd ノードのディスク I/O 負荷を最適化します。etcd の I/O 需要が他のワークロードに干渉してはなりません。
2. 100/250/500 Pod で同時に複数の反復を実行するテストには、4 つのコンピュートノードが使用されます。まず、Pod をインスタンス化できるかどうかを評価するために、アイドリング Pod が使用されました。次に、ネットワークと CPU を必要とするクライアント/サーバーのワークロードを使用して、ストレス下でのシステムの安定性を評価しました。クライアント Pod とサーバー Pod はペアで展開され、各ペアは 2 つのコンピュートノードに分散されました。
3. 個別のワークロードノードは使用されませんでした。ワークロードは、2 つのコンピュートノード間のマイクロサービスワークロードをシミュレートします。
4. 使用されるプロセッサーの物理的な数は、6 つの Integrated Facilities for Linux (IFL) です。
5. 使用される物理メモリーの合計は 512 GiB です。

手順

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 の namespace を作成します。

   1. 以下の YAML を nro-namespace.yaml ファイルに保存します。

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

   2. 以下のコマンドを実行して Namespace 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. 以下のコマンドを実行して Subscription CR を作成します。

      $ oc create -f nro-sub.yaml

検証

1. openshift-numaresources namespace の 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 の namespace を作成します。

   1. OpenShift Container Platform Web コンソールで、Administration → Namespaces をクリックします。
   2. Create Namespace をクリックし、Name フィールドに openshift-numresources と入力して Create をクリックします。

2. NUMA Resources Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator のリストから NUMA Resources Operator を選択し、Install をクリックします。
   3. Installed Namespaces フィールドで、openshift-umaresources namespace を選択して Install をクリックします。

3. オプション: NUMA Resources Operator が正常にインストールされたことを確認します。

   1. Operators → Installed Operators ページに切り替えます。

   2. NUMA Resources Operator が openshift-umaresources namespace にリストされ、Status が InstallSucceeded であることを確認します。

      注記

      インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • Workloads → Pods ページに移動し、default プロジェクトの 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. 次の YAML を nro-perfprof.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.isorated および cpu.reserved 仕様は、分離および予約された CPU の範囲を定義します。CPU 設定の有効な値を入力します。パフォーマンスプロファイルの設定について、詳しくは 関連情報 セクションを参照してください。

   2. 次のコマンドを実行して、PerformanceProfile CR を作成します。

      $ oc create -f nro-perfprof.yaml

      出力例

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

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-rhel9:v4.15"
        cacheResyncPeriod: "5s" 1

      1

      スケジューラーキャッシュの同期間隔を秒単位の値で入力します。ほとんどの実装におけるこの値は、5 が一般的です。

      注記

      • cacheResyncPeriod 仕様を有効にすると、NUMA Resource Operator は、ノード上の保留中のリソースを監視し、定義された間隔でスケジューラーキャッシュ内のこの情報を同期することで、より正確なリソース可用性を報告できます。これは、次善のスケジューリング決定が引き起こす Topology Affinity Error エラーを最小限に抑えるのにも役立ちます。間隔が短いほど、ネットワーク負荷が大きくなります。デフォルトでは、cacheResyncPeriod 仕様は無効になっています。
      • cacheResyncPeriod 仕様の実装には、NUMAResourcesOperator CR の podsFingerprinting 仕様の値を Enabled に設定する必要があります。

   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 で指定した namespace に置き換えます。

      $ 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 に割り当てられたリソースが原因で、Available な容量が減少しています。

      保証された Pod によって消費されるリソースは、noderesourcetopologies.topology.node.k8s.io にリスト表示されている使用可能なノードリソースから差し引かれます。

4. Best-effort または Burstable の サービス品質 (qosClass) を持つ Pod のリソース割り当てが、noderesourcetopologies.topology.node.k8s.io の NUMA ノードリソースに反映されていません。Pod の消費リソースがノードリソースの計算に反映されない場合は、Pod の qosClass が Guaranteed で、CPU 要求が 10 進値ではなく整数値であることを確認してください。次のコマンドを実行すると、Pod の qosClass が Guaranteed であることを確認できます。

   $ 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 の場合、Static は大文字の 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.15"
        cacheResyncPeriod: "5s" 1

      1

      スケジューラーキャッシュの同期間隔を秒単位の値で入力します。ほとんどの実装におけるこの値は、5 が一般的です。

      注記

      • cacheResyncPeriod 仕様を有効にすると、NUMA Resource Operator は、ノード上の保留中のリソースを監視し、定義された間隔でスケジューラーキャッシュ内のこの情報を同期することで、より正確なリソース可用性を報告できます。これは、次善のスケジューリング決定が引き起こす Topology Affinity Error エラーを最小限に抑えるのにも役立ちます。間隔が短いほど、ネットワーク負荷が大きくなります。デフォルトでは、cacheResyncPeriod 仕様は無効になっています。
      • cacheResyncPeriod 仕様の実装には、NUMAResourcesOperator CR の podsFingerprinting 仕様の値を Enabled に設定する必要があります。

   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 で指定した namespace に置き換えます。

      $ 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 に割り当てられたリソースが原因で、Available な容量が減少しています。

      保証された Pod によって消費されるリソースは、noderesourcetopologies.topology.node.k8s.io にリスト表示されている使用可能なノードリソースから差し引かれます。

4. Best-effort または Burstable の サービス品質 (qosClass) を持つ Pod のリソース割り当てが、noderesourcetopologies.topology.node.k8s.io の NUMA ノードリソースに反映されていません。Pod の消費リソースがノードリソースの計算に反映されない場合は、Pod の qosClass が Guaranteed で、CPU 要求が 10 進値ではなく整数値であることを確認してください。次のコマンドを実行すると、Pod の qosClass が Guaranteed であることを確認できます。

   $ 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/v1
   kind: NUMAResourcesScheduler
   metadata:
     name: numaresourcesscheduler
   spec:
     imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.15"
     logLevel: Debug

3. 次のコマンドを実行して、更新された Debug ロギング 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 namespace で実行されている 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 の値を使用して、対象となる 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) ワーカー 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. 次のコマンドを実行して、マウント namespace 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 マウント namespace を確認します。

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

   出力例

   mnt:[4026531953]

4. kubelet マウント namespace をチェックします。

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

   出力例

   mnt:[4026531840]

5. CRI-O マウント namespace を確認します。

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

   出力例

   mnt:[4026531840]

手順

1. クラスターホストへのリモート SSH シェルを開きます。以下に例を示します。

   $ ssh core@<node_name>

2. root ユーザーとして、提供された kubesenter スクリプトを使用してコマンドを実行します。Kubernetes namespace 内で単一のコマンドを実行するには、コマンドと任意の引数を kubenenter スクリプトに提供します。たとえば、Kubernetes namespace 内で 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 namespace 内で新しいインタラクティブシェルを開始するには、引数を指定せずに kubesenter スクリプトを実行します。

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

   出力例

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

手順

1. Web コンソールで、Compute → Bare Metal Hosts に移動します。
2. Add Host → New with Dialog を選択します。
3. 新規ベアメタルホストの一意の名前を指定します。
4. Boot MAC address を設定します。
5. Baseboard Management Console (BMC) Address を設定します。
6. ホストのベースボード管理コントローラー (BMC) のユーザー認証情報を入力します。
7. 作成後にホストの電源をオンにすることを選択し、Create を選択します。
8. 利用可能なベアメタルホストの数に一致するようにレプリカ数をスケールアップします。Compute → MachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシンレプリカ数を増やします。

手順

1. Web コンソールで、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) の間の TLS ホスト検証が無効になります。

4. Create を選択して YAML を保存し、新規ベアメタルホストを作成します。

5. 利用可能なベアメタルホストの数に一致するようにレプリカ数をスケールアップします。Compute → MachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシン数を増やします。

   注記

   oc scale コマンドおよび適切なベアメタルコンピュートマシンセットを使用して、ベアメタルノードの数を管理することもできます。

手順

1. metal3.io/autoscale-to-hosts アノテーションを追加して、自動スケーリング用に設定するコンピュートマシンセットにアノテーションを付けます。<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 で変更される場合、BareMetalHost オブジェクトは Machine オブジェクトが作成された MachineSet に対して引き続きカウントされます。

2. プロビジョニングのユースケースでは、次のコマンドを使用して、再起動が完了した後にアノテーションを削除します。

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

手順

1. Bare Metal Event Relay の namespace を作成します。

   1. 以下の YAML を bare-metal-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. Bare Metal Event Relay にサブスクライブします。

   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 Web コンソールを使用して Bare Metal Event Relay をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator のリストから Bare Metal Event Relay を選択し、Install をクリックします。
   3. Install Operatorページで、Namespace を選択または作成し、openshift-bare-metal-events を選択して、Install をクリックします。

1. Operators → Installed Operators ページに切り替えます。

2. Status が InstallSucceeded の状態で、Bare Metal Event Relay がプロジェクトにリスト表示されていることを確認します。

   注記

   インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

手順

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"
   }

   この例では、サブスクリプションが 1 つ設定されています (/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. BMC ユーザー名およびパスワード Secret CR を作成します。これにより、ハードウェアイベントプロキシーがベアメタルホストの Redfish メッセージレジストリーにアクセスできるようになります。

   1. 以下の YAML を hw-event-bmc-secret.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. デフォルトの cpufreq ガバナーを、PerformanceProfile カスタムリソース (CR) で追加のカーネル引数として設定します。

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

   1

   schedutil ガバナーの使用が推奨されますが、ondemand ガバナーや powersave ガバナーなどの他のガバナーを使用することもできます。

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 で確認できます。開始点として、All Cores Turbo 周波数ですべての CPU を制限する割合を使用できます。All Cores Turbo 周波数は、すべてのコアがすべて使用されているときに全コアが実行される周波数です。

手順

1. 環境のハードウェアとトポロジーに適したパフォーマンスプロファイルを作成します。

2. infra およびアプリケーションコンテナー用に予約して分離する CPU で、 reserved および isolated パラメーターを追加します。

   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

   クラスターおよびオペレーティングシステムのハウスキーピングタスクを実行する infra コンテナーの 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 コアで 8 つの論理 CPU コアが実行されています。CPU0 および CPU4 は物理コアの Core0 で実行されており、CPU1 および CPU5 は物理コア 1 で実行されています。

   または、特定の物理 CPU コア (以下の例では cpu0) に設定されているスレッドを表示するには、シェルプロンプトを開いて次のコマンドを実行します。

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

   出力例

   0-4

2. PerformanceProfile YAML で分離された CPU および予約された CPU を適用します。たとえば、論理コア CPU0 と CPU4 をisolated として設定し、論理コア CPU1 から CPU3 および CPU5 から CPU7 をreserved として設定できます。予約および分離された CPU を設定する場合に、Pod 内の infra コンテナーは予約された CPU を使用し、アプリケーションコンテナーは分離された CPU を使用します。

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

   注記

   予約済みの CPU プールと分離された CPU プールは重複してはならず、これらは共に、ワーカーノードの利用可能なすべてのコアに広がる必要があります。