12.5. 単一の NUMA ノードポリシーの設定
NUMA Resources Operator を有効にするには、クラスター上で単一の NUMA ノードポリシーを設定します。このポリシーは、パフォーマンスプロファイルを作成するか、KubeletConfig カスタムリソース (CR) を設定することで実装できます。
単一の NUMA ノードポリシーの設定方法としては、パフォーマンスプロファイルを適用する方法が推奨されます。パフォーマンスプロファイルの作成には、Performance Profile Creator (PPC) ツールを使用できます。クラスター上でパフォーマンスプロファイルが作成されると、PPC ツールは KubeletConfig や チューニング済み プロファイルなどの他のチューニングコンポーネントを自動的に作成します。
パフォーマンスプロファイルの作成の詳細は、「関連情報」セクションの「Performance Profile Creator の概要」を参照してください。
12.5.1. NUMA 対応スケジューラーの高可用性 (HA) の管理 リンクのコピーリンクがクリップボードにコピーされました!
NUMA 対応セカンダリースケジューラーの高可用性を確保するため、NUMA Resources Operator は制御プレーンノード上にスケジューラーレプリカを自動的に作成します。Operator は、NUMAResourcesScheduler カスタムリソース (CR) の spec.replicas フィールドを使用してこの設定を管理します。
高可用性の管理はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
デフォルトでは、NUMA Resources Operator は、コントロールプレーンノードごとに 1 つのスケジューラーレプリカ (最大 3 つのレプリカ) を作成して、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.
次のいずれかの方法を使用して、スケジューラーの動作を制御できます。
- レプリカの数をカスタマイズします。
- NUMA 対応スケジューリングを無効にします。
12.5.1.1. スケジューラーレプリカのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
NUMAResourcesScheduler カスタムリソースの spec.replicas フィールドを更新することで、スケジューラーレプリカの具体的な数を設定できます。この設定は、デフォルトの HA 動作を上書きします。
手順
例として、レプリカの数を 2 に設定する
custom-ha.yamlという名前の次の YAML を使用して、NUMAResourcesSchedulerCR を作成します。apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesScheduler metadata: name: example-custom spec: imageSpec: 'registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.20' replicas: 2 # ...次のコマンドを実行して、NUMA 対応 Pod スケジューラーをデプロイします。
$ oc apply -f custom-ha.yaml
12.5.1.2. NUMA 対応スケジューリングの無効化 リンクのコピーリンクがクリップボードにコピーされました!
NUMA 対応スケジューラーを無効にすると、実行中のすべてのスケジューラー Pod が停止し、新しい Pod の起動も防止されます。
手順
次の必要最小限の 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 # ...次のコマンドを実行して、NUMA 対応 Pod スケジューラーを無効にします。
$ oc apply -f nro-disable-scheduler.yaml
12.5.1.3. スケジューラーの高可用性 (HA) ステータスの検証 リンクのコピーリンクがクリップボードにコピーされました!
NUMA 対応スケジューラーのステータスを確認することで、設定に基づいて想定されるレプリカ数でスケジューラーが実行されていることを確認できます。
手順
次のコマンドを実行して、スケジューラー Pod だけをリスト表示します。
$ oc get pods -n openshift-numaresources -l app=secondary-scheduler予想される出力
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デフォルトの HA モードを使用すると、Pod の数がコントロールプレーンノードの数と等しくなります。標準的な高可用性 (HA) 設定の OpenShift Container Platform クラスターは、通常 3 つのコントロールプレーンノードを持ち、そのため 3 つの Pod が表示されます。レプリカをカスタマイズ した場合、Pod の数は設定した値と一致します。スケジューラーを無効化 した場合、このラベルが付いた実行中の Pod はありません。
注記NUMA 対応スケジューラーでは、レプリカの上限が 3 つに制限されています。Hosted Control Plane クラスターでは、スケジューラー Pod はホスト型クラスターのコンピュートノード上で実行されます。
次のコマンドを実行して、レプリカの数とステータスを確認します。
$ oc get deployment secondary-scheduler -n openshift-numaresources出力例
NAME READY UP-TO-DATE AVAILABLE AGE secondary-scheduler 3/3 3 3 5mこの出力の 3/3 は、期待される 3 つのレプリカのうち 3 つが準備完了状態であることを示しています。
より詳細な情報を得るには、次のコマンドを実行します。
$ oc describe deployment secondary-scheduler -n openshift-numaresources出力例
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailableReplicas行に、デプロイメントが 3 つのレプリカで設定されており、3 つとも更新済みで使用可能であることが表示されます。