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

スケーラビリティーおよびパフォーマンス

OpenShift Container Platform 4.18

実稼働環境における OpenShift Container Platform クラスターのスケーリングおよびパフォーマンスチューニング

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、クラスターをスケーリングし、OpenShift Container Platform 環境のパフォーマンスを最適化する方法を説明します。

第1章 OpenShift Container Platform スケーラビリティーおよびパフォーマンスの概要

OpenShift Container Platform は、クラスターのパフォーマンスとスケーリングを最適化するのに役立つベストプラクティスとツールを提供します。次のドキュメントでは、推奨されるパフォーマンスとスケーラビリティーのプラクティス、リファレンス設計仕様、最適化、低レイテンシーのチューニングに関する情報を提供します。

Red Hat サポートへの問い合わせは、サポート を参照してください。

注記

一部のパフォーマンス Operator およびスケーラビリティー Operator には、OpenShift Container Platform のリリースサイクルとは独立したリリースサイクルがあります。詳細は、OpenShift Operators を参照してください。

コントロールプレーンの推奨プラクティス

インフラストラクチャーの推奨プラクティス

etcd に関する推奨されるプラクティス

通信事業者リファレンス設計仕様

OpenShift Container Platform 4.18 の通信事業者 RAN DU リファレンス設計仕様

通信事業者コアリファレンス設計仕様

計画、最適化、測定

オブジェクトの最大値に合わせた環境計画

IBM Z および IBM LinuxONE の推奨プラクティス

Node Tuning Operator の使用

CPU マネージャーおよび Topology Manager の使用

NUMA 対応ワークロードのスケジューリング

ストレージ、ルーティング、ネットワーク、CPU 使用率の最適化

ベアメタルホストとイベントの管理

huge page の機能およびそれらがアプリケーションによって消費される仕組み

クラスターの安定性とパーティションワークロードを改善するための低レイテンシーチューニング

ワーカーレイテンシープロファイルを使用したレイテンシーの高い環境でのクラスターの安定性の向上

ワークロードパーティショニング

Node Observability Operator の使用

第3章 通信事業者コアリファレンス設計仕様

通信事業者コアリファレンス設計仕様 (RDS) は、通信事業者コアワークロードをホストする、コモディティーハードウェア上で実行される OpenShift Container Platform クラスターを設定するものです。

3.1. 通信事業者コア RDS 4.18 使用モデルの概要

通信事業者コアリファレンス設計仕様 (RDS) は、シグナリングやアグリゲーションなどのコントロールプレーン機能を含む大規模な通信アプリケーションを支えるプラットフォームを表したものです。これは、ユーザープレーン機能 (UPF) など、いくつかの集中型データプレーン機能も対象としています。通常、これらの機能には、スケーラビリティー、複雑なネットワークのサポート、耐障害性の高いソフトウェア定義ストレージが必要です。また、RAN などのファーエッジデプロイメントよりも厳密さや制約は少ないものの、パフォーマンス要件への対応も必要です。

3.2. 通信事業者コアクラスター使用モデルについて

通信事業者コアクラスター使用モデルは、コモディティーハードウェア上で実行されるクラスター向けに設計されています。通信事業者コアクラスターは、シグナリング、アグリゲーション、セッションボーダーコントローラー (SBC) などのコントロールプレーン機能や、5G ユーザープレーン機能 (UPF) などの集中型データプレーン機能を含む大規模な通信アプリケーションを支えるものです。通信事業者コアクラスターの機能には、スケーラビリティー、複雑なネットワークサポート、耐障害性の高いソフトウェア定義ストレージが必要です。また、ファーエッジ RAN デプロイメントよりも厳密さや制約は少ないものの、パフォーマンス要件への対応も必要です。

図3.1 通信事業者コア RDS クラスターのサービスベースのアーキテクチャーとネットワークトポロジー

オーバーレイされたネットワークトポロジーを備えたサービスベースのアーキテクチャーを示す 5G コアクラスター

通信事業者コア機能のネットワーク要件は、ネットワーク機能とパフォーマンスポイントの範囲によって大きく異なります。IPv6 が必須であり、デュアルスタックが一般的です。機能によっては、最大のスループットとトランザクションレートや、ユーザープレーン DPDK ネットワークのサポートが必要です。それ以外の機能は、より一般的なクラウドネイティブパターンを使用し、OVN-Kubernetes、カーネルネットワーク、負荷分散を利用できます。

通信事業者コアクラスターは、通常、標準の (非リアルタイム) カーネルで構成された 3 つのコントロールプレーンと 2 つ以上のワーカーノードで構成されます。ワーカーノードは、さまざまなネットワークおよびパフォーマンス要件を持つワークロードに対応するために、たとえば非ユーザーデータプレーンや高スループットのユースケース向けに、MachineConfigPool カスタムリソース (CR) を使用してセグメント化できます。通信事業者に必要な運用機能をサポートするために、コアクラスターには Day 2 OLM 管理 Operator の標準セットがインストールされています。

3.3. リファレンス設計の範囲

通信事業者コアおよび通信事業者 RAN リファレンス設計仕様 (RDS) は、通信事業者コアおよび通信事業者 RAN プロファイルを実行するクラスターで信頼性が高く再現性のあるパフォーマンスを実現するために推奨され、テストされ、サポートされている設定をキャプチャーします。

各 RDS には、クラスターが個々のプロファイルを実行するために設計および検証された、リリースされた機能とサポートされている設定が含まれています。設定により、機能と KPI ターゲットを満たすベースラインの OpenShift Container Platform インストールが提供されます。各 RDS では、個々の設定ごとに予想される変動も説明します。各 RDS の検証には、長期間にわたる大規模なテストが多数含まれます。

注記

検証済みのリファレンス設定は、OpenShift Container Platform のメジャー Y-stream リリースごとに更新されます。Z-stream パッチリリースは、リファレンス設定に照らして定期的に再テストされます。

3.4. リファレンス設計からの逸脱

検証済みの通信事業者コアおよび通信事業者 RAN DU リファレンス設計仕様 (RDS) から逸脱すると、変更した特定のコンポーネントや機能を超えた大きな影響が生じる可能性があります。逸脱には、完全なソリューションのコンテキストでの分析とエンジニアリングが必要です。

重要

RDS からのすべての逸脱は、明確なアクション追跡情報とともに分析され、文書化される必要があります。パートナーには、逸脱をリファレンス設計に合わせる方法を理解するためのデューデリジェンスが求められます。これには、パートナーが Red Hat と連携して、プラットフォームでユースケースがクラス最高の結果を達成できるようにするための関連情報を提供することが必要になる場合があります。これは、ソリューションのサポート可能性と、Red Hat 全体およびパートナーとの整合性を確保するために重要です。

RDS からの逸脱は、次の結果の一部またはすべてを引き起こす可能性があります。

  • 問題の解決にはさらに時間がかかる場合があります。
  • プロジェクトのサービスレベル契約 (SLA)、プロジェクトの期限、エンドプロバイダーのパフォーマンス要件などが満たされないリスクがあります。

  • 承認されていない逸脱については、経営幹部レベルでのエスカレーションが必要になる場合があります。

    注記

    Red Hat は、パートナーのエンゲージメントの優先順位に基づいて、逸脱のリクエストへの対応を優先します。

3.5. 通信事業者コアの共通ベースラインモデル

以下の設定と使用モデルは、すべての通信事業者コアのユースケースに適用できます。通信事業者コアのユースケースは、この共通の機能ベースラインに基づいて構築します。

クラスタートポロジー

通信事業者コアクラスターは次の要件に準拠します。

  • 高可用性コントロールプレーン (3 つ以上のコントロールプレーンノード)
  • スケジュール対象外のコントロールプレーンノード
  • 複数のマシン設定プール
ストレージ
通信事業者コアのユースケースでは、Red Hat OpenShift Data Foundation が提供する永続ストレージが必要です。
ネットワーク

通信事業者コアクラスターのネットワークは、次の要件に準拠します。

  • デュアルスタック IPv4/IPv6 (IPv4 プライマリー)。
  • 完全な非接続環境。クラスターはライフサイクルのどの時点でもパブリックネットワークにアクセスできません。
  • 複数のネットワークをサポートします。セグメント化されたネットワークにより、運用、管理および保守 (OAM)、シグナリング、およびストレージトラフィック間の分離を実現します。
  • クラスターネットワークタイプは、IPv6 のサポートに必要な OVN-Kubernetes です。

  • 通信事業者コアクラスターには、基盤となる RHCOS、SR-IOV Network Operator、ロードバランサー、およびその他のコンポーネントによってサポートされる複数のネットワークレイヤーがあります。これらのレイヤーには次のものが含まれます。

    • クラスターネットワークレイヤー。クラスターネットワークの設定は、インストール設定を通じて定義および適用します。NMState Operator を使用して、Day 2 オペレーション中に設定を更新します。初期設定を使用して以下を確立します。

      • ホストインターフェイスの設定。
      • アクティブ/アクティブボンディング (LACP)。
    • セカンダリー/追加ネットワークレイヤー。ネットワークの additionalNetwork または NetworkAttachmentDefinition CR を通じて OpenShift Container Platform CNI を設定します。初期設定を使用して、MACVLAN 仮想ネットワークインターフェイスを設定します。
    • アプリケーションワークロードレイヤー。ユーザープレーンネットワークは、クラウドネイティブネットワーク機能 (CNF) で実行されます。
Service Mesh
通信事業者 CNF では Service Mesh を使用できます。すべての通信事業者コアクラスターには、Service Mesh の実装が必要です。実装と設定の選択は、この仕様の範囲外です。

3.6. 通信事業者コアクラスターの共通使用モデルのエンジニアリングに関する考慮事項

  • クラスターのワークロードの詳細は、「アプリケーションワークロード」を参照してください。

  • ワーカーノードは、次のいずれかの CPU で実行する必要があります。

    • OpenShift Container Platform でサポートされている場合は、Intel 第 3 世代 Xeon (IceLake) CPU 以上、またはシリコンセキュリティーバグ (Spectre など) の軽減策が無効になっている CPU。Skylake およびそれ以前の CPU では、Spectre や同様の軽減策を有効にすると、トランザクションパフォーマンスが 40% 低下する可能性があります。

    • AMD EPYC Zen 4 CPU (Genoa、Bergamo 以降) 以上 (OpenShift Container Platform でサポートされている場合)。

      注記

      現在、AMD CPU では Pod ごとの電源管理を利用できません。

    • ワーカーノードで IRQ バランシングを有効にします。PerformanceProfile CR では、globallyDisableIrqLoadBalancing が false に設定されます。Guaranteed QoS Pod には、「CPU のパーティショニングとパフォーマンスチューニング」の説明のとおり、分離を実現するためのアノテーションが付けられます。

  • すべてのクラスターノードが次の条件を満たしている必要があります。

    • ハイパースレッディングが有効である
    • x86_64 CPU アーキテクチャーを備えている
    • 標準の (非リアルタイム) カーネルが有効である
    • ワークロードパーティショニング用に設定されていない

  • クラスター内のマシン設定プールによって、電源管理と最大パフォーマンスのバランスが異なります。マシン設定プールグループ内のすべてのノードで、次の設定が一貫している必要があります。

    • クラスターのスケーリング。詳細は、「スケーラビリティー」を参照してください。
    • 少なくとも 120 ノードまでクラスターをスケーリングできる必要があります。
  • CPU パーティショニングは PerformanceProfile CR を使用して設定され、MachineConfigPool ごとにノードに適用されます。「CPU パーティショニングとパフォーマンスチューニング」で関連する考慮事項を参照してください。

  • 設定された機能セットとアプリケーションのワークロード特性によって、OpenShift Container Platform の CPU 要件が異なります。リファレンス設定に基づいて設定されたクラスターの場合、次の CPU 要件が検証済みです。リファレンス設定では、kube-burner ノード密度テストによって作成される 3000 個の Pod からなるシミュレートされたワークロードを実行します。

    • コントロールプレーンとワーカーノードの予約済み CPU の最小数は、NUMA ノードあたり 2 CPU (4 ハイパースレッド) です。
    • DPDK 以外のネットワークトラフィックに使用する NIC は、少なくとも 16 個の RX/TX キューを使用するように設定する必要があります。
    • 多数の Pod やその他のリソースを持つノードでは、追加の予約済み CPU が必要になる場合があります。残りの CPU はユーザーのワークロードに使用できます。
    注記

    OpenShift Container Platform の設定、ワークロードのサイズ、およびワークロードの特性の変動により、OpenShift プラットフォームに必要な CPU 数にどのような影響があるかを判断するには、追加の分析が必要です。

3.6.1. アプリケーションワークロード

通信事業者コアクラスターで実行されるアプリケーションワークロードには、高パフォーマンスのクラウドネイティブネットワーク機能 (CNF) と従来の Best-effort または Burstable Pod ワークロードが混在している場合があります。

パフォーマンスまたはセキュリティーの要件により CPU を排他的または専用に使用する必要がある Pod では、Guaranteed QoS スケジューリングを利用できます。通常、ユーザープレーンネットワーク (DPDK など) を使用して高パフォーマンス CNF またはレイテンシーの影響を受けやすい CNF を実行する Pod では、ノードのチューニングと Guaranteed QoS スケジューリングによって実現される専用の CPU 全体を排他的に使用する必要があります。専用の CPU を必要とする Pod 設定を作成する場合は、ハイパースレッドシステムの潜在的な影響に注意してください。コア全体 (2 つのハイパースレッド) を Pod に割り当てる必要がある場合、Pod は 2 の倍数の CPU 数を要求する必要があります。

高スループットまたは低レイテンシーのネットワークを必要としないネットワーク機能を実行する Pod は、Best-effort または Burstable QoS Pod を使用してスケジュールする必要があります。専用または分離された CPU コアは必要ありません。

エンジニアリングに関する考慮事項

次の情報を使用して、通信事業者コアワークロードとクラスターリソースを計画してください。

  • CNF アプリケーションを、最新バージョンの Red Hat Best Practices for Kubernetes に準拠させる必要があります。

  • アプリケーションの要求に応じて、Best-effort および Burstable QoS Pod を組み合わせて使用します。

    • ノードを設定する PerformanceProfile CR で予約済みまたは分離された CPU を適切に設定して、Guaranteed QoS Pod を使用します。
    • Guaranteed QoS Pod には、CPU を完全に分離するためのアノテーションを含める必要があります。
    • Best-effort および Burstable Pod では、CPU の排他的使用が保証されません。ワークロードが、他のワークロード、オペレーティングシステムデーモン、またはカーネルタスクによるプリエンプションの対象になる可能性があります。

  • exec プローブは、他に適切な選択肢がない場合にのみ、慎重に使用してください。

    • CNF が CPU ピニングを使用する場合は、exec プローブを使用しないでください。httpGet や tcpSocket などの他のプローブ実装を使用します。
    • exec プローブを使用する必要がある場合は、exec プローブの頻度と量を制限します。exec プローブの最大数は 10 未満に維持し、頻度は 10 秒以上にする必要があります。
    • startup プローブは、安定状態の動作時には大量のリソースを使用しないため、使用できます。exec プローブに対するこのような制限は、主に liveness プローブと readiness プローブに適用されます。exec プローブはプロセスのフォークを必要とするため、他のプローブタイプと比較して管理コアの CPU 使用率が大幅に高くなります。

3.6.2. シグナリングワークロード

シグナリングワークロードでは通常、SCTP、REST、gRPC、または同様の TCP または UDP プロトコルが使用されます。シグナリングワークロードは、MACVLAN または SR-IOV インターフェイスとして設定されたセカンダリー Multus CNI を使用して、数十万のトランザクション毎秒 (TPS) に対応します。このワークロードは、Guaranteed または Burstable のいずれかの QoS を持つ Pod で実行できます。

3.7. 通信事業者コア RDS のコンポーネント

以下のセクションでは、通信事業者コアワークロードを実行するためにクラスターを設定およびデプロイするために使用するさまざまな OpenShift Container Platform コンポーネントと設定を説明します。

3.7.1. CPU パーティショニングとパフォーマンスチューニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
CPU パーティショニングは、機密性の高いワークロードを、汎用タスク、割り込み、およびドライバー作業キューから分離することで、パフォーマンスを向上させ、レイテンシーを削減します。このような補助的なプロセスに割り当てられた CPU のことを、次のセクションでは 予約済み CPU と呼びます。ハイパースレッディングが有効なシステムでは、CPU は 1 つのハイパースレッドになります。
制限と要件

  • オペレーティングシステムでは、カーネルネットワークを含むすべてのサポートタスクを実行するために、一定量の CPU が必要です。

    • ユーザープレーンネットワークアプリケーション (DPDK) のみを備えたシステムでは、オペレーティングシステムとインフラストラクチャーコンポーネント用に、少なくとも 1 つのコア (ハイパースレッディングが有効な場合は 2 つのハイパースレッド) が予約されている必要があります。
  • ハイパースレッディングが有効なシステムでは、コアシブリングスレッドが常に同じ CPU プール内にある必要があります。
  • 予約済みコアと分離されたコアのセットには、すべての CPU コアが含まれている必要があります。
  • 各 NUMA ノードのコア 0 は、予約済み CPU セットに含める必要があります。
  • 低レイテンシーのワークロードでは、割り込み、カーネルスケジューラー、またはプラットフォームの他の部分による影響を受けないように特別な設定が必要です。詳細は、「パフォーマンスプロファイルの作成」を参照してください。
エンジニアリングに関する考慮事項
  • 必要な最小予約容量 (systemReserved) は、Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes? ナレッジベース記事のガイダンスで確認できます。
  • 実際に必要な予約済み CPU 容量は、クラスターの設定とワークロードの属性によって異なります。
  • 予約済み CPU の値は、フルコア (2 ハイパースレッド) に合わせて切り上げる必要があります。
  • CPU パーティショニングを変更すると、関連するマシン設定プールに含まれるノードがドレインされ、再起動されます。
  • 予約済み CPU は Pod 密度を低下させます。予約済み CPU は、OpenShift Container Platform ノードの割り当て可能な容量から削除されるためです。

  • ワークロードがリアルタイム対応である場合は、リアルタイムワークロードヒントを有効にする必要があります。

    • リアルタイム workloadHint 設定を適用すると、nohz_full カーネルコマンドラインパラメーターが適用され、高パフォーマンスアプリケーションのパフォーマンスが向上します。workloadHint 設定を適用すると、cpu-quota.crio.io: "disable" アノテーションと適切な runtimeClassName 値を持たない分離された Pod または Burstable Pod が、CRI-O のレート制限の対象となります。workloadHint パラメーターを設定するときは、パフォーマンスの向上と CRI-O のレート制限による潜在的な影響との間のトレードオフに注意してください。必要な Pod にアノテーションが正しく付けられていることを確認してください。
  • IRQ アフィニティーをサポートしていないハードウェアは、分離された CPU に影響します。Guaranteed CPU QoS を持つ Pod が割り当てられた CPU を完全に使用できるように、すべてのサーバーハードウェアが IRQ アフィニティーをサポートしている必要があります。
  • OVS が、ネットワークトラフィックのニーズに合わせて、OVS の cpuset エントリーを動的に管理します。プライマリー CNI で高いネットワークスループットを処理するために、追加の CPU を予約する必要はありません。

  • クラスター上で実行されているワークロードがカーネルレベルのネットワークを使用する場合、参加している NIC の RX/TX キュー数を 16 または 32 キューに設定する必要があります (ハードウェアが許す場合)。デフォルトのキュー数に注意してください。設定がない場合、デフォルトのキュー数は、オンラインの CPU ごとに 1 つの RX/TX キューです。この場合、割り当てられる割り込みが多すぎる可能性があります。

    注記

    ドライバーによっては、キューの数を減らした後でも、割り込みの割り当てが解除されません。

  • クラスター上で実行されているワークロードに cgroup v1 が必要な場合は、クラスターの初期デプロイ中に cgroup v1 を使用するようにノードを設できます。「Linux コントロールグループバージョン 1 (cgroup v1) の有効化」および Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads を参照してください。

    注記

    cgroup v1 のサポートは、OpenShift Container Platform 4.19 で削除される予定です。cgroup v1 を実行しているクラスターは cgroup v2 に移行する必要があります。

関連情報

3.7.2. サービスメッシュ

説明
通信事業者コアのクラウドネイティブ機能 (CNF) には通常、サービスメッシュの実装が必要です。特定のサービスメッシュ機能とパフォーマンス要件は、アプリケーションによって異なります。Service Mesh の実装と設定の選択は、このドキュメントの範囲外です。実装では、Pod ネットワーキングで導入される追加のレイテンシーなど、サービスメッシュがクラスターリソースの使用状況とパフォーマンスに与える影響を考慮する必要があります。

関連情報

3.7.3. ネットワーク

次の図は、通信事業者コアリファレンス設計のネットワーク設定を示しています。

図3.2 通信事業者コアリファレンス設計のネットワーク設定

通信事業者コアリファレンス設計のネットワーク設定の概要
このリリースの変更点
  • SR-IOV Operator でのベンダープラグイン無効化のサポート
  • MetalLB および EgressIP 通信事業者 QE 検証により拡張された通信事業者コア RDS 検証

  • FRR-K8s が Cluster Network Operator で利用できるようになりました。

    注記

    metallb-system namespace にカスタムの FRRConfiguration CR がある場合は、それを openshift-network-operator namespace に移動する必要があります。

説明
  • クラスターをデュアルスタック IP (IPv4 と IPv6) 用に設定します。
  • 検証済みの物理ネットワーク設定は、2 つのデュアルポート NIC で構成されています。1 つの NIC は、プライマリー CNI (OVN-Kubernetes) と IPVLAN および MACVLAN トラフィック間で共有されます。もう 1 つの NIC は、SR-IOV VF ベースの Pod トラフィック専用です。
  • 2 つの NIC ポートがアタッチされたアクティブ/アクティブ IEEE 802.3ad LACP モードで、Linux ボンディングインターフェイス (bond0) を作成します。トップオブラックネットワーク機器は、マルチシャーシリンクアグリゲーション (mLAG) テクノロジーをサポートし、そのように設定されている必要があります。
  • VLAN インターフェイスは、プライマリー CNI を含め、bond0 の上に作成されます。
  • ボンディングおよび VLAN インターフェイスは、クラスターのインストール時に、インストールのネットワーク設定段階で作成されます。プライマリー CNI によって使用される VLAN (vlan0) を除き、他のすべての VLAN は、Kubernetes NMstate Operator を使用して Day 2 アクティビティー中に作成できます。
  • MACVLAN および IPVLAN インターフェイスは、対応する CNI を使用して作成されます。同じ基本インターフェイスを共有することはありません。詳細は、「Cluster Network Operator」を参照してください。
  • SR-IOV VF は SR-IOV Network Operator によって管理されます。
  • LoadBalancer サービスの背後にある Pod のソース IP アドレスの一貫性を確保するために、EgressIP CR を設定し、podSelector パラメーターを指定します。

  • 次の手順を実行することで、サービストラフィックの分離を実装できます。

    1. NodeNetworkConfigurationPolicy CR を使用して、ノード上の VLAN インターフェイスと特定のカーネル IP ルートを設定します。
    2. VLAN ごとに MetalLB BGPPeer CR を作成して、リモート BGP ルーターとのピアリングを確立します。

    3. MetalLB BGPAdvertisement CR を定義して、選択した BGPPeer リソースのリストにアドバタイズする IP アドレスプールを指定します。

      次の図は、特定のサービス IP アドレスを、特定の VLAN インターフェイスを介して外部にアドバタイズする方法を示しています。サービスルートは、BGPAdvertisement CR で定義され、IPAddressPool1 および BGPPeer1 フィールドの値を使用して設定されます。

図3.3 Telco コアリファレンス設計の MetalLB サービス分離

Telco コアリファレンス設計の MetalLB サービス分離

関連情報

3.7.3.1. Cluster Network Operator
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

Cluster Network Operator (CNO) は、クラスターのインストール中に、デフォルトの OVN-Kubernetes ネットワークプラグインを含むクラスターネットワークコンポーネントをデプロイおよび管理します。CNO を使用すると、プライマリーインターフェイスの MTU 設定、Pod の Egress にノードルーティングテーブルを使用するための OVN ゲートウェイモード、および MACVLAN などの追加のセカンダリーネットワークを設定できます。

ネットワークトラフィックの分離をサポートするために、CNO を通じて複数のネットワークインターフェイスが設定されます。これらのインターフェイスへのトラフィックステアリングは、NMState Operator を使用して適用される静的ルートを通じて設定されます。Pod トラフィックが適切にルーティングされるように、OVN-K は routingViaHost オプションを有効にして設定されます。この設定では、Pod の Egress トラフィックに OVN ではなくカーネルルーティングテーブルと適用された静的ルートを使用します。

Whereabouts CNI プラグインは、DHCP サーバーを使用せずに、追加の Pod ネットワークインターフェイスに動的な IPv4 および IPv6 アドレス指定を提供するために使用されます。

制限と要件
  • IPv6 サポートには OVN-Kubernetes が必要です。
  • 大規模 MTU クラスターをサポートするには、接続されたネットワーク機器を同じ値またはそれ以上の値に設定する必要があります。最大 8900 の MTU サイズがサポートされます。

  • MACVLAN と IPVLAN は、同じ基礎カーネルメカニズム、具体的には rx_handler に依存しているため、同じメインインターフェイス上に配置できません。このハンドラーを使用すると、ホストが受信パケットを処理する前にサードパーティーモジュールが受信パケットを処理できるようになります。このようなハンドラーは、ネットワークインターフェイスごとに 1 つだけ登録できます。MACVLAN と IPVLAN は両方とも、機能するために独自の rx_handler を登録する必要があるため、競合が発生し、同じインターフェイス上で共存することはできません。詳細はソースコードを確認してください。

  • 代替の NIC 設定としては、共有 NIC を複数の NIC に分割したり、単一のデュアルポート NIC を使用したりすることが考えられます。ただし、これらはテストおよび検証されていません。
  • シングルスタック IP 設定のクラスターは検証されていません。
  • Network CR の reachabilityTotalTimeoutSeconds パラメーターで、EgressIP ノードの到達可能性チェックの合計タイムアウトを秒単位で設定します。推奨値は 1 秒です。
エンジニアリングに関する考慮事項
  • Pod の Egress トラフィックは、routingViaHost オプションを使用してカーネルルーティングテーブルによって処理されます。ホストに適切な静的ルートを設定する必要があります。

関連情報

3.7.3.2. ロードバランサー
このリリースの変更点

  • FRR-K8s が Cluster Network Operator で利用できるようになりました。

    重要

    metallb-system namespace にカスタムの FRRConfiguration CR がある場合は、それを openshift-network-operator namespace に移動する必要があります。

説明
MetalLB は、標準ルーティングプロトコルを使用するベアメタル Kubernetes クラスターのロードバランサー実装です。これを使用すると、Kubernetes サービスが外部 IP アドレスを取得できます。この IP アドレスは、クラスターのホストネットワークにも追加されます。MetalLB Operator により、クラスターに MetalLB のインスタンスがデプロイされ、そのライフサイクルが管理されます。ユースケースによっては、ステートフルロードバランシングなど、MetalLB では利用できない機能が必要になる場合があります。必要に応じて、外部のサードパーティーロードバランサーを使用できます。外部ロードバランサーの選択と設定は、この仕様の範囲外です。外部のサードパーティーロードバランサーを使用する場合、統合作業の一環として十分な分析を実行し、パフォーマンスとリソース使用率の要件がすべて満たされていることを確認する必要があります。
制限と要件
  • ステートフルロードバランシングは MetalLB ではサポートされていません。これがワークロード CNF の要件である場合は、代替ロードバランサー実装を使用する必要があります。
  • 外部 IP アドレスがクライアントからクラスターのホストネットワークにルーティング可能であることを確認する必要があります。
エンジニアリングに関する考慮事項
  • MetalLB は、通信事業者コア使用モデルでは、BGP モードでのみ使用されます。
  • MetalLB は、通信事業者コア使用モデルでは、ローカルゲートウェイモードで使用される OVN-Kubernetes ネットワークプロバイダーでのみサポートされます。「Cluster Network Operator」の routingViaHost を参照してください。

  • MetalLB の BGP 設定は、ネットワークとピアの要件に応じて変化することが予想されます。

    • アドレス、アグリゲーション長、自動割り当てなどのバリエーションを使用してアドレスプールを設定できます。
    • MetalLB はルートのアナウンスにのみ BGP を使用します。このモードでは、transmitInterval および minimumTtl パラメーターのみが関連します。BFD プロファイル内の他のパラメーターは、デフォルトに近い値にしておく必要があります。値を短くすると、検出漏れが発生し、パフォーマンスに影響する可能性があるためです。

関連情報

3.7.3.3. SR-IOV
このリリースの変更点
  • クラスターホストでセキュアブートが有効になっている場合、SR-IOV Network Operator を使用して Mellanox NIC の Virtual Function を作成できるようになりました。Virtual Function を作成するには、まず Mellanox NIC のファームウェア設定をスキップし、ファームウェアで Virtual Function の数を手動で割り当ててから、システムをセキュアブートに切り替える必要があります。
説明
SR-IOV を使用すると、Physical Function (PF) を複数の Virtual Function (VF) に分割できます。その後、VF を複数の Pod に割り当てることで、Pod を分離したまま、より高いスループットパフォーマンスを実現できます。SR-IOV Network Operator は、SR-IOV CNI、ネットワークデバイスプラグイン、および SR-IOV スタックのその他のコンポーネントをプロビジョニングおよび管理します。
制限と要件
  • 特定のネットワークインターフェイスだけがサポートされています。詳細は、「サポートされるデバイス」を参照してください。
  • SR-IOV と IOMMU の有効化: SR-IOV Network Operator により、カーネルコマンドラインで IOMMU が自動的に有効化されます。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウンの検出が必要な場合は、プロトコルレベルで実行する必要があります。
  • MultiNetworkPolicy CR は、netdevice ネットワークにのみ適用できます。これは、vfio インターフェイスを管理できない iptables が実装で使用されるためです。
エンジニアリングに関する考慮事項
  • vfio モードの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーション用に追加のセカンダリーネットワークを有効にするために使用されます。
  • SriovOperatorConfig CR を明示的に作成する必要があります。この CR はリファレンス設定ポリシーに含まれているため、初期デプロイ時に作成されます。
  • UEFI セキュアブートまたはカーネルロックダウンを使用したファームウェア更新をサポートしていない NIC は、アプリケーションワークロードに必要な数の Virtual Function (VF) をサポートするために、十分な数の VF を有効にして事前設定する必要があります。Mellanox NIC の場合、SR-IOV Network Operator で Mellanox ベンダープラグインを無効にする必要があります。詳細は、「SR-IOV ネットワークデバイスの設定」を参照してください。
  • Pod の起動後に VF の MTU 値を変更する場合、SriovNetworkNodePolicy の MTU フィールドを設定しないでください。代わりに、Kubernetes NMState Operator を使用して、関連する PF の MTU を設定してください。

関連情報

3.7.3.4. NMState Operator
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Kubernetes NMState Operator は、クラスターノード全体でステートドリブンのネットワーク設定を実行するための Kubernetes API を提供します。これにより、ネットワークインターフェイス設定、静的 IP と DNS、VLAN、トランク、ボンディング、静的ルート、MTU、およびセカンダリーインターフェイスでの無差別モードの有効化が可能になります。クラスターノードは、各ノードのネットワークインターフェイスの状態を API サーバーに定期的に報告します。
制限と要件
該当なし
エンジニアリングに関する考慮事項
  • 初期ネットワーク設定は、インストール CR の NMStateConfig コンテンツを使用して適用されます。NMState Operator は、ネットワーク更新に必要な場合にのみ使用されます。
  • SR-IOV の Virtual Function がホストネットワークに使用される場合、NMState Operator (NodeNetworkConfigurationPolicy CR) を使用して、VLAN や MTU などの VF インターフェイスが設定されます。

関連情報

3.7.4. ロギング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Cluster Logging Operator を使用すると、リモートアーカイブと分析のために、ノードからログを収集して送信できます。リファレンス設定では、Kafka を使用して監査ログとインフラストラクチャーログをリモートアーカイブに送信します。
制限と要件
該当なし
エンジニアリングに関する考慮事項
  • クラスターの CPU 使用率の影響は、生成されるログの数またはサイズと、設定されたログフィルタリングの量によって決まります。
  • リファレンス設定には、アプリケーションログの送信は含まれていません。設定にアプリケーションログを含めるには、アプリケーションのロギングレートを評価し、予約セットに十分な追加の CPU リソースを割り当てる必要があります。

関連情報

3.7.5. 電源管理

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Performance Profile を使用して、高電力モード、低電力モード、または混合モードでクラスターを設定します。電源モードの選択は、クラスター上で実行しているワークロードの特性、特にレイテンシーに対する敏感さによって異なります。Pod ごとの電源管理 C ステート機能を使用して、低レイテンシー Pod の最大遅延を設定します。
制限と要件
  • 電源設定は、C ステートや P ステートの有効化など、適切な BIOS 設定に依存します。設定はハードウェアベンダーによって異なります。
エンジニアリングに関する考慮事項
  • レイテンシー: レイテンシーの影響を受けやすいワークロードが要件を満たせるように、高電力設定または Pod ごとの電源管理設定が必要です。Pod ごとの電源管理は、専用のピニングされた CPU を持つ Guaranteed QoS Pod でのみ使用できます。

関連情報

3.7.6. ストレージ

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

クラウドネイティブのストレージサービスは、Red Hat OpenShift Data Foundation またはその他のサードパーティーソリューションによって提供されます。

OpenShift Data Foundation は、コンテナー向けの Ceph ベースのソフトウェア定義ストレージソリューションです。ブロックストレージ、ファイルシステムストレージ、オンプレミスオブジェクトストレージを提供し、永続的および非永続的なデータ要件の両方に合わせて動的にプロビジョニングできます。通信事業者コアアプリケーションには永続的なストレージが必要です。

注記

すべてのストレージデータが転送中に暗号化されるとは限りません。リスクを軽減するには、ストレージネットワークを他のクラスターネットワークから分離します。ストレージネットワークは、他のクラスターネットワークからアクセス可能またはルーティング可能であってはなりません。ストレージネットワークに直接接続されているノードのみがストレージネットワークにアクセスできるようにする必要があります。

関連情報

3.7.6.1. Red Hat OpenShift Data Foundation
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Red Hat OpenShift Data Foundation は、コンテナー向けのソフトウェア定義ストレージサービスです。通信事業者コアクラスターの場合、ストレージサポートは、アプリケーションワークロードクラスターの外部で実行される OpenShift Data Foundation ストレージサービスによって提供されます。OpenShift Data Foundation は、セカンダリー CNI ネットワークを使用したストレージトラフィックの分離をサポートします。
制限と要件
  • IPv4/IPv6 デュアルスタックネットワーク環境では、OpenShift Data Foundation は IPv4 アドレスを使用します。詳細は、ネットワーク要件 を参照してください。
エンジニアリングに関する考慮事項
  • OpenShift Data Foundation ネットワークトラフィックは、VLAN 分離などを使用して、専用ネットワーク上の他のトラフィックから分離する必要があります。
3.7.6.2. 追加のストレージソリューション

他のストレージソリューションを使用して、通信事業者コアクラスターに永続的なストレージを提供することもできます。このソリューションの設定と統合は、リファレンス設計仕様 (RDS) の範囲外です。

ストレージソリューションを通信事業者コアクラスターに統合する場合は、適切なサイズ設定とパフォーマンス分析を行い、ストレージが全体的なパフォーマンスとリソース使用率の要件を満たしていることを確認する必要があります。

3.7.7. 通信事業者コアデプロイメントのコンポーネント

次のセクションでは、Red Hat Advanced Cluster Management (RHACM) を使用してハブクラスターを設定するために使用するさまざまな OpenShift Container Platform コンポーネントと設定を説明します。

3.7.7.1. Red Hat Advanced Cluster Management
このリリースの変更点
  • シングルノードの OpenShift クラスターの場合、イメージベースのインストールが推奨されるインストール方法です。
説明

Red Hat Advanced Cluster Management (RHACM) は、デプロイされたクラスターに対して、Multi Cluster Engine (MCE) のインストールと継続的な GitOps ZTP ライフサイクル管理を提供します。管理者は、メンテナンス期間中に Policy カスタムリソース (CR) をクラスターに適用することで、クラスターの設定とアップグレードを宣言的に管理します。

管理者は、Topology Aware Lifecycle Manager によって管理される RHACM ポリシーコントローラーを使用してポリシーを適用します。設定、アップグレード、およびクラスターのステータスは、ポリシーコントローラーを通じて管理されます。

マネージドクラスターをインストールすると、RHACM は、カスタムディスクパーティション分割、ロールの割り当て、マシン設定プールへの割り当てをサポートするために、個々のノードにラベルと初期イグニッション設定を適用します。これらの設定は、SiteConfig または ClusterInstance CR を使用して定義します。

制限と要件
エンジニアリングに関する考慮事項
  • インストール、サイト、またはデプロイメントごとに固有のコンテンツを持つ複数のクラスターを管理する場合は、RHACM ハブテンプレートを使用することを強く推奨します。RHACM ハブテンプレートを使用すると、インストールごとに固有の値を指定しながら、一貫したポリシーセットをクラスターに適用できます。

関連情報

3.7.7.2. Topology Aware Lifecycle Manager
このリリースの変更点
このリリースではリファレンス設計の更新はありません。
説明

Topology Aware Lifecycle Manager は、ハブクラスター上でのみ実行される Operator です。TALM は、クラスターや Operator のアップグレード、設定などの変更をネットワーク内のマネージドクラスターにどのようにデプロイするかを管理します。TALM には次のコア機能があります。

  • クラスターポリシーの定義に従って、クラスター設定とアップグレード (OpenShift Container Platform および Operator) を順次更新します。
  • クラスター更新の遅延適用を提供します。
  • ユーザーが設定可能なバッチで、クラスターのセットにポリシー更新を段階的にロールアウトできます。
  • ztp-done または同様のユーザー定義ラベルをクラスターに追加することで、クラスターごとのアクションを実行できます。
制限と要件
  • 400 個のバッチでクラスターを同時にデプロイできます。
エンジニアリングに関する考慮事項
  • クラスターの初期インストール中に、TALM によって ran.openshift.io/ztp-deploy-wave アノテーションが付いたポリシーのみが適用されます。
  • ユーザーが作成した ClusterGroupUpgrade CR の制御下で、TALM によって任意のポリシーを修正できます。

関連情報

3.7.7.3. GitOps Operator および GitOps ZTP プラグイン
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

GitOps Operator は、クラスターのデプロイメントと設定を管理するための GitOps 駆動型インフラストラクチャーを提供します。クラスターの定義と設定は Git リポジトリーで管理されます。

ZTP プラグインは、SiteConfig CR から Installation CR を生成し、RHACM の PolicyGenerator CR に基づいてポリシーに設定 CR を自動的にラップすることをサポートします。

SiteConfig Operator は、ClusterInstance CR からの Installation CR の生成に対するサポートを強化します。

重要

可能な場合は、GitOps ZTP プラグイン方式を使用した SiteConfig ではなく、ClusterInstance CR を使用してクラスターをインストールしてください。

必要なすべてのアーティファクト (SiteConfig、ClusterInstance、PolicyGenerator、PolicyGenTemplate、および補助的なリファレンス CR) を含めて、リリースバージョンに応じて Git リポジトリーを設定する必要があります。これにより、複数のバージョンの OpenShift プラットフォームと設定バージョンを同時に、またアップグレードを通じてクラスターにデプロイして管理できるようになります。

Git の構造に関しては、お客様またはパートナーが提供するコンテンツとは別のディレクトリーにリファレンス CR を保管することが推奨されます。これにより、既存のコンテンツを上書きするだけで参照の更新をインポートできます。お客様またはパートナーが提供する CR は、生成された設定ポリシーに簡単に組み込めるように、リファレンス CR と同じ階層のディレクトリーで提供できます。

制限と要件
  • 各 ArgoCD アプリケーションは最大 300 個のノードをサポートします。複数の ArgoCD アプリケーションを使用すると、1 つのハブクラスターでサポートされるクラスターの最大数を実現できます。

  • SiteConfig CR は、参照マニフェストを参照するために extraManifests.searchPaths フィールドを使用する必要があります。

    注記

    OpenShift Container Platform 4.15 以降、spec.extraManifestPath フィールドは非推奨になりました。

エンジニアリングに関する考慮事項

  • クラスターアップグレードのメンテナンス期間中に MachineConfigPool (mcp) CR の paused フィールドを true に設定し、maxUnavailable フィールドを最大許容値に設定します。これにより、アップグレード中に複数のクラスターノードが再起動されることがなくなり、全体的なアップグレード時間が短縮されます。mcp CR の一時停止を解除すると、すべての設定変更が 1 回の再起動で適用されます。

    注記

    インストール中にカスタムの mcp CR を一時停止し、maxUnavailable を 100% に設定すると、インストール時間を短縮できます。

  • コンテンツを更新するときに混乱や意図しない上書きを避けるために、core-overlay 配下の reference-crs/ ディレクトリーにあるカスタム CR と Git の追加マニフェストには、一意で区別できる名前を使用する必要があります。
  • SiteConfig CR では、複数の追加マニフェストパスが許可されます。複数のディレクトリーパスでファイル名が重複している場合は、ディレクトリー順序リストで最後に見つかったファイルが優先されます。

関連情報

3.7.7.4. モニタリング
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

OpenShift Container Platform には Cluster Monitoring Operator (CMO) がデフォルトで含まれています。CMO は、プラットフォームコンポーネントと、必要に応じてユーザープロジェクトのモニタリング (メトリクス、ダッシュボード、アラート) を提供します。管理者は、デフォルトのログ保持期間、カスタムアラートルールなどをカスタマイズできます。アップストリームの Kubernetes と cAdvisor に基づく、Pod の CPU およびメモリーメトリクスのデフォルト処理では、メトリクスの精度よりも古いデータを優先するというトレードオフが行われます。これによりレポートが急増し、ユーザーが指定したしきい値によっては、誤ったアラートが作成される可能性があります。OpenShift Container Platform は、オプトイン方式の Dedicated Service Monitor 機能をサポートしています。この機能は、上記のような動作の影響を受けない、Pod の CPU およびメモリーメトリクスの追加セットを作成するものです。詳細は、Dedicated Service Monitors - Questions and Answers (Red Hat ナレッジベース) を参照してください。

デフォルト設定に加えて、通信事業者コアクラスターには次のメトリクスが設定されることが予想されます。

  • ユーザーワークロードの Pod CPU とメモリーのメトリクスとアラート
制限と要件
  • Pod メトリクスを正確に表すには、Dedicated Service Monitor 機能を有効にする必要があります。
エンジニアリングに関する考慮事項
  • Prometheus の保持期間はユーザーによって指定されます。使用される値は、クラスター上の履歴データを維持するための運用要件と、CPU およびストレージリソースとの間のトレードオフです。保持期間が長くなると、ストレージの需要が増加し、データのインデックス管理に追加の CPU が必要になります。

関連情報

3.7.8. スケジューリング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

スケジューラーは、特定のワークロードに対して適切なノードを選択する役割を担うクラスター全体のコンポーネントです。これはプラットフォームの中核部分であり、一般的なデプロイメントシナリオでは特別な設定は必要ありません。次のセクションでは、いくつかの具体的な使用例について説明します。

NUMA 対応スケジューリングは、NUMA Resources Operator を通じて有効にできます。詳細は、「NUMA 対応ワークロードのスケジューリング」を参照してください。

制限と要件

  • デフォルトのスケジューラーはワークロードの NUMA 局所性を理解しません。ワーカーノード上のすべての空きリソースの合計のみを認識します。これにより、Topology Manager ポリシーが single-numa-node または restrict に設定されているノードにスケジュールされた場合に、ワークロードが拒否される可能性があります。詳細は、「Topology Manager ポリシー」を参照してください。

    • たとえば、6 つの CPU を要求する Pod があり、NUMA ノードごとに 4 つの CPU を持つ空のノードにスケジュールされているとします。ノードの割り当て可能な合計容量は 8 CPU です。スケジューラーは Pod を空のノードに配置します。各 NUMA ノードで使用できる CPU は 4 つしかないため、ノードのローカルアドミッションが失敗します。
  • 複数の NUMA ノードを持つすべてのクラスターでは、NUMA Resources Operator を使用する必要があります。詳細は、「NUMA Resources Operator のインストール」を参照してください。NUMA 対応スケジューリングが必要なすべてのノードを選択するには、KubeletConfig CR の machineConfigPoolSelector フィールドを使用します。
  • すべてのマシン設定プールに一貫したハードウェア設定を指定する必要があります。たとえば、すべてのノードに同じ NUMA ゾーン数を割り当てることが求められます。
エンジニアリングに関する考慮事項
  • Pod では、正しいスケジュールと分離のためにアノテーションが必要になる場合があります。アノテーションの詳細は、「CPU パーティショニングとパフォーマンスチューニング」を参照してください。
  • SriovNetworkNodePolicy CR の excludeTopology フィールドを使用して、スケジューリング中に SR-IOV Virtual Function NUMA アフィニティーを無視するように設定できます。

関連情報

Topology Manager ポリシー

3.7.9. ノード設定

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
制限と要件

  • 追加のカーネルモジュールを分析して、CPU 負荷、システムパフォーマンス、KPI を満たす能力への影響を判断してください。

    表3.1 追加のカーネルモジュール
    機能説明

    追加のカーネルモジュール

    MachineConfig CR を使用して次のカーネルモジュールをインストールし、CNF に拡張カーネル機能を提供します。

    • sctp
    • ip_gre
    • ip6_tables
    • ip6t_REJECT
    • ip6table_filter
    • ip6table_mangle
    • iptable_filter
    • iptable_mangle
    • iptable_nat
    • xt_multiport
    • xt_owner
    • xt_REDIRECT
    • xt_statistic
    • xt_TCPMSS

    コンテナーマウント namespace の非表示

    kubelet のハウスキーピングとエビクションモニタリングの頻度を減らして、CPU 使用量を削減します。kubelet/CRI-O に認識されるコンテナーマウント namespace を作成し、システムマウントスキャンのオーバーヘッドを削減します。

    Kdump の有効化

    任意の設定 (デフォルトで有効)

関連情報

3.7.10. ホストファームウェアとブートローダーの設定

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
エンジニアリングに関する考慮事項

  • 推奨される設定は、セキュアブートを有効にすることです。

    注記

    セキュアブートを有効にすると、署名されたカーネルモジュールのみがカーネルによってロードされます。ツリー外のドライバーはサポートされていません。

3.7.11. 非接続環境

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

通信事業者コアクラスターは、インターネットに直接アクセスできないネットワークにインストールされることが想定されています。クラスターのインストール、設定、および操作に必要なすべてのコンテナーイメージが、インターネット非接続環境のレジストリーで利用できる必要があります。これには、OpenShift Container Platform イメージ、Day 2 OLM Operator イメージ、アプリケーションワークロードイメージが含まれます。非接続環境を使用すると、次のような複数の利点が得られます。

  • セキュリティー - クラスターへのアクセスが制限されます。
  • キュレーションされたコンテンツ - クラスター用にキュレーションおよび承認された更新に基づいてレジストリーが作成されます。
制限と要件
  • すべてのカスタム CatalogSource リソースに一意の名前が必要です。デフォルトのカタログ名を再利用しないでください。
エンジニアリングに関する考慮事項
  • クラスターのインストール中に有効なタイムソースを設定する必要があります。

関連情報

3.7.12. Agent-based Installer

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

通信事業者コアクラスターは、Agent-based Installer を使用してインストールできます。この方法を使用すると、インストールを管理するための追加のサーバーや仮想マシンを必要とせずに、ベアメタルサーバーに OpenShift をインストールできます。Agent-based Installer は、任意のシステム (ラップトップなど) で動作し、ISO インストールイメージを生成できます。この ISO は、クラスターのスーパーバイザーノードのインストールメディアとして使用されます。インストールの進行状況は、スーパーバイザーノードの API インターフェイスにネットワーク接続できる任意のシステムから ABI ツールを使用して監視できます。

ABI は以下をサポートしています。

  • 宣言型 CR からのインストール
  • 非接続環境でのインストール
  • インストールを完了するために補助的な追加インストールや踏み台サーバーを必要としないインストール
制限と要件
  • 非接続のインストール環境では、インストールされたホストからアクセス可能なレジストリーが必要であり、必要なすべてのコンテンツがそのレジストリーにミラーリングされている必要があります。
エンジニアリングに関する考慮事項
  • ネットワーク設定は、インストール時に NMState 設定として適用する必要があります。NMState Operator を使用した Day 2 ネットワーク設定はサポートされていません。

関連情報

3.7.13. セキュリティー

このリリースの変更点
説明

通信事業者のお客様は、セキュリティーを重視しており、複数の攻撃ベクトルに対してクラスターを強化する必要があります。OpenShift Container Platform には、クラスターを保護する単一のコンポーネントや機能はありません。クラスターを保護するには、次のセキュリティー重視の機能と設定を使用します。

  • SecurityContextConstraints (SCC): すべてのワークロード Pod は、restricted-v2 または restricted SCC を使用して実行する必要があります。
  • Seccomp: すべての Pod は、RuntimeDefault (またはより強力な) seccomp プロファイルを使用して実行する必要があります。
  • ルートレス DPDK Pod: 多くのユーザープレーンネットワーキング (DPDK) CNF では、Pod を root 権限で実行する必要があります。この機能を使用すると、root 権限がなくても、要件に準拠した DPDK Pod を実行できます。ルートレス DPDK Pod は、ルートレス Pod 内にタップデバイスを作成し、DPDK アプリケーションからカーネルにトラフィックを挿入します。
  • ストレージ: ストレージネットワークは分離されており、他のクラスターネットワークにルーティングできないようにする必要があります。詳細は、「ストレージ」セクションを参照してください。

OpenShift クラスターノードでカスタム nftables ファイアウォールルールを実装するのに使用できる方法については、Custom nftable firewall rules in OpenShift を参照してください。この記事は、OpenShift 環境でネットワークセキュリティーポリシーの管理を担当するクラスター管理者を対象としています。この方法を導入する前に、次のような運用上の影響を慎重に検討することが重要です。

  • 早期適用: ルールは、ネットワークが完全に稼働する前の起動時に適用されます。ルールによって、ブートプロセス中に必要な重要なサービスが誤ってブロックされないように注意してください。
  • 設定ミスのリスク: カスタムルールに誤りがあると、意図しない結果が生じ、パフォーマンスに影響が出たり、正当なトラフィックがブロックされたり、ノードが分離される可能性があります。メインクラスターにルールをデプロイする前に、非実稼働環境でルールを十分にテストしてください。
  • 外部エンドポイント: OpenShift が機能するには外部エンドポイントへのアクセスが必要です。ファイアウォールの許可リストの詳細は、「OpenShift Container Platform のファイアウォールの設定」を参照してください。クラスターノードが外部エンドポイントにアクセスできることを確認してください。

  • ノードの再起動: node disruption policy が設定されていない限り、必要なファイアウォール設定で MachineConfig CR を適用すると、ノードが再起動します。この影響に注意して、それに応じてメンテナンス期間をスケジュールしてください。詳細は、「node disruption policy を使用してマシン設定の変更による停止を最小限に抑える」を参照してください。

    注記

    node disruption policy は、OpenShift Container Platform 4.17 以降で利用できます。

  • ネットワークフローマトリックス: Ingress トラフィックの管理の詳細は、「OpenShift Container Platform ネットワークフローマトリックス」を参照してください。Ingress トラフィックを重要なフローに制限して、ネットワークセキュリティーを強化できます。このマトリックスでは、ベースクラスターサービスに関する詳細情報が提供されていますが、Day-2 Operator によって生成されるトラフィックは対象外です。
  • クラスターバージョンの更新とアップグレード: OpenShift クラスターを更新またはアップグレードするときは注意してください。プラットフォームのファイアウォール要件に適用された最近の変更により、ネットワークポートの権限の調整が必要になる場合があります。ドキュメントにガイドラインが記載されていますが、この要件は今後変化する可能性があることに注意してください。システム停止を最小限に抑えるには、実稼働環境に適用する前に、ステージング環境で更新やアップグレードをテストする必要があります。これにより、ファイアウォール設定の変更に関連する潜在的な互換性の問題を特定して対処できるようになります。
制限と要件

  • ルートレス DPDK Pod には、次の追加設定が必要です。

    • タッププラグインの container_t SELinux コンテキストを設定します。
    • クラスターホストの container_use_devices SELinux ブール値を有効にします。
エンジニアリングに関する考慮事項
  • ルートレス DPDK Pod を使用するには、ホスト上で container_use_devices SELinux ブール値を有効にして、タップデバイスの作成を許可します。これにより、許容範囲内のセキュリティーリスクが発生します。

関連情報

3.7.14. スケーラビリティー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
ワークロードのスケーリングについては、「アプリケーションワークロード」で説明されています。
制限と要件
  • クラスターは少なくとも 120 ノードまで拡張できます。

3.8. 通信事業者コアリファレンス設定の CR

以下のカスタムリソース (CR) を使用して、通信事業者コアプロファイルを使用して OpenShift Container Platform クラスターを設定およびデプロイします。特に指定がない限り、CR を使用して、すべての特定の使用モデルで使用される共通のベースラインを形成します。

3.8.1. 通信事業者コアリファレンス設計の設定 CR の抽出

telco-core-rds-rhel9 コンテナーイメージから、通信事業者コアプロファイルのカスタムリソース (CR) の完全なセットを抽出できます。コンテナーイメージには、通信事業者コアプロファイルの必須の CR と任意の CR が含まれています。

前提条件

  • podman をインストールしている。

手順

  • 次のコマンドを実行して、telco-core-rds-rhel9 コンテナーイメージからコンテンツを抽出します。

    Copy to Clipboard Toggle word wrap 
    $ mkdir -p ./out
     Copy to Clipboard Toggle word wrap 
    $ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out

検証

  • out ディレクトリーのディレクトリー構造は次のとおりです。通信事業者コアの CR は、out/telco-core-rds/ ディレクトリーで確認できます。

    出力例

    Copy to Clipboard Toggle word wrap 
    out/
└── telco-core-rds
    ├── configuration
    │   └── reference-crs
    │       ├── optional
    │       │   ├── logging
    │       │   ├── networking
    │       │   │   └── multus
    │       │   │       └── tap_cni
    │       │   ├── other
    │       │   └── tuning
    │       └── required
    │           ├── networking
    │           │   ├── metallb
    │           │   ├── multinetworkpolicy
    │           │   └── sriov
    │           ├── other
    │           ├── performance
    │           ├── scheduling
    │           └── storage
    │               └── odf-external
    └── install

3.8.2. クラスターと通信事業者コアリファレンス設定の比較

通信事業者コアクラスターをデプロイした後、cluster-compare プラグインを使用して、クラスターが通信事業者コアリファレンス設計仕様 (RDS) に準拠しているかどうかを評価できます。cluster-compare プラグインは、OpenShift CLI (oc) のプラグインです。このプラグインは、通信事業者コアリファレンス設定を使用して、通信事業者コアカスタムリソース (CR) を使用するクラスターを検証します。

通信事業者コア用のプラグイン固有のリファレンス設定は、通信事業者コア CR とともにコンテナーイメージにパッケージ化されています。

cluster-compare プラグインの詳細は、「cluster-compare プラグインについて」を参照してください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • registry.redhat.io コンテナーイメージレジストリーにアクセスするための認証情報がある。
  • cluster-compare プラグインをインストールした。

手順

  1. 次のコマンドを実行して、認証情報を使用してコンテナーイメージレジストリーにログオンします。

    Copy to Clipboard Toggle word wrap 
    $ podman login registry.redhat.io

  2. 次のコマンドを実行して、telco-core-rds-rhel9 コンテナーイメージからコンテンツを抽出します。

    Copy to Clipboard Toggle word wrap 
    $ mkdir -p ./out
     Copy to Clipboard Toggle word wrap 
    $ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out

    リファレンス設定は、reference-crs-kube-compare/ ディレクトリーで確認できます。

    Copy to Clipboard Toggle word wrap 
    out/telco-core-rds/configuration/reference-crs-kube-compare/
├── metadata.yaml
    1 
    
├── optional
    2 
    
│   ├── logging
│   ├── networking
│   ├── other
│   └── tuning
└── required
    3 
    
    ├── networking
    ├── other
    ├── performance
    ├── scheduling
    └── storage
    1 1
    リファレンス設定用の設定ファイル。
    2
    任意のテンプレート用のディレクトリー。
    3
    必須のテンプレート用のディレクトリー。

  3. 次のコマンドを実行して、クラスターの設定を通信事業者コアリファレンス設定と比較します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    W1212 14:13:06.281590   36629 compare.go:425] Reference Contains Templates With Types (kind) Not Supported By Cluster: BFDProfile, BGPAdvertisement, BGPPeer, ClusterLogForwarder, Community, IPAddressPool, MetalLB, MultiNetworkPolicy, NMState, NUMAResourcesOperator, NUMAResourcesScheduler, NodeNetworkConfigurationPolicy, SriovNetwork, SriovNetworkNodePolicy, SriovOperatorConfig, StorageCluster

...

**********************************

Cluster CR: config.openshift.io/v1_OperatorHub_cluster
    1 
    
Reference File: required/other/operator-hub.yaml
    2 
    
Diff Output: diff -u -N /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster
--- /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
+++ /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
@@ -1,6 +1,6 @@
 apiVersion: config.openshift.io/v1
 kind: OperatorHub
 metadata:
+  annotations:
    3 
    
+    include.release.openshift.io/hypershift: "true"
   name: cluster
-spec:
-  disableAllDefaultSources: true

**********************************

Summary
    4 
    
CRs with diffs: 3/4
    5 
    
CRs in reference missing from the cluster: 22
    6 
    
other:
  other:
    Missing CRs:
    7 
    
    - optional/other/control-plane-load-kernel-modules.yaml
    - optional/other/worker-load-kernel-modules.yaml
required-networking:
  networking-root:
    Missing CRs:
    - required/networking/nodeNetworkConfigurationPolicy.yaml
  networking-sriov:
    Missing CRs:
    - required/networking/sriov/sriovNetwork.yaml
    - required/networking/sriov/sriovNetworkNodePolicy.yaml
    - required/networking/sriov/SriovOperatorConfig.yaml
    - required/networking/sriov/SriovSubscription.yaml
    - required/networking/sriov/SriovSubscriptionNS.yaml
    - required/networking/sriov/SriovSubscriptionOperGroup.yaml
required-other:
  scheduling:
    Missing CRs:
    - required/other/catalog-source.yaml
    - required/other/icsp.yaml
required-performance:
  performance:
    Missing CRs:
    - required/performance/PerformanceProfile.yaml
required-scheduling:
  scheduling:
    Missing CRs:
    - required/scheduling/nrop.yaml
    - required/scheduling/NROPSubscription.yaml
    - required/scheduling/NROPSubscriptionNS.yaml
    - required/scheduling/NROPSubscriptionOperGroup.yaml
    - required/scheduling/sched.yaml
required-storage:
  storage-odf:
    Missing CRs:
    - required/storage/odf-external/01-rook-ceph-external-cluster-details.secret.yaml
    - required/storage/odf-external/02-ocs-external-storagecluster.yaml
    - required/storage/odf-external/odfNS.yaml
    - required/storage/odf-external/odfOperGroup.yaml
    - required/storage/odf-external/odfSubscription.yaml
No CRs are unmatched to reference CRs
    8 
    
Metadata Hash: fe41066bac56517be02053d436c815661c9fa35eec5922af25a1be359818f297
    9 
    
No patched CRs
    10

    1
    比較対象の CR。プラグインにより、対応するテンプレートとの差異のある各 CR が表示されます。
    2
    比較対象の CR とマッチするテンプレート。
    3
    Linux diff 形式の出力に、テンプレートとクラスター CR の差異が表示されます。
    4
    プラグインにより、各 CR の行の差分が報告されます。その後、差分の概要が報告されます。
    5
    対応するテンプレートとの差異を比較した CR の数。
    6
    リファレンス設定に表されているが、ライブクラスターには存在しない CR の数。
    7
    リファレンス設定に表されているが、ライブクラスターには存在しない CR のリスト。
    8
    リファレンス設定内の対応するテンプレートとマッチしなかった CR。
    9
    メタデータハッシュはリファレンス設定を識別するものです。
    10
    パッチが適用された CR のリスト。

関連情報

3.8.3. ノード設定のリファレンス CR

表3.2 ノード設定 CR
コンポーネントリファレンス CR説明任意

追加のカーネルモジュール

control-plane-load-kernel-modules.yaml

オプション: コントロールプレーンノードのカーネルモジュールを設定します。

いいえ

追加のカーネルモジュール

sctp_module_mc.yaml

オプション: ワーカーノードに SCTP カーネルモジュールをロードします。

いいえ

追加のカーネルモジュール

worker-load-kernel-modules.yaml

オプション: ワーカーノードのカーネルモジュールを設定します。

いいえ

コンテナーマウント namespace の非表示

mount_namespace_config_master.yaml

コントロールプレーンノード上の kubelet と CRI-O 間でコンテナー固有のマウントを共有するためのマウント namespace を設定します。

いいえ

コンテナーマウント namespace の非表示

mount_namespace_config_worker.yaml

ワーカーノード上の kubelet と CRI-O 間でコンテナー固有のマウントを共有するためのマウント namespace を設定します。

いいえ

Kdump の有効化

kdump-master.yaml

マスターノードで kdump クラッシュレポートを設定します。

いいえ

Kdump の有効化

kdump-worker.yaml

ワーカーノードで kdump クラッシュレポートを設定します。

いいえ

3.8.4. リソースチューニングのリファレンス CR

表3.3 リソースチューニング CR
コンポーネントリファレンス CR説明任意

システム予約容量

control-plane-system-reserved.yaml

オプション: kubelet を設定して、コントロールプレーンノードプールの予約済みリソースの自動サイズ設定を有効にします。

いいえ

3.8.5. ネットワークのリファレンス CR

表3.4 ネットワーク CR
コンポーネントリファレンス CR説明任意

ベースライン

Network.yaml

デフォルトのクラスターネットワークを設定して、OVN Kubernetes 設定 (ホスト経由のルーティングなど) を指定します。また、カスタム CNI 設定を含む追加のネットワークの定義と、複数のネットワークを対象としたネットワークポリシーのために MultiNetworkPolicy CR を使用することを可能にします。

いいえ

ベースライン

networkAttachmentDefinition.yaml

オプション: ノードセレクターや CNI 設定などのネットワーク設定の詳細を指定する NetworkAttachmentDefinition リソースを定義します。

はい

ロードバランサー

addr-pool.yaml

指定範囲の IP の動的な割り当ての自動実行を有効にして IP アドレスプールを管理するように MetalLB を設定します。

いいえ

ロードバランサー

bfd-profile.yaml

カスタマイズされた間隔、検出乗数、およびモードを使用して双方向フォワーディング検出 (BFD) を設定し、ネットワーク障害の検出と負荷分散フェイルオーバーを迅速化します。

いいえ

ロードバランサー

bgp-advr.yaml

MetalLB の BGP アドバタイズメントリソースを定義し、IP アドレスプールを BGP ピアにアドバタイズする方法を指定します。これにより、トラフィックのルーティングと通知をきめ細かく制御できるようになります。

いいえ

ロードバランサー

bgp-peer.yaml

動的ルーティングの BGP ネイバーを表す、MetalLB 内の BGP ピアを定義します。

いいえ

ロードバランサー

community.yaml

名前付きリソースの下に 1 つ以上の BGP コミュニティーをグループ化する MetalLB コミュニティーを定義します。コミュニティーを BGP アドバタイズメントに適用すると、ルーティングポリシーを制御し、トラフィックルーティングを変更できます。

いいえ

ロードバランサー

metallb.yaml

クラスター内の MetalLB リソースを定義します。

いいえ

ロードバランサー

metallbNS.yaml

クラスター内の metallb-system namespace を定義します。

いいえ

ロードバランサー

metallbOperGroup.yaml

MetalLB Operator の Operator グループを定義します。

いいえ

ロードバランサー

metallbSubscription.yaml

インストールプランの手動承認を使用して、metallb Operator のサブスクリプションリソースを作成します。

いいえ

Multus - ルートレス DPDK Pod 用の Tap CNI

mc_rootless_pods_selinux.yaml

ワーカーノード上の TAP CNI プラグインに SELinux ブール値を設定する MachineConfig リソースを設定します。

はい

NMState Operator

NMState.yaml

NMState Operator がノードネットワーク設定を管理するために使用する NMState リソースを定義します。

いいえ

NMState Operator

NMStateNS.yaml

NMState Operator の namespace を作成します。

いいえ

NMState Operator

NMStateOperGroup.yaml

openshift-nmstate namespace に Operator グループを作成し、NMState Operator がリソースを監視および管理できるようにします。

いいえ

NMState Operator

NMStateSubscription.yaml

OLM を通じて管理される NMState Operator のサブスクリプションを作成します。

いいえ

SR-IOV Network Operator

sriovNetwork.yaml

ネットワーク機能、IP アドレス管理 (ipam)、および関連するネットワーク namespace およびリソースを指定して SR-IOV ネットワークを定義します。

いいえ

SR-IOV Network Operator

sriovNetworkNodePolicy.yaml

デバイス選択、VF の割り当て (numVfs)、ノード固有の設定 (nodeSelector)、優先度のカスタマイズなど、特定ノード上の SR-IOV デバイスのネットワークポリシーを設定します。

いいえ

SR-IOV Network Operator

SriovOperatorConfig.yaml

インジェクターと Operator Webhook の有効化、Pod のドレインの無効化、設定デーモンのノードセレクターの定義など、SR-IOV Operator のさまざまな設定を指定します。

いいえ

SR-IOV Network Operator

SriovSubscription.yaml

OLM を通じて管理される SR-IOV Network Operator のサブスクリプションを作成します。

いいえ

SR-IOV Network Operator

SriovSubscriptionNS.yaml

SR-IOV Network Operator サブスクリプションの namespace を作成します。

いいえ

SR-IOV Network Operator

SriovSubscriptionOperGroup.yaml

SR-IOV Network Operator の Operator グループを作成し、Operator がターゲット namespace 内のリソースを監視および管理できるようにします。

いいえ

3.8.6. スケジューリングのリファレンス CR

表3.5 CR のスケジューリング
コンポーネントリファレンス CR説明任意

NUMA 対応スケジューラー

nrop.yaml

NUMA Resources Operator を有効にして、ワークロードを特定の NUMA ノード設定に合わせて調整します。複数の NUMA ノードを持つクラスターに必要です。

いいえ

NUMA 対応スケジューラー

NROPSubscription.yaml

OLM を通じて管理される NUMA Resources Operator のサブスクリプションを作成します。複数の NUMA ノードを持つクラスターに必要です。

いいえ

NUMA 対応スケジューラー

NROPSubscriptionNS.yaml

NUMA Resources Operator のサブスクリプションの namespace を作成します。複数の NUMA ノードを持つクラスターに必要です。

いいえ

NUMA 対応スケジューラー

NROPSubscriptionOperGroup.yaml

numaresources-operator namespace に Operator グループを作成し、NUMA Resources Operator がリソースを監視および管理できるようにします。複数の NUMA ノードを持つクラスターに必要です。

いいえ

NUMA 対応スケジューラー

sched.yaml

ノード全体の Pod の NUMA 対応スケジューリングを処理できる、クラスター内のトポロジー対応スケジューラーを設定します。

いいえ

NUMA 対応スケジューラー

Scheduler.yaml

ワークロードに対してコントロールプレーンノードをスケジュール対象外として設定します。

いいえ

3.8.7. ストレージのリファレンス CR

表3.6 ストレージ CR
コンポーネントリファレンス CR説明任意

外部 ODF 設定

01-rook-ceph-external-cluster-details.secret.yaml

openshift-storage namespace 内の外部 Ceph クラスターの base64 エンコードされた設定データを含む Secret リソースを定義します。

いいえ

外部 ODF 設定

02-ocs-external-storagecluster.yaml

外部ストレージバックエンドを使用するようにクラスターを設定する OpenShift Container Storage (OCS) ストレージリソースを定義します。

いいえ

外部 ODF 設定

odfNS.yaml

OpenShift Data Foundation Operator の監視対象の openshift-storage namespace を作成します。

いいえ

外部 ODF 設定

odfOperGroup.yaml

openshift-storage namespace に Operator グループを作成し、OpenShift Data Foundation Operator がリソースを監視および管理できるようにします。

いいえ

外部 ODF 設定

odfSubscription.yaml

openshift-storage namespace に OpenShift Data Foundation Operator のサブスクリプションを作成します。

いいえ

3.9. 通信事業者コアリファレンス設計のソフトウェア仕様

Red Hat 通信事業者コア 4.18 ソリューションは、OpenShift Container Platform クラスター用の次の Red Hat ソフトウェア製品を使用して検証されています。

表3.7 通信事業者コアクラスターの検証済みソフトウェアコンポーネント
コンポーネントソフトウェアバージョン

Red Hat Advanced Cluster Management (RHACM)

2.121

Cluster Logging Operator

6.12

OpenShift Data Foundation

4.18

SR-IOV Network Operator

4.18

MetalLB

4.18

NMState Operator

4.18

NUMA 対応スケジューラー

4.18

[1] この表は、対応する RHACM バージョン 2.13 のリリース時に更新される予定です。

[2] この表は、対応する Cluster Logging Operator 6.2 のリリース時に更新される予定です。

第4章 通信事業者 RAN DU リファレンス設計仕様

通信事業者 RAN DU リファレンス設計仕様 (RDS) は、無線アクセスネットワーク (RAN) で 5G ワークロードをホストする、コモディティーハードウェア上で実行されるクラスターの設定を表したものです。テスト済みでサポート対象の推奨設定を記録したものであり、通信事業者 RAN DU プロファイルを実行するクラスターで、信頼性が高く再現性のあるパフォーマンスを実現します。

4.1. 通信事業者 RAN DU 5G デプロイメントのリファレンス設計仕様

Red Hat と認定パートナーは、OpenShift Container Platform 4.18 クラスター上で通信アプリケーションを実行するために必要なネットワークと運用機能に関する深い技術的専門知識とサポートを提供します。

Red Hat の通信パートナーは、エンタープライズ 5G ソリューション向けに大規模に複製できる、十分に統合され、十分にテストされた安定した環境を必要としています。通信事業者コアおよび RAN DU リファレンス設計仕様 (RDS) では、OpenShift Container Platform の特定のバージョンに基づいて推奨されるソリューションアーキテクチャーの概要が示されています。各 RDS は、通信事業者コアおよび RAN DU 使用モデル向けにテストおよび検証されたプラットフォーム設定を表したものです。RDS は、通信事業者の 5G コアと RAN DU の重要な KPI セットを定義することで、アプリケーションを実行する際の最適なエクスペリエンスを保証します。RDS に従うことで、重大度の高いエスカレーションが最小限に抑えられ、アプリケーションの安定性が向上します。

5G のユースケースは進化しており、ワークロードは継続的に変化しています。Red Hat は、お客様とパートナーからのフィードバックに基づいて、通信事業者コアと RAN DU RDS を継続的に改善し、要件の変化に対応することに取り組んでいます。

リファレンス設定には、ファーエッジクラスターとハブクラスターコンポーネントの設定が含まれています。

このドキュメントのリファレンス設定は、次の図に示すように、一元的に管理されるハブクラスターインフラストラクチャーを使用してデプロイされます。

図4.1 通信事業者 RAN DU デプロイメントアーキテクチャー

2 つの異なるネットワークファーエッジデプロイメントプロセスを示す図

4.2. リファレンス設計の範囲

通信事業者コアおよび通信事業者 RAN リファレンス設計仕様 (RDS) は、通信事業者コアおよび通信事業者 RAN プロファイルを実行するクラスターで信頼性が高く再現性のあるパフォーマンスを実現するために推奨され、テストされ、サポートされている設定をキャプチャーします。

各 RDS には、クラスターが個々のプロファイルを実行するために設計および検証された、リリースされた機能とサポートされている設定が含まれています。設定により、機能と KPI ターゲットを満たすベースラインの OpenShift Container Platform インストールが提供されます。各 RDS では、個々の設定ごとに予想される変動も説明します。各 RDS の検証には、長期間にわたる大規模なテストが多数含まれます。

注記

検証済みのリファレンス設定は、OpenShift Container Platform のメジャー Y-stream リリースごとに更新されます。Z-stream パッチリリースは、リファレンス設定に照らして定期的に再テストされます。

4.3. リファレンス設計からの逸脱

検証済みの通信事業者コアおよび通信事業者 RAN DU リファレンス設計仕様 (RDS) から逸脱すると、変更した特定のコンポーネントや機能を超えた大きな影響が生じる可能性があります。逸脱には、完全なソリューションのコンテキストでの分析とエンジニアリングが必要です。

重要

RDS からのすべての逸脱は、明確なアクション追跡情報とともに分析され、文書化される必要があります。パートナーには、逸脱をリファレンス設計に合わせる方法を理解するためのデューデリジェンスが求められます。これには、パートナーが Red Hat と連携して、プラットフォームでユースケースがクラス最高の結果を達成できるようにするための関連情報を提供することが必要になる場合があります。これは、ソリューションのサポート可能性と、Red Hat 全体およびパートナーとの整合性を確保するために重要です。

RDS からの逸脱は、次の結果の一部またはすべてを引き起こす可能性があります。

  • 問題の解決にはさらに時間がかかる場合があります。
  • プロジェクトのサービスレベル契約 (SLA)、プロジェクトの期限、エンドプロバイダーのパフォーマンス要件などが満たされないリスクがあります。

  • 承認されていない逸脱については、経営幹部レベルでのエスカレーションが必要になる場合があります。

    注記

    Red Hat は、パートナーのエンゲージメントの優先順位に基づいて、逸脱のリクエストへの対応を優先します。

4.4. RAN DU 使用モデルのエンジニアリングに関する考慮事項

RAN DU 使用モデルは、RAN 分散ユニット (DU) ワークロードをホストする、コモディティーハードウェア上で実行される OpenShift Container Platform クラスターを設定するものです。モデルおよびシステムレベルの考慮事項については、以下で説明します。個々のコンポーネントの具体的な制限、要件、およびエンジニアリングに関する考慮事項については、後のセクションで詳しく説明します。

注記

RAN DU の KPI テスト結果の詳細は、Telco RAN DU reference design specification KPI test results for OpenShift 4.18 を参照してください。この情報は顧客とパートナーのみが利用できます。

ワークロード
  • DU ワークロードについては、「通信事業者 RAN DU アプリケーションワークロード」で説明されています。
  • DU ワーカーノードは、最大のパフォーマンスが得られるようにチューニングされたホストファームウェアを備えた Intel 第 3 世代 Xeon (IceLake) 2.20 GHz 以上です。
リソース
システム内で実行中の Pod の最大数 (アプリケーションワークロードと OpenShift Container Platform Pod を含む) は 120 です。
リソース使用量

OpenShift Container Platform のリソース使用量は、以下のアプリケーションワークロードの特性など、さまざまな要因によって異なります。

  • Pod 数
  • プローブの種類と頻度
  • カーネルネットワークを使用したプライマリーまたはセカンダリー CNI のメッセージングレート
  • API アクセスレート
  • ロギングレート
  • ストレージ IOPS

リソース使用量は、次のように設定されたクラスターを対象に測定されます。

  1. クラスターは、シングルノードの OpenShift がインストールされた 1 台のホストです。
  2. クラスターは、「リファレンスアプリケーションワークロードの特性」で説明されている代表的なアプリケーションワークロードを実行します。
  3. クラスターは、「ハブクラスター管理の特性」で詳述されている制約下で管理されます。
  4. 使用モデル設定で "任意" と記載されているコンポーネントは対象外です。
注記

これらの基準を満たさない RAN DU RDS の範囲外の設定では、リソース使用量と KPI 目標の達成能力への影響を判断するために、追加の分析が必要です。これらの要件を満たすには、追加のクラスターリソースを割り当てる必要がある場合があります。

リファレンスアプリケーションワークロードの特性
  1. 管理および制御機能を含む vRAN アプリケーションに 15 個の Pod と 30 個のコンテナーを使用します。
  2. Pod あたり平均 2 つの ConfigMap CR と 4 つの Secret CR を使用します。
  3. 10 秒以上の頻度で最大 10 個の exec プローブを使用します。

  4. kube-apiserver のアプリケーション負荷増分は、クラスタープラットフォーム使用量の 10% 以下です。

    注記

    プラットフォームメトリクスから CPU 負荷を抽出できます。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    $ query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
  5. アプリケーションログはプラットフォームログコレクターによって収集されません。
  6. プライマリー CNI 上の総トラフィックは 8 Mbps 未満です。
ハブクラスター管理の特性

RHACM は推奨されるクラスター管理ソリューションであり、次の制限に従って設定されています。

  1. 基準に適合した評価間隔 (10 分以上) を使用する RHACM 設定ポリシーを最大 5 つ使用します。
  2. クラスターポリシーで、最小限の数 (最大 10 個) のマネージドクラスターテンプレートを使用します。ハブ側のテンプレーティングを使用します。
  3. policyController を除いて RHACM アドオンを無効にし、デフォルト設定で可観測性を設定します。

次の表に、リファレンスアプリケーションの負荷時のリソース使用量を示します。

表4.1 リファレンスアプリケーションの負荷時のリソース使用量
メトリクス制限注記

OpenShift プラットフォームの CPU 使用量

4000 mc 未満 - 2 コア (4HT)

プラットフォームの CPU は、各予約済みコアの両方のハイパースレッドを含む予約済みコアにピニングされます。このシステムは、定期的なシステムタスクとスパイクに対応できるように、安定状態で 3 つの CPU (3000 mc) を使用するように設計されています。

OpenShift プラットフォームのメモリー

16 G 未満

 

4.5. 通信事業者 RAN DU アプリケーションワークロード

次の要件と制限に準拠した RAN DU アプリケーションを開発します。

説明と制限
  • 最新バージョンの Red Hat best practices for Kubernetes に準拠したクラウドネイティブネットワーク機能 (CNF) を開発します。
  • 高性能ネットワークには SR-IOV を使用します。

  • exec プローブは、他に適切な選択肢がない場合にのみ、慎重に使用してください。

    • CNF が CPU ピニングを使用する場合は、exec プローブを使用しないでください。httpGet や tcpSocket などの他のプローブ実装を使用します。

    • exec プローブを使用する必要がある場合は、exec プローブの頻度と量を制限します。exec プローブの最大数は 10 未満に維持し、頻度は 10 秒以上にする必要があります。exec プローブはプロセスのフォークを必要とするため、他のプローブタイプと比較して管理コアの CPU 使用率が大幅に高くなります。

      注記

      起動プローブは、定常状態の動作中に最小限のリソースしか必要としません。exec プローブの制限は、主に liveness および readiness プローブに適用されます。

注記

この仕様で説明されているリファレンス DU アプリケーションワークロードのディメンションに準拠するテストワークロードは、openshift-kni/du-test-workloads にあります。

4.6. 通信事業者 RAN DU リファレンス設計のコンポーネント

以下のセクションでは、RAN DU ワークロードを実行するためにクラスターを設定およびデプロイするのに使用するさまざまな OpenShift Container Platform コンポーネントと設定を説明します。

図4.2 通信事業者 RAN DU リファレンス設計のコンポーネント

通信事業者 RAN DU リファレンス設計のコンポーネントを示す図
注記

通信事業者 RAN DU プロファイルで指定されていない追加コンポーネントが、ワークロードアプリケーションに割り当てられた CPU リソースに影響を与えないことを確認してください。

重要

ツリー外のドライバーはサポートされていません。5G RAN アプリケーションコンポーネントは、RAN DU プロファイルに含まれておらず、アプリケーションに割り当てられたリソース (CPU) に合わせて設計する必要があります。

4.6.1. ホストファームウェアのチューニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

初期クラスターデプロイメント中に最適なパフォーマンスが得られるようにホストファームウェア設定を調整します。詳細は、「vDU アプリケーションのワークロードに推奨されるシングルノード OpenShift クラスター設定」を参照してください。初期デプロイ時にホストファームウェアにチューニング設定を適用します。詳細は、「GitOps ZTP によるホストファームウェア設定の管理」を参照してください。マネージドクラスターホストのファームウェア設定は、ハブクラスターで個別の BareMetalHost カスタムリソース (CR) として使用できます。この CR は、ClusterInstance CR と GitOps ZTP を使用してマネージドクラスターをデプロイするときに作成されます。

注記

ClusterInstance CR は、指定のリファレンス CR example-sno.yaml に基づいて作成してください。

制限と要件
  • ホストファームウェア設定でハイパースレッディングを有効にする必要があります。
エンジニアリングに関する考慮事項
  • パフォーマンスを最大限に高めるために、すべてのファームウェア設定を調整します。
  • 省電力用に調整されていない限り、すべての設定は最大のパフォーマンスが得られるものと予想されます。
  • 必要に応じて、省電力用にパフォーマンスを犠牲にしてホストファームウェアを調整できます。
  • Secure Boot を有効にします。セキュアブートを有効にすると、署名されたカーネルモジュールのみがカーネルによってロードされます。ツリー外のドライバーはサポートされていません。

関連情報

4.6.2. CPU パーティショニングとパフォーマンスチューニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
RAN DU 使用モデルには、低レイテンシーのパフォーマンスを実現する PerformanceProfile CR によるクラスターパフォーマンスチューニングが含まれています。PerformanceProfile CR は、Node Tuning Operator によって調整されます。RAN DU ユースケースでは、低レイテンシーのパフォーマンスを実現するためにクラスターをチューニングする必要があります。PerformanceProfile CR を使用したノードのチューニングの詳細は、「パフォーマンスプロファイルによる低レイテンシーを実現するためのノードのチューニング」を参照してください。
制限と要件

Node Tuning Operator は、PerformanceProfile CR を使用してクラスターを設定します。通信事業者 RAN DU プロファイル PerformanceProfile CR で次の設定を指定する必要があります。

  • 次のいずれかの CPU に対して、4 つのハイパースレッド (2 コア) に相当する 4 つ以上の予約済み cpuset を設定します。

    • 最大のパフォーマンスが得られるようにチューニングされたホストファームウェアを備えた Intel 第 3 世代 Xeon (IceLake) 2.20 GHz 以上の CPU

    • AMD EPYC Zen 4 CPU (Genoa、Bergamo、またはそれ以降)

      注記

      AMD EPYC Zen 4 CPU (Genoa、Bergamo、またはそれ以降) は完全にサポートされています。現在、電力消費の評価が進められています。パフォーマンスへの潜在的な影響を判断するために、Pod ごとの電源管理などの機能を評価することを推奨します。

  • 予約済み cpuset を設定し、含まれる各コアの両方のハイパースレッドシブリングを含めます。予約されていないコアは、ワークロードのスケジュールに割り当て可能な CPU として使用できます。
  • ハイパースレッドシブリングが予約済みコアと分離されたコアに分割されていないことを確認します。
  • 予約済みおよび分離された CPU に、CPU 内の全コアの全スレッドが含まれていることを確認します。
  • 予約済み CPU セットに各 NUMA ノードの Core 0 を含めます。
  • huge page のサイズを 1G に設定します。
  • デフォルトで管理ワークロードパーティションの一部として設定されている OpenShift Container Platform Pod のみを予約済みコアにピニングします。
エンジニアリングに関する考慮事項
  • パフォーマンスメトリクスを完全に満たすには、RT カーネルを使用する必要があります。必要に応じて、パフォーマンスに相応の影響が及びますが、非 RT カーネルを使用することもできます。
  • 設定する huge page の数は、アプリケーションのワークロード要件によって異なります。このパラメーターの変動は予想され、許容されます。
  • 選択したハードウェアとシステムで使用されている追加コンポーネントに基づいて、予約済みおよび分離された CPU セットの設定が変更されることが予想されます。この変更が指定の制限を満たしている必要があります。
  • IRQ アフィニティーをサポートしていないハードウェアは、分離された CPU に影響します。CPU 全体が保証される QoS を持つ Pod で、割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートしている必要があります。
  • デプロイ時に cpuPartitioningMode を AllNodes に設定してワークロードパーティショニングを有効にする場合、PerformanceProfile CR でオペレーティングシステム、割り込み、および OpenShift Container Platform Pod をサポートするために十分な CPU を割り当てる必要があります。

関連情報

4.6.3. PTP Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
GPS によるグランドマスタークロック (T-GM) のサポート、通常クロック (OC)、境界クロック (T-BC)、デュアル境界クロック、高可用性 (HA)、HTTP 経由のオプションの高速イベント通知などの機能を使用して、RAN DU ユースケースの PTP を PTPConfig CR でクラスターノードに設定します。PTP は、RAN 環境において正確なタイミングと信頼性を確保します。
制限と要件
  • デュアル NIC と HA を備えたノードでは境界クロックが 2 つに制限されます。
  • T-GM の Westport Channel NIC 設定は 2 つに制限されます。
エンジニアリングに関する考慮事項
  • RAN DU RDS の設定は、通常クロック、境界クロック、グランドマスタークロック、および高可用性デュアル NIC 境界クロック用に提供されています。
  • PTP 高速イベント通知は、ConfigMap CR を使用してサブスクライバーの詳細を保持します。
  • O-RAN 仕様で説明されている階層型イベントサブスクリプションは、PTP イベントではサポートされていません。
  • PTP 高速イベント REST API v2 を使用します。PTP 高速イベント REST API v1 は非推奨になりました。REST API v2 は O-RAN Release 3 に準拠しています。

4.6.4. SR-IOV Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
SR-IOV Operator は、SR-IOV CNI およびデバイスプラグインをプロビジョニングおよび設定します。netdevice (カーネル VF) デバイスと vfio (DPDK) デバイスの両方がサポートされており、RAN DU 使用モデルに適用できます。
制限と要件
  • OpenShift Container Platform でサポートされているデバイスを使用します。「サポートされるデバイス」を参照してください。
  • ホストファームウェア設定での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウン検出が必要な場合は、プロトコルレベルでこれを設定する必要があります。
エンジニアリングに関する考慮事項
  • vfio ドライバータイプの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーションで追加のセカンダリーネットワークを有効にするために使用されます。
  • SriovNetwork および SriovNetworkNodePolicy カスタムリソース (CR) の設定と数は、顧客によって異なることが予想されます。
  • IOMMU カーネルのコマンドライン設定は、インストール時に MachineConfig CR で適用されます。これにより、SriovOperator CR がノードを追加するときにノードの再起動が発生しなくなります。
  • 並列でノードをドレインするための SR-IOV サポートは、シングルノードの OpenShift クラスターには適用されません。
  • デプロイメントに SriovOperatorConfig CR を含める必要があります。この CR は自動的に作成されません。この CR は、初期デプロイ時に適用されるリファレンス設定ポリシーに含まれています。
  • ワークロードを特定のノードにピニングまたは制限する場合、SR-IOV 並列ノードドレイン機能によって Pod の再スケジュールが行われません。このような場合、SR-IOV Operator によって並列ノードドレイン機能が無効化されます。
  • セキュアブートまたはカーネルロックダウン中のファームウェア更新をサポートしていない NIC は、アプリケーションワークロードに必要な Virtual Function (VF) の数をサポートするために十分な VF で事前に設定されている必要があります。Mellanox NIC の場合、SR-IOV Network Operator で Mellanox ベンダープラグインを無効にする必要があります。詳細は、「SR-IOV ネットワークデバイスの設定」を参照してください。

  • Pod の起動後に Virtual Function の MTU 値を変更する場合、SriovNetworkNodePolicy CR の MTU フィールドを設定しないでください。代わりに、Network Manager を設定するか、カスタムの systemd スクリプトを使用して、Physical Function の MTU を適切な値に設定します。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    # ip link set dev <physical_function> mtu 9000

関連情報

4.6.5. ロギング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
ロギングを使用して、リモート分析のためにファーエッジのノードからログを収集します。推奨されるログコレクターは Vector です。
エンジニアリングに関する考慮事項
  • たとえば、インフラストラクチャー以外のログや、アプリケーションワークロードからの監査ログを処理するには、ロギングレートの増加に応じて CPU とネットワーク帯域幅の追加が必要になります。
  • OpenShift Container Platform 4.14 以降では、Vector がリファレンスログコレクターです。RAN 使用モデルでの fluentd の使用は非推奨です。

関連情報

4.6.6. SRIOV-FEC Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
SRIOV-FEC Operator は、FEC アクセラレーターハードウェアをサポートするオプションのサードパーティー認定 Operator です。
制限と要件

  • FEC Operator v2.7.0 以降:

    • セキュアブートがサポートされています。
    • PF の vfio ドライバーでは、Pod に注入される vfio-token を使用する必要があります。Pod 内のアプリケーションは、EAL パラメーター --vfio-vf-token を使用して VF トークンを DPDK に渡すことができます。
エンジニアリングに関する考慮事項
  • SRIOV-FEC Operator は、分離された CPU セットの CPU コアを使用します。
  • たとえば、検証ポリシーを拡張することによって、アプリケーションデプロイメントの事前チェックの一部として FEC の準備を検証できます。

関連情報

4.6.7. Lifecycle Agent

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Lifecycle Agent は、シングルノードの OpenShift クラスターにローカルのライフサイクル管理サービスを提供します。
制限と要件
  • Lifecycle Agent は、マルチノードクラスターまたは追加のワーカーを持つシングルノードの OpenShift クラスターには適用されません。
  • Lifecycle Agent には、クラスターのインストール時に作成する永続ボリュームが必要です。パーティション要件の説明については、「GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定」を参照してください。

関連情報

4.6.8. Local Storage Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Local Storage Operator を使用して、アプリケーションで PVC リソースとして使用できる永続ボリュームを作成できます。作成する PV リソースの数とタイプは、要件によって異なります。
エンジニアリングに関する考慮事項
  • PV を作成する前に、PV CR のバッキングストレージを作成します。これは、パーティション、ローカルボリューム、LVM ボリューム、または完全なディスクにすることができます。
  • ディスクとパーティションが正しく割り当てられていることを確認するには、各デバイスへのアクセスに使用されるハードウェアパス別に LocalVolume CR 内のデバイスリストを参照します (例: /dev/disk/by-path/<id>)。論理名 (例: /dev/sda) は、ノードの再起動後も一貫性が保たれるとは限りません。

4.6.9. Logical Volume Manager Storage

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
論理ボリュームマネージャー (LVM) ストレージはオプションのコンポーネントです。アプリケーションが永続ボリューム要求 (PVC) リソースとして使用できる論理ボリュームをローカルデバイスから作成することにより、ブロックストレージとファイルストレージの両方の動的なプロビジョニングを提供します。ボリューム拡張やスナップショットも可能です。設定例は、RDS の StorageLVMCluster.yaml ファイルで提供されています。
制限と要件
  • シングルノードの OpenShift クラスターでは、永続ストレージは LVM ストレージまたはローカルストレージのいずれかによって提供される必要があり、両方によって提供される必要はありません。
  • ボリュームスナップショットはリファレンス設定から除外されます。
エンジニアリングに関する考慮事項
  • LVM Storage は、RAN DU ユースケースのローカルストレージ実装として使用できます。LVM Storage をストレージソリューションとして使用すると、Local Storage Operator が置き換えられ、必要な CPU がプラットフォームのオーバーヘッドとして管理パーティションに割り当てられます。リファレンス設定には、これらのストレージソリューションのいずれか 1 つを含める必要がありますが、両方を含めることはできません。
  • ストレージ要件を満たす十分なディスクまたはパーティションが利用可能であることを確認します。

4.6.10. ワークロードパーティショニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
ワークロードパーティショニングは、DU プロファイルに含まれる OpenShift Container Platform Pod と Day 2 Operator Pod を予約済み CPU セットにピニングし、予約済み CPU をノードの計算から除外します。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。ワークロードパーティショニングは、インストールパラメーターの機能セット cpuPartitioningMode: AllNodes によって有効化されます。管理パーティションコアのセットは、PerformanceProfile CR で設定する予約済み CPU セットを使用して設定されます。
制限と要件
  • Pod を管理パーティションに適用できるようにするには、Namespace と Pod CR にアノテーションを付ける必要がある
  • CPU 制限のある Pod をパーティションに割り当てることはできません。これは、ミューテーションによって Pod の QoS が変わる可能性があるためです。
  • 管理パーティションに割り当てることができる CPU の最小数の詳細は、「Node Tuning Operator」を参照してください。
エンジニアリングに関する考慮事項
  • ワークロードパーティショニングは、すべての管理 Pod を予約済みコアにピニングします。オペレーティングシステム、管理 Pod、およびワークロードの開始、ノードの再起動、またはその他のシステムイベントの発生時に発生する CPU 使用率の予想される急増を考慮して、予約セットに十分な数のコアを割り当てる必要があります。

関連情報

4.6.11. クラスターのチューニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
クラスター機能を使用して無効にできるコンポーネントの完全なリストについては、「クラスター機能」を参照してください。
制限と要件
  • インストーラーによるプロビジョニングのインストール方法では、クラスター機能は使用できません。
エンジニアリングに関する考慮事項

  • OpenShift Container Platform 4.16 以降を実行しているクラスターでは、PerformanceProfile が適用されても、クラスターは自動的に cgroup v1 に戻りません。クラスター上で実行されているワークロードに cgroup v1 が必要な場合は、クラスターを cgroup v1 用に設定する必要があります。詳細は、「Linux Control Group バージョン 1 (cgroup v1) の有効化」を参照してください。この設定は、クラスターの初期デプロイ中に行う必要があります。

    注記

    cgroup v1 のサポートは、OpenShift Container Platform 4.19 で削除される予定です。cgroup v1 を実行しているクラスターは cgroup v2 に移行する必要があります。

次の表に、必要なプラットフォームチューニング設定を示します。

表4.2 クラスター機能の設定
機能説明

オプションのクラスター機能を削除する

シングルノードの OpenShift クラスターでのみオプションのクラスター Operator を無効にすることで、OpenShift Container Platform のフットプリントを削減します。

  • Node Tuning Operator、Operator Lifecycle Manager、および Ingress Operator を除くすべてのオプションの Operator を削除します。

クラスター監視を設定する

次の手順を実行して、フットプリントを削減するようにモニタリングスタックを設定します。

  • ローカルの alertmanager コンポーネントおよび telemeter コンポーネントを無効にします。
  • RHACM の可観測性を使用する際、アラートをハブクラスターに転送するには、適切な additionalAlertManagerConfigs CR で CR を拡張する必要があります。

  • Prometheus の保持期間を 24 時間に短縮します。

    注記

    RHACM ハブクラスターは、マネージドクラスターメトリクスを集約します。

ネットワーク診断を無効にする

シングルノード OpenShift のネットワーク診断は必要ないため無効にします。

単一の OperatorHub カタログソースを設定する

RAN DU デプロイメントに必要な Operator のみを含む単一のカタログソースを使用するようにクラスターを設定します。各カタログソースにより、クラスター上の CPU 使用率が増加します。単一の CatalogSource を使用すると、プラットフォームの CPU 予算内に収まります。

Console Operator を無効にする

コンソールが無効になっている状態でクラスターがデプロイされた場合、Console CR (ConsoleOperatorDisable.yaml) は必要ありません。コンソールが有効になっている状態でクラスターがデプロイされた場合、Console CR を適用する必要があります。

関連情報

4.6.12. マシン設定

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
制限と要件
CRI-O ワイプ無効化 MachineConfig CR は、定義されたメンテナンス期間内のスケジュールされたメンテナンス時以外は、ディスク上のイメージが静的であると想定します。イメージが静的になるように、Pod の imagePullPolicy フィールドを Always に設定することは避けてください。
表4.3 マシン設定オプション
機能説明

コンテナーランタイム

すべてのノードロールのコンテナーランタイムを crun に設定します。

Kubelet 設定とコンテナーマウント namespace の非表示

kubelet のハウスキーピングとエビクションモニタリングの頻度を減らし、CPU 使用率を削減します。

SCTP

任意の設定 (デフォルトで有効)

Kdump

オプション設定 (デフォルトで有効): カーネルパニックが発生したときに kdump がデバッグ情報をキャプチャーできるようにします。kdump を有効にするリファレンス CR では、リファレンス設定に含まれるドライバーとカーネルモジュールのセットに基づいて、メモリー予約量が増加します。

CRI-O ワイプ無効化

不正なシャットダウン後の CRI-O イメージキャッシュの自動ワイプを無効にします。

SR-IOV 関連のカーネル引数

カーネルコマンドラインに SR-IOV 関連の引数を追加します。

RCU Normal の設定

システムの起動が完了した後に rcu_normal を設定する systemd サービス

ワンショット時間同期

コントロールプレーンまたはワーカーノードに対して 1 回限りの NTP システム時間同期ジョブを実行します。

関連情報

4.7. 通信事業者 RAN DU デプロイメントのコンポーネント

次のセクションでは、RHACM を使用してハブクラスターを設定するために使用するさまざまな OpenShift Container Platform コンポーネントと設定について説明します。

4.7.1. Red Hat Advanced Cluster Management

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

RHACM は、デプロイされたクラスターに対して、Multi Cluster Engine (MCE) のインストールと継続的なライフサイクル管理機能を提供します。管理者は、メンテナンス期間中に Policy カスタムリソース (CR) をクラスターに適用することで、クラスターの設定とアップグレードを宣言的に管理します。

RHACM は次の機能を提供します。

  • RHACM の MCE コンポーネントを使用したクラスターのゼロタッチプロビジョニング (ZTP)。
  • RHACM ポリシーコントローラーを介した設定、アップグレード、およびクラスターのステータス。
  • RHACM は、マネージドクラスターのインストール中に、ClusterInstance CR を通じて設定されたとおりに個々のノードにラベルを適用できます。

シングルノードの OpenShift クラスターの場合、推奨されるインストール方法は、MCE で利用できるイメージベースのインストーラー方式です。この方法では、クラスターの定義に ClusterInstance CR を使用します。

シングルノードの OpenShift クラスターの場合、推奨されるアップグレード方法は、イメージベースのアップグレード方法です。

制限と要件
  • 単一のハブクラスターは、各クラスターに 5 つの Policy CR がバインドされた、最大 3500 個のデプロイされたシングルノード OpenShift クラスターをサポートします。
エンジニアリングに関する考慮事項
  • RHACM ポリシーハブ側テンプレートを使用して、クラスター設定をより適切にスケーリングします。グループおよびクラスターごとの値がテンプレートに置き換えられる単一のグループポリシーまたは少数の一般的なグループポリシーを使用することで、ポリシーの数を大幅に削減できます。
  • クラスター固有の設定: マネージドクラスターには通常、個々のクラスターに固有の設定値がいくつかあります。これらの設定は、クラスター名に基づいて ConfigMap CR から取得された値を使用して、RHACM ポリシーハブ側テンプレートを使用して管理する必要があります。
  • マネージドクラスターの CPU リソースを節約するには、クラスターの GitOps ZTP インストール後に、静的設定を適用するポリシーをマネージドクラスターからアンバインドする必要があります。

関連情報

4.7.2. SiteConfig Operator

このリリースの変更点
  • このリリースでは RDS の更新はありません。
説明

SiteConfig Operator は、テンプレートを中心としたソリューションであり、さまざまなインストール方法でクラスターをプロビジョニングするように設計されています。この Operator は、非推奨の SiteConfig API に代わる統合された ClusterInstance API を導入します。SiteConfig Operator は ClusterInstance API を活用し、次の機能を提供することでクラスターのプロビジョニングを改善します。

  • 定義とインストール方法の分離の改善
  • Git ワークフローと非 Git ワークフローの統合
  • インストール方法を問わず一貫した API
  • スケーラビリティーの向上
  • カスタムインストールテンプレートによる柔軟性の向上
  • デプロイメントの問題のトラブルシューティングに役立つ詳細情報

SiteConfig Operator は、検証済みのデフォルトのインストールテンプレートを提供します。このテンプレートにより、Assisted Installer と Image-based Installer の両方のプロビジョニング方法で、クラスターのデプロイが容易になります。

  • Assisted Installer は、事前定義された設定と検証済みのホスト設定を活用して、OpenShift Container Platform クラスターのデプロイを自動化します。これにより、ターゲットインフラストラクチャーを OpenShift Container Platform の要件に確実に準拠させることができます。Assisted Installer は、手動セットアップに比べて時間と複雑さを最小限に抑えながらインストールプロセスを合理化します。
  • Image-based Installer は、事前設定および検証済みの OpenShift Container Platform シードイメージを利用して、シングルノード OpenShift クラスターのデプロイを迅速化します。シードイメージはターゲットホストにプリインストールされているため、迅速な再設定とデプロイが可能になります。Image-based Installer は、クラスターの作成プロセスを簡素化し、デプロイ時間を大幅に短縮するため、リモート環境や非接続環境に特に適しています。
制限と要件
  • 1 つのハブクラスターによってサポートされるのは、最大 3500 個のデプロイ済みシングルノード OpenShift クラスターです。

4.7.3. Topology Aware Lifecycle Manager

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

Topology Aware Lifecycle Manager は、ハブクラスター上でのみ実行され、クラスターのアップグレード、Operator のアップグレード、クラスター設定などの変更をネットワークにデプロイする方法を管理するための Operator です。TALM は次の機能をサポートしています。

  • ユーザーが設定可能なバッチで、クラスター群にポリシー更新を段階的にロールアウトします。
  • クラスターごとのアクションにより、マネージドクラスターの設定変更に従って、ztp-done ラベルまたはその他のユーザー設定可能なラベルを追加します。

  • シングルノード OpenShift クラスターイメージの事前キャッシュ: TALM は、アップグレードを開始する前に、OpenShift Container Platform、OLM Operator、および追加のユーザーイメージをシングルノード OpenShift クラスターに事前キャッシュするオプションをサポートしています。シングルノード OpenShift クラスターのアップグレードに推奨されるイメージベースのアップグレード方法を使用する場合、事前キャッシュ機能は適用されません。

    • オプションの事前キャッシュ設定は、PreCachingConfig CR を使用して指定します。詳細は、サンプルの PreCachingConfig リファレンス CR を参照してください。
    • 設定可能なフィルタリングにより未使用のイメージを除外します。
    • 設定可能な space-required パラメーターを使用して、事前キャッシュの前後のストレージ領域検証を有効にします。
制限と要件
  • 400 個のバッチでクラスターを同時にデプロイできます。
  • 事前キャッシュとバックアップは、シングルノード OpenShift クラスターのみを対象としています。
エンジニアリングに関する考慮事項
  • PreCachingConfig CR は任意です。プラットフォーム関連の OpenShift および OLM Operator イメージのみを事前キャッシュする必要がある場合、作成する必要はありません。
  • ClusterGroupUpgrade CR で参照する前に、PreCachingConfig CR を適用する必要があります。
  • クラスターのインストール中に、ran.openshift.io/ztp-deploy-wave アノテーションが付いたポリシーのみが TALM によって自動的に適用されます。
  • ユーザーが作成した ClusterGroupUpgrade CR の制御下で、TALM によって任意のポリシーを修正できます。

関連情報

4.7.4. GitOps Operator および GitOps ZTP

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

GitOps Operator と GitOps ZTP は、クラスターのデプロイメントと設定を管理するための GitOps ベースのインフラストラクチャーを提供します。クラスターの定義と設定は、Git で宣言的な状態として維持されます。ClusterInstance CR をハブクラスターに適用すると、SiteConfig Operator がそれをインストール CR としてレンダリングします。以前のリリースでは、GitOps ZTP プラグインは SiteConfig CR からのインストール CR の生成をサポートしていました。このプラグインは現在非推奨です。PolicyGenerator または PolicyGenTemplate CR に基づいて設定 CR をポリシーに自動的にラップできるようにする別の GitOps ZTP プラグインが利用可能です。

ベースラインリファレンス設定 CR を使用して、マネージドクラスターに OpenShift Container Platform の複数のバージョンをデプロイおよび管理できます。ベースライン CR と並行してカスタム CR を使用できます。複数のバージョンごとのポリシーを同時に維持するには、Git を使用して、PolicyGenerator または PolicyGenTemplate CR でソース CR とポリシー CR のバージョンを管理します。

制限と要件
  • ClusterInstance CR の数は、ArgoCD アプリケーションごとに 300 個です。複数のアプリケーションを使用すると、1 つのハブクラスターでサポートされるクラスターの最大数を実現できます。
  • Git の source-crs/ ディレクトリーの内容は、ZTP プラグインコンテナーで提供される内容よりも優先されます。検索パスで Git が優先されるためです。
  • source-crs/ ディレクトリーは、ジェネレーターとして PolicyGenerator または PolicyGenTemplate CR を含む kustomization.yaml ファイルと同じディレクトリーに配置することが明確に求められます。このコンテキストでは、source-crs/ ディレクトリーを別の場所に配置することはできません。
エンジニアリングに関する考慮事項
  • マルチノードクラスターのアップグレードの場合、paused フィールドを true に設定することで、メンテナンス期間中に MachineConfigPool (MCP) CR を一時停止できます。MCP CR で maxUnavailable 設定を指定することで、MCP CR ごとの同時に更新されるノードの数を増やすことができます。MaxUnavailable フィールドは、MachineConfig の更新中に同時に使用できなくなるプール内のノードのパーセンテージを定義します。maxUnavailable を最大許容値に設定します。これにより、アップグレード中にクラスター内で再起動する回数が減り、アップグレード時間が短縮されます。最終的に MCP CR の一時停止を解除すると、変更されたすべての設定が 1 回の再起動で適用されます。
  • クラスターのインストール中に、paused フィールドを true に設定し、maxUnavailable を 100% に設定することで、カスタムの MCP CR を一時停止し、インストール時間を短縮できます。

  • リファレンス CR とカスタム CR を別々のディレクトリーに保存してください。これを行うと、カスタム CR に触れることなく、ディレクトリーのすべてのコンテンツを簡単に置き換えるだけで、リファレンス CR にパッチを適用して更新できます。複数のバージョンを管理する場合は、次のベストプラクティスが推奨されます。

    • すべてのソース CR とポリシー作成 CR を Git リポジトリーに保存して、各 OpenShift Container Platform バージョンのポリシーが Git のコンテンツのみに基づいて一貫して生成されるようにします。
    • リファレンスソース CR をカスタム CR と別のディレクトリーに保存します。これにより、必要に応じてリファレンス CR を簡単に更新できるようになります。
  • コンテンツを更新する際の混乱や意図しない上書きを避けるため、source-crs/ ディレクトリー内のカスタム CR と Git 内の追加マニフェストには、一意で区別できる名前を使用することを強く推奨します。
  • 追加のインストールマニフェストは、ConfigMap CR を通じて ClusterInstance CR で参照されます。ConfigMap CR は、ClusterInstance CR とともに、クラスターの信頼できる唯一の情報源として機能する Git に保存する必要があります。必要に応じて、ConfigMap ジェネレーターを使用して ConfigMap CR を作成できます。

関連情報

4.7.5. Agent-based Installer

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
オプションの Agent-based Installer コンポーネントは、一元的なインフラストラクチャーなしでインストール機能を提供するものです。インストールプログラムは、サーバーにマウントする ISO イメージを作成します。サーバーが起動すると、OpenShift Container Platform と提供された追加のマニフェストがインストールされます。Agent-based Installer を使用すると、ハブクラスターなしで OpenShift Container Platform をインストールできます。クラスターのインストールにはコンテナーイメージレジストリーが必要です。
制限と要件
  • インストール時に、追加のマニフェストの限定されたセットを提供できます。
  • RAN DU ユースケースに必要な MachineConfiguration CR を含める必要があります。
エンジニアリングに関する考慮事項
  • Agent-based Installer は、ベースラインの OpenShift Container Platform インストールを提供します。
  • インストール後に、Day 2 Operator と残りの RAN DU ユースケース設定をインストールします。

関連情報

4.8. 通信事業者 RAN DU リファレンス設定の CR

次のカスタムリソース (CR) を使用して、通信事業者 RAN DU プロファイルを使用して OpenShift Container Platform クラスターを設定およびデプロイします。特に指定がない限り、CR を使用して、すべての特定の使用モデルで使用される共通のベースラインを形成します。

注記

ztp-site-generate コンテナーイメージから RAN DU CR の完全なセットを抽出できます。詳細は、GitOps ZTP サイト設定リポジトリーの準備 を参照してください。

4.8.1. クラスターチューニングのリファレンス CR

表4.4 クラスターチューニング CR
コンポーネントリファレンス CR説明任意

クラスター機能

example-sno.yaml

RAN DU プロファイルを使用してシングルノード OpenShift をインストールするための代表的な SiteConfig CR

いいえ

コンソールの無効化

ConsoleOperatorDisable.yaml

Console Operator を無効にします。

いいえ

非接続レジストリー

09-openshift-marketplace-ns.yaml

OpenShift Operator Marketplace を管理するための専用の namespace を定義します。

いいえ

非接続レジストリー

DefaultCatsrc.yaml

非接続レジストリーのカタログソースを設定します。

いいえ

非接続レジストリー

DisableOLMPprof.yaml

OLM のパフォーマンスプロファイリングを無効にします。

いいえ

非接続レジストリー

DisconnectedICSP.yaml

非接続レジストリーのイメージコンテンツソースポリシーを設定します。

いいえ

非接続レジストリー

OperatorHub.yaml

任意。マルチノードクラスターの場合のみ。OpenShift で OperatorHub を設定し、すべてのデフォルトの Operator ソースを無効にします。マーケットプレイス機能が無効になっているシングルノード OpenShift のインストールでは必要ありません。

いいえ

モニタリング設定

ReduceMonitoringFootprint.yaml

Alertmanager と Telemeter を無効にしてモニタリングフットプリントを削減し、Prometheus の保持時間を 24 時間に設定します。

いいえ

ネットワーク診断の無効化

DisableSnoNetworkDiag.yaml

クラスターネットワーク設定を指定して、組み込みのネットワークトラブルシューティングおよび診断機能を無効にします。

いいえ

4.8.2. Day 2 Operator のリファレンス CR

表4.5 Day 2 の Operator CR
コンポーネントリファレンス CR説明任意

Cluster Logging Operator

ClusterLogForwarder.yaml

クラスターのログ転送を設定します。

いいえ

Cluster Logging Operator

ClusterLogNS.yaml

クラスターロギングの namespace を設定します。

いいえ

Cluster Logging Operator

ClusterLogOperGroup.yaml

クラスターロギングの Operator グループを設定します。

いいえ

Cluster Logging Operator

ClusterLogServiceAccount.yaml

4.18 で追加されました。クラスターロギングのサービスアカウントを設定します。

いいえ

Cluster Logging Operator

ClusterLogServiceAccountAuditBinding.yaml

4.18 で追加されました。クラスターロギングのサービスアカウントを設定します。

いいえ

Cluster Logging Operator

ClusterLogServiceAccountInfrastructureBinding.yaml

4.18 で追加されました。クラスターロギングのサービスアカウントを設定します。

いいえ

Cluster Logging Operator

ClusterLogSubscription.yaml

Cluster Logging Operator のインストールと更新を管理します。

いいえ

Lifecycle Agent

ImageBasedUpgrade.yaml

OpenShift のイメージベースのアップグレードプロセスを管理します。

はい

Lifecycle Agent

LcaSubscription.yaml

LCA Operator のインストールと更新を管理します。

はい

Lifecycle Agent

LcaSubscriptionNS.yaml

LCA サブスクリプションの namespace を設定します。

はい

Lifecycle Agent

LcaSubscriptionOperGroup.yaml

LCA サブスクリプションの Operator グループを設定します。

はい

Local Storage Operator

StorageClass.yaml

Delete 回収ポリシーを使用し、クラスター内で動的プロビジョニングを行わないストレージクラスを定義します。

いいえ

Local Storage Operator

StorageLV.yaml

デバイスパスとファイルシステムタイプを指定して、openshift-local-storage namespace の example-storage-class のローカルストレージデバイスを設定します。

いいえ

Local Storage Operator

StorageNS.yaml

ワークロード管理とデプロイメントウェーブのアノテーションを使用して、Local Storage Operator の namespace を作成します。

いいえ

Local Storage Operator

StorageOperGroup.yaml

Local Storage Operator の Operator グループを作成します。

いいえ

Local Storage Operator

StorageSubscription.yaml

ワークロード管理とデプロイメントウェーブのアノテーションを使用して、Local Storage Operator の namespace を作成します。

いいえ

LVM Operator

LVMOperatorStatus.yaml

LVM Storage Operator のインストールまたはアップグレードを検証します。

はい

LVM Operator

StorageLVMCluster.yaml

ストレージデバイスクラスとボリュームグループ設定のプレースホルダーを使用して、LVM クラスター設定を定義します。必要な場合に Local Storage Operator の代替となります。

いいえ

LVM Operator

StorageLVMSubscription.yaml

LVMS Operator のインストールと更新を管理します。必要な場合に Local Storage Operator の代替となります。

いいえ

LVM Operator

StorageLVMSubscriptionNS.yaml

クラスター監視とワークロード管理のためのラベルとアノテーションを使用して、LVMS Operator の namespace を作成します。必要な場合に Local Storage Operator の代替となります。

いいえ

LVM Operator

StorageLVMSubscriptionOperGroup.yaml

LVMS Operator のターゲット namespace を定義します。必要な場合に Local Storage Operator の代替となります。

いいえ

Node Tuning Operator

PerformanceProfile.yaml

OpenShift クラスター内のノードパフォーマンス設定を指定し、低レイテンシーとリアルタイムのワークロードを最適化します。

いいえ

Node Tuning Operator

TunedPerformancePatch.yaml

特定 namespace 内のノードのスケジューラーグループやサービス設定などのパフォーマンスチューニング設定を適用します。

いいえ

PTP 高速イベント通知

PtpConfigBoundaryForEvent.yaml

イベント同期の追加オプションを使用して、PTP 境界クロックの PTP 設定を指定します。クラスターのロールに依存します。

いいえ

PTP 高速イベント通知

PtpConfigForHAForEvent.yaml

追加の PTP 高速イベント設定を使用して、高可用性境界クロックの PTP を設定します。クラスターのロールに依存します。

いいえ

PTP 高速イベント通知

PtpConfigMasterForEvent.yaml

追加の PTP 高速イベント設定を使用して、PTP グランドマスタークロックの PTP を設定します。クラスターのロールに依存します。

いいえ

PTP 高速イベント通知

PtpConfigSlaveForEvent.yaml

追加の PTP 高速イベント設定を使用して、PTP 通常クロックの PTP を設定します。クラスターのロールに依存します。

いいえ

PTP 高速イベント通知

PtpOperatorConfigForEvent.yaml

デフォルトの OperatorConfig をオーバーライドします。openshift-ptp namespace で PTP デーモンを実行するためのノード選択基準を指定して、PTP Operator を設定します。

いいえ

PTP Operator

PtpConfigBoundary.yaml

PTP 境界クロックの PTP 設定を指定します。クラスターのロールに依存します。

いいえ

PTP Operator

PtpConfigDualCardGmWpc.yaml

デュアル NIC を持つホストの PTP グランドマスタークロック設定を指定します。クラスターのロールに依存します。

いいえ

PTP Operator

PtpConfigGmWpc.yaml

単一の NIC を持つホストの PTP グランドマスタークロック設定を指定します。クラスターのロールに依存します。

いいえ

PTP Operator

PtpConfigSlave.yaml

PTP 通常クロックの PTP 設定を指定します。クラスターのロールに依存します。

いいえ

PTP Operator

PtpOperatorConfig.yaml

openshift-ptp namespace で PTP デーモンを実行するためのノード選択基準を指定して、PTP Operator 設定を指定します。

いいえ

PTP Operator

PtpSubscription.yaml

openshift-ptp namespace の PTP Operator のインストールと更新を管理します。

いいえ

PTP Operator

PtpSubscriptionNS.yaml

PTP Operator の namespace を設定します。

いいえ

PTP Operator

PtpSubscriptionOperGroup.yaml

PTP Operator の Operator グループを設定します。

いいえ

PTP Operator (高可用性)

PtpConfigBoundary.yaml

高可用性 PTP 境界クロックの PTP 設定を指定します。

いいえ

PTP Operator (高可用性)

PtpConfigForHA.yaml

高可用性 PTP 境界クロックの PTP 設定を指定します。

いいえ

SR-IOV FEC Operator

AcceleratorsNS.yaml

VRAN Acceleration Operator の namespace を設定します。アプリケーションワークロードのオプション部分です。

はい

SR-IOV FEC Operator

AcceleratorsOperGroup.yaml

VRAN Acceleration Operator の Operator グループを設定します。アプリケーションワークロードのオプション部分です。

はい

SR-IOV FEC Operator

AcceleratorsSubscription.yaml

VRAN Acceleration Operator のインストールと更新を管理します。アプリケーションワークロードのオプション部分です。

はい

SR-IOV FEC Operator

SriovFecClusterConfig.yaml

ドライバー、VF の数、およびノード選択を指定して、ノードの SR-IOV FPGA Ethernet Controller (FEC) 設定を指定します。

はい

SR-IOV Operator

SriovNetwork.yaml

さまざまなネットワーク設定のプレースホルダーを使用して、SR-IOV ネットワーク設定を定義します。

いいえ

SR-IOV Operator

SriovNetworkNodePolicy.yaml

デバイスタイプ、RDMA サポート、Physical Function 名、Virtual Function の数など、特定のノードの SR-IOV ネットワーク設定を指定します。

いいえ

SR-IOV Operator

SriovOperatorConfig.yaml

ノード選択、インジェクター、Webhook オプションなどの SR-IOV Network Operator 設定を指定します。

いいえ

SR-IOV Operator

SriovOperatorConfigForSNO.yaml

openshift-sriov-network-operator namespace で、ノード選択、インジェクター、Webhook オプション、ノードドレインの無効化など、シングルノード OpenShift の SR-IOV Network Operator 設定を指定します。

いいえ

SR-IOV Operator

SriovSubscription.yaml

SR-IOV Network Operator のインストールと更新を管理します。

いいえ

SR-IOV Operator

SriovSubscriptionNS.yaml

ワークロード管理とデプロイメントウェーブの特定のアノテーションを使用して、SR-IOV Network Operator の namespace を作成します。

いいえ

SR-IOV Operator

SriovSubscriptionOperGroup.yaml

SR-IOV Network Operator のターゲット namespace を定義し、この namespace 内での管理とデプロイを可能にします。

いいえ

4.8.3. マシン設定のリファレンス CR

表4.6 マシン設定の CR
コンポーネントリファレンス CR説明任意

コンテナーランタイム (crun)

enable-crun-master.yaml

コントロールプレーンノードのコンテナーランタイム (crun) を設定します。

いいえ

コンテナーランタイム (crun)

enable-crun-worker.yaml

ワーカーノードのコンテナーランタイム (crun) を設定します。

いいえ

CRI-O ワイプ無効化

99-crio-disable-wipe-master.yaml

コントロールプレーンノード再起動後の CRI-O キャッシュ自動ワイプを無効にします。

いいえ

CRI-O ワイプ無効化

99-crio-disable-wipe-worker.yaml

ワーカーノード再起動後の CRI-O キャッシュ自動ワイプを無効にします。

いいえ

Kdump の有効化

06-kdump-master.yaml

マスターノードで kdump クラッシュレポートを設定します。

いいえ

Kdump の有効化

06-kdump-worker.yaml

ワーカーノードで kdump クラッシュレポートを設定します。

いいえ

Kubelet の設定とコンテナーマウントの非表示

01-container-mount-ns-and-kubelet-conf-master.yaml

コントロールプレーンノード上の kubelet と CRI-O 間でコンテナー固有のマウントを共有するためのマウント namespace を設定します。

いいえ

Kubelet の設定とコンテナーマウントの非表示

01-container-mount-ns-and-kubelet-conf-worker.yaml

ワーカーノード上の kubelet と CRI-O 間でコンテナー固有のマウントを共有するためのマウント namespace を設定します。

いいえ

ワンショット時間同期

99-sync-time-once-master.yaml

マスターノードで時間を一度同期します。

いいえ

ワンショット時間同期

99-sync-time-once-worker.yaml

ワーカーノードで時間を一度同期します。

いいえ

SCTP

03-sctp-machine-config-master.yaml

マスターノードに SCTP カーネルモジュールをロードします。

はい

SCTP

03-sctp-machine-config-worker.yaml

ワーカーノードに SCTP カーネルモジュールをロードします。

はい

RCU normal の設定

08-set-rcu-normal-master.yaml

コントロールプレーンノードが起動した後、rcu_normal を設定して rcu_expedited を無効にします。

いいえ

RCU normal の設定

08-set-rcu-normal-worker.yaml

ワーカーノードが起動した後、rcu_normal を設定して rcu_expedited を無効にします。

いいえ

SRIOV 関連のカーネル引数

07-sriov-related-kernel-args-master.yaml

マスターノードで SR-IOV サポートを有効にします。

いいえ

4.9. クラスターと通信事業者 RAN DU リファレンス設定の比較

通信事業者 RAN DU クラスターをデプロイした後、cluster-compare プラグインを使用して、クラスターが通信事業者 RAN DU リファレンス設計仕様 (RDS) に準拠しているかどうかを評価できます。cluster-compare プラグインは、OpenShift CLI (oc) のプラグインです。このプラグインは、通信事業者 RAN DU リファレンス設定を使用して、通信事業者 RAN DU カスタムリソース (CR) を使用するクラスターを検証します。

プラグイン固有の通信事業者 RAN DU リファレンス設定は、通信事業者 RAN DU CR とともにコンテナーイメージにパッケージ化されています。

cluster-compare プラグインの詳細は、「cluster-compare プラグインについて」を参照してください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • registry.redhat.io コンテナーイメージレジストリーにアクセスするための認証情報がある。
  • cluster-compare プラグインをインストールした。

手順

  1. 次のコマンドを実行して、認証情報を使用してコンテナーイメージレジストリーにログオンします。

    Copy to Clipboard Toggle word wrap 
    $ podman login registry.redhat.io

  2. 次のコマンドを実行して、ztp-site-generate-rhel8 コンテナーイメージからコンテンツを抽出します。

    Copy to Clipboard Toggle word wrap 
    $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18
     Copy to Clipboard Toggle word wrap 
    $ mkdir -p ./out
     Copy to Clipboard Toggle word wrap 
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.18 extract /home/ztp --tar | tar x -C ./out

  3. 次のコマンドを実行して、クラスターの設定をリファレンス設定と比較します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r out/reference/metadata.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    ...

**********************************

Cluster CR: config.openshift.io/v1_OperatorHub_cluster
    1 
    
Reference File: required/other/operator-hub.yaml
    2 
    
Diff Output: diff -u -N /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster
--- /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
+++ /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
@@ -1,6 +1,6 @@
 apiVersion: config.openshift.io/v1
 kind: OperatorHub
 metadata:
+  annotations:
    3 
    
+    include.release.openshift.io/hypershift: "true"
   name: cluster
-spec:
-  disableAllDefaultSources: true

**********************************

Summary
    4 
    
CRs with diffs: 11/12
    5 
    
CRs in reference missing from the cluster: 40
    6 
    
optional-image-registry:
  image-registry:
    Missing CRs:
    7 
    
    - optional/image-registry/ImageRegistryPV.yaml
optional-ptp-config:
  ptp-config:
    One of the following is required:
    - optional/ptp-config/PtpConfigBoundary.yaml
    - optional/ptp-config/PtpConfigGmWpc.yaml
    - optional/ptp-config/PtpConfigDualCardGmWpc.yaml
    - optional/ptp-config/PtpConfigForHA.yaml
    - optional/ptp-config/PtpConfigMaster.yaml
    - optional/ptp-config/PtpConfigSlave.yaml
    - optional/ptp-config/PtpConfigSlaveForEvent.yaml
    - optional/ptp-config/PtpConfigForHAForEvent.yaml
    - optional/ptp-config/PtpConfigMasterForEvent.yaml
    - optional/ptp-config/PtpConfigBoundaryForEvent.yaml
  ptp-operator-config:
    One of the following is required:
    - optional/ptp-config/PtpOperatorConfig.yaml
    - optional/ptp-config/PtpOperatorConfigForEvent.yaml
optional-storage:
  storage:
    Missing CRs:
    - optional/local-storage-operator/StorageLV.yaml

...

No CRs are unmatched to reference CRs
    8 
    
Metadata Hash: 09650c31212be9a44b99315ec14d2e7715ee194a5d68fb6d24f65fd5ddbe3c3c
    9 
    
No patched CRs
    10

    1
    比較対象の CR。プラグインにより、対応するテンプレートとの差異のある各 CR が表示されます。
    2
    比較対象の CR とマッチするテンプレート。
    3
    Linux diff 形式の出力に、テンプレートとクラスター CR の差異が表示されます。
    4
    プラグインにより、各 CR の行の差分が報告されます。その後、差分の概要が報告されます。
    5
    対応するテンプレートとの差異を比較した CR の数。
    6
    リファレンス設定に表されているが、ライブクラスターには存在しない CR の数。
    7
    リファレンス設定に表されているが、ライブクラスターには存在しない CR のリスト。
    8
    リファレンス設定内の対応するテンプレートとマッチしなかった CR。
    9
    メタデータハッシュはリファレンス設定を識別するものです。
    10
    パッチが適用された CR のリスト。

関連情報

4.10. Telco RAN DU 4.18 の検証済みソフトウェアコンポーネント

Red Hat telco RAN DU 4.18 ソリューションは、OpenShift Container Platform 管理クラスター用の次の Red Hat ソフトウェア製品を使用して検証されています。

表4.7 Telco RAN DU マネージドクラスターの検証済みソフトウェアコンポーネント
コンポーネントソフトウェアバージョン

マネージドクラスターのバージョン

4.18

Cluster Logging Operator

6.11

Local Storage Operator

4.18

OpenShift API for Data Protection (OADP)

1.4

PTP Operator

4.18

SR-IOV Operator

4.18

SRIOV-FEC Operator

2.10

Lifecycle Agent

4.18

[1] この表は、調整された Cluster ロギング Operator バージョン 6.2 がリリースされると更新されます。

4.11. 通信事業者 RAN DU 4.18 ハブクラスターの検証済みソフトウェアコンポーネント

Red Hat 通信事業者 RAN 4.18 ソリューションは、OpenShift Container Platform ハブクラスター用の次の Red Hat ソフトウェア製品を使用して検証されています。

表4.8 通信事業者ハブクラスターの検証済みソフトウェアコンポーネント
コンポーネントソフトウェアバージョン

ハブクラスターのバージョン

4.18

Red Hat Advanced Cluster Management (RHACM)

2.121

Red Hat OpenShift GitOps

1.14

GitOps ZTP サイト生成プラグイン

4.18

Topology Aware Lifecycle Manager (TALM)

4.18

[1] この表は、対応する RHACM バージョン 2.13 のリリース時に更新される予定です。

第5章 クラスター設定の比較

5.1. cluster-compare について

cluster-compare プラグインは、クラスター設定をリファレンス設定と比較する OpenShift CLI (oc) プラグインです。このプラグインは、設定可能な検証ルールとテンプレートを使用して、設定の差異を報告する一方で、想定内の差異は除外します。

開発環境、実稼働環境、およびサポート環境で cluster-compare プラグインを使用して、クラスターがリファレンス設定に準拠していることを確認し、重要な設定の差異を迅速に特定してトラブルシューティングしてください。

5.1.1. cluster-compare プラグインの概要

大規模にデプロイされるクラスターでは、通常、検証済みのベースラインカスタムリソース (CR) セットを使用して、ユースケースの要件を満たすようにクラスターを設定し、異なる環境にデプロイする際の一貫性を確保します。

ライブクラスターには、検証済みの CR セットと比べて多少の差異があることが予想されます。たとえば、変数の置換、オプションのコンポーネント、またはハードウェア固有のフィールドが原因で設定が異なる場合があります。このような差異により、クラスターがベースライン設定に準拠しているかどうかを正確に評価することが困難になります。

oc コマンドで cluster-compare プラグインを使用すると、ライブクラスターの設定をリファレンス設定と比較できます。リファレンス設定はベースライン設定を表すものですが、さまざまなプラグインの機能を使用して、比較時に想定内の差異を除外します。たとえば、検証ルールを適用したり、任意および必須のリソースを指定したり、リソース間の関係を定義したりできます。このプラグインにより、重要でない差異が抑制されるため、複数の環境でベースライン設定へのクラスターの準拠状況を評価しやすくなります。

クラスターの設定をリファレンス設定とインテリジェントに比較する機能の使用例を以下に示します。

実稼働環境: サービス更新、アップグレード、およびリファレンス設定の変更時に、リファレンス設定への準拠を確保する。

開発環境: テストパイプラインのリファレンス設定への準拠を確保する。

設計環境: 設定をパートナーラボのリファレンス設定と比較して、一貫性を確保する。

サポート環境: リファレンス設定をライブクラスターからの must-gather データと比較して、設定の問題をトラブルシューティングする。

図5.1 cluster-compare プラグインの概要

cluster-compare プラグインの概要

5.1.2. リファレンス設定について

cluster-compare プラグインは、リファレンス設定を使用して、ライブクラスターの設定を検証します。リファレンス設定は、metadata.yaml という名前の YAML ファイルで構成されます。このファイルは、ベースライン設定を表す一連のテンプレートを参照します。

リファレンス設定のディレクトリー構造の例

Copy to Clipboard Toggle word wrap 
├── metadata.yaml
1 

├── optional
2 

│   ├── optionalTemplate1.yaml
│   └── optionalTemplate2.yaml
├── required
│   ├── requiredTemplate3.yaml
│   └── requiredTemplate4.yaml
└── baselineClusterResources
3 

    ├── clusterResource1.yaml
    ├── clusterResource2.yaml
    ├── clusterResource3.yaml
    └── clusterResource4.yaml

1
リファレンス設定は、metadata.yaml ファイルと一連のテンプレートで構成されます。
2
この例では、metadata.yaml ファイルによって参照されるテンプレートに、任意 (optional) と必須 (required) のディレクトリー構造を使用しています。
3
クラスターのベースライン設定として使用する設定 CR。

プラグインは、比較時に各テンプレートをクラスターの設定リソースとマッチします。プラグインは、Golang テンプレート構文やインライン正規表現検証などの機能を使用して、テンプレート内の任意または必須フィールドを評価します。metadata.yaml ファイルは、追加の検証ルールを適用して、テンプレートが任意か必須かを決定し、テンプレートの依存関係を評価します。

これらの機能を使用して、プラグインはクラスターとリファレンス設定間の重要な設定の差異を特定します。たとえば、フィールド値の不一致、不足しているリソース、余分なリソース、フィールドタイプの不一致、またはバージョンの不一致を検出できます。

リファレンス設定を指定する方法の詳細は、「リファレンス設定の作成」を参照してください。

5.1.3. 関連情報

5.2. cluster-compare プラグインのインストール

Red Hat Container Catalog 内のコンテナーイメージから cluster-compare プラグインを抽出し、oc コマンドのプラグインとして使用できます。

5.2.1. cluster-compare プラグインのインストール

cluster-compare プラグインをインストールして、リファレンス設定をライブクラスターまたは must-gather データのクラスター設定と比較します。

前提条件

  1. OpenShift CLI (oc) がインストールされている。
  2. podman がインストールされている。
  3. Red Hat Container Catalog にアクセスできる。

手順

  1. 次のコマンドを実行して、Red Hat Container Catalog にログインします。

    Copy to Clipboard Toggle word wrap 
    $ podman login registry.redhat.io

  2. 次のコマンドを実行して、cluster-compare イメージのコンテナーを作成します。

    Copy to Clipboard Toggle word wrap 
    $ podman create --name cca registry.redhat.io/openshift4/kube-compare-artifacts-rhel9:latest

  3. 次のコマンドを実行して、cluster-compare プラグインを PATH 環境変数に含まれているディレクトリーにコピーします。

    Copy to Clipboard Toggle word wrap 
    $ podman cp cca:/usr/share/openshift/<arch>/kube-compare.<rhel_version> <directory_on_path>/kubectl-cluster_compare

    • arch は、お使いのマシンのアーキテクチャーです。有効な値は以下のとおりです。

      • linux_amd64
      • linux_arm64
      • linux_ppc64le
      • linux_s390x
    • <rhel_version> は、マシンの RHEL のバージョンです。有効な値は rhel8 または rhel9 です。
    • <directory_on_path> は、PATH 環境変数に含まれているディレクトリーへのパスです。

検証

  • 次のコマンドを実行して、プラグインのヘルプを表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -h

    出力例

    Copy to Clipboard Toggle word wrap 
    Compare a known valid reference configuration and a set of specific cluster configuration CRs.

...

Usage:
  compare -r <Reference File>

Examples:
  # Compare a known valid reference configuration with a live cluster:
  kubectl cluster-compare -r ./reference/metadata.yaml

 ...

5.2.2. 関連情報

5.3. cluster-compare プラグインの使用

cluster-compare プラグインを使用すると、リファレンス設定をライブクラスターまたは must-gather データからの設定と比較できます。

5.3.1. ライブクラスターでの cluster-compare プラグインの使用

cluster-compare プラグインを使用すると、リファレンス設定をライブクラスターの設定カスタムリソース (CR) と比較できます。

設計中、開発中、またはテスト中に、ライブクラスターの設定を検証し、リファレンス設定に準拠していることを確認してください。

注記

cluster-compare プラグインは、非実稼働環境のライブクラスターでのみ使用してください。実稼働環境の場合は、must-gather データに対してプラグインを使用してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • cluster-compare プラグインをダウンロードし、PATH 環境変数に含めた。
  • リファレンス設定にアクセスできる。

手順

  • 次のコマンドを使用して、cluster-compare プラグインを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r <path_to_reference_config>/metadata.yaml

    • -r は、リファレンス設定の metadata.yaml ファイルへのパスを指定します。ローカルディレクトリーまたは URI を指定できます。

      出力例

      Copy to Clipboard Toggle word wrap 
      ...

**********************************

Cluster CR: operator.openshift.io/v1_Console_cluster
      1 
      
Reference File: optional/console-disable/ConsoleOperatorDisable.yaml
      2 
      
Diff Output: diff -u -N /tmp/MERGED-622469311/operator-openshift-io-v1_console_cluster /tmp/LIVE-2358803347/operator-openshift-io-v1_console_cluster
/tmp/MERGED-622469311/operator-openshift-io-v1_console_cluster	2024-11-20 15:43:42.888633602 +0000
+++ /tmp/LIVE-2358803347/operator-openshift-io-v1_console_cluster	2024-11-20 15:43:42.888633602 +0000
@@ -4,5 +4,5 @@
   name: cluster
 spec:
   logLevel: Normal
-  managementState: Removed
      3 
      
+  managementState: Managed
   operatorLogLevel: Normal

**********************************

…

Summary
      4 
      
CRs with diffs: 5/49
      5 
      
CRs in reference missing from the cluster: 1
      6 
      
required-cluster-tuning:
  cluster-tuning:
    Missing CRs:
      7 
      
    - required/cluster-tuning/disabling-network-diagnostics/DisableSnoNetworkDiag.yaml
No CRs are unmatched to reference CRs
      8 
      
Metadata Hash: 512a9bf2e57fd5a5c44bbdea7abb3ffd7739d4a1f14ef9021f6793d5cdf868f0
      9 
      
No patched CRs
      10

      1
      比較対象の CR。プラグインにより、対応するテンプレートとの差異のある各 CR が表示されます。
      2
      比較対象の CR とマッチするテンプレート。
      3
      Linux diff 形式の出力に、テンプレートとクラスター CR の差異が表示されます。
      4
      プラグインにより、各 CR の行の差分が報告されます。その後、差分の概要が報告されます。
      5
      対応するテンプレートとの差異を比較した CR の数。
      6
      リファレンス設定に表されているが、ライブクラスターには存在しない CR の数。
      7
      リファレンス設定に表されているが、ライブクラスターには存在しない CR のリスト。
      8
      リファレンス設定内の対応するテンプレートとマッチしなかった CR。
      9
      メタデータハッシュはリファレンス設定を識別するものです。
      10
      パッチが適用された CR のリスト。

5.3.2. must-gather データでの cluster-compare プラグインの使用

cluster-compare プラグインを使用すると、リファレンス設定を must-gather データからの設定カスタムリソース (CR) と比較できます。

must-gather データを使用してクラスター設定を検証し、実稼働環境での設定の問題をトラブルシューティングします。

注記

実稼働環境の場合は、必ず must-gather データに対して cluster-compare プラグインを使用してください。

  • ターゲットクラスターから must-gather データにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-compare プラグインをダウンロードし、PATH 環境変数に含めた。
  • リファレンス設定にアクセスできる。

手順

  • 次のコマンドを実行して、must-gather データをリファレンス設定と比較します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -f "must-gather*/*/cluster-scoped-resources","must-gather*/*/namespaces" -R
    • -r は、リファレンス設定の metadata.yaml ファイルへのパスを指定します。ローカルディレクトリーまたは URI を指定できます。
    • -f は、must-gather データディレクトリーへのパスを指定します。ローカルディレクトリーまたは URI を指定できます。この例では、比較対象を重要なクラスター設定ディレクトリーに制限します。

    • -R は、ターゲットディレクトリーを再帰的に検索します。

      出力例

      Copy to Clipboard Toggle word wrap 
      ...

**********************************

Cluster CR: operator.openshift.io/v1_Console_cluster
      1 
      
Reference File: optional/console-disable/ConsoleOperatorDisable.yaml
      2 
      
Diff Output: diff -u -N /tmp/MERGED-622469311/operator-openshift-io-v1_console_cluster /tmp/LIVE-2358803347/operator-openshift-io-v1_console_cluster
/tmp/MERGED-622469311/operator-openshift-io-v1_console_cluster	2024-11-20 15:43:42.888633602 +0000
+++ /tmp/LIVE-2358803347/operator-openshift-io-v1_console_cluster	2024-11-20 15:43:42.888633602 +0000
@@ -4,5 +4,5 @@
   name: cluster
 spec:
   logLevel: Normal
-  managementState: Removed
      3 
      
+  managementState: Managed
   operatorLogLevel: Normal

**********************************

…

Summary
      4 
      
CRs with diffs: 5/49
      5 
      
CRs in reference missing from the cluster: 1
      6 
      
required-cluster-tuning:
  cluster-tuning:
    Missing CRs:
      7 
      
    - required/cluster-tuning/disabling-network-diagnostics/DisableSnoNetworkDiag.yaml
No CRs are unmatched to reference CRs
      8 
      
Metadata Hash: 512a9bf2e57fd5a5c44bbdea7abb3ffd7739d4a1f14ef9021f6793d5cdf868f0
      9 
      
No patched CRs
      10

      1
      比較対象の CR。プラグインにより、対応するテンプレートとの差異のある各 CR が表示されます。
      2
      比較対象の CR とマッチするテンプレート。
      3
      Linux diff 形式の出力に、テンプレートとクラスター CR の差異が表示されます。
      4
      プラグインにより、各 CR の行の差分が報告されます。その後、差分の概要が報告されます。
      5
      対応するテンプレートとの差異を比較した CR の数。
      6
      リファレンス設定に表されているが、ライブクラスターには存在しない CR の数。
      7
      リファレンス設定に表されているが、ライブクラスターには存在しない CR のリスト。
      8
      リファレンス設定内の対応するテンプレートとマッチしなかった CR。
      9
      メタデータハッシュはリファレンス設定を識別するものです。
      10
      パッチが適用された CR のリスト。

関連情報

5.3.3. cluster-compare プラグインのオプションのリファレンス

ここでは、cluster-compare プラグインのオプションについて説明します。

表5.1 cluster-compare プラグインのオプション
オプション説明

-A、--all-resources

ライブクラスターで使用すると、リファレンス設定内のタイプに一致するクラスター内の全リソースとのマッチングを試行します。ローカルファイルで使用すると、リファレンス設定内のタイプに一致するローカルファイル内の全リソースとのマッチングを試行します。

--concurrency

ライブバージョンのリソースと比較するときに、並列処理するテンプレートの数の整数値を指定します。数値が大きいほど速度は増加しますが、その期間中のメモリー、I/O、CPU の使用率も増加します。デフォルト値は 4 です。

-c、--diff-config

ユーザー設定ファイルへのパスを指定します。

-f、--filename

リファレンス設定との比較に使用する設定カスタムリソースのファイル名、ディレクトリー、または URL を指定します。

--generate-override-for

パッチが必要なテンプレートのパスを指定します。

注記

metadata.yaml ファイルを基準とした対象テンプレートのファイルパスを使用する必要があります。たとえば、metadata.yaml ファイルのファイルパスが ./compare/metadata.yaml の場合、テンプレートの相対ファイルパスは optional/my-template.yaml です。

-h、--help

ヘルプ情報を表示します。

-k、--kustomize

kustomization ディレクトリーを処理するためのパスを指定します。このフラグは -f または -R と一緒に使用することはできません。

-o、--output

出力形式を指定します。json、yaml、generate-patches を指定できます。

--override-reason

オーバーライドを生成する理由を指定します。

-p、--overrides

リファレンス設定のパッチオーバーライドファイルへのパスを指定します。

-R、--recursive

-f、--filename で指定されたディレクトリーを再帰的に処理します。

-r、--reference

リファレンス設定の metadata.yaml ファイルへのパスを指定します。

--show-managed-fields

マネージドフィールドを比較に含めるには true を指定します。

-v、--verbose

プラグイン出力の詳細度を高めます。

5.3.4. 例: クラスターと通信事業者コアリファレンス設定の比較

cluster-compare プラグインを使用すると、リファレンス設定をライブクラスターまたは must-gather データからの設定と比較できます。

この例では、ライブクラスターの設定と通信事業者コアリファレンス設定を比較します。通信事業者コアリファレンス設定は、通信事業者コアリファレンス設計仕様 (RDS) に基づくものです。通信事業者コア RDS は、コントロールプレーンや一部の集中型データプレーン機能を含む大規模な通信アプリケーションを支えるクラスター向けに設計されています。

リファレンス設定は、通信事業者 Core RDS とともにコンテナーイメージにパッケージ化されています。

cluster-compare プラグインを通信事業者コアプロファイルおよび通信事業者 RAN 分散ユニット (DU) プロファイルとともに使用する例については、「関連情報」セクションを参照してください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • registry.redhat.io コンテナーイメージレジストリーにアクセスするための認証情報がある。
  • cluster-compare プラグインをインストールした。

手順

  1. 次のコマンドを実行して、認証情報を使用してコンテナーイメージレジストリーにログオンします。

    Copy to Clipboard Toggle word wrap 
    $ podman login registry.redhat.io

  2. 次のコマンドを実行して、telco-core-rds-rhel9 コンテナーイメージからコンテンツを抽出します。

    Copy to Clipboard Toggle word wrap 
    $ mkdir -p ./out
     Copy to Clipboard Toggle word wrap 
    $ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out

    リファレンス設定は、reference-crs-kube-compare/ ディレクトリーで確認できます。

    Copy to Clipboard Toggle word wrap 
    out/telco-core-rds/configuration/reference-crs-kube-compare/
├── metadata.yaml
    1 
    
├── optional
    2 
    
│   ├── logging
│   ├── networking
│   ├── other
│   └── tuning
└── required
    3 
    
    ├── networking
    ├── other
    ├── performance
    ├── scheduling
    └── storage
    1
    リファレンス設定用の設定ファイル。
    2
    任意のテンプレート用のディレクトリー。
    3
    必須のテンプレート用のディレクトリー。

  3. 次のコマンドを実行して、クラスターの設定を通信事業者コアリファレンス設定と比較します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    W1212 14:13:06.281590   36629 compare.go:425] Reference Contains Templates With Types (kind) Not Supported By Cluster: BFDProfile, BGPAdvertisement, BGPPeer, ClusterLogForwarder, Community, IPAddressPool, MetalLB, MultiNetworkPolicy, NMState, NUMAResourcesOperator, NUMAResourcesScheduler, NodeNetworkConfigurationPolicy, SriovNetwork, SriovNetworkNodePolicy, SriovOperatorConfig, StorageCluster

...

**********************************

Cluster CR: config.openshift.io/v1_OperatorHub_cluster
    1 
    
Reference File: required/other/operator-hub.yaml
    2 
    
Diff Output: diff -u -N /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster
--- /tmp/MERGED-2801470219/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
+++ /tmp/LIVE-2569768241/config-openshift-io-v1_operatorhub_cluster	2024-12-12 14:13:22.898756462 +0000
@@ -1,6 +1,6 @@
 apiVersion: config.openshift.io/v1
 kind: OperatorHub
 metadata:
+  annotations:
    3 
    
+    include.release.openshift.io/hypershift: "true"
   name: cluster
-spec:
-  disableAllDefaultSources: true

**********************************

Summary
    4 
    
CRs with diffs: 3/4
    5 
    
CRs in reference missing from the cluster: 22
    6 
    
other:
  other:
    Missing CRs:
    7 
    
    - optional/other/control-plane-load-kernel-modules.yaml
    - optional/other/worker-load-kernel-modules.yaml
required-networking:
  networking-root:
    Missing CRs:
    - required/networking/nodeNetworkConfigurationPolicy.yaml
  networking-sriov:
    Missing CRs:
    - required/networking/sriov/sriovNetwork.yaml
    - required/networking/sriov/sriovNetworkNodePolicy.yaml
    - required/networking/sriov/SriovOperatorConfig.yaml
    - required/networking/sriov/SriovSubscription.yaml
    - required/networking/sriov/SriovSubscriptionNS.yaml
    - required/networking/sriov/SriovSubscriptionOperGroup.yaml
required-other:
  scheduling:
    Missing CRs:
    - required/other/catalog-source.yaml
    - required/other/icsp.yaml
required-performance:
  performance:
    Missing CRs:
    - required/performance/PerformanceProfile.yaml
required-scheduling:
  scheduling:
    Missing CRs:
    - required/scheduling/nrop.yaml
    - required/scheduling/NROPSubscription.yaml
    - required/scheduling/NROPSubscriptionNS.yaml
    - required/scheduling/NROPSubscriptionOperGroup.yaml
    - required/scheduling/sched.yaml
required-storage:
  storage-odf:
    Missing CRs:
    - required/storage/odf-external/01-rook-ceph-external-cluster-details.secret.yaml
    - required/storage/odf-external/02-ocs-external-storagecluster.yaml
    - required/storage/odf-external/odfNS.yaml
    - required/storage/odf-external/odfOperGroup.yaml
    - required/storage/odf-external/odfSubscription.yaml
No CRs are unmatched to reference CRs
    8 
    
Metadata Hash: fe41066bac56517be02053d436c815661c9fa35eec5922af25a1be359818f297
    9 
    
No patched CRs
    10

    1
    比較対象の CR。プラグインにより、対応するテンプレートとの差異のある各 CR が表示されます。
    2
    比較対象の CR とマッチするテンプレート。
    3
    Linux diff 形式の出力に、テンプレートとクラスター CR の差異が表示されます。
    4
    プラグインにより、各 CR の行の差分が報告されます。その後、差分の概要が報告されます。
    5
    対応するテンプレートとの差異を比較した CR の数。
    6
    リファレンス設定に表されているが、ライブクラスターには存在しない CR の数。
    7
    リファレンス設定に表されているが、ライブクラスターには存在しない CR のリスト。
    8
    リファレンス設定内の対応するテンプレートとマッチしなかった CR。
    9
    メタデータハッシュはリファレンス設定を識別するものです。
    10
    パッチが適用された CR のリスト。

5.3.5. 関連情報

5.4. リファレンス設定の作成

クラスターの設定リソースを検証するためのリファレンス設定を指定します。

5.4.1. metadata.yaml ファイルの構造

metadata.yaml ファイルは、リファレンス設定のテンプレートを一元的に定義および設定するため場所です。このファイルには、parts と components という階層が含まれています。parts は components のグループであり、components はテンプレートのグループです。各コンポーネントで、テンプレートの依存関係、検証ルールを設定し、説明的なメタデータを追加できます。

metadata.yaml ファイルの例

Copy to Clipboard Toggle word wrap 
apiVersion: v2
parts:
1 

  - name: Part1
2 

    components:
      - name: Component1
3 

        <component1_configuration>
4 

  - name: Part2
      - name: Component2
        <component2_configuration>

1
各 part には、通常、ワークロードまたはワークロードのセットを記述します。
2
part の名前を指定します。
3
component の名前を指定します。
4
テンプレートの設定を指定します。たとえば、テンプレートの関係を定義したり、比較で使用するフィールドを設定したりします。

5.4.2. テンプレートの関係の設定

リファレンス設定でテンプレート間の関係を定義することで、複雑な依存関係を伴うユースケースに対応できます。たとえば、特定のテンプレートを要求するコンポーネントを設定したり、グループから 1 つのテンプレートを要求するコンポーネントを設定したり、グループからのすべてのテンプレートを許可するコンポーネントを設定できます。

手順

  • ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    metadata.yaml ファイルの例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:
  - name: Part1
    components:
      - name: Component1
        allOf:
    1 
    
          - path: RequiredTemplate1.yaml
          - path: RequiredTemplate2.yaml
      - name: Component2
        allOrNoneOf:
    2 
    
          - path: OptionalBlockTemplate1.yaml
          - path: OptionalBlockTemplate2.yaml
      - name: Component3
        anyOf:
    3 
    
          - path: OptionalTemplate1.yaml
          - path: OptionalTemplate2.yaml
      - name: Component4
        noneOf:
    4 
    
          - path: BannedTemplate1.yaml
          - path: BannedTemplate2.yaml
      - name: Component5
        oneOf:
    5 
    
          - path: RequiredExclusiveTemplate1.yaml
          - path: RequiredExclusiveTemplate2.yaml
      - name: Component6
        anyOneOf:
    6 
    
          - path: OptionalExclusiveTemplate1.yaml
          - path: OptionalExclusiveTemplate2.yaml
#...

    1
    必要なテンプレートを指定します。
    2
    すべて必須またはすべて任意のテンプレートのグループを指定します。クラスター内に対応するカスタムリソース (CR) が 1 つ存在する場合、クラスター内に対応するすべての CR が存在する必要があります。
    3
    任意のテンプレートを指定します。
    4
    除外するテンプレートを指定します。対応する CR がクラスター内に存在する場合、プラグインが検証エラーを返します。
    5
    1 つだけ存在できるテンプレートを指定します。対応する CR がクラスター内に存在する場合、または 1 つ以上存在する場合、プラグインが検証エラーを返します。
    6
    クラスター内に 1 つだけ存在できるテンプレートを指定します。対応する CR がクラスター内に複数存在する場合、プラグインが検証エラーを返します。

5.4.3. テンプレートで想定内の差異を設定する

Golang テンプレート構文を使用すると、テンプレート内の可変的な内容を処理できます。この構文を使用すると、テンプレート内の任意、必須、および条件付きの内容を処理する検証ロジックを設定できます。

注記
  • cluster-compare プラグインでは、すべてのテンプレートを有効な YAML としてレンダリングする必要があります。フィールドの欠落による解析エラーを回避するには、テンプレート構文を実装するときに {{- if .spec.<optional_field> }} などの条件付きテンプレート構文を使用してください。このような条件付きロジックを使用すると、テンプレートでフィールドの欠落が適切に処理され、有効な YAML 形式が維持されます。
  • 複雑なユースケースの場合は、カスタム関数と組み込み関数を使用した Golang テンプレート構文を使用できます。Sprig ライブラリーの関数を含むすべての Golang 組み込み関数がサポートされています。

手順

  • ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
kind: Service
metadata:
  name: frontend
    1 
    
  namespace: {{ .metadata.namespace }}
    2 
    
  labels:
    app: guestbook
    tier: frontend
spec:
  {{- if and .spec.type (eq (.spec.type) "NodePort" "LoadBalancer") }}
  type: {{.spec.type }}
    3 
    
  {{- else }}
  type: should be NodePort or LoadBalancer
  {{- end }}
  ports:
  - port: 80
  selector:
    app: guestbook
    {{- if .spec.selector.tier }}
    4 
    
    tier: frontend
    {{- end }}
    1
    指定の値と一致する必要がある必須フィールドを設定します。
    2
    任意の値を持つことができる必須フィールドを設定します。
    3
    .spec.type フィールドの検証を設定します。
    4
    任意のフィールドを設定します。

5.4.4. テンプレートフィールドを除外するための metadata.yaml ファイルの設定

比較からフィールドを除外するように metadata.yaml ファイルを設定できます。クラスター設定に関係のないアノテーションやラベルなど、比較に関係のないフィールドは除外します。

次の方法で、metadata.yaml ファイルで除外を設定できます。

  • テンプレートで指定されていないカスタムリソース内のすべてのフィールドを除外する。

  • pathToKey フィールドを使用して定義した特定のフィールドを除外する。

    注記

    pathToKey はドットで区切りのパスです。ピリオドを含むキー値をエスケープするには、引用符を使用してください。

5.4.4.1. テンプレートで指定されていないすべてのフィールドを除外する

比較プロセス中に、cluster-compare プラグインは、対応するカスタムリソース (CR) のフィールドをマージしてテンプレートをレンダリングします。ignore-unspecified-fields を true に設定すると、CR に存在するがテンプレートには存在しないすべてのフィールドがマージから除外されます。テンプレートで指定したフィールドのみを比較対象にする場合は、この方法を使用します。

手順

  • ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:
  - name: Part1
    components:
      - name: Namespace
        allOf:
          - path: namespace.yaml
            config:
              ignore-unspecified-fields: true
    1 
    
#...
    1
    true を指定して、対応する namespace.yaml テンプレートで明示的に設定されていない CR 内のすべてのフィールドを比較から除外します。
5.4.4.2. デフォルトの除外フィールドを設定して特定のフィールドを除外する

defaultOmitRef フィールドの fieldsToOmitRefs のデフォルト値を定義することで、フィールドを除外できます。このデフォルトの除外は、特定のテンプレートの config.fieldsToOmitRefs フィールドによってオーバーライドされない限り、すべてのテンプレートに適用されます。

手順

  • ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    metadata.yaml ファイルの例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:

#...

fieldsToOmit:
   defaultOmitRef: default
    1 
    
   items:
      default:
         - pathToKey: a.custom.default."k8s.io"
    2

    1
    特定のテンプレートの config.fieldsToOmitRefs フィールドによってオーバーライドされない限り、全テンプレートのデフォルトの除外を設定します。
    2
    この値がすべてのテンプレートから除外されます。
5.4.4.3. 特定のフィールドを除外する

フィールドへのパスを定義し、テンプレートの config セクションでその定義を参照することで、除外するフィールドを指定できます。

手順

  • ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    metadata.yaml ファイルの例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:
  - name: Part1
    components:
      - name: Component1
        - path: deployment.yaml
          config:
            fieldsToOmitRefs:
              - deployments
    1 
    

#...

fieldsToOmit:
   items:
      deployments:
         - pathToKey: spec.selector.matchLabels.k8s-app
    2

    1
    deploy.yaml テンプレートの fieldsToOmit.items.deployments 項目を参照します。
    2
    spec.selector.matchLabels.k8s-app フィールドを比較から除外します。
    注記

    fieldsToOmitRefs を設定すると、デフォルト値が置き換えられます。

5.4.4.4. デフォルトの除外グループを設定して特定のフィールドを除外する

除外するフィールドのデフォルトグループを作成できます。除外グループは、除外を定義するときに重複を避けるために、別のグループを参照できます。

手順

  • ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    metadata.yaml ファイルの例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:

#...

fieldsToOmit:
   defaultOmitRef: default
   items:
    common:
      - pathToKey: metadata.annotations."kubernetes.io/metadata.name"
      - pathToKey: metadata.annotations."kubernetes.io/metadata.name"
      - pathToKey: metadata.annotations."kubectl.kubernetes.io/last-applied-configuration"
      - pathToKey: metadata.creationTimestamp
      - pathToKey: metadata.generation
      - pathToKey: spec.ownerReferences
      - pathToKey: metadata.ownerReferences
    default:
      - include: common
    1 
    
      - pathToKey: status

    1
    common グループがデフォルトグループに含まれます。

5.4.5. テンプレートフィールドのインライン検証の設定

特に Golang テンプレート構文のメンテナンスが困難な場合や複雑すぎる場合は、インライン正規表現を有効にしてテンプレートフィールドを検証できます。インライン正規表現を使用すると、テンプレートが簡素化され、可読性が向上し、より高度な検証ロジックが可能になります。

cluster-compare プラグインには、インライン検証用の 2 つの関数があります。

  • regex: 正規表現を使用してフィールドの内容を検証します。
  • capturegroups: キャプチャーグループ以外のテキストを完全一致として処理し、名前付きキャプチャーグループ内でのみ正規表現マッチングを適用し、繰り返しキャプチャーグループの一貫性を確保することで、マルチラインテキストの比較を強化します。
5.4.5.1. 正規表現関数を使用したインライン検証の設定

正規表現を使用してフィールドを検証するには、regex インライン関数を使用します。

手順

  1. ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:
- name: Part1
  components:
  - name: Example
    allOf:
    - path: example.yaml
      config:
        perField:
        - pathToKey: spec.bigTextBlock
    1 
    
          inlineDiffFunc: regex
    2
    1
    インライン検証対象のフィールドを指定します。
    2
    正規表現を使用したインライン検証を有効にします。

  2. 正規表現を使用して、関連するテンプレートのフィールドを検証します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: ConfigMap
metadata:
  namespace: dashboard
data:
  bigTextBlock: |-
    This is a big text block with some static content, like this line.
    It also has a place where (?<username>[a-z0-9]+) would put in their own name. (?<username>[a-z0-9]+) would put in their own name.
5.4.5.2. キャプチャーグループ関数を使用したインライン検証の設定

マルチライン文字列を含むフィールドをより正確に検証するには、capturegroups インライン関数を使用します。

手順

  1. ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:
- name: Part1
  components:
  - name: Example
    allOf:
    - path: example.yaml
      config:
        perField:
        - pathToKey: spec.bigTextBlock
    1 
    
          inlineDiffFunc: capturegroups
    2
    1
    インライン検証対象のフィールドを指定します。
    2
    キャプチャーグループを使用したインライン検証を有効にします。

  2. 正規表現を使用して、関連するテンプレートのフィールドを検証します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: ConfigMap
metadata:
  namespace: dashboard
data:
  bigTextBlock: |-
    This static content outside of a capture group should match exactly.
    Here is a username capture group: (?<username>[a-z0-9]+).
    It should match this capture group: (?<username>[a-z0-9]+).

5.4.6. 出力の説明の設定

各パーツ、コンポーネント、またはテンプレートに、追加のコンテキスト、手順、またはドキュメントリンクを提供するための説明を含めることができます。これらの説明は、特定のテンプレートまたは構造が必要な理由を伝えるのに役立ちます。

手順

  • ユースケースに合わせて metadata.yaml ファイルを作成します。例として次の構造を使用します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v2
parts:
  - name: Part1
    description: |-
      General text for every template under this part, unless overridden.
    components:
      - name: Component1
        # With no description set, this inherits the description from the part above.
        OneOf:
          - path: Template1.yaml
            # This inherits the component description, if set.
          - path: Template2.yaml
          - path: Template3.yaml
            description: |-
              This template has special instructions that don't apply to the others.
      - name: Component2
        description: |-
          This overrides the part text with something more specific.
          Multi-line text is supported, at all levels.
        allOf:
          - path: RequiredTemplate1.yaml
          - path: RequiredTemplate2.yaml
            description: |-
              Required for important reasons.
          - path: RequiredTemplate3.yaml

5.5. リファレンス設定の高度なカスタマイズ

リファレンス設計からの一時的な逸脱を許可する場合は、より高度なカスタマイズを適用できます。

警告

このカスタマイズでは、比較時に cluster-compare プラグインが使用するデフォルトのマッチングプロセスをオーバーライドします。このような高度なカスタマイズを適用する場合は、cluster-compare から重要な情報が除外されるなど、意図しない結果が発生する可能性があるため、注意してください。

リファレンス設定を動的にカスタマイズするための高度なタスクには、次のようなものがあります。

  • 手動マッチング: クラスターのカスタムリソースをリファレンス設定のテンプレートと手動でマッチするようにユーザー設定ファイルを設定します。
  • リファレンスへのパッチ適用: cluster-compare コマンドでパッチオプションを使用してリファレンスにパッチを適用し、リファレンス設定を指定します。

5.5.1. CR とテンプレート間の手動マッチングの設定

場合によっては、cluster-compare プラグインのデフォルトのマッチングが期待どおりに機能しないことがあります。ユーザー設定ファイルを使用すると、カスタムリソース (CR) をテンプレートにマッピングする方法を手動で定義できます。

デフォルトでは、プラグインは apiversion、kind、name、namespace フィールドに基づいて CR をテンプレートにマッピングします。ただし、複数のテンプレートが 1 つの CR とマッチする場合もあります。たとえば、これは次のような状況で発生する可能性があります。

  • 同じ apiversion、kind、name、および namespace フィールドを持つテンプレートが複数存在する。
  • テンプレートが、CR の namespace や name に関係なく、特定の apiversion と kind を持ついずれかの CR とマッチする。

CR が複数のテンプレートとマッチする場合、プラグインはタイブレークメカニズムを使用して、差異が最も少ないテンプレートを選択します。プラグインが選択するテンプレートを明示的に制御するには、手動のマッチングルールを定義するユーザー設定 YAML ファイルを作成します。この設定ファイルを cluster-compare コマンドに渡すことで、必要なテンプレートの選択を適用できます。

手順

  1. 手動マッチングの条件を定義するユーザー設定ファイルを作成します。

    user-config.yaml ファイルの例

    Copy to Clipboard Toggle word wrap 
    correlationSettings:
    1 
    
   manualCorrelation:
    2 
    
      correlationPairs:
    3 
    
        ptp.openshift.io/v1_PtpConfig_openshift-ptp_grandmaster: optional/ptp-config/PtpOperatorConfig.yaml
    4 
    
        ptp.openshift.io/v1_PtpOperatorConfig_openshift-ptp_default: optional/ptp-config/PtpOperatorConfig.yaml

    1
    correlationSettings セクションには、手動による相関付け設定を含めます。
    2
    manualCorrelation セクションでは、手動による相関付けが有効であることを指定します。
    3
    correlationPairs セクションには、手動でマッチする CR とテンプレートのペアをリストします。
    4
    マッチする CR とテンプレートのペアを指定します。CR 仕様では、<apiversion>_<kind>_<namespace>_<name> という形式を使用します。namespace がないクラスタースコープの CR の場合は、<apiversion>_<kind>_<name> という形式を使用します。テンプレートへのパスは、metadata.yaml ファイルからの相対パスである必要があります。

  2. 次のコマンドを実行して、cluster-compare コマンドでユーザー設定ファイルを参照します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -c <path_to_user_config>/user-config.yaml
    1
    1
    -c オプションを使用して user-config.yaml ファイルを指定します。

5.5.2. リファレンス設定へのパッチ適用

場合によっては、予想されるクラスター設定の逸脱を処理するために、リファレンス設定にパッチを適用する必要があります。パッチはプラグインによって比較プロセス中に適用され、指定されたリソースフィールドがパッチファイルの定義のとおりに変更されます。

たとえば、最新のリファレンス設定では非推奨になっている古いフィールドをクラスターで使用しているため、テンプレートに一時的にパッチを適用する必要がある場合があります。パッチが適用されたファイルは、比較出力の概要に報告されます。

パッチファイルは次の 2 つの方法で作成できます。

  • cluster-compare プラグインを使用してパッチ YAML ファイルを生成する。
  • 独自のパッチファイルを作成する。
5.5.2.1. cluster-compare プラグインを使用したパッチの生成

cluster-compare プラグインを使用して、特定のテンプレートファイル用のパッチを生成できます。プラグインは、クラスターのカスタムリソース (CR) と一致するようにテンプレートを調整します。パッチが適用されたテンプレートに含まれる以前に有効だった差異は報告されません。プラグインは、パッチが適用されたファイルを出力で強調表示します。

手順

  1. 次のコマンドを実行して、テンプレートのパッチを生成します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -o 'generate-patches' --override-reason "A valid reason for the override" --generate-override-for "<template1_path>" --generate-override-for "<template2_path>" > <path_to_patches_file>
    • -r は、リファレンス設定の metadata.yaml ファイルへのパスを指定します。
    • -o は、出力形式を指定します。パッチ出力を生成するには、generate-patches 値を使用する必要があります。
    • --override-reason は、パッチの理由を説明します。

    • --generate-override-for は、パッチが必要なテンプレートへのパスを指定します。

      注記

      metadata.yaml ファイルを基準とした対象テンプレートのファイルパスを使用する必要があります。たとえば、metadata.yaml ファイルのファイルパスが ./compare/metadata.yaml の場合、テンプレートの相対ファイルパスは optional/my-template.yaml です。

    • <path_to_patches_file> は、パッチのファイル名とパスを指定します。

  2. オプション: リファレンス設定に適用する前にパッチファイルを確認します。

    patch-config ファイルの例

    Copy to Clipboard Toggle word wrap 
    - apiVersion: storage.k8s.io/v1
  kind: StorageClass
  name: crc-csi-hostpath-provisioner
  patch: '{"provisioner":"kubevirt.io.hostpath-provisioner"}'
    1 
    
  reason: A valid reason for the override
  templatePath: optional/local-storage-operator/StorageClass.yaml
    2 
    
  type: mergepatch
    3

    1
    プラグインは、CR と一致するようにテンプレート内のフィールドを修正します。
    2
    テンプレートへのパス。
    3
    mergepath オプションは、JSON を対象テンプレートにマージします。指定されていないフィールドは変更されません。

  3. 次のコマンドを実行して、リファレンス設定にパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r <referenceConfigurationDirectory> -p <path_to_patches_file>
    • -r は、リファレンス設定の metadata.yaml ファイルへのパスを指定します。

    • -p は、パッチファイルへのパスを指定します。

      出力例

      Copy to Clipboard Toggle word wrap 
      ...

Cluster CR: storage.k8s.io/v1_StorageClass_crc-csi-hostpath-provisioner
Reference File: optional/local-storage-operator/StorageClass.yaml
Description: Component description
Diff Output: None
Patched with patch
Patch Reasons:
- A valid reason for the override

...

No CRs are unmatched to reference CRs
Metadata Hash: bb2165004c496b32e0c8509428fb99c653c3cf4fba41196ea6821bd05c3083ab
Cluster CRs with patches applied: 1

5.5.2.2. パッチファイルの手動作成

予想されるクラスター設定の逸脱を処理するためのパッチファイルを作成できます。

注記

パッチの type フィールドには、次の 3 つの値を指定できます。

  • mergepatch - JSON を対象テンプレートにマージします。指定されていないフィールドは変更されません。
  • rfc6902 - add、remove、replace、move、および copy 操作を使用して、対象テンプレート内の JSON をマージします。各操作は特定のパスを対象とします。
  • go-template - Golang テンプレートを定義します。プラグインがクラスターのカスタムリソース (CR) を入力として使用してテンプレートをレンダリングし、対象テンプレートの mergepatch または rfc6902 パッチのいずれかを生成します。

次の例は、3 つの異なる形式すべてを使用した同じパッチを示しています。

手順

  1. ユースケースに合わせてパッチファイルを作成します。例として次の構造を使用します。

    patch-config の例

    Copy to Clipboard Toggle word wrap 
    - apiVersion: v1
    1 
    
  kind: Namespace
  name: openshift-storage
  reason: known deviation
  templatePath: namespace.yaml
  type: mergepatch
  patch: '{"metadata":{"annotations":{"openshift.io/sa.scc.mcs":"s0:c29,c14","openshift.io/sa.scc.supplemental-groups":"1000840000/10000","openshift.io/sa.scc.uid-range":"1000840000/10000","reclaimspace.csiaddons.openshift.io/schedule":"@weekly","workload.openshift.io/allowed":null},"labels":{"kubernetes.io/metadata.name":"openshift-storage","olm.operatorgroup.uid/ffcf3f2d-3e37-4772-97bc-983cdfce128b":"","openshift.io/cluster-monitoring":"false","pod-security.kubernetes.io/audit":"privileged","pod-security.kubernetes.io/audit-version":"v1.24","pod-security.kubernetes.io/warn":"privileged","pod-security.kubernetes.io/warn-version":"v1.24","security.openshift.io/scc.podSecurityLabelSync":"true"}},"spec":{"finalizers":["kubernetes"]}}'
- name: openshift-storage
  apiVersion: v1
  kind: Namespace
  templatePath: namespace.yaml
  type: rfc6902
  reason: known deviation
  patch: '[
    {"op": "add", "path": "/metadata/annotations/openshift.io~1sa.scc.mcs", "value": "s0:c29,c14"},
    {"op": "add", "path": "/metadata/annotations/openshift.io~1sa.scc.supplemental-groups", "value": "1000840000/10000"},
    {"op": "add", "path": "/metadata/annotations/openshift.io~1sa.scc.uid-range", "value": "1000840000/10000"},
    {"op": "add", "path": "/metadata/annotations/reclaimspace.csiaddons.openshift.io~1schedule", "value": "@weekly"},
    {"op": "remove", "path": "/metadata/annotations/workload.openshift.io~1allowed"},
    {"op": "add", "path": "/metadata/labels/kubernetes.io~1metadata.name", "value": "openshift-storage"},
    {"op": "add", "path": "/metadata/labels/olm.operatorgroup.uid~1ffcf3f2d-3e37-4772-97bc-983cdfce128b", "value": ""},
    {"op": "add", "path": "/metadata/labels/openshift.io~1cluster-monitoring", "value": "false"},
    {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1audit", "value": "privileged"},
    {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1audit-version", "value": "v1.24"},
    {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1warn", "value": "privileged"},
    {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1warn-version", "value": "v1.24"},
    {"op": "add", "path": "/metadata/labels/security.openshift.io~1scc.podSecurityLabelSync", "value": "true"},
    {"op": "add", "path": "/spec", "value": {"finalizers": ["kubernetes"]}}
    ]'
- apiVersion: v1
  kind: Namespace
  name: openshift-storage
  reason: "known deviation"
  templatePath: namespace.yaml
  type: go-template
  patch: |
    {
        "type": "rfc6902",
        "patch": '[
            {"op": "add", "path": "/metadata/annotations/openshift.io~1sa.scc.mcs", "value": "s0:c29,c14"},
            {"op": "add", "path": "/metadata/annotations/openshift.io~1sa.scc.supplemental-groups", "value": "1000840000/10000"},
            {"op": "add", "path": "/metadata/annotations/openshift.io~1sa.scc.uid-range", "value": "1000840000/10000"},
            {"op": "add", "path": "/metadata/annotations/reclaimspace.csiaddons.openshift.io~1schedule", "value": "@weekly"},
            {"op": "remove", "path": "/metadata/annotations/workload.openshift.io~1allowed"},
            {"op": "add", "path": "/metadata/labels/kubernetes.io~1metadata.name", "value": "openshift-storage"},
            {"op": "add", "path": "/metadata/labels/olm.operatorgroup.uid~1ffcf3f2d-3e37-4772-97bc-983cdfce128b", "value": ""},
            {"op": "add", "path": "/metadata/labels/openshift.io~1cluster-monitoring", "value": "false"},
            {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1audit", "value": "privileged"},
            {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1audit-version", "value": "v1.24"},
            {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1warn", "value": "privileged"},
            {"op": "add", "path": "/metadata/labels/pod-security.kubernetes.io~1warn-version", "value": "v1.24"},
            {"op": "add", "path": "/metadata/labels/security.openshift.io~1scc.podSecurityLabelSync", "value": "true"},
            {"op": "add", "path": "/spec", "value": {"finalizers": {{ .spec.finalizers | toJson }} }}
        ]'
    }

    1
    パッチは kind、apiVersion、name、および namespace フィールドを使用して、パッチを正しいクラスター CR とマッチします。

  2. 次のコマンドを実行して、リファレンス設定にパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc cluster-compare -r <referenceConfigurationDirectory> -p <path_to_patches_file>
    • -r は、リファレンス設定の metadata.yaml ファイルへのパスを指定します。

    • p は、パッチファイルへのパスを指定します。

      出力例

      Copy to Clipboard Toggle word wrap 
      ...

Cluster CR: storage.k8s.io/v1_StorageClass_crc-csi-hostpath-provisioner
Reference File: namespace.yaml
Description: Component description
Diff Output: None
Patched with patch
Patch Reasons:
- known deviation
- known deviation
- known deviation

...

No CRs are unmatched to reference CRs
Metadata Hash: bb2165004c496b32e0c8509428fb99c653c3cf4fba41196ea6821bd05c3083ab
Cluster CRs with patches applied: 1

5.6. cluster-compare のトラブルシューティング

cluster-compare プラグインを使用すると、複数のクラスターカスタムリソース (CR) が存在する場合に、誤検知や競合などの予期しない結果が表示されることがあります。

5.6.1. 存在しないリソースの誤検知のトラブルシューティング

クラスター内にクラスターカスタムリソース (CR) が存在する場合でも、リソースが存在しないと報告される場合があります。

手順

  1. 最新バージョンの cluster-compare プラグインを使用していることを確認します。詳細は、「cluster-compare プラグインのインストール」を参照してください。
  2. 最新バージョンのリファレンス設定を使用していることを確認します。
  3. テンプレートに、クラスター CR と同じ apiVersion、kind、name、および namespace フィールドがあることを確認します。

5.6.2. 同じ CR に複数のテンプレートがマッチする問題のトラブルシューティング

場合によっては、複数のクラスター CR に同じ apiVersion、namespace、および kind が含まれているため、それらがテンプレートとマッチすることがあります。プラグインによるデフォルトのマッチングでは、差異が最も少ない CR が比較されます。

必要に応じて、このような状況を回避するようにリファレンス設定を指定できます。

手順

  1. テンプレートのマッチングが重複しないように、各テンプレートに異なる apiVersion、namespace、および kind の値が含まれていることを確認します。
  2. ユーザー設定ファイルを使用して、テンプレートと CR を手動でマッチします。詳細は、「CR とテンプレート間の手動マッチングの設定」を参照してください。

5.6.3. 関連情報

第6章 オブジェクトの最大値に合わせた環境計画

OpenShift Container Platform クラスターの計画時に以下のテスト済みのオブジェクトの最大値を考慮します。

これらのガイドラインは、最大規模のクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。指定のしきい値に影響を与える要因には、etcd バージョンやストレージデータ形式などの多数の要因があります。

ほとんど場合、これらの制限値を超えると、パフォーマンスが全体的に低下します。ただし、これによって必ずしもクラスターに障害が発生する訳ではありません。

警告

Pod の起動および停止が多数あるクラスターなど、急速な変更が生じるクラスターは、実質的な最大サイズが記録よりも小さくなることがあります。

6.1. メジャーリリースに関する OpenShift Container Platform のテスト済みクラスターの最大値

注記

Red Hat は、OpenShift Container Platform クラスターのサイズ設定に関する直接的なガイダンスを提供していません。これは、クラスターが OpenShift Container Platform のサポート範囲内にあるかどうかを判断するには、クラスターのスケールを制限するすべての多次元な要因を慎重に検討する必要があるためです。

OpenShift Container Platform は、クラスターの絶対最大値ではなく、テスト済みのクラスター最大値をサポートします。OpenShift Container Platform のバージョン、コントロールプレーンのワークロード、およびネットワークプラグインのすべての組み合わせがテストされているわけではないため、以下の表は、すべてのデプロイメントの規模の絶対的な期待値を表すものではありません。すべてのディメンションを同時に最大にスケーリングすることはできない場合があります。この表には、特定のワークロードとデプロイメント設定に対してテストされた最大値が含まれており、同様のデプロイメントで何が期待できるかに関するスケールガイドとして機能します。

最大値のタイプ4.x テスト済みの最大値

ノード数

2,000 [1]

Pod の数[2]

150,000

ノードあたりの Pod 数

2,500 [3]

コアあたりの Pod 数

デフォルト値はありません。

namespace の数[4]

10,000

ビルド数

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

namespace ごとの Pod の数[5]

25,000

Ingress Controller ごとのルートとバックエンドの数

ルーターあたり 2,000

シークレットの数

80,000

config map の数

90,000

サービスの数[6]

10,000

namespace ごとのサービス数

5,000

サービスごとのバックエンド数

5,000

namespace ごとのデプロイメントの数[5]

2,000

ビルド設定の数

12,000

カスタムリソース定義 (CRD) の数

1,024 [7]

  1. 一時停止 Pod は、2000 ノードスケールで OpenShift Container Platform のコントロールプレーンコンポーネントにストレスをかけるためにデプロイされました。同様の数値にスケーリングできるかどうかは、特定のデプロイメントとワークロードのパラメーターによって異なります。
  2. ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、およびストレージ要件により異なります。
  3. これは、31 台のサーバー (3 つのコントロールプレーン、2 つのインフラストラクチャーノード、および 26 のワーカーノード) を備えたクラスターでテストされました。2,500 のユーザー Pod が必要な場合は、各ノードが 2000 超の Pod を内包できる規模のネットワークを割り当てるために hostPrefix を 20 に設定し、カスタム kubelet 設定で maxPods を 2500 に設定する必要があります。詳細は、OCP 4.13 でノードごとに 2500 Pod を実行する を参照してください。
  4. 有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強く推奨します。
  5. システムには、状態遷移への対応として、指定された namespace 内のすべてのオブジェクトに対して反復処理する必要がある制御ループがいくつかあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
  6. 各サービスポートと各サービスのバックエンドには、iptables に対応するエントリーがあります。特定のサービスのバックエンドの数は、Endpoints オブジェクトのサイズに影響を与え、システム全体に送信されるデータのサイズに影響を与えます。
  7. 29 台のサーバーでテストされたクラスター: 3 つのコントロールプレーン、2 つのインフラストラクチャーノード、および 24 ワーカーノード。クラスターには 500 の namespace がありました。OpenShift Container Platform では、OpenShift Container Platform によってインストールされるカスタムリソース定義 (CRD)、OpenShift Container Platform と統合される製品、およびユーザーが作成した CRD を含むカスタムリソース定義 (CRD) の合計数が 1,024 に制限されます。作成された CRD の数が 1,024 を超える場合、oc コマンドリクエストのスロットリングが適用される可能性があります。

6.1.1. シナリオ例

例として、OpenShift Container Platform 4.18、OVN-Kubernetes ネットワークプラグイン、および以下のワークロードオブジェクトを使用して、500 個のワーカーノード (m5.2xl) がテストされ、サポートされています。

  • デフォルトに加えて、200 個の namespace
  • ノードあたり 60 Pod。30 台のサーバーと 30 台のクライアント Pod (合計 30k)
  • 57 イメージストリーム/ns (合計 11.4k)
  • サーバー Pod によってサポートされる 15 サービス/ns (合計 3k)
  • 以前のサービスに裏打ちされた 15 ルート/ns (合計 3k)
  • 20 シークレット/ns (合計 4k)
  • 10 設定マップ/ns (合計 2k)
  • 6 つのネットワークポリシー/ns (すべて拒否、イングレスから許可、ネームスペース内ルールを含む)
  • 57 ビルド/ns

次の要因は、クラスターのワークロードのスケーリングにプラスまたはマイナスの影響を与えることがわかっており、デプロイメントを計画するときにスケールの数値に考慮する必要があります。追加情報とガイダンスについては、営業担当者または Red Hat サポート にお問い合わせください。

  • ノードあたりの Pod 数
  • Pod あたりのコンテナー数
  • 使用されるプローブのタイプ (liveness/readiness、exec/http など)
  • ネットワークポリシーの数
  • プロジェクトまたは namespace の数
  • プロジェクトあたりのイメージストリーム数
  • プロジェクトあたりのビルド数
  • サービス/エンドポイントの数とタイプ
  • ルート数
  • シャード数
  • シークレットの数
  • config map の数

  • API 呼び出しのレート、またはクラスターの “チャーン“。これは、クラスター設定内で物事が変化する速さの推定値です。

    • 5 分間のウィンドウでの 1 秒あたりの Pod 作成リクエストの Prometheus クエリー: sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m]))
    • 5 分間のウィンドウで 1 秒あたりのすべての API リクエストに対する Prometheus クエリー: sum(irate(apiserver_request_count{}[5m]))
  • CPU のクラスターノードリソース消費量
  • メモリーのクラスターノードリソース消費量

6.2. クラスターの最大値がテスト済みの OpenShift Container Platform 環境および設定

6.2.1. AWS クラウドプラットフォーム:

ノードフレーバーvCPURAM(GiB)ディスクタイプディスクサイズ (GiB)/IOSカウントリージョン

コントロールプレーン/etcd [1]

r5.4xlarge

16

128

gp3

220

3

us-west-2

インフラ [2]

m5.12xlarge

48

192

gp3

100

3

us-west-2

ワークロード [3]

m5.4xlarge

16

64

gp3

500 [4]

1

us-west-2

コンピュート

m5.2xlarge

8

32

gp3

100

3/25/250/500 [5]

us-west-2

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

6.2.2. IBM Power プラットフォーム

ノードvCPURAM(GiB)ディスクタイプディスクサイズ (GiB)/IOSカウント

コントロールプレーン/etcd [1]

16

32

io1

GiB あたり 120/10 IOPS

3

インフラ [2]

16

64

gp2

120

2

ワークロード [3]

16

256

gp2

120 [4]

1

コンピュート

16

64

gp2

120

2 から 100 [5]

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

6.2.3. IBM Z プラットフォーム

ノードvCPU [4]RAM(GiB)[5]ディスクタイプディスクサイズ (GiB)/IOSカウント

コントロールプレーン/etcd [1,2]

8

32

ds8k

300 / LCU 1

3

コンピュート [1,3]

8

32

ds8k

150 / LCU 2

4 ノード (ノードあたり 100/250/500 Pod にスケーリング)

  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 です。

6.3. テスト済みのクラスターの最大値に基づく環境計画

重要

ノード上で物理リソースを過剰にサブスクライブすると、Kubernetes スケジューラーが Pod の配置時に行うリソースの保証に影響が及びます。メモリースワップを防ぐために実行できる処置について確認してください。

一部のテスト済みの最大値については、単一のディメンションが作成するオブジェクトでのみ変更されます。これらの制限はクラスター上で数多くのオブジェクトが実行されている場合には異なります。

このドキュメントに記載されている数は、Red Hat のテスト方法、セットアップ、設定、およびチューニングに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。

環境の計画時に、ノードに配置できる Pod 数を判別します。

Copy to Clipboard Toggle word wrap 
required pods per cluster / pods per node = total number of nodes needed

ノードあたりの Pod のデフォルトの最大数は 250 です。ただし、ノードに適合する Pod 数はアプリケーション自体によって異なります。「アプリケーション要件に合わせて環境計画を立てる方法」で説明されているように、アプリケーションのメモリー、CPU およびストレージの要件を検討してください。

シナリオ例

クラスターごとに 2200 の Pod のあるクラスターのスコープを設定する場合、ノードごとに最大 500 の Pod があることを前提として、最低でも 5 つのノードが必要になります。

Copy to Clipboard Toggle word wrap 
2200 / 500 = 4.4

ノード数を 20 に増やす場合は、Pod 配分がノードごとに 110 の Pod に変わります。

Copy to Clipboard Toggle word wrap 
2200 / 20 = 110

ここでは、以下のようになります。

Copy to Clipboard Toggle word wrap 
required pods per cluster / total number of nodes = expected pods per node

OpenShift Container Platform には、OVN-Kubernetes、DNS、Operators など、デフォルトですべてのワーカーノードで実行するいくつかのシステム Pod が付属しています。したがって、上記の式の結果は異なる場合があります。

6.4. アプリケーション要件に合わせて環境計画を立てる方法

アプリケーション環境の例を考えてみましょう。

Pod タイプPod 数最大メモリーCPU コア数永続ストレージ

apache

100

500 MB

0.5

1 GB

node.js

200

1 GB

1

1 GB

postgresql

100

1 GB

2

10 GB

JBoss EAP

100

1 GB

1

1 GB

推定要件: CPU コア 550 個、メモリー 450GB およびストレージ 1.4TB

ノードのインスタンスサイズは、希望に応じて増減を調整できます。ノードのリソースはオーバーコミットされることが多く、デプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。このデプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。運用上の敏捷性やインスタンスあたりのコストなどの要因を考慮する必要があります。

ノードのタイプ数量CPURAM (GB)

ノード (オプション 1)

100

4

16

ノード (オプション 2)

50

8

32

ノード (オプション 3)

25

16

64

アプリケーションによってはオーバーコミットの環境に適しているものもあれば、そうでないものもあります。たとえば、Java アプリケーションや Huge Page を使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境は一般的な比率として約 30 % オーバーコミットされています。

アプリケーション Pod は環境変数または DNS のいずれかを使用してサービスにアクセスできます。環境変数を使用する場合、それぞれのアクティブなサービスについて、変数が Pod がノードで実行される際に kubelet によって挿入されます。クラスター対応の DNS サーバーは、Kubernetes API で新規サービスの有無を監視し、それぞれに DNS レコードのセットを作成します。DNS がクラスター全体で有効にされている場合、すべての Pod は DNS 名でサービスを自動的に解決できるはずです。DNS を使用したサービス検出は、5000 サービスを超える使用できる場合があります。サービス検出に環境変数を使用する場合、引数のリストは namespace で 5000 サービスを超える場合の許可される長さを超えると、Pod およびデプロイメントは失敗します。デプロイメントのサービス仕様ファイルのサービスリンクを無効にして、以下を解消します。

Copy to Clipboard Toggle word wrap 
---
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: apps.openshift.io/v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    clusterIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template

namespace で実行できるアプリケーション Pod の数は、環境変数がサービス検出に使用される場合にサービスの数およびサービス名の長さによって異なります。システムの ARG_MAX は、新規プロセスの引数の最大の長さを定義し、デフォルトで 2097152 バイト (2 MiB) に設定されます。Kubelet は、以下を含む namespace で実行するようにスケジュールされる各 Pod に環境変数を挿入します。

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

引数の長さが許可される値を超え、サービス名の文字数がこれに影響する場合、namespace の Pod は起動に失敗し始めます。たとえば、5000 サービスを含む namespace では、サービス名の制限は 33 文字であり、これにより namespace で 5000 Pod を実行できます。

第7章 クォータと制限範囲の使用

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。

クラスター管理者は、クォータと制限範囲を使用して制約を設定し、プロジェクトで使用されるオブジェクトの数やコンピュートリソースの量を制限できます。これは、管理者がすべてのプロジェクトでリソースの効果的な管理および割り当てを実行し、いずれのプロジェクトでの使用量がクラスターサイズに対して適切な量を超えることのないようにするのに役立ちます。

重要

クォータはクラスター管理者によって設定され、所定プロジェクトにスコープが設定されます。OpenShift Container Platform プロジェクトの所有者は、プロジェクトのクォータを変更できますが、範囲を制限することはできません。OpenShift Container Platform ユーザーは、クォータや制限範囲を変更できません。

以下のセクションは、クォータおよび制限範囲の設定を確認し、それらの制約対象や、独自の Pod およびコンテナーでコンピュートリソースを要求し、制限する方法を理解するのに役立ちます。

7.1. クォータで管理されるリソース

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。

以下では、クォータで管理できる一連のコンピュートリソースとオブジェクトタイプを説明します。

注記

status.phase が Failed または Succeeded の場合、Pod は終了状態になります。

表7.1 クォータで管理されるコンピュートリソース
リソース名説明

cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値であり、相互に置き換え可能なものとして使用できます。

memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません。memory および requests.memory は同じ値であり、相互に置き換え可能なものとして使用できます。

ephemeral-storage

非終了状態のすべての Pod におけるローカルの一時ストレージ要求の合計は、この値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

requests.cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値であり、相互に置き換え可能なものとして使用できます。

requests.memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません。memory および requests.memory は同じ値であり、相互に置き換え可能なものとして使用できます。

requests.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ要求の合計は、この値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

limits.cpu

非終了状態のすべての Pod での CPU 制限の合計はこの値を超えることができません。

limits.memory

非終了状態のすべての Pod でのメモリー制限の合計はこの値を超えることができません。

limits.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ制限の合計は、この値を超えることができません。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

表7.2 クォータで管理されるストレージリソース
リソース名説明

requests.storage

任意の状態のすべての永続ボリューム要求でのストレージ要求の合計は、この値を超えることができません。

persistentvolumeclaims

プロジェクトに存在できる永続ボリューム要求の合計数です。

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

一致するストレージクラスを持つ、任意の状態のすべての永続ボリューム要求でのストレージ要求の合計はこの値を超えることができません。

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

プロジェクトに存在できる、一致するストレージクラスを持つ永続ボリューム要求の合計数です。

表7.3 クォータで管理されるオブジェクト数
リソース名説明

pods

プロジェクトに存在できる非終了状態の Pod の合計数です。

replicationcontrollers

プロジェクトに存在できるレプリケーションコントローラーの合計数です。

resourcequotas

プロジェクトに存在できるリソースクォータの合計数です。

services

プロジェクトに存在できるサービスの合計数です。

secrets

プロジェクトに存在できるシークレットの合計数です。

configmaps

プロジェクトに存在できる ConfigMap オブジェクトの合計数です。

persistentvolumeclaims

プロジェクトに存在できる永続ボリューム要求の合計数です。

openshift.io/imagestreams

プロジェクトに存在できるイメージストリームの合計数です。

count/<resource>.<group> 構文を使用して、これらの標準の namespace リソースタイプに対してオブジェクトカウントクォータを設定できます。

Copy to Clipboard Toggle word wrap 
$ oc create quota <name> --hard=count/<resource>.<group>=<quota>
1
1
<resource> はリソースの名前であり、<group> は API グループです (該当する場合)。リソースおよびそれらの関連付けられた API グループのリストに kubectl api-resources コマンドを使用します。

7.1.1. 拡張リソースのリソースクォータの設定

リソースのオーバーコミットは拡張リソースには許可されません。そのため、クォータで同じ拡張リソースの requests および limits を指定する必要があります。現時点で、接頭辞 requests. のあるクォータ項目のみが拡張リソースに許可されます。以下は、GPU リソース nvidia.com/gpu のリソースクォータを設定する方法のシナリオ例です。

手順

  1. クラスター内のノードで使用可能な GPU の数を確認するには、次のコマンドを使用します。

    Copy to Clipboard Toggle word wrap 
    $ oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'

    出力例

    Copy to Clipboard Toggle word wrap 
                        openshift.com/gpu-accelerator=true
Capacity:
 nvidia.com/gpu:  2
Allocatable:
 nvidia.com/gpu:  2
 nvidia.com/gpu:  0           0

    この例では、2 つの GPU が利用可能です。

  2. このコマンドを使用して、namespace nvidia にクォータを設定します。この例では、クォータは 1 です。

    Copy to Clipboard Toggle word wrap 
    $ cat gpu-quota.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: nvidia
spec:
  hard:
    requests.nvidia.com/gpu: 1

  3. 次のコマンドでクォータを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f gpu-quota.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    resourcequota/gpu-quota created

  4. 次のコマンドを使用して、namespace に正しいクォータが設定されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc describe quota gpu-quota -n nvidia

    出力例

    Copy to Clipboard Toggle word wrap 
    Name:                    gpu-quota
Namespace:               nvidia
Resource                 Used  Hard
--------                 ----  ----
requests.nvidia.com/gpu  0     1

  5. 次のコマンドを使用して、単一の GPU を要求する Pod を実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc create pod gpu-pod.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: Pod
metadata:
  generateName: gpu-pod-s46h7
  namespace: nvidia
spec:
  restartPolicy: OnFailure
  containers:
  - name: rhel7-gpu-pod
    image: rhel7
    env:
      - name: NVIDIA_VISIBLE_DEVICES
        value: all
      - name: NVIDIA_DRIVER_CAPABILITIES
        value: "compute,utility"
      - name: NVIDIA_REQUIRE_CUDA
        value: "cuda>=5.0"

    command: ["sleep"]
    args: ["infinity"]

    resources:
      limits:
        nvidia.com/gpu: 1

  6. 次のコマンドを使用して、Pod が実行されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pods

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME              READY     STATUS      RESTARTS   AGE
gpu-pod-s46h7     1/1       Running     0          1m

  7. 次のコマンドを実行して、クォータ Used カウンターが正しいことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc describe quota gpu-quota -n nvidia

    出力例

    Copy to Clipboard Toggle word wrap 
    Name:                    gpu-quota
Namespace:               nvidia
Resource                 Used  Hard
--------                 ----  ----
requests.nvidia.com/gpu  1     1

  8. 次のコマンドを使用して、nvidia namespace に 2 番目の GPU Pod を作成してみます。2 つの GPU があるので、これをノード上で実行することは可能です。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f gpu-pod.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1

    この Forbidden エラーメッセージは、クォータが 1 GPU であり、この Pod がクォータを超える 2 番目の GPU を割り当てようとしたために発生します。

7.1.2. クォータのスコープ

各クォータには スコープ のセットが関連付けられます。クォータは、列挙されたスコープの交差部分に一致する場合にのみリソースの使用状況を測定します。

スコープをクォータに追加すると、クォータが適用されるリソースのセットを制限できます。許可されるセット以外のリソースを設定すると、検証エラーが発生します。

スコープ説明

Terminating

spec.activeDeadlineSeconds >= 0 の Pod に一致します。

NotTerminating

spec.activeDeadlineSeconds が nil の Pod に一致します。

BestEffort

cpu または memory のいずれかに関するサービスの QoS (Quality of Service) が Best Effort の Pod に一致します。

otBestEffort

cpu および memory に関するサービスの QoS (Quality of Service) が Best Effort ではない Pod に一致します。

BestEffort スコープは、以下のリソースに制限するようにクォータを制限します。

  • pods

Terminating、NotTerminating、および NotBestEffort スコープは、以下のリソースを追跡するようにクォータを制限します。

  • pods
  • memory
  • requests.memory
  • limits.memory
  • cpu
  • requests.cpu
  • limits.cpu
  • ephemeral-storage
  • requests.ephemeral-storage
  • limits.ephemeral-storage
注記

一時ストレージ要求と制限は、テクノロジープレビューとして提供されている一時ストレージを有効にした場合にのみ適用されます。この機能はデフォルトでは無効にされています。

関連情報

コンピュートリソースの詳細は、クォータによって管理されるリソース を参照してください。

コンピュートリソースのコミットの詳細は、Quality of Service (QoS) クラス を参照してください。

7.2. 管理者のクォータ使用量

7.2.1. クォータの実施

プロジェクトのリソースクォータが最初に作成されると、プロジェクトは、更新された使用状況の統計情報が計算されるまでクォータ制約の違反を引き起こす可能性のある新規リソースの作成機能を制限します。

クォータが作成され、使用状況の統計が更新されると、プロジェクトは新規コンテンツの作成を許可します。リソースを作成または変更する場合、クォータの使用量はリソースの作成または変更要求があるとすぐに増分します。

リソースを削除する場合、クォータの使用量は、プロジェクトのクォータ統計の次回の完全な再計算時に減分されます。

設定可能な時間を指定して、クォータ使用量の統計値を現在確認されるシステム値まで下げるのに必要な時間を決定します。

プロジェクト変更がクォータ使用制限を超える場合、サーバーはそのアクションを拒否し、クォータ制約を違反していること、およびシステムで現在確認される使用量の統計値を示す適切なエラーメッセージがユーザーに返されます。

7.2.2. リクエストと制限の比較

コンピュートリソースをクォータによって割り当てる場合、各コンテナーは CPU、メモリー、および一時ストレージのそれぞれに対して要求値と制限値を指定できます。クォータはこれらの値のいずれも制限できます。

クォータに requests.cpu または requests.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースを明示的に要求することが求められます。クォータに limits.cpu または limits.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースの明示的な制限を指定することが求められます。

7.2.3. リソースクォータ定義の例

core-object-counts.yaml の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10"
1 

    persistentvolumeclaims: "4"
2 

    replicationcontrollers: "20"
3 

    secrets: "10"
4 

    services: "10"
5

1
プロジェクトに存在できる ConfigMap オブジェクトの合計数です。
2
プロジェクトに存在できる永続ボリューム要求 (PVC) の合計数です。
3
プロジェクトに存在できるレプリケーションコントローラーの合計数です。
4
プロジェクトに存在できるシークレットの合計数です。
5
プロジェクトに存在できるサービスの合計数です。

openshift-object-counts.yaml の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10"
1

1
プロジェクトに存在できるイメージストリームの合計数です。

compute-resources.yaml の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"
1 

    requests.cpu: "1"
2 

    requests.memory: 1Gi
3 

    requests.ephemeral-storage: 2Gi
4 

    limits.cpu: "2"
5 

    limits.memory: 2Gi
6 

    limits.ephemeral-storage: 4Gi
7

1
プロジェクトに存在できる非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 要求の合計は 1 コアを超えることができません。
3
非終了状態のすべての Pod において、メモリー要求の合計は 1 Gi を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ要求の合計は 2 Gi を超えることができません。
5
非終了状態のすべての Pod において、CPU 制限の合計は 2 コアを超えることができません。
6
非終了状態のすべての Pod において、メモリー制限の合計は 2 Gi を超えることができません。
7
非終了状態のすべての Pod において、一時ストレージ制限の合計は 4 Gi を超えることができません。

besteffort.yaml の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1"
1 

  scopes:
  - BestEffort
2

1
プロジェクトに存在できる QoS (Quality of Service) が BestEffort の非終了状態の Pod の合計数です
2
クォータを、メモリーまたは CPU のいずれかの QoS (Quality of Service) が BestEffort の一致する Pod のみに制限します。

compute-resources-long-running.yaml の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4"
1 

    limits.cpu: "4"
2 

    limits.memory: "2Gi"
3 

    limits.ephemeral-storage: "4Gi"
4 

  scopes:
  - NotTerminating
5

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。
5
クォータを spec.activeDeadlineSeconds が nil に設定されている一致する Pod のみに制限します。ビルド Pod は、RestartNever ポリシーが適用されない場合に NotTerminating になります。

compute-resources-time-bound.yaml の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2"
1 

    limits.cpu: "1"
2 

    limits.memory: "1Gi"
3 

    limits.ephemeral-storage: "1Gi"
4 

  scopes:
  - Terminating
5

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。
5
クォータを spec.activeDeadlineSeconds >=0 に設定されている一致する Pod のみに制限します。たとえば、このクォータではビルド Pod に対して課金されますが、Web サーバーやデータベースなどの長時間実行される Pod に対しては課金されません。

storage-consumption.yaml の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10"
1 

    requests.storage: "50Gi"
2 

    gold.storageclass.storage.k8s.io/requests.storage: "10Gi"
3 

    silver.storageclass.storage.k8s.io/requests.storage: "20Gi"
4 

    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5"
5 

    bronze.storageclass.storage.k8s.io/requests.storage: "0"
6 

    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0"
7

1
プロジェクト内の永続ボリューム要求の合計数です。
2
プロジェクトのすべての永続ボリューム要求において、要求されるストレージの合計はこの値を超えることができません。
3
プロジェクトのすべての永続ボリューム要求において、gold ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
4
プロジェクトのすべての永続ボリューム要求において、silver ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
5
プロジェクトのすべての永続ボリューム要求において、silver ストレージクラスの要求の合計数はこの値を超えることができません。
6
プロジェクトのすべての永続ボリューム要求において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合、bronze ストレージクラスはストレージを要求できないことを意味します。
7
プロジェクトのすべての永続ボリューム要求において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合は、bronze ストレージクラスでは要求を作成できないことを意味します。

7.2.4. クォータの作成

クォータを作成するには、まずファイルでクォータを定義します。次に、そのファイルを使用してプロジェクトに適用します。これを説明するリンクは、関連情報セクションを参照してください。

Copy to Clipboard Toggle word wrap 
$ oc create -f <resource_quota_definition> [-n <project_name>]

以下は、core-object-counts.yaml リソースクォータ定義と demoproject プロジェクト名を使用した例です。

Copy to Clipboard Toggle word wrap 
$ oc create -f core-object-counts.yaml -n demoproject

7.2.5. オブジェクトカウントクォータの作成

BuildConfig および DeploymentConfig などの、OpenShift Container Platform の標準的な namespace を使用しているリソースタイプのすべてにオブジェクトカウントクォータを作成できます。オブジェクトクォータカウントは、定義されたクォータをすべての標準的な namespace を使用しているリソースタイプに設定します。

リソースクォータの使用時に、オブジェクトがサーバーストレージにある場合、そのオブジェクトはクォータに基づいてチャージされます。以下のクォータのタイプはストレージリソースが使い切られることから保護するのに役立ちます。

リソースのオブジェクトカウントクォータを設定するには、以下のコマンドを実行します。

Copy to Clipboard Toggle word wrap 
$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>

オブジェクトカウントクォータの表示例:

Copy to Clipboard Toggle word wrap 
$ oc create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4
resourcequota "test" created

$ oc describe quota test
Name:                         test
Namespace:                    quota
Resource                      Used  Hard
--------                      ----  ----
count/deployments.extensions  0     2
count/pods                    0     3
count/replicasets.extensions  0     4
count/secrets                 0     4

この例では、リスト表示されたリソースをクラスター内の各プロジェクトのハード制限に制限します。

7.2.6. クォータの表示

Web コンソールでプロジェクトの Quota ページに移動し、プロジェクトのクォータで定義されるハード制限に関連する使用状況の統計情報を表示できます。

CLI を使用してクォータの詳細を表示することもできます。

  1. 最初に、プロジェクトで定義されたクォータのリストを取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc get quota -n demoproject
NAME                AGE
besteffort          11m
compute-resources   2m
core-object-counts  29m

  2. 関連するクォータを記述します。たとえば、core-object-counts クォータの場合、以下を実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc describe quota core-object-counts -n demoproject
Name:			core-object-counts
Namespace:		demoproject
Resource		Used	Hard
--------		----	----
configmaps		3	10
persistentvolumeclaims	0	4
replicationcontrollers	3	20
secrets			9	10
services		2	10

7.2.7. クォータの同期期間の設定

リソースのセットが削除される際に、リソースの同期期間が /etc/origin/master/master-config.yaml ファイルの resource-quota-sync-period 設定によって決定されます。

クォータの使用状況が復元される前に、ユーザーがリソースの再使用を試行すると問題が発生する場合があります。resource-quota-sync-period 設定を変更して、リソースセットの再生成が所定の期間 (秒単位) に実行され、リソースを再度利用可能にすることができます。

resource-quota-sync-period 設定例

Copy to Clipboard Toggle word wrap 
kubernetesMasterConfig:
  apiLevels:
  - v1beta3
  - v1
  apiServerArguments: null
  controllerArguments:
    resource-quota-sync-period:
      - "10s"

変更を加えたら、コントローラーサービスを再起動して変更を適用します。

Copy to Clipboard Toggle word wrap 
$ master-restart api
$ master-restart controllers

再生成時間の調整は、リソースの作成および自動化が使用される場合のリソース使用状況の判別に役立ちます。

注記

resource-quota-sync-period 設定により、システムパフォーマンスのバランスが保たれます。同期期間を短縮すると、コントローラーに大きな負荷がかかる可能性があります。

7.2.8. リソースを消費するための明示的なクォータ

リソースがクォータで管理されていない場合、ユーザーには消費できるリソース量の制限がありません。たとえば、gold ストレージクラスに関連するストレージのクォータがない場合、プロジェクトが作成できる gold ストレージの容量はバインドされません。

高コストのコンピュートまたはストレージリソースの場合、管理者はリソースを消費するために明示的なクォータを付与することを要求できます。たとえば、プロジェクトに gold ストレージクラスに関連するストレージのクォータが明示的に付与されていない場合、そのプロジェクトのユーザーはこのタイプのストレージを作成することができません。

特定リソースの消費における明示的なクォータが必要となるようにするには、以下のスタンザを master-config.yaml に追加する必要があります。

Copy to Clipboard Toggle word wrap 
admissionConfig:
  pluginConfig:
    ResourceQuota:
      configuration:
        apiVersion: resourcequota.admission.k8s.io/v1alpha1
        kind: Configuration
        limitedResources:
        - resource: persistentvolumeclaims
1 

        matchContains:
        - gold.storageclass.storage.k8s.io/requests.storage
2
1
デフォルトで消費が制限されるグループまたはリソース。
2
デフォルトで制限対象となる、グループ/リソースに関連付けられたクォータで追跡されるリソースの名前です。

上記の例では、クォータシステムは PersistentVolumeClaim を作成するか、または更新するすべての操作をインターセプトします。クォータによって制御されるリソースの消費を確認します。プロジェクト内にそれらのリソースをカバーするクォータがない場合、リクエストは拒否されます。この例では、ユーザーがゴールドストレージクラスに関連付けられたストレージを使用する PersistentVolumeClaim を作成し、プロジェクト内に一致するクォータがない場合、リクエストは拒否されます。

関連情報

クォータを設定するために必要なファイルを作成する方法の例は、クォータによって管理されるリソース を参照してください。

クォータによって管理されるコンピュートリソース を割り当てる方法の説明。

プロジェクトリソースの制限とクォータの管理は、プロジェクトの使用 を参照してください。

プロジェクトにクォータが定義されている場合は、デプロイメントについて でクラスター設定の考慮事項を参照してください。

7.3. 制限範囲の設定

LimitRange オブジェクトによって定義される制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、および永続ボリューム要求レベルでのコンピュートリソース制約を定義します。制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、または永続ボリューム要求が消費できるリソースの量を指定します。

すべてのリソース作成および変更要求は、プロジェクトのそれぞれの LimitRange オブジェクトに対して評価されます。リソースが列挙される制約のいずれかに違反する場合、そのリソースは拒否されます。リソースが明示的な値を指定しない場合で、制約がデフォルト値をサポートする場合は、デフォルト値がリソースに適用されます。

CPU とメモリーの制限について、最大値を指定しても最小値を指定しない場合、リソースは最大値よりも多くの CPU とメモリーリソースを消費する可能性があります。

コア制限範囲オブジェクトの定義

Copy to Clipboard Toggle word wrap 
apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits"
1 

spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2"
2 

        memory: "1Gi"
3 

      min:
        cpu: "200m"
4 

        memory: "6Mi"
5 

    - type: "Container"
      max:
        cpu: "2"
6 

        memory: "1Gi"
7 

      min:
        cpu: "100m"
8 

        memory: "4Mi"
9 

      default:
        cpu: "300m"
10 

        memory: "200Mi"
11 

      defaultRequest:
        cpu: "200m"
12 

        memory: "100Mi"
13 

      maxLimitRequestRatio:
        cpu: "10"
14

1
制限範囲オブジェクトの名前です。
2
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。
3
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。
4
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
5
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
6
Pod の単一コンテナーが要求できる CPU の最大量です。
7
Pod の単一コンテナーが要求できるメモリーの最大量です。
8
Pod の単一コンテナーが要求できる CPU の最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
9
Pod の単一コンテナーが要求できるメモリーの最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
10
Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトの CPU 制限。
11
Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトのメモリー制限。
12
Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトの CPU 要求。
13
Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトのメモリー要求。
14
コンテナーの要求に対する制限の最大比率。

OpenShift Container Platform の制限範囲オブジェクトの定義

Copy to Clipboard Toggle word wrap 
apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "openshift-resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi
1 

    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20
2 

        openshift.io/images: 30
3 

    - type: "Pod"
      max:
        cpu: "2"
4 

        memory: "1Gi"
5 

        ephemeral-storage: "1Gi"
6 

      min:
        cpu: "1"
7 

        memory: "1Gi"
8

1
内部レジストリーにプッシュできるイメージの最大サイズ。
2
イメージストリームの仕様で定義される一意のイメージタグの最大数。
3
イメージストリームのステータスについて仕様で定義される一意のイメージ参照の最大数。
4
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。
5
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。
6
すべてのコンテナーにわたって、Pod がノード上で要求できる一時ストレージの最大量。
7
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。重要な情報は、「サポートされる制約」の表を参照してください。
8
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果の制限がなく、Pod は max メモリー値を超える量を消費することができます。

コアおよび OpenShift Container Platform リソースの両方を 1 つの制限範囲オブジェクトで指定できます。

7.3.1. コンテナーの制限

サポートされるリソース:

  • CPU
  • メモリー

サポートされる制約

コンテナーごとに設定されます。指定される場合、以下を満たしている必要があります。

コンテナー

制約動作

Min

Min[resource] は container.resources.requests[resource] 以下 (必須)、container/resources.limits[<resource>] 以下 (オプション)

設定で min CPU を定義している場合、要求値はその CPU 値よりも大きくなければなりません。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max 値よりも多くのリソースを消費できます。

Max

container.resources.limits[<resource>] (必須) は Max[<resource>] 以下

設定で max CPU を定義している場合、CPU 要求値を定義する必要はありません。ただし、制限範囲で指定される最大 CPU 制約を満たす制限を設定する必要があります。

MaxLimitRequestRatio

MaxLimitRequestRatio[<resource>] は (container.resources.limits[<resource>] / container.resources.requests[<resource>]) 以下

制限範囲で maxLimitRequestRatio 制約を定義する場合、新規コンテナーには request と limit 値の両方が必要になります。さらに OpenShift Container Platform は、limit を request で除算して、制限の要求に対する比率を算出します。結果は、1 を超える整数である必要があります。

たとえば、コンテナーの limit 値が cpu: 500 で、request 値が cpu: 100 である場合、cpu の要求に対する制限の比は 5 になります。この比率は maxLimitRequestRatio 以下である必要があります。

サポートされるデフォルト:

Default[<resource>]
指定がない場合は container.resources.limit[<resource>] を所定の値にデフォルト設定します。
Default Requests[<resource>]
指定がない場合は、container.resources.requests[<resource>] を所定の値にデフォルト設定します。

7.3.2. Pod の制限

サポートされるリソース:

  • CPU
  • メモリー

サポートされる制約:

Pod のすべてのコンテナーにおいて、以下を満たしている必要があります。

表7.4 Pod
制約実施される動作

Min

Min[<resource>] は container.resources.requests[<resource>] 以下 (必須)、container.resources.limits[<resource>] 以下min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max 値よりも多くのリソースを消費できます。

Max

container.resources.limits[<resource>] (必須)、Max[<resource>] 以下

MaxLimitRequestRatio

MaxLimitRequestRatio[<resource>] は (container.resources.limits[<resource>] / container.resources.requests[<resource>]) 以下

7.3.3. イメージの制限

サポートされるリソース:

  • ストレージ

リソースタイプ名:

  • openshift.io/Image

イメージごとに設定されます。指定される場合は、以下が一致している必要があります。

表7.5 イメージ
制約動作

Max

image.dockerimagemetadata.size は Max[<resource>] 以下

注記

制限を超える Blob がレジストリーにアップロードされないようにするために、クォータを実施するようレジストリーを設定する必要があります。REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA 環境変数を true に設定する必要があります。デフォルトでは、新規デプロイメントでは、環境変数は true に設定されます。

7.3.4. イメージストリームの制限

サポートされるリソース:

  • openshift.io/image-tags
  • openshift.io/images

リソースタイプ名:

  • openshift.io/ImageStream

イメージストリームごとに設定されます。指定される場合は、以下が一致している必要があります。

表7.6 ImageStream
制約動作

Max[openshift.io/image-tags]

length( uniqueimagetags( imagestream.spec.tags ) ) は Max[openshift.io/image-tags] 以下

uniqueimagetags は、指定された仕様タグのイメージへの一意の参照を返します。

Max[openshift.io/images]

length( uniqueimages( imagestream.status.tags ) ) は Max[openshift.io/images] 以下

uniqueimages はステータスタグにある一意のイメージ名を返します。名前はイメージのダイジェストと等しくなります。

7.3.5. イメージ参照のカウント

openshift.io/image-tags リソースは、一意のストリーム制限を表します。使用可能な参照は、ImageStreamTag、ImageStreamImage、または DockerImage になります。タグは、oc tag コマンドと oc import-image コマンドを使用するか、イメージストリームを使用して作成できます。内部参照か外部参照であるかの区別はありません。ただし、イメージストリームの仕様でタグ付けされる一意の参照は、それぞれ 1 回のみカウントされます。内部コンテナーイメージレジストリーへのプッシュを制限しませんが、タグの制限に役立ちます。

openshift.io/images リソースは、イメージストリームのステータスに記録される一意のイメージ名を表します。内部レジストリーにプッシュできる複数のイメージを制限するのに役立ちます。内部参照か外部参照であるかの区別はありません。

7.3.6. PersistentVolumeClaim の制限

サポートされるリソース:

  • ストレージ

サポートされる制約:

プロジェクトのすべての永続ボリューム要求において、以下が一致している必要があります。

表7.7 Pod
制約実施される動作

Min

Min[<resource>] <= claim.spec.resources.requests[<resource>] (必須)

Max

claim.spec.resources.requests[<resource>] (必須) <= Max[<resource>]

Limit Range オブジェクトの定義

Copy to Clipboard Toggle word wrap 
{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs"
1 

  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi"
2 

        },
        "max": {
          "storage": "50Gi"
3 

        }
      }
    ]
  }
}

1
制限範囲オブジェクトの名前です。
2
永続ボリューム要求で要求できるストレージの最小量です。
3
永続ボリューム要求で要求できるストレージの最大量です。

関連情報

ストリームの制限の詳細は、イメージストリームの管理 を参照してください。

詳細は、ストリーム制限 を参照してください。

詳細は、コンピュートリソースの制約 を参照してください。

CPU とメモリーの測定方法の詳細は、推奨されるコントロールプレーンのプラクティス を参照してください。

一時ストレージの制限とリクエストを指定できます。この機能の詳細は、一時ストレージについて を参照してください。

7.4. 範囲制限操作

7.4.1. 制限範囲の作成

ここでは、制限範囲を作成するための手順の例を示します。

手順

  1. オブジェクトを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f <limit_range_file> -n <project>

7.4.2. 制限を表示する

Web コンソールでプロジェクトの Quota ページに移動し、プロジェクトで定義される制限範囲を表示できます。以下の手順を実行して、CLI を使用して制限範囲の詳細を表示することもできます。

手順

  1. プロジェクトで定義される制限範囲オブジェクトのリストを取得します。たとえば、demoproject というプロジェクトの場合:

    Copy to Clipboard Toggle word wrap 
    $ oc get limits -n demoproject

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME              AGE
resource-limits   6d

  2. 制限範囲を記述します。たとえば、resource-limits という制限範囲の場合:

    Copy to Clipboard Toggle word wrap 
    $ oc describe limits resource-limits -n demoproject

    出力例

    Copy to Clipboard Toggle word wrap 
    Name:                           resource-limits
Namespace:                      demoproject
Type                            Resource                Min     Max     Default Request Default Limit   Max Limit/Request Ratio
----                            --------                ---     ---     --------------- -------------   -----------------------
Pod                             cpu                     200m    2       -               -               -
Pod                             memory                  6Mi     1Gi     -               -               -
Container                       cpu                     100m    2       200m            300m            10
Container                       memory                  4Mi     1Gi     100Mi           200Mi           -
openshift.io/Image              storage                 -       1Gi     -               -               -
openshift.io/ImageStream        openshift.io/image      -       12      -               -               -
openshift.io/ImageStream        openshift.io/image-tags -       10      -               -               -

7.4.3. 制限範囲の削除

制限範囲を削除するには、次のコマンドを実行します。

+

Copy to Clipboard Toggle word wrap 
$ oc delete limits <limit_name>

S

関連情報

ユーザーが作成できるプロジェクト数に対するさまざまな制限の適用、制限の管理、プロジェクトリソースのクォータに関する詳細は、プロジェクトごとのリソースクォータ を参照してください。

第9章 Node Tuning Operator の使用

Node Tuning Operator を説明し、この Operator を使用し、Tuned デーモンのオーケストレーションを実行してノードレベルのチューニングを管理する方法を説明します。

9.1. Node Tuning Operator について

Node Tuning Operator は、TuneD デーモンを調整することでノードレベルのチューニングを管理し、Performance Profile コントローラーを使用して低レイテンシーのパフォーマンスを実現するのに役立ちます。ほとんどの高パフォーマンスアプリケーションでは、一定レベルのカーネルのチューニングが必要です。Node Tuning Operator は、ノードレベルの sysctl の統一された管理インターフェイスをユーザーに提供し、ユーザーが指定するカスタムチューニングを追加できるよう柔軟性を提供します。

Operator は、コンテナー化された OpenShift Container Platform の TuneD デーモンを Kubernetes デーモンセットとして管理します。これにより、カスタムチューニング仕様が、デーモンが認識する形式でクラスターで実行されるすべてのコンテナー化された TuneD デーモンに渡されます。デーモンは、ノードごとに 1 つずつ、クラスターのすべてのノードで実行されます。

コンテナー化された TuneD デーモンによって適用されるノードレベルの設定は、プロファイルの変更をトリガーするイベントで、または終了シグナルの受信および処理によってコンテナー化された TuneD デーモンが正常に終了する際にロールバックされます。

Node Tuning Operator は、パフォーマンスプロファイルコントローラーを使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現します。

クラスター管理者は、以下のようなノードレベルの設定を定義するパフォーマンスプロファイルを設定します。

  • カーネルを kernel-rt に更新します。
  • ハウスキーピング用の CPU を選択します。
  • 実行中のワークロード用の CPU を選択します。

Node Tuning Operator は、バージョン 4.1 以降における標準的な OpenShift Container Platform インストールの一部となっています。

注記

OpenShift Container Platform の以前のバージョンでは、Performance Addon Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。

9.2. Node Tuning Operator 仕様サンプルへのアクセス

このプロセスを使用して Node Tuning Operator 仕様サンプルにアクセスします。

手順

  • 次のコマンドを実行して、Node Tuning Operator 仕様の例にアクセスします。

    Copy to Clipboard Toggle word wrap 
    oc get tuned.tuned.openshift.io/default -o yaml -n openshift-cluster-node-tuning-operator

デフォルトの CR は、OpenShift Container Platform プラットフォームの標準的なノードレベルのチューニングを提供することを目的としており、Operator 管理の状態を設定するためにのみ変更できます。デフォルト CR へのその他のカスタム変更は、Operator によって上書きされます。カスタムチューニングの場合は、独自のチューニングされた CR を作成します。新規に作成された CR は、ノード/Pod ラベルおよびプロファイルの優先順位に基づいて OpenShift Container Platform ノードに適用されるデフォルトの CR およびカスタムチューニングと組み合わされます。

警告

特定の状況で Pod ラベルのサポートは必要なチューニングを自動的に配信する便利な方法ですが、この方法は推奨されず、とくに大規模なクラスターにおいて注意が必要です。デフォルトの調整された CR は Pod ラベル一致のない状態で提供されます。カスタムプロファイルが Pod ラベル一致のある状態で作成される場合、この機能はその時点で有効になります。Pod ラベル機能は、Node Tuning Operator の将来のバージョンで非推奨になる予定です。

9.3. クラスターに設定されるデフォルトのプロファイル

以下は、クラスターに設定されるデフォルトのプロファイルです。

Copy to Clipboard Toggle word wrap 
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/ocp-tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40

OpenShift Container Platform 4.9 以降では、すべての OpenShift TuneD プロファイルが TuneD パッケージに含まれています。oc exec コマンドを使用して、これらのプロファイルの内容を表示できます。

Copy to Clipboard Toggle word wrap 
$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

9.4. TuneD プロファイルが適用されていることの確認

クラスターノードに適用されている TuneD プロファイルを確認します。

Copy to Clipboard Toggle word wrap 
$ oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

出力例

Copy to Clipboard Toggle word wrap 
NAME             TUNED                     APPLIED   DEGRADED   AGE
master-0         openshift-control-plane   True      False      6h33m
master-1         openshift-control-plane   True      False      6h33m
master-2         openshift-control-plane   True      False      6h33m
worker-a         openshift-node            True      False      6h28m
worker-b         openshift-node            True      False      6h28m

  • NAME: Profile オブジェクトの名前。ノードごとに Profile オブジェクトが 1 つあり、それぞれの名前が一致します。
  • TUNED: 適用する任意の TuneD プロファイルの名前。
  • APPLIED: TuneD デーモンが任意のプロファイルを適用する場合は True。(true/False/Unknown)。
  • DEGRADED: TuneD プロファイルのアプリケーション中にエラーが報告される場合は True (True/False/Unknown)
  • AGE: Profile オブジェクトの作成からの経過時間。

ClusterOperator/node-tuning オブジェクトには、Operator とそのノードエージェントの状態に関する有用な情報も含まれています。たとえば、Operator の設定ミスは、ClusterOperator/node-tuning ステータスメッセージによって報告されます。

ClusterOperator/node-tuning オブジェクトに関するステータス情報を取得するには、次のコマンドを実行します。

Copy to Clipboard Toggle word wrap 
$ oc get co/node-tuning -n openshift-cluster-node-tuning-operator

出力例

Copy to Clipboard Toggle word wrap 
NAME          VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
node-tuning   4.18.1    True        False         True       60m     1/5 Profiles with bootcmdline conflict

ClusterOperator/node-tuning またはプロファイルオブジェクトのステータスが DEGRADED の場合、追加情報が Operator またはオペランドログに提供されます。

9.5. カスタムチューニング仕様

Operator のカスタムリソース (CR) には 2 つの重要なセクションがあります。1 つ目のセクションの profile: は TuneD プロファイルおよびそれらの名前のリストです。2 つ目の recommend: は、プロファイル選択ロジックを定義します。

複数のカスタムチューニング仕様は、Operator の namespace に複数の CR として共存できます。新規 CR の存在または古い CR の削除は Operator によって検出されます。既存のカスタムチューニング仕様はすべてマージされ、コンテナー化された TuneD デーモンの適切なオブジェクトは更新されます。

管理状態

Operator 管理の状態は、デフォルトの Tuned CR を調整して設定されます。デフォルトで、Operator は Managed 状態であり、spec.managementState フィールドはデフォルトの Tuned CR に表示されません。Operator Management 状態の有効な値は以下のとおりです。

  • Managed: Operator は設定リソースが更新されるとそのオペランドを更新します。
  • Unmanaged: Operator は設定リソースへの変更を無視します。
  • Removed: Operator は Operator がプロビジョニングしたオペランドおよびリソースを削除します。

プロファイルデータ

profile: セクションは、TuneD プロファイルおよびそれらの名前をリスト表示します。

Copy to Clipboard Toggle word wrap 
profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

推奨プロファイル

profile: 選択ロジックは、CR の recommend: セクションによって定義されます。recommend: セクションは、選択基準に基づくプロファイルの推奨項目のリストです。

Copy to Clipboard Toggle word wrap 
recommend:
<recommend-item-1>
# ...
<recommend-item-n>

リストの個別項目:

Copy to Clipboard Toggle word wrap 
- machineConfigLabels:
1 

    <mcLabels>
2 

  match:
3 

    <match>
4 

  priority: <priority>
5 

  profile: <tuned_profile_name>
6 

  operand:
7 

    debug: <bool>
8 

    tunedConfig:
      reapply_sysctl: <bool>
9
1
オプション:
2
キー/値の MachineConfig ラベルのディクショナリー。キーは一意である必要があります。
3
省略する場合は、優先度の高いプロファイルが最初に一致するか、machineConfigLabels が設定されていない限り、プロファイルの一致が想定されます。
4
オプションのリスト。
5
プロファイルの順序付けの優先度。数値が小さいほど優先度が高くなります (0 が最も高い優先度になります)。
6
一致に適用する TuneD プロファイル。例: tuned_profile_1
7
オプションのオペランド設定。
8
TuneD デーモンのデバッグオンまたはオフを有効にします。オプションは、オンの場合は true、オフの場合は false です。デフォルトは false です。
9
TuneD デーモンの reapply_sysctl 機能をオンまたはオフにします。オプションは on で true、オフの場合は false です。

<match> は、以下のように再帰的に定義されるオプションの一覧です。

Copy to Clipboard Toggle word wrap 
- label: <label_name>
1 

  value: <label_value>
2 

  type: <label_type>
3 

    <match>
4
1
ノードまたは Pod のラベル名。
2
オプションのノードまたは Pod のラベルの値。省略されている場合も、<label_name> があるだけで一致条件を満たします。
3
オプションのオブジェクトタイプ (node または pod)。省略されている場合は、node が想定されます。
4
オプションの <match> リスト。

<match> が省略されない場合、ネストされたすべての <match> セクションが true に評価される必要もあります。そうでない場合には false が想定され、それぞれの <match> セクションのあるプロファイルは適用されず、推奨されません。そのため、ネスト化 (子の <match> セクション) は論理 AND 演算子として機能します。これとは逆に、<match> 一覧のいずれかの項目が一致する場合は、<match> の一覧全体が true に評価されます。そのため、リストは論理 OR 演算子として機能します。

machineConfigLabels が定義されている場合は、マシン設定プールベースのマッチングが指定の recommend: 一覧の項目に対してオンになります。<mcLabels> はマシン設定のラベルを指定します。マシン設定は、プロファイル <tuned_profile_name> についてカーネル起動パラメーターなどのホスト設定を適用するために自動的に作成されます。この場合は、マシン設定セレクターが <mcLabels> に一致するすべてのマシン設定プールを検索し、プロファイル <tuned_profile_name> を確認されるマシン設定プールが割り当てられるすべてのノードに設定する必要があります。マスターロールとワーカーのロールの両方を持つノードをターゲットにするには、マスターロールを使用する必要があります。

リスト項目の match および machineConfigLabels は論理 OR 演算子によって接続されます。match 項目は、最初にショートサーキット方式で評価されます。そのため、true と評価される場合、machineConfigLabels 項目は考慮されません。

重要

マシン設定プールベースのマッチングを使用する場合は、同じハードウェア設定を持つノードを同じマシン設定プールにグループ化することが推奨されます。この方法に従わない場合は、TuneD オペランドが同じマシン設定プールを共有する 2 つ以上のノードの競合するカーネルパラメーターを計算する可能性があります。

例: ノードまたは Pod のラベルベースのマッチング

Copy to Clipboard Toggle word wrap 
- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

上記のコンテナー化された TuneD デーモンの CR は、プロファイルの優先順位に基づいてその recommend.conf ファイルに変換されます。最も高い優先順位 (10) を持つプロファイルは openshift-control-plane-es であるため、これが最初に考慮されます。指定されたノードで実行されるコンテナー化された TuneD デーモンは、同じノードに tuned.openshift.io/elasticsearch ラベルが設定された Pod が実行されているかどうかを確認します。これがない場合は、<match> セクション全体が false として評価されます。このラベルを持つこのような Pod がある場合に、<match> セクションが true に評価されるようにするには、ノードラベルを node-role.kubernetes.io/master または node-role.kubernetes.io/infra にする必要もあります。

優先順位が 10 のプロファイルのラベルが一致した場合は、openshift-control-plane-es プロファイルが適用され、その他のプロファイルは考慮されません。ノード/Pod ラベルの組み合わせが一致しない場合は、2 番目に高い優先順位プロファイル (openshift-control-plane) が考慮されます。このプロファイルは、コンテナー化された TuneD Pod が node-role.kubernetes.io/master または node-role.kubernetes.io/infra ラベルを持つノードで実行される場合に適用されます。

最後に、プロファイル openshift-node には最低の優先順位である 30 が設定されます。これには <match> セクションがないため、常に一致します。これは、より高い優先順位の他のプロファイルが指定されたノードで一致しない場合に openshift-node プロファイルを設定するために、最低の優先順位のノードが適用される汎用的な (catch-all) プロファイルとして機能します。

意志決定ワークフロー

例: マシン設定プールベースのマッチング

Copy to Clipboard Toggle word wrap 
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

ノードの再起動を最小限にするには、ターゲットノードにマシン設定プールのノードセレクターが一致するラベルを使用してラベルを付け、上記の Tuned CR を作成してから、最後にカスタムのマシン設定プール自体を作成します。

クラウドプロバイダー固有の TuneD プロファイル

この機能により、すべてのクラウドプロバイダー固有のノードに、OpenShift Container Platform クラスター上の特定のクラウドプロバイダーに合わせて特別に調整された TuneD プロファイルを簡単に割り当てることができます。これは、追加のノードラベルを追加したり、ノードをマシン設定プールにグループ化したりせずに実行できます。

この機能は、<cloud-provider>://<cloud-provider-specific-id> の形式で spec.providerID ノードオブジェクト値を利用して、NTO オペランドコンテナーの <cloud-provider> の値で /var/lib/tuned/provider ファイルを書き込みます。その後、このファイルのコンテンツは TuneD により、プロバイダー provider-<cloud-provider> プロファイル (存在する場合) を読み込むために使用されます。

openshift-control-plane および openshift-node プロファイルの両方の設定を継承する openshift プロファイルは、条件付きプロファイルの読み込みを使用してこの機能を使用するよう更新されるようになりました。現時点で、NTO や TuneD にクラウドプロバイダー固有のプロファイルは含まれていません。ただし、すべてのクラウドプロバイダー固有のクラスターノードに適用されるカスタムプロファイル provider-<cloud-provider> を作成できます。

GCE クラウドプロバイダープロファイルの例

Copy to Clipboard Toggle word wrap 
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: provider-gce
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=GCE Cloud provider-specific profile
      # Your tuning for GCE Cloud provider goes here.
    name: provider-gce

注記

プロファイルの継承により、provider-<cloud-provider> プロファイルで指定された設定は、openshift プロファイルとその子プロファイルによって上書きされます。

9.6. カスタムチューニングの例

デフォルト CR からの TuneD プロファイルの使用

以下の CR は、ラベル tuned.openshift.io/ingress-node-label を任意の値に設定した状態で OpenShift Container Platform ノードのカスタムノードレベルのチューニングを適用します。

例: openshift-control-plane TuneD プロファイルを使用したカスタムチューニング

Copy to Clipboard Toggle word wrap 
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress

重要

カスタムプロファイル作成者は、デフォルトの TuneD CR に含まれるデフォルトの調整されたデーモンプロファイルを組み込むことが強く推奨されます。上記の例では、デフォルトの openshift-control-plane プロファイルを使用してこれを実行します。

ビルトイン TuneD プロファイルの使用

NTO が管理するデーモンセットのロールアウトに成功すると、TuneD オペランドはすべて同じバージョンの TuneD デーモンを管理します。デーモンがサポートするビルトイン TuneD プロファイルをリスト表示するには、以下の方法で TuneD Pod をクエリーします。

Copy to Clipboard Toggle word wrap 
$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/ -name tuned.conf -printf '%h\n' | sed 's|^.*/||'

このコマンドで取得したプロファイル名をカスタムのチューニング仕様で使用できます。

例: built-in hpc-compute TuneD プロファイルの使用

Copy to Clipboard Toggle word wrap 
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-hpc-compute
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile for HPC compute workloads
      include=openshift-node,hpc-compute
    name: openshift-node-hpc-compute

  recommend:
  - match:
    - label: tuned.openshift.io/openshift-node-hpc-compute
    priority: 20
    profile: openshift-node-hpc-compute

ビルトインの hpc-compute プロファイルに加えて、上記の例には、デフォルトの Tuned CR に同梱される openshift-node TuneD デーモンプロファイルが含まれており、コンピュートノードに OpenShift 固有のチューニングを使用します。

ホストレベルの sysctl のオーバーライド

/run/sysctl.d/、/etc/sysctl.d/、および /etc/sysctl.conf ホスト設定ファイルを使用して、実行時にさまざまなカーネルパラメーターを変更できます。OpenShift Container Platform は、実行時にカーネルパラメーターを設定する複数のホスト設定ファイルを追加します。たとえば、net.ipv[4-6].、fs.inotify、および vm.max_map_count。これらのランタイムパラメーターは、kubelet および Operator の開始前に、システムの基本的な機能調整を提供します。

reapply_sysctl オプションが false に設定されていない限り、Operator はこれらの設定をオーバーライドしません。このオプションを false に設定すると、TuneD はカスタムプロファイルを適用した後、ホスト設定ファイルからの設定を適用しません。

例: ホストレベルの sysctl のオーバーライド

Copy to Clipboard Toggle word wrap 
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-no-reapply-sysctl
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift profile
      include=openshift-node
      [sysctl]
      vm.max_map_count=>524288
    name: openshift-no-reapply-sysctl
  recommend:
  - match:
    - label: tuned.openshift.io/openshift-no-reapply-sysctl
    priority: 15
    profile: openshift-no-reapply-sysctl
    operand:
      tunedConfig:
        reapply_sysctl: false

9.7. チューニング変更の適用の延期

管理者は、Node Tuning Operator (NTO) を使用して、実行中のシステム上のカスタムリソース (CR) を更新し、チューニングの変更を行います。たとえば、チューニングするオブジェクトの [sysctl] セクションで sysctl パラメーターを更新または追加することがあります。管理者がチューニングの変更を適用すると、NTO は TuneD にすべての設定を再処理するように要求します。その結果、チューニングされるプロセスですべてのチューニングがロールバックされてから再適用されます。

レイテンシーの影響を受けやすいアプリケーションでは、パフォーマンスが一時的に低下する可能性があるため、TuneD プロファイルの削除と再適用が許容されない場合があります。これは、CPU パーティショニングを実行し、パフォーマンスプロファイルを使用してプロセスまたは割り込みのアフィニティーを管理する設定の場合に特に重要です。この問題を回避するために、OpenShift Container Platform ではチューニングの変更を適用するための新しい方法が導入されました。OpenShift Container Platform 4.17 より前は、利用できる方法は immediate だけでした。この方法では、変更がすぐに適用され、多くの場合、チューニングされた再起動がトリガーされていました。

これに加えて次の方法がサポートされています。

  • always: すべての変更が次回のノードの再起動時に適用されます。
  • update: チューニングの変更によって TuneD プロファイルが変更されると、デフォルトですぐに適用され、できるだけ早く反映されます。チューニングの変更によって TuneD プロファイルが変更されず、プロファイルの値がその場で変更された場合、変更は always として処理されます。

この機能を有効にするには、アノテーション tuned.openshift.io/deferred を追加します。次の表は、アノテーションに使用できる値をまとめたものです。

アノテーション値説明

missing

変更がすぐに適用されます。

always

変更が次回のノードの再起動時に適用されます。

update

変更によってプロファイルが変更された場合はすぐに適用されます。それ以外の場合は次のノードの再起動時に適用されます。

次の例は、always 方式を使用して kernel.shmmni sysctl パラメーターに変更を適用する方法を示しています。

例

Copy to Clipboard Toggle word wrap 
apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  annotations:
    tuned.openshift.io/deferred: "always"
spec:
  profile:
    - name: performance-patch
      data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-performance
1 

        [sysctl]
        kernel.shmmni=8192
2 

  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: worker-cnf
3 

      priority: 19
      profile: performance-patch

1
include ディレクティブは、openshift-node-performance-performance プロファイルを継承するために使用します。これは、プロファイルから必要な設定が欠落するのを防ぐためのベストプラクティスです。
2
kernel.shmmni sysctl パラメーターを 8192 に変更します。
3
machineConfigLabels フィールドは、worker-cnf ロールをターゲットにするために使用します。プロファイルが正しいノードにのみ適用されるように、MachineConfigPool リソースを設定します。

9.7.1. チューニング変更の適用の延期: 例

次の実例では、Node Tuning Operator を使用してチューニング変更の適用を延期する方法を説明します。

前提条件

  • cluster-admin ロールへのアクセス権がある。
  • クラスターにパフォーマンスプロファイルを適用した。
  • プロファイルが指定のノードにのみ適用されるように、MachineConfigPool リソース (worker-cnf など) が設定されている。

手順

  1. 次のコマンドを実行して、クラスターに現在適用されているプロファイルを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc -n openshift-cluster-node-tuning-operator get tuned

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                     AGE
default                                  63m
openshift-node-performance-performance   21m

  2. 次のコマンドを実行して、クラスター内のマシン設定プールを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-79a26af9f78ced61fa8ccd309d3c859c       True      False      False      3              3                   3                     0                      157m
worker       rendered-worker-d9352e91a1b14de7ef453fa54480ce0e       True      False      False      2              2                   2                     0                      157m
worker-cnf   rendered-worker-cnf-f398fc4fcb2b20104a51e744b8247272   True      False      False      1              1                   1                     0                      92m

  3. 次のコマンドを実行して、現在適用されているパフォーマンスプロファイルの情報を表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc describe performanceprofile performance | grep Tuned

    出力例

    Copy to Clipboard Toggle word wrap 
    Tuned:                   openshift-cluster-node-tuning-operator/openshift-node-performance-performance

  4. kernel.shmmni sysctl パラメーターの既存の値を確認します。

    1. 次のコマンドを実行してノード名を表示します。

      Copy to Clipboard Toggle word wrap 
      $ oc get nodes

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                          STATUS   ROLES                  AGE    VERSION
ip-10-0-26-151.ec2.internal   Ready    worker,worker-cnf      116m   v1.30.6
ip-10-0-46-60.ec2.internal    Ready    worker                 115m   v1.30.6
ip-10-0-52-141.ec2.internal   Ready    control-plane,master   123m   v1.30.6
ip-10-0-6-97.ec2.internal     Ready    control-plane,master   121m   v1.30.6
ip-10-0-86-145.ec2.internal   Ready    worker                 117m   v1.30.6
ip-10-0-92-228.ec2.internal   Ready    control-plane,master   123m   v1.30.6

    2. 次のコマンドを実行して、ノード ip-10-0-32-74.ec2.internal の kernel.shmmni sysctl パラメーターの現在の値を表示します。

      Copy to Clipboard Toggle word wrap 
      $ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host sysctl kernel.shmmni

      出力例

      Copy to Clipboard Toggle word wrap 
      kernel.shmmni = 4096

  5. kernel.shmmni sysctl パラメーターを 8192 に変更するプロファイルパッチ (例: perf-patch.yaml) を作成します。次の設定を適用し、always 方式を使用して、変更の適用を新しい手動再起動まで延期します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  annotations:
    tuned.openshift.io/deferred: "always"
spec:
  profile:
    - name: performance-patch
      data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-performance
    1 
    
        [sysctl]
        kernel.shmmni=8192
    2 
    
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: worker-cnf
    3 
    
      priority: 19
      profile: performance-patch
    1
    include ディレクティブは、openshift-node-performance-performance プロファイルを継承するために使用します。これは、プロファイルから必要な設定が欠落するのを防ぐためのベストプラクティスです。
    2
    kernel.shmmni sysctl パラメーターを 8192 に変更します。
    3
    machineConfigLabels フィールドは、worker-cnf ロールをターゲットにするために使用します。

  6. 次のコマンドを実行してプロファイルのパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc apply -f perf-patch.yaml

  7. 次のコマンドを実行して、プロファイルのパッチが次のノードの再起動を待機していることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc -n openshift-cluster-node-tuning-operator get profile

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                          TUNED                     APPLIED   DEGRADED   MESSAGE                                                                            AGE
ip-10-0-26-151.ec2.internal   performance-patch         False     True       The TuneD daemon profile is waiting for the next node restart: performance-patch   126m
ip-10-0-46-60.ec2.internal    openshift-node            True      False      TuneD profile applied.                                                             125m
ip-10-0-52-141.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             130m
ip-10-0-6-97.ec2.internal     openshift-control-plane   True      False      TuneD profile applied.                                                             130m
ip-10-0-86-145.ec2.internal   openshift-node            True      False      TuneD profile applied.                                                             126m
ip-10-0-92-228.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             130m

  8. 再起動する前に、kernel.shmmni sysctl パラメーターの値が変更されていないことを確認します。

    1. 次のコマンドを実行して、ノード ip-10-0-26-151.ec2.internal の kernel.shmmni sysctl パラメーターへの performance-patch の変更が適用されていないことを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host sysctl kernel.shmmni

      出力例

      Copy to Clipboard Toggle word wrap 
      kernel.shmmni = 4096

  9. 次のコマンドを実行して、ノード ip-10-0-26-151.ec2.internal を再起動し、必要な変更を適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host reboot&

  10. 別のターミナルウィンドウで次のコマンドを実行して、ノードが再起動したことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ watch oc get nodes

    ノード ip-10-0-26-151.ec2.internal が Ready 状態に戻るまで待ちます。

  11. 次のコマンドを実行して、プロファイルのパッチが次のノードの再起動を待機していることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc -n openshift-cluster-node-tuning-operator get profile

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                          TUNED                     APPLIED   DEGRADED   MESSAGE                                                                            AGE
ip-10-0-20-251.ec2.internal   performance-patch         True      False      TuneD profile applied.                                                             3h3m
ip-10-0-30-148.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
ip-10-0-32-74.ec2.internal    openshift-node            True      True       TuneD profile applied.                                                             179m
ip-10-0-33-49.ec2.internal    openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
ip-10-0-84-72.ec2.internal    openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
ip-10-0-93-89.ec2.internal    openshift-node            True      False      TuneD profile applied.                                                             179m

  12. 再起動後に kernel.shmmni sysctl パラメーターの値が変更されたことを確認します。

    1. 次のコマンドを実行して、kernel.shmmni sysctl パラメーターの変更がノード ip-10-0-32-74.ec2.internal に適用されていることを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc debug node/ip-10-0-32-74.ec2.internal  -q -- chroot host sysctl kernel.shmmni

      出力例

      Copy to Clipboard Toggle word wrap 
      kernel.shmmni = 8192

注記

もう一度再起動すると、kernel.shmmni sysctl パラメーターの元の値が復元されます。

9.8. サポートされている TuneD デーモンプラグイン

[main] セクションを除き、以下の TuneD プラグインは、Tuned CR の profile: セクションで定義されたカスタムプロファイルを使用する場合にサポートされます。

  • audio
  • cpu
  • disk
  • eeepc_she
  • modules
  • mounts
  • net
  • scheduler
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • usb
  • video
  • vm
  • bootloader

これらのプラグインの一部によって提供される動的チューニング機能の中に、サポートされていない機能があります。以下の TuneD プラグインは現時点でサポートされていません。

  • script
  • systemd
注記

TuneD ブートローダープラグインは、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーノードのみサポートします。

関連情報

9.9. ホステッドクラスターにおけるノードのチューニング設定

ホストされたクラスター内のノードでノードレベルのチューニングを設定するには、Node Tuning Operator を使用できます。ホストされたコントロールプレーンでは、Tuned オブジェクトを含む config map を作成し、ノードプールでそれらの config map を参照することで、ノードのチューニングを設定できます。

手順

  1. チューニングされた有効なマニフェストを含む config map を作成し、ノードプールでマニフェストを参照します。次の例で Tuned マニフェストは、任意の値を持つ tuned-1-node-label ノードラベルを含むノード上で vm.dirty_ratio を 55 に設定するプロファイルを定義します。次の ConfigMap マニフェストを tuned-1.yaml という名前のファイルに保存します。

    Copy to Clipboard Toggle word wrap 
        apiVersion: v1
    kind: ConfigMap
    metadata:
      name: tuned-1
      namespace: clusters
    data:
      tuning: |
        apiVersion: tuned.openshift.io/v1
        kind: Tuned
        metadata:
          name: tuned-1
          namespace: openshift-cluster-node-tuning-operator
        spec:
          profile:
          - data: |
              [main]
              summary=Custom OpenShift profile
              include=openshift-node
              [sysctl]
              vm.dirty_ratio="55"
            name: tuned-1-profile
          recommend:
          - priority: 20
            profile: tuned-1-profile
    注記

    Tuned 仕様の spec.recommend セクションのエントリーにラベルを追加しない場合は、ノードプールベースのマッチングが想定されるため、spec.recommend セクションの最も優先度の高いプロファイルがプール内のノードに適用されます。Tuned .spec.recommend.match セクションでラベル値を設定することにより、よりきめ細かいノードラベルベースのマッチングを実現できますが、ノードプールの .spec.management.upgradeType 値を InPlace に設定しない限り、ノードラベルはアップグレード中に保持されません。

  2. 管理クラスターに ConfigMap オブジェクトを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml

  3. ノードプールを編集するか作成して、ノードプールの spec.tuningConfig フィールドで ConfigMap オブジェクトを参照します。この例では、2 つのノードを含む nodepool-1 という名前の NodePool が 1 つだけあることを前提としています。

    Copy to Clipboard Toggle word wrap 
        apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
      ...
      name: nodepool-1
      namespace: clusters
    ...
    spec:
      ...
      tuningConfig:
      - name: tuned-1
    status:
    ...
    注記

    複数のノードプールで同じ config map を参照できます。Hosted Control Plane では、Node Tuning Operator が Tuned CR の名前にノードプール名と namespace のハッシュを追加して、それらを区別します。この場合を除き、同じホステッドクラスターの異なる Tuned CR に、同じ名前の複数の TuneD プロファイルを作成しないでください。

検証

これで Tuned マニフェストを含む ConfigMap オブジェクトを作成し、それを NodePool で参照しました。次に、Node Tuning Operator は Tuned オブジェクトをホストされたクラスターに同期します。どの Tuned オブジェクトが定義されているか、どの TuneD プロファイルが各ノードに適用されているかを確認できます。

  1. ホストされたクラスター内の Tuned オブジェクトを一覧表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io \
  -n openshift-cluster-node-tuning-operator

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME       AGE
default    7m36s
rendered   7m36s
tuned-1    65s

  2. ホストされたクラスター内の Profile オブジェクトを一覧表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io \
  -n openshift-cluster-node-tuning-operator

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                           TUNED            APPLIED   DEGRADED   AGE
nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
nodepool-1-worker-2            tuned-1-profile  True      False      7m14s

    注記

    カスタムプロファイルが作成されていない場合は、openshift-node プロファイルがデフォルトで適用されます。

  3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを開始し、sysctl 値を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="$HC_KUBECONFIG" \
  debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio

    出力例

    Copy to Clipboard Toggle word wrap 
    vm.dirty_ratio = 55

9.10. カーネルブートパラメーターを設定することによる、ホストされたクラスターの高度なノードチューニング

カーネルブートパラメーターの設定が必要な、ホストされたコントロールプレーンでのより高度なチューニングについては、Node Tuning Operator を使用することもできます。次の例は、Huge Page が予約されたノードプールを作成する方法を示しています。

手順

  1. サイズが 2 MB の 10 個の Huge Page を作成するための Tuned オブジェクトマニフェストを含む ConfigMap オブジェクトを作成します。この ConfigMap マニフェストを tuned-hugepages.yaml という名前のファイルに保存します。

    Copy to Clipboard Toggle word wrap 
        apiVersion: v1
    kind: ConfigMap
    metadata:
      name: tuned-hugepages
      namespace: clusters
    data:
      tuning: |
        apiVersion: tuned.openshift.io/v1
        kind: Tuned
        metadata:
          name: hugepages
          namespace: openshift-cluster-node-tuning-operator
        spec:
          profile:
          - data: |
              [main]
              summary=Boot time configuration for hugepages
              include=openshift-node
              [bootloader]
              cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
            name: openshift-node-hugepages
          recommend:
          - priority: 20
            profile: openshift-node-hugepages
    注記

    .spec.recommend.match フィールドは意図的に空白のままにしています。この場合、この Tuned オブジェクトは、この ConfigMap オブジェクトが参照されているノードプール内のすべてのノードに適用されます。同じハードウェア設定を持つノードを同じノードプールにグループ化します。そうしないと、TuneD オペランドは、同じノードプールを共有する 2 つ以上のノードに対して競合するカーネルパラメーターを計算する可能性があります。

  2. 管理クラスターに ConfigMap オブジェクトを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml
    1
    1
    <management_cluster_kubeconfig> を管理クラスターの kubeconfig ファイルの名前に置き換えます。

  3. NodePool マニフェスト YAML ファイルを作成し、NodePool のアップグレードタイプをカスタマイズして、spec.tuningConfig セクションで作成した ConfigMap オブジェクトを参照します。NodePool マニフェストを作成し、hcp CLI を使用して hugepages-nodepool.yaml という名前のファイルに保存します。

    Copy to Clipboard Toggle word wrap 
    $ hcp create nodepool aws \
  --cluster-name <hosted_cluster_name> \
    1 
    
  --name <nodepool_name> \
    2 
    
  --node-count <nodepool_replicas> \
    3 
    
  --instance-type <instance_type> \
    4 
    
  --render > hugepages-nodepool.yaml
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <nodepool_name> をノードプールの名前に置き換えます。
    3
    <nodepool_replicas> をノードプールのレプリカの数 (例: 2) に置き換えます。
    4
    <instance_type> をインスタンスタイプ (例: m5.2xlarge) に置き換えます。
    注記

    hcp create コマンドの --render フラグはシークレットをレンダリングしません。シークレットをレンダリングするには、hcp create コマンドで --render フラグと --render-sensitive フラグの両方を使用する必要があります。

  4. hugepages-nodepool.yaml ファイルで、.spec.management.upgradeType を InPlace に設定し、作成した tuned-hugepages ConfigMap オブジェクトを参照するように .spec.tuningConfig を設定します。

    Copy to Clipboard Toggle word wrap 
        apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
      name: hugepages-nodepool
      namespace: clusters
      ...
    spec:
      management:
        ...
        upgradeType: InPlace
      ...
      tuningConfig:
      - name: tuned-hugepages
    注記

    新しい MachineConfig オブジェクトを適用するときに不要なノードの再作成を回避するには、.spec.management.upgradeType を InPlace に設定します。Replace アップグレードタイプを使用する場合、ノードは完全に削除され、TuneD オペランドが計算した新しいカーネルブートパラメーターを適用すると、新しいノードでノードを置き換えることができます。

  5. 管理クラスターに NodePool を作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml

検証

ノードが使用可能になると、コンテナー化された TuneD デーモンが、適用された TuneD プロファイルに基づいて、必要なカーネルブートパラメーターを計算します。ノードの準備が整い、一度再起動して生成された MachineConfig オブジェクトを適用したら、TuneD プロファイルが適用され、カーネルブートパラメーターが設定されていることを確認できます。

  1. ホストされたクラスター内の Tuned オブジェクトを一覧表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io \
  -n openshift-cluster-node-tuning-operator

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                 AGE
default              123m
hugepages-8dfb1fed   1m23s
rendered             123m

  2. ホストされたクラスター内の Profile オブジェクトを一覧表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io \
  -n openshift-cluster-node-tuning-operator

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                           TUNED                      APPLIED   DEGRADED   AGE
nodepool-1-worker-1            openshift-node             True      False      132m
nodepool-1-worker-2            openshift-node             True      False      131m
hugepages-nodepool-worker-1    openshift-node-hugepages   True      False      4m8s
hugepages-nodepool-worker-2    openshift-node-hugepages   True      False      3m57s

    新しい NodePool の両方のワーカーノードには、openshift-node-hugepages プロファイルが適用されています。

  3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを起動し、/proc/cmdline を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" \
  debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline

    出力例

    Copy to Clipboard Toggle word wrap 
    BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50

関連情報

第10章 CPU マネージャーおよび Topology Manager の使用

CPU マネージャーは、CPU グループを管理して、ワークロードを特定の CPU に制限します。

CPU マネージャーは、以下のような属性が含まれるワークロードに有用です。

  • できるだけ長い CPU 時間が必要な場合
  • プロセッサーのキャッシュミスの影響を受ける場合
  • レイテンシーが低いネットワークアプリケーションの場合
  • 他のプロセスと連携し、単一のプロセッサーキャッシュを共有することに利点がある場合

Topology Manager は、CPU マネージャー、デバイスマネージャー、およびその他の Hint Provider からヒントを収集し、同じ Non-Uniform Memory Access (NUMA) ノード上のすべての QoS (Quality of Service) クラスについて CPU、SR-IOV VF、その他デバイスリソースなどの Pod リソースを調整します。

Topology Manager は、収集したヒントのトポロジー情報を使用し、設定される Topology Manager ポリシーおよび要求される Pod リソースに基づいて、pod がノードから許可されるか、拒否されるかどうかを判別します。

Topology Manager は、ハードウェアアクセラレーターを使用して低遅延 (latency-critical) の実行と高スループットの並列計算をサポートするワークロードの場合に役立ちます。

Topology Manager を使用するには、static ポリシーで CPU マネージャーを設定する必要があります。

10.1. CPU マネージャーの設定

CPU マネージャーを設定するには、KubeletConfig カスタムリソース (CR) を作成し、それを目的のノードセットに適用します。

手順

  1. 次のコマンドを実行してノードにラベルを付けます。

    Copy to Clipboard Toggle word wrap 
    # oc label node perf-node.example.com cpumanager=true

  2. すべてのコンピュートノードに対して CPU マネージャーを有効にするには、次のコマンドを実行して CR を編集します。

    Copy to Clipboard Toggle word wrap 
    # oc edit machineconfigpool worker

  3. custom-kubelet: cpumanager-enabled ラベルを metadata.labels セクションに追加します。

    Copy to Clipboard Toggle word wrap 
    metadata:
  creationTimestamp: 2020-xx-xxx
  generation: 3
  labels:
    custom-kubelet: cpumanager-enabled

  4. KubeletConfig、cpumanager-kubeletconfig.yaml、カスタムリソース (CR) を作成します。直前の手順で作成したラベルを参照し、適切なノードを新規の kubelet 設定で更新します。machineConfigPoolSelector セクションを参照してください。

    Copy to Clipboard Toggle word wrap 
    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static
    1 
    
     cpuManagerReconcilePeriod: 5s
    2
    1
    ポリシーを指定します。
    • noneこのポリシーは、既存のデフォルト CPU アフィニティースキームを明示的に有効にし、スケジューラーが自動的に実行するもの以外のアフィニティーを提供しません。これはデフォルトポリシーになります。
    • staticこのポリシーは、整数の CPU 要求を持つ保証された Pod 内のコンテナーを許可します。また、ノードの排他的 CPU へのアクセスも制限します。static の場合は、小文字 の s を使用する必要があります。
    2
    オプション: CPU マネージャーの調整頻度を指定します。デフォルトは 5s です。

  5. 次のコマンドを実行して、動的 kubelet 設定を作成します。

    Copy to Clipboard Toggle word wrap 
    # oc create -f cpumanager-kubeletconfig.yaml

    これにより、CPU マネージャー機能が kubelet 設定に追加され、必要な場合には Machine Config Operator (MCO) がノードを再起動します。CPU マネージャーを有効にするために再起動する必要はありません。

  6. 次のコマンドを実行して、マージされた kubelet 設定を確認します。

    Copy to Clipboard Toggle word wrap 
    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

    出力例

    Copy to Clipboard Toggle word wrap 
           "ownerReferences": [
            {
                "apiVersion": "machineconfiguration.openshift.io/v1",
                "kind": "KubeletConfig",
                "name": "cpumanager-enabled",
                "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
            }
        ]

  7. 次のコマンドを実行して、更新された kubelet.conf ファイルをコンピュートノードで確認します。

    Copy to Clipboard Toggle word wrap 
    # oc debug node/perf-node.example.com
sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

    出力例

    Copy to Clipboard Toggle word wrap 
    cpuManagerPolicy: static
    1 
    
cpuManagerReconcilePeriod: 5s
    2

    1
    cpuManagerPolicy は、KubeletConfig CR の作成時に定義されます。
    2
    cpuManagerReconcilePeriod は、KubeletConfig CR の作成時に定義されます。

  8. 次のコマンドを実行してプロジェクトを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc new-project <project_name>

  9. コア 1 つまたは複数を要求する Pod を作成します。制限および要求の CPU の値は整数にする必要があります。これは、対象の Pod 専用のコア数です。

    Copy to Clipboard Toggle word wrap 
    # cat cpumanager-pod.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: Pod
metadata:
  generateName: cpumanager-
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: cpumanager
    image: gcr.io/google_containers/pause:3.2
    resources:
      requests:
        cpu: 1
        memory: "1G"
      limits:
        cpu: 1
        memory: "1G"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  nodeSelector:
    cpumanager: "true"

  10. Pod を作成します。

    Copy to Clipboard Toggle word wrap 
    # oc create -f cpumanager-pod.yaml

検証

  1. 次のコマンドを実行して、ラベルを付けたノードに Pod がスケジュールされていることを確認します。

    Copy to Clipboard Toggle word wrap 
    # oc describe pod cpumanager

    出力例

    Copy to Clipboard Toggle word wrap 
    Name:               cpumanager-6cqz7
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:  perf-node.example.com/xxx.xx.xx.xxx
...
 Limits:
      cpu:     1
      memory:  1G
    Requests:
      cpu:        1
      memory:     1G
...
QoS Class:       Guaranteed
Node-Selectors:  cpumanager=true

  2. 次のコマンドを実行して、CPU が Pod 専用として割り当てられていることを確認します。

    Copy to Clipboard Toggle word wrap 
    # oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2

    出力例

    Copy to Clipboard Toggle word wrap 
    NAMESPACE    NAME                CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
cpuman       cpumanager-mlrrz    1 (28%)       1 (28%)     1G (13%)         1G (13%)       27m

  3. cgroups が正しく設定されていることを確認します。次のコマンドを実行して、pause プロセスのプロセス ID (PID) を取得します。

    Copy to Clipboard Toggle word wrap 
    # oc debug node/perf-node.example.com
     Copy to Clipboard Toggle word wrap 
    sh-4.2# systemctl status | grep -B5 pause
    注記

    出力で複数の pause プロセスエントリーが返される場合は、正しい一時停止プロセスを特定する必要があります。

    出力例

    Copy to Clipboard Toggle word wrap 
    # ├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
└─kubepods.slice
  ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
  │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
  │ └─32706 /pause

  4. 次のコマンドを実行して、サービス品質 (QoS) 層 (Guaranteed) の Pod が kubepods.slice サブディレクトリー内に配置されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    # cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
     Copy to Clipboard Toggle word wrap 
    # for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done
    注記

    他の QoS 階層の Pod は、親 kubepods の子である cgroups に配置されます。

    出力例

    Copy to Clipboard Toggle word wrap 
    cpuset.cpus 1
tasks 32706

  5. 次のコマンドを実行して、タスクに許可されている CPU リストを確認します。

    Copy to Clipboard Toggle word wrap 
    # grep ^Cpus_allowed_list /proc/32706/status

    出力例

    Copy to Clipboard Toggle word wrap 
     Cpus_allowed_list:    1

  6. システム上の別の Pod が、Guaranteed Pod に割り当てられたコアで実行できないことを確認します。たとえば、besteffort QoS 階層の Pod を検証するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    # cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
     Copy to Clipboard Toggle word wrap 
    # oc describe node perf-node.example.com

    出力例

    Copy to Clipboard Toggle word wrap 
    ...
Capacity:
 attachable-volumes-aws-ebs:  39
 cpu:                         2
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      8162900Ki
 pods:                        250
Allocatable:
 attachable-volumes-aws-ebs:  39
 cpu:                         1500m
 ephemeral-storage:           124768236Ki
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      7548500Ki
 pods:                        250
-------                               ----                           ------------  ----------  ---------------  -------------  ---
  default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests          Limits
  --------                    --------          ------
  cpu                         1440m (96%)       1 (66%)

    この仮想マシンには、2 つの CPU コアがあります。system-reserved 設定は 500 ミリコアを予約し、Node Allocatable の量になるようにノードの全容量からコアの半分を引きます。ここで Allocatable CPU は 1500 ミリコアであることを確認できます。これは、それぞれがコアを 1 つ受け入れるので、CPU マネージャー Pod の 1 つを実行できることを意味します。1 つのコア全体は 1000 ミリコアに相当します。2 つ目の Pod をスケジュールしようとする場合、システムは Pod を受け入れますが、これがスケジュールされることはありません。

    Copy to Clipboard Toggle word wrap 
    NAME                    READY   STATUS    RESTARTS   AGE
cpumanager-6cqz7        1/1     Running   0          33m
cpumanager-7qc2t        0/1     Pending   0          11s

10.2. Topology Manager ポリシー

Topology Manager は、CPU マネージャーや Device Manager などの Hint Provider からトポロジーのヒントを収集し、収集したヒントを使用して Pod リソースを調整することで、すべての Quality of Service (QoS) クラスの Pod リソースを調整します。

Topology Manager は、cpumanager-enabled という名前の KubeletConfig カスタムリソース (CR) で割り当てる 4 つの割り当てポリシーをサポートしています。

none ポリシー
これはデフォルトのポリシーで、トポロジーの配置は実行しません。
best-effort ポリシー
best-effort トポロジー管理ポリシーを持つ Pod のそれぞれのコンテナーの場合、kubelet は各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は、そのコンテナーの推奨される NUMA ノードのアフィニティーを保存します。アフィニティーが優先されない場合、Topology Manager はこれを保管し、ノードに対して Pod を許可します。
restricted ポリシー
restricted トポロジー管理ポリシーを持つ Pod のそれぞれのコンテナーの場合、kubelet は各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は、そのコンテナーの推奨される NUMA ノードのアフィニティーを保存します。アフィニティーが優先されない場合、Topology Manager はこの Pod をノードから拒否します。これにより、Pod が Pod の受付の失敗により Terminated 状態になります。
single-numa-node ポリシー
single-numa-node トポロジー管理ポリシーがある Pod のそれぞれのコンテナーの場合、kubelet は各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は単一の NUMA ノードのアフィニティーが可能かどうかを判別します。可能である場合、Pod はノードに許可されます。単一の NUMA ノードアフィニティーが使用できない場合には、Topology Manager は Pod をノードから拒否します。これにより、Pod は Pod の受付失敗と共に Terminated (終了) 状態になります。

10.3. Topology Manager のセットアップ

Topology Manager を使用するには、cpumanager-enabled という名前の KubeletConfig カスタムリソース (CR) で割り当てポリシーを設定する必要があります。CPU マネージャーをセットアップしている場合は、このファイルが存在している可能性があります。ファイルが存在しない場合は、作成できます。

前提条件

  • CPU マネージャーのポリシーを static に設定します。

手順

Topology Manager をアクティブにするには、以下を実行します。

  1. カスタムリソースで Topology Manager 割り当てポリシーを設定します。

    Copy to Clipboard Toggle word wrap 
    $ oc edit KubeletConfig cpumanager-enabled
     Copy to Clipboard Toggle word wrap 
    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: cpumanager-enabled
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: cpumanager-enabled
  kubeletConfig:
     cpuManagerPolicy: static
    1 
    
     cpuManagerReconcilePeriod: 5s
     topologyManagerPolicy: single-numa-node
    2
    1
    このパラメーターは、小文字の s で static にする必要があります。
    2
    選択した Topology Manager 割り当てポリシーを指定します。このポリシーは single-numa-node になります。使用できる値は、default、best-effort、restricted、single-numa-node です。

10.4. Pod の Topology Manager ポリシーとの対話

以下のサンプル Pod 仕様は、Pod の Topology Manger との対話を説明しています。

以下の Pod は、リソース要求や制限が指定されていないために BestEffort QoS クラスで実行されます。

Copy to Clipboard Toggle word wrap 
spec:
  containers:
  - name: nginx
    image: nginx

以下の Pod は、要求が制限よりも小さいために Burstable QoS クラスで実行されます。

Copy to Clipboard Toggle word wrap 
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

選択したポリシーが none 以外の場合は、Topology Manager はこれらの Pod 仕様のいずれかも考慮しません。

以下の最後のサンプル Pod は、要求が制限と等しいために Guaranteed QoS クラスで実行されます。

Copy to Clipboard Toggle word wrap 
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

Topology Manager はこの Pod を考慮します。Topology Manager はヒントプロバイダー (CPU マネージャーおよび Device Manager ) を参照して、Pod のトポロジーヒントを取得します。

Topology Manager はこの情報を使用して、このコンテナーに最適なトポロジーを保管します。この Pod の場合、CPU マネージャーおよびデバイスマネージャーは、リソース割り当ての段階でこの保存された情報を使用します。

第11章 NUMA 対応ワークロードのスケジューリング

NUMA 対応のスケジューリングと、それを使用して OpenShift Container Platform クラスターに高パフォーマンスのワークロードをデプロイする方法を学びます。

NUMA Resources Operator を使用すると、同じ NUMA ゾーンで高パフォーマンスのワークロードをスケジュールすることができます。これは、利用可能なクラスターノードの NUMA リソースを報告するノードリソースエクスポートエージェントと、ワークロードを管理するセカンダリースケジューラーをデプロイします。

11.1. NUMA 対応のスケジューリングについて

NUMA の概要

Non-Uniform Memory Access (NUMA) は、異なる CPU が異なるメモリー領域に異なる速度でアクセスできるようにするコンピュートプラットフォームアーキテクチャーです。NUMA リソーストポロジーは、コンピュートノード内の相互に関連する CPU、メモリー、および PCI デバイスの位置を指しています。共同配置されたリソースは、同じ NUMA ゾーン にあるとされています。高性能アプリケーションの場合、クラスターは単一の NUMA ゾーンで Pod ワークロードを処理する必要があります。

パフォーマンスに関する考慮事項

NUMA アーキテクチャーにより、複数のメモリーコントローラーを備えた CPU は、メモリーが配置されている場所に関係なく、CPU コンプレックス全体で使用可能なメモリーを使用できます。これにより、パフォーマンスを犠牲にして柔軟性を高めることができます。NUMA ゾーン外のメモリーを使用してワークロードを処理する CPU は、単一の NUMA ゾーンで処理されるワークロードよりも遅くなります。また、I/O に制約のあるワークロードの場合、離れた NUMA ゾーンのネットワークインターフェイスにより、情報がアプリケーションに到達する速度が低下します。通信ワークロードなどの高性能ワークロードは、これらの条件下では仕様どおりに動作できません。

NUMA 対応のスケジューリング

NUMA 対応のスケジューリングは、要求されたクラスターコンピュートリソース (CPU、メモリー、デバイス) を同じ NUMA ゾーンに配置して、レイテンシーの影響を受けやすいワークロードや高性能なワークロードを効率的に処理します。また、NUMA 対応のスケジューリングにより、コンピュートノードあたりの Pod 密度を向上させ、リソース効率を高めています。

Node Tuning Operator との統合

Node Tuning Operator のパフォーマンスプロファイルを NUMA 対応スケジューリングと統合することで、CPU アフィニティーをさらに設定し、レイテンシーの影響を受けやすいワークロードのパフォーマンスを最適化できます。

デフォルトのスケジューリングロジック

デフォルトの OpenShift Container Platform Pod スケジューラーのスケジューリングロジックは、個々の NUMA ゾーンではなく、コンピュートノード全体の利用可能なリソースを考慮します。kubelet トポロジーマネージャーで最も制限的なリソースアライメントが要求された場合、Pod をノードに許可するときにエラー状態が発生する可能性があります。逆に、最も制限的なリソース調整が要求されていない場合、Pod は適切なリソース調整なしでノードに許可され、パフォーマンスが低下したり予測不能になったりする可能性があります。たとえば、Pod スケジューラーが Pod の要求されたリソースが利用可能かどうか把握せずに保証された Pod ワークロードに対して次善のスケジューリング決定を行うと、Topology Affinity Error ステータスを伴う Pod 作成の暴走が発生する可能性があります。スケジュールの不一致の決定により、Pod の起動が無期限に遅延する可能性があります。また、クラスターの状態とリソースの割り当てによっては、Pod のスケジューリングの決定が適切でないと、起動の試行が失敗するためにクラスターに余分な負荷がかかる可能性があります。

NUMA 対応の Pod スケジューリングの図

NUMA Resources Operator は、カスタム NUMA リソースのセカンダリースケジューラーおよびその他のリソースをデプロイして、デフォルトの OpenShift Container Platform Pod スケジューラーの欠点を軽減します。次の図は、NUMA 対応 Pod スケジューリングの俯瞰的な概要を示しています。

図11.1 NUMA 対応スケジューリングの概要

クラスター内でさまざまなコンポーネントがどのように相互作用するかを示す NUMA 対応スケジューリングの図
NodeResourceTopology API
NodeResourceTopology API は、各コンピュートノードで使用可能な NUMA ゾーンリソースを記述します。
NUMA 対応スケジューラー
NUMA 対応のセカンダリースケジューラーは、利用可能な NUMA ゾーンに関する情報を NodeResourceTopology API から受け取り、最適に処理できるノードで高パフォーマンスのワークロードをスケジュールします。
ノードトポロジーエクスポーター
ノードトポロジーエクスポーターは、各コンピュートノードで使用可能な NUMA ゾーンリソースを NodeResourceTopology API に公開します。ノードトポロジーエクスポーターデーモンは、PodResources API を使用して、kubelet からのリソース割り当てを追跡します。
PodResources API

PodResources API は各ノードに対してローカルであり、リソーストポロジーと利用可能なリソースを kubelet に公開します。

注記

PodResources API の List エンドポイントは、特定のコンテナーに割り当てられた排他的な CPU を公開します。API は、共有プールに属する CPU は公開しません。

GetAllocatableResources エンドポイントは、ノード上で使用できる割り当て可能なリソースを公開します。

11.2. NUMA リソーススケジューリングストラテジー

高パフォーマンスのワークロードをスケジュールする場合、セカンダリースケジューラーは、さまざまなストラテジーを採用して、選択したワーカーノード内のどの NUMA ノードによってワークロードを処理するかを決定できます。OpenShift Container Platform でサポートされているストラテジーには、LeastAllocated、MostAllocated、BalancedAllocation があります。これらのストラテジーを理解することで、パフォーマンスとリソース使用率のためにワークロードの配置を最適化できます。

NUMA 対応クラスターで高パフォーマンスワークロードがスケジュールされるときには、次の手順が実行されます。

  1. まず、スケジューラーがクラスター全体の基準に基づいて適切なワーカーノードを選択します。たとえば、taint、ラベル、リソースの可用性などの基準です。
  2. ワーカーノードが選択されると、スケジューラーはその NUMA ノードを評価し、スコアリングストラテジーを適用して、どの NUMA ノードによってワークロードを処理するかを決定します。
  3. ワークロードがスケジュールされると、選択された NUMA ノードのリソースが更新され、割り当てが反映されます。

適用されるデフォルトのストラテジーは、LeastAllocated ストラテジーです。このストラテジーでは、利用可能なリソースが最も多く、使用率が最も低い NUMA ノードにワークロードが割り当てられます。このストラテジーの目的は、競合を減らし、ホットスポットを回避するために、NUMA ノード全体にワークロードを分散することです。

次の表に、各ストラテジーとその効果の概要を示します。

スコアリングストラテジーの概要
表11.1 スコアリングストラテジーの概要
ストラテジー説明効果

LeastAllocated

利用可能なリソースが最も多い NUMA ノードを優先します。

ワークロードを分散して競合を減らし、優先度の高いタスクのための余裕を確保します。

MostAllocated

利用可能なリソースが最も少ない NUMA ノードを優先します。

ワークロードを少数の NUMA ノードに集約し、他のノードを解放してエネルギー効率を高めます。

BalancedAllocation

CPU とメモリーの使用量がバランスのとれた NUMA ノードを優先します。

均等なリソース使用を実現し、偏った使用パターンを防ぎます。

LeastAllocated ストラテジーの例

LeastAllocated がデフォルトのストラテジーです。このストラテジーでは、利用可能なリソースが最も多い NUMA ノードにワークロードを割り当て、リソースの競合を最小限に抑え、ワークロードを NUMA ノード全体に分散します。これにより、ホットスポットが削減され、優先度の高いタスクに十分な余裕が確保されます。ワーカーノードに 2 つの NUMA ノードがあり、ワークロードに 4 つの仮想 CPU と 8 GB のメモリーが必要であると仮定します。

表11.2 NUMA ノード初期状態の例
NUMA ノード合計 CPU 数使用済み CPU 数合計メモリー (GB)使用済みメモリー (GB)利用可能なリソース

NUMA 1

16

12

64

56

4 CPU、8 GB のメモリー

NUMA 2

16

6

64

24

10 CPU、40 GB のメモリー

NUMA 2 には NUMA 1 と比較して利用可能なリソースが多いため、ワークロードは NUMA 2 に割り当てられます。

MostAllocated ストラテジーの例

MostAllocated ストラテジーは、利用可能なリソースが最も少ない NUMA ノード (最も使用されている NUMA ノード) にワークロードを割り当てることで、ワークロードを集約します。この方法により、エネルギー効率や完全な分離を必要とする重要なワークロードのために、他の NUMA ノードを解放できます。この例では、LeastAllocated セクションにリストされている「NUMA ノード初期状態の例」の値を使用します。

このワークロードには、4 つの仮想 CPU と 8 GB のメモリーが必要です。NUMA 1 は NUMA 2 に比べて利用可能なリソースが少ないため、スケジューラーはワークロードを NUMA 1 に割り当て、そのリソースをさらに活用します。一方、NUMA 2 はアイドル状態にするか、その負荷を最小限に抑えます。

BalancedAllocation ストラテジーの例

BalancedAllocation ストラテジーでは、CPU とメモリーのリソース使用率が最もバランスのとれた NUMA ノードにワークロードを割り当てます。目的は、メモリーが十分に使用されていないのに CPU 使用率が高くなるなど、不均衡な使用を防ぐことです。ワーカーノードの NUMA ノードの状態が次のようなものであると仮定します。

表11.3 BalancedAllocation の NUMA ノード初期状態の例
NUMA ノードCPU の使用率メモリー使用率BalancedAllocation のスコア

NUMA 1

60%

55%

高 (バランスがとれている)

NUMA 2

80%

20%

低 (バランスがとれていない)

NUMA 1 は、NUMA 2 と比較して CPU とメモリーの使用率がよりバランスがとれています。そのため、BalancedAllocation ストラテジーを適用すると、ワークロードは NUMA 1 に割り当てられます。

関連情報

11.3. NUMA Resources Operator のインストール

NUMA Resources Operator は、NUMA 対応のワークロードとデプロイメントをスケジュールできるリソースをデプロイします。OpenShift Container Platform CLI または Web コンソールを使用して NUMA Resources Operator をインストールできます。

11.3.1. CLI を使用した NUMA Resources Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. NUMA Resources Operator の namespace を作成します。

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

      Copy to Clipboard Toggle word wrap 
      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-numaresources

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

      Copy to Clipboard Toggle word wrap 
      $ oc create -f nro-namespace.yaml

  2. NUMA Resources Operator の Operator グループを作成します。

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

      Copy to Clipboard Toggle word wrap 
      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  targetNamespaces:
  - openshift-numaresources

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

      Copy to Clipboard Toggle word wrap 
      $ oc create -f nro-operatorgroup.yaml

  3. NUMA Resources Operator のサブスクリプションを作成します。

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

      Copy to Clipboard Toggle word wrap 
      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  channel: "4.18"
  name: numaresources-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

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

      Copy to Clipboard Toggle word wrap 
      $ oc create -f nro-sub.yaml

検証

  1. openshift-numaresources namespace の CSV リソースを調べて、インストールが成功したことを確認します。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc get csv -n openshift-numaresources

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                             DISPLAY                  VERSION   REPLACES   PHASE
numaresources-operator.v4.18.2   numaresources-operator   4.18.2               Succeeded

11.3.2. Web コンソールを使用した NUMA Resources Operator のインストール

クラスター管理者は、Web コンソールを使用して NUMA Resources Operator をインストールできます。

手順

  1. NUMA Resources Operator の namespace を作成します。

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

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

    1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
    2. 利用可能な Operator のリストから numaresources-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 のログを確認します。

11.4. NUMA 対応ワークロードのスケジューリング

通常、遅延の影響を受けやすいワークロードを実行するクラスターは、ワークロードの遅延を最小限に抑え、パフォーマンスを最適化するのに役立つパフォーマンスプロファイルを備えています。NUMA 対応スケジューラーは、使用可能なノードの NUMA リソースと、ノードに適用されるパフォーマンスプロファイル設定に基づいき、ワークロードをデプロイします。NUMA 対応デプロイメントとワークロードのパフォーマンスプロファイルを組み合わせることで、パフォーマンスを最大化するようにワークロードがスケジュールされます。

NUMA Resources Operator を完全に動作させるには、NUMAResourcesOperator カスタムリソースと NUMA 対応のセカンダリー Pod スケジューラーをデプロイする必要があります。

11.4.1. NUMAResourcesOperator カスタムリソースの作成

NUMA Resources Operator をインストールしたら、NUMAResourcesOperator カスタムリソース (CR) を作成します。この CR は、デーモンセットや API など、NUMA 対応スケジューラーをサポートするために必要なすべてのクラスターインフラストラクチャーをインストールするように NUMA Resources Operator に指示します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールしている。

手順

  1. NUMAResourcesOperator カスタムリソースを作成します。

    1. 次の最小限必要な YAML ファイルの例を nrop.yaml として保存します。

      Copy to Clipboard Toggle word wrap 
      apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
  - machineConfigPoolSelector:
      matchLabels:
        pools.operator.machineconfiguration.openshift.io/worker: ""
      1
      1
      これは、NUMA Resources Operator を設定する MachineConfigPool リソースと一致する必要があります。たとえば、通信ワークロードを実行することが予想されるノードのセットを指定する worker-cnf という名前の MachineConfigPool リソースを作成したとします。各 NodeGroup は 1 つの MachineConfigPool に完全に一致する必要があります。NodeGroup が複数の MachineConfigPool に一致する設定はサポートされていません。

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

      Copy to Clipboard Toggle word wrap 
      $ oc create -f nrop.yaml

  2. オプション: 複数のマシン設定プール (MCP) に対して NUMA 対応スケジューリングを有効にするには、プールごとに個別の NodeGroup を定義します。たとえば、次の例に示すように、NUMAResourcesOperator CR で、worker-cnf、worker-ht、および worker-other の 3 つの NodeGroup を定義します。

    複数の NodeGroups を含む NUMAResourcesOperator CR の YAML 定義の例

    Copy to Clipboard Toggle word wrap 
    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  logLevel: Normal
  nodeGroups:
    - machineConfigPoolSelector:
        matchLabels:
          machineconfiguration.openshift.io/role: worker-ht
    - machineConfigPoolSelector:
        matchLabels:
          machineconfiguration.openshift.io/role: worker-cnf
    - machineConfigPoolSelector:
        matchLabels:
          machineconfiguration.openshift.io/role: worker-other

検証

  1. 以下のコマンドを実行して、NUMA Resources Operator が正常にデプロイされたことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get numaresourcesoperators.nodetopology.openshift.io

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                    AGE
numaresourcesoperator   27s

  2. 数分後、次のコマンドを実行して、必要なリソースが正常にデプロイされたことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get all -n openshift-numaresources

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                                    READY   STATUS    RESTARTS   AGE
pod/numaresources-controller-manager-7d9d84c58d-qk2mr   1/1     Running   0          12m
pod/numaresourcesoperator-worker-7d96r                  2/2     Running   0          97s
pod/numaresourcesoperator-worker-crsht                  2/2     Running   0          97s
pod/numaresourcesoperator-worker-jp9mw                  2/2     Running   0          97s

11.4.2. NUMA 対応のセカンダリー Pod スケジューラーのデプロイ

NUMA Resources Operator をインストールした後、次の手順に従って NUMA 対応のセカンダリー Pod スケジューラーをデプロイします。

手順

  1. NUMA 対応のカスタム Pod スケジューラーをデプロイする NUMAResourcesScheduler カスタムリソースを作成します。

    1. 次の最小限必要な YAML を nro-scheduler.yaml ファイルに保存します。

      Copy to Clipboard Toggle word wrap 
      apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.18"
      1
      1
      非接続環境では、次のいずれかの方法でこのイメージの解像度を設定してください。
      • ImageTagMirrorSet カスタムリソース (CR) を作成する。詳細は、「関連情報」セクションの「イメージレジストリーのリポジトリーミラーリングの設定」を参照してください。
      • 切断されたレジストリーへの URL を設定する。

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

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

  2. 数秒後、次のコマンドを実行して、必要なリソースのデプロイメントが成功したことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get all -n openshift-numaresources

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                                    READY   STATUS    RESTARTS   AGE
pod/numaresources-controller-manager-7d9d84c58d-qk2mr   1/1     Running   0          12m
pod/numaresourcesoperator-worker-7d96r                  2/2     Running   0          97s
pod/numaresourcesoperator-worker-crsht                  2/2     Running   0          97s
pod/numaresourcesoperator-worker-jp9mw                  2/2     Running   0          97s
pod/secondary-scheduler-847cb74f84-9whlm                1/1     Running   0          10m

NAME                                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
daemonset.apps/numaresourcesoperator-worker   3         3         3       3            3           node-role.kubernetes.io/worker=   98s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/numaresources-controller-manager   1/1     1            1           12m
deployment.apps/secondary-scheduler                1/1     1            1           10m

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/numaresources-controller-manager-7d9d84c58d   1         1         1       12m
replicaset.apps/secondary-scheduler-847cb74f84                1         1         1       10m

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

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

注記

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

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

関連情報

11.4.4. パフォーマンスプロファイルの例

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

Copy to Clipboard Toggle word wrap 
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
1
これは、NUMA Resources Operator を設定する MachineConfigPool と一致する必要があります。たとえば、通信ワークロードを実行するノードのセットを指定する、worker-cnf という名前の MachineConfigPool を作成したとします。
2
topologyPolicy は single-numa-node に設定する必要があります。PPC ツールを実行するときに topology-manager-policy 引数を single-numa-node に設定して、確実に設定するようにします。

11.4.5. KubeletConfig CR の作成

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

手順

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

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

      Copy to Clipboard Toggle word wrap 
      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
      1
      このラベルを、NUMAResourcesOperator CR の machineConfigPoolSelector と一致するように調整します。
      2
      cpuManagerPolicy の場合、static は小文字の s を使用する必要があります。
      3
      ノード上の CPU に基づいて調整します。
      4
      memoryManagerPolicy の場合、Static は大文字の S を使用する必要があります。
      5
      topologyManagerPolicy は single-numa-node に設定する必要があります。

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

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

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

11.4.6. NUMA 対応スケジューラーを使用したワークロードのスケジューリング

topo-aware-scheduler をインストールし、NUMAResourcesOperator および NUMAResourcesScheduler CR を適用し、クラスターが一致するパフォーマンスプロファイルまたは kubeletconfig を含むようになったので、ワークロードを処理する必要最小限のリソースを指定するデプロイメント CR を使用して、NUMA 対応スケジューラーでワークロードをスケジュールできます。

次のデプロイメント例では、サンプルワークロードに NUMA 対応のスケジューリングを使用します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次のコマンドを実行して、クラスターにデプロイされている NUMA 対応スケジューラーの名前を取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

    出力例

    Copy to Clipboard Toggle word wrap 
    "topo-aware-scheduler"

  2. topo-aware-scheduler という名前のスケジューラーを使用する Deployment CR を作成します。次に例を示します。

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

      Copy to Clipboard Toggle word wrap 
      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 を作成します。

      Copy to Clipboard Toggle word wrap 
      $ oc create -f nro-deployment.yaml

検証

  1. デプロイメントが正常に行われたことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pods -n openshift-numaresources

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                                READY   STATUS    RESTARTS   AGE
numa-deployment-1-6c4f5bdb84-wgn6g                  2/2     Running   0          5m2s
numaresources-controller-manager-7d9d84c58d-4v65j   1/1     Running   0          18m
numaresourcesoperator-worker-7d96r                  2/2     Running   4          43m
numaresourcesoperator-worker-crsht                  2/2     Running   2          43m
numaresourcesoperator-worker-jp9mw                  2/2     Running   2          43m
secondary-scheduler-847cb74f84-fpncj                1/1     Running   0          18m

  2. 次のコマンドを実行して、topo-aware-scheduler がデプロイされた Pod をスケジュールしていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc describe pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources

    出力例

    Copy to Clipboard Toggle word wrap 
    Events:
  Type    Reason          Age    From                  Message
  ----    ------          ----   ----                  -------
  Normal  Scheduled       4m45s  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-6c4f5bdb84-wgn6g to worker-1

    注記

    スケジューリングに使用可能なリソースよりも多くのリソースを要求するデプロイメントは、MinimumReplicasUnavailable エラーで失敗します。必要なリソースが利用可能になると、デプロイメントは成功します。Pod は、必要なリソースが利用可能になるまで Pending 状態のままになります。

  3. ノードに割り当てられる予定のリソースが一覧表示されていることを確認します。

    1. 次のコマンドを実行して、デプロイメント Pod を実行しているノードを特定します。

      Copy to Clipboard Toggle word wrap 
      $ oc get pods -n openshift-numaresources -o wide

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
numa-deployment-1-6c4f5bdb84-wgn6g   0/2     Running   0          82m   10.128.2.50   worker-1   <none>  <none>

    2. 次のコマンドを実行します。このとき、デプロイメント Pod を実行しているノードの名前を指定します。

      Copy to Clipboard Toggle word wrap 
      $ oc describe noderesourcetopologies.topology.node.k8s.io worker-1

      出力例

      Copy to Clipboard Toggle word wrap 
      ...

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 であることを確認できます。

    Copy to Clipboard Toggle word wrap 
    $ oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"

    出力例

    Copy to Clipboard Toggle word wrap 
    Guaranteed

11.5. オプション: NUMA リソース更新のポーリング操作の設定

nodeGroup 内の NUMA Resources Operator によって制御されるデーモンは、リソースをポーリングして、利用可能な NUMA リソースに関する更新を取得します。NUMAResourcesOperator カスタムリソース (CR) で spec.nodeGroups 仕様を設定することで、これらのデーモンのポーリング操作を微調整できます。これにより、ポーリング操作の高度な制御が可能になります。これらの仕様を設定して、スケジューリング動作を改善し、最適ではないスケジューリング決定のトラブルシューティングを行います。

設定オプションは次のとおりです。

  • infoRefreshMode: kubelet をポーリングするためのトリガー条件を決定します。NUMA Resources Operator は、結果として取得した情報を API サーバーに報告します。
  • infoRefreshPeriod: ポーリング更新の間隔を決定します。

  • podsFingerprinting: ノード上で実行されている現在の Pod セットのポイントインタイム情報がポーリング更新で公開されるかどうかを決定します。

    注記

    podsFingerprinting のデフォルト値は EnabledExclusiveResources です。スケジューラーのパフォーマンスを最適化するには、podsFingerprinting を EnabledExclusiveResources または Enabled に設定します。さらに、NUMAResourcesScheduler カスタムリソース (CR) の cacheResyncPeriod を 0 より大きい値に設定します。cacheResyncPeriod 仕様は、ノード上の保留中のリソースを監視することで、より正確なリソースの可用性を報告するのに役立ちます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールしている。

手順

  • NUMAResourcesOperator CR で spec.nodeGroups 仕様を設定します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
  - config:
      infoRefreshMode: Periodic
    1 
    
      infoRefreshPeriod: 10s
    2 
    
      podsFingerprinting: Enabled
    3 
    
    name: worker
    1
    有効な値は Periodic、Events、PeriodicAndEvents です。Periodic を使用して、infoRefreshPeriod で定義した間隔で kubelet をポーリングします。Events を使用して、Pod のライフサイクルイベントごとに kubelet をポーリングします。両方のメソッドを有効にするには、PeriodicAndEvents を使用します。
    2
    Periodic または PeriodicAndEvents リフレッシュモードのポーリング間隔を定義します。リフレッシュモードが Events の場合、このフィールドは無視されます。
    3
    有効な値は、Enabled、Disabled、および EnabledExclusiveResources です。NUMAResourcesScheduler の cacheResyncPeriod 仕様では、Enabled または EnabledExclusiveResources に設定する必要があります。

検証

  1. NUMA Resources Operator をデプロイした後、次のコマンドを実行して、ノードグループ設定が適用されたことを検証します。

    Copy to Clipboard Toggle word wrap 
    $ oc get numaresop numaresourcesoperator -o json | jq '.status'

    出力例

    Copy to Clipboard Toggle word wrap 
          ...

        "config": {
        "infoRefreshMode": "Periodic",
        "infoRefreshPeriod": "10s",
        "podsFingerprinting": "Enabled"
      },
      "name": "worker"

      ...

11.6. NUMA 対応スケジューリングのトラブルシューティング

NUMA 対応の Pod スケジューリングに関する一般的な問題をトラブルシューティングするには、次の手順を実行します。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールし、NUMA 対応のセカンダリースケジューラーをデプロイします。

手順

  1. 次のコマンドを実行して、noderesourcetopologies CRD がクラスターにデプロイされていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get crd | grep noderesourcetopologies

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                                              CREATED AT
noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

  2. 次のコマンドを実行して、NUMA 対応スケジューラー名が NUMA 対応ワークロードで指定された名前と一致することを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

    出力例

    Copy to Clipboard Toggle word wrap 
    topo-aware-scheduler

  3. NUMA 対応のスケジュール可能なノードに noderesourcetopologies CR が適用されていることを確認します。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc get noderesourcetopologies.topology.node.k8s.io

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                    AGE
compute-0.example.com   17h
compute-1.example.com   17h

    注記

    ノードの数は、マシン設定プール (mcp) ワーカー定義によって設定されているワーカーノードの数と等しくなければなりません。

  4. 次のコマンドを実行して、スケジュール可能なすべてのノードの NUMA ゾーンの粒度を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
items:
- apiVersion: topology.node.k8s.io/v1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:38Z"
    generation: 63760
    name: worker-0
    resourceVersion: "8450223"
    uid: 8b77be46-08c0-4074-927b-d49361471590
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones:
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources:
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262352048128"
      available: "262352048128"
      capacity: "270107316224"
      name: memory
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269231067136"
      available: "269231067136"
      capacity: "270573244416"
      name: memory
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    type: Node
- apiVersion: topology.node.k8s.io/v1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:37Z"
    generation: 62061
    name: worker-1
    resourceVersion: "8450129"
    uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones:
    1 
    
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources:
    2 
    
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262391033856"
      available: "262391033856"
      capacity: "270146301952"
      name: memory
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269192085504"
      available: "269192085504"
      capacity: "270534262784"
      name: memory
    type: Node
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

    1
    zones 以下の各スタンザは、単一の NUMA ゾーンのリソースを記述しています。
    2
    resources は、NUMA ゾーンリソースの現在の状態を記述しています。items.zones.resources.available 以下に記載されているリソースが、保証された各 Pod に割り当てられた排他的な NUMA ゾーンリソースに対応していることを確認します。

11.6.1. より正確なリソース可用性の報告

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

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      Copy to Clipboard Toggle word wrap 
      $ oc get NUMAResourcesScheduler

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                     AGE
numaresourcesscheduler   92m

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      出力例

      Copy to Clipboard Toggle word wrap 
      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 次の YAML を nro-scheduler-cacheresync.yaml ファイルに保存します。この例では、ログレベルを Debug に変更します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.18"
  cacheResyncPeriod: "5s"
    1
    1
    スケジューラーキャッシュの同期間隔を秒単位の値で入力します。ほとんどの実装におけるこの値は、5 が一般的です。

  3. 次のコマンドを実行して、更新された NUMAResourcesScheduler リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f nro-scheduler-cacheresync.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

検証手順

  1. NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、CRD が正常に作成されたことを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get crd | grep numaresourcesschedulers

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                                                              CREATED AT
numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                     AGE
numaresourcesscheduler   3h26m

  2. スケジューラーのログが増加したログレベルを示していることを確認します。

    1. 以下のコマンドを実行して、openshift-numaresources namespace で実行されている Pod のリストを取得します。

      Copy to Clipboard Toggle word wrap 
      $ oc get pods -n openshift-numaresources

      出力例

      Copy to Clipboard Toggle word wrap 
      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 のログを取得します。

      Copy to Clipboard Toggle word wrap 
      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      出力例

      Copy to Clipboard Toggle word wrap 
      ...
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"

11.6.2. 高パフォーマンスワークロードの実行場所の変更

NUMA 対応のセカンダリースケジューラーは、ワークロードを最適に処理できるワーカーノード上および NUMA ノード内で、高パフォーマンスワークロードをスケジュールする役割を担います。デフォルトでは、セカンダリースケジューラーは、選択されたワーカーノード内で利用可能なリソースが最も多い NUMA ノードにワークロードを割り当てます。

ワークロードの実行場所を変更する場合は、NUMAResourcesScheduler カスタムリソースに scoringStrategy 設定を追加し、その値を MostAllocated または BalancedAllocation のいずれかに設定します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次の手順を使用して、現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      Copy to Clipboard Toggle word wrap 
      $ oc get NUMAResourcesScheduler

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                     AGE
numaresourcesscheduler   92m

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      出力例

      Copy to Clipboard Toggle word wrap 
      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 次の YAML を nro-scheduler-mostallocated.yaml ファイルに保存します。この例では、scoringStrategy を MostAllocated に変更します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v{product-version}"
  scoringStrategy:
        type: "MostAllocated"
    1
    1
    scoringStrategy 設定が省略されている場合は、デフォルトの LeastAllocated が適用されます。

  3. 次のコマンドを実行して、更新された NUMAResourcesScheduler リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f nro-scheduler-mostallocated.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

検証

  1. 次の手順を使用して、NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、カスタムリソース定義 (CRD) が正常に作成されたことを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get crd | grep numaresourcesschedulers

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                                                              CREATED AT
numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                     AGE
numaresourcesscheduler   3h26m

  2. 次のコマンドを実行して、スケジューラーの関連する ConfigMap リソースを確認し、ScoringStrategy が正しく適用されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get -n openshift-numaresources cm topo-aware-scheduler-config -o yaml | grep scoring -A 1

    出力例

    Copy to Clipboard Toggle word wrap 
    scoringStrategy:
  type: MostAllocated

11.6.3. NUMA 対応スケジューラーログの確認

ログを確認して、NUMA 対応スケジューラーの問題をトラブルシューティングします。必要に応じて、NUMAResourcesScheduler リソースの spec.logLevel フィールドを変更して、スケジューラーのログレベルを上げることができます。許容値は Normal、Debug、および Trace で、Trace が最も詳細なオプションとなります。

注記

セカンダリースケジューラーのログレベルを変更するには、実行中のスケジューラーリソースを削除し、ログレベルを変更して再デプロイします。このダウンタイム中、スケジューラーは新しいワークロードのスケジューリングに使用できません。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      Copy to Clipboard Toggle word wrap 
      $ oc get NUMAResourcesScheduler

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                     AGE
numaresourcesscheduler   90m

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      Copy to Clipboard Toggle word wrap 
      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      出力例

      Copy to Clipboard Toggle word wrap 
      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 以下の YAML をファイル nro-scheduler-debug.yaml に保存します。この例では、ログレベルを Debug に変更します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.18"
  logLevel: Debug

  3. 次のコマンドを実行して、更新された Debug ロギング NUMAResourcesScheduler リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f nro-scheduler-debug.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

検証手順

  1. NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、CRD が正常に作成されたことを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get crd | grep numaresourcesschedulers

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                                                              CREATED AT
numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                     AGE
numaresourcesscheduler   3h26m

  2. スケジューラーのログが増加したログレベルを示していることを確認します。

    1. 以下のコマンドを実行して、openshift-numaresources namespace で実行されている Pod のリストを取得します。

      Copy to Clipboard Toggle word wrap 
      $ oc get pods -n openshift-numaresources

      出力例

      Copy to Clipboard Toggle word wrap 
      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 のログを取得します。

      Copy to Clipboard Toggle word wrap 
      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      出力例

      Copy to Clipboard Toggle word wrap 
      ...
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"

11.6.4. リソーストポロジーエクスポーターのトラブルシューティング

対応する resource-topology-exporter ログを調べて、予期しない結果が発生している noderesourcetopologies オブジェクトをトラブルシューティングします。

注記

クラスター内の NUMA リソーストポロジーエクスポータインスタンスには、参照するノードの名前を付けることが推奨されます。たとえば、worker という名前のワーカーノードには、worker という対応する noderesourcetopologies オブジェクトがあるはずです。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. NUMA Resources Operator によって管理されるデーモンセットを取得します。各 daemonset には、NUMAResourcesOperator CR 内に対応する nodeGroup があります。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"

    出力例

    Copy to Clipboard Toggle word wrap 
    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}

  2. 前のステップの name の値を使用して、対象となる daemonset のラベルを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

    出力例

    Copy to Clipboard Toggle word wrap 
    {"name":"resource-topology"}

  3. 次のコマンドを実行して、resource-topology ラベルを使用して Pod を取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

    出力例

    Copy to Clipboard Toggle word wrap 
    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 コンテナーのログを調べます。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

    出力例

    Copy to Clipboard Toggle word wrap 
    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

11.6.5. 欠落しているリソーストポロジーエクスポーター設定マップの修正

クラスター設定が正しく設定されていないクラスターに NUMA Resources Operator をインストールすると、場合によっては、Operator はアクティブとして表示されますが、リソーストポロジーエクスポーター (RTE) デーモンセット Pod のログには、RTE の設定が欠落していると表示されます。以下に例を示します。

Copy to Clipboard Toggle word wrap 
Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

このログメッセージは、必要な設定の kubeletconfig がクラスターに適切に適用されなかったため、RTE configmap が欠落していることを示しています。たとえば、次のクラスターには numaresourcesoperator-worker configmap カスタムリソース (CR) がありません。

Copy to Clipboard Toggle word wrap 
$ oc get configmap

出力例

Copy to Clipboard Toggle word wrap 
NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

正しく設定されたクラスターでは、oc get configmap は numaresourcesoperator-worker configmap CR も返します。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールし、NUMA 対応のセカンダリースケジューラーをデプロイします。

手順

  1. 次のコマンドを使用して、kubeletconfig の spec.machineConfigPoolSelector.matchLabels と MachineConfigPool (mcp) ワーカー CR の metadata.labels の値を比較します。

    1. 次のコマンドを実行して、kubeletconfig ラベルを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get kubeletconfig -o yaml

      出力例

      Copy to Clipboard Toggle word wrap 
      machineConfigPoolSelector:
  matchLabels:
    cnf-worker-tuning: enabled

    2. 次のコマンドを実行して、mcp ラベルを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get mcp worker -o yaml

      出力例

      Copy to Clipboard Toggle word wrap 
      labels:
  machineconfiguration.openshift.io/mco-built-in: ""
  pools.operator.machineconfiguration.openshift.io/worker: ""

      cnf-worker-tuning: enabled ラベルが MachineConfigPool オブジェクトに存在しません。

  2. MachineConfigPool CR を編集して、不足しているラベルを含めます。次に例を示します。

    Copy to Clipboard Toggle word wrap 
    $ oc edit mcp worker -o yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    labels:
  machineconfiguration.openshift.io/mco-built-in: ""
  pools.operator.machineconfiguration.openshift.io/worker: ""
  cnf-worker-tuning: enabled

  3. ラベルの変更を適用し、クラスターが更新された設定を適用するのを待ちます。以下のコマンドを実行します。

検証

  • 不足している numaresourcesoperator-worker configmap CR が適用されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get configmap

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
numaresourcesoperator-worker   1      5m
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

11.6.6. NUMA Resources Operator データの収集

oc adm must-gather CLI コマンドを使用すると、NUMA Resources Operator に関連付けられた機能やオブジェクトなど、クラスターに関する情報を収集できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  • must-gather を使用して NUMA Resources Operator データを収集するには、NUMA Resources Operator の must-gather イメージを指定する必要があります。

    Copy to Clipboard Toggle word wrap 
    $ oc adm must-gather --image=registry.redhat.io/openshift4/numaresources-must-gather-rhel9:v4.18

第12章 スケーラビリティとパフォーマンスの最適化

12.1. ストレージの最適化

ストレージを最適化すると、すべてのリソースでストレージの使用を最小限に抑えることができます。管理者は、ストレージを最適化することで、既存のストレージリソースが効率的に機能できるようにすることができます。

12.1.1. 利用可能な永続ストレージオプション

永続ストレージオプションについて理解し、OpenShift Container Platform 環境を最適化できるようにします。

表12.1 利用可能なストレージオプション
ストレージタイプ説明例

ブロック

  • ブロックデバイスとしてオペレーティングシステムに公開されます。
  • ストレージを完全に制御し、ファイルシステムを通過してファイルの低いレベルで操作する必要のあるアプリケーションに適しています。
  • ストレージエリアネットワーク (SAN) とも呼ばれます。
  • 共有できません。一度に 1 つのクライアントだけがこのタイプのエンドポイントをマウントできるという意味です。

AWS EBS および VMware vSphere は、OpenShift Container Platform で永続ボリューム (PV) の動的なプロビジョニングをサポートします。

ファイル

  • マウントされるファイルシステムのエクスポートとして、OS に公開されます。
  • ネットワークアタッチストレージ (NAS) とも呼ばれます。
  • 同時実行、レイテンシー、ファイルロックのメカニズムその他の各種機能は、プロトコルおよび実装、ベンダー、スケールによって大きく異なります。

RHEL NFS、NetApp NFS [1]、および Vendor NFS

オブジェクト

  • REST API エンドポイント経由でアクセスできます。
  • OpenShift イメージレジストリーで使用するように設定できます。
  • アプリケーションは、ドライバーをアプリケーションやコンテナーに組み込む必要があります。

AWS S3

  1. NetApp NFS は Trident を使用する場合に動的 PV のプロビジョニングをサポートします。

12.1.3. データストレージ管理

以下の表は、OpenShift Container Platform コンポーネントがデータを書き込むメインディレクトリーの概要を示しています。

表12.3 OpenShift Container Platform データを保存するメインディレクトリー
ディレクトリー注記サイジング予想される拡張

/var/log

すべてのコンポーネントのログファイルです。

10 から 30 GB。

ログファイルはすぐに拡張する可能性があります。サイズは拡張するディスク別に管理するか、ログローテーションを使用して管理できます。

/var/lib/etcd

データベースを保存する際に etcd ストレージに使用されます。

20 GB 未満。

データベースは、最大 8 GB まで拡張できます。

環境と共に徐々に拡張します。メタデータのみを格納します。

メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。

/var/lib/containers

これは CRI-O ランタイムのマウントポイントです。アクティブなコンテナーランタイム (Pod を含む) およびローカルイメージのストレージに使用されるストレージです。レジストリーストレージには使用されません。

16 GB メモリーの場合、1 ノードにつき 50 GB。このサイジングは、クラスターの最小要件の決定には使用しないでください。

メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。

拡張は実行中のコンテナーの容量によって制限されます。

/var/lib/kubelet

Pod の一時ボリュームストレージです。これには、ランタイムにコンテナーにマウントされる外部のすべての内容が含まれます。環境変数、kube シークレット、および永続ボリュームでサポートされていないデータボリュームが含まれます。

変動あり。

ストレージを必要とする Pod が永続ボリュームを使用している場合は最小になります。一時ストレージを使用する場合はすぐに拡張する可能性があります。

12.1.4. Microsoft Azure のストレージパフォーマンスの最適化

OpenShift Container Platform と Kubernetes は、ディスクのパフォーマンスの影響を受けるため、特にコントロールプレーンノードの etcd には、より高速なストレージが推奨されます。

実稼働の Azure クラスターとワークロードが集中するクラスターの場合、コントロールプレーンマシンの仮想マシンオペレーティングシステムディスクは、テスト済みの推奨最小スループットである 5000 IOPS/200MBps を維持できなければなりません。このスループットは、P30 (最低 1 TiB Premium SSD) を使用することで実現できます。Azure および Azure Stack Hub の場合、ディスクパフォーマンスは SSD ディスクサイズに直接依存します。Standard_D8s_v3 仮想マシンまたは他の同様のマシンタイプでサポートされるスループットと 5000 IOPS の目標を達成するには、少なくとも P30 ディスクが必要です。

データ読み取り時のレイテンシーを低く抑え、高い IOPS およびスループットを実現するには、ホストのキャッシュを ReadOnly に設定する必要があります。仮想マシンメモリーまたはローカル SSD ディスクに存在するキャッシュからのデータの読み取りは、blob ストレージにあるディスクからの読み取りよりもはるかに高速です。

12.2. ルーティングの最適化

OpenShift Container Platform HAProxy ルーターは、パフォーマンスを最適化するためにスケーリングまたは設定できます。

12.2.1. ベースライン Ingress Controller (ルーター) のパフォーマンス

OpenShift Container Platform Ingress コントローラー (ルーター) は、ルートとイングレスを使用して設定されたアプリケーションとサービスのイングレストラフィックのイングレスポイントです。

1 秒に処理される HTTP 要求について、単一の HAProxy ルーターを評価する場合に、パフォーマンスは多くの要因により左右されます。特に以下が含まれます。

  • HTTP keep-alive/close モード
  • ルートタイプ
  • TLS セッション再開のクライアントサポート
  • ターゲットルートごとの同時接続数
  • ターゲットルート数
  • バックエンドサーバーのページサイズ
  • 基盤となるインフラストラクチャー (ネットワーク、CPU など)

特定の環境でのパフォーマンスは異なりますが、Red Hat ラボはサイズが 4 vCPU/16GB RAM のパブリッククラウドインスタンスでテストしています。1kB 静的ページを提供するバックエンドで終端する 100 ルートを処理する単一の HAProxy ルーターは、1 秒あたりに以下の数のトランザクションを処理できます。

HTTP keep-alive モードのシナリオの場合:

暗号化LoadBalancerServiceHostNetwork

なし

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

HTTP close (keep-alive なし) のシナリオの場合:

暗号化LoadBalancerServiceHostNetwork

なし

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

デフォルトの Ingress Controller 設定は、spec.tuningOptions.threadCount フィールドを 4 に設定して、使用されました。Load Balancer Service と Host Network という 2 つの異なるエンドポイント公開戦略がテストされました。TLS セッション再開は暗号化ルートについて使用されています。HTTP keep-alive では、1 台の HAProxy ルーターで、8 kB という小さなページサイズで 1 Gbit の NIC を飽和させることができます。

最新のプロセッサーが搭載されたベアメタルで実行する場合は、上記のパブリッククラウドインスタンスのパフォーマンスの約 2 倍のパフォーマンスになることを予想できます。このオーバーヘッドは、パブリッククラウドにある仮想化レイヤーにより発生し、プライベートクラウドベースの仮想化にも多くの場合、該当します。以下の表は、ルーターの背後で使用するアプリケーション数に関するガイドです。

アプリケーション数アプリケーションタイプ

5-10

静的なファイル/Web サーバーまたはキャッシュプロキシー

100-1000

動的なコンテンツを生成するアプリケーション

通常、HAProxy は、使用しているテクノロジーに応じて、最大 1000 個のアプリケーションのルートをサポートできます。Ingress Controller のパフォーマンスは、言語や静的コンテンツと動的コンテンツの違いを含め、その背後にあるアプリケーションの機能およびパフォーマンスによって制限される可能性があります。

Ingress またはルーターのシャード化は、アプリケーションに対してより多くのルートを提供するために使用され、ルーティング層の水平スケーリングに役立ちます。

Ingress シャーディングの詳細は、ルートラベルを使用した Ingress Controller のシャーディング設定 および namespace ラベルを使用した Ingress Controller のシャーディング設定 を参照してください。

Ingress Controller のデプロイメントは、スレッドの Ingress Controller スレッド数の設定、タイムアウトの Ingress Controller 設定パラメーター、および Ingress Controller 仕様のその他のチューニング設定に記載されている情報を使用して変更できます。

12.2.2. Ingress Controller の liveness、準備、および起動プローブの設定

クラスター管理者は、OpenShift Container Platform Ingress Controller (ルーター) によって管理されるルーター展開の kubelet の活性、準備、およびスタートアッププローブのタイムアウト値を設定できます。ルーターの liveness および readiness プローブは、デフォルトのタイムアウト値である 1 秒を使用します。これは、ネットワークまたはランタイムのパフォーマンスが著しく低下している場合には短すぎます。プローブのタイムアウトにより、アプリケーション接続を中断する不要なルーターの再起動が発生する可能性があります。より大きなタイムアウト値を設定する機能により、不要で不要な再起動のリスクを減らすことができます。

ルーターコンテナーの livenessProbe、readinessProbe、および startupProbe パラメーターの timeoutSeconds 値を更新できます。

パラメーター説明

livenessProbe

livenessProbe は、Pod が停止していて再起動が必要かどうかを kubelet に報告します。

readinessProbe

readinessProbe は、Pod が正常かどうかを報告します。準備プローブが異常な Pod を報告すると、kubelet は Pod をトラフィックを受け入れる準備ができていないものとしてマークします。その後、その Pod のエンドポイントは準備ができていないとマークされ、このステータスが kube-proxy に伝播されます。ロードバランサーが設定されたクラウドプラットフォームでは、kube-proxy はクラウドロードバランサーと通信して、その Pod を持つノードにトラフィックを送信しません。

startupProbe

startupProbe は、kubelet がルーターの活性と準備のプローブの送信を開始する前に、ルーター Pod の初期化に最大 2 分を与えます。この初期化時間により、多くのルートまたはエンドポイントを持つルーターが時期尚早に再起動するのを防ぐことができます。

重要

タイムアウト設定オプションは、問題を回避するために使用できる高度なチューニング手法です。ただし、これらの問題は最終的に診断する必要があり、プローブがタイムアウトする原因となる問題については、サポートケースまたは Jira issue を開く必要があります。

次の例は、デフォルトのルーター展開に直接パッチを適用して、活性プローブと準備プローブに 5 秒のタイムアウトを設定する方法を示しています。

Copy to Clipboard Toggle word wrap 
$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

検証

Copy to Clipboard Toggle word wrap 
$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3

12.2.3. HAProxy リロード間隔の設定

ルートまたはルートに関連付けられたエンドポイントを更新すると、OpenShift Container Platform ルーターは HAProxy の設定を更新します。次に、HAProxy は更新された設定をリロードして、これらの変更を有効にします。HAProxy がリロードすると、更新された設定を使用して新しい接続を処理する新しいプロセスが生成されます。

HAProxy は、それらの接続がすべて閉じられるまで、既存の接続を処理するために古いプロセスを実行し続けます。古いプロセスの接続が長く続くと、これらのプロセスはリソースを蓄積して消費する可能性があります。

デフォルトの最小 HAProxy リロード間隔は 5 秒です。spec.tuningOptions.reloadInterval フィールドを使用して Ingress Controller を設定し、より長い最小リロード間隔を設定できます。

警告

最小 HAProxy リロード間隔に大きな値を設定すると、ルートとそのエンドポイントの更新を監視する際にレイテンシーが発生する可能性があります。リスクを軽減するには、更新の許容レイテンシーよりも大きな値を設定しないようにしてください。

手順

  • 次のコマンドを実行して、Ingress Controller のデフォルト最小 HAProxy リロード間隔を 15 秒に変更します。

    Copy to Clipboard Toggle word wrap 
    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'

12.3. ネットワークの最適化

OVN-Kubernetes は、Geneve に似たプロトコルである Generic Network Virtualization Encapsulation (Geneve) を使用して、ノード間のトラフィックをトンネリングします。このネットワークは、ネットワークインターフェイスコントローラー (NIC) オフロードを使用して調整できます。

Geneve は、ネットワークを 4096 から 1600 万以上に増加したり、物理ネットワーク全体でレイヤー 2 接続を実現したりするなど、VLAN を超える利点を提供します。これにより、異なるシステム上で実行されている場合でも、サービスの背後にある Pod すべてが相互に通信できるようになります。

OpenShift Container Platform を実行するクラウド環境、仮想環境、ベアメタル環境では、最小限のチューニングで NIC の機能の大部分を使用できます。OVN-Kubernetes と Geneve トンネリングを使用する実稼働クラスターは、特別な設定なしで、高スループットのトラフィックを効率的に処理し、スケールアップ (100 Gbps NIC の利用など) およびスケールアウト (NIC の追加など) を行うことができます。

効率の最大化が重要な一部の高パフォーマンス環境では、ターゲットを絞ったパフォーマンスチューニングによって、CPU 使用率を最適化し、オーバーヘッドを削減し、NIC の機能を最大限に活用できます。

最大スループットと CPU 効率が重要な環境では、次の方法を使用してパフォーマンスをさらに最適化できます。

  • iPerf3 や k8s-netperf などのツールを使用してネットワークのパフォーマンスを検証します。これらのツールを使用すると、Pod およびノードインターフェイス全体のスループット、レイテンシー、および 1 秒あたりのパケット数 (PPS) を評価できます。
  • Border Gateway Protocol (BGP) などの OVN-Kubernetes ユーザー定義ネットワーク (UDN) ルーティング手法を評価します。
  • Geneve オフロード対応ネットワークアダプターを使用します。Geneve オフロードは、システムの CPU から、パケットのチェックサム計算と関連の CPU オーバーヘッドを、ネットワークアダプター上の専用のハードウェアに移動します。これにより、CPU サイクルが解放され、Pod やアプリケーションで使用できるようになります。また、ネットワークインフラストラクチャーの全帯域幅をユーザーが使用できるようになります。

12.3.1. ネットワークでの MTU の最適化

重要な Maximum Transmission Unit (MTU) が 2 つあります。1 つはネットワークインターフェイスコントローラー (NIC) MTU で、もう 1 つはクラスターネットワーク MTU です。

NIC の MTU は OpenShift Container Platform のインストール時に設定します。また、クラスターの MTU の変更は、インストール後のタスクとして実行できます。詳細は、「クラスターネットワーク MTU の変更」を参照してください。

OVN-Kubernetes プラグインを使用するクラスターの場合、MTU はネットワークの NIC でサポートされている最大値よりも 100 バイト以上小さい必要があります。スループットを最適化する場合は、8900 など、可能な限り大きな値を選択します。レイテンシーを最低限に抑えるために最適化するには、より小さい値を選択します。

重要

クラスターが OVN-Kubernetes プラグインを使用し、ネットワークが NIC を使用してネットワーク経由で断片化されていないジャンボフレームパケットを送受信する場合は、Pod が失敗しないように、NIC の MTU 値として 9000 バイトを指定する必要があります。

関連情報

12.3.3. IPsec の影響

ノードホストの暗号化、復号化に CPU 機能が使用されるので、使用する IP セキュリティーシステムにかかわらず、ノードのスループットおよび CPU 使用率の両方でのパフォーマンスに影響があります。

IPSec は、NIC に到達する前に IP ペイロードレベルでトラフィックを暗号化して、NIC オフロードに使用されてしまう可能性のあるフィールドを保護します。つまり、IPSec が有効な場合には、NIC アクセラレーション機能を使用できない場合があり、スループットの減少、CPU 使用率の上昇につながります。

12.3.4. 関連情報

12.4. マウント namespace のカプセル化による CPU 使用率の最適化

マウント namespace のカプセル化を使用して kubelet および CRI-O プロセスにプライベート namespace を提供することで、OpenShift Container Platform クラスターでの CPU 使用率を最適化できます。これにより、機能に違いはなく、systemd が使用するクラスター CPU リソースが削減されます。

重要

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

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

12.4.1. マウント namespace のカプセル化

マウント namespace は、異なる namespace のプロセスが互いのファイルを表示できないように、マウントポイントを分離するために使用されます。カプセル化は、Kubernetes マウント namespace を、ホストオペレーティングシステムによって常にスキャンされない別の場所に移動するプロセスです。

ホストオペレーティングシステムは systemd を使用して、すべてのマウント namespace (標準の Linux マウントと、Kubernetes が操作に使用する多数のマウントの両方) を常にスキャンします。kubelet と CRI-O の現在の実装はどちらも、すべてのコンテナーランタイムと kubelet マウントポイントに最上位の namespace を使用します。ただし、これらのコンテナー固有のマウントポイントをプライベート namespace にカプセル化すると、systemd のオーバーヘッドが削減され、機能に違いはありません。CRI-O と kubelet の両方に個別のマウント namespace を使用すると、systemd または他のホスト OS の相互作用からコンテナー固有のマウントをカプセル化できます。

CPU の大幅な最適化を潜在的に達成するこの機能は、すべての OpenShift Container Platform 管理者が利用できるようになりました。カプセル化は、Kubernetes 固有のマウントポイントを特権のないユーザーによる検査から安全な場所に保存することで、セキュリティーを向上させることもできます。

次の図は、カプセル化の前後の Kubernetes インストールを示しています。どちらのシナリオも、双方向、ホストからコンテナー、およびなしのマウント伝搬設定を持つコンテナーの例を示しています。

カプセル化前

ここでは、systemd、ホストオペレーティングシステムプロセス、kubelet、およびコンテナーランタイムが単一のマウント namespace を共有していることがわかります。

  • systemd、ホストオペレーティングシステムプロセス、kubelet、およびコンテナーランタイムはそれぞれ、すべてのマウントポイントにアクセスして可視化できます。
  • コンテナー 1 は、双方向のマウント伝達で設定され、systemd およびホストマウント、kubelet および CRI-O マウントにアクセスできます。/run/a などのコンテナー 1 で開始されたマウントは、systemd、ホスト OS プロセス、kubelet、コンテナーランタイム、およびホストからコンテナーへのまたは双方向のマウント伝達が設定されている他のコンテナー (コンテナー 2 のように) に表示されます。
  • ホストからコンテナーへのマウント伝達で設定されたコンテナー 2 は、systemd およびホストマウント、kubelet および CRI-O マウントにアクセスできます。/run/b などのコンテナー 2 で発生したマウントは、他のコンテキストからは見えません。
  • マウント伝達なしで設定されたコンテナー 3 には、外部マウントポイントが表示されません。/run/c などのコンテナー 3 で開始されたマウントは、他のコンテキストからは見えません。

次の図は、カプセル化後のシステム状態を示しています。

カプセル化後
  • メインの systemd プロセスは、Kubernetes 固有のマウントポイントの不要なスキャンに専念しなくなりました。systemd 固有のホストマウントポイントのみを監視します。
  • ホストオペレーティングシステムプロセスは、systemd およびホストマウントポイントにのみアクセスできます。
  • CRI-O と kubelet の両方に個別のマウント namespace を使用すると、すべてのコンテナー固有のマウントが systemd または他のホスト OS の対話から完全に分離されます。
  • コンテナー 1 の動作は変更されていませんが、/run/a などのコンテナーが作成するマウントが systemd またはホスト OS プロセスから認識されなくなります。kubelet、CRI-O、およびホストからコンテナーまたは双方向のマウント伝達が設定されている他のコンテナー (コンテナー 2 など) からは引き続き表示されます。
  • コンテナー 2 とコンテナー 3 の動作は変更されていません。

12.4.2. マウント namespace のカプセル化の設定

クラスターがより少ないリソースオーバーヘッドで実行されるように、マウント namespace のカプセル化を設定できます。

注記

マウント namespace のカプセル化はテクノロジープレビュー機能であり、デフォルトでは無効になっています。これを使用するには、機能を手動で有効にする必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次の YAML を使用して、mount_namespace_config.yaml という名前のファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    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 を適用します。

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

    出力例

    Copy to Clipboard Toggle word wrap 
    machineconfig.machineconfiguration.openshift.io/99-kubens-master created
machineconfig.machineconfiguration.openshift.io/99-kubens-worker created

  3. MachineConfig CR がクラスターに適用されるまで、最大 30 分かかる場合があります。次のコマンドを実行して、MachineConfig CR のステータスをチェックできます。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    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 がすべてのコントロールプレーンとワーカーノードに正常に適用されるまで待ちます。

    Copy to Clipboard Toggle word wrap 
    $ oc wait --for=condition=Updated mcp --all --timeout=30m

    出力例

    Copy to Clipboard Toggle word wrap 
    machineconfigpool.machineconfiguration.openshift.io/master condition met
machineconfigpool.machineconfiguration.openshift.io/worker condition met

検証

クラスターホストのカプセル化を確認するには、次のコマンドを実行します。

  1. クラスターホストへのデバッグシェルを開きます。

    Copy to Clipboard Toggle word wrap 
    $ oc debug node/<node_name>

  2. chroot セッションを開きます。

    Copy to Clipboard Toggle word wrap 
    sh-4.4# chroot /host

  3. systemd マウント namespace を確認します。

    Copy to Clipboard Toggle word wrap 
    sh-4.4# readlink /proc/1/ns/mnt

    出力例

    Copy to Clipboard Toggle word wrap 
    mnt:[4026531953]

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

    Copy to Clipboard Toggle word wrap 
    sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt

    出力例

    Copy to Clipboard Toggle word wrap 
    mnt:[4026531840]

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

    Copy to Clipboard Toggle word wrap 
    sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt

    出力例

    Copy to Clipboard Toggle word wrap 
    mnt:[4026531840]

これらのコマンドは、systemd、kubelet、およびコンテナーランタイムに関連付けられたマウント namespace を返します。OpenShift Container Platform では、コンテナーランタイムは CRI-O です。

上記の例のように、systemd が kubelet および CRI-O とは異なるマウント namespace にある場合、カプセル化が有効になります。3 つのプロセスすべてが同じマウント namespace にある場合、カプセル化は有効ではありません。

12.4.3. カプセル化された namespace の検査

Red Hat Enterprise Linux CoreOS (RHCOS) で利用可能な kubensenter スクリプトを使用して、デバッグまたは監査の目的でクラスターホストオペレーティングシステムの Kubernetes 固有のマウントポイントを検査できます。

クラスターホストへの SSH シェルセッションは、デフォルトの namespace にあります。SSH シェルプロンプトで Kubernetes 固有のマウントポイントを検査するには、ルートとして kubensenter スクリプトを実行する必要があります。kubensenter スクリプトは、マウントカプセル化の状態を認識しており、カプセル化が有効になっていない場合でも安全に実行できます。

注記

oc debug リモートシェルセッションは、デフォルトで Kubernetes namespace 内で開始されます。oc debug を使用する場合、マウントポイントを検査するために kubensenter を実行する必要はありません。

カプセル化機能が有効になっていない場合、kubensenter findmnt コマンドと findmnt コマンドは、oc debug セッションで実行されているか SSH シェルプロンプトで実行されているかに関係なく、同じ出力を返します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • クラスターホストへの SSH アクセスを設定しました。

手順

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

    Copy to Clipboard Toggle word wrap 
    $ ssh core@<node_name>

  2. root ユーザーとして、提供された kubensenter スクリプトを使用してコマンドを実行します。Kubernetes namespace 内で単一のコマンドを実行するには、コマンドと任意の引数を kubensenter スクリプトに提供します。たとえば、Kubernetes namespace 内で findmnt コマンドを実行するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    [core@control-plane-1 ~]$ sudo kubensenter findmnt

    出力例

    Copy to Clipboard Toggle word wrap 
    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 内で新しいインタラクティブシェルを開始するには、引数を指定せずに kubensenter スクリプトを実行します。

    Copy to Clipboard Toggle word wrap 
    [core@control-plane-1 ~]$ sudo kubensenter

    出力例

    Copy to Clipboard Toggle word wrap 
    kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt

12.4.4. カプセル化された namespace で追加サービスを実行する

ホスト OS で実行する機能に依存し、kubelet、CRI-O、またはコンテナー自体によって作成されたマウントポイントを表示できる監視ツールは、これらのマウントポイントを表示するためにコンテナーマウント namespace に入る必要があります。OpenShift Container Platform に付属する kubensenter スクリプトは、Kubernetes マウントポイント内で別のコマンドを実行し、既存のツールを適応させるために使用できます。

kubensenter スクリプトは、マウントカプセル化機能の状態を認識しており、カプセル化が有効になっていない場合でも安全に実行できます。その場合、スクリプトはデフォルトのマウント namespace で提供されたコマンドを実行します。

たとえば、systemd サービスを新しい Kubernetes マウント namespace 内で実行する必要がある場合は、サービスファイルを編集し、kubensenter で ExecStart= コマンドラインを使用します。

Copy to Clipboard Toggle word wrap 
[Unit]
Description=Example service
[Service]
ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2

12.4.5. 関連情報

第13章 ベアメタルホストの管理

OpenShift Container Platform をベアメタルクラスターにインストールする場合、クラスターに存在するベアメタルホストの machine および machineset カスタムリソース (CR) を使用して、ベアメタルノードをプロビジョニングし、管理できます。

13.1. ベアメタルホストおよびノードについて

Red Hat Enterprise Linux CoreOS (RHCOS) ベアメタルホストをクラスター内のノードとしてプロビジョニングするには、まずベアメタルホストハードウェアに対応する MachineSet カスタムリソース (CR) オブジェクトを作成します。ベアメタルホストコンピュートマシンセットは、お使いの設定に固有のインフラストラクチャーコンポーネントを記述します。特定の Kubernetes ラベルをこれらのコンピュートマシンセットに適用してから、インフラストラクチャーコンポーネントを更新して、それらのマシンでのみ実行されるようにします。

Machine CR は、metal3.io/autoscale-to-hosts アノテーションを含む関連する MachineSet をスケールアップする際に自動的に作成されます。OpenShift Container Platform は Machine CR を使用して、MachineSet CR で指定されるホストに対応するベアメタルノードをプロビジョニングします。

13.2. ベアメタルホストのメンテナンス

OpenShift Container Platform Web コンソールからクラスター内のベアメタルホストの詳細を維持することができます。Compute → Bare Metal Hosts に移動し、Actions ドロップダウンメニューからタスクを選択します。ここでは、BMC の詳細、ホストの起動 MAC アドレス、電源管理の有効化などの項目を管理できます。また、ホストのネットワークインターフェイスおよびドライブの詳細を確認することもできます。

ベアメタルホストをメンテナンスモードに移行できます。ホストをメンテナンスモードに移行すると、スケジューラーはすべての管理ワークロードを対応するベアメタルノードから移動します。新しいワークロードは、メンテナンスモードの間はスケジュールされません。

Web コンソールでベアメタルホストのプロビジョニングを解除することができます。ホストのプロビジョニング解除により以下のアクションが実行されます。

  1. ベアメタルホスト CR に cluster.k8s.io/delete-machine: true のアノテーションを付けます。
  2. 関連するコンピュートマシンセットをスケールダウンします
注記

デーモンセットおよび管理対象外の静的 Pod を別のノードに最初に移動することなく、ホストの電源をオフにすると、サービスの中断やデータの損失が生じる場合があります。

関連情報

13.2.1. Web コンソールを使用したベアメタルホストのクラスターへの追加

Web コンソールのクラスターにベアメタルホストを追加できます。

前提条件

  • RHCOS クラスターのベアメタルへのインストール
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  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 を選択してクラスター内のマシンレプリカ数を増やします。
注記

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

13.2.2. Web コンソールの YAML を使用したベアメタルホストのクラスターへの追加

ベアメタルホストを記述する YAML ファイルを使用して、Web コンソールのクラスターにベアメタルホストを追加できます。

前提条件

  • クラスターで使用するために RHCOS コンピュートマシンをベアメタルインフラストラクチャーにインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ベアメタルホストの Secret CR を作成します。

手順

  1. Web コンソールで、Compute → Bare Metal Hosts に移動します。
  2. Add Host → New from YAML を選択します。

  3. 以下の YAML をコピーして貼り付け、ホストの詳細で関連フィールドを変更します。

    Copy to Clipboard Toggle word wrap 
    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 コマンドおよび適切なベアメタルコンピュートマシンセットを使用して、ベアメタルノードの数を管理することもできます。

13.2.3. 利用可能なベアメタルホストの数へのマシンの自動スケーリング

利用可能な BareMetalHost オブジェクトの数に一致する Machine オブジェクトの数を自動的に作成するには、metal3.io/autoscale-to-hosts アノテーションを MachineSet オブジェクトに追加します。

前提条件

  • クラスターで使用する RHCOS ベアメタルコンピュートマシンをインストールし、対応する BareMetalHost オブジェクトを作成している。
  • OpenShift Container Platform CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. metal3.io/autoscale-to-hosts アノテーションを追加して、自動スケーリング用に設定するコンピュートマシンセットにアノテーションを付けます。<machineset> をコンピュートマシンセットの名前に置き換えます。

    Copy to Clipboard Toggle word wrap 
    $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'

    新しいスケーリングされたマシンが起動するまで待ちます。

注記

BareMetalHost オブジェクトを使用してクラスター内にマシンを作成し、その後ラベルまたはセレクターが BareMetalHost で変更される場合、BareMetalHost オブジェクトは Machine オブジェクトが作成された MachineSet に対して引き続きカウントされます。

13.2.4. プロビジョナーノードからのベアメタルホストの削除

特定の状況では、プロビジョナーノードからベアメタルホストを一時的に削除する場合があります。たとえば、OpenShift Container Platform 管理コンソールを使用して、または Machine Config Pool の更新の結果として、ベアメタルホストの再起動がトリガーされたプロビジョニング中に、OpenShift Container Platform は統合された Dell Remote Access Controller (iDrac) にログインし、ジョブキューの削除を発行します。

利用可能な BareMetalHost オブジェクトの数と一致する数の Machine オブジェクトを管理しないようにするには、baremetalhost.metal3.io/detached アノテーションを MachineSet オブジェクトに追加します。

注記

このアノテーションは、Provisioned、ExternallyProvisioned、または Ready/Available 状態の BareMetalHost オブジェクトに対してのみ効果があります。

前提条件

  • クラスターで使用する RHCOS ベアメタルコンピュートマシンをインストールし、対応する BareMetalHost オブジェクトを作成している。
  • OpenShift Container Platform CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. プロビジョナーノードから削除するコンピューティングマシンセットに、baremetalhost.metal3.io/detached アノテーションを追加してアノテーションを付けます。

    Copy to Clipboard Toggle word wrap 
    $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'

    新しいマシンが起動するまで待ちます。

    注記

    BareMetalHost オブジェクトを使用してクラスター内にマシンを作成し、その後ラベルまたはセレクターが BareMetalHost で変更される場合、BareMetalHost オブジェクトは Machine オブジェクトが作成された MachineSet に対して引き続きカウントされます。

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

    Copy to Clipboard Toggle word wrap 
    $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'

関連情報

13.2.5. ベアメタルホストの電源をオフにする

ベアメタルクラスターホストの電源は、Web コンソールからオフにするか、OpenShift CLI (oc) を使用してクラスター内でパッチを適用することでオフにできます。ホストの電源をオフにする前に、ノードにスケジュール対象外 (unschedulable) のマークを付け、ノードからすべての Pod およびワークロードをドレインする必要があります。

前提条件

  • クラスターで使用するために、ベアメタルインフラストラクチャーに RHCOS コンピュートマシンをインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 管理対象となるようにホストを設定し、クラスターホストの BMC 認証情報を追加している。BMC 認証情報を追加するには、クラスターで Secret カスタムリソース (CR) を適用するか、Web コンソールにログインして管理対象となるようにベアメタルホストを設定します。

手順

  1. Web コンソールで、電源をオフにするノードをスケジュール対象外としてマークします。以下の手順を実行します。

    1. Nodes に移動し、電源をオフにするノードを選択します。Actions メニューを展開し、Mark as unschedulable を選択します。
    2. Pod デプロイメントを調整するか、またはノードでワークロードをゼロにスケールダウンして、ノード上で実行中の Pod を手動で削除または再配置します。ドレインプロセスが完了するまで待ちます。
    3. Compute → Bare Metal Hosts に移動します。
    4. 電源をオフにするベアメタルホストの Options メニュー を展開し、Power Off を選択します。Immediate power off を選択します。

  2. または、oc を使用して、電源をオフにするホストの BareMetalHost リソースにパッチを適用できます。

    1. 管理対象ベアメタルホストの名前を取得します。以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc get baremetalhosts -n openshift-machine-api -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.provisioning.state}{"\n"}{end}'

      出力例

      Copy to Clipboard Toggle word wrap 
      master-0.example.com  managed
master-1.example.com  managed
master-2.example.com  managed
worker-0.example.com  managed
worker-1.example.com  managed
worker-2.example.com  managed

    2. ノードをスケジューリング対象外としてマークします。

      Copy to Clipboard Toggle word wrap 
      $ oc adm cordon <bare_metal_host>
      1
      1
      <bare_metal_host> は、シャットダウンするホストです (例: worker-2.example.com)。

    3. ノード上のすべての Pod をドレイン (解放) します。

      Copy to Clipboard Toggle word wrap 
      $ oc adm drain <bare_metal_host> --force=true

      レプリケーションコントローラーでサポートされる Pod は、クラスター内の他の利用可能なノードに再スケジュールされます。

    4. ベアメタルホストの電源を安全にオフにします。以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc patch <bare_metal_host> --type json -p '[{"op": "replace", "path": "/spec/online", "value": false}]'

    5. ホストの電源をオンにしたら、ノードをワークロードに対してスケジュール可能な状態にします。以下のコマンドを実行します。

      Copy to Clipboard Toggle word wrap 
      $ oc adm uncordon <bare_metal_host>

第14章 Huge Page の機能およびそれらがアプリケーションによって消費される仕組み

14.1. Huge Page の機能

メモリーは Page と呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 256,000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。そうでない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズは固定されているので、TLB ミスの発生率を減らすには Page サイズを大きくする必要があります。

Huge Page とは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的な Huge Page サイズです。別のアーキテクチャーではサイズは異なります。Huge Page を使用するには、アプリケーションが認識できるようにコードを書き込む必要があります。Transparent Huge Page (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。

OpenShift Container Platform では、Pod のアプリケーションが事前に割り当てられた Huge Page を割り当て、消費することができます。

14.2. Huge Page がアプリケーションによって消費される仕組み

ノードは、Huge Page の容量をレポートできるように Huge Page を事前に割り当てる必要があります。ノードは、単一サイズの Huge Page のみを事前に割り当てることができます。

Huge Page は、リソース名の hugepages-<size> を使用してコンテナーレベルのリソース要件で消費可能です。この場合、サイズは特定のノードでサポートされる整数値を使用した最もコンパクトなバイナリー表記です。たとえば、ノードが 2048KiB ページサイズをサポートする場合、これはスケジュール可能なリソース hugepages-2Mi を公開します。CPU やメモリーとは異なり、Huge Page はオーバーコミットをサポートしません。

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi
1 

        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
1
hugepages のメモリー量は、実際に割り当てる量に指定します。この値は、ページサイズで乗算した hugepages のメモリー量に指定しないでください。たとえば、Huge Page サイズが 2MB と仮定し、アプリケーションに Huge Page でバックアップする RAM 100 MB を使用する場合には、Huge Page は 50 に指定します。OpenShift Container Platform により、計算処理が実行されます。上記の例にあるように、100MB を直接指定できます。

指定されたサイズの Huge Page の割り当て

プラットフォームによっては、複数の Huge Page サイズをサポートするものもあります。特定のサイズの Huge Page を割り当てるには、Huge Page の起動コマンドパラメーターの前に、Huge Page サイズの選択パラメーター hugepagesz=<size> を指定してください。<size> の値は、バイトで指定する必要があります。その際、オプションでスケール接尾辞 [kKmMgG] を指定できます。デフォルトの Huge Page サイズは、default_hugepagesz=<size> の起動パラメーターで定義できます。

Huge page の要件

  • Huge Page 要求は制限と同じでなければなりません。制限が指定されているにもかかわらず、要求が指定されていない場合には、これがデフォルトになります。
  • Huge Page は、Pod のスコープで分割されます。コンテナーの分割は、今後のバージョンで予定されています。
  • Huge Page がサポートする EmptyDir ボリュームは、Pod 要求よりも多くの Huge Page メモリーを消費することはできません。
  • shmget() で SHM_HUGETLB を使用して Huge Page を消費するアプリケーションは、proc/sys/vm/hugetlb_shm_group に一致する補助グループで実行する必要があります。

14.3. Downward API を使用した Huge Page リソースの使用

Downward API を使用して、コンテナーで使用する Huge Page リソースに関する情報を挿入できます。

リソースの割り当ては、環境変数、ボリュームプラグイン、またはその両方として挿入できます。コンテナーで開発および実行するアプリケーションは、指定されたボリューム内の環境変数またはファイルを読み取ることで、利用可能なリソースを判別できます。

手順

  1. 以下の例のような hugepages-volume-pod.yaml ファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
  labels:
    app: hugepages-example
spec:
  containers:
  - securityContext:
      capabilities:
        add: [ "IPC_LOCK" ]
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    - mountPath: /etc/podinfo
      name: podinfo
    resources:
      limits:
        hugepages-1Gi: 2Gi
        memory: "1Gi"
        cpu: "1"
      requests:
        hugepages-1Gi: 2Gi
    env:
    - name: REQUESTS_HUGEPAGES_1GI \
    1 
    
      valueFrom:
        resourceFieldRef:
          containerName: example
          resource: requests.hugepages-1Gi
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
  - name: podinfo
    downwardAPI:
      items:
        - path: "hugepages_1G_request" \
    2 
    
          resourceFieldRef:
            containerName: example
            resource: requests.hugepages-1Gi
            divisor: 1Gi
    1
    requests.hugepages-1Gi からリソースの使用を読み取り、REQUESTS_HUGEPAGES_1GI 環境変数として値を公開するように指定します。
    2
    requests.hugepages-1Gi からリソースの使用を読み取り、値を /etc/podinfo/hugepages_1G_request ファイルとして公開します。

  2. hugepages-volume-pod.yaml ファイルから Pod を作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f hugepages-volume-pod.yaml

検証

  1. REQUESTS_HUGEPAGES_1GI 環境 変数の値を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
     -- env | grep REQUESTS_HUGEPAGES_1GI

    出力例

    Copy to Clipboard Toggle word wrap 
    REQUESTS_HUGEPAGES_1GI=2147483648

  2. /etc/podinfo/hugepages_1G_request ファイルの値を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
     -- cat /etc/podinfo/hugepages_1G_request

    出力例

    Copy to Clipboard Toggle word wrap 
    2

関連情報

14.4. 起動時の Huge Page 設定

ノードは、OpenShift Container Platform クラスターで使用される Huge Page を事前に割り当てる必要があります。Huge Page を予約する方法は、ブート時とランタイム時に実行する 2 つの方法があります。ブート時の予約は、メモリーが大幅に断片化されていないために成功する可能性が高くなります。Node Tuning Operator は、現時点で特定のノードでの Huge Page のブート時の割り当てをサポートします。

手順

ノードの再起動を最小限にするには、以下の手順の順序に従う必要があります。

  1. ラベルを使用して同じ Huge Page 設定を必要とするすべてのノードにラベルを付けます。

    Copy to Clipboard Toggle word wrap 
    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=

  2. 以下の内容でファイルを作成し、これに hugepages-tuned-boottime.yaml という名前を付けます。

    Copy to Clipboard Toggle word wrap 
    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: hugepages
    1 
    
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
    2 
    
  - data: |
      [main]
      summary=Boot time configuration for hugepages
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
    3 
    
    name: openshift-node-hugepages

  recommend:
  - machineConfigLabels:
    4 
    
      machineconfiguration.openshift.io/role: "worker-hp"
    priority: 30
    profile: openshift-node-hugepages
    1
    チューニングされたリソースの name を hugepages に設定します。
    2
    Huge Page を割り当てる profile セクションを設定します。
    3
    一部のプラットフォームではさまざまなサイズの Huge Page をサポートするため、パラメーターの順序に注意してください。
    4
    マシン設定プールベースのマッチングを有効にします。

  3. チューニングされた hugepages オブジェクトの作成

    Copy to Clipboard Toggle word wrap 
    $ oc create -f hugepages-tuned-boottime.yaml

  4. 以下の内容でファイルを作成し、これに hugepages-mcp.yaml という名前を付けます。

    Copy to Clipboard Toggle word wrap 
    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-hp
  labels:
    worker-hp: ""
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-hp: ""

  5. マシン設定プールを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f hugepages-mcp.yaml

断片化されていないメモリーが十分にある場合、worker-hp マシン設定プールのすべてのノードには 50 2Mi の Huge Page が割り当てられているはずです。

Copy to Clipboard Toggle word wrap 
$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
注記

TuneD ブートローダープラグインは、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーノードのみサポートします。

14.5. Transparent Huge Page (THP) の無効化

Transparent Huge Page (THP) は、Huge Page を作成し、管理し、使用するためのほとんどの要素を自動化しようとします。THP は Huge Page を自動的に管理するため、すべてのタイプのワークロードに対して常に最適に処理される訳ではありません。THP は、多くのアプリケーションが独自の Huge Page を処理するため、パフォーマンス低下につながる可能性があります。したがって、THP を無効にすることを検討してください。以下の手順では、Node Tuning Operator (NTO) を使用して THP を無効にする方法を説明します。

手順

  1. 以下の内容でファイルを作成し、thp-disable-tuned.yaml という名前を付けます。

    Copy to Clipboard Toggle word wrap 
    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: thp-workers-profile
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom tuned profile for OpenShift to turn off THP on worker nodes
      include=openshift-node

      [vm]
      transparent_hugepages=never
    name: openshift-thp-never-worker

  recommend:
  - match:
    - label: node-role.kubernetes.io/worker
    priority: 25
    profile: openshift-thp-never-worker

  2. Tuned オブジェクトを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create -f thp-disable-tuned.yaml

  3. アクティブなプロファイルのリストを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get profile -n openshift-cluster-node-tuning-operator

検証

  • ノードのいずれかにログインし、通常の THP チェックを実行して、ノードがプロファイルを正常に適用したかどうかを確認します。

    Copy to Clipboard Toggle word wrap 
    $ cat /sys/kernel/mm/transparent_hugepage/enabled

    出力例

    Copy to Clipboard Toggle word wrap 
    always madvise [never]

第15章 クラスターノードの低レイテンシーチューニングについて

エッジコンピューティングは、レイテンシーと輻輳の問題を軽減し、通信アプリケーションおよび 5G ネットワークアプリケーションのパフォーマンスを向上させる上で重要な役割を果たします。可能な限りレイテンシーを抑えたネットワークアーキテクチャーを維持することが、5G のネットワークパフォーマンス要件を満たすための鍵となります。平均レイテンシーが 50 ms の 4G テクノロジーと比較して、5G ではレイテンシーを 1 ms 以下に抑えることを目指しています。このレイテンシーの削減により、ワイヤレススループットが 10 倍向上します。

15.1. 低レイテンシーについて

Telco 領域にデプロイされるアプリケーションの多くは、ゼロパケットロスに耐えられる低レイテンシーを必要とします。パケットロスをゼロに調整すると、ネットワークのパフォーマンス低下させる固有の問題を軽減することができます。詳細は、Tuning for Zero Packet Loss in Red Hat OpenStack Platform (RHOSP) を参照してください。

エッジコンピューティングの取り組みは、レイテンシーの削減にも役立ちます。クラウドの端にあり、ユーザーに近いと考えてください。これにより、ユーザーと離れた場所にあるデータセンター間の距離が大幅に削減されるため、アプリケーションの応答時間とパフォーマンスのレイテンシーが短縮されます。

管理者は、すべてのデプロイメントを可能な限り低い管理コストで実行できるように、多数のエッジサイトおよびローカルサービスを一元管理できるようにする必要があります。また、リアルタイムの低レイテンシーおよび高パフォーマンスを実現するために、クラスターの特定のノードをデプロイし、設定するための簡単な方法も必要になります。低レイテンシーノードは、Cloud-native Network Functions (CNF) や Data Plane Development Kit (DPDK) などのアプリケーションに役立ちます。

現時点で、OpenShift Container Platform はリアルタイムの実行および低レイテンシーを実現するために OpenShift Container Platform クラスターでソフトウェアを調整するメカニズムを提供します (約 20 マイクロ秒未満の応答時間)。これには、カーネルおよび OpenShift Container Platform の設定値のチューニング、カーネルのインストール、およびマシンの再設定が含まれます。ただし、この方法では 4 つの異なる Operator を設定し、手動で実行する場合に複雑であり、間違いが生じる可能性がある多くの設定を行う必要があります。

OpenShift Container Platform は、ノードチューニング Operator を使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現します。クラスター管理者は、このパフォーマンスプロファイル設定を使用することにより、より信頼性の高い方法でこれらの変更をより容易に実行することができます。管理者は、カーネルを kernel-rt に更新するかどうかを指定し、Pod の infra コンテナーなどのクラスターおよびオペレーティングシステムのハウスキーピング向けに CPU を予約して、アプリケーションコンテナーがワークロードを実行するように CPU を分離することができます。

OpenShift Container Platform は、さまざまな業界環境の要求を満たすように PerformanceProfile を調整できる Node Tuning Operator のワークロードヒントもサポートします。ワークロードのヒントは、highPowerConsumption (消費電力が増加する代わりにレイテンシーを非常に低く抑える) と realTime (最適なレイテンシーを優先) で利用できます。これらのヒントの true/false 設定の組み合わせを使用して、アプリケーション固有のワークロードプロファイルと要件を処理できます。

ワークロードのヒントは、業界セクターの設定に対するパフォーマンスの微調整を簡素化します。“1 つのサイズですべてに対応する” アプローチの代わりに、ワークロードのヒントは、以下を優先するなどの使用パターンに対応できます。

  • 低レイテンシー
  • リアルタイム機能
  • 電力の効率的な使用

理想は、上記のすべての項目を優先することです。しかし、これらの項目の一部は、他の項目を犠牲にして実現されます。Node Tuning Operator は、ワークロードの期待を認識し、ワークロードの要求をより適切に満たすことができるようになりました。クラスター管理者は、ワークロードがどのユースケースに分類されるかを指定できるようになりました。Node Tuning Operator は、PerformanceProfile を使用して、ワークロードのパフォーマンス設定を微調整します。

アプリケーションが動作している環境は、その動作に影響を与えます。厳密なレイテンシー要件のない一般的なデータセンターの場合、一部の高性能ワークロード Pod の CPU パーティショニングを可能にする最小限のデフォルトチューニングのみが必要です。レイテンシーが優先されるデータセンターやワークロードの場合でも、消費電力を最適化するための対策が講じられています。最も複雑なケースは、製造機械やソフトウェア無線などのレイテンシーの影響を受けやすい機器に近いクラスターです。この最後のクラスのデプロイメントは、多くの場合、ファーエッジと呼ばれます。ファーエッジデプロイメントの場合、超低レイテンシーが最優先事項であり、電力管理を犠牲にして実現されます。

15.2. 低レイテンシーおよびリアルタイムアプリケーションを実現するハイパースレッディングについて

ハイパースレッディングは、物理 CPU プロセッサーコアを 2 つの論理コアとして機能させ、2 つの独立したスレッドを同時に実行できるようにする Intel プロセッサーテクノロジーです。ハイパースレッディングにより、並列処理が有効な特定のワークロードタイプでシステムスループットが向上します。デフォルトの OpenShift Container Platform 設定では、ハイパースレッディングが有効になっていることが想定されています。

通信アプリケーションの場合、レイテンシーを可能な限り最小限に抑えるようにアプリケーションインフラストラクチャーを設計することが重要です。ハイパースレッディングは、パフォーマンス時間を低下させ、低レイテンシーを必要とする計算集約型ワークロードのスループットに悪影響を及ぼす可能性があります。ハイパースレッディングを無効にすると、予測可能なパフォーマンスが確保され、これらのワークロードの処理時間が短縮されます。

注記

ハイパースレッディングの実装と設定は、OpenShift Container Platform を実行しているハードウェアによって異なります。当該ハードウェアに固有のハイパースレッディング実装の詳細は、関連するホストハードウェアチューニング情報を参照してください。ハイパースレッディングを無効にすると、クラスターのコアあたりのコストが増加する可能性があります。

関連情報

第16章 パフォーマンスプロファイルによる低レイテンシーを実現するためのノードのチューニング

ノードをチューニングして低レイテンシーを実現するには、クラスターパフォーマンスプロファイルを使用します。インフラストラクチャーおよびアプリケーションコンテナーの CPU を制限したり、huge page やハイパースレッディングを設定したり、レイテンシーの影響を受けやすいプロセスの CPU パーティションを設定したりすることができます。

16.1. パフォーマンスプロファイルの作成

Performance Profile Creator (PPC) ツールを使用して、クラスターパフォーマンスプロファイルを作成できます。PPC は Node Tuning Operator の機能です。

PPC は、クラスターに関する情報とユーザー指定の設定を組み合わせて、ハードウェア、トポロジー、ユースケースに適したパフォーマンスプロファイルを生成します。

注記

パフォーマンスプロファイルは、クラスターが基盤となるハードウェアリソースに直接アクセスできるベアメタル環境にのみ適用されます。シングルノード OpenShift とマルチノードクラスターの両方に対してパフォーマンスプロファイルを設定できます。

以下は、クラスターでパフォーマンスプロファイルを作成して適用するための大まかなワークフローです。

  • パフォーマンス設定の対象となるノードのマシン設定プール (MCP) を作成します。シングルノードの OpenShift クラスターでは、クラスター内にノードが 1 つしかないため、master MCP を使用する必要があります。
  • must-gather コマンドを使用してクラスターに関する情報を収集します。

  • 次のいずれかの方法で PPC ツールを使用してパフォーマンスプロファイルを作成します。

    • Podman を使用して PPC ツールを実行します。
    • ラッパースクリプトを使用して PPC ツールを実行します。
  • ユースケースに合わせてパフォーマンスプロファイルを設定し、そのパフォーマンスプロファイルをクラスターに適用します。

16.1.1. Performance Profile Creator の概要

Performance Profile Creator (PPC) は、Node Tuning Operator とともに提供されるコマンドラインツールで、クラスターのパフォーマンスプロファイルを作成するのに役立ちます。

最初に、PPC ツールを使用して must-gather データを処理し、次の情報を含むクラスターの主要なパフォーマンス設定を表示できます。

  • 割り当てられた CPU ID でパーティショニングされた NUMA セル
  • ハイパースレッディングノード設定

この情報を使用して、パフォーマンスプロファイルを設定することができます。

PPC の実行

PPC ツールにパフォーマンス設定引数を指定して、ハードウェア、トポロジー、およびユースケースに適した提案されたパフォーマンスプロファイルを生成します。

次のいずれかの方法で PPC を実行できます。

  • Podman を使用して PPC を実行する
  • ラッパースクリプトを使用して PPC を実行する
注記

ラッパースクリプトを使用すると、より細かい Podman タスクの一部が実行可能なスクリプトに抽象化されます。たとえば、ラッパースクリプトは、必要なコンテナーイメージをプルして実行したり、コンテナーにディレクトリーをマウントしたり、Podman を介してコンテナーに直接パラメーターを提供したりといったタスクを処理します。どちらの方法でも同じ結果が得られます。

16.1.2. パフォーマンスチューニングの対象となるノードにマシン設定プールを作成する

マルチノードクラスターの場合、マシン設定プール (MCP) を定義して、パフォーマンスプロファイルで設定するターゲットノードを識別できます。

シングルノードの OpenShift クラスターでは、クラスター内にノードが 1 つしかないため、master MCP を使用する必要があります。シングルノードの OpenShift クラスター用に別の MCP を作成する必要はありません。

前提条件

  • cluster-admin ロールへのアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、設定用のターゲットノードにラベルを付けます。

    Copy to Clipboard Toggle word wrap 
    $ oc label node <node_name> node-role.kubernetes.io/worker-cnf=""
    1
    1
    <node_name> をノードの名前に置き換えます。この例では、worker-cnf ラベルを適用します。

  2. ターゲットノードを含む MachineConfigPool リソースを作成します。

    1. MachineConfigPool リソースを定義する YAML ファイルを作成します。

      mcp-worker-cnf.yaml ファイルの例

      Copy to Clipboard Toggle word wrap 
      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-cnf
      1 
      
  labels:
    machineconfiguration.openshift.io/role: worker-cnf
      2 
      
spec:
  machineConfigSelector:
    matchExpressions:
      - {
           key: machineconfiguration.openshift.io/role,
           operator: In,
           values: [worker, worker-cnf],
        }
  paused: false
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-cnf: ""
      3

      1
      MachineConfigPool リソースの名前を指定します。
      2
      マシン設定プールの一意のラベルを指定します。
      3
      定義したターゲットラベルを持つノードを指定します。

    2. 次のコマンドを実行して、MachineConfigPool リソースを適用します。

      Copy to Clipboard Toggle word wrap 
      $ oc apply -f mcp-worker-cnf.yaml

      出力例

      Copy to Clipboard Toggle word wrap 
      machineconfigpool.machineconfiguration.openshift.io/worker-cnf created

検証

  • 次のコマンドを実行して、クラスター内のマシン設定プールを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-58433c7c3c1b4ed5ffef95234d451490       True      False      False      3              3                   3                     0                      6h46m
worker       rendered-worker-168f52b168f151e4f853259729b6azc4       True      False      False      2              2                   2                     0                      6h46m
worker-cnf   rendered-worker-cnf-168f52b168f151e4f853259729b6azc4   True      False      False      1              1                   1                     0                      73s

16.1.3. PPC 用のクラスターに関するデータを収集する

Performance Profile Creator (PPC) ツールには must-gather データが必要です。クラスター管理者は、must-gather コマンドを実行し、クラスターに関する情報を取得します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • パフォーマンスプロファイルを使用して設定するターゲット MCP を特定している。

手順

  1. must-gather データを保存するディレクトリーに移動します。

  2. 次のコマンドを実行してクラスター情報を収集します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm must-gather

    このコマンドは、must-gather.local.1971646453781853027 のような命名形式で、ローカルディレクトリーに must-gather データを含むフォルダーを作成します。

  3. オプション: must-gather ディレクトリーから圧縮ファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    $ tar cvaf must-gather.tar.gz <must_gather_folder>
    1
    1
    must-gather データフォルダーの名前に置き換えます。
    注記

    Performance Profile Creator ラッパースクリプトを実行している場合は、出力を圧縮する必要があります。

関連情報

16.1.4. Podman を使用した Performance Profile Creator の実行

クラスター管理者は、Podman と Performance Profile Creator (PPC) を使用してパフォーマンスプロファイルを作成できます。

PPC 引数の詳細は、Performance Profile Creator の引数 のセクションを参照してください。

重要

PPC は、クラスターからの must-gather データを使用して、パフォーマンスプロファイルを作成します。パフォーマンス設定の対象となるノードのラベルを変更するなど、クラスターに変更を加えた場合は、PPC を再度実行する前に、must-gather データを再作成する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • ベアメタルハードウェアにクラスターがインストールされている。
  • podman と OpenShift CLI (oc) がインストールされている。
  • Node Tuning Operator イメージへのアクセスがある。
  • 設定のターゲットノードを含むマシン設定プールが特定されている。
  • クラスターの must-gather データにアクセスできる。

手順

  1. 次のコマンドを実行して、マシン設定プールを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-58433c8c3c0b4ed5feef95434d455490       True      False      False      3              3                   3                     0                      8h
worker       rendered-worker-668f56a164f151e4a853229729b6adc4       True      False      False      2              2                   2                     0                      8h
worker-cnf   rendered-worker-cnf-668f56a164f151e4a853229729b6adc4   True      False      False      1              1                   1                     0                      79m

  2. 次のコマンドを実行して、Podman を使用して registry.redhat.io に認証します。

    Copy to Clipboard Toggle word wrap 
    $ podman login registry.redhat.io
     Copy to Clipboard Toggle word wrap 
    Username: <user_name>
Password: <password>

  3. オプション: 次のコマンドを実行して、PPC ツールのヘルプを表示します。

    Copy to Clipboard Toggle word wrap 
    $ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.18 -h

    出力例

    Copy to Clipboard Toggle word wrap 
    A tool that automates creation of Performance Profiles

Usage:
  performance-profile-creator [flags]

Flags:
      --disable-ht                        Disable Hyperthreading
  -h, --help                              help for performance-profile-creator
      --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
      --mcp-name string                   MCP name corresponding to the target machines (required)
      --must-gather-dir-path string       Must gather directory path (default "must-gather")
      --offlined-cpu-count int            Number of offlined CPUs
      --per-pod-power-management          Enable Per Pod Power Management
      --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
      --profile-name string               Name of the performance profile to be created (default "performance")
      --reserved-cpu-count int            Number of reserved CPUs (required)
      --rt-kernel                         Enable Real Time Kernel (required)
      --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
      --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
      --user-level-networking             Run with User level Networking(DPDK) enabled

  4. クラスターに関する情報を表示するには、次のコマンドを実行して、log 引数を指定した PPC ツールを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.18 --info log --must-gather-dir-path /must-gather
    • --entrypoint performance-profile-creator は、podman への新しいエントリーポイントとして、パフォーマンスプロファイルクリエーターを定義します。

    • -v <path_to_must_gather> は、次のいずれかのコンポーネントへのパスを指定します。

      • must-gather データが含まれるディレクトリー。
      • must-gather の展開された .tar ファイルを含む既存のディレクトリー

    • --info log は、出力形式の値を指定します。

      出力例

      Copy to Clipboard Toggle word wrap 
      level=info msg="Cluster info:"
level=info msg="MCP 'master' nodes:"
level=info msg=---
level=info msg="MCP 'worker' nodes:"
level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)"
level=info msg="NUMA cell 0 : [0 1 2 3]"
level=info msg="CPU(s): 4"
level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)"
level=info msg="NUMA cell 0 : [0 1 2 3]"
level=info msg="CPU(s): 4"
level=info msg=---
level=info msg="MCP 'worker-cnf' nodes:"
level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)"
level=info msg="NUMA cell 0 : [0 1 2 3]"
level=info msg="CPU(s): 4"
level=info msg=---

  5. 次のコマンドを実行して、パフォーマンスプロファイルを作成します。この例では、サンプルの PPC 引数と値を使用します。

    Copy to Clipboard Toggle word wrap 
    $ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.18 --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml

    • -v <path_to_must_gather> は、次のいずれかのコンポーネントへのパスを指定します。

      • must-gather データが含まれるディレクトリー。
      • must-gather の展開された .tar ファイルを含むディレクトリー。
    • --mcp-name=worker-cnf は、worker-cnf マシン設定プールを指定します。
    • --reserved-cpu-count=1 は、予約済みの CPU を 1 つ指定します。
    • --rt-kernel=true は、リアルタイムカーネルを有効にします。
    • --split-reserved-cpus-across-numa=false は、NUMA ノード間での予約済み CPU の分割を無効にします。
    • --power-consumption-mode=ultra-low-latency は、消費電力の増加を犠牲にして、レイテンシーを最小限に抑えることを指定します。

    • --offlined-cpu-count=1 は、オフラインの CPU を 1 つ指定します。

      注記

      この例の mcp-name 引数は、コマンド oc get mcp の出力に基づいて worker-cnf に設定されます。シングルノード OpenShift の場合は、--mcp-name=master を使用します。

      出力例

      Copy to Clipboard Toggle word wrap 
      level=info msg="Nodes targeted by worker-cnf MCP are: [worker-2]"
level=info msg="NUMA cell(s): 1"
level=info msg="NUMA cell 0 : [0 1 2 3]"
level=info msg="CPU(s): 4"
level=info msg="1 reserved CPUs allocated: 0 "
level=info msg="2 isolated CPUs allocated: 2-3"
level=info msg="Additional Kernel Args based on configuration: []"

  6. 次のコマンドを実行して、作成された YAML ファイルを確認します。

    Copy to Clipboard Toggle word wrap 
    $ cat my-performance-profile.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    ---
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: 2-3
    offlined: "1"
    reserved: "0"
  machineConfigPoolSelector:
    machineconfiguration.openshift.io/role: worker-cnf
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numa:
    topologyPolicy: restricted
  realTimeKernel:
    enabled: true
  workloadHints:
    highPowerConsumption: true
    perPodPowerManagement: false
    realTime: true

  7. 生成されたプロファイルを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc apply -f my-performance-profile.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    performanceprofile.performance.openshift.io/performance created

16.1.5. Performance Profile Creator ラッパースクリプトの実行

ラッパースクリプトは、Performance Profile Creator (PPC) ツールを使用してパフォーマンスプロファイルを作成するプロセスを簡素化します。このスクリプトは、必要なコンテナーイメージのプルと実行、コンテナーへのディレクトリーのマウント、Podman を介してコンテナーに直接パラメーターを提供するなどのタスクを処理します。

Performance Profile Creator の引数の詳細は、Performance Profile Creator の引数 のセクションを参照してください。

重要

PPC は、クラスターからの must-gather データを使用して、パフォーマンスプロファイルを作成します。パフォーマンス設定の対象となるノードのラベルを変更するなど、クラスターに変更を加えた場合は、PPC を再度実行する前に、must-gather データを再作成する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • ベアメタルハードウェアにクラスターがインストールされている。
  • podman と OpenShift CLI (oc) がインストールされている。
  • Node Tuning Operator イメージへのアクセスがある。
  • 設定のターゲットノードを含むマシン設定プールが特定されている。
  • must-gather tarball にアクセスできる。

手順

  1. ローカルマシンにファイル (例: run-perf-profile-creator.sh) を作成します。

    Copy to Clipboard Toggle word wrap 
    $ vi run-perf-profile-creator.sh

  2. ファイルに以下のコードを貼り付けます。

    Copy to Clipboard Toggle word wrap 
    #!/bin/bash

readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman}
readonly CURRENT_SCRIPT=$(basename "$0")
readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator"
readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists"
readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull"
readonly MUST_GATHER_VOL="/must-gather"

NTO_IMG="registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.18"
MG_TARBALL=""
DATA_DIR=""

usage() {
  print "Wrapper usage:"
  print "  ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]"
  print ""
  print "Options:"
  print "   -h                 help for ${CURRENT_SCRIPT}"
  print "   -p                 Node Tuning Operator image"
  print "   -t                 path to a must-gather tarball"

  ${IMG_EXISTS_CMD} "${NTO_IMG}" && ${CMD} "${NTO_IMG}" -h
}

function cleanup {
  [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}"
}
trap cleanup EXIT

exit_error() {
  print "error: $*"
  usage
  exit 1
}

print() {
  echo  "$*" >&2
}

check_requirements() {
  ${IMG_EXISTS_CMD} "${NTO_IMG}" || ${IMG_PULL_CMD} "${NTO_IMG}" || \
      exit_error "Node Tuning Operator image not found"

  [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory"
  [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found"

  DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory"
  tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball"
  chmod a+rx "${DATA_DIR}"

  return 0
}

main() {
  while getopts ':hp:t:' OPT; do
    case "${OPT}" in
      h)
        usage
        exit 0
        ;;
      p)
        NTO_IMG="${OPTARG}"
        ;;
      t)
        MG_TARBALL="${OPTARG}"
        ;;
      ?)
        exit_error "invalid argument: ${OPTARG}"
        ;;
    esac
  done
  shift $((OPTIND - 1))

  check_requirements || exit 1

  ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${NTO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}"
  echo "" 1>&2
}

main "$@"

  3. このスクリプトの実行権限を全員に追加します。

    Copy to Clipboard Toggle word wrap 
    $ chmod a+x run-perf-profile-creator.sh

  4. 次のコマンドを実行して、Podman を使用して registry.redhat.io に認証します。

    Copy to Clipboard Toggle word wrap 
    $ podman login registry.redhat.io
     Copy to Clipboard Toggle word wrap 
    Username: <user_name>
Password: <password>

  5. オプション: 次のコマンドを実行して、PPC ツールのヘルプを表示します。

    Copy to Clipboard Toggle word wrap 
    $ ./run-perf-profile-creator.sh -h

    出力例

    Copy to Clipboard Toggle word wrap 
    Wrapper usage:
  run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags]

Options:
   -h                 help for run-perf-profile-creator.sh
   -p                 Node Tuning Operator image
   -t                 path to a must-gather tarball
A tool that automates creation of Performance Profiles

Usage:
  performance-profile-creator [flags]

Flags:
      --disable-ht                        Disable Hyperthreading
  -h, --help                              help for performance-profile-creator
      --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
      --mcp-name string                   MCP name corresponding to the target machines (required)
      --must-gather-dir-path string       Must gather directory path (default "must-gather")
      --offlined-cpu-count int            Number of offlined CPUs
      --per-pod-power-management          Enable Per Pod Power Management
      --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
      --profile-name string               Name of the performance profile to be created (default "performance")
      --reserved-cpu-count int            Number of reserved CPUs (required)
      --rt-kernel                         Enable Real Time Kernel (required)
      --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
      --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
      --user-level-networking             Run with User level Networking(DPDK) enabled
      --enable-hardware-tuning            Enable setting maximum CPU frequencies

    注記

    オプションで、-p オプションを使用して Node Tuning Operator イメージのパスを設定できます。パスを設定しない場合、ラッパースクリプトはデフォルトのイメージ (registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.18) を使用します。

  6. クラスターに関する情報を表示するには、次のコマンドを実行して、log 引数を指定した PPC ツールを実行します。

    Copy to Clipboard Toggle word wrap 
    $ ./run-perf-profile-creator.sh -t /<path_to_must_gather_dir>/must-gather.tar.gz -- --info=log

    • -t /<path_to_must_gather_dir>/must-gather.tar.gz は、must-gather tarball を含むディレクトリーへのパスを指定します。これはラッパースクリプトに必要な引数です。

      出力例

      Copy to Clipboard Toggle word wrap 
      level=info msg="Cluster info:"
level=info msg="MCP 'master' nodes:"
level=info msg=---
level=info msg="MCP 'worker' nodes:"
level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)"
level=info msg="NUMA cell 0 : [0 1 2 3]"
level=info msg="CPU(s): 4"
level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)"
level=info msg="NUMA cell 0 : [0 1 2 3]"
level=info msg="CPU(s): 4"
level=info msg=---
level=info msg="MCP 'worker-cnf' nodes:"
level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)"
level=info msg="NUMA cell 0 : [0 1 2 3]"
level=info msg="CPU(s): 4"
level=info msg=---

  7. 次のコマンドを実行して、パフォーマンスプロファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    $ ./run-perf-profile-creator.sh -t /path-to-must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml

    この例では、サンプルの PPC 引数と値を使用します。

    • --mcp-name=worker-cnf は、worker-cnf マシン設定プールを指定します。
    • --reserved-cpu-count=1 は、予約済みの CPU を 1 つ指定します。
    • --rt-kernel=true は、リアルタイムカーネルを有効にします。
    • --split-reserved-cpus-across-numa=false は、NUMA ノード間での予約済み CPU の分割を無効にします。
    • --power-consumption-mode=ultra-low-latency は、消費電力の増加を犠牲にして、レイテンシーを最小限に抑えることを指定します。

    • --offlined-cpu-count=1 は、オフラインの CPU を 1 つ指定します。

      注記

      この例の mcp-name 引数は、コマンド oc get mcp の出力に基づいて worker-cnf に設定されます。シングルノード OpenShift の場合は、--mcp-name=master を使用します。

  8. 次のコマンドを実行して、作成された YAML ファイルを確認します。

    Copy to Clipboard Toggle word wrap 
    $ cat my-performance-profile.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    ---
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: 2-3
    offlined: "1"
    reserved: "0"
  machineConfigPoolSelector:
    machineconfiguration.openshift.io/role: worker-cnf
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
  numa:
    topologyPolicy: restricted
  realTimeKernel:
    enabled: true
  workloadHints:
    highPowerConsumption: true
    perPodPowerManagement: false
    realTime: true

  9. 生成されたプロファイルを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc apply -f my-performance-profile.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    performanceprofile.performance.openshift.io/performance created

16.1.6. Performance Profile Creator の引数

表16.1 Performance Profile Creator に必要な引数
引数説明

mcp-name

ターゲットマシンに対応する worker-cnf などの MCP の名前。

must-gather-dir-path

must gather ディレクトリーのパス。

この引数は、Podman を使用して PPC ツールを実行する場合にのみ必要です。ラッパースクリプトで PPC を使用する場合は、この引数を使用しないでください。代わりに、ラッパースクリプトの -t オプションを使用して、must-gather tarball へのディレクトリーパスを指定します。

reserved-cpu-count

予約された CPU の数。ゼロより大きい自然数を使用してください。

rt-kernel

リアルタイムカーネルを有効にします。

使用できる値は true または false です。

表16.2 オプションの Performance Profile Creator の引数
引数説明

disable-ht

ハイパースレッディングを無効にします。

使用できる値は true または false です。

デフォルト: false。

警告

この引数が true に設定されている場合は、BIOS でハイパースレッディングを無効にしないでください。ハイパースレッディングの無効化は、カーネルコマンドライン引数で実行できます。

enable-hardware-tuning

最大 CPU 周波数の設定を有効にします。

この機能を有効にするには、次の両方のフィールドで、分離された予約済み CPU 上で実行されるアプリケーションの最大周波数を設定します。

  • spec.hardwareTuning.isolatedCpuFreq
  • spec.hardwareTuning.reservedCpuFreq

これは高度な機能です。ハードウェアチューニングを設定すると、生成された PerformanceProfile には、周波数設定の方法に関する警告とガイダンスが含まれます。

info

クラスター情報を取得します。この引数には、must-gather-dir-path 引数も必要です。他の引数が設定されている場合は無視されます。

以下の値を使用できます。

  • log
  • JSON

デフォルト: log。

offlined-cpu-count

オフラインの CPU の数。

注記

ゼロより大きい自然数を使用してください。十分な数の論理プロセッサーがオフラインになっていない場合、エラーメッセージがログに記録されます。メッセージは次のとおりです。

Copy to Clipboard Toggle word wrap 
Error: failed to compute the reserved and isolated CPUs: please ensure that reserved-cpu-count plus offlined-cpu-count should be in the range [0,1]
 Copy to Clipboard Toggle word wrap 
Error: failed to compute the reserved and isolated CPUs: please specify the offlined CPU count in the range [0,1]

power-consumption-mode

電力消費モード。

以下の値を使用できます。

  • default: CPU パーティショニングのみで達成されるパフォーマンス。
  • low-latency: レイテンシーを改善するための強化された対策。
  • ultra-low-latency: 電力管理を犠牲にして、最適な遅延を優先します。

デフォルト: default。

per-pod-power-management

Pod ごとの電源管理を有効にします。電力消費モードとして ultra-low-latency を設定している場合、この引数は使用できません。

使用できる値は true または false です。

デフォルト: false。

profile-name

作成するパフォーマンスプロファイルの名前。

デフォルト: performance。

split-reserved-cpus-across-numa

NUMA ノード全体で予約された CPU を分割します。

使用できる値は true または false です。

デフォルト: false。

topology-manager-policy

作成するパフォーマンスプロファイルの kubelet Topology Manager ポリシー。

以下の値を使用できます。

  • single-numa-node
  • best-effort
  • restricted

デフォルト: restricted。

user-level-networking

ユーザーレベルのネットワーク (DPDK) を有効にして実行します。

使用できる値は true または false です。

デフォルト: false。

16.1.7. リファレンスパフォーマンスプロファイル

次のリファレンスパフォーマンスプロファイルをベースに、独自のカスタムプロファイルを作成してください。

16.1.7.1. OpenStack で OVS-DPDK を使用するクラスター用のパフォーマンスプロファイルテンプレート

Red Hat OpenStack Platform (RHOSP) で Open vSwitch と Data Plane Development Kit (OVS-DPDK) を使用するクラスターでマシンのパフォーマンスを最大化するには、パフォーマンスプロファイルを使用できます。

次のパフォーマンスプロファイルテンプレートを使用して、デプロイメント用のプロファイルを作成できます。

OVS-DPDK を使用するクラスター用のパフォーマンスプロファイルテンプレート

Copy to Clipboard Toggle word wrap 
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: cnf-performanceprofile
spec:
  additionalKernelArgs:
    - nmi_watchdog=0
    - audit=0
    - mce=off
    - processor.max_cstate=1
    - idle=poll
    - intel_idle.max_cstate=0
    - default_hugepagesz=1GB
    - hugepagesz=1G
    - intel_iommu=on
  cpu:
    isolated: <CPU_ISOLATED>
    reserved: <CPU_RESERVED>
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      - count: <HUGEPAGES_COUNT>
        node: 0
        size: 1G
  nodeSelector:
    node-role.kubernetes.io/worker: ''
  globallyDisableIrqLoadBalancing: true
  realTimeKernel:
    enabled: false

CPU_ISOLATED キー、CPU_RESERVED キー、および HUGEPAGES_COUNT キーの設定に適した値を入力します。

16.1.7.2. 通信事業者 RAN DU リファレンス設計のパフォーマンスプロファイル

次のパフォーマンスプロファイルは、通信事業者の RAN DU ワークロードをホストするコモディティーハードウェア上の OpenShift Container Platform クラスターのパフォーマンス設定を指定するものです。

通信事業者 RAN DU リファレンス設計のパフォーマンスプロファイル

Copy to Clipboard Toggle word wrap 
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ''
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

16.1.7.3. 通信事業者コアリファレンス設計パフォーマンスプロファイル

次のパフォーマンスプロファイルは、通信事業者コアワークロードをホストするコモディティーハードウェア上の OpenShift Container Platform クラスターのパフォーマンス設定をノードレベルで指定します。

通信事業者コアリファレンス設計パフォーマンスプロファイル

Copy to Clipboard Toggle word wrap 
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ''
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

16.2. サポートされているパフォーマンスプロファイルの API バージョン

Node Tuning Operator は、パフォーマンスプロファイル apiVersion フィールドの v2、v1、および v1alpha1 をサポートします。v1 および v1alpha1 API は同一です。v2 API には、デフォルト値の false が設定されたオプションのブール値フィールド globallyDisableIrqLoadBalancing が含まれます。

デバイス割り込み処理を使用するためのパフォーマンスプロファイルのアップグレード

Node Tuning Operator パフォーマンスプロファイルのカスタムリソース定義 (CRD) を v1 または v1alpha1 から v2 にアップグレードする場合、globallyDisableIrqLoadBalancing は true に設定されます。

注記

globallyDisableIrqLoadBalancing は、IRQ ロードバランシングを分離 CPU セットに対して無効にするかどうかを切り替えます。このオプションを true に設定すると、分離 CPU セットの IRQ ロードバランシングが無効になります。オプションを false に設定すると、IRQ をすべての CPU 間でバランスさせることができます。

Node Tuning Operator API の v1alpha1 から v1 へのアップグレード

Node Tuning Operator API バージョンを v1alpha1 から v1 にアップグレードする場合、v1alpha1 パフォーマンスプロファイルは "None" 変換ストラテジーを使用してオンザフライで変換され、API バージョン v1 の Node Tuning Operator に提供されます。

Node Tuning Operator API の v1alpha1 または v1 から v2 へのアップグレード

古い Node Tuning Operator API バージョンからアップグレードする場合、既存の v1 および v1alpha1 パフォーマンスプロファイルは、globallyDisableIrqLoadBalancing フィールドに true の値を挿入する変換 Webhook を使用して変換されます。

16.3. ワークロードヒントを使用したノードの電力消費とリアルタイム処理の設定

手順

  • Performance Profile Creator (PPC) ツールを使用して、環境のハードウェアとトポロジーに適した PerformanceProfile を作成します。次の表は、PPC ツールに関連付けられた power-consumption-mode フラグに設定可能な値と、適用されるワークロードヒントを示しています。
表16.3 電力消費とリアルタイム設定の組み合わせがレイテンシーに与える影響
Performance Profile Creator の設定ヒント環境説明

デフォルト

Copy to Clipboard Toggle word wrap 
workloadHints:
highPowerConsumption: false
realTime: false

レイテンシー要件のない高スループットクラスター

CPU パーティショニングのみで達成されるパフォーマンス。

Low-latency

Copy to Clipboard Toggle word wrap 
workloadHints:
highPowerConsumption: false
realTime: true

地域のデータセンター

エネルギー節約と低レイテンシーの両方が望ましい: 電力管理、レイテンシー、スループットの間の妥協。

Ultra-low-latency

Copy to Clipboard Toggle word wrap 
workloadHints:
highPowerConsumption: true
realTime: true

ファーエッジクラスター、レイテンシークリティカルなワークロード

消費電力の増加を犠牲にして、絶対的な最小のレイテンシーと最大の決定論のために最適化されています。

Pod ごとの電源管理

Copy to Clipboard Toggle word wrap 
workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: true

重要なワークロードと重要でないワークロード

Pod ごとの電源管理が可能です。

例

次の設定は、通信事業者 RAN DU デプロイメントで一般的に使用されます。

Copy to Clipboard Toggle word wrap 
    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: workload-hints
    spec:
      ...
      workloadHints:
        realTime: true
        highPowerConsumption: false
        perPodPowerManagement: false
1
1
システムの待ち時間に影響を与える可能性のある一部のデバッグおよび監視機能を無効にします。
注記

パフォーマンスプロファイルで realTime ワークロードヒントフラグが true に設定されている場合、ピニングされた CPU を持つすべての Guaranteed Pod に、cpu-quota.crio.io:disable アノテーションを追加してください。このアノテーションは、Pod 内のプロセスのパフォーマンスの低下を防ぐために必要です。realTime ワークロードヒントが明示的に設定されていない場合は、デフォルトで true になります。

電力消費とリアルタイム設定の組み合わせがレイテンシーにどのような影響を与えるかの詳細は、Understanding workload hints を参照してください。

16.4. 高優先度のワークロードと低優先度のワークロードを同じ場所で実行するノードの省電力設定

優先度の高いワークロードのレイテンシーやスループットに影響を与えることなく、優先度の高いワークロードと同じ場所にある優先度の低いワークロードを持つノードの省電力を有効にすることができます。ワークロード自体を変更することなく、省電力が可能です。

重要

この機能は、Intel Ice Lake 以降の世代の Intel CPU でサポートされています。プロセッサーの機能は、優先度の高いワークロードのレイテンシーとスループットに影響を与える可能性があります。

前提条件

  • BIOS の C ステートとオペレーティングシステム制御の P ステートを有効にした。

手順

  1. per-pod-power-management 引数を true に設定して PerformanceProfile を生成します。

    Copy to Clipboard Toggle word wrap 
    $ podman run --entrypoint performance-profile-creator -v \
/must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.18 \
--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 の例

    Copy to Clipboard Toggle word wrap 
    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
     name: performance
spec:
    [.....]
    workloadHints:
        realTime: true
        highPowerConsumption: false
        perPodPowerManagement: true

  2. デフォルトの cpufreq ガバナーを、PerformanceProfile カスタムリソース (CR) で追加のカーネル引数として設定します。

    Copy to Clipboard Toggle word wrap 
    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 周波数を設定します。

    Copy to Clipboard Toggle word wrap 
    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 周波数は、すべてのコアがすべて使用されているときに全コアが実行される周波数です。

関連情報

16.5. インフラストラクチャーおよびアプリケーションコンテナーの CPU の制限

一般的なハウスキーピングおよびワークロードタスクは、レイテンシーの影響を受けやすいプロセスに影響を与える可能性のある方法で CPU を使用します。デフォルトでは、コンテナーランタイムはすべてのオンライン CPU を使用して、すべてのコンテナーを一緒に実行します。これが原因で、コンテキストスイッチおよびレイテンシーが急増する可能性があります。CPU をパーティショニングすることで、ノイズの多いプロセスとレイテンシーの影響を受けやすいプロセスを分離し、干渉を防ぐことができます。以下の表は、Node Tuning Operator を使用してノードを調整した後、CPU でプロセスがどのように実行されるかを示しています。

表16.4 プロセスの CPU 割り当て
プロセスタイプDetails

Burstable および BestEffort Pod

低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。

インフラストラクチャー Pod

低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。

割り込み

予約済み CPU にリダイレクトします (OpenShift Container Platform 4.7 以降ではオプション)

カーネルプロセス

予約済み CPU へのピン

レイテンシーの影響を受けやすいワークロード Pod

分離されたプールからの排他的 CPU の特定のセットへのピン

OS プロセス/systemd サービス

予約済み CPU へのピン

すべての QoS プロセスタイプ (Burstable、BestEffort、または Guaranteed) の Pod に割り当て可能なノード上のコアの容量は、分離されたプールの容量と同じです。予約済みプールの容量は、クラスターおよびオペレーティングシステムのハウスキーピング業務で使用するためにノードの合計コア容量から削除されます。

例 1

ノードは 100 コアの容量を備えています。クラスター管理者は、パフォーマンスプロファイルを使用して、50 コアを分離プールに割り当て、50 コアを予約プールに割り当てます。クラスター管理者は、25 コアを QoS Guaranteed Pod に割り当て、25 コアを BestEffort または Burstable Pod に割り当てます。これは、分離されたプールの容量と一致します。

例 2

ノードは 100 コアの容量を備えています。クラスター管理者は、パフォーマンスプロファイルを使用して、50 コアを分離プールに割り当て、50 コアを予約プールに割り当てます。クラスター管理者は、50 個のコアを QoS Guaranteed Pod に割り当て、1 個のコアを BestEffort または Burstable Pod に割り当てます。これは、分離されたプールの容量を 1 コア超えています。CPU 容量が不十分なため、Pod のスケジューリングが失敗します。

使用する正確なパーティショニングパターンは、ハードウェア、ワークロードの特性、予想されるシステム負荷などの多くの要因によって異なります。いくつかのサンプルユースケースは次のとおりです。

  • レイテンシーの影響を受けやすいワークロードがネットワークインターフェイスコントローラー (NIC) などの特定のハードウェアを使用する場合は、分離されたプール内の CPU が、このハードウェアにできるだけ近いことを確認してください。少なくとも、ワークロードを同じ Non-Uniform Memory Access (NUMA) ノードに配置する必要があります。
  • 予約済みプールは、すべての割り込みを処理するために使用されます。システムネットワークに依存する場合は、すべての着信パケット割り込みを処理するために、十分なサイズの予約プールを割り当てます。4.18 以降のバージョンでは、ワークロードはオプションで機密としてラベル付けできます。

予約済みパーティションと分離パーティションにどの特定の CPU を使用するかを決定するには、詳細な分析と測定が必要です。デバイスやメモリーの NUMA アフィニティーなどの要因が作用しています。選択は、ワークロードアーキテクチャーと特定のユースケースにも依存します。

重要

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

ハウスキーピングタスクとワークロードが相互に干渉しないようにするには、パフォーマンスプロファイルの spec セクションで CPU の 2 つのグループを指定します。

  • isolated - アプリケーションコンテナーワークロードの CPU を指定します。これらの CPU のレイテンシーが一番低くなります。このグループのプロセスには割り込みがないため、DPDK ゼロパケットロスの帯域幅がより高くなります。
  • reserved - クラスターおよびオペレーティングシステムのハウスキーピング業務用の CPU を指定します。reserved グループのスレッドは、ビジーであることが多いです。reserved グループでレイテンシーの影響を受けやすいアプリケーションを実行しないでください。レイテンシーの影響を受けやすいアプリケーションは、isolated グループで実行されます。

手順

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

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

    Copy to Clipboard Toggle word wrap 
    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
    オプション: ノードセレクターを指定してパフォーマンスプロファイルを特定のノードに適用します。

16.6. クラスターのハイパースレッディングの設定

OpenShift Container Platform クラスターのハイパースレッディングを設定するには、パフォーマンスプロファイル内の CPU スレッド数を、予約済みまたは分離された CPU プールに設定されているのと同じコア数に設定します。

注記

パフォーマンスプロファイルを設定してからホストのハイパースレッディング設定を変更する場合は、PerformanceProfile YAML の CPU isolated フィールドと reserved フィールドを新しい設定に合わせて更新してください。

警告

以前に有効にしたホストのハイパースレッディング設定を無効にすると、PerformanceProfile YAML にリストされている CPU コアの ID が正しくなくなる可能性があります。この設定が間違っていると、リスト表示される CPU が見つからなくなるため、ノードが利用できなくなる可能性があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) のインストール。

手順

  1. 設定する必要のあるホストのどの CPU でどのスレッドが実行されているかを確認します。

    クラスターにログインして以下のコマンドを実行し、ホスト CPU で実行されているスレッドを表示できます。

    Copy to Clipboard Toggle word wrap 
    $ lscpu --all --extended

    出力例

    Copy to Clipboard Toggle word wrap 
    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) に設定されているスレッドを表示するには、シェルプロンプトを開いて次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

    出力例

    Copy to Clipboard Toggle word wrap 
    0-4

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

    Copy to Clipboard Toggle word wrap 
    ...
  cpu:
    isolated: 0,4
    reserved: 1-3,5-7
...
    注記

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

重要

ハイパースレッディングは、ほとんどの Intel プロセッサーでデフォルトで有効になっています。ハイパースレッディングが有効な場合、特定のコアで処理されるすべてのスレッドを分離するか、同じコアで処理する必要があります。

ハイパースレッディングが有効な場合、保証されたすべての Pod が、Pod の障害を引き起こす可能性がある "ノイジーネイバー" 状況を回避するために、同時マルチスレッディング (SMT) レベルの倍数を使用する必要があります。詳細は、Static policy options を参照してください。

16.6.1. 低レイテンシーアプリケーション用のハイパースレッディングの無効化

低レイテンシー処理用にクラスターを設定する場合は、クラスターをデプロイする前に、ハイパースレッディングを無効にするかどうかを検討してください。ハイパースレッディングを無効にするには、次の手順を実行します。

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

  2. nosmt を追加のカーネル引数として設定します。以下のパフォーマンスプロファイルの例は、この設定について示しています。

    Copy to Clipboard Toggle word wrap 
    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: example-performanceprofile
spec:
  additionalKernelArgs:
    - nmi_watchdog=0
    - audit=0
    - mce=off
    - processor.max_cstate=1
    - idle=poll
    - intel_idle.max_cstate=0
    - nosmt
  cpu:
    isolated: 2-3
    reserved: 0-1
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      - count: 2
        node: 0
        size: 1G
  nodeSelector:
    node-role.kubernetes.io/performance: ''
  realTimeKernel:
    enabled: true
    注記

    予約および分離された CPU を設定する場合に、Pod 内の infra コンテナーは予約された CPU を使用し、アプリケーションコンテナーは分離された CPU を使用します。

16.7. Guaranteed Pod の分離された CPU のデバイス割り込み処理の管理

Node Tuning Operator は、ホスト CPU を、Pod Infra コンテナーを含むクラスターとオペレーティングシステムのハウスキーピング業務用の予約 CPU と、ワークロードを実行するアプリケーションコンテナー用の分離 CPU に分割して管理することができます。これにより、低レイテンシーのワークロード用の CPU を isolated (分離された CPU) として設定できます。

デバイスの割り込みについては、Guaranteed Pod が実行されている CPU を除き、CPU のオーバーロードを防ぐためにすべての分離された CPU および予約された CPU 間で負荷が分散されます。Guaranteed Pod の CPU は、関連するアノテーションが Pod に設定されている場合にデバイス割り込みを処理できなくなります。

パフォーマンスプロファイルで、globallyDisableIrqLoadBalancing は、デバイス割り込みが処理されるかどうかを管理するために使用されます。特定のワークロードでは、予約された CPU は、デバイスの割り込みを処理するのに常に十分な訳ではないため、デバイスの割り込みは分離された CPU でグローバルに無効化されていません。デフォルトでは、Node Tuning Operator は分離された CPU でのデバイス割り込みを無効にしません。

16.7.1. ノードの有効な IRQ アフィニティー設定の確認

一部の IRQ コントローラーでは IRQ アフィニティー設定がサポートされていないため、常にすべてのオンライン CPU が IRQ マスクとして公開されます。これらの IRQ コントローラーは CPU 0 で正常に実行されます。

以下は、IRQ アフィニティー設定がサポートされていないことを Red Hat が認識しているドライバーとハードウェアの例です。このリストはすべてを網羅しているわけではありません。

  • megaraid_sas などの一部の RAID コントローラードライバー
  • 多くの不揮発性メモリーエクスプレス (NVMe) ドライバー
  • 一部の LAN on Motherboard (LOM) ネットワークコントローラー
  • managed_irqs を使用するドライバー
注記

IRQ アフィニティー設定をサポートしない理由は、プロセッサーの種類、IRQ コントローラー、マザーボードの回路接続などに関連している可能性があります。

分離された CPU に有効な IRQ アフィニティーが設定されている場合は、一部のハードウェアまたはドライバーで IRQ アフィニティー設定がサポートされていないことを示唆している可能性があります。有効なアフィニティーを見つけるには、ホストにログインし、次のコマンドを実行します。

Copy to Clipboard Toggle word wrap 
$ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;

出力例

Copy to Clipboard Toggle word wrap 
/proc/irq/0/effective_affinity: 1
/proc/irq/1/effective_affinity: 8
/proc/irq/2/effective_affinity: 0
/proc/irq/3/effective_affinity: 1
/proc/irq/4/effective_affinity: 2
/proc/irq/5/effective_affinity: 1
/proc/irq/6/effective_affinity: 1
/proc/irq/7/effective_affinity: 1
/proc/irq/8/effective_affinity: 1
/proc/irq/9/effective_affinity: 2
/proc/irq/10/effective_affinity: 1
/proc/irq/11/effective_affinity: 1
/proc/irq/12/effective_affinity: 4
/proc/irq/13/effective_affinity: 1
/proc/irq/14/effective_affinity: 1
/proc/irq/15/effective_affinity: 1
/proc/irq/24/effective_affinity: 2
/proc/irq/25/effective_affinity: 4
/proc/irq/26/effective_affinity: 2
/proc/irq/27/effective_affinity: 1
/proc/irq/28/effective_affinity: 8
/proc/irq/29/effective_affinity: 4
/proc/irq/30/effective_affinity: 4
/proc/irq/31/effective_affinity: 8
/proc/irq/32/effective_affinity: 8
/proc/irq/33/effective_affinity: 1
/proc/irq/34/effective_affinity: 2

一部のドライバーは、managed_irqs を使用します。そのアフィニティーはカーネルによって内部的に管理され、ユーザー空間はアフィニティーを変更できません。場合によっては、これらの IRQ が分離された CPU に割り当てられることもあります。manage_irqs の詳細は、Affinity of managed interrupts cannot be changed even if they target isolated CPU を参照してください。

16.7.2. ノード割り込みアフィニティーの設定

どのコアがデバイス割り込み要求 (IRQ) を受信できるかを制御するために、IRQ 動的負荷分散用にクラスターノードを設定します。

前提条件

  • コアを分離するには、すべてのサーバーハードウェアコンポーネントが IRQ アフィニティーをサポートしている必要があります。サーバーのハードウェアコンポーネントが IRQ アフィニティーをサポートしているかどうかを確認するには、サーバーのハードウェア仕様を参照するか、ハードウェアプロバイダーに問い合わせてください。

手順

  1. cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
  2. パフォーマンスプロファイルの apiVersion を performance.openshift.io/v2 を使用するように設定します。
  3. globallyDisableIrqLoadBalancing フィールドを削除するか、これを false に設定します。

  4. 適切な分離された CPU と予約された CPU を設定します。以下のスニペットは、2 つの CPU を確保するプロファイルを示しています。IRQ 負荷分散は、isolated CPU セットで実行されている Pod に対して有効になります。

    Copy to Clipboard Toggle word wrap 
    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: dynamic-irq-profile
spec:
  cpu:
    isolated: 2-5
    reserved: 0-1
...
    注記

    予約 CPU と分離 CPU を設定すると、オペレーティングシステムプロセス、カーネルプロセス、および systemd サービスが予約 CPU 上で実行されます。インフラストラクチャー Pod は、低レイテンシーのワークロードが実行されている場所を除いて、任意の CPU で実行されます。低レイテンシーのワークロード Pod は、分離されたプールの専用 CPU で実行されます。詳細は、「インフラストラクチャーおよびアプリケーションコンテナーの CPU の制限」を参照してください。

16.8. huge page の設定

ノードは、OpenShift Container Platform クラスターで使用される Huge Page を事前に割り当てる必要があります。Node Tuning Operator を使用し、特定のノードで Huge Page を割り当てます。

OpenShift Container Platform は、Huge Page を作成し、割り当てる方法を提供します。Node Tuning Operator は、パフォーマンスプロファイルを使用して、これをより簡単に行う方法を提供します。

たとえば、パフォーマンスプロファイルの hugepages pages セクションで、size、count、およびオプションで node の複数のブロックを指定できます。

Copy to Clipboard Toggle word wrap 
hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0
1
1
node は、Huge Page が割り当てられる NUMA ノードです。node を省略すると、ページはすべての NUMA ノード間で均等に分散されます。
注記

更新が完了したことを示す関連するマシン設定プールのステータスを待機します。

これらは、Huge Page を割り当てるのに必要な唯一の設定手順です。

検証

  • 設定を確認するには、ノード上の /proc/meminfo ファイルを参照します。

    Copy to Clipboard Toggle word wrap 
    $ oc debug node/ip-10-0-141-105.ec2.internal
     Copy to Clipboard Toggle word wrap 
    # grep -i huge /proc/meminfo

    出力例

    Copy to Clipboard Toggle word wrap 
    AnonHugePages:    ###### ##
ShmemHugePages:        0 kB
HugePages_Total:       2
HugePages_Free:        2
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       #### ##
Hugetlb:            #### ##

  • 新規サイズを報告するには、oc describe を使用します。

    Copy to Clipboard Toggle word wrap 
    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge

    出力例

    Copy to Clipboard Toggle word wrap 
                                       hugepages-1g=true
 hugepages-###:  ###
 hugepages-###:  ###

16.8.1. 複数の Huge Page サイズの割り当て

同じコンテナーで異なるサイズの Huge Page を要求できます。これにより、Huge Page サイズのニーズの異なる複数のコンテナーで構成されるより複雑な Pod を定義できます。

たとえば、サイズ 1G と 2M を定義でき、Node Tuning Operator は以下に示すようにノード上に両方のサイズを設定します。

Copy to Clipboard Toggle word wrap 
spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

16.9. Node Tuning Operator を使用した NIC キューの削減

Node Tuning Operator は、NIC キューを削減してパフォーマンスを向上させるのに役立ちます。パフォーマンスプロファイルを使用して調整を行い、さまざまなネットワークデバイスのキューをカスタマイズできます。

16.9.1. パフォーマンスプロファイルによる NIC キューの調整

パフォーマンスプロファイルを使用すると、各ネットワークデバイスのキュー数を調整できます。

サポート対象のネットワークデバイスは以下のとおりです。

  • 非仮想ネットワークデバイス
  • 複数のキュー (チャネル) をサポートするネットワークデバイス

サポート対象外のネットワークデバイスは以下の通りです。

  • Pure Software ネットワークインターフェイス
  • ブロックデバイス
  • Intel DPDK Virtual Function

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. cluster-admin 権限を持つユーザーとして、Node Tuning Operator を実行する OpenShift Container Platform クラスターにログインします。
  2. お使いのハードウェアとトポロジーに適したパフォーマンスプロファイルを作成して適用します。プロファイルの作成に関するガイダンスは、「パフォーマンスプロファイルの作成」セクションを参照してください。

  3. この作成したパフォーマンスプロファイルを編集します。

    Copy to Clipboard Toggle word wrap 
    $ oc edit -f <your_profile_name>.yaml

  4. spec フィールドに net オブジェクトを設定します。オブジェクトリストには、以下の 2 つのフィールドを含めることができます。

    • userLevelNetworking は、ブール値フラグとして指定される必須フィールドです。userLevelNetworking が true の場合、サポートされているすべてのデバイスのキュー数は、予約された CPU 数に設定されます。デフォルトは false です。

    • devices は、キューを予約 CPU 数に設定するデバイスのリストを指定する任意のフィールドです。デバイスリストに何も指定しないと、設定がすべてのネットワークデバイスに適用されます。設定は以下のとおりです。

      • interfaceName: このフィールドはインターフェイス名を指定し、正または負のシェルスタイルのワイルドカードをサポートします。

        • ワイルドカード構文の例: <string> .*
        • 負のルールには、感嘆符のプリフィックスが付きます。除外リスト以外のすべてのデバイスにネットキューの変更を適用するには、!<device> を使用します (例: !eno1)。
      • vendorID: 16 ビット (16 進数) として表されるネットワークデバイスベンダー ID。接頭辞は 0x です。

      • deviceID: 16 ビット (16 進数) として表されるネットワークデバイス ID (モデル)。接頭辞は 0x です。

        注記

        deviceID が指定されている場合は、vendorID も定義する必要があります。デバイスエントリー interfaceName、vendorID、または vendorID と deviceID のペアで指定されているすべてのデバイス識別子に一致するデバイスは、ネットワークデバイスとしての資格があります。その後、このネットワークデバイスは net キュー数が予約 CPU 数に設定されます。

        2 つ以上のデバイスを指定すると、net キュー数は、それらのいずれかに一致する net デバイスに設定されます。

  5. このパフォーマンスプロファイルの例を使用して、キュー数をすべてのデバイスの予約 CPU 数に設定します。

    Copy to Clipboard Toggle word wrap 
    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 数にキュー数を設定します。

    Copy to Clipboard Toggle word wrap 
    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 数にキュー数を設定します。

    Copy to Clipboard Toggle word wrap 
    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 数にキュー数を設定します。

    Copy to Clipboard Toggle word wrap 
    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 数にキュー数を設定します。

    Copy to Clipboard Toggle word wrap 
    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. 更新されたパフォーマンスプロファイルを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc apply -f <your_profile_name>.yaml

関連情報

16.9.2. キューステータスの確認

このセクションでは、さまざまなパフォーマンスプロファイルについて、変更の適用を検証する方法を複数例示しています。

例 1

この例では、サポートされている すべて のデバイスの net キュー数は、予約された CPU 数 (2) に設定されます。

パフォーマンスプロファイルの関連セクションは次のとおりです。

Copy to Clipboard Toggle word wrap 
apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
# ...

  • 以下のコマンドを使用して、デバイスに関連付けられたキューのステータスを表示します。

    注記

    パフォーマンスプロファイルが適用されたノードで、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ ethtool -l <device>

  • プロファイルの適用前にキューのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ ethtool -l ens4

    出力例

    Copy to Clipboard Toggle word wrap 
    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   4

  • プロファイルの適用後にキューのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ ethtool -l ens4

    出力例

    Copy to Clipboard Toggle word wrap 
    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   2
    1

1
チャネルを組み合わせると、すべて のサポート対象のデバイスの予約 CPU の合計数は 2 になります。これは、パフォーマンスプロファイルでの設定内容と一致します。

例 2

この例では、サポートされている すべて のネットワークデバイスの net キュー数は、予約された CPU 数 (2) に特定の vendorID を指定して、設定されます。

パフォーマンスプロファイルの関連セクションは次のとおりです。

Copy to Clipboard Toggle word wrap 
apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
      devices:
      - vendorID = 0x1af4
# ...

  • 以下のコマンドを使用して、デバイスに関連付けられたキューのステータスを表示します。

    注記

    パフォーマンスプロファイルが適用されたノードで、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ ethtool -l <device>

  • プロファイルの適用後にキューのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ ethtool -l ens4

    出力例

    Copy to Clipboard Toggle word wrap 
    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   2
    1

1
vendorID=0x1af4 であるサポート対象の全デバイスの合計予約 CPU 数は 2 となります。たとえば、vendorID=0x1af4 のネットワークデバイス ens2 が別に存在する場合に、このデバイスも合計で 2 つの net キューを持ちます。これは、パフォーマンスプロファイルでの設定内容と一致します。

例 3

この例では、サポートされている すべて のネットワークデバイスが定義したデバイス ID のいずれかに一致する場合に、そのネットワークデバイスの net キュー数は、予約された CPU 数 (2) に設定されます。

udevadm info コマンドで、デバイスの詳細なレポートを確認できます。以下の例では、デバイスは以下のようになります。

Copy to Clipboard Toggle word wrap 
# udevadm info -p /sys/class/net/ens4
...
E: ID_MODEL_ID=0x1000
E: ID_VENDOR_ID=0x1af4
E: INTERFACE=ens4
...
 Copy to Clipboard Toggle word wrap 
# udevadm info -p /sys/class/net/eth0
...
E: ID_MODEL_ID=0x1002
E: ID_VENDOR_ID=0x1001
E: INTERFACE=eth0
...

  • interfaceName が eth0 のデバイスの場合に net キューを 2 に、vendorID=0x1af4 を持つデバイスには、以下のパフォーマンスプロファイルを設定します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
    spec:
      cpu:
        reserved: 0-1  #total = 2
        isolated: 2-8
      net:
        userLevelNetworking: true
        devices:
        - interfaceName = eth0
        - vendorID = 0x1af4
...

  • プロファイルの適用後にキューのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ ethtool -l ens4

    出力例

    Copy to Clipboard Toggle word wrap 
    Channel parameters for ens4:
Pre-set maximums:
RX:         0
TX:         0
Other:      0
Combined:   4
Current hardware settings:
RX:         0
TX:         0
Other:      0
Combined:   2
    1

    1
    vendorID=0x1af4 であるサポート対象の全デバイスの合計予約 CPU 数は 2 に設定されます。たとえば、vendorID=0x1af4 のネットワークデバイス ens2 が別に存在する場合に、このデバイスも合計で 2 つの net キューを持ちます。同様に、interfaceName が eth0 のデバイスには、合計 net キューが 2 に設定されます。

16.9.3. NIC キューの調整に関するロギング

割り当てられたデバイスの詳細を示すログメッセージは、それぞれの Tuned デーモンログに記録されます。以下のメッセージは、/var/log/tuned/tuned.log ファイルに記録される場合があります。

  • 正常に割り当てられたデバイスの詳細を示す INFO メッセージが記録されます。

    Copy to Clipboard Toggle word wrap 
    INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3

  • 割り当てることのできるデバイスがない場合は、WARNING メッセージが記録されます。

    Copy to Clipboard Toggle word wrap 
    WARNING  tuned.plugins.base: instance net_test: no matching devices available

第17章 リアルタイムおよび低レイテンシーワークロードのプロビジョニング

多くの組織、特に金融業界や通信業界では、ハイパフォーマンスコンピューティングと予測可能な低レイテンシーが求められます。

OpenShift Container Platform は、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスと一貫した応答時間を実現するための自動チューニングを実装する Node Tuning Operator を提供します。このような変更を行うには、パフォーマンスプロファイル設定を使用します。kernel-rt へのカーネルの更新、Pod インフラコンテナーを含むクラスターおよびオペレーティングシステムのハウスキーピング作業用 CPU の予約、アプリケーションコンテナーがワークロードを実行するための CPU の分離、未使用の CPU の無効化による電力消費削減を行うことができます。

注記

アプリケーションを作成するときは、RHEL for Real Time プロセスおよびスレッド に記載されている一般的な推奨事項に従ってください。

関連情報

17.1. リアルタイム機能を備えたワーカーに低レイテンシーのワークロードをスケジュールする

リアルタイム機能を設定するパフォーマンスプロファイルを適用したワーカーノードに、低レイテンシーのワークロードをスケジュールできます。

注記

特定のノードでワークロードをスケジュールするには、Pod カスタムリソース (CR) でラベルセレクターを使用します。ラベルセレクターは、Node Tuning Operator によって低レイテンシー用に設定されたマシン設定プールに割り当てられているノードと一致している必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 低レイテンシーのワークロード向けにワーカーノードをチューニングするパフォーマンスプロファイルをクラスターに適用した。

手順

  1. 低レイテンシーのワークロード用の Pod CR を作成し、クラスターに適用します。次に例を示します。

    リアルタイム処理を使用するように設定した Pod 仕様の例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: Pod
metadata:
  name: dynamic-low-latency-pod
  annotations:
    cpu-quota.crio.io: "disable"
    1 
    
    cpu-load-balancing.crio.io: "disable"
    2 
    
    irq-load-balancing.crio.io: "disable"
    3 
    
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: dynamic-low-latency-pod
    image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18"
    command: ["sleep", "10h"]
    resources:
      requests:
        cpu: 2
        memory: "200M"
      limits:
        cpu: 2
        memory: "200M"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: ""
    4 
    
  runtimeClassName: performance-dynamic-low-latency-profile
    5 
    
# ...

    1
    Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。
    2
    CPU 負荷分散を無効にします。
    3
    ノード上の Pod を割り込み処理から除外します。
    4
    nodeSelector ラベルは、Node CR で指定したラベルと一致している必要があります。
    5
    runtimeClassName は、クラスターで設定したパフォーマンスプロファイルの名前と一致している必要があります。
  2. Pod の runtimeClassName を performance-<profile_name> の形式で入力します。<profile_name> は PerformanceProfile YAML の name です。上記の例では、name は performance-dynamic-low-latency-profile です。

  3. Pod が正常に実行されていることを確認します。ステータスが running であり、正しい cnf-worker ノードが設定されている必要があります。

    Copy to Clipboard Toggle word wrap 
    $ oc get pod -o wide

    予想される出力

    Copy to Clipboard Toggle word wrap 
    NAME                     READY   STATUS    RESTARTS   AGE     IP           NODE
dynamic-low-latency-pod  1/1     Running   0          5h33m   10.131.0.10  cnf-worker.example.com

  4. IRQ の動的負荷分散向けに設定された Pod が実行される CPU を取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

    予想される出力

    Copy to Clipboard Toggle word wrap 
    Cpus_allowed_list:  2-3

検証

ノードの設定が正しく適用されていることを確認します。

  1. ノードにログインして設定を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc debug node/<node-name>

  2. ノードのファイルシステムを使用できることを確認します。

    Copy to Clipboard Toggle word wrap 
    sh-4.4# chroot /host

    予想される出力

    Copy to Clipboard Toggle word wrap 
    sh-4.4#

  3. デフォルトのシステム CPU アフィニティーマスクに、CPU 2 や 3 などの dynamic-low-latency-pod CPU が含まれていないことを確認します。

    Copy to Clipboard Toggle word wrap 
    sh-4.4# cat /proc/irq/default_smp_affinity

    出力例

    Copy to Clipboard Toggle word wrap 
    33

  4. システムの IRQ が dynamic-low-latency-pod CPU で実行されるように設定されていないことを確認します。

    Copy to Clipboard Toggle word wrap 
    sh-4.4# find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    出力例

    Copy to Clipboard Toggle word wrap 
    /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

警告

低レイテンシー用にノードをチューニングするときに、保証された CPU を必要とするアプリケーションと組み合わせて実行プローブを使用すると、レイテンシーが急上昇する可能性があります。代わりに、適切に設定されたネットワークプローブのセットなど、他のプローブを使用してください。

関連情報

17.2. Guaranteed QoS クラスを持つ Pod の作成

高パフォーマンスのワークロード向けに、quality of service (QoS) クラスが Guaranteed の Pod を作成できます。QoS クラスが Guaranteed の Pod を設定すると、その Pod は指定された CPU とメモリーリソースに優先的にアクセスできます。

QoS クラスが Guaranteed の Pod を作成するには、次の仕様を適用する必要があります。

  • Pod 内の各コンテナーのメモリー制限フィールドとメモリー要求フィールドに同じ値を設定します。
  • Pod 内の各コンテナーの CPU 制限フィールドと CPU 要求フィールドに同じ値を設定します。

一般的に、QoS クラスが Guaranteed の Pod はノードから削除されません。唯一の例外は、予約済みリソースを超えたシステムデーモンによってリソース競合が発生した場合です。このシナリオでは、kubelet は、ノードの安定性を維持するために最も優先度の低い Pod から順番に Pod を削除する可能性があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc)

手順

  1. 次のコマンドを実行して、Pod の namespace を作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create namespace qos-example
    1
    1
    この例では qos-example namespace を使用します。

    出力例

    Copy to Clipboard Toggle word wrap 
    namespace/qos-example created

  2. Pod リソースを作成します。

    1. Pod リソースを定義する YAML ファイルを作成します。

      qos-example.yaml ファイルの例

      Copy to Clipboard Toggle word wrap 
      apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: qos-demo-ctr
    image: quay.io/openshifttest/hello-openshift:openshift
      1 
      
    resources:
      limits:
        memory: "200Mi"
      2 
      
        cpu: "1"
      3 
      
      requests:
        memory: "200Mi"
      4 
      
        cpu: "1"
      5 
      
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]

      1
      この例では、パブリック hello-openshift イメージを使用します。
      2
      メモリー制限を 200 MB に設定します。
      3
      CPU 制限を 1 CPU に設定します。
      4
      メモリー要求を 200 MB に設定します。
      5
      CPU 要求を 1 CPU に設定します。
      注記

      コンテナーのメモリー制限を指定しても、メモリー要求を指定しなかった場合、OpenShift Container Platform によって制限に合わせてメモリー要求が自動的に割り当てられます。同様に、コンテナーの CPU 制限を指定しても、CPU 要求を指定しなかった場合、OpenShift Container Platform によって制限に合わせて CPU 要求が自動的に割り当てられます。

    2. 次のコマンドを実行して、Pod リソースを作成します。

      Copy to Clipboard Toggle word wrap 
      $ oc apply -f qos-example.yaml --namespace=qos-example

      出力例

      Copy to Clipboard Toggle word wrap 
      pod/qos-demo created

検証

  • 次のコマンドを実行して、Pod の qosClass 値を表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pod qos-demo --namespace=qos-example --output=yaml | grep qosClass

    出力例

    Copy to Clipboard Toggle word wrap 
        qosClass: Guaranteed

17.3. Pod の CPU 負荷分散の無効化

CPU 負荷分散を無効または有効にする機能は CRI-O レベルで実装されます。CRI-O のコードは、以下の要件を満たす場合にのみ CPU の負荷分散を無効または有効にします。

  • Pod は performance-<profile-name> ランタイムクラスを使用する必要があります。以下に示すように、パフォーマンスプロファイルのステータスを確認して、適切な名前を取得できます。

    Copy to Clipboard Toggle word wrap 
    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
...
status:
  ...
  runtimeClass: performance-manual

Node Tuning Operator は、関連ノード下での高性能ランタイムハンドラー config snippet の作成と、クラスター下での高性能ランタイムクラスの作成を担当します。このスニペットには、CPU 負荷分散の設定機能を有効にする点を除いて、デフォルトのランタイムハンドラーと同じ内容が含まれています。

Pod の CPU 負荷分散を無効にするには、Pod 仕様に以下のフィールドが含まれる必要があります。

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: Pod
metadata:
  #...
  annotations:
    #...
    cpu-load-balancing.crio.io: "disable"
    #...
  #...
spec:
  #...
  runtimeClassName: performance-<profile_name>
  #...
注記

CPU マネージャーの静的ポリシーが有効にされている場合に、CPU 全体を使用する Guaranteed QoS を持つ Pod について CPU 負荷分散を無効にします。これ以外の場合に CPU 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。

17.4. 優先度の高い Pod の省電力モードの無効化

ワークロードが実行されるノードの省電力を設定するときに、優先度の高いワークロードが影響を受けないように Pod を設定できます。

省電力設定でノードを設定するときは、優先度の高いワークロードを Pod レベルのパフォーマンス設定で設定する必要があります。つまり、Pod で使用されるすべてのコアにその設定が適用されます。

Pod レベルで P ステートと C ステートを無効にすることで、優先度の高いワークロードを設定して、最高のパフォーマンスと最小の待機時間を実現できます。

表17.1 優先度の高いワークロードの設定
アノテーション設定可能な値説明

cpu-c-states.crio.io:

  • "enable"
  • "disable"
  • "max_latency:microseconds"

このアノテーションを使用すると、各 CPU の C ステートを有効または無効にすることができます。あるいは、C ステートの最大レイテンシーをマイクロ秒単位で指定することもできます。たとえば、cpu-c-states.crio.io: "max_latency:10" を設定して、最大レイテンシー 10 マイクロ秒の C ステートを有効にします。Pod に最高のパフォーマンスを提供するには、値を "disable" に設定します。

cpu-freq-governor.crio.io:

サポートされている cpufreq governor。

各 CPU の cpufreq ガバナーを設定します。"performance" ガバナーは、優先度の高いワークロードに推奨されます。

前提条件

  • 優先度の高いワークロード Pod がスケジュールされているノードのパフォーマンスプロファイルで省電力を設定した。

手順

  1. 優先度の高いワークロード Pod に必要なアノテーションを追加します。このアノテーションは default 設定をオーバーライドします。

    優先度の高いワークロードアノテーションの例

    Copy to Clipboard Toggle word wrap 
    apiVersion: v1
kind: Pod
metadata:
  #...
  annotations:
    #...
    cpu-c-states.crio.io: "disable"
    cpu-freq-governor.crio.io: "performance"
    #...
  #...
spec:
  #...
  runtimeClassName: performance-<profile_name>
  #...

  2. Pod を再起動してアノテーションを適用します。

関連情報

高優先度のワークロードと低優先度のワークロードを同じ場所で実行するノードの省電力設定

17.5. CPU CFS クォータの無効化

ピニングされた Pod の CPU スロットリングを除外するには、cpu-quota.crio.io: "disable" アノテーションを使用して Pod を作成します。このアノテーションは、Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。

cpu-quota.crio.io を無効にした Pod 仕様の例

Copy to Clipboard Toggle word wrap 
apiVersion: v1
kind: Pod
metadata:
  annotations:
      cpu-quota.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
#...

注記

CPU CFS のクォータは、CPU マネージャーの静的ポリシーが有効になっている場合、および CPU 全体を使用する Guaranteed QoS を持つ Pod の場合にのみ無効にしてください。たとえば、CPU ピニングされたコンテナーを含む Pod などです。これ以外の場合に CPU CFS クォータを無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響を与える可能性があります。

関連情報

17.6. ピニングされたコンテナーが実行されている CPU の割り込み処理の無効化

ワークロードの低レイテンシーを実現するために、一部のコンテナーでは、コンテナーのピニング先の CPU がデバイス割り込みを処理しないようにする必要があります。Pod アノテーション irq-load-balancing.crio.io を使用して、ピニングされたコンテナーが実行されている CPU でデバイス割り込みを処理するかどうかを定義します。設定すると、CRI-O により、Pod コンテナーが実行されているデバイスの割り込みが無効にされます。

個々の Pod に属するコンテナーがピニングされている CPU の割り込み処理を無効にするには、パフォーマンスプロファイルで globallyDisableIrqLoadBalancing が false に設定されていることを確認します。次に、Pod 仕様で、irq-load-balancing.crio.io Pod アノテーションを disable に設定します。

次の Pod 仕様には、このアノテーションが含まれています。

Copy to Clipboard Toggle word wrap 
apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      irq-load-balancing.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

関連情報

第18章 低レイテンシーノードのチューニングステータスのデバッグ

チューニングステータスのレポートし、クラスターノードのレイテンシーの問題をデバッグするには、PerformanceProfile カスタムリソース (CR) ステータスフィールドを使用します。

18.1. 低レイテンシー CNF チューニングステータスのデバッグ

PerformanceProfile カスタムリソース (CR) には、チューニングのステータスを報告し、レイテンシーのパフォーマンスの低下の問題をデバッグするためのステータスフィールドが含まれます。これらのフィールドは、Operator の調整機能の状態を記述する状態を報告します。

パフォーマンスプロファイルに割り当てられるマシン設定プールのステータスが degraded 状態になると典型的な問題が発生する可能性があり、これにより PerformanceProfile のステータスが低下します。この場合、マシン設定プールは失敗メッセージを発行します。

Node Tuning Operator には performanceProfile.spec.status.Conditions ステータスフィールドが含まれています。

Copy to Clipboard Toggle word wrap 
Status:
  Conditions:
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Available
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Upgradeable
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Progressing
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Degraded

Status フィールドには、パフォーマンスプロファイルのステータスを示す Type 値を指定する Conditions が含まれます。

Available
すべてのマシン設定および Tuned プロファイルが正常に作成され、クラスターコンポーネントで利用可能になり、それら (NTO、MCO、Kubelet) を処理します。
Upgradeable
Operator によって維持されるリソースは、アップグレードを実行する際に安全な状態にあるかどうかを示します。
Progressing
パフォーマンスプロファイルからのデプロイメントプロセスが開始されたことを示します。
Degraded

以下の場合にエラーを示します。

  • パーマンスプロファイルの検証に失敗しました。
  • すべての関連するコンポーネントの作成が完了しませんでした。

これらのタイプには、それぞれ以下のフィールドが含まれます。

Status
特定のタイプの状態 (true または false)。
Timestamp
トランザクションのタイムスタンプ。
Reason string
マシンの読み取り可能な理由。
Message string
状態とエラーの詳細を説明する人が判読できる理由 (ある場合)。

18.1.1. マシン設定プール

パフォーマンスプロファイルとその作成される製品は、関連付けられたマシン設定プール (MCP) に従ってノードに適用されます。MCP は、カーネル引数、kube 設定、Huge Page の割り当て、および rt-kernel のデプロイメントを含むパフォーマンスプロファイルが作成するマシン設定の適用に関する進捗に関する貴重な情報を保持します。Performance Profile コントローラーは MCP の変更を監視し、それに応じてパフォーマンスプロファイルのステータスを更新します。

MCP は、Degraded の場合に限りパフォーマンスプロファイルステータスに返し、performanceProfile.status.condition.Degraded = true になります。

例

以下の例は、これに作成された関連付けられたマシン設定プール (worker-cnf) を持つパフォーマンスプロファイルのサンプルです。

  1. 関連付けられたマシン設定プールの状態は degraded (低下) になります。

    Copy to Clipboard Toggle word wrap 
    # oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    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 セクションには理由が示されます。

    Copy to Clipboard Toggle word wrap 
    # oc describe mcp worker-cnf

    出力例

    Copy to Clipboard Toggle word wrap 
      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 (低下) の状態は、degraded = true とマークされたパフォーマンスプロファイルの status フィールドにも表示されるはずです。

    Copy to Clipboard Toggle word wrap 
    # oc describe performanceprofiles performance

    出力例

    Copy to Clipboard Toggle word wrap 
    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

18.2. Red Hat サポート向けの低レイテンシーのチューニングデバッグデータの収集

サポートケースを作成する際、ご使用のクラスターに関するデバッグ情報を Red Hat サポートに提供していただくと Red Hat のサポートに役立ちます。

must-gather ツールを使用すると、ノードのチューニング、NUMA トポロジー、および低レイテンシーの設定に関する問題のデバッグに必要な OpenShift Container Platform クラスターに関する診断情報を収集できます。

迅速なサポートを得るには、OpenShift Container Platform と低レイテンシーチューニングの両方の診断情報を提供してください。

18.2.1. must-gather ツールについて

oc adm must-gather CLI コマンドは、以下のような問題のデバッグに必要となる可能性のあるクラスターからの情報を収集します。

  • リソース定義
  • 監査ログ
  • サービスログ

--image 引数を指定してコマンドを実行する際にイメージを指定できます。イメージを指定する際、ツールはその機能または製品に関連するデータを収集します。oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

18.2.2. 低遅延チューニングデータの収集

oc adm must-gather CLI コマンドを使用してクラスターに関する情報を収集できます。これには、以下を始めとする低レイテンシーチューニングに関連する機能およびオブジェクトが含まれます。

  • Node Tuning Operator namespace と子オブジェクト
  • MachineConfigPool および関連付けられた MachineConfig オブジェクト
  • Node Tuning Operator および関連付けられた Tuned オブジェクト
  • Linux カーネルコマンドラインオプション
  • CPU および NUMA トポロジー
  • 基本的な PCI デバイス情報と NUMA 局所性

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Container Platform CLI (oc) がインストールされている。

手順

  1. must-gather データを保存するディレクトリーに移動します。

  2. 次のコマンドを実行してデバッグ情報を収集します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm must-gather

    出力例

    Copy to Clipboard Toggle word wrap 
    [must-gather      ] OUT Using must-gather plug-in image: quay.io/openshift-release
When opening a support case, bugzilla, or issue please include the following summary data along with any other requested information:
ClusterID: 829er0fa-1ad8-4e59-a46e-2644921b7eb6
ClusterVersion: Stable at "<cluster_version>"
ClusterOperators:
	All healthy and stable


[must-gather      ] OUT namespace/openshift-must-gather-8fh4x created
[must-gather      ] OUT clusterrolebinding.rbac.authorization.k8s.io/must-gather-rhlgc created
[must-gather-5564g] POD 2023-07-17T10:17:37.610340849Z Gathering data for ns/openshift-cluster-version...
[must-gather-5564g] POD 2023-07-17T10:17:38.786591298Z Gathering data for ns/default...
[must-gather-5564g] POD 2023-07-17T10:17:39.117418660Z Gathering data for ns/openshift...
[must-gather-5564g] POD 2023-07-17T10:17:39.447592859Z Gathering data for ns/kube-system...
[must-gather-5564g] POD 2023-07-17T10:17:39.803381143Z Gathering data for ns/openshift-etcd...

...

Reprinting Cluster State:
When opening a support case, bugzilla, or issue please include the following summary data along with any other requested information:
ClusterID: 829er0fa-1ad8-4e59-a46e-2644921b7eb6
ClusterVersion: Stable at "<cluster_version>"
ClusterOperators:
	All healthy and stable

  3. 作業ディレクトリーに作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ tar cvaf must-gather.tar.gz must-gather-local.5421342344627712289
    1
    1
    must-gather-local.5421342344627712289// を、must-gather ツールによって作成されたディレクトリー名に置き換えます。
    注記

    圧縮ファイルを作成して、サポートケースにデータを添付したり、パフォーマンスプロファイルの作成時に Performance Profile Creator ラッパースクリプトで使用したりできます。

  4. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。

関連情報

第19章 プラットフォーム検証のためのレイテンシーテストの実行

Cloud-native Network Functions (CNF) テストイメージを使用して、CNF ワークロードの実行に必要なすべてのコンポーネントがインストールされている CNF 対応の OpenShift Container Platform クラスターでレイテンシーテストを実行できます。レイテンシーテストを実行して、ワークロードのノードチューニングを検証します。

cnf-tests コンテナーイメージは、registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 で入手できます。

19.1. レイテンシーテストを実行するための前提条件

レイテンシーテストを実行するには、クラスターが次の要件を満たしている必要があります。

  • 必要な CNF 設定をすべて適用した。これには、リファレンス設計仕様 (RDS) またはお客様固有の要件に基づく PerformanceProfile クラスターおよびその他の設定が含まれます。
  • podman login コマンドを使用して、カスタマーポータルの認証情報で registry.redhat.io にログインした。

関連情報

19.2. レイテンシーの測定

cnf-tests イメージは、3 つのツールを使用してシステムのレイテンシーを測定します。

  • hwlatdetect
  • cyclictest
  • oslat

各ツールには特定の用途があります。信頼できるテスト結果を得るために、ツールを順番に使用します。

hwlatdetect
ベアメタルハードウェアが達成できるベースラインを測定します。次のレイテンシーテストに進む前に、hwlatdetect によって報告されるレイテンシーが必要なしきい値を満たしていることを確認してください。これは、オペレーティングシステムのチューニングによってハードウェアレイテンシーのスパイクを修正することはできないためです。
cyclictest
hwlatdetect が検証に合格した後、リアルタイムのカーネルスケジューラーのレイテンシーを検証します。cyclictest ツールは繰り返しタイマーをスケジュールし、希望のトリガー時間と実際のトリガーの時間の違いを測定します。この違いは、割り込みまたはプロセスの優先度によって生じるチューニングで、基本的な問題を発見できます。ツールはリアルタイムカーネルで実行する必要があります。
oslat
CPU 集約型 DPDK アプリケーションと同様に動作し、CPU の高いデータ処理をシミュレーションするビジーループにすべての中断と中断を測定します。

テストでは、次の環境変数が導入されます。

表19.1 レイテンシーテスト環境変数
環境変数説明

LATENCY_TEST_DELAY

テストの実行を開始するまでの時間を秒単位で指定します。この変数を使用すると、CPU マネージャーの調整ループでデフォルトの CPU プールを更新できるようになります。デフォルト値は 0 です。

LATENCY_TEST_CPUS

レイテンシーテストを実行する Pod が使用する CPU の数を指定します。変数を設定しない場合、デフォルト設定にはすべての分離された CPU が含まれます。

LATENCY_TEST_RUNTIME

レイテンシーテストを実行する必要がある時間を秒単位で指定します。デフォルト値は 300 秒です。

注記

レイテンシーテストが完了する前に Ginkgo 2.0 テストスイートがタイムアウトしないようにするには、-ginkgo.timeout フラグを LATENCY_TEST_RUNTIME + 2 分より大きい値に設定します。LATENCY_TEST_DELAY 値も設定する場合は、-ginkgo.timeout を LATENCY_TEST_RUNTIME + LATENCY_TEST_DELAY + 2 分より大きい値に設定する必要があります。Ginkgo 2.0 テストスイートのデフォルトのタイムアウト値は 1 時間です。

HWLATDETECT_MAXIMUM_LATENCY

ワークロードとオペレーティングシステムの最大許容ハードウェアレイテンシーをマイクロ秒単位で指定します。HWLATDETECT_MAXIMUM_LATENCY または MAXIMUM_LATENCY の値を設定しない場合、ツールはデフォルトの予想しきい値 (20μs) とツール自体の実際の最大レイテンシーを比較します。次に、テストはそれに応じて失敗または成功します。

CYCLICTEST_MAXIMUM_LATENCY

cyclictest の実行中に、ウェイクアップする前にすべてのスレッドが期待する最大レイテンシーをマイクロ秒単位で指定します。CYCLICTEST_MAXIMUM_LATENCY または MAXIMUM_LATENCY の値を設定しない場合、ツールは予想される最大レイテンシーと実際の最大レイテンシーの比較をスキップします。

OSLAT_MAXIMUM_LATENCY

oslat テスト結果の最大許容レイテンシーをマイクロ秒単位で指定します。OSLAT_MAXIMUM_LATENCY または MAXIMUM_LATENCY の値を設定しない場合、ツールは予想される最大レイテンシーと実際の最大レイテンシーの比較をスキップします。

MAXIMUM_LATENCY

最大許容レイテンシーをマイクロ秒単位で指定する統合変数。利用可能なすべてのレイテンシーツールに適用できます。

注記

レイテンシーツールに固有の変数は、統合された変数よりも優先されます。たとえば、OSLAT_MAXIMUM_LATENCY が 30 マイクロ秒に設定され、MAXIMUM_LATENCY が 10 マイクロ秒に設定されている場合、oslat テストは 30 マイクロ秒の最大許容遅延で実行されます。

19.3. レイテンシーテストの実行

クラスターレイテンシーテストを実行して、Cloud-native Network Functions (CNF) ワークロードのノードチューニングを検証します。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

この手順では、hwlatdetect、cycltest、および oslat という 3 つの個別のテストを実行します。各テストの詳細は、それぞれのセクションを参照してください。

手順

  1. kubeconfig ファイルを含むディレクトリーでシェルプロンプトを開きます。

    現在のディレクトリーにある kubeconfig ファイルとそれに関連する $KUBECONFIG 環境変数を含むテストイメージを提供し、ボリュームを介してマウントします。これにより、実行中のコンテナーがコンテナー内から kubeconfig ファイルを使用できるようになります。

    注記

    次のコマンドにより、ローカルの kubeconfig が cnf-tests コンテナー内の kubeconfig/kubeconfig にマウントされ、クラスターにアクセスできるようになります。

  2. レイテンシーテストを実行するために、次のコマンドを実行します。必要に応じて変数値を置き換えます。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=600\
-e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 /usr/bin/test-run.sh \
--ginkgo.v --ginkgo.timeout="24h"

    LATENCY_TEST_RUNTIME は秒単位で表示されます。この場合は 600 秒 (10 分) です。観測された最大レイテンシーが MAXIMUM_LATENCY (20 μs) より低い場合、テストは正常に実行されます。

    結果がレイテンシーのしきい値を超えると、テストは失敗します。

  3. オプション: --ginkgo.dry-run フラグを追加して、レイテンシーテストをドライランモードで実行します。これは、テストでどのようなコマンドが実行されるかを確認するのに役立ちます。
  4. オプション: --ginkgo.v フラグを追加して、詳細度を上げてテストを実行します。

  5. オプション: --ginkgo.timeout="24h" フラグを追加して、レイテンシーテストが完了する前に Ginkgo 2.0 テストスイートがタイムアウトしないようにします。

    重要

    テストの際には、上記のように、より短い期間を使用してテストを実行できます。ただし、最終的な検証と有効な結果を得るには、テストを少なくとも 12 時間 (43200 秒) 実行する必要があります。

19.3.1. hwlatdetect の実行

hwlatdetect ツールは、Red Hat Enterprise Linux (RHEL) 9.x の通常のサブスクリプションを含む rt-kernel パッケージで利用できます。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

前提条件

  • レイテンシーテストを実行するための前提条件を確認した。

手順

  • hwlatdetect テストを実行するには、変数値を適切に置き換えて、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
/usr/bin/test-run.sh --ginkgo.focus="hwlatdetect" --ginkgo.v --ginkgo.timeout="24h"

    hwlatdetect テストは 10 分間 (600 秒) 実行されます。観測された最大レイテンシーが MAXIMUM_LATENCY (20 μs) よりも低い場合、テストは正常に実行されます。

    結果がレイテンシーのしきい値を超えると、テストは失敗します。

    重要

    テストの際には、上記のように、より短い期間を使用してテストを実行できます。ただし、最終的な検証と有効な結果を得るには、テストを少なくとも 12 時間 (43200 秒) 実行する必要があります。

    障害出力の例

    Copy to Clipboard Toggle word wrap 
    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=hwlatdetect
I0908 15:25:20.023712      27 request.go:601] Waited for 1.046586367s due to client-side throttling, not priority and fairness, request: GET:https://api.hlxcl6.lab.eng.tlv2.redhat.com:6443/apis/imageregistry.operator.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662650718
Will run 1 of 3 specs

[...]

• Failure [283.574 seconds]
[performance] Latency Test
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
  with the hwlatdetect image
  /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:228
    should succeed [It]
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:236

    Log file created at: 2022/09/08 15:25:27
    Running on machine: hwlatdetect-b6n4n
    Binary: Built with gc go1.17.12 for linux/amd64
    Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
    I0908 15:25:27.160620       1 node.go:39] Environment information: /proc/cmdline: BOOT_IMAGE=(hd1,gpt3)/ostree/rhcos-c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/vmlinuz-4.18.0-372.19.1.el8_6.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=metal ostree=/ostree/boot.1/rhcos/c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/0 ip=dhcp root=UUID=5f80c283-f6e6-4a27-9b47-a287157483b2 rw rootflags=prjquota boot=UUID=773bf59a-bafd-48fc-9a87-f62252d739d3 skew_tick=1 nohz=on rcu_nocbs=0-3 tuned.non_isolcpus=0000ffff,ffffffff,fffffff0 systemd.cpu_affinity=4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79 intel_iommu=on iommu=pt isolcpus=managed_irq,0-3 nohz_full=0-3 tsc=nowatchdog nosoftlockup nmi_watchdog=0 mce=off skew_tick=1 rcutree.kthread_prio=11 + +
    I0908 15:25:27.160830       1 node.go:46] Environment information: kernel version 4.18.0-372.19.1.el8_6.x86_64
    I0908 15:25:27.160857       1 main.go:50] running the hwlatdetect command with arguments [/usr/bin/hwlatdetect --threshold 1 --hardlimit 1 --duration 100 --window 10000000us --width 950000us]
    F0908 15:27:10.603523       1 main.go:53] failed to run hwlatdetect command; out: hwlatdetect:  test duration 100 seconds
       detector: tracer
       parameters:
            Latency threshold: 1us
    1 
    
            Sample window:     10000000us
            Sample width:      950000us
         Non-sampling period:  9050000us
            Output File:       None

    Starting test
    test finished
    Max Latency: 326us
    2 
    
    Samples recorded: 5
    Samples exceeding threshold: 5
    ts: 1662650739.017274507, inner:6, outer:6
    ts: 1662650749.257272414, inner:14, outer:326
    ts: 1662650779.977272835, inner:314, outer:12
    ts: 1662650800.457272384, inner:3, outer:9
    ts: 1662650810.697273520, inner:3, outer:2

[...]

JUnit report was created: /junit.xml/cnftests-junit.xml


Summarizing 1 Failure:

[Fail] [performance] Latency Test with the hwlatdetect image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:476

Ran 1 of 194 Specs in 365.797 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped
--- FAIL: TestTest (366.08s)
FAIL

    1
    MAXIMUM_LATENCY または HWLATDETECT_MAXIMUM_LATENCY 環境変数を使用して、レイテンシーしきい値を設定できます。
    2
    テスト中に測定される最大レイテンシー値。
hwlatdetect テスト結果の例

以下のタイプの結果をキャプチャーできます。

  • テスト中に行われた変更への影響の履歴を作成するために、各実行後に収集される大まかな結果
  • 最良の結果と設定を備えたラフテストの組み合わせセット

良い結果の例

Copy to Clipboard Toggle word wrap 
hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0

hwlatdetect ツールは、サンプルが指定されたしきい値を超えた場合にのみ出力を提供します。

悪い結果の例

Copy to Clipboard Toggle word wrap 
hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None

Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63

hwlatdetect の出力は、複数のサンプルがしきい値を超えていることを示しています。ただし、同じ出力は、次の要因に基づいて異なる結果を示す可能性があります。

  • テストの期間
  • CPU コアの数
  • ホストファームウェアの設定
警告

次のレイテンシーテストに進む前に、hwlatdetect によって報告されたレイテンシーが必要なしきい値を満たしていることを確認してください。ハードウェアによって生じるレイテンシーを修正するには、システムベンダーのサポートに連絡しないといけない場合があります。

すべての遅延スパイクがハードウェアに関連しているわけではありません。ワークロードの要件を満たすようにホストファームウェアを調整してください。詳細は、システムチューニング用のファームウェアパラメーターの設定 を参照してください。

19.3.2. cyclictest の実行

cyclictest ツールは、指定された CPU でのリアルタイムカーネルスケジューラーのレイテンシーを測定します。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

前提条件

  • レイテンシーテストを実行するための前提条件を確認した。

手順

  • cyclictest を実行するには、次のコマンドを実行し、必要に応じて変数の値を置き換えます。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
/usr/bin/test-run.sh --ginkgo.focus="cyclictest" --ginkgo.v --ginkgo.timeout="24h"

    このコマンドは、cyclictest ツールを 10 分 (600 秒) 実行します。観測された最大レイテンシーが MAXIMUM_LATENCY (この例では 20 μs) よりも低い場合、テストは正常に実行されます。通常、20 μs 以上のレイテンシースパイクは、通信事業者の RAN ワークロードでは許容されません。

    結果がレイテンシーのしきい値を超えると、テストは失敗します。

    重要

    テストの際には、上記のように、より短い期間を使用してテストを実行できます。ただし、最終的な検証と有効な結果を得るには、テストを少なくとも 12 時間 (43200 秒) 実行する必要があります。

    障害出力の例

    Copy to Clipboard Toggle word wrap 
    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=cyclictest
I0908 13:01:59.193776      27 request.go:601] Waited for 1.046228824s due to client-side throttling, not priority and fairness, request: GET:https://api.compute-1.example.com:6443/apis/packages.operators.coreos.com/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662642118
Will run 1 of 3 specs

[...]

Summarizing 1 Failure:

[Fail] [performance] Latency Test with the cyclictest image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:220

Ran 1 of 194 Specs in 161.151 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped
--- FAIL: TestTest (161.48s)
FAIL

サイクルテスト結果の例

同じ出力は、ワークロードごとに異なる結果を示す可能性があります。たとえば、18μs までのスパイクは 4G DU ワークロードでは許容されますが、5G DU ワークロードでは許容されません。

良い結果の例

Copy to Clipboard Toggle word wrap 
running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 579506   535967  418614  573648  532870  529897  489306  558076  582350  585188  583793  223781  532480  569130  472250  576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:

悪い結果の例

Copy to Clipboard Toggle word wrap 
running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 564632   579686  354911  563036  492543  521983  515884  378266  592621  463547  482764  591976  590409  588145  589556  353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917

19.3.3. oslat の実行

oslat テストは、CPU を集中的に使用する DPDK アプリケーションをシミュレートし、すべての中断と中断を測定して、クラスターが CPU の負荷の高いデータ処理をどのように処理するかをテストします。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

前提条件

  • レイテンシーテストを実行するための前提条件を確認した。

手順

  • oslat テストを実行するには、変数値を適切に置き換えて、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
/usr/bin/test-run.sh --ginkgo.focus="oslat" --ginkgo.v --ginkgo.timeout="24h"

    LATENCY_TEST_CPUS は、oslat コマンドでテストする CPU の数を指定します。

    このコマンドは、oslat ツールを 10 分 (600 秒) 実行します。観測された最大レイテンシーが MAXIMUM_LATENCY (20 μs) よりも低い場合、テストは正常に実行されます。

    結果がレイテンシーのしきい値を超えると、テストは失敗します。

    重要

    テストの際には、上記のように、より短い期間を使用してテストを実行できます。ただし、最終的な検証と有効な結果を得るには、テストを少なくとも 12 時間 (43200 秒) 実行する必要があります。

    障害出力の例

    Copy to Clipboard Toggle word wrap 
    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=oslat
I0908 12:51:55.999393      27 request.go:601] Waited for 1.044848101s due to client-side throttling, not priority and fairness, request: GET:https://compute-1.example.com:6443/apis/machineconfiguration.openshift.io/v1?timeout=32s
Running Suite: CNF Features e2e integration tests
=================================================
Random Seed: 1662641514
Will run 1 of 3 specs

[...]

• Failure [77.833 seconds]
[performance] Latency Test
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
  with the oslat image
  /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:128
    should succeed [It]
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:153

    The current latency 304 is bigger than the expected one 1 :
    1 
    

[...]

Summarizing 1 Failure:

[Fail] [performance] Latency Test with the oslat image [It] should succeed
/remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:177

Ran 1 of 194 Specs in 161.091 seconds
FAIL! -- 0 Passed | 1 Failed | 0 Pending | 2 Skipped
--- FAIL: TestTest (161.42s)
FAIL

    1
    この例では、測定されたレイテンシーが最大許容値を超えています。

19.4. レイテンシーテストの失敗レポートの生成

次の手順を使用して、JUnit レイテンシーテストの出力とテストの失敗レポートを生成します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • レポートがダンプされる場所へのパスを --report パラメーターを渡すことで、クラスターの状態とトラブルシューティング用のリソースに関する情報を含むテスト失敗レポートを作成します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \
-e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
/usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v

    ここでは、以下のようになります。

    <report_folder_path>
    レポートが生成されるフォルダーへのパスです。

19.5. JUnit レイテンシーテストレポートの生成

次の手順を使用して、JUnit レイテンシーテストの出力とテストの失敗レポートを生成します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • レポートがダンプされる場所へのパスとともに --junit パラメーターを渡すことにより、JUnit 準拠の XML レポートを作成します。

    注記

    このコマンドを実行する前に、junit フォルダーを作成する必要があります。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junit:/junit \
-e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
/usr/bin/test-run.sh --ginkgo.junit-report junit/<file-name>.xml --ginkgo.v

    ここでは、以下のようになります。

    junit
    junit レポートを保存するフォルダーです。

19.6. 単一ノードの OpenShift クラスターでレイテンシーテストを実行する

単一ノードの OpenShift クラスターでレイテンシーテストを実行できます。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。podman コマンドを機能させるには、作成したボリュームに :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • Node Tuning Operator を使用してクラスターパフォーマンスプロファイルを適用しました。

手順

  • 単一ノードの OpenShift クラスターでレイテンシーテストを実行するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
/usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
    注記

    各テストのデフォルトの実行時間は 300 秒です。有効なレイテンシーテスト結果を得るには、LATENCY_TEST_RUNTIME 変数を更新してテストを少なくとも 12 時間実行してください。バケットのレイテンシー検証ステップを実行するには、最大レイテンシーを指定する必要があります。最大レイテンシー変数の詳細は、「レイテンシーの測定」セクションの表を参照してください。

    テストスイートの実行後に、未解決のリソースすべてがクリーンアップされます。

19.7. 切断されたクラスターでのレイテンシーテストの実行

CNF テストイメージは、外部レジストリーに到達できない切断されたクラスターでテストを実行できます。これには、次の 2 つの手順が必要です。

  1. cnf-tests イメージをカスタム切断レジストリーにミラーリングします。
  2. カスタムの切断されたレジストリーからイメージを使用するようにテストに指示します。
クラスターからアクセスできるカスタムレジストリーへのイメージのミラーリング

mirror 実行ファイルがイメージに同梱されており、テストイメージをローカルレジストリーにミラーリングするために oc が必要とする入力を提供します。

  1. クラスターおよび registry.redhat.io にアクセスできる中間マシンから次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
/usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

    ここでは、以下のようになります。

    <disconnected_registry>
    my.local.registry:5000/ など、設定した切断されたミラーレジストリーです。

  2. cnf-tests イメージを切断されたレジストリーにミラーリングした場合は、テストの実行時にイメージの取得に使用された元のレジストリーをオーバーライドする必要があります。次に例を示します。

    Copy to Clipboard Toggle word wrap 
    podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e IMAGE_REGISTRY="<disconnected_registry>" \
-e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.18" \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> \
<disconnected_registry>/cnf-tests-rhel8:v4.18 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
カスタムレジストリーからのイメージを使用するためのテストの設定

CNF_TESTS_IMAGE 変数と IMAGE_REGISTRY 変数を使用して、カスタムテストイメージとイメージレジストリーを使用してレイテンシーテストを実行できます。

  • カスタムテストイメージとイメージレジストリーを使用するようにレイテンシーテストを設定するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e IMAGE_REGISTRY="<custom_image_registry>" \
-e CNF_TESTS_IMAGE="<custom_cnf-tests_image>" \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"

    ここでは、以下のようになります。

    <custom_image_registry>
    custom.registry:5000/ などのカスタムイメージレジストリーです。
    <custom_cnf-tests_image>
    custom-cnf-tests-image:latest などのカスタム cnf-tests イメージです。
クラスター OpenShift イメージレジストリーへのイメージのミラーリング

OpenShift Container Platform は、クラスター上の標準ワークロードとして実行される組み込まれたコンテナーイメージレジストリーを提供します。

手順

  1. レジストリーをルートを使用して公開し、レジストリーへの外部アクセスを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge

  2. 次のコマンドを実行して、レジストリーエンドポイントを取得します。

    Copy to Clipboard Toggle word wrap 
    $ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')

  3. イメージを公開する namespace を作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create ns cnftests

  4. イメージストリームを、テストに使用されるすべての namespace で利用可能にします。これは、テスト namespace が cnf-tests イメージストリームからイメージを取得できるようにするために必要です。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
     Copy to Clipboard Toggle word wrap 
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests

  5. 次のコマンドを実行して、docker シークレット名と認証トークンを取得します。

    Copy to Clipboard Toggle word wrap 
    $ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
     Copy to Clipboard Toggle word wrap 
    $ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')

  6. dockerauth.json ファイルを作成します。次に例を示します。

    Copy to Clipboard Toggle word wrap 
    $ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json

  7. イメージミラーリングを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:4.18 \
/usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
-a=$(pwd)/dockerauth.json -f -

  8. テストを実行します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> \
-e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
異なるテストイメージセットのミラーリング

オプションで、レイテンシーテスト用にミラーリングされるデフォルトのアップストリームイメージを変更できます。

手順

  1. mirror コマンドは、デフォルトでアップストリームイメージをミラーリングしようとします。これは、以下の形式のファイルをイメージに渡すことで上書きできます。

    Copy to Clipboard Toggle word wrap 
    [
    {
        "registry": "public.registry.io:5000",
        "image": "imageforcnftests:4.18"
    }
]

  2. ファイルを mirror コマンドに渡します。たとえば、images.json としてローカルに保存します。以下のコマンドでは、ローカルパスはコンテナー内の /kubeconfig にマウントされ、これを mirror コマンドに渡すことができます。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 /usr/bin/mirror \
--registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
|  oc image mirror -f -

19.8. cnf-tests コンテナーでのエラーのトラブルシューティング

レイテンシーテストを実行するには、cnf-tests コンテナー内からクラスターにアクセスできる必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • 次のコマンドを実行して、cnf-tests コンテナー内からクラスターにアクセスできることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel8:v4.18 \
oc get nodes

    このコマンドが機能しない場合は、DNS 間のスパン、MTU サイズ、またはファイアウォールアクセスに関連するエラーが発生している可能性があります。

第20章 ワーカーレイテンシープロファイルを使用したレイテンシーの高い環境でのクラスターの安定性の向上

クラスター管理者が遅延テストを実行してプラットフォームを検証した際に、遅延が大きい場合でも安定性を確保するために、クラスターの動作を調整する必要性が判明することがあります。クラスター管理者が変更する必要があるのは、ファイルに記録されている 1 つのパラメーターだけです。このパラメーターは、監視プロセスがステータスを読み取り、クラスターの健全性を解釈する方法に影響を与える 4 つのパラメーターを制御するものです。1 つのパラメーターのみを変更し、サポートしやすく簡単な方法でクラスターをチューニングできます。

Kubelet プロセスは、クラスターの健全性を監視する上での出発点です。Kubelet は、OpenShift Container Platform クラスター内のすべてのノードのステータス値を設定します。Kubernetes コントローラーマネージャー (kube controller) は、デフォルトで 10 秒ごとにステータス値を読み取ります。ノードのステータス値を読み取ることができない場合、設定期間が経過すると、kube controller とそのノードとの接続が失われます。デフォルトの動作は次のとおりです。

  1. コントロールプレーン上のノードコントローラーが、ノードの健全性を Unhealthy に更新し、ノードの Ready 状態を `Unknown` とマークします。
  2. この操作に応じて、スケジューラーはそのノードへの Pod のスケジューリングを停止します。
  3. ノードライフサイクルコントローラーが、NoExecute effect を持つ node.kubernetes.io/unreachable taint をノードに追加し、デフォルトでノード上のすべての Pod を 5 分後にエビクトするようにスケジュールします。

この動作は、ネットワークが遅延の問題を起こしやすい場合、特にネットワークエッジにノードがある場合に問題が発生する可能性があります。場合によっては、ネットワークの遅延が原因で、Kubernetes コントローラーマネージャーが正常なノードから更新を受信できないことがあります。Kubelet は、ノードが正常であっても、ノードから Pod を削除します。

この問題を回避するには、ワーカーレイテンシープロファイル を使用して、Kubelet と Kubernetes コントローラーマネージャーがアクションを実行する前にステータスの更新を待機する頻度を調整できます。これらの調整により、コントロールプレーンとワーカーノード間のネットワーク遅延が最適でない場合に、クラスターが適切に動作するようになります。

これらのワーカーレイテンシープロファイルには、3 つのパラメーターセットが含まれています。パラメーターは、遅延の増加に対するクラスターの反応を制御するように、慎重に調整された値で事前定義されています。試験により手作業で最良の値を見つける必要はありません。

クラスターのインストール時、またはクラスターネットワークのレイテンシーの増加に気付いたときはいつでも、ワーカーレイテンシープロファイルを設定できます。

20.1. ワーカーレイテンシープロファイルについて

ワーカーレイテンシープロファイルは、4 つの異なるカテゴリーからなる慎重に調整されたパラメーターです。これらの値を実装する 4 つのパラメーターは、node-status-update-frequency、node-monitor-grace-period、default-not-ready-toleration-seconds、および default-unreachable-toleration-seconds です。これらのパラメーターにより、遅延の問題に対するクラスターの反応を制御できる値を使用できます。手作業で最適な値を決定する必要はありません。

重要

これらのパラメーターの手動設定はサポートされていません。パラメーター設定が正しくないと、クラスターの安定性に悪影響が及びます。

すべてのワーカーレイテンシープロファイルは、次のパラメーターを設定します。

node-status-update-frequency
kubelet がノードのステータスを API サーバーにポストする頻度を指定します。
node-monitor-grace-period
Kubernetes コントローラーマネージャーが、ノードを異常とマークし、node.kubernetes.io/not-ready または node.kubernetes.io/unreachable taint をノードに追加する前に、kubelet からの更新を待機する時間を秒単位で指定します。
default-not-ready-toleration-seconds
ノードを異常とマークした後、Kube API Server Operator がそのノードから Pod を削除するまでに待機する時間を秒単位で指定します。
default-unreachable-toleration-seconds
ノードを到達不能とマークした後、Kube API Server Operator がそのノードから Pod を削除するまでに待機する時間を秒単位で指定します。

次の Operator は、ワーカーレイテンシープロファイルの変更を監視し、それに応じて対応します。

  • Machine Config Operator (MCO) は、ワーカーノードの node-status-update-frequency パラメーターを更新します。
  • Kubernetes コントローラーマネージャーは、コントロールプレーンノードの node-monitor-grace-period パラメーターを更新します。
  • Kubernetes API Server Operator は、コントロールプレーンノードの default-not-ready-toleration-seconds および default-unreachable-toleration-seconds パラメーターを更新します。

ほとんどの場合はデフォルト設定が機能しますが、OpenShift Container Platform は、ネットワークで通常よりも高いレイテンシーが発生している状況に対して、他に 2 つのワーカーレイテンシープロファイルを提供します。次のセクションでは、3 つのワーカーレイテンシープロファイルを説明します。

デフォルトのワーカーレイテンシープロファイル

Default プロファイルを使用すると、各 Kubelet が 10 秒ごとにステータスを更新します (node-status-update-frequency)。Kube Controller Manager は、5 秒ごとに Kubelet のステータスをチェックします。

Kubernetes Controller Manager は、Kubelet からのステータス更新を 40 秒 (node-monitor-grace-period) 待機した後、Kubelet が正常ではないと判断します。ステータスが提供されない場合、Kubernetes コントローラーマネージャーは、ノードに node.kubernetes.io/not-ready または node.kubernetes.io/unreachable taint のマークを付け、そのノードの Pod を削除します。

Pod が NoExecute taint を持つノード上にある場合、Pod は tolerationSeconds に従って実行されます。Pod に taint がない場合、その Pod は 300 秒以内に削除されます (Kube API Server の default-not-ready-toleration-seconds および default-unreachable-toleration-seconds 設定)。

プロファイルコンポーネントパラメーター値

デフォルト

kubelet

node-status-update-frequency

10s

Kubelet コントローラーマネージャー

node-monitor-grace-period

40s

Kubernetes API Server Operator

default-not-ready-toleration-seconds

300s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

300s

中規模のワーカーレイテンシープロファイル

ネットワークレイテンシーが通常の場合、MediumUpdateAverageReaction プロファイルを使用します。

MediumUpdateAverageReaction プロファイルは、kubelet の更新の頻度を 20 秒に減らし、Kubernetes コントローラーマネージャーがそれらの更新を待機する期間を 2 分に変更します。そのノード上の Pod の Pod 排除期間は 60 秒に短縮されます。Pod に tolerationSeconds パラメーターがある場合、エビクションはそのパラメーターで指定された期間待機します。

Kubernetes コントローラーマネージャーは、ノードが異常であると判断するまでに 2 分間待機します。別の 1 分間でエビクションプロセスが開始されます。

プロファイルコンポーネントパラメーター値

MediumUpdateAverageReaction

kubelet

node-status-update-frequency

20s

Kubelet コントローラーマネージャー

node-monitor-grace-period

2m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

ワーカーの低レイテンシープロファイル

ネットワーク遅延が非常に高い場合は、LowUpdateSlowReaction プロファイルを使用します。

LowUpdateSlowReaction プロファイルは、kubelet の更新頻度を 1 分に減らし、Kubernetes コントローラーマネージャーがそれらの更新を待機する時間を 5 分に変更します。そのノード上の Pod の Pod 排除期間は 60 秒に短縮されます。Pod に tolerationSeconds パラメーターがある場合、エビクションはそのパラメーターで指定された期間待機します。

Kubernetes コントローラーマネージャーは、ノードが異常であると判断するまでに 5 分間待機します。別の 1 分間でエビクションプロセスが開始されます。

プロファイルコンポーネントパラメーター値

LowUpdateSlowReaction

kubelet

node-status-update-frequency

1m

Kubelet コントローラーマネージャー

node-monitor-grace-period

5m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

注記

レイテンシープロファイルは、カスタムのマシン設定プールをサポートしていません。デフォルトのワーカーマシン設定プールのみをサポートしていします。

20.2. クラスター作成時にワーカー遅延プロファイルを実装する

重要

インストールプログラムの設定を編集するには、まず openshift-install create manifests コマンドを使用して、デフォルトのノードマニフェストとその他のマニフェスト YAML ファイルを作成します。このファイル構造がなければ、workerLatencyProfile は追加できません。インストール先のプラットフォームにはさまざまな要件があります。該当するプラットフォームのドキュメントで、インストールセクションを参照してください。

workerLatencyProfile は、次の順序でマニフェストに追加する必要があります。

  1. インストールに適したフォルダー名を使用して、クラスターの構築に必要なマニフェストを作成します。
  2. config.node を定義する YAML ファイルを作成します。ファイルは manifests ディレクトリーに置く必要があります。
  3. 初めてマニフェストで workerLatencyProfile を定義する際には、クラスターの作成時に Default、MediumUpdateAverageReaction、または LowUpdateSlowReaction マニフェストのいずれかを指定します。

検証

  • 以下は、マニフェストファイル内の spec.workerLatencyProfile Default 値を示すマニフェストを作成する例です。

    Copy to Clipboard Toggle word wrap 
    $ openshift-install create manifests --dir=<cluster-install-dir>

  • マニフェストを編集して値を追加します。この例では、vi を使用して、"Default" の workerLatencyProfile 値が追加されたマニフェストファイルの例を示します。

    Copy to Clipboard Toggle word wrap 
    $ vi <cluster-install-dir>/manifests/config-node-default-profile.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    apiVersion: config.openshift.io/v1
kind: Node
metadata:
name: cluster
spec:
workerLatencyProfile: "Default"

20.3. ワーカーレイテンシープロファイルの使用と変更

ネットワークの遅延に対処するためにワーカー遅延プロファイルを変更するには、node.config オブジェクトを編集してプロファイルの名前を追加します。遅延が増加または減少したときに、いつでもプロファイルを変更できます。

ワーカーレイテンシープロファイルは、一度に 1 つずつ移行する必要があります。たとえば、Default プロファイルから LowUpdateSlowReaction ワーカーレイテンシープロファイルに直接移行することはできません。まず Default ワーカーレイテンシープロファイルから MediumUpdateAverageReaction プロファイルに移行し、次に LowUpdateSlowReaction プロファイルに移行する必要があります。同様に、Default プロファイルに戻る場合は、まずロープロファイルからミディアムプロファイルに移行し、次に Default に移行する必要があります。

注記

OpenShift Container Platform クラスターのインストール時にワーカーレイテンシープロファイルを設定することもできます。

手順

デフォルトのワーカーレイテンシープロファイルから移動するには、以下を実行します。

  1. 中規模のワーカーのレイテンシープロファイルに移動します。

    1. node.config オブジェクトを編集します。

      Copy to Clipboard Toggle word wrap 
      $ oc edit nodes.config/cluster

    2. spec.workerLatencyProfile: MediumUpdateAverageReaction を追加します。

      node.config オブジェクトの例

      Copy to Clipboard Toggle word wrap 
      apiVersion: config.openshift.io/v1
kind: Node
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2022-07-08T16:02:51Z"
  generation: 1
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: 36282574-bf9f-409e-a6cd-3032939293eb
  resourceVersion: "1865"
  uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
spec:
  workerLatencyProfile: MediumUpdateAverageReaction
      1 
      

# ...

      1
      中規模のワーカーレイテンシーポリシーを指定します。

      変更が適用されると、各ワーカーノードでのスケジューリングは無効になります。

  2. 必要に応じて、ワーカーのレイテンシーが低いプロファイルに移動します。

    1. node.config オブジェクトを編集します。

      Copy to Clipboard Toggle word wrap 
      $ oc edit nodes.config/cluster

    2. spec.workerLatencyProfile の値を LowUpdateSlowReaction に変更します。

      node.config オブジェクトの例

      Copy to Clipboard Toggle word wrap 
      apiVersion: config.openshift.io/v1
kind: Node
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2022-07-08T16:02:51Z"
  generation: 1
  name: cluster
  ownerReferences:
  - apiVersion: config.openshift.io/v1
    kind: ClusterVersion
    name: version
    uid: 36282574-bf9f-409e-a6cd-3032939293eb
  resourceVersion: "1865"
  uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
spec:
  workerLatencyProfile: LowUpdateSlowReaction
      1 
      

# ...

      1
      低ワーカーレイテンシーポリシーの使用を指定します。

変更が適用されると、各ワーカーノードでのスケジューリングは無効になります。

検証

  • 全ノードが Ready 状態に戻ると、以下のコマンドを使用して Kubernetes Controller Manager を確認し、これが適用されていることを確認できます。

    Copy to Clipboard Toggle word wrap 
    $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

    出力例

    Copy to Clipboard Toggle word wrap 
    # ...
    - lastTransitionTime: "2022-07-11T19:47:10Z"
      reason: ProfileUpdated
      status: "False"
      type: WorkerLatencyProfileProgressing
    - lastTransitionTime: "2022-07-11T19:47:10Z"
    1 
    
      message: all static pod revision(s) have updated latency profile
      reason: ProfileUpdated
      status: "True"
      type: WorkerLatencyProfileComplete
    - lastTransitionTime: "2022-07-11T19:20:11Z"
      reason: AsExpected
      status: "False"
      type: WorkerLatencyProfileDegraded
    - lastTransitionTime: "2022-07-11T19:20:36Z"
      status: "False"
# ...

    1
    プロファイルが適用され、アクティブであることを指定します。

ミディアムプロファイルからデフォルト、またはデフォルトからミディアムに変更する場合、node.config オブジェクトを編集し、spec.workerLatencyProfile パラメーターを適切な値に設定します。

20.4. workerLatencyProfile の結果の値を表示する手順の例

次のコマンドを使用して、workerLatencyProfile の値を表示できます。

検証

  1. Kube API サーバーによる default-not-ready-toleration-seconds および default-unreachable-toleration-seconds フィールドの出力を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get KubeAPIServer -o yaml | grep -A 1 default-

    出力例

    Copy to Clipboard Toggle word wrap 
    default-not-ready-toleration-seconds:
- "300"
default-unreachable-toleration-seconds:
- "300"

  2. Kube Controller Manager からの node-monitor-grace-period フィールドの値を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get KubeControllerManager -o yaml | grep -A 1 node-monitor

    出力例

    Copy to Clipboard Toggle word wrap 
    node-monitor-grace-period:
- 40s

  3. Kubelet からの nodeStatusUpdateFrequency 値を確認します。デバッグシェル内のルートディレクトリーとしてディレクトリー /host を設定します。root ディレクトリーを /host に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。

    Copy to Clipboard Toggle word wrap 
    $ oc debug node/<worker-node-name>
$ chroot /host
# cat /etc/kubernetes/kubelet.conf|grep nodeStatusUpdateFrequency

    出力例

    Copy to Clipboard Toggle word wrap 
      “nodeStatusUpdateFrequency”: “10s”

これらの出力は、Worker Latency Profile のタイミング変数のセットを検証します。

第21章 ワークロードパーティショニング

ワークロードパーティショニングは、コンピュートノード CPU リソースを個別の CPU セットに分割します。主な目的は、指定されたコア上にプラットフォーム Pod を維持し、顧客のワークロードが実行されている CPU が中断されないようにすることです。

ワークロードパーティショニングを使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod が分離され、予約された CPU セットで実行されます。これにより、クラスターデプロイメント内の残りの CPU はそのまま残り、非プラットフォームワークロード専用に使用できるようになります。クラスター管理に必要な予約済み CPU の最小数は、4 つの CPU ハイパースレッド (HT) です。

ワークロードのパーティショニングを有効にし、CPU リソースを効果的に管理するという観点から、正しく設定されていないノードは、ノードアドミッション Webhook を介してクラスターに参加することはできません。ワークロードパーティショニング機能を有効にすると、コントロールプレーンとワーカーのマシン設定プールに、ノードが使用する設定が提供されます。これらのプールに新しいノードを追加すると、クラスターに参加する前にノードが正しく設定されていることが確認されます。

現在、プール内のすべてのノードにわたって正しい CPU アフィニティーが設定されるようにするには、ノードはマシン設定プールごとに均一な設定を持つ必要があります。承認後、クラスター内のノードは、management.workload.openshift.io/cores と呼ばれる新しいリソースタイプをサポートしていると認識し、CPU 容量を正確に報告します。ワークロードパーティショニングは、クラスターのインストール中に install-config.yaml ファイルに cpuPartitioningMode フィールドを追加することによってのみ有効にできます。

ワークロードの分割が有効になっている場合、スケジューラーは management.workload.openshift.io/cores リソースにより、デフォルトの cpuset だけでなく、ホストの cpushares 容量に基づいて Pod を適切に割り当てることができます。これにより、ワークロードパーティショニングシナリオでのリソースの割り当てがより正確になります。

ワークロードのパーティショニングにより、Pod の設定で指定された CPU 要求と制限が尊重されるようになります。OpenShift Container Platform 4.16 以降では、CPU パーティショニングを通じてプラットフォーム Pod に正確な CPU 使用率制限が設定されます。ワークロードパーティショニングでは、management.workload.openshift.io/cores のカスタムリソースタイプが使用されるため、Kubernetes による拡張リソースの要件により、リクエストと制限の値は同じになります。ただし、ワークロードパーティショニングによって変更されたアノテーションは、必要な制限を正しく反映します。

注記

拡張リソースはオーバーコミットできないため、コンテナー仕様にリクエストと制限の両方が存在する場合は、リクエストと制限が等しくなければなりません。

21.1. ワークロードパーティショニングの有効化

ワークロードパーティショニングでは、クラスター管理 Pod にアノテーションが付けられ、指定された CPU アフィニティーに正しくパーティション分割されます。これらの Pod は、Performance Profile の予約値によって指定された最小サイズの CPU 設定内で正常に動作します。プラットフォーム用に確保する CPU コアの数を計算する際には、ワークロードパーティショニングを利用する追加の Day 2 Operator を考慮する必要があります。

ワークロード分割は、標準の Kubernetes スケジューリング機能を使用して、ユーザーワークロードをプラットフォームワークロードから分離します。

注記

ワークロードパーティショニングを有効にできるのは、クラスターのインストール時のみです。インストール後にワークロードパーティショニングを無効にすることはできません。ただし、reserved CPU と isolated CPU の CPU 設定はインストール後に変更できます。

クラスター全体でワークロードパーティショニングを有効にするには、次の手順を使用します。

手順

  • install-config.yaml ファイルに、追加フィールド cpuPartitioningMode を追加し、それを AllNodes に設定します。

    Copy to Clipboard Toggle word wrap 
    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 です。

21.2. パフォーマンスプロファイルとワークロードパーティショニング

パフォーマンスプロファイルを適用すると、ワークロードパーティショニング機能を利用できるようになります。適切に設定されたパフォーマンスプロファイルは、isolated および reserved CPU を指定します。パフォーマンスプロファイルを作成するための推奨方法は、Performance Profile Creator (PPC) ツールを使用してパフォーマンスプロファイルを作成することです。

関連情報

21.3. パフォーマンスプロファイル設定のサンプル

Copy to Clipboard Toggle word wrap 
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ''
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false
表21.1 シングルノード OpenShift クラスターの PerformanceProfile CR オプション
PerformanceProfile CR フィールド説明

metadata.name

name が、関連する 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.workloadHints

workloadHints を使用して、各種ワークロードの最上位フラグのセットを定義します。この例では、クラスターが低レイテンシーかつ高パフォーマンスになるように設定されています。

関連情報

第22章 Node Observability Operator の使用

Node Observability Operator は、コンピュートノードのスクリプトから CRI-O および Kubelet プロファイリングまたはメトリクスを収集して保存します。

Node Observability Operator を使用すると、プロファイリングデータをクエリーして、CRI-O および Kubelet のパフォーマンス傾向を分析できるようになります。カスタムリソース定義の run フィールドを使用して、パフォーマンス関連の問題のデバッグと、ネットワークメトリクスの埋め込みスクリプトの実行をサポートします。CRI-O および Kubelet のプロファイリングまたはスクリプトを有効にするには、カスタムリソース定義で type フィールドを設定します。

重要

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

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

22.1. Node Observability Operator のワークフロー

次のワークフローは、Node Observability Operator を使用してプロファイリングデータをクエリーする方法の概要を示しています。

  1. Node Observability Operator を OpenShift Container Platform クラスターにインストールします。
  2. NodeObservability カスタムリソースを作成して、選択したワーカーノードで CRI-O プロファイリングを有効にします。
  3. プロファイリングクエリーを実行して、プロファイリングデータを生成します。

22.2. Node Observability Operator のインストール

Node Observability Operator は、デフォルトでは OpenShift Container Platform にインストールされていません。OpenShift Container Platform CLI または Web コンソールを使用して、Node Observability Operator をインストールできます。

22.2.1. CLI を使用した Node Observability Operator のインストール

OpenShift CLI(oc) を使用して、Node Observability Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 次のコマンドを実行して、Node Observability Operator が使用可能であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get packagemanifests -n openshift-marketplace node-observability-operator

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                            CATALOG                AGE
node-observability-operator     Red Hat Operators      9h

  2. 次のコマンドを実行して、node-observability-operator namespace を作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc new-project node-observability-operator

  3. OperatorGroup オブジェクト YAML ファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: node-observability-operator
  namespace: node-observability-operator
spec:
  targetNamespaces: []
EOF

  4. Subscription オブジェクトの YAML ファイルを作成して、namespace を Operator にサブスクライブします。

    Copy to Clipboard Toggle word wrap 
    cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: node-observability-operator
  namespace: node-observability-operator
spec:
  channel: alpha
  name: node-observability-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

検証

  1. 次のコマンドを実行して、インストールプラン名を表示します。

    Copy to Clipboard Toggle word wrap 
    $ oc -n node-observability-operator get sub node-observability-operator -o yaml | yq '.status.installplan.name'

    出力例

    Copy to Clipboard Toggle word wrap 
    install-dt54w

  2. 次のコマンドを実行して、インストールプランのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc -n node-observability-operator get ip <install_plan_name> -o yaml | yq '.status.phase'

    <install_plan_name> は、前のコマンドの出力から取得したインストール計画名です。

    出力例

    Copy to Clipboard Toggle word wrap 
    COMPLETE

  3. Node Observability Operator が稼働していることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get deploy -n node-observability-operator

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                            READY   UP-TO-DATE  AVAILABLE   AGE
node-observability-operator-controller-manager  1/1     1           1           40h

22.2.2. Web コンソールを使用した Node Observability Operator のインストール

Node Observability Operator は、OpenShift Container Platform コンソールからインストールできます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. 管理者のナビゲーションパネルで、Operators → OperatorHub をデプロイメントします。
  3. All items フィールドに Node Observability Operator と入力し、Node Observability Operator タイルを選択します。
  4. Install をクリックします。

  5. Install Operator ページで、次の設定を指定します。

    1. Update channel 領域で、alpha をクリックします。
    2. Installation mode 領域で、A specific namespace on the cluster をクリックします。
    3. Installed Namespace リストから、リストから node-observability-operator を選択します。
    4. Update approval 領域で、Automatic を選択します。
    5. Install をクリックします。

検証

  1. 管理者のナビゲーションパネルで、Operators → Installed Operators をデプロイメントします。
  2. Node Observability Operator が Operators リストにリストされていることを確認します。

22.3. Node Observability Operator を使用して CRI-O および Kubelet プロファイリングデータをリクエストする

CRI-O および Kubelet プロファイリングデータの収集に使用する、Node Observability カスタムリソースを作成します。

22.3.1. Node Observability カスタムリソースの作成

プロファイリングクエリーを実行する前に、NodeObservability カスタムリソース (CR) を作成して実行する必要があります。一致する NodeObservability CR を実行すると、必要なマシン設定およびマシン設定プール CR が作成され、nodeSelector に一致するワーカーノードで CRI-O プロファイリングを有効にします。

重要

ワーカーノードで CRI-O プロファイリングが有効になっていない場合、NodeObservabilityMachineConfig リソースが作成されます。NodeObservability CR で指定された nodeSelector に一致するワーカーノードが再起動します。完了するまでに 10 分以上かかる場合があります。

注記

Kubelet プロファイリングはデフォルトで有効になっています。

ノードの CRI-Ounix ソケットは、エージェント Pod にマウントされます。これにより、エージェントは CRI-O と通信して pprof 要求を実行できます。同様に、kubelet-serving-ca 証明書チェーンはエージェント Pod にマウントされ、エージェントとノードの kubelet エンドポイント間の安全な通信を可能にします。

前提条件

  • Node Observability Operator をインストールしました。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform CLI にログインします。

    Copy to Clipboard Toggle word wrap 
    $ oc login -u kubeadmin https://<HOSTNAME>:6443

  2. 次のコマンドを実行して、node-observability-operator namespace に切り替えます。

    Copy to Clipboard Toggle word wrap 
    $ oc project node-observability-operator

  3. 次のテキストを含む nodeobservability.yaml という名前の CR ファイルを作成します。

    Copy to Clipboard Toggle word wrap 
        apiVersion: nodeobservability.olm.openshift.io/v1alpha2
    kind: NodeObservability
    metadata:
      name: cluster
    1 
    
    spec:
      nodeSelector:
        kubernetes.io/hostname: <node_hostname>
    2 
    
      type: crio-kubelet
    1
    クラスターごとに NodeObservability CR が 1 つしかないため、名前を cluster として指定する必要があります。
    2
    Node Observability エージェントをデプロイする必要があるノードを指定します。

  4. NodeObservability CR を実行します。

    Copy to Clipboard Toggle word wrap 
    oc apply -f nodeobservability.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    nodeobservability.olm.openshift.io/cluster created

  5. 次のコマンドを実行して、NodeObservability CR のステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nob/cluster -o yaml | yq '.status.conditions'

    出力例

    Copy to Clipboard Toggle word wrap 
    conditions:
  conditions:
  - lastTransitionTime: "2022-07-05T07:33:54Z"
    message: 'DaemonSet node-observability-ds ready: true NodeObservabilityMachineConfig
      ready: true'
    reason: Ready
    status: "True"
    type: Ready

    NodeObservability CR の実行は、理由が Ready で、ステータスが True のときに完了します。

22.3.2. プロファイリングクエリーの実行

プロファイリングクエリーを実行するには、NodeObservabilityRun リソースを作成する必要があります。プロファイリングクエリーは、CRI-O および Kubelet プロファイリングデータを 30 秒間フェッチするブロッキング操作です。プロファイリングクエリーが完了したら、コンテナーファイルシステムの /run/node-observability ディレクトリー内のプロファイリングデータを取得する必要があります。データの有効期間は、emptyDir ボリュームを介してエージェント Pod にバインドされるため、エージェント Pod が running の状態にある間にプロファイリングデータにアクセスできます。

重要

一度にリクエストできるプロファイリングクエリーは 1 つだけです。

前提条件

  • Node Observability Operator をインストールしました。
  • NodeObservability カスタムリソース (CR) を作成しました。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 次のテキストを含む nodeobservabilityrun.yaml という名前の NodeObservabilityRun リソースファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: nodeobservability.olm.openshift.io/v1alpha2
kind: NodeObservabilityRun
metadata:
  name: nodeobservabilityrun
spec:
  nodeObservabilityRef:
    name: cluster

  2. NodeObservabilityRun リソースを実行して、プロファイリングクエリーをトリガーします。

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

  3. 次のコマンドを実行して、NodeObservabilityRun のステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodeobservabilityrun nodeobservabilityrun -o yaml  | yq '.status.conditions'

    出力例

    Copy to Clipboard Toggle word wrap 
    conditions:
- lastTransitionTime: "2022-07-07T14:57:34Z"
  message: Ready to start profiling
  reason: Ready
  status: "True"
  type: Ready
- lastTransitionTime: "2022-07-07T14:58:10Z"
  message: Profiling query done
  reason: Finished
  status: "True"
  type: Finished

    ステータスが True になり、タイプが Finished になると、プロファイリングクエリーは完了です。

  4. 次の bash スクリプトを実行して、コンテナーの /run/node-observability パスからプロファイリングデータを取得します。

    Copy to Clipboard Toggle word wrap 
    for a in $(oc get nodeobservabilityrun nodeobservabilityrun -o yaml | yq .status.agents[].name); do
  echo "agent ${a}"
  mkdir -p "/tmp/${a}"
  for p in $(oc exec "${a}" -c node-observability-agent -- bash -c "ls /run/node-observability/*.pprof"); do
    f="$(basename ${p})"
    echo "copying ${f} to /tmp/${a}/${f}"
    oc exec "${a}" -c node-observability-agent -- cat "${p}" > "/tmp/${a}/${f}"
  done
done

22.4. Node Observability Operator スクリプト

スクリプトを作成すると、現在の Node Observability Operator および Node Observability Agent を使用して、事前設定された bash スクリプトを実行できます。

これらのスクリプトは、CPU 負荷、メモリーの逼迫、ワーカーノードの問題などの主要なメトリクスを監視します。sar レポートとカスタムパフォーマンスメトリクスも収集します。

22.4.1. スクリプト用のノード監視カスタムリソースを作成する

スクリプトを実行する前に、NodeObservability カスタムリソース (CR) を作成して実行する必要があります。NodeObservability CR を実行すると、nodeSelector ラベルに一致するコンピュートノード上でエージェントがスクリプトモードで有効になります。

前提条件

  • Node Observability Operator をインストールしました。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform クラスターにログインします。

    Copy to Clipboard Toggle word wrap 
    $ oc login -u kubeadmin https://<host_name>:6443

  2. 次のコマンドを実行して、node-observability-operator namespace に切り替えます。

    Copy to Clipboard Toggle word wrap 
    $ oc project node-observability-operator

  3. 次の内容を含む nodeobservability.yaml という名前のファイルを作成します。

    Copy to Clipboard Toggle word wrap 
        apiVersion: nodeobservability.olm.openshift.io/v1alpha2
    kind: NodeObservability
    metadata:
      name: cluster
    1 
    
    spec:
      nodeSelector:
        kubernetes.io/hostname: <node_hostname>
    2 
    
      type: scripting
    3
    1
    クラスターごとに NodeObservability CR が 1 つしかないため、名前を cluster として指定する必要があります。
    2
    Node Observability エージェントをデプロイする必要があるノードを指定します。
    3
    エージェントをスクリプトモードでデプロイするには、タイプを scripting に設定する必要があります。

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

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

    出力例

    Copy to Clipboard Toggle word wrap 
    nodeobservability.olm.openshift.io/cluster created

  5. 次のコマンドを実行して、NodeObservability CR のステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nob/cluster -o yaml | yq '.status.conditions'

    出力例

    Copy to Clipboard Toggle word wrap 
    conditions:
  conditions:
  - lastTransitionTime: "2022-07-05T07:33:54Z"
    message: 'DaemonSet node-observability-ds ready: true NodeObservabilityScripting
      ready: true'
    reason: Ready
    status: "True"
    type: Ready

    NodeObservability CR の実行は、reason が Ready、status が "True". の場合に完了します。

22.4.2. Node Observability Operator スクリプトの設定

前提条件

  • Node Observability Operator をインストールしました。
  • NodeObservability カスタムリソース (CR) を作成しました。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 次の内容を含む、nodeobservabilityrun-script.yaml という名前のファイルを作成します。

    Copy to Clipboard Toggle word wrap 
    apiVersion: nodeobservability.olm.openshift.io/v1alpha2
kind: NodeObservabilityRun
metadata:
  name: nodeobservabilityrun-script
  namespace: node-observability-operator
spec:
  nodeObservabilityRef:
    name: cluster
    type: scripting
    重要

    次のスクリプトのみをリクエストできます。

    • metrics.sh
    • network-metrics.sh (monitor.sh を使用)

  2. 次のコマンドを使用して NodeObservabilityRun リソースを作成することで、スクリプトをトリガーします。

    Copy to Clipboard Toggle word wrap 
    $ oc apply -f nodeobservabilityrun-script.yaml

  3. 次のコマンドを実行して、NodeObservabilityRun スクリプトのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodeobservabilityrun nodeobservabilityrun-script -o yaml  | yq '.status.conditions'

    出力例

    Copy to Clipboard Toggle word wrap 
    Status:
  Agents:
    Ip:    10.128.2.252
    Name:  node-observability-agent-n2fpm
    Port:  8443
    Ip:    10.131.0.186
    Name:  node-observability-agent-wcc8p
    Port:  8443
  Conditions:
    Conditions:
      Last Transition Time:  2023-12-19T15:10:51Z
      Message:               Ready to start profiling
      Reason:                Ready
      Status:                True
      Type:                  Ready
      Last Transition Time:  2023-12-19T15:11:01Z
      Message:               Profiling query done
      Reason:                Finished
      Status:                True
      Type:                  Finished
  Finished Timestamp:        2023-12-19T15:11:01Z
  Start Timestamp:           2023-12-19T15:10:51Z

    Status が True、Type が Finished になると、スクリプトの作成は完了です。

  4. 次の bash スクリプトを実行して、コンテナーのルートパスからスクリプトデータを取得します。

    Copy to Clipboard Toggle word wrap 
    #!/bin/bash

RUN=$(oc get nodeobservabilityrun --no-headers | awk '{print $1}')

for a in $(oc get nodeobservabilityruns.nodeobservability.olm.openshift.io/${RUN} -o json | jq .status.agents[].name); do
  echo "agent ${a}"
  agent=$(echo ${a} | tr -d "\"\'\`")
  base_dir=$(oc exec "${agent}" -c node-observability-agent -- bash -c "ls -t | grep node-observability-agent" | head -1)
  echo "${base_dir}"
  mkdir -p "/tmp/${agent}"
  for p in $(oc exec "${agent}" -c node-observability-agent -- bash -c "ls ${base_dir}"); do
    f="/${base_dir}/${p}"
    echo "copying ${f} to /tmp/${agent}/${p}"
    oc exec "${agent}" -c node-observability-agent -- cat ${f} > "/tmp/${agent}/${p}"
  done
done

22.5. 関連情報

ワーカーメトリクスの収集方法の詳細は、Red Hat ナレッジベースの記事 を参照してください。

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.