第17章 ワークロードの分割
ワークロードの分割はテクノロジープレビュー機能としてのみ使用できます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
リソースに制約のある環境では、ワークロードの分割を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、インフラストラクチャー Pod を分離し、予約済みの CPU セットで実行できます。
クラスター管理に必要な予約済み CPU の最小数は、4 つの CPU ハイパースレッド (HT) です。ワークロード分割では、クラスター管理ワークロードパーティションに含めるために、一連のクラスター管理 Pod と一連の一般的なアドオン Operator に注釈を付けます。これらの Pod は、最低限のサイズの CPU 設定内で正常に動作します。最小クラスター管理 Pod のセット外の追加の Operator またはワークロードでは、追加の CPU をワークロードパーティションに追加する必要があります。
ワークロード分割は、標準の Kubernetes スケジューリング機能を使用して、ユーザーワークロードをプラットフォームワークロードから分離します。
ワークロードの分割には次の変更が必要です。
install-config.yamlファイルに、cpuPartitioningModeを追加フィールドとして追加します。apiVersion: v1 baseDomain: devcluster.openshift.com cpuPartitioningMode: AllNodes 1 compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 3 controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: {} replicas: 3- 1
- インストール時に CPU のパーティション設定用クラスターをセットアップします。デフォルト値は
Noneです。
注記ワークロードの分割は、クラスターのインストール中にのみ有効にできます。インストール後にワークロードパーティショニングを無効にすることはできません。
パフォーマンスプロファイルで、
isolatedおよびreservedCPU を指定します。推奨されるパフォーマンスプロファイル設定
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: openshift-node-performance-profile spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime" - "module_blacklist=irdma" cpu: isolated: 2-51,54-103 reserved: 0-1,52-53 hugepages: defaultHugepagesSize: 1G pages: - count: 32 size: 1G node: 0 machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/master: "" nodeSelector: node-role.kubernetes.io/master: '' numa: topologyPolicy: "restricted" realTimeKernel: enabled: true workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: false表17.1 シングルノード OpenShift クラスターの PerformanceProfile CR オプション PerformanceProfile CR フィールド 説明 metadata.namenameが、関連する GitOps ZTP カスタムリソース (CR) に設定されている次のフィールドと一致していることを確認してください。-
TunedPerformancePatch.yamlのinclude=openshift-node-performance-${PerformanceProfile.metadata.name} -
validatorCRs/informDuValidator.yamlのname: 50-performance-${PerformanceProfile.metadata.name}
spec.additionalKernelArgs"efi=runtime"は、クラスターホストの UEFI セキュアブートを設定します。spec.cpu.isolated分離された CPU を設定します。すべてのハイパースレッディングペアが一致していることを確認します。
重要予約済みおよび分離された CPU プールは重複してはならず、いずれも使用可能なすべてのコア全体にわたる必要があります。考慮されていない CPU コアは、システムで未定義の動作を引き起こします。
spec.cpu.reserved予約済みの CPU を設定します。ワークロードの分割が有効になっている場合、システムプロセス、カーネルスレッド、およびシステムコンテナースレッドは、これらの CPU に制限されます。分離されていないすべての CPU を予約する必要があります。
spec.hugepages.pages-
huge page の数 (
count) を設定します。 -
huge page のサイズ (
size) を設定します。 -
nodeをhugepageが割り当てられた NUMA ノード (node) に設定します。
spec.realTimeKernelリアルタイムカーネルを使用するには、
enabledをtrueに設定します。spec.workloadHintsworkloadHintsを使用して、各種ワークロードの最上位フラグのセットを定義します。この例では、クラスターが低レイテンシーかつ高パフォーマンスになるように設定されています。-
ワークロードパーティショニングにより、プラットフォーム Pod に拡張された Management.workload.openshift.io/cores リソースタイプが導入されます。kubelet は、対応するリソース内のプールに割り当てられた Pod でリソースと CPU リクエストをアドバタイズします。ワークロードの分割が有効になっている場合、スケジューラーは management.workload.openshift.io/cores リソースにより、デフォルトの cpuset だけでなく、ホストの cpushares 容量に基づいて Pod を適切に割り当てることができます。
関連情報
- 単一ノードの OpenShift クラスターで推奨されるワークロードパーティショニング設定については、ワークロードパーティショニング を参照してください。
