Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

12.5. 単一の NUMA ノードポリシーの設定

NUMA Resources Operator では、クラスター上に単一の NUMA ノードポリシーを設定する必要があります。この設定を行うには、パフォーマンスプロファイルを作成して適用するか、KubeletConfig を設定するという 2 つの方法があります。

注記

単一の NUMA ノードポリシーの設定方法としては、パフォーマンスプロファイルを適用する方法が推奨されます。パフォーマンスプロファイルの作成には、Performance Profile Creator (PPC) ツールを使用できます。クラスター上にパフォーマンスプロファイルを作成すると、KubeletConfig や tuned プロファイルなどの他のチューニングコンポーネントが自動的に作成されます。

パフォーマンスプロファイルの作成の詳細は、「関連情報」セクションの「Performance Profile Creator の概要」を参照してください。

12.5.1. NUMA 対応スケジューラーの高可用性(HA)の管理
リンクのコピー

重要

高可用性の管理はテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

NUMA Resources Operator は、NUMAResourcesScheduler カスタムリソース(CR)の spec.replicas フィールドに基づいて、NUMA 対応のセカンダリースケジューラーの高可用性を管理します。デフォルトでは、NUMA Resources Operator は、最大 3 つのレプリカを持つコントロールプレーンノードごとに 1 つのスケジューラーレプリカを作成して HA モードを自動的に有効にします。

次のマニフェストは、このデフォルトの動作を示しています。レプリカの検出を自動的に有効にするには、replicas フィールドを省略します。 

apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: example-auto-ha
spec:
  imageSpec: 'registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.20'
  # The 'replicas' field is not included, enabling auto-detection.
Copy to Clipboard Toggle word wrap

以下のオプションのいずれかを使用して、スケジューラーの動作を制御できます。

  • レプリカの数をカスタマイズする。
  • NUMA 対応のスケジューリングの無効化。

12.5.1.1. スケジューラーレプリカのカスタマイズ
リンクのコピー

NUMAResourcesScheduler カスタムリソースの spec.replicas フィールドを更新して、スケジューラーレプリカの特定の数を設定します。これにより、デフォルトの HA 動作が上書きされます。

手順

  1. レプリカの数を 2 に設定する custom-ha.yaml などの名前を付けられた次の YAML で NUMAResourcesScheduler CR を作成します。 

    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: example-custom
spec:
  imageSpec: 'registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.20'
  replicas: 2
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、NUMA 対応 Pod スケジューラーをデプロイします。 

    $ oc apply -f custom-ha.yaml
    Copy to Clipboard Toggle word wrap

12.5.1.2. NUMA 対応スケジューリングの無効化
リンクのコピー

NUMA 対応スケジューラーを無効にし、実行中のスケジューラー Pod をすべて停止し、新規スケジューラー Pod を起動しないようにします。

手順

  1. 以下の最小限の YAML を nro-disable-scheduler.yaml ファイルに保存します。spec.replicas フィールドを 0 に設定してスケジューラーを無効にします。 

    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: example-disable
spec:
  imageSpec: 'registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.20'
  replicas: 0
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、NUMA 対応 Pod スケジューラーを無効にします。 

    $ oc apply -f nro-disable-scheduler.yaml
    Copy to Clipboard Toggle word wrap

12.5.1.3. スケジューラーの高可用性(HA)ステータスの確認
リンクのコピー

NUMA 対応スケジューラーのステータスを確認し、設定に基づいて予想されるレプリカ数で実行されていることを確認します。

手順

  1. 次のコマンドを実行して、スケジューラー Pod のみを一覧表示します。 

    $ oc get pods -n openshift-numaresources -l app=secondary-scheduler
    Copy to Clipboard Toggle word wrap

    予想される出力

    デフォルトの HA モードを使用すると、Pod 数はコントロールプレーンノードの数と等しくなります。標準の HA OpenShift Container Platform クラスターには通常 3 つのコントロールプレーンノードがあるため、3 つの Pod が表示されます。 

    NAME                                   READY   STATUS    RESTARTS   AGE
secondary-scheduler-5b8c9d479d-2r4p5   1/1     Running   0          5m
secondary-scheduler-5b8c9d479d-k2f3p   1/1     Running   0          5m
secondary-scheduler-5b8c9d479d-q8c7b   1/1     Running   0          5m
    Copy to Clipboard Toggle word wrap
    • レプリカをカスタマイズした 場合、Pod の数は設定した値と一致します。

    • スケジューラーを無効 にした場合、このラベルを持つ実行中の Pod はありません。

      注記

      NUMA 対応のスケジューラーには、3 つのレプリカの制限が適用されます。ホステッドコントロールプレーンクラスターでは、スケジューラー Pod はホストされたクラスターのワーカーノードで実行されます。

  2. 次のコマンドを実行して、レプリカの数とそのステータスを確認します。 

    $ oc get deployment secondary-scheduler -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
secondary-scheduler   3/3     3            3           5m
    Copy to Clipboard Toggle word wrap

    この出力では、3/3 は予想される 3 つのレプリカから準備ができていることを意味します。

  3. 詳細については、次のコマンドを実行してください。 

    $ oc describe deployment secondary-scheduler -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    出力例

    Replicas 行には、3 つのレプリカ用に設定されたデプロイメントが表示され、3 つのレプリカすべてが更新され、利用可能な状態が表示されます。 

    Replicas:        3 desired | 3 updated | 3 total | 3 available | 0 unavailable
    Copy to Clipboard Toggle word wrap

12.5.2. パフォーマンスプロファイルの例
リンクのコピー

この YAML の例は、Performance Profile Creator (PPC) ツールを使用して作成されたパフォーマンスプロファイルを示しています。 

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: "3"
    reserved: 0-2
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/worker: ""
1 

  nodeSelector:
    node-role.kubernetes.io/worker: ""
  numa:
    topologyPolicy: single-numa-node
2 

  realTimeKernel:
    enabled: true
  workloadHints:
    highPowerConsumption: true
    perPodPowerManagement: false
    realTime: true
Copy to Clipboard Toggle word wrap
1
この値は、NUMA Resources Operator を設定する MachineConfigPool 値と一致する必要があります。たとえば、worker-cnf という名前の MachineConfigPool オブジェクトを作成し、通信ワークロードを実行する一連のノードを指定します。MachineConfigPool の値は、後ほど「NUMAResourcesOperator カスタムリソースの作成」で設定する NUMAResourcesOperator CR の machineConfigPoolSelector 値と一致する必要があります。
2
PPC ツールを実行する際に、topology-manager-policy 引数を single-numa-node に設定して、topologyPolicy フィールドが single-numa-node に設定されていることを確認します。
注記

Hosted Control Plane クラスターの場合、machineConfigPoolSelector は機能しません。代わりに、ノードの関連付けは指定された NodePool オブジェクトによって決定されます。

12.5.3. KubeletConfig CR の作成
リンクのコピー

単一の NUMA ノードポリシーの設定方法としては、パフォーマンスプロファイルを適用する方法が推奨されます。もう 1 つの方法は、次の手順に示すように、KubeletConfig カスタムリソース (CR) を作成して適用することです。

手順

  1. マシンプロファイルの Pod アドミタンスポリシーを設定する KubeletConfig カスタムリソース (CR) を作成します。

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

      apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: worker-tuning
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
      1 
      
  kubeletConfig:
    cpuManagerPolicy: "static"
      2 
      
    cpuManagerReconcilePeriod: "5s"
    reservedSystemCPUs: "0,1"
      3 
      
    memoryManagerPolicy: "Static"
      4 
      
    evictionHard:
      memory.available: "100Mi"
    kubeReserved:
      memory: "512Mi"
    reservedMemory:
      - numaNode: 0
        limits:
          memory: "1124Mi"
    systemReserved:
      memory: "512Mi"
    topologyManagerPolicy: "single-numa-node"
      5
      Copy to Clipboard Toggle word wrap
      1
      このラベルが、後ほど「NUMAResourcesOperator カスタムリソースの作成」で設定する NUMAResourcesOperator CR の machineConfigPoolSelector 設定と一致していることを確認します。
      2
      cpuManagerPolicy の場合、static は小文字の s を使用する必要があります。
      3
      ノード上の CPU に基づいて調整します。
      4
      memoryManagerPolicy の場合、Static は大文字の S を使用する必要があります。
      5
      topologyManagerPolicy は single-numa-node に設定する必要があります。
      注記

      Hosted Control Plane クラスターの場合、machineConfigPoolSelector 設定は機能しません。代わりに、ノードの関連付けは指定された NodePool オブジェクトによって決定されます。Hosted Control Plane クラスターに KubeletConfig を適用するには、設定を含む ConfigMap を作成し、NodePool の spec.config フィールド内でその ConfigMap を参照する必要があります。

    2. 以下のコマンドを実行して KubeletConfig CR を作成します。 

      $ oc create -f nro-kubeletconfig.yaml
      Copy to Clipboard Toggle word wrap
      注記

      パフォーマンスプロファイルまたは KubeletConfig を適用すると、ノードの再起動が自動的にトリガーされます。再起動がトリガーされない場合は、ノードグループに対応する KubeletConfig のラベルを確認して、問題のトラブルシューティングを実施できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat