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


OpenShift Container Platform 4.16

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

概要

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

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

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

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

注記

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

1.2. 通信事業者向けリファレンス設計仕様

Telco RAN DU 仕様

1.3. 計画、最適化、測定

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

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

Node Tuning Operator の使用

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

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

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

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

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

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

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

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

Node Observability Operator の使用

第3章 リファレンス設計仕様

3.1. 通信事業者向けコアおよび RAN DU リファレンス設計仕様

通信事業者コアリファレンスデザイン仕様 (RDS) では、コントロールプレーンや一部の集中型データプレーン機能を含む大規模な通信アプリケーションをサポートできるコモディティーハードウェア上で実行する OpenShift Container Platform 4.16 クラスターを説明します。

通信事業者の RAN RDS は、無線アクセスネットワーク (RAN) で 5G ワークロードをホストするために、コモディティーハードウェア上で実行するクラスターの設定を説明します。

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

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

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

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

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

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

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

注記

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

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

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

重要

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

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

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

    注記

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

3.2. 通信事業者向け RAN DU リファレンス設計仕様

3.2.1. 通信事業者向け RAN DU 4.16 参照デザインの概要

Telco RAN 分散ユニット (DU) 4.16 リファレンスデザインは、コモディティーハードウェア上で実行している OpenShift Container Platform 4.16 クラスターを設定して、通信事業者向け RAN DU ワークロードをホストします。通信事業者向け RAN DU プロファイルを実行するクラスターで信頼性が高く再現性のあるパフォーマンスを得るために、推奨され、テストされ、サポートされている設定をキャプチャーします。

3.2.1.1. デプロイメントアーキテクチャーの概要

集中管理された RHACM ハブクラスターから、管理対象クラスターに通信事業者向け RAN DU 4.16 参照設定を展開します。リファレンスデザイン仕様 (RDS) には、管理対象クラスターとハブクラスターコンポーネントの設定が含まれます。

図3.1 通信事業者向け RAN DU デプロイメントアーキテクチャーの概要

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

3.2.2. 通信事業者向け RAN DU 使用モデルの概要

次の情報を使用して、ハブクラスターと管理対象シングルノード OpenShift クラスターの通信事業者向け RAN DU ワークロード、クラスターリソース、およびハードウェア仕様を計画します。

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

DU ワーカーノードには、最大のパフォーマンスが得られるようにファームウェアが調整された、第 3 世代 Xeon (Ice Lake) 2.20 GHz 以上の CPU が必要です。

5G RAN DU ユーザーアプリケーションとワークロードは、次のベストプラクティスとアプリケーション制限に準拠する必要があります。

  • CNF ベストプラクティスガイド の最新バージョンに準拠したクラウドネイティブネットワーク機能 (CNF) を開発します。
  • 高性能ネットワークには SR-IOV を使用します。
  • exec プローブは控えめに使用し、他の適切なオプションが利用できない場合にのみ使用してください。

    • CNF が CPU ピンニングを使用する場合は、exec プローブを使用しないでください。httpGettcpSocket などの他のプローブ実装を使用します。
    • exec プローブを使用する必要がある場合は、exec プローブの頻度と量を制限します。exec プローブの最大数は 10 未満に維持し、頻度は 10 秒以上にする必要があります。
  • 絶対に実行可能な代替手段がない限り、exec プローブの使用は避けてください。
注記

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

3.2.2.2. 通信事業者向け RAN DU の代表的な参照アプリケーションワークロード特性

代表的な参照アプリケーションワークロードには、次の特性があります。

  • 管理および制御機能を含む vRAN アプリケーション用に最大 15 個の Pod と 30 個のコンテナーを備えています。
  • Pod ごとに最大 2 つの ConfigMap と 4 つの Secret CR を使用します。
  • 10 秒以上の頻度で最大 10 個の exec プローブを使用します。
  • kube-apiserver の増分アプリケーション負荷は、クラスタープラットフォーム使用量の 10% 未満です。

    注記

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

    query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
  • アプリケーションログはプラットフォームログコレクターにより収集されません
  • プライマリー CNI 上の総トラフィックは 1 MBps 未満です
3.2.2.3. 通信事業者向け RAN DU ワーカーノードクラスターリソース使用率

システム内で実行している Pod の最大数 (アプリケーションワークロードと OpenShift Container Platform Pod を含む) は 120 です。

リソース利用

OpenShift Container Platform のリソース使用率は、次のようなアプリケーションのワークロード特性を含む多くの要因によって異なります。

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

クラスターリソース要件は、次の条件で適用されます。

  • クラスターは、説明した代表的なアプリケーションワークロードを実行しています。
  • クラスターは、「通信事業者向け RAN DU ワーカーノードクラスターリソース使用率」で説明されている制約に従って管理されます。
  • RAN DU 使用モデル設定でオプションとして記載されているコンポーネントは適用されません。
重要

通信事業者向け RAN DU 参照デザインの範囲外の設定は、リソース使用率への影響と KPI 目標達成能力を判断するために、追加の分析を行う必要があります。要件に応じて、クラスターに関連情報を割り当てることが求められる場合があります。

3.2.2.4. ハブクラスター管理特性

推奨されるクラスター管理ソリューションは、Red Hat Advanced Cluster Management (RHACM) です。ハブクラスターで次の制限を設定します。

  • 準拠した評価間隔が少なくとも 10 分である最大 5 つの RHACM ポリシーを設定します。
  • ポリシーでは最大 10 個のマネージドクラスターテンプレートを使用します。可能な場合は、ハブ側のテンプレートを使用します。
  • policy-controller および observability-controller アドオンを除くすべての RHACM アドオンを無効にします。Observability をデフォルト設定に設定します。

    重要

    オプションのコンポーネントを設定したり、追加機能を有効にしたりすると、追加のリソースが使用され、システム全体のパフォーマンスが低下する可能性があります。

    詳細は、参照設計のデプロイメントコンポーネント を参照してください。

Expand
表3.1 参照アプリケーション負荷時の OpenShift プラットフォームのリソース使用率
メトリクスLimit注記

CPU の使用率

4000 mc 未満 - 2 コア (4 ハイパースレッド)

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

使用されているメモリー

16G 未満

 
3.2.2.5. 通信事業者向け RAN DU RDS コンポーネント

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

図3.2 通信事業者向け RAN DU 参照設計コンポーネント

通信事業者向け RAN DU コンポーネントスタックを説明する図。
注記

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

重要

ツリー外のドライバーはサポートされていません。

3.2.3. 通信事業者向け RAN DU 4.16 参照デザインコンポーネント

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

3.2.3.1. ホストファームウェアのチューニング
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

システムレベルのパフォーマンスを設定します。推奨設定は、低遅延と高パフォーマンスを実現するホストファームウェアの設定 を参照してください。

Ironic 検査が有効になっていると、ファームウェア設定値はハブクラスター上のクラスターごとの BareMetalHost CR から入手できます。クラスターのインストールに使用する SiteConfig CR の spec.clusters.nodes フィールドのラベルを使用して、Ironic 検査を有効にします。以下に例を示します。

nodes:
  - hostName: "example-node1.example.com"
    ironicInspect: "enabled"
注記

通信事業者向け RAN DU 参照 SiteConfig では、ironicInspect フィールドはデフォルトで有効になりません。

制限と要件
  • ハイパースレッディングを有効にする必要がある
エンジニアリングに関する考慮事項
  • パフォーマンスを最大限に高めるためにすべての設定を調整する

    注記

    必要に応じて、パフォーマンスを犠牲にして電力を節約するためにファームウェアの選択を調整できます。

3.2.3.2. Node Tuning Operator
このリリースの新機能
  • このリリースでは、Node Tuning Operator は、予約済みおよび分離されたコア CPU の PerformanceProfile で CPU 周波数の設定をサポートします。これは、特定の周波数を定義するために使用できるオプションの機能です。この機能を使用して、Intel ハードウェアの intel_pstate CPUFreq ドライバーを有効にし、特定の周波数を設定します。FlexRAN のようなアプリケーションの周波数については、Intel の推奨事項に従う必要があります。このようなアプリケーションでは、デフォルトの CPU 周波数をデフォルトの実行周波数よりも低い値に設定する必要があります。
  • 以前は、RAN DU プロファイルの場合、PerformanceProfilerealTime ワークロードヒントを true に設定すると、常に intel_pstate が無効になりました。このリリースでは、Node Tuning Operator は TuneD を使用して基盤となる Intel ハードウェアを検出し、プロセッサーの世代に基づいて intel_pstate カーネルパラメーターを適切に設定します。
  • このリリースでは、パフォーマンスプロファイルを持つ OpenShift Container Platform デプロイメントでは、基盤となるリソース管理レイヤーとして cgroups v2 がデフォルトで使用されるようになりました。この変更に対応していないワークロードを実行する場合でも、古い cgroups v1 メカニズムに戻すことができます。
説明

パフォーマンスプロファイルを作成して、クラスターのパフォーマンスを調整します。パフォーマンスプロファイルで設定する設定には次のものが含まれます。

  • リアルタイムカーネルまたは非リアルタイムカーネルを選択します。
  • 予約済みまたは分離された cpuset にコアを割り当てます。管理ワークロードパーティションに割り当てられた OpenShift Container Platform プロセスは、予約セットに固定されます。
  • kubelet 機能 (CPU マネージャー、トポロジーマネージャー、メモリーマネージャー) を有効にします。
  • Huge Page の設定
  • 追加のカーネル引数を設定します。
  • コアごとの電力調整と最大 CPU 周波数を設定します。
  • 予約済みおよび分離されたコア周波数チューニング。
制限と要件

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

  • 予約済みおよび分離されたコアを選択し、最大のパフォーマンスが得られるようにファームウェアが調整された Intel 第 3 世代 Xeon (Ice Lake) 2.20 GHz CPU 以上に少なくとも 4 つのハイパースレッド (2 つのコアに相当) を割り当てるようにします。
  • 予約済みの cpuset を設定して、含まれる各コアの両方のハイパースレッドシブリングを含めます。予約されていないコアは、ワークロードのスケジュールに割り当て可能な CPU として使用できます。ハイパースレッドシブリングが予約済みコアと分離コアに分割されていないことを確認します。
  • 予約済みおよび分離された CPU として設定した内容に基づいて、すべてのコアのすべてのスレッドを含めるように予約済みおよび分離された CPU を設定します。
  • 各 NUMA ノードのコア 0 を予約済み CPU セットに含めるように設定します。
  • huge page のサイズを 1G に設定します。
注記

管理パーティションにワークロードをさらに追加しないでください。OpenShift 管理プラットフォームの一部である Pod のみを管理パーティションにアノテーション付けする必要があります。

エンジニアリングに関する考慮事項
  • パフォーマンス要件を満たすには、RT カーネルを使用する必要があります。

    注記

    必要に応じて、非 RT カーネルを使用できます。

  • 設定する huge page の数は、アプリケーションのワークロード要件によって異なります。このパラメーターの変動は予想され、許容されます。
  • 選択されたハードウェアとシステムで使用されている追加コンポーネントに基づいて、予約済みおよび分離された CPU セットの設定に変化が生じることが予想されます。変動は指定された制限を満たす必要があります。
  • IRQ アフィニティーをサポートしていないハードウェアは、分離された CPU に影響します。CPU 全体の QoS が保証された Pod が割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートする必要があります。詳細は、IRQ アフィニティー設定のサポートについて を参照してください。
重要

cgroup v1 は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。

3.2.3.3. PTP Operator
このリリースの新機能
  • デュアル Intel E810 Westport Channel NIC のグランドマスタークロック (T-GM) として linuxptp サービスを設定する機能が、一般に利用可能になりました。
  • linuxptp サービス ptp4l および phc2sys を、デュアル PTP 境界クロック (T-BC) の高可用性 (HA) システムクロックとして設定できます。
説明

クラスターノードでの PTP のサポートと設定の詳細は、PTP タイミング を参照してください。DU ノードは次のモードで実行できます。

  • グランドマスタークロックまたは境界クロック (T-BC) に同期された通常のクロック (OC) として
  • シングルまたはデュアルカード E810 Westport Channel NIC をサポートする、GPS から同期されるグランドマスタークロックとして
  • E810 Westport Channel NIC をサポートするデュアル境界クロック (NIC ごとに 1 つ)
  • 異なる NIC 上に複数の時間ソースがある場合に、システムクロックの高可用性を実現します。
  • オプション: 無線ユニット (RU) の境界クロックとして

グランドマスタークロックのイベントとメトリクスは、4.14 通信事業者向け RAN DU RDS で追加されたテクニカルプレビュー機能です。詳細は、PTP ハードウェア高速イベント通知フレームワークの使用 を参照してください。

DU アプリケーションが実行しているノードで発生する PTP イベントにアプリケーションをサブスクライブできます。

制限と要件
  • デュアル NIC および HA の場合、境界クロックは 2 つに制限されます。
  • T-GM の WPC カード設定は 2 枚までに制限される
エンジニアリングに関する考慮事項
  • 通常のクロック、境界クロック、グランドマスタークロック、または PTP-HA の設定が提供されます。
  • PTP 高速イベント通知は ConfigMap CR を使用して PTP イベントサブスクリプションを保存します。
  • GPS タイミングを備えた PTP グランドマスタークロックには、Intel E810-XXV-4T Westport Channel NIC を使用します (最小ファームウェアバージョン 4.40)。
3.2.3.4. SR-IOV Operator
このリリースの新機能
  • このリリースでは、SR-IOV Network Operator を使用して QinQ (802.1ad および 802.1q) タグ付けを設定できます。QinQ タグ付けは、内部 VLAN タグと外部 VLAN タグの両方の使用を可能にすることで、効率的なトラフィック管理を実現します。外部 VLAN タグ付けはハードウェアアクセラレーションされており、ネットワークパフォーマンスが向上します。この更新は SR-IOV Network Operator 自体を超えて拡張されます。nmstate を使用して外部 VLAN タグを設定することで、外部のマネージド VF 上で QinQ を設定できるようになりました。QinQ のサポートは NIC によって異なります。特定の NIC モデルの既知の制限事項の包括的なリストについては、関連情報 セクションの SR-IOV 対応ワークロードに対する QinQ サポートの設定 を参照してください。
  • このリリースでは、ネットワークポリシーの更新中にノードを並行してドレインするように SR-IOV Network Operator を設定できるため、セットアッププロセスが大幅に高速化されます。これは、特に以前は完了までに数時間、場合によっては数日かかっていた大規模なクラスターのデプロイメントにおいて、大幅な時間の節約につながります。
説明
SR-IOV Operator は、SR-IOV CNI およびデバイスプラグインをプロビジョニングおよび設定します。netdevice (カーネル VF) と vfio (DPDK) デバイスの両方がサポートされています。
制限と要件
  • OpenShift Container Platform 対応デバイスを使用する
  • BIOS での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウン検出が必要な場合は、プロトコルレベルでこれを設定する必要があります。
  • マルチネットワークポリシーは、netdevice ドライバータイプにのみ適用できます。マルチネットワークポリシーには iptables ツールが必要ですが、このツールでは vfio ドライバータイプを管理できません。
エンジニアリングに関する考慮事項
  • vfio ドライバータイプの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーションで追加のセカンダリーネットワークを有効にするために使用されます。
  • SriovNetwork および SriovNetworkNodePolicy カスタムリソース (CR) の設定と数は、顧客によって異なることが予想されます。
  • IOMMU カーネルのコマンドライン設定は、インストール時に MachineConfig CR で適用されます。これにより、SriovOperator CR がノードを追加するときにノードの再起動が発生しなくなります。
  • 並列でノードをドレインするための SR-IOV サポートは、シングルノードの OpenShift クラスターには適用されません。
  • デプロイメントから SriovOperatorConfig CR を除外すると、CR は自動的に作成されません。
  • ワークロードを特定のノードにピン留めまたは制限するシナリオでは、SR-IOV 並列ノードドレイン機能によって Pod の再スケジュールは行われません。このようなシナリオでは、SR-IOV Operator は並列ノードドレイン機能を無効にします。
3.2.3.5. ロギング
このリリースの新機能
  • Cluster Logging Operator 6.0 はこのリリースの新機能です。既存の実装を更新して、新しいバージョンの API に適応させます。ポリシーを使用して、古い Operator アーティファクトを削除する必要があります。詳細は、関連情報 を参照してください。
説明
ロギングを使用して、リモート分析のためにファーエッジのノードからログを収集します。推奨されるログコレクターは Vector です。
エンジニアリングに関する考慮事項
  • たとえば、インフラストラクチャー以外のログや、アプリケーションワークロードからの監査ログを処理するには、ロギングレートの増加に応じて CPU とネットワーク帯域幅の追加が必要になります。
  • OpenShift Container Platform 4.14 以降では、Vector が参照ログコレクターになります。

    注記

    RAN 使用モデルでの fluentd の使用は非推奨です。

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

    • SecureBoot がサポートされている
    • PFvfio ドライバーでは、Pod に挿入される vfio-token を使用する必要があります。Pod 内のアプリケーションは、EAL パラメーター --vfio-vf-token を使用して VF トークンを DPDK に渡すことができます。
エンジニアリングに関する考慮事項
  • SRIOV-FEC Operator は、isolated CPU セットの CPU コアを使用します。
  • たとえば、検証ポリシーを拡張することによって、アプリケーションデプロイメントの事前チェックの一部として FEC の準備を検証できます。
3.2.3.7. Local Storage Operator
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Local Storage Operator を使用して、アプリケーションで PVC リソースとして使用できる永続ボリュームを作成できます。作成する PV リソースの数とタイプは、要件によって異なります。
エンジニアリングに関する考慮事項
  • PV を作成する前に、PV CR のバッキングストレージを作成します。これは、パーティション、ローカルボリューム、LVM ボリューム、または完全なディスクにすることができます。
  • ディスクとパーティションの正しい割り当てを確認するには、各デバイスへのアクセスに使用されるハードウェアパス別に LocalVolume CR 内のデバイスリストを参照してください。論理名 (例: /dev/sda) は、ノードの再起動後も一貫性が保たれるとは限りません。

    詳細は、デバイス識別子に関する RHEL 9 のドキュメント を参照してください。

3.2.3.8. LVMS Operator
このリリースの新機能
  • このリリースではリファレンスデザインの更新はありません。
注記

LVMS Operator はオプションのコンポーネントです。

LVMS Operator をストレージソリューションとして使用すると、Local Storage Operator が置き換えられ、必要な CPU がプラットフォームのオーバーヘッドとして管理パーティションに割り当てられます。参照設定には、これらのストレージソリューションのいずれか 1 つを含める必要がありますが、両方を含めることはできません。

説明

LVMS Operator は、ブロックおよびファイルストレージの動的なプロビジョニングを提供します。LVMS Operator は、アプリケーションが PVC リソースとして使用できるローカルデバイスから論理ボリュームを作成します。ボリューム拡張やスナップショットも可能です。

次の設定例では、インストールディスクを除くノード上の使用可能なすべてのディスクを活用する vg1 ボリュームグループを作成します。

StorageLVMCluster.yaml

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: storage-lvmcluster
  namespace: openshift-storage
  annotations:
    ran.openshift.io/ztp-deploy-wave: "10"
spec:
  storage:
    deviceClasses:
    - name: vg1
      thinPoolConfig:
        name: thin-pool-1
        sizePercent: 90
        overprovisionRatio: 10

制限と要件
  • シングルノードの OpenShift クラスターでは、永続ストレージは LVMS またはローカルストレージのいずれかによって提供される必要があり、両方によって提供される必要はありません。
エンジニアリングに関する考慮事項
  • ストレージ要件を満たす十分なディスクまたはパーティションが利用可能であることを確認します。
3.2.3.9. ワークロードパーティショニング
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

ワークロードパーティショニングは、DU プロファイルの一部である OpenShift プラットフォームと Day 2 Operator Pod を予約済み cpuset に固定し、予約済み CPU をノードアカウンティングから削除します。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。

OpenShift Container Platform 4.14 では、ワークロードパーティショニングを有効にして設定する方法が変更されました。

4.14 以降
  • インストールパラメーターを設定してパーティションを設定します。

    cpuPartitioningMode: AllNodes
  • PerformanceProfile CR で予約された CPU セットを使用して管理パーティションコアを設定する
4.13 以前
  • インストール時に追加の MachineConfiguration CR を適用してパーティションを設定する
制限と要件
  • Pod を管理パーティションに適用できるようにするには、NamespacePod CR にアノテーションを付ける必要がある
  • CPU 制限のある Pod をパーティションに割り当てることはできません。これは、ミューテーションによって Pod の QoS が変わる可能性があるためです。
  • 管理パーティションに割り当てることができる CPU の最小数の詳細は、ノードチューニング Operator を参照してください。
エンジニアリングに関する考慮事項
  • ワークロードパーティショニングでは、すべての管理 Pod を予約済みコアにピン固定します。オペレーティングシステム、管理 Pod、およびワークロードの開始、ノードの再起動、またはその他のシステムイベントの発生時に発生する CPU 使用率の予想される急増を考慮して、予約セットに十分な数のコアを割り当てる必要があります。
3.2.3.10. クラスターのチューニング
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
インストール前に有効または無効にするオプションのコンポーネントの完全なリストについては、クラスター機能 セクションを参照してください。
制限と要件
  • インストーラーによるプロビジョニングのインストール方法では、クラスター機能は使用できません。
  • すべてのプラットフォームチューニング設定を適用する必要があります。次の表に、必要なプラットフォームチューニング設定を示します。

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

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

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

    • Marketplace および Node Tuning 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 を適用する必要があります。

エンジニアリングに関する考慮事項
  • このリリースでは、OpenShift Container Platform デプロイメントはデフォルトで Control Groups バージョン 2 (cgroup v2) を使用します。その結果、クラスター内のパフォーマンスプロファイルは、基盤となるリソース管理レイヤーに cgroups v2 を使用します。クラスター上で実行しているワークロードに cgroups v1 が必要な場合は、cgroups v1 を使用するようにノードを設定できます。この設定は、初期クラスターデプロイメントの一部として行うことができます。
3.2.3.11. マシン設定
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
制限と要件
  • CRI-O ワイプ無効化 MachineConfig は、定義されたメンテナンスウィンドウ内のスケジュールされたメンテナンス時以外は、ディスク上のイメージが静的であると想定します。イメージが静的であることを保証するには、Pod の imagePullPolicy フィールドを Always に設定しないでください。

    Expand
    表3.3 マシン設定オプション
    機能説明

    コンテナーランタイム

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

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

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

    SCTP

    オプション設定 (デフォルトで有効): SCTP を有効にします。SCTP は RAN アプリケーションで必要ですが、RHCOS ではデフォルトで無効になっています。

    kdump

    オプション設定 (デフォルトで有効): カーネルパニックが発生したときに kdump がデバッグ情報をキャプチャーできるようにします。

    CRI-O ワイプ無効化

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

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

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

    RCU 通常の systemd サービス

    システムが完全に起動した後に rcu_normal を設定します。

    ワンショット時間同期

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

3.2.3.12. Lifecycle Agent
このリリースの新機能
  • Lifecycle Agent を使用して、シングルノードの OpenShift クラスターのイメージベースのアップグレードを有効にします。
説明
Lifecycle Agent は、シングルノードの OpenShift クラスターにローカルのライフサイクル管理サービスを提供します。
制限と要件
  • Lifecycle Agent は、マルチノードクラスターまたは追加のワーカーを持つシングルノードの OpenShift クラスターには適用されません。
  • 永続ボリュームが必要です。
3.2.3.13. 参照設計のデプロイメントコンポーネント

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

3.2.3.13.1. Red Hat Advanced Cluster Management (RHACM)
このリリースの新機能
  • PolicyGenerator リソースと Red Hat Advanced Cluster Management (RHACM) を使用して、GitOps ZTP でマネージドクラスターのポリシーをデプロイできるようになりました。これはテクノロジープレビューの機能です。
説明

RHACM は、デプロイされたクラスターに対して、Multi Cluster Engine (MCE) のインストールと継続的なライフサイクル管理機能を提供します。Policy CR を使用して設定とアップグレードを宣言的に指定し、Topology Aware Lifecycle Manager が管理する RHACM ポリシーコントローラーを使用してクラスターにポリシーを適用します。

  • GitOps Zero Touch Provisioning (ZTP) は、RHACM の MCE 機能を使用します
  • 設定、アップグレード、クラスターステータスは RHACM ポリシーコントローラーで管理されます。

インストール中に、RHACM は SiteConfig カスタムリソース (CR) で設定されたとおりに個々のノードにラベルを適用できます。

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

TALM は、ハブクラスター上でのみ実行し、変更 (クラスターおよび Operator のアップグレード、設定などを含む) がネットワークに展開される方法を管理するための Operator です。TALM は次のことを行います。

  • Policy CR を使用して、ユーザーが設定可能なバッチでクラスターのフリートに更新を段階的に適用します。
  • クラスターごとに ztp-done ラベルまたはその他のユーザー設定可能なラベルを追加します。
シングルノード OpenShift クラスターの事前キャッシュ

TALM は、アップグレードを開始する前に、OpenShift Container Platform、OLM Operator、および追加のユーザーイメージをシングルノードの OpenShift クラスターに事前キャッシュするオプションをサポートします。

  • オプションの事前キャッシュ設定を指定するために、PreCachingConfig カスタムリソースを使用できます。以下に例を示します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: PreCachingConfig
    metadata:
      name: example-config
      namespace: example-ns
    spec:
      additionalImages:
        - quay.io/foobar/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e
        - quay.io/foobar/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adf
        - quay.io/foobar/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfs
      spaceRequired: 45 GiB 
    1
    
      overrides:
        preCacheImage: quay.io/test_images/pre-cache:latest
        platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e
      operatorsIndexes:
        - registry.example.com:5000/custom-redhat-operators:1.0.0
      operatorsPackagesAndChannels:
        - local-storage-operator: stable
        - ptp-operator: stable
        - sriov-network-operator: stable
      excludePrecachePatterns: 
    2
    
        - aws
        - vsphere
    1 1
    設定可能な space-required パラメーターにより、事前キャッシュの前後のストレージスペースを検証できます。
    2
    設定可能なフィルタリングにより、未使用のイメージを除外できます
制限と要件
  • TALM は 400 のバッチでの同時クラスターデプロイメントをサポートします
  • 事前キャッシュおよびバックアップ機能は、シングルノードの OpenShift クラスターのみを対象としています。
エンジニアリングに関する考慮事項
  • PreCachingConfig CR はオプションであり、プラットフォーム関連 (OpenShift および OLM Operator) イメージを事前キャッシュするだけの場合は作成する必要はありません。ClusterGroupUpgrade CR で参照する前に、PreCachingConfig CR を適用する必要があります。
3.2.3.13.3. GitOps および GitOps ZTP プラグイン
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

GitOps および GitOps ZTP プラグインは、クラスターのデプロイメントと設定を管理するための GitOps ベースのインフラストラクチャーを提供します。クラスターの定義と設定は、Git で宣言的な状態として維持されます。ZTP プラグインは、SiteConfig CR からインストール CR を生成することと、PolicyGenTemplate CR に基づいてポリシーに設定 CR を自動的にラップすることをサポートします。

ベースライン参照設定 CR を使用して、マネージドクラスターに OpenShift Container Platform の複数のバージョンをデプロイおよび管理できます。ベースライン CR と並行してカスタム CR を使用することもできます。

制限
  • ArgoCD アプリケーションごとに 300 個の SiteConfig CR。複数のアプリケーションを使用することで、単一のハブクラスターでサポートされるクラスターの最大数を実現できます。
  • Git の /source-crs フォルダー内のコンテンツは、GitOps ZTP プラグインコンテナーで提供されるコンテンツを上書きします。検索パスでは Git が優先されます。
  • kustomization.yaml ファイルと同じディレクトリーに /source-crs フォルダーを追加します。このフォルダーには、ジェネレーターとして PolicyGenTemplate が含まれています。

    注記

    このコンテキストでは、/source-crs ディレクトリーの代替の場所はサポートされていません。

エンジニアリングに関する考慮事項
  • コンテンツを更新するときに混乱や意図しないファイルの上書きを避けるため、/source-crs フォルダー内のユーザー指定の CR と Git 内の追加マニフェストには、一意で区別できる名前を使用します。
  • SiteConfig CR では、複数の追加マニフェストパスが許可されます。複数のディレクトリーパスで同じ名前のファイルが見つかった場合は、最後に見つかったファイルが優先されます。これにより、バージョン固有の Day 0 マニフェスト (追加マニフェスト) の完全なセットを Git に配置し、SiteConfig CR から参照できるようになります。この機能を使用すると、複数の OpenShift Container Platform バージョンをマネージドクラスターに同時にデプロイできます。
  • SiteConfig CR の extraManifestPath フィールドは、OpenShift Container Platform 4.15 以降では非推奨です。代わりに新しい extraManifests.searchPaths フィールドを使用してください。
3.2.3.13.4. Agent-based Installer
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

Agent-based Installer (ABI) は、集中型インフラストラクチャーなしでインストール機能を提供します。インストールプログラムは、サーバーにマウントする ISO イメージを作成します。サーバーが起動すると、OpenShift Container Platform と提供された追加のマニフェストがインストールされます。

注記

ABI を使用して、ハブクラスターなしで OpenShift Container Platform クラスターをインストールすることもできます。このように ABI を使用する場合でも、イメージレジストリーは必要です。

Agent-based Installer (ABI) はオプションのコンポーネントです。

制限と要件
  • インストール時に、追加のマニフェストの限定されたセットを提供できます。
  • RAN DU ユースケースに必要な MachineConfiguration CR を含める必要があります。
エンジニアリングに関する考慮事項
  • ABI は、ベースラインの OpenShift Container Platform インストールを提供します。
  • インストール後に、Day 2 Operator と残りの RAN DU ユースケース設定をインストールします。

3.2.4. 通信事業者向け RAN 分散ユニット (DU) 参照設定 CR

次のカスタムリソース (CR) を使用して、通信事業者向け RAN DU プロファイルを使用して OpenShift Container Platform クラスターを設定およびデプロイします。一部の CR は、要件に応じてオプションになります。変更できる CR フィールドは、CR 内で YAML コメントによってアノテーションが付けられます。

注記

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

3.2.4.1. Day 2 Operator 参照 CR
Expand
表3.4 Day 2 の Operator CR
コンポーネント参照 CR任意このリリースの新機能

クラスターロギング

ClusterLogForwarder.yaml

いいえ

いいえ

クラスターロギング

ClusterLogging.yaml

いいえ

いいえ

クラスターロギング

ClusterLogNS.yaml

いいえ

いいえ

クラスターロギング

ClusterLogOperGroup.yaml

いいえ

いいえ

クラスターロギング

ClusterLogSubscription.yaml

いいえ

いいえ

Lifecycle Agent

ImageBasedUpgrade.yaml

はい

はい

Lifecycle Agent

LcaSubscription.yaml

はい

はい

Lifecycle Agent

LcaSubscriptionNS.yaml

はい

はい

Lifecycle Agent

LcaSubscriptionOperGroup.yaml

はい

はい

Local Storage Operator

StorageClass.yaml

はい

いいえ

Local Storage Operator

StorageLV.yaml

はい

いいえ

Local Storage Operator

StorageNS.yaml

はい

いいえ

Local Storage Operator

StorageOperGroup.yaml

はい

いいえ

Local Storage Operator

StorageSubscription.yaml

はい

いいえ

LVM Storage

LVMOperatorStatus.yaml

いいえ

はい

LVM Storage

StorageLVMCluster.yaml

いいえ

はい

LVM Storage

StorageLVMSubscription.yaml

いいえ

はい

LVM Storage

StorageLVMSubscriptionNS.yaml

いいえ

はい

LVM Storage

StorageLVMSubscriptionOperGroup.yaml

いいえ

はい

Node Tuning Operator

PerformanceProfile.yaml

いいえ

いいえ

Node Tuning Operator

TunedPerformancePatch.yaml

いいえ

いいえ

PTP 高速イベント通知

PtpConfigBoundaryForEvent.yaml

はい

はい

PTP 高速イベント通知

PtpConfigForHAForEvent.yaml

はい

はい

PTP 高速イベント通知

PtpConfigMasterForEvent.yaml

はい

はい

PTP 高速イベント通知

PtpConfigSlaveForEvent.yaml

はい

はい

PTP 高速イベント通知

PtpOperatorConfigForEvent.yaml

はい

いいえ

PTP Operator

PtpConfigBoundary.yaml

いいえ

いいえ

PTP Operator

PtpConfigDualCardGmWpc.yaml

いいえ

いいえ

PTP Operator

PtpConfigThreeCardGmWpc.yaml

いいえ

いいえ

PTP Operator

PtpConfigForHA.yaml

いいえ

はい

PTP Operator

PtpConfigGmWpc.yaml

いいえ

いいえ

PTP Operator

PtpConfigSlave.yaml

いいえ

いいえ

PTP Operator

PtpOperatorConfig.yaml

いいえ

いいえ

PTP Operator

PtpSubscription.yaml

いいえ

いいえ

PTP Operator

PtpSubscriptionNS.yaml

いいえ

いいえ

PTP Operator

PtpSubscriptionOperGroup.yaml

いいえ

いいえ

SR-IOV FEC Operator

AcceleratorsNS.yaml

はい

いいえ

SR-IOV FEC Operator

AcceleratorsOperGroup.yaml

はい

いいえ

SR-IOV FEC Operator

AcceleratorsSubscription.yaml

はい

いいえ

SR-IOV FEC Operator

SriovFecClusterConfig.yaml

はい

いいえ

SR-IOV Operator

SriovNetwork.yaml

いいえ

いいえ

SR-IOV Operator

SriovNetworkNodePolicy.yaml

いいえ

いいえ

SR-IOV Operator

SriovOperatorConfig.yaml

いいえ

いいえ

SR-IOV Operator

SriovOperatorConfigForSNO.yaml

いいえ

はい

SR-IOV Operator

SriovSubscription.yaml

いいえ

いいえ

SR-IOV Operator

SriovSubscriptionNS.yaml

いいえ

いいえ

SR-IOV Operator

SriovSubscriptionOperGroup.yaml

いいえ

いいえ

3.2.4.2. クラスターチューニング参照 CR
Expand
表3.5 クラスターチューニング CR
コンポーネント参照 CR任意このリリースの新機能

クラスター機能

example-sno.yaml

いいえ

いいえ

コンソール Operator 無効化

ConsoleOperatorDisable.yaml

いいえ

いいえ

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

DisableSnoNetworkDiag.yaml

いいえ

いいえ

モニタリング設定

ReduceMonitoringFootprint.yaml

いいえ

いいえ

OperatorHub

09-openshift-marketplace-ns.yaml

いいえ

いいえ

OperatorHub

DefaultCatsrc.yaml

いいえ

いいえ

OperatorHub

DisableOLMPprof.yaml

いいえ

いいえ

OperatorHub

DisconnectedICSP.yaml

いいえ

いいえ

OperatorHub

OperatorHub.yaml

はい

いいえ

3.2.4.3. マシン設定のリファレンス CR
Expand
表3.6 マシン設定の CR
コンポーネント参照 CR任意このリリースの新機能

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

enable-crun-master.yaml

いいえ

いいえ

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

enable-crun-worker.yaml

いいえ

いいえ

CRI-O ワイプを無効にする

99-crio-disable-wipe-master.yaml

いいえ

いいえ

CRI-O ワイプを無効にする

99-crio-disable-wipe-worker.yaml

いいえ

いいえ

kdump の有効化

06-kdump-master.yaml

いいえ

いいえ

kdump の有効化

06-kdump-worker.yaml

いいえ

いいえ

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

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

いいえ

いいえ

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

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

いいえ

いいえ

ワンショット時間同期

99-sync-time-once-master.yaml

いいえ

いいえ

ワンショット時間同期

99-sync-time-once-worker.yaml

いいえ

いいえ

SCTP

03-sctp-machine-config-master.yaml

いいえ

いいえ

SCTP

03-sctp-machine-config-worker.yaml

いいえ

いいえ

RCU を通常に設定

08-set-rcu-normal-master.yaml

いいえ

いいえ

RCU を通常に設定

08-set-rcu-normal-worker.yaml

いいえ

いいえ

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

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

いいえ

はい

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

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

いいえ

いいえ

3.2.4.4. YAML リファレンス

以下は、通信事業者向け RAN DU 4.16 参照設定を構成するすべてのカスタムリソース (CR) の完全な参照です。

3.2.4.4.1. Day 2 Operator 参照 YAML

ClusterLogForwarder.yaml

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
#  outputs: $outputs
#  pipelines: $pipelines

#apiVersion: "logging.openshift.io/v1"
#kind: ClusterLogForwarder
#metadata:
#  name: instance
#  namespace: openshift-logging
#spec:
#  outputs:
#    - type: "kafka"
#      name: kafka-open
#      url: tcp://10.46.55.190:9092/test
#  pipelines:
#  - inputRefs:
#    - audit
#    - infrastructure
#    labels:
#      label1: test1
#      label2: test2
#      label3: test3
#      label4: test4
#    name: all-to-default
#    outputRefs: 
#    - kafka-open

ClusterLogging.yaml

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
  managementState: "Managed"
  collection:
    type: "vector"

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  targetNamespaces:
    - openshift-logging

ClusterLogSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

ImageBasedUpgrade.yaml

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle
  # When setting `stage: Prep`, remember to add the seed image reference object below.
  # seedImageRef:
  #   image: $image
  #   version: $version

LcaSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: lifecycle-agent
  namespace: openshift-lifecycle-agent
  annotations: {}
spec:
  channel: "stable"
  name: lifecycle-agent
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

LcaSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-lifecycle-agent
  annotations:
    workload.openshift.io/allowed: management
  labels:
    kubernetes.io/metadata.name: openshift-lifecycle-agent

LcaSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: lifecycle-agent
  namespace: openshift-lifecycle-agent
  annotations: {}
spec:
  targetNamespaces:
    - openshift-lifecycle-agent

StorageClass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations: {}
  name: example-storage-class
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete

StorageLV.yaml

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "local-disks"
  namespace: "openshift-local-storage"
  annotations: {}
spec:
  logLevel: Normal
  managementState: Managed
  storageClassDevices:
    # The list of storage classes and associated devicePaths need to be specified like this example:
    - storageClassName: "example-storage-class"
      volumeMode: Filesystem
      fsType: xfs
      # The below must be adjusted to the hardware.
      # For stability and reliability, it's recommended to use persistent
      # naming conventions for devicePaths, such as /dev/disk/by-path.
      devicePaths:
        - /dev/disk/by-path/pci-0000:05:00.0-nvme-1
#---
## How to verify
## 1. Create a PVC
# apiVersion: v1
# kind: PersistentVolumeClaim
# metadata:
#   name: local-pvc-name 
# spec:
#   accessModes:
#   - ReadWriteOnce
#   volumeMode: Filesystem 
#   resources:
#     requests:
#       storage: 100Gi 
#   storageClassName: example-storage-class
#---
## 2. Create a pod that mounts it
# apiVersion: v1
# kind: Pod
# metadata:
#   labels:
#     run: busybox
#   name: busybox
# spec:
#   containers:
#   - image: quay.io/quay/busybox:latest
#     name: busybox
#     resources: {}
#     command: ["/bin/sh", "-c", "sleep infinity"]
#     volumeMounts:
#     - name: local-pvc 
#       mountPath: /data
#   volumes:
#   - name: local-pvc
#     persistentVolumeClaim:
#       claimName: local-pvc-name
#   dnsPolicy: ClusterFirst
#   restartPolicy: Always
## 3. Run the pod on the cluster and verify the size and access of the `/data` mount

StorageNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-local-storage
  annotations:
    workload.openshift.io/allowed: management

StorageOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-local-storage
  namespace: openshift-local-storage
  annotations: {}
spec:
  targetNamespaces:
    - openshift-local-storage

StorageSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: local-storage-operator
  namespace: openshift-local-storage
  annotations: {}
spec:
  channel: "stable"
  name: local-storage-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

LVMOperatorStatus.yaml

# This CR verifies the installation/upgrade of the Sriov Network Operator
apiVersion: operators.coreos.com/v1
kind: Operator
metadata:
  name: lvms-operator.openshift-storage
  annotations: {}
status:
  components:
    refs:
      - kind: Subscription
        namespace: openshift-storage
        conditions:
          - type: CatalogSourcesUnhealthy
            status: "False"
      - kind: InstallPlan
        namespace: openshift-storage
        conditions:
          - type: Installed
            status: "True"
      - kind: ClusterServiceVersion
        namespace: openshift-storage
        conditions:
          - type: Succeeded
            status: "True"
            reason: InstallSucceeded

StorageLVMCluster.yaml

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: lvmcluster
  namespace: openshift-storage
  annotations: {}
spec: {}
#example: creating a vg1 volume group leveraging all available disks on the node
#         except the installation disk.
#  storage:
#    deviceClasses:
#    - name: vg1
#      thinPoolConfig:
#        name: thin-pool-1
#        sizePercent: 90
#        overprovisionRatio: 10

StorageLVMSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: lvms-operator
  namespace: openshift-storage
  annotations: {}
spec:
  channel: "stable"
  name: lvms-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

StorageLVMSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-storage
  labels:
    workload.openshift.io/allowed: "management"
    openshift.io/cluster-monitoring: "true"
  annotations: {}

StorageLVMSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: lvms-operator-operatorgroup
  namespace: openshift-storage
  annotations: {}
spec:
  targetNamespaces:
    - openshift-storage

PerformanceProfile.yaml

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

TunedPerformancePatch.yaml

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  annotations: {}
spec:
  profile:
    - name: performance-patch
      # Please note:
      # - The 'include' line must match the associated PerformanceProfile name, following below pattern
      #   include=openshift-node-performance-${PerformanceProfile.metadata.name}
      # - When using the standard (non-realtime) kernel, remove the kernel.timer_migration override from
      #   the [sysctl] section and remove the entire section if it is empty.
      data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-openshift-node-performance-profile
        [scheduler]
        group.ice-ptp=0:f:10:*:ice-ptp.*
        group.ice-gnss=0:f:10:*:ice-gnss.*
        group.ice-dplls=0:f:10:*:ice-dplls.*
        [service]
        service.stalld=start,enable
        service.chronyd=stop,disable
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: "$mcp"
      priority: 19
      profile: performance-patch

PtpConfigBoundaryForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary"
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        # The interface name is hardware-specific
        [$iface_slave]
        masterOnly 0
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 248
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 135
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "boundary"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigForHAForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-ha
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary-ha"
      ptp4lOpts: " "
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
        haProfiles: "$profile1,$profile2"
  recommend:
    - profile: "boundary-ha"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigMasterForEvent.yaml

# The grandmaster profile is provided for testing only
# It is not installed on production clusters
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "grandmaster"
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "grandmaster"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigSlaveForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: du-ptp-slave
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "slave"
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 -s --summary_interval -4"
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "slave"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpOperatorConfigForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
  annotations: {}
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/$mcp: ""
  ptpEventConfig:
    enableEventPublisher: true
    transportHost: "http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"

PtpConfigBoundary.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary"
      ptp4lOpts: "-2"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        # The interface name is hardware-specific
        [$iface_slave]
        masterOnly 0
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 248
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 135
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "boundary"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigDualCardGmWpc.yaml

# The grandmaster profile is provided for testing only
# It is not installed on production clusters
# In this example two cards $iface_nic1 and $iface_nic2 are connected via
# SMA1 ports by a cable and $iface_nic2 receives 1PPS signals from $iface_nic1
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "grandmaster"
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: -r -u 0 -m -w -N 8 -R 16 -s $iface_nic1 -n 24
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      plugins:
        e810:
          enableDefaultConfig: false
          settings:
            LocalMaxHoldoverOffSet: 1500
            LocalHoldoverTimeout: 14400
            MaxInSpecOffset: 1500
          pins: $e810_pins
          #  "$iface_nic1":
          #    "U.FL2": "0 2"
          #    "U.FL1": "0 1"
          #    "SMA2": "0 2"
          #    "SMA1": "2 1"
          #  "$iface_nic2":
          #    "U.FL2": "0 2"
          #    "U.FL1": "0 1"
          #    "SMA2": "0 2"
          #    "SMA1": "1 1"
          ublxCmds:
            - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1
                - "-P"
                - "29.20"
                - "-z"
                - "CFG-HW-ANT_CFG_VOLTCTRL,1"
              reportOutput: false
            - args: #ubxtool -P 29.20 -e GPS
                - "-P"
                - "29.20"
                - "-e"
                - "GPS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d Galileo
                - "-P"
                - "29.20"
                - "-d"
                - "Galileo"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d GLONASS
                - "-P"
                - "29.20"
                - "-d"
                - "GLONASS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d BeiDou
                - "-P"
                - "29.20"
                - "-d"
                - "BeiDou"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d SBAS
                - "-P"
                - "29.20"
                - "-d"
                - "SBAS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000
                - "-P"
                - "29.20"
                - "-t"
                - "-w"
                - "5"
                - "-v"
                - "1"
                - "-e"
                - "SURVEYIN,600,50000"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p MON-HW
                - "-P"
                - "29.20"
                - "-p"
                - "MON-HW"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,300
                - "-P"
                - "29.20"
                - "-p"
                - "CFG-MSG,1,38,300"
              reportOutput: true
      ts2phcOpts: " "
      ts2phcConf: |
        [nmea]
        ts2phc.master 1
        [global]
        use_syslog  0
        verbose 1
        logging_level 7
        ts2phc.pulsewidth 100000000
        #cat /dev/GNSS to find available serial port
        #example value of gnss_serialport is /dev/ttyGNSS_1700_0
        ts2phc.nmea_serialport $gnss_serialport
        leapfile  /usr/share/zoneinfo/leap-seconds.list
        [$iface_nic1]
        ts2phc.extts_polarity rising
        ts2phc.extts_correction 0
        [$iface_nic2]
        ts2phc.master 0
        ts2phc.extts_polarity rising
        #this is a measured value in nanoseconds to compensate for SMA cable delay
        ts2phc.extts_correction -10
      ptp4lConf: |
        [$iface_nic1]
        masterOnly 1
        [$iface_nic1_1]
        masterOnly 1
        [$iface_nic1_2]
        masterOnly 1
        [$iface_nic1_3]
        masterOnly 1
        [$iface_nic2]
        masterOnly 1
        [$iface_nic2_1]
        masterOnly 1
        [$iface_nic2_2]
        masterOnly 1
        [$iface_nic2_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 6
        clockAccuracy 0x27
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval 0
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval -4
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        clock_servo pi
        sanity_freq_limit  200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 1
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0x20
  recommend:
    - profile: "grandmaster"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigThreeCardGmWpc.yaml

# In this example, the three cards are connected via SMA cables:
# - $iface_nic1 has the GNSS signal input
# - $iface_nic2 SMA1 is connected to $iface_nic1 SMA1
# - $iface_nic3 SMA1 is connected to $iface_nic1 SMA2
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster
  namespace: openshift-ptp
  annotations:
    {}
spec:
  profile:
  - name: grandmaster
    ptp4lOpts: -2 --summary_interval -4
    phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_nic1 -n 24
    ptpSchedulingPolicy: SCHED_FIFO
    ptpSchedulingPriority: 10
    ptpSettings:
      logReduce: "true"
    plugins:
      e810:
        enableDefaultConfig: false
        settings:
          LocalHoldoverTimeout: 14400
          LocalMaxHoldoverOffSet: 1500
          MaxInSpecOffset: 1500
        pins:
          # Syntax guide:
          # - The 1st number in each pair must be one of:
          #    0 - Disabled
          #    1 - RX
          #    2 - TX
          # - The 2nd number in each pair must match the channel number
          $iface_nic1:
            SMA1: 2 1
            SMA2: 2 2
            U.FL1: 0 1
            U.FL2: 0 2
          $iface_nic2:
            SMA1: 1 1
            SMA2: 0 2
            U.FL1: 0 1
            U.FL2: 0 2
          $iface_nic3:
            SMA1: 1 1
            SMA2: 0 2
            U.FL1: 0 1
            U.FL2: 0 2
        ublxCmds:
          - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1
              - "-P"
              - "29.20"
              - "-z"
              - "CFG-HW-ANT_CFG_VOLTCTRL,1"
            reportOutput: false
          - args: #ubxtool -P 29.20 -e GPS
              - "-P"
              - "29.20"
              - "-e"
              - "GPS"
            reportOutput: false
          - args: #ubxtool -P 29.20 -d Galileo
              - "-P"
              - "29.20"
              - "-d"
              - "Galileo"
            reportOutput: false
          - args: #ubxtool -P 29.20 -d GLONASS
              - "-P"
              - "29.20"
              - "-d"
              - "GLONASS"
            reportOutput: false
          - args: #ubxtool -P 29.20 -d BeiDou
              - "-P"
              - "29.20"
              - "-d"
              - "BeiDou"
            reportOutput: false
          - args: #ubxtool -P 29.20 -d SBAS
              - "-P"
              - "29.20"
              - "-d"
              - "SBAS"
            reportOutput: false
          - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000
              - "-P"
              - "29.20"
              - "-t"
              - "-w"
              - "5"
              - "-v"
              - "1"
              - "-e"
              - "SURVEYIN,600,50000"
            reportOutput: true
          - args: #ubxtool -P 29.20 -p MON-HW
              - "-P"
              - "29.20"
              - "-p"
              - "MON-HW"
            reportOutput: true
          - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,248
              - "-P"
              - "29.20"
              - "-p"
              - "CFG-MSG,1,38,248"
            reportOutput: true
    ts2phcOpts: " "
    ts2phcConf: |
      [nmea]
      ts2phc.master 1
      [global]
      use_syslog  0
      verbose 1
      logging_level 7
      ts2phc.pulsewidth 100000000
      #example value of nmea_serialport is /dev/gnss0
      ts2phc.nmea_serialport (?<gnss_serialport>[/\w\s/]+)
      leapfile /usr/share/zoneinfo/leap-seconds.list
      [$iface_nic1]
      ts2phc.extts_polarity rising
      ts2phc.extts_correction 0
      [$iface_nic2]
      ts2phc.master 0
      ts2phc.extts_polarity rising
      #this is a measured value in nanoseconds to compensate for SMA cable delay
      ts2phc.extts_correction -10
      [$iface_nic3]
      ts2phc.master 0
      ts2phc.extts_polarity rising
      #this is a measured value in nanoseconds to compensate for SMA cable delay
      ts2phc.extts_correction -10
    ptp4lConf: |
      [$iface_nic1]
      masterOnly 1
      [$iface_nic1_1]
      masterOnly 1
      [$iface_nic1_2]
      masterOnly 1
      [$iface_nic1_3]
      masterOnly 1
      [$iface_nic2]
      masterOnly 1
      [$iface_nic2_1]
      masterOnly 1
      [$iface_nic2_2]
      masterOnly 1
      [$iface_nic2_3]
      masterOnly 1
      [$iface_nic3]
      masterOnly 1
      [$iface_nic3_1]
      masterOnly 1
      [$iface_nic3_2]
      masterOnly 1
      [$iface_nic3_3]
      masterOnly 1
      [global]
      #
      # Default Data Set
      #
      twoStepFlag 1
      priority1 128
      priority2 128
      domainNumber 24
      #utc_offset 37
      clockClass 6
      clockAccuracy 0x27
      offsetScaledLogVariance 0xFFFF
      free_running 0
      freq_est_interval 1
      dscp_event 0
      dscp_general 0
      dataset_comparison G.8275.x
      G.8275.defaultDS.localPriority 128
      #
      # Port Data Set
      #
      logAnnounceInterval -3
      logSyncInterval -4
      logMinDelayReqInterval -4
      logMinPdelayReqInterval 0
      announceReceiptTimeout 3
      syncReceiptTimeout 0
      delayAsymmetry 0
      fault_reset_interval -4
      neighborPropDelayThresh 20000000
      masterOnly 0
      G.8275.portDS.localPriority 128
      #
      # Run time options
      #
      assume_two_step 0
      logging_level 6
      path_trace_enabled 0
      follow_up_info 0
      hybrid_e2e 0
      inhibit_multicast_service 0
      net_sync_monitor 0
      tc_spanning_tree 0
      tx_timestamp_timeout 50
      unicast_listen 0
      unicast_master_table 0
      unicast_req_duration 3600
      use_syslog 1
      verbose 0
      summary_interval -4
      kernel_leap 1
      check_fup_sync 0
      clock_class_threshold 7
      #
      # Servo Options
      #
      pi_proportional_const 0.0
      pi_integral_const 0.0
      pi_proportional_scale 0.0
      pi_proportional_exponent -0.3
      pi_proportional_norm_max 0.7
      pi_integral_scale 0.0
      pi_integral_exponent 0.4
      pi_integral_norm_max 0.3
      step_threshold 2.0
      first_step_threshold 0.00002
      clock_servo pi
      sanity_freq_limit 200000000
      ntpshm_segment 0
      #
      # Transport options
      #
      transportSpecific 0x0
      ptp_dst_mac 01:1B:19:00:00:00
      p2p_dst_mac 01:80:C2:00:00:0E
      udp_ttl 1
      udp6_scope 0x0E
      uds_address /var/run/ptp4l
      #
      # Default interface options
      #
      clock_type BC
      network_transport L2
      delay_mechanism E2E
      time_stamping hardware
      tsproc_mode filter
      delay_filter moving_median
      delay_filter_length 10
      egressLatency 0
      ingressLatency 0
      boundary_clock_jbod 1
      #
      # Clock description
      #
      productDescription ;;
      revisionData ;;
      manufacturerIdentity 00:00:00
      userDescription ;
      timeSource 0x20
    ptpClockThreshold:
      holdOverTimeout: 5
      maxOffsetThreshold: 100
      minOffsetThreshold: -100
  recommend:
  - profile: grandmaster
    priority: 4
    match:
    - nodeLabel: node-role.kubernetes.io/$mcp

PtpConfigForHA.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-ha
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary-ha"
      ptp4lOpts: ""
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
        haProfiles: "$profile1,$profile2"
  recommend:
    - profile: "boundary-ha"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigGmWpc.yaml

# The grandmaster profile is provided for testing only
# It is not installed on production clusters
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "grandmaster"
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: -r -u 0 -m -w -N 8 -R 16 -s $iface_master -n 24
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      plugins:
        e810:
          enableDefaultConfig: false
          settings:
            LocalMaxHoldoverOffSet: 1500
            LocalHoldoverTimeout: 14400
            MaxInSpecOffset: 1500
          pins: $e810_pins
          #  "$iface_master":
          #    "U.FL2": "0 2"
          #    "U.FL1": "0 1"
          #    "SMA2": "0 2"
          #    "SMA1": "0 1"
          ublxCmds:
            - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1
                - "-P"
                - "29.20"
                - "-z"
                - "CFG-HW-ANT_CFG_VOLTCTRL,1"
              reportOutput: false
            - args: #ubxtool -P 29.20 -e GPS
                - "-P"
                - "29.20"
                - "-e"
                - "GPS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d Galileo
                - "-P"
                - "29.20"
                - "-d"
                - "Galileo"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d GLONASS
                - "-P"
                - "29.20"
                - "-d"
                - "GLONASS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d BeiDou
                - "-P"
                - "29.20"
                - "-d"
                - "BeiDou"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d SBAS
                - "-P"
                - "29.20"
                - "-d"
                - "SBAS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000
                - "-P"
                - "29.20"
                - "-t"
                - "-w"
                - "5"
                - "-v"
                - "1"
                - "-e"
                - "SURVEYIN,600,50000"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p MON-HW
                - "-P"
                - "29.20"
                - "-p"
                - "MON-HW"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,300
                - "-P"
                - "29.20"
                - "-p"
                - "CFG-MSG,1,38,300"
              reportOutput: true
      ts2phcOpts: " "
      ts2phcConf: |
        [nmea]
        ts2phc.master 1
        [global]
        use_syslog  0
        verbose 1
        logging_level 7
        ts2phc.pulsewidth 100000000
        #cat /dev/GNSS to find available serial port
        #example value of gnss_serialport is /dev/ttyGNSS_1700_0
        ts2phc.nmea_serialport $gnss_serialport
        leapfile  /usr/share/zoneinfo/leap-seconds.list
        [$iface_master]
        ts2phc.extts_polarity rising
        ts2phc.extts_correction 0
      ptp4lConf: |
        [$iface_master]
        masterOnly 1
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 6
        clockAccuracy 0x27
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval 0
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval -4
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        clock_servo pi
        sanity_freq_limit  200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0x20
  recommend:
    - profile: "grandmaster"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigSlave.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: ordinary
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "ordinary"
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 -s"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "ordinary"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpOperatorConfig.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
  annotations: {}
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/$mcp: ""

PtpSubscription.yaml

---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ptp-operator-subscription
  namespace: openshift-ptp
  annotations: {}
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

PtpSubscriptionNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

PtpSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
  annotations: {}
spec:
  targetNamespaces:
    - openshift-ptp

AcceleratorsNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: vran-acceleration-operators
  annotations: {}

AcceleratorsOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: vran-operators
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  targetNamespaces:
    - vran-acceleration-operators

AcceleratorsSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-fec-subscription
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  channel: stable
  name: sriov-fec
  source: certified-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

SriovFecClusterConfig.yaml

apiVersion: sriovfec.intel.com/v2
kind: SriovFecClusterConfig
metadata:
  name: config
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  drainSkip: $drainSkip # true if SNO, false by default
  priority: 1
  nodeSelector:
    node-role.kubernetes.io/master: ""
  acceleratorSelector:
    pciAddress: $pciAddress
  physicalFunction:
    pfDriver: "vfio-pci"
    vfDriver: "vfio-pci"
    vfAmount: 16
    bbDevConfig: $bbDevConfig
#Recommended configuration for Intel ACC100 (Mount Bryce) FPGA here: https://github.com/smart-edge-open/openshift-operator/blob/main/spec/openshift-sriov-fec-operator.md#sample-cr-for-wireless-fec-acc100
#Recommended configuration for Intel N3000 FPGA here: https://github.com/smart-edge-open/openshift-operator/blob/main/spec/openshift-sriov-fec-operator.md#sample-cr-for-wireless-fec-n3000

SriovNetwork.yaml

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: ""
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  #  resourceName: ""
  networkNamespace: openshift-sriov-network-operator
#  vlan: ""
#  spoofChk: ""
#  ipam: ""
#  linkState: ""
#  maxTxRate: ""
#  minTxRate: ""
#  vlanQoS: ""
#  trust: ""
#  capabilities: ""

SriovNetworkNodePolicy.yaml

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: $name
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  # The attributes for Mellanox/Intel based NICs as below.
  #     deviceType: netdevice/vfio-pci
  #     isRdma: true/false
  deviceType: $deviceType
  isRdma: $isRdma
  nicSelector:
    # The exact physical function name must match the hardware used    
    pfNames: [$pfNames]
  nodeSelector:
    node-role.kubernetes.io/$mcp: ""
  numVfs: $numVfs
  priority: $priority
  resourceName: $resourceName

SriovOperatorConfig.yaml

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  configDaemonNodeSelector:
    "node-role.kubernetes.io/$mcp": ""
  # Injector and OperatorWebhook pods can be disabled (set to "false") below
  # to reduce the number of management pods. It is recommended to start with the 
  # webhook and injector pods enabled, and only disable them after verifying the
  # correctness of user manifests.
  #   If the injector is disabled, containers using sr-iov resources must explicitly assign
  #   them in the  "requests"/"limits" section of the container spec, for example:
  #    containers:
  #    - name: my-sriov-workload-container
  #      resources:
  #        limits:
  #          openshift.io/<resource_name>:  "1"
  #        requests:
  #          openshift.io/<resource_name>:  "1"
  enableInjector: false
  enableOperatorWebhook: false
  logLevel: 0

SriovOperatorConfigForSNO.yaml

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  configDaemonNodeSelector:
    "node-role.kubernetes.io/$mcp": ""
  # Injector and OperatorWebhook pods can be disabled (set to "false") below
  # to reduce the number of management pods. It is recommended to start with the 
  # webhook and injector pods enabled, and only disable them after verifying the
  # correctness of user manifests.
  #   If the injector is disabled, containers using sr-iov resources must explicitly assign
  #   them in the  "requests"/"limits" section of the container spec, for example:
  #    containers:
  #    - name: my-sriov-workload-container
  #      resources:
  #        limits:
  #          openshift.io/<resource_name>:  "1"
  #        requests:
  #          openshift.io/<resource_name>:  "1"
  enableInjector: false
  enableOperatorWebhook: false
  # Disable drain is needed for Single Node Openshift
  disableDrain: true
  logLevel: 0

SriovSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  channel: "stable"
  name: sriov-network-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

SriovSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management

SriovSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  targetNamespaces:
    - openshift-sriov-network-operator

3.2.4.4.2. クラスターチューニング参照 YAML

example-sno.yaml

# example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
---
apiVersion: ran.openshift.io/v1
kind: SiteConfig
metadata:
  name: "example-sno"
  namespace: "example-sno"
spec:
  baseDomain: "example.com"
  pullSecretRef:
    name: "assisted-deployment-pull-secret"
  clusterImageSetNameRef: "openshift-4.16"
  sshPublicKey: "ssh-rsa AAAA..."
  clusters:
    - clusterName: "example-sno"
      networkType: "OVNKubernetes"
      # installConfigOverrides is a generic way of passing install-config
      # parameters through the siteConfig.  The 'capabilities' field configures
      # the composable openshift feature.  In this 'capabilities' setting, we
      # remove all the optional set of components.
      # Notes:
      # - OperatorLifecycleManager is needed for 4.15 and later
      # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
      # - Ingress is needed for 4.16 and later
      installConfigOverrides: |
        {
          "capabilities": {
            "baselineCapabilitySet": "None",
            "additionalEnabledCapabilities": [
              "NodeTuning",
              "OperatorLifecycleManager",
              "Ingress"
            ]
          }
        }
      # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
      # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
      # extraManifestPath: sno-extra-manifest
      clusterLabels:
        # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
        du-profile: "latest"
        # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
        # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
        common: true
        # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
        group-du-sno: ""
        # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
        # Normally this should match or contain the cluster name so it only applies to a single cluster
        sites: "example-sno"
      clusterNetwork:
        - cidr: 1001:1::/48
          hostPrefix: 64
      machineNetwork:
        - cidr: 1111:2222:3333:4444::/64
      serviceNetwork:
        - 1001:2::/112
      additionalNTPSources:
        - 1111:2222:3333:4444::2
      # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
      # please see Workload Partitioning Feature for a complete guide.
      cpuPartitioningMode: AllNodes
      # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
      #crTemplates:
      #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
      nodes:
        - hostName: "example-node1.example.com"
          role: "master"
          # Optionally; This can be used to configure desired BIOS setting on a host:
          #biosConfigRef:
          #  filePath: "example-hw.profile"
          bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
          bmcCredentialsName:
            name: "example-node1-bmh-secret"
          bootMACAddress: "AA:BB:CC:DD:EE:11"
          # Use UEFISecureBoot to enable secure boot
          bootMode: "UEFI"
          rootDeviceHints:
            deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
          # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
          ignitionConfigOverride: |
            {
              "ignition": {
                "version": "3.2.0"
              },
              "storage": {
                "disks": [
                  {
                    "device": "/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62",
                    "partitions": [
                      {
                        "label": "var-lib-containers",
                        "sizeMiB": 0,
                        "startMiB": 250000
                      }
                    ],
                    "wipeTable": false
                  }
                ],
                "filesystems": [
                  {
                    "device": "/dev/disk/by-partlabel/var-lib-containers",
                    "format": "xfs",
                    "mountOptions": [
                      "defaults",
                      "prjquota"
                    ],
                    "path": "/var/lib/containers",
                    "wipeFilesystem": true
                  }
                ]
              },
              "systemd": {
                "units": [
                  {
                    "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                    "enabled": true,
                    "name": "var-lib-containers.mount"
                  }
                ]
              }
            }
          nodeNetwork:
            interfaces:
              - name: eno1
                macAddress: "AA:BB:CC:DD:EE:11"
            config:
              interfaces:
                - name: eno1
                  type: ethernet
                  state: up
                  ipv4:
                    enabled: false
                  ipv6:
                    enabled: true
                    address:
                      # For SNO sites with static IP addresses, the node-specific,
                      # API and Ingress IPs should all be the same and configured on
                      # the interface
                      - ip: 1111:2222:3333:4444::aaaa:1
                        prefix-length: 64
              dns-resolver:
                config:
                  search:
                    - example.com
                  server:
                    - 1111:2222:3333:4444::2
              routes:
                config:
                  - destination: ::/0
                    next-hop-interface: eno1
                    next-hop-address: 1111:2222:3333:4444::1
                    table-id: 254

ConsoleOperatorDisable.yaml

apiVersion: operator.openshift.io/v1
kind: Console
metadata:
  name: cluster
spec:
  managementState: Removed

DisableSnoNetworkDiag.yaml

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  annotations: {}
spec:
  disableNetworkDiagnostics: true

ReduceMonitoringFootprint.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
  annotations: {}
data:
  config.yaml: |
    alertmanagerMain:
      enabled: false
    telemeterClient:
      enabled: false
    prometheusK8s:
       retention: 24h

09-openshift-marketplace-ns.yaml

# Taken from https://github.com/operator-framework/operator-marketplace/blob/53c124a3f0edfd151652e1f23c87dd39ed7646bb/manifests/01_namespace.yaml
# Update it as the source evolves.
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: ""
    workload.openshift.io/allowed: "management"
  labels:
    openshift.io/cluster-monitoring: "true"
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.25
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: v1.25
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: v1.25
  name: "openshift-marketplace"

DefaultCatsrc.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: default-cat-source
  namespace: openshift-marketplace
  annotations:
    target.workload.openshift.io/management: '{"effect": "PreferredDuringScheduling"}'
spec:
  displayName: default-cat-source
  image: $imageUrl
  publisher: Red Hat
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 1h
status:
  connectionState:
    lastObservedState: READY

DisableOLMPprof.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: collect-profiles-config
  namespace: openshift-operator-lifecycle-manager
  annotations: {}
data:
  pprof-config.yaml: |
    disabled: True

DisconnectedICSP.yaml

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: disconnected-internal-icsp
  annotations: {}
spec:
#    repositoryDigestMirrors:
#    - $mirrors

OperatorHub.yaml

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
  annotations: {}
spec:
  disableAllDefaultSources: true

3.2.4.4.3. マシン設定参照 YAML

enable-crun-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: enable-crun-master
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/master: ""
  containerRuntimeConfig:
    defaultRuntime: crun

enable-crun-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: enable-crun-worker
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  containerRuntimeConfig:
    defaultRuntime: crun

99-crio-disable-wipe-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-crio-disable-wipe-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,W2NyaW9dCmNsZWFuX3NodXRkb3duX2ZpbGUgPSAiIgo=
          mode: 420
          path: /etc/crio/crio.conf.d/99-crio-disable-wipe.toml

99-crio-disable-wipe-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-crio-disable-wipe-worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,W2NyaW9dCmNsZWFuX3NodXRkb3duX2ZpbGUgPSAiIgo=
          mode: 420
          path: /etc/crio/crio.conf.d/99-crio-disable-wipe.toml

06-kdump-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 06-kdump-enable-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump.service
  kernelArguments:
    - crashkernel=512M

06-kdump-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 06-kdump-enable-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump.service
  kernelArguments:
    - crashkernel=512M

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

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: container-mount-namespace-and-kubelet-conf-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKCmRlYnVnKCkgewogIGVjaG8gJEAgPiYyCn0KCnVzYWdlKCkgewogIGVjaG8gVXNhZ2U6ICQoYmFzZW5hbWUgJDApIFVOSVQgW2VudmZpbGUgW3Zhcm5hbWVdXQogIGVjaG8KICBlY2hvIEV4dHJhY3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJzdCBFeGVjU3RhcnQgc3RhbnphIGZyb20gdGhlIGdpdmVuIHN5c3RlbWQgdW5pdCBhbmQgcmV0dXJuIGl0IHRvIHN0ZG91dAogIGVjaG8KICBlY2hvICJJZiAnZW52ZmlsZScgaXMgcHJvdmlkZWQsIHB1dCBpdCBpbiB0aGVyZSBpbnN0ZWFkLCBhcyBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZSBuYW1lZCAndmFybmFtZSciCiAgZWNobyAiRGVmYXVsdCAndmFybmFtZScgaXMgRVhFQ1NUQVJUIGlmIG5vdCBzcGVjaWZpZWQiCiAgZXhpdCAxCn0KClVOSVQ9JDEKRU5WRklMRT0kMgpWQVJOQU1FPSQzCmlmIFtbIC16ICRVTklUIHx8ICRVTklUID09ICItLWhlbHAiIHx8ICRVTklUID09ICItaCIgXV07IHRoZW4KICB1c2FnZQpmaQpkZWJ1ZyAiRXh0cmFjdGluZyBFeGVjU3RhcnQgZnJvbSAkVU5JVCIKRklMRT0kKHN5c3RlbWN0bCBjYXQgJFVOSVQgfCBoZWFkIC1uIDEpCkZJTEU9JHtGSUxFI1wjIH0KaWYgW1sgISAtZiAkRklMRSBdXTsgdGhlbgogIGRlYnVnICJGYWlsZWQgdG8gZmluZCByb290IGZpbGUgZm9yIHVuaXQgJFVOSVQgKCRGSUxFKSIKICBleGl0CmZpCmRlYnVnICJTZXJ2aWNlIGRlZmluaXRpb24gaXMgaW4gJEZJTEUiCkVYRUNTVEFSVD0kKHNlZCAtbiAtZSAnL15FeGVjU3RhcnQ9LipcXCQvLC9bXlxcXSQvIHsgcy9eRXhlY1N0YXJ0PS8vOyBwIH0nIC1lICcvXkV4ZWNTdGFydD0uKlteXFxdJC8geyBzL15FeGVjU3RhcnQ9Ly87IHAgfScgJEZJTEUpCgppZiBbWyAkRU5WRklMRSBdXTsgdGhlbgogIFZBUk5BTUU9JHtWQVJOQU1FOi1FWEVDU1RBUlR9CiAgZWNobyAiJHtWQVJOQU1FfT0ke0VYRUNTVEFSVH0iID4gJEVOVkZJTEUKZWxzZQogIGVjaG8gJEVYRUNTVEFSVApmaQo=
          mode: 493
          path: /usr/local/bin/extractExecStart
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKbnNlbnRlciAtLW1vdW50PS9ydW4vY29udGFpbmVyLW1vdW50LW5hbWVzcGFjZS9tbnQgIiRAIgo=
          mode: 493
          path: /usr/local/bin/nsenterCmns
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Manages a mount namespace that both kubelet and crio can use to share their container-specific mounts

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            RuntimeDirectory=container-mount-namespace
            Environment=RUNTIME_DIRECTORY=%t/container-mount-namespace
            Environment=BIND_POINT=%t/container-mount-namespace/mnt
            ExecStartPre=bash -c "findmnt ${RUNTIME_DIRECTORY} || mount --make-unbindable --bind ${RUNTIME_DIRECTORY} ${RUNTIME_DIRECTORY}"
            ExecStartPre=touch ${BIND_POINT}
            ExecStart=unshare --mount=${BIND_POINT} --propagation slave mount --make-rshared /
            ExecStop=umount -R ${RUNTIME_DIRECTORY}
          name: container-mount-namespace.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART}"
              name: 90-container-mount-namespace.conf
          name: crio.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART} --housekeeping-interval=30s"
              name: 90-container-mount-namespace.conf
            - contents: |
                [Service]
                Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
                Environment="OPENSHIFT_EVICTION_MONITORING_PERIOD_DURATION=30s"
              name: 30-kubelet-interval-tuning.conf
          name: kubelet.service

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

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: container-mount-namespace-and-kubelet-conf-worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKCmRlYnVnKCkgewogIGVjaG8gJEAgPiYyCn0KCnVzYWdlKCkgewogIGVjaG8gVXNhZ2U6ICQoYmFzZW5hbWUgJDApIFVOSVQgW2VudmZpbGUgW3Zhcm5hbWVdXQogIGVjaG8KICBlY2hvIEV4dHJhY3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJzdCBFeGVjU3RhcnQgc3RhbnphIGZyb20gdGhlIGdpdmVuIHN5c3RlbWQgdW5pdCBhbmQgcmV0dXJuIGl0IHRvIHN0ZG91dAogIGVjaG8KICBlY2hvICJJZiAnZW52ZmlsZScgaXMgcHJvdmlkZWQsIHB1dCBpdCBpbiB0aGVyZSBpbnN0ZWFkLCBhcyBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZSBuYW1lZCAndmFybmFtZSciCiAgZWNobyAiRGVmYXVsdCAndmFybmFtZScgaXMgRVhFQ1NUQVJUIGlmIG5vdCBzcGVjaWZpZWQiCiAgZXhpdCAxCn0KClVOSVQ9JDEKRU5WRklMRT0kMgpWQVJOQU1FPSQzCmlmIFtbIC16ICRVTklUIHx8ICRVTklUID09ICItLWhlbHAiIHx8ICRVTklUID09ICItaCIgXV07IHRoZW4KICB1c2FnZQpmaQpkZWJ1ZyAiRXh0cmFjdGluZyBFeGVjU3RhcnQgZnJvbSAkVU5JVCIKRklMRT0kKHN5c3RlbWN0bCBjYXQgJFVOSVQgfCBoZWFkIC1uIDEpCkZJTEU9JHtGSUxFI1wjIH0KaWYgW1sgISAtZiAkRklMRSBdXTsgdGhlbgogIGRlYnVnICJGYWlsZWQgdG8gZmluZCByb290IGZpbGUgZm9yIHVuaXQgJFVOSVQgKCRGSUxFKSIKICBleGl0CmZpCmRlYnVnICJTZXJ2aWNlIGRlZmluaXRpb24gaXMgaW4gJEZJTEUiCkVYRUNTVEFSVD0kKHNlZCAtbiAtZSAnL15FeGVjU3RhcnQ9LipcXCQvLC9bXlxcXSQvIHsgcy9eRXhlY1N0YXJ0PS8vOyBwIH0nIC1lICcvXkV4ZWNTdGFydD0uKlteXFxdJC8geyBzL15FeGVjU3RhcnQ9Ly87IHAgfScgJEZJTEUpCgppZiBbWyAkRU5WRklMRSBdXTsgdGhlbgogIFZBUk5BTUU9JHtWQVJOQU1FOi1FWEVDU1RBUlR9CiAgZWNobyAiJHtWQVJOQU1FfT0ke0VYRUNTVEFSVH0iID4gJEVOVkZJTEUKZWxzZQogIGVjaG8gJEVYRUNTVEFSVApmaQo=
          mode: 493
          path: /usr/local/bin/extractExecStart
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKbnNlbnRlciAtLW1vdW50PS9ydW4vY29udGFpbmVyLW1vdW50LW5hbWVzcGFjZS9tbnQgIiRAIgo=
          mode: 493
          path: /usr/local/bin/nsenterCmns
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Manages a mount namespace that both kubelet and crio can use to share their container-specific mounts

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            RuntimeDirectory=container-mount-namespace
            Environment=RUNTIME_DIRECTORY=%t/container-mount-namespace
            Environment=BIND_POINT=%t/container-mount-namespace/mnt
            ExecStartPre=bash -c "findmnt ${RUNTIME_DIRECTORY} || mount --make-unbindable --bind ${RUNTIME_DIRECTORY} ${RUNTIME_DIRECTORY}"
            ExecStartPre=touch ${BIND_POINT}
            ExecStart=unshare --mount=${BIND_POINT} --propagation slave mount --make-rshared /
            ExecStop=umount -R ${RUNTIME_DIRECTORY}
          name: container-mount-namespace.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART}"
              name: 90-container-mount-namespace.conf
          name: crio.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART} --housekeeping-interval=30s"
              name: 90-container-mount-namespace.conf
            - contents: |
                [Service]
                Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
                Environment="OPENSHIFT_EVICTION_MONITORING_PERIOD_DURATION=30s"
              name: 30-kubelet-interval-tuning.conf
          name: kubelet.service

99-sync-time-once-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-sync-time-once-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Sync time once
            After=network-online.target
            Wants=network-online.target
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecCondition=/bin/bash -c 'systemctl is-enabled chronyd.service --quiet && exit 1 || exit 0'
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service

99-sync-time-once-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-sync-time-once-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Sync time once
            After=network-online.target
            Wants=network-online.target
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecCondition=/bin/bash -c 'systemctl is-enabled chronyd.service --quiet && exit 1 || exit 0'
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service

03-sctp-machine-config-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: load-sctp-module-master
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8,sctp
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

03-sctp-machine-config-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: load-sctp-module-worker
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8,sctp
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

08-set-rcu-normal-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 08-set-rcu-normal-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKIwojIERpc2FibGUgcmN1X2V4cGVkaXRlZCBhZnRlciBub2RlIGhhcyBmaW5pc2hlZCBib290aW5nCiMKIyBUaGUgZGVmYXVsdHMgYmVsb3cgY2FuIGJlIG92ZXJyaWRkZW4gdmlhIGVudmlyb25tZW50IHZhcmlhYmxlcwojCgojIERlZmF1bHQgd2FpdCB0aW1lIGlzIDYwMHMgPSAxMG06Ck1BWElNVU1fV0FJVF9USU1FPSR7TUFYSU1VTV9XQUlUX1RJTUU6LTYwMH0KCiMgRGVmYXVsdCBzdGVhZHktc3RhdGUgdGhyZXNob2xkID0gMiUKIyBBbGxvd2VkIHZhbHVlczoKIyAgNCAgLSBhYnNvbHV0ZSBwb2QgY291bnQgKCsvLSkKIyAgNCUgLSBwZXJjZW50IGNoYW5nZSAoKy8tKQojICAtMSAtIGRpc2FibGUgdGhlIHN0ZWFkeS1zdGF0ZSBjaGVjawpTVEVBRFlfU1RBVEVfVEhSRVNIT0xEPSR7U1RFQURZX1NUQVRFX1RIUkVTSE9MRDotMiV9CgojIERlZmF1bHQgc3RlYWR5LXN0YXRlIHdpbmRvdyA9IDYwcwojIElmIHRoZSBydW5uaW5nIHBvZCBjb3VudCBzdGF5cyB3aXRoaW4gdGhlIGdpdmVuIHRocmVzaG9sZCBmb3IgdGhpcyB0aW1lCiMgcGVyaW9kLCByZXR1cm4gQ1BVIHV0aWxpemF0aW9uIHRvIG5vcm1hbCBiZWZvcmUgdGhlIG1heGltdW0gd2FpdCB0aW1lIGhhcwojIGV4cGlyZXMKU1RFQURZX1NUQVRFX1dJTkRPVz0ke1NURUFEWV9TVEFURV9XSU5ET1c6LTYwfQoKIyBEZWZhdWx0IHN0ZWFkeS1zdGF0ZSBhbGxvd3MgYW55IHBvZCBjb3VudCB0byBiZSAic3RlYWR5IHN0YXRlIgojIEluY3JlYXNpbmcgdGhpcyB3aWxsIHNraXAgYW55IHN0ZWFkeS1zdGF0ZSBjaGVja3MgdW50aWwgdGhlIGNvdW50IHJpc2VzIGFib3ZlCiMgdGhpcyBudW1iZXIgdG8gYXZvaWQgZmFsc2UgcG9zaXRpdmVzIGlmIHRoZXJlIGFyZSBzb21lIHBlcmlvZHMgd2hlcmUgdGhlCiMgY291bnQgZG9lc24ndCBpbmNyZWFzZSBidXQgd2Uga25vdyB3ZSBjYW4ndCBiZSBhdCBzdGVhZHktc3RhdGUgeWV0LgpTVEVBRFlfU1RBVEVfTUlOSU1VTT0ke1NURUFEWV9TVEFURV9NSU5JTVVNOi0wfQoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKd2l0aGluKCkgewogIGxvY2FsIGxhc3Q9JDEgY3VycmVudD0kMiB0aHJlc2hvbGQ9JDMKICBsb2NhbCBkZWx0YT0wIHBjaGFuZ2UKICBkZWx0YT0kKCggY3VycmVudCAtIGxhc3QgKSkKICBpZiBbWyAkY3VycmVudCAtZXEgJGxhc3QgXV07IHRoZW4KICAgIHBjaGFuZ2U9MAogIGVsaWYgW1sgJGxhc3QgLWVxIDAgXV07IHRoZW4KICAgIHBjaGFuZ2U9MTAwMDAwMAogIGVsc2UKICAgIHBjaGFuZ2U9JCgoICggIiRkZWx0YSIgKiAxMDApIC8gbGFzdCApKQogIGZpCiAgZWNobyAtbiAibGFzdDokbGFzdCBjdXJyZW50OiRjdXJyZW50IGRlbHRhOiRkZWx0YSBwY2hhbmdlOiR7cGNoYW5nZX0lOiAiCiAgbG9jYWwgYWJzb2x1dGUgbGltaXQKICBjYXNlICR0aHJlc2hvbGQgaW4KICAgIColKQogICAgICBhYnNvbHV0ZT0ke3BjaGFuZ2UjIy19ICMgYWJzb2x1dGUgdmFsdWUKICAgICAgbGltaXQ9JHt0aHJlc2hvbGQlJSV9CiAgICAgIDs7CiAgICAqKQogICAgICBhYnNvbHV0ZT0ke2RlbHRhIyMtfSAjIGFic29sdXRlIHZhbHVlCiAgICAgIGxpbWl0PSR0aHJlc2hvbGQKICAgICAgOzsKICBlc2FjCiAgaWYgW1sgJGFic29sdXRlIC1sZSAkbGltaXQgXV07IHRoZW4KICAgIGVjaG8gIndpdGhpbiAoKy8tKSR0aHJlc2hvbGQiCiAgICByZXR1cm4gMAogIGVsc2UKICAgIGVjaG8gIm91dHNpZGUgKCsvLSkkdGhyZXNob2xkIgogICAgcmV0dXJuIDEKICBmaQp9CgpzdGVhZHlzdGF0ZSgpIHsKICBsb2NhbCBsYXN0PSQxIGN1cnJlbnQ9JDIKICBpZiBbWyAkbGFzdCAtbHQgJFNURUFEWV9TVEFURV9NSU5JTVVNIF1dOyB0aGVuCiAgICBlY2hvICJsYXN0OiRsYXN0IGN1cnJlbnQ6JGN1cnJlbnQgV2FpdGluZyB0byByZWFjaCAkU1RFQURZX1NUQVRFX01JTklNVU0gYmVmb3JlIGNoZWNraW5nIGZvciBzdGVhZHktc3RhdGUiCiAgICByZXR1cm4gMQogIGZpCiAgd2l0aGluICIkbGFzdCIgIiRjdXJyZW50IiAiJFNURUFEWV9TVEFURV9USFJFU0hPTEQiCn0KCndhaXRGb3JSZWFkeSgpIHsKICBsb2dnZXIgIlJlY292ZXJ5OiBXYWl0aW5nICR7TUFYSU1VTV9XQUlUX1RJTUV9cyBmb3IgdGhlIGluaXRpYWxpemF0aW9uIHRvIGNvbXBsZXRlIgogIGxvY2FsIHQ9MCBzPTEwCiAgbG9jYWwgbGFzdENjb3VudD0wIGNjb3VudD0wIHN0ZWFkeVN0YXRlVGltZT0wCiAgd2hpbGUgW1sgJHQgLWx0ICRNQVhJTVVNX1dBSVRfVElNRSBdXTsgZG8KICAgIHNsZWVwICRzCiAgICAoKHQgKz0gcykpCiAgICAjIERldGVjdCBzdGVhZHktc3RhdGUgcG9kIGNvdW50CiAgICBjY291bnQ9JChjcmljdGwgcHMgMj4vZGV2L251bGwgfCB3YyAtbCkKICAgIGlmIFtbICRjY291bnQgLWd0IDAgXV0gJiYgc3RlYWR5c3RhdGUgIiRsYXN0Q2NvdW50IiAiJGNjb3VudCI7IHRoZW4KICAgICAgKChzdGVhZHlTdGF0ZVRpbWUgKz0gcykpCiAgICAgIGVjaG8gIlN0ZWFkeS1zdGF0ZSBmb3IgJHtzdGVhZHlTdGF0ZVRpbWV9cy8ke1NURUFEWV9TVEFURV9XSU5ET1d9cyIKICAgICAgaWYgW1sgJHN0ZWFkeVN0YXRlVGltZSAtZ2UgJFNURUFEWV9TVEFURV9XSU5ET1cgXV07IHRoZW4KICAgICAgICBsb2dnZXIgIlJlY292ZXJ5OiBTdGVhZHktc3RhdGUgKCsvLSAkU1RFQURZX1NUQVRFX1RIUkVTSE9MRCkgZm9yICR7U1RFQURZX1NUQVRFX1dJTkRPV31zOiBEb25lIgogICAgICAgIHJldHVybiAwCiAgICAgIGZpCiAgICBlbHNlCiAgICAgIGlmIFtbICRzdGVhZHlTdGF0ZVRpbWUgLWd0IDAgXV07IHRoZW4KICAgICAgICBlY2hvICJSZXNldHRpbmcgc3RlYWR5LXN0YXRlIHRpbWVyIgogICAgICAgIHN0ZWFkeVN0YXRlVGltZT0wCiAgICAgIGZpCiAgICBmaQogICAgbGFzdENjb3VudD0kY2NvdW50CiAgZG9uZQogIGxvZ2dlciAiUmVjb3Zlcnk6IFJlY292ZXJ5IENvbXBsZXRlIFRpbWVvdXQiCn0KCnNldFJjdU5vcm1hbCgpIHsKICBlY2hvICJTZXR0aW5nIHJjdV9ub3JtYWwgdG8gMSIKICBlY2hvIDEgPiAvc3lzL2tlcm5lbC9yY3Vfbm9ybWFsCn0KCm1haW4oKSB7CiAgd2FpdEZvclJlYWR5CiAgZWNobyAiV2FpdGluZyBmb3Igc3RlYWR5IHN0YXRlIHRvb2s6ICQoYXdrICd7cHJpbnQgaW50KCQxLzM2MDApImgiLCBpbnQoKCQxJTM2MDApLzYwKSJtIiwgaW50KCQxJTYwKSJzIn0nIC9wcm9jL3VwdGltZSkiCiAgc2V0UmN1Tm9ybWFsCn0KCmlmIFtbICIke0JBU0hfU09VUkNFWzBdfSIgPSAiJHswfSIgXV07IHRoZW4KICBtYWluICIke0B9IgogIGV4aXQgJD8KZmkK
          mode: 493
          path: /usr/local/bin/set-rcu-normal.sh
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Disable rcu_expedited after node has finished booting by setting rcu_normal to 1

            [Service]
            Type=simple
            ExecStart=/usr/local/bin/set-rcu-normal.sh

            # Maximum wait time is 600s = 10m:
            Environment=MAXIMUM_WAIT_TIME=600

            # Steady-state threshold = 2%
            # Allowed values:
            #  4  - absolute pod count (+/-)
            #  4% - percent change (+/-)
            #  -1 - disable the steady-state check
            # Note: '%' must be escaped as '%%' in systemd unit files
            Environment=STEADY_STATE_THRESHOLD=2%%

            # Steady-state window = 120s
            # If the running pod count stays within the given threshold for this time
            # period, return CPU utilization to normal before the maximum wait time has
            # expires
            Environment=STEADY_STATE_WINDOW=120

            # Steady-state minimum = 40
            # Increasing this will skip any steady-state checks until the count rises above
            # this number to avoid false positives if there are some periods where the
            # count doesn't increase but we know we can't be at steady-state yet.
            Environment=STEADY_STATE_MINIMUM=40

            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: set-rcu-normal.service

08-set-rcu-normal-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 08-set-rcu-normal-worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKIwojIERpc2FibGUgcmN1X2V4cGVkaXRlZCBhZnRlciBub2RlIGhhcyBmaW5pc2hlZCBib290aW5nCiMKIyBUaGUgZGVmYXVsdHMgYmVsb3cgY2FuIGJlIG92ZXJyaWRkZW4gdmlhIGVudmlyb25tZW50IHZhcmlhYmxlcwojCgojIERlZmF1bHQgd2FpdCB0aW1lIGlzIDYwMHMgPSAxMG06Ck1BWElNVU1fV0FJVF9USU1FPSR7TUFYSU1VTV9XQUlUX1RJTUU6LTYwMH0KCiMgRGVmYXVsdCBzdGVhZHktc3RhdGUgdGhyZXNob2xkID0gMiUKIyBBbGxvd2VkIHZhbHVlczoKIyAgNCAgLSBhYnNvbHV0ZSBwb2QgY291bnQgKCsvLSkKIyAgNCUgLSBwZXJjZW50IGNoYW5nZSAoKy8tKQojICAtMSAtIGRpc2FibGUgdGhlIHN0ZWFkeS1zdGF0ZSBjaGVjawpTVEVBRFlfU1RBVEVfVEhSRVNIT0xEPSR7U1RFQURZX1NUQVRFX1RIUkVTSE9MRDotMiV9CgojIERlZmF1bHQgc3RlYWR5LXN0YXRlIHdpbmRvdyA9IDYwcwojIElmIHRoZSBydW5uaW5nIHBvZCBjb3VudCBzdGF5cyB3aXRoaW4gdGhlIGdpdmVuIHRocmVzaG9sZCBmb3IgdGhpcyB0aW1lCiMgcGVyaW9kLCByZXR1cm4gQ1BVIHV0aWxpemF0aW9uIHRvIG5vcm1hbCBiZWZvcmUgdGhlIG1heGltdW0gd2FpdCB0aW1lIGhhcwojIGV4cGlyZXMKU1RFQURZX1NUQVRFX1dJTkRPVz0ke1NURUFEWV9TVEFURV9XSU5ET1c6LTYwfQoKIyBEZWZhdWx0IHN0ZWFkeS1zdGF0ZSBhbGxvd3MgYW55IHBvZCBjb3VudCB0byBiZSAic3RlYWR5IHN0YXRlIgojIEluY3JlYXNpbmcgdGhpcyB3aWxsIHNraXAgYW55IHN0ZWFkeS1zdGF0ZSBjaGVja3MgdW50aWwgdGhlIGNvdW50IHJpc2VzIGFib3ZlCiMgdGhpcyBudW1iZXIgdG8gYXZvaWQgZmFsc2UgcG9zaXRpdmVzIGlmIHRoZXJlIGFyZSBzb21lIHBlcmlvZHMgd2hlcmUgdGhlCiMgY291bnQgZG9lc24ndCBpbmNyZWFzZSBidXQgd2Uga25vdyB3ZSBjYW4ndCBiZSBhdCBzdGVhZHktc3RhdGUgeWV0LgpTVEVBRFlfU1RBVEVfTUlOSU1VTT0ke1NURUFEWV9TVEFURV9NSU5JTVVNOi0wfQoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKd2l0aGluKCkgewogIGxvY2FsIGxhc3Q9JDEgY3VycmVudD0kMiB0aHJlc2hvbGQ9JDMKICBsb2NhbCBkZWx0YT0wIHBjaGFuZ2UKICBkZWx0YT0kKCggY3VycmVudCAtIGxhc3QgKSkKICBpZiBbWyAkY3VycmVudCAtZXEgJGxhc3QgXV07IHRoZW4KICAgIHBjaGFuZ2U9MAogIGVsaWYgW1sgJGxhc3QgLWVxIDAgXV07IHRoZW4KICAgIHBjaGFuZ2U9MTAwMDAwMAogIGVsc2UKICAgIHBjaGFuZ2U9JCgoICggIiRkZWx0YSIgKiAxMDApIC8gbGFzdCApKQogIGZpCiAgZWNobyAtbiAibGFzdDokbGFzdCBjdXJyZW50OiRjdXJyZW50IGRlbHRhOiRkZWx0YSBwY2hhbmdlOiR7cGNoYW5nZX0lOiAiCiAgbG9jYWwgYWJzb2x1dGUgbGltaXQKICBjYXNlICR0aHJlc2hvbGQgaW4KICAgIColKQogICAgICBhYnNvbHV0ZT0ke3BjaGFuZ2UjIy19ICMgYWJzb2x1dGUgdmFsdWUKICAgICAgbGltaXQ9JHt0aHJlc2hvbGQlJSV9CiAgICAgIDs7CiAgICAqKQogICAgICBhYnNvbHV0ZT0ke2RlbHRhIyMtfSAjIGFic29sdXRlIHZhbHVlCiAgICAgIGxpbWl0PSR0aHJlc2hvbGQKICAgICAgOzsKICBlc2FjCiAgaWYgW1sgJGFic29sdXRlIC1sZSAkbGltaXQgXV07IHRoZW4KICAgIGVjaG8gIndpdGhpbiAoKy8tKSR0aHJlc2hvbGQiCiAgICByZXR1cm4gMAogIGVsc2UKICAgIGVjaG8gIm91dHNpZGUgKCsvLSkkdGhyZXNob2xkIgogICAgcmV0dXJuIDEKICBmaQp9CgpzdGVhZHlzdGF0ZSgpIHsKICBsb2NhbCBsYXN0PSQxIGN1cnJlbnQ9JDIKICBpZiBbWyAkbGFzdCAtbHQgJFNURUFEWV9TVEFURV9NSU5JTVVNIF1dOyB0aGVuCiAgICBlY2hvICJsYXN0OiRsYXN0IGN1cnJlbnQ6JGN1cnJlbnQgV2FpdGluZyB0byByZWFjaCAkU1RFQURZX1NUQVRFX01JTklNVU0gYmVmb3JlIGNoZWNraW5nIGZvciBzdGVhZHktc3RhdGUiCiAgICByZXR1cm4gMQogIGZpCiAgd2l0aGluICIkbGFzdCIgIiRjdXJyZW50IiAiJFNURUFEWV9TVEFURV9USFJFU0hPTEQiCn0KCndhaXRGb3JSZWFkeSgpIHsKICBsb2dnZXIgIlJlY292ZXJ5OiBXYWl0aW5nICR7TUFYSU1VTV9XQUlUX1RJTUV9cyBmb3IgdGhlIGluaXRpYWxpemF0aW9uIHRvIGNvbXBsZXRlIgogIGxvY2FsIHQ9MCBzPTEwCiAgbG9jYWwgbGFzdENjb3VudD0wIGNjb3VudD0wIHN0ZWFkeVN0YXRlVGltZT0wCiAgd2hpbGUgW1sgJHQgLWx0ICRNQVhJTVVNX1dBSVRfVElNRSBdXTsgZG8KICAgIHNsZWVwICRzCiAgICAoKHQgKz0gcykpCiAgICAjIERldGVjdCBzdGVhZHktc3RhdGUgcG9kIGNvdW50CiAgICBjY291bnQ9JChjcmljdGwgcHMgMj4vZGV2L251bGwgfCB3YyAtbCkKICAgIGlmIFtbICRjY291bnQgLWd0IDAgXV0gJiYgc3RlYWR5c3RhdGUgIiRsYXN0Q2NvdW50IiAiJGNjb3VudCI7IHRoZW4KICAgICAgKChzdGVhZHlTdGF0ZVRpbWUgKz0gcykpCiAgICAgIGVjaG8gIlN0ZWFkeS1zdGF0ZSBmb3IgJHtzdGVhZHlTdGF0ZVRpbWV9cy8ke1NURUFEWV9TVEFURV9XSU5ET1d9cyIKICAgICAgaWYgW1sgJHN0ZWFkeVN0YXRlVGltZSAtZ2UgJFNURUFEWV9TVEFURV9XSU5ET1cgXV07IHRoZW4KICAgICAgICBsb2dnZXIgIlJlY292ZXJ5OiBTdGVhZHktc3RhdGUgKCsvLSAkU1RFQURZX1NUQVRFX1RIUkVTSE9MRCkgZm9yICR7U1RFQURZX1NUQVRFX1dJTkRPV31zOiBEb25lIgogICAgICAgIHJldHVybiAwCiAgICAgIGZpCiAgICBlbHNlCiAgICAgIGlmIFtbICRzdGVhZHlTdGF0ZVRpbWUgLWd0IDAgXV07IHRoZW4KICAgICAgICBlY2hvICJSZXNldHRpbmcgc3RlYWR5LXN0YXRlIHRpbWVyIgogICAgICAgIHN0ZWFkeVN0YXRlVGltZT0wCiAgICAgIGZpCiAgICBmaQogICAgbGFzdENjb3VudD0kY2NvdW50CiAgZG9uZQogIGxvZ2dlciAiUmVjb3Zlcnk6IFJlY292ZXJ5IENvbXBsZXRlIFRpbWVvdXQiCn0KCnNldFJjdU5vcm1hbCgpIHsKICBlY2hvICJTZXR0aW5nIHJjdV9ub3JtYWwgdG8gMSIKICBlY2hvIDEgPiAvc3lzL2tlcm5lbC9yY3Vfbm9ybWFsCn0KCm1haW4oKSB7CiAgd2FpdEZvclJlYWR5CiAgZWNobyAiV2FpdGluZyBmb3Igc3RlYWR5IHN0YXRlIHRvb2s6ICQoYXdrICd7cHJpbnQgaW50KCQxLzM2MDApImgiLCBpbnQoKCQxJTM2MDApLzYwKSJtIiwgaW50KCQxJTYwKSJzIn0nIC9wcm9jL3VwdGltZSkiCiAgc2V0UmN1Tm9ybWFsCn0KCmlmIFtbICIke0JBU0hfU09VUkNFWzBdfSIgPSAiJHswfSIgXV07IHRoZW4KICBtYWluICIke0B9IgogIGV4aXQgJD8KZmkK
          mode: 493
          path: /usr/local/bin/set-rcu-normal.sh
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Disable rcu_expedited after node has finished booting by setting rcu_normal to 1

            [Service]
            Type=simple
            ExecStart=/usr/local/bin/set-rcu-normal.sh

            # Maximum wait time is 600s = 10m:
            Environment=MAXIMUM_WAIT_TIME=600

            # Steady-state threshold = 2%
            # Allowed values:
            #  4  - absolute pod count (+/-)
            #  4% - percent change (+/-)
            #  -1 - disable the steady-state check
            # Note: '%' must be escaped as '%%' in systemd unit files
            Environment=STEADY_STATE_THRESHOLD=2%%

            # Steady-state window = 120s
            # If the running pod count stays within the given threshold for this time
            # period, return CPU utilization to normal before the maximum wait time has
            # expires
            Environment=STEADY_STATE_WINDOW=120

            # Steady-state minimum = 40
            # Increasing this will skip any steady-state checks until the count rises above
            # this number to avoid false positives if there are some periods where the
            # count doesn't increase but we know we can't be at steady-state yet.
            Environment=STEADY_STATE_MINIMUM=40

            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: set-rcu-normal.service

3.2.5. 通信事業者向け RAN DU 参照設定ソフトウェア仕様

以下の情報は、通信事業者向け RAN DU 参照デザイン仕様 (RDS) 検証済みソフトウェアバージョンを説明しています。

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

Red Hat telco RAN DU 4.16 ソリューションは、次に示す OpenShift Container Platform のマネージドクラスターおよびハブクラスター用の Red Hat ソフトウェア製品を使用して検証されています。

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

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

4.16

Cluster Logging Operator

6.0

Local Storage Operator

4.16

PTP Operator

4.16

SRIOV Operator

4.16

Node Tuning Operator

4.16

Logging Operator

4.16

SRIOV-FEC Operator

2.9

Expand
表3.8 ハブクラスターの検証済みソフトウェアコンポーネント
コンポーネントソフトウェアバージョン

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

4.16

GitOps ZTP プラグイン

4.16

Red Hat Advanced Cluster Management (RHACM)

2.10, 2.11

Red Hat OpenShift GitOps

1.16

Topology Aware Lifecycle Manager (TALM)

4.16

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

3.3.1. Telco core 4.18 リファレンス設計の概要

通信事業者向けコア参照デザイン仕様 (RDS) は、通信事業者向けコアワークロードをホストするために、コモディティーハードウェア上で実行する OpenShift Container Platform クラスターを設定します。

3.3.2. 通信事業者向けコア 4.16 使用モデルの概要

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

通信事業者向けコア使用モデルアーキテクチャー

Use model architecture

通信事業者向けコア機能のネットワークの前提条件は多岐にわたり、さまざまなネットワーク属性とパフォーマンスベンチマークが含まれます。IPv6 は必須であり、デュアルスタック設定が普及しています。特定の機能では、最大のスループットとトランザクションレートが要求されるため、DPDK などのユーザープレーンネットワークサポートが必要になります。その他の機能は従来のクラウドネイティブパターンに準拠しており、OVN-K、カーネルネットワーキング、負荷分散などのソリューションを使用できます。

Telco コアクラスターは、標準の 3 つのコントロールプレーンクラスターとして設定され、ワーカーノードは標準の非リアルタイム (RT) カーネルで設定します。さまざまなネットワークとパフォーマンスの要件を持つワークロードをサポートするために、ワーカーノードは MachineConfigPool CR を使用してセグメント化されます。たとえば、これは非ユーザーデータプレーンノードを高スループットノードから分離するために行われます。必要な通信事業者向け運用機能をサポートするために、クラスターには Operator Lifecycle Manager (OLM) Day 2 Operator の標準セットがインストールされています。

3.3.2.1. 共通ベースラインモデル

以下の設定と使用モデルの説明は、すべての通信事業者向けコア使用事例に適用できます。

クラスター

クラスターは次の要件に準拠しています。

  • 高可用性 (3 つ以上のスーパーバイザノード) コントロールプレーン
  • スケジュールできないスーパーバイザーノード
  • 複数の MachineConfigPool リソース
ストレージ
コアユースケースでは、外部の OpenShift Data Foundation によって提供される永続ストレージが必要です。詳細は、「参照コア設計コンポーネント」の「ストレージ」を参照してください。
ネットワーク

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

  • デュアルスタック IPv4/IPv6
  • 完全に切断されています。クラスターは、ライフサイクルのどの時点でもパブリックネットワークにアクセスできません。
  • 複数のネットワーク: セグメント化されたネットワークにより、OAM、シグナリング、およびストレージトラフィックが分離されます。
  • クラスターネットワークタイプ: IPv6 のサポートには OVN-Kubernetes が必要です。

コアクラスターには、基盤となる RHCOS、SR-IOV Operator、ロードバランサー、および次の「ネットワーク」セクションで詳述するその他のコンポーネントによってサポートされる複数のネットワークレイヤーがあります。大まかに言えば、これらのレイヤーには次のものが含まれます。

  • クラスターネットワーク: クラスターネットワーク設定は、インストール設定を通じて定義および適用されます。設定の更新は、NMState Operator を通じて 2 日目に実行できます。初期設定では次のことを確立できます。

    • ホストインターフェイスの設定
    • アクティブ/アクティブボンディング (リンクアグリゲーション制御プロトコル (LACP))
  • セカンダリーまたは追加のネットワーク: OpenShift CNI は、Network additionalNetworks または NetworkAttachmentDefinition CR を通じて設定されます。

    • MACVLAN
  • アプリケーションワークロード: ユーザープレーンネットワークは、Cloud-native Network Functions (CNF) で実行しています。
Service Mesh
通信事業者向け CNF による Service Mesh の使用は非常に一般的です。すべてのコアクラスターに Service Mesh 実装が含まれることが予想されます。Service Mesh の実装と設定は、この仕様の範囲外です。
3.3.2.1.1. エンジニアリングの考慮事項共通使用モデル

共通使用モデルには、次のエンジニアリング上の考慮事項が関連します。

ワーカーノード
  • Intel 第 3 世代 Xeon (IceLake) CPU 以上 (OpenShift Container Platform でサポートされている場合)、またはシリコンセキュリティーバグ (Spectre など) の軽減策が無効になっている CPU。Skylake およびそれ以前の CPU では、Spectre や同様の軽減策を有効にすると、トランザクションパフォーマンスが 40% 低下する可能性があります。
  • AMD EPYC Zen 4 CPU (Genoa、Bergamo) または AMD EPYC Zen 5 CPU (Turin) (OpenShift Container Platform でサポートされている場合)。
  • OpenShift Container Platform でサポートされている場合の Intel Sierra Forest CPU。
  • ワーカーノードで IRQ バランシングが有効になっています。PerformanceProfile は、globallyDisableIrqLoadBalancing: false を設定します。保証された QoS Pod には、「参照コア設計コンポーネント」セクションの「CPU パーティショニングとパフォーマンスチューニング」サブセクションで説明されているように、分離を保証するためのアノテーションが付けられます。
全ノード
  • ハイパースレッディングがすべてのノードで有効になっている
  • CPU アーキテクチャーは x86_64 のみ
  • ノードは標準 (非 RT) カーネルを実行している
  • ノードはワークロード分割用に設定されていない

電源管理と最大パフォーマンスの間のノード設定のバランスは、クラスター内の MachineConfigPools によって異なります。この設定は、MachineConfigPool 内のすべてのノードに対して一貫しています。

CPU パーティション設定
CPU パーティショニングは PerformanceProfile を使用して設定され、MachineConfigPool ごとに適用されます。「参照コア設計コンポーネント」の「CPU パーティショニングとパフォーマンスチューニング」サブセクションを参照してください。
3.3.2.1.2. アプリケーションワークロード

コアクラスターで実行しているアプリケーションワークロードには、高性能ネットワーク CNF と従来のベストエフォート型またはバースト可能な Pod ワークロードが混在している場合があります。

保証された QoS スケジューリングは、パフォーマンスまたはセキュリティーの要件により CPU を排他的または専用に使用する必要がある Pod で利用できます。通常、DPDK を使用したユーザープレーンネットワークを利用する、高性能で低レイテンシーに敏感なクラウドネイティブ関数 (CNF) をホストする Pod では、CPU 全体を排他的に使用する必要があります。これは、ノードのチューニングと保証されたサービス品質 (QoS) スケジューリングを通じて実現されます。CPU の排他的使用を必要とする Pod の場合は、ハイパースレッドシステムの潜在的な影響に注意し、コア全体 (2 つのハイパースレッド) を Pod に割り当てる必要がある場合は 2 の倍数の CPU を要求するように設定します。

高スループットと低レイテンシーのネットワークを必要としないネットワーク機能を実行する Pod は、通常、ベストエフォートまたはバースト可能な QoS でスケジュールされ、専用または分離された CPU コアを必要としません。

制限の説明
  • CNF アプリケーションは、Red Hat Best Practices for Kubernetes ガイドの最新バージョンに準拠する必要があります。
  • ベストエフォート型とバースト型 QoS Pod の組み合わせ用。

    • 保証された QoS Pod が使用される可能性がありますが、PerformanceProfile で予約済みおよび分離された CPU を正しく設定する必要があります。
    • 保証された QoS Pod には、CPU を完全に分離するためのアノテーションを含める必要があります。
    • ベストエフォートおよびバースト可能な Pod では、CPU の排他的使用は保証されません。ワークロードは、他のワークロード、オペレーティングシステムデーモン、またはカーネルタスクによってプリエンプトされる可能性があります。
  • 実行可能な代替手段がない限り、exec プローブは回避する必要があります。

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

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

シグナリング作業負荷
  • シグナリングワークロードでは通常、SCTP、REST、gRPC、または同様の TCP プロトコルまたは UDP プロトコルが使用されます。
  • MACVLAN または SR-IOV として設定されたセカンダリー CNI (multus) を使用すると、1 秒あたりのトランザクション数 (TPS) は数十万単位になります。
  • シグナリングワークロードは、保証された QoS またはバースト可能な QoS のいずれかを備えた Pod で実行されます。

3.3.3. 通信事業者向けコア参照設計コンポーネント

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

3.3.3.1. CPU パーティショニングとパフォーマンスチューニング
このリリースの新機能
  • このリリースでは、OpenShift Container Platform デプロイメントはデフォルトで Control Groups バージョン 2 (cgroup v2) を使用します。その結果、クラスター内のパフォーマンスプロファイルは、基盤となるリソース管理レイヤーに cgroups v2 を使用します。
説明
CPU パーティショニングにより、機密性の高いワークロードを一般的な目的、補助プロセス、割り込み、およびドライバー作業キューから分離して、パフォーマンスとレイテンシーを向上させることができます。これらの補助プロセスに割り当てられた CPU は、次のセクションでは reserved と呼ばれます。ハイパースレッドシステムでは、CPU は 1 つのハイパースレッドです。
制限と要件
  • オペレーティングシステムでは、カーネルネットワークを含むすべてのサポートタスクを実行するために、一定量の CPU が必要です。

    • ユーザープレーンネットワーキングアプリケーション (DPDK) のみを備えたシステムでは、オペレーティングシステムとインフラストラクチャーコンポーネント用に少なくとも 1 つのコア (有効な場合は 2 つのハイパースレッド) が予約されている必要があります。
  • ハイパースレッディングが有効になっているシステムでは、常にすべてのコアシブリングスレッドを同じ CPU プールに配置する必要があります。
  • 予約済みコアと分離されたコアのセットには、すべての CPU コアが含まれている必要があります。
  • 各 NUMA ノードのコア 0 は、予約済み CPU セットに含める必要があります。
  • 分離されたコアは割り込みによって影響を受ける可能性があります。保証された QoS Pod で CPU をフルに使用する必要がある場合は、次のアノテーションを Pod に添付する必要があります。

    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
    irq-load-balancing.crio.io: "disable"
  • PerformanceProfile.workloadHints.perPodPowerManagement を使用して Pod ごとの電源管理を有効にすると、保証された QoS Pod で CPU をフルに使用する必要がある場合は、次のアノテーションも Pod に添付する必要があります。

    cpu-c-states.crio.io: "disable"
    cpu-freq-governor.crio.io: "performance"
エンジニアリングに関する考慮事項
  • 必要な最小予約容量 (systemReserved) は、"Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes?" のガイダンスに従ってください。
  • 実際に必要な予約済み CPU 容量は、クラスターの設定とワークロードの属性によって異なります。
  • この予約済み CPU 値は、フルコア (2 ハイパースレッド) の配置に切り上げられる必要があります。
  • CPU パーティショニングを変更すると、MCP 内のノードがドレインされ、再起動されます。
  • 予約された CPU は OpenShift ノードの割り当て可能な容量から削除されるため、Pod 密度が低下します。
  • ワークロードがリアルタイム対応である場合は、リアルタイムワークロードヒントを有効にする必要があります。
  • Interrupt Request (IRQ) アフィニティーをサポートしていないハードウェアは、分離された CPU に影響を与えます。CPU QoS が保証された Pod が割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートする必要があります。
  • OVS は、ネットワークトラフィックのニーズに合わせて cpuset 設定を動的に管理します。プライマリー CNI で高いネットワークスループットを処理するために追加の CPU を予約する必要はありません。
  • クラスター上で実行しているワークロードに cgroups v1 が必要な場合は、cgroups v1 を使用するようにノードを設定できます。この設定は、初期クラスターデプロイメントの一部として行うことができます。詳細は、関連情報 セクションの インストール中に Linux cgroup v1 を有効にする を参照してください。
3.3.3.2. Service Mesh
説明
通常、通信事業者向けコア CNF にはサービスメッシュの実装が必要です。必要な特定の機能とパフォーマンスはアプリケーションによって異なります。Service Mesh の実装と設定の選択は、このドキュメントの範囲外です。Pod ネットワーキングに導入される追加のレイテンシーなど、Service Mesh がクラスターリソースの使用率とパフォーマンスに与える影響は、全体的なソリューションエンジニアリングで考慮する必要があります。
3.3.3.3. ネットワーク

OpenShift Container Platform のネットワーキングは、1 つまたは複数のハイブリッドクラスターのネットワークトラフィックを管理するためにクラスターが必要とする高度なネットワーク関連機能で Kubernetes ネットワーキングを拡張する機能、プラグイン、高度なネットワーク機能のエコシステムです。

3.3.3.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 クラスターをサポートするには、接続されたネットワーク機器を同じ値またはそれ以上の値に設定する必要があります。
  • MACVLAN と IPVLAN は、同じ基礎カーネルメカニズム、具体的には rx_handler に依存しているため、同じメインインターフェイス上に配置できません。このハンドラーを使用すると、ホストが受信パケットを処理する前にサードパーティーモジュールが受信パケットを処理できるようになります。このようなハンドラーは、ネットワークインターフェイスごとに 1 つだけ登録できます。MACVLAN と IPVLAN は両方とも、機能するために独自の rx_handler を登録する必要があるため、競合が発生し、同じインターフェイス上で共存することはできません。詳細は、ipvlan/ipvlan_main.c#L82 および net/macvlan.c#L1260 を参照してください。
  • 代替の NIC 設定としては、共有 NIC を複数の NIC に分割したり、単一のデュアルポート NIC を使用したりすることが挙げられます。

    重要

    共有 NIC を複数の NIC に分割したり、単一のデュアルポート NIC を使用したりすることは、通信事業者向けコアリファレンス設計では検証されていません。

  • シングルスタック IP クラスターは検証されていません。
エンジニアリングに関する考慮事項
  • Pod の Egress トラフィックは、routingViaHost オプションを使用してカーネルルーティングテーブルによって処理されます。ホストに適切な静的ルートを設定する必要があります。
3.3.3.3.2. ロードバランサー
このリリースの新機能
  • OpenShift Container Platform 4.17 では、frr-k8s がデフォルトで完全にサポートされる Border Gateway Protocol (BGP) バックエンドになりました。非推奨となった frr BGP モードは引き続き利用可能です。frr-k8s バックエンドを使用するには、クラスターをアップグレードする必要があります。
説明

MetalLB は、ベアメタルクラスター用の標準ルーティングプロトコルを使用するロードバランサー実装です。これにより、Kubernetes サービスは外部 IP アドレスを取得できるようになり、その IP アドレスはクラスターのホストネットワークにも追加されます。

注記

一部のユースケースでは、ステートフルロードバランシングなど、MetalLB では利用できない機能が必要になる場合があります。必要に応じて、外部のサードパーティーロードバランサーを使用します。外部ロードバランサーの選択と設定は、このドキュメントの対象外となります。外部のサードパーティーロードバランサーを使用する場合は、パフォーマンスとリソース使用率のすべての要件を満たしていることを確認してください。

制限と要件
  • ステートフルロードバランシングは MetalLB ではサポートされていません。これがワークロード CNF の要件である場合は、代替ロードバランサー実装を使用する必要があります。
  • ネットワークインフラストラクチャーでは、外部 IP アドレスがクライアントからクラスターのホストネットワークにルーティング可能であることを保証する必要があります。
エンジニアリングに関する考慮事項
  • MetalLB は、コアユースケースモデルの BGP モードでのみ使用されます。
  • 通信コア使用モデルの場合、MetalLB は、OVN-Kubernetes ネットワークプラグインの ovnKubernetesConfig.gatewayConfig 仕様で routingViaHost=true を設定した場合にのみサポートされます。
  • MetalLB での BGP 設定は、ネットワークとピアの要件によって異なります。
  • アドレスプールは必要に応じて設定でき、アドレス、集約長、自動割り当て、その他の関連パラメーターを変更できます。
  • MetalLB はルートのアナウンスにのみ BGP を使用します。このモードでは、transmitInterval および minimumTtl パラメーターのみが関連します。BFD プロファイル内の他のパラメーターは、デフォルト設定に近いままにしておく必要があります。値が短いとエラーが発生し、パフォーマンスに影響する可能性があります。
3.3.3.3.3. SR-IOV
このリリースの新機能
  • このリリースでは、SR-IOV Network Operator を使用して QinQ (802.1ad および 802.1q) タグ付けを設定できます。QinQ タグ付けは、内部 VLAN タグと外部 VLAN タグの両方の使用を可能にすることで、効率的なトラフィック管理を実現します。外部 VLAN タグ付けはハードウェアアクセラレーションされており、ネットワークパフォーマンスが向上します。この更新は SR-IOV Network Operator 自体を超えて拡張されます。nmstate を使用して外部 VLAN タグを設定することで、外部のマネージド VF 上で QinQ を設定できるようになりました。QinQ のサポートは NIC によって異なります。特定の NIC モデルの既知の制限事項の包括的なリストについては、公式ドキュメントを参照してください。
  • このリリースでは、ネットワークポリシーの更新中にノードを並行してドレインするように SR-IOV Network Operator を設定できるため、セットアッププロセスが大幅に高速化されます。これは、特に以前は完了までに数時間、場合によっては数日かかっていた大規模なクラスターのデプロイメントにおいて、大幅な時間の節約につながります。
説明
SR-IOV を使用すると、物理ネットワークインターフェイス (PF) を複数の Virtual Function (VF) に分割できます。その後、VF を複数の Pod に割り当てることで、Pod を分離したまま、より高いスループットパフォーマンスを実現できます。SR-IOV Network Operator は、SR-IOV CNI、ネットワークデバイスプラグイン、および SR-IOV スタックのその他のコンポーネントをプロビジョニングおよび管理します。
制限と要件
  • サポートされているネットワークインターフェイスコントローラーは、サポートされているデバイス に記載されています。
  • BIOS での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウンの検出が必要な場合は、プロトコルレベルで実行する必要があります。
  • MultiNetworkPolicy CR は、netdevice ネットワークにのみ適用できます。これは、実装では vfio インターフェイスを管理できない iptables ツールが使用されるためです。
エンジニアリングに関する考慮事項
  • vfio モードの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーション用に追加のセカンダリーネットワークを有効にするために使用されます。
  • デプロイメントから SriovOperatorConfig CR を除外すると、CR は自動的に作成されません。
3.3.3.3.4. NMState Operator
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
NMState Operator は、クラスターのノード全体でネットワーク設定を実行するための Kubernetes API を提供します。これにより、ネットワークインターフェイス設定、静的 IP と DNS、VLAN、トランク、ボンディング、静的ルート、MTU、およびセカンダリーインターフェイスでの無差別モードの有効化が可能になります。クラスターノードは、各ノードのネットワークインターフェイスの状態を API サーバーに定期的に報告します。
制限と要件
該当なし
エンジニアリングに関する考慮事項
  • 初期ネットワーク設定は、インストール CR の NMStateConfig コンテンツを使用して適用されます。NMState Operator は、ネットワーク更新に必要な場合にのみ使用されます。
  • SR-IOV Virtual Function がホストネットワークに使用される場合は、NodeNetworkConfigurationPolicy を使用する NMState Operator を使用して、VLAN や MTU などの VF インターフェイスが設定されます。
3.3.3.4. ロギング
このリリースの新機能
  • Cluster Logging Operator 6.0 はこのリリースの新機能です。既存の実装を更新して、新しいバージョンの API に適応させます。ポリシーを使用して、古い Operator アーティファクトを削除する必要があります。詳細は、関連情報 を参照してください。
説明
Cluster Logging Operator を使用すると、リモートアーカイブと分析のために、ノードからログを収集して送信できます。参照設定では、Kafka を使用して監査ログとインフラストラクチャーログをリモートアーカイブに送信します。
制限と要件
該当なし
エンジニアリングに関する考慮事項
  • クラスターの CPU 使用率の影響は、生成されるログの数またはサイズと、設定されたログフィルタリングの量によって決まります。
  • 参照設定には、アプリケーションログの送信は含まれません。設定にアプリケーションログを含めるには、アプリケーションのログ記録レートを評価し、予約セットに十分な追加の CPU リソースを割り当てる必要があります。
3.3.3.5. 電源管理
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
パフォーマンスプロファイル を使用して、クラスターを高電力モード、低電力モード、または混合モードで設定できます。電源モードの選択は、クラスター上で実行しているワークロードの特性、特にレイテンシーに対する敏感さによって異なります。Pod ごとの電源管理 C ステート機能を使用して、低レイテンシー Pod の最大遅延を設定します。

詳細は、ノードの省電力設定を 参照してください。

制限と要件
  • 電源設定は、C ステートや P ステートの有効化など、適切な BIOS 設定に依存します。設定はハードウェアベンダーによって異なります。
エンジニアリングに関する考慮事項
  • レイテンシー: レイテンシーの影響を受けやすいワークロードが要件を満たすようにするには、高電力設定または Pod ごとの電源管理設定のいずれかが必要になります。Pod ごとの電源管理は、専用の固定 CPU を備えた Guaranteed QoS Pod でのみ使用できます。
3.3.3.6. ストレージ
概要

クラウドネイティブストレージサービスは、Red Hat またはサードパーティーの OpenShift Data Foundation を含む複数のソリューションによって提供できます。

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

注記

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

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

他のストレージソリューションを使用して、コアクラスターに永続的なストレージを提供することもできます。これらのソリューションの設定と統合は、通信事業者向けコア RDS の範囲外です。ストレージソリューションをコアクラスターに統合する場合は、ストレージが全体的なパフォーマンスとリソース使用率の要件を満たしていることを確認するために、適切なサイズ設定とパフォーマンス分析を行う必要があります。

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

Cluster Monitoring Operator (CMO) は、すべての OpenShift クラスターにデフォルトで含まれており、プラットフォームコンポーネントとオプションでユーザープロジェクトのモニタリング (メトリクス、ダッシュボード、アラート) を提供します。

モニタリング Operator の設定では、次のようなカスタマイズが可能です。

  • デフォルトの保存期間
  • カスタムアラートルール

Pod の CPU とメモリーのメトリクスのデフォルトの処理は、アップストリームの Kubernetes cAdvisor に基づいており、メトリクスの精度よりも古いデータの処理を優先するトレードオフが行われます。これにより、データが急激に変化し、ユーザーが指定したしきい値を超えると、誤ってアラートがトリガーされることになります。OpenShift は、スパイク動作の影響を受けない Pod CPU およびメモリーメトリクスの追加セットを作成する、オプトインの専用サービスモニター機能をサポートしています。詳細は、このソリューションガイド を参照してください。

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

  • ユーザーワークロードの Pod CPU とメモリーのメトリクスとアラート
制限と要件
  • モニタリング設定では、Pod メトリクスを正確に表現するために専用のサービスモニター機能を有効にする必要があります。
エンジニアリングに関する考慮事項
  • Prometheus の保持期間はユーザーによって指定されます。使用される値は、クラスター上の履歴データを維持するための運用要件と、CPU およびストレージリソースとの間のトレードオフです。保持期間が長くなると、ストレージの必要性が高まり、データのインデックス管理に追加の CPU が必要になります。
3.3.3.8. スケジューリング
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
  • スケジューラーは、特定のワークロードに対して適切なノードを選択するロールを担う、クラスター全体のコンポーネントです。これはプラットフォームの中核部分であり、一般的なデプロイメントシナリオでは特別な設定は必要ありません。ただし、次のセクションで説明する具体的な使用例はほとんどありません。NUMA 対応スケジューリングは、NUMA リソース Operator を通じて有効にできます。詳細は、NUMA 対応ワークロードのスケジューリング を参照してください。
制限と要件
  • デフォルトのスケジューラーはワークロードの NUMA 局所性を理解しません。ワーカーノード上のすべての空きリソースの合計のみを認識します。これにより、Topology Manager ポリシーsingle-numa-node または restricted に設定されているノードにスケジュールされた場合にワークロードが拒否される可能性があります。

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

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

  • 宣言型 CR からのインストール
  • インストールをサポートするために追加のサーバーは必要ありません
  • 非接続環境でのインストールをサポート
制限と要件
  • 切断されたインストールには、必要なすべてのコンテンツがミラーリングされたアクセス可能なレジストリーが必要です。
エンジニアリングに関する考慮事項
  • ネットワーク設定は、NMState Operator を使用した Day-2 設定よりも優先して、インストール中に NMState 設定として適用する必要があります。
3.3.3.10. セキュリティー
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

通信事業者向け Operator はセキュリティーを重視しており、複数の攻撃ベクトルに対してクラスターを強化する必要があります。OpenShift Container Platform 内には、クラスターのセキュリティー保護を担当する単一のコンポーネントや機能はありません。このセクションでは、この仕様でカバーされている使用モデルのセキュリティー指向の機能と設定の詳細を説明します。

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

    • container_t SELinux コンテキストを使用して TAP プラグインを設定します。
    • ホスト上で container_use_devices SELinux ブール値を有効にします。
エンジニアリングに関する考慮事項
  • ルートレス DPDK Pod のサポートの場合、TAP デバイスを作成するには、ホスト上で SELinux ブール値 container_use_devices を有効にする必要があります。これにより、短期から中期の使用では許容できるセキュリティーリスクが発生します。他の解決策も検討されます。
3.3.3.11. スケーラビリティー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

クラスターは、制限と要件のセクションに記載されているサイズに合わせてスケーリングされます。

ワークロードのスケーリングについては、使用モデルのセクションで説明します。

制限と要件
  • クラスターは少なくとも 120 ノードまで拡張可能
エンジニアリングに関する考慮事項
該当なし
3.3.3.12. 追加の設定
3.3.3.12.1. 非接続環境
説明

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

  • セキュリティーのためにクラスターへのアクセスを制限する
  • キュレーションされたコンテンツ: レジストリーは、クラスターのキュレーションされ承認された更新に基づいて作成されます。
制限と要件
  • すべてのカスタム CatalogSources には一意の名前が必要です。デフォルトのカタログ名を再利用しないでください。
  • 有効なタイムソースは、クラスターのインストールの一部として設定する必要があります。
エンジニアリングに関する考慮事項
該当なし
3.3.3.12.2. カーネル
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

ユーザーは、MachineConfig を使用して次のカーネルモジュールをインストールし、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
制限と要件
  • これらのカーネルモジュールを通じて利用可能な機能の使用は、CPU 負荷、システムパフォーマンス、および KPI を維持する能力への影響を判断するためにユーザーが分析する必要があります。

    注記

    ツリー外のドライバーはサポートされていません。

エンジニアリングに関する考慮事項
該当なし

3.3.4. 通信事業者向けコア 4.16 参照設定 CR

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

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

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

前提条件

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

手順

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

    $ mkdir -p ./out
    $ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.16 | base64 -d | tar xv -C out

検証

  • out ディレクトリーのフォルダー構造は次のとおりです。通信事業者向けコア CR は、out/telco-core-rds/ ディレクトリーで表示できます。

    出力例

    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.3.4.2. リソース調整参照 CR
Expand
表3.9 リソース調整 CR
コンポーネント参照 CR任意このリリースの新機能

システム予約容量

control-plane-system-reserved.yaml

はい

いいえ

3.3.4.3. ストレージのリファレンス CR
Expand
表3.10 ストレージ CR
コンポーネント参照 CR任意このリリースの新機能

外部 ODF 設定

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

いいえ

いいえ

外部 ODF 設定

02-ocs-external-storagecluster.yaml

いいえ

いいえ

外部 ODF 設定

odfNS.yaml

いいえ

いいえ

外部 ODF 設定

odfOperGroup.yaml

いいえ

いいえ

外部 ODF 設定

odfSubscription.yaml

いいえ

いいえ

3.3.4.4. ネットワークのリファレンス CR
Expand
表3.11 ネットワーク CR
コンポーネント参照 CR任意このリリースの新機能

ベースライン

Network.yaml

いいえ

いいえ

ベースライン

networkAttachmentDefinition.yaml

はい

はい

ロードバランサー

addr-pool.yaml

いいえ

いいえ

ロードバランサー

bfd-profile.yaml

いいえ

いいえ

ロードバランサー

bgp-advr.yaml

いいえ

いいえ

ロードバランサー

bgp-peer.yaml

いいえ

いいえ

ロードバランサー

community.yaml

はい

はい

ロードバランサー

metallb.yaml

いいえ

いいえ

ロードバランサー

metallbNS.yaml

はい

いいえ

ロードバランサー

metallbOperGroup.yaml

はい

いいえ

ロードバランサー

metallbSubscription.yaml

いいえ

いいえ

Multus - ルートレス DPDK Pod 用の CNI をタップ

mc_rootless_pods_selinux.yaml

いいえ

いいえ

NMState Operator

NMState.yaml

いいえ

はい

NMState Operator

NMStateNS.yaml

いいえ

はい

NMState Operator

NMStateOperGroup.yaml

いいえ

はい

NMState Operator

NMStateSubscription.yaml

いいえ

はい

SR-IOV Network Operator

sriovNetwork.yaml

はい

いいえ

SR-IOV Network Operator

sriovNetworkNodePolicy.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovOperatorConfig.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscription.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscriptionNS.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscriptionOperGroup.yaml

いいえ

いいえ

3.3.4.5. スケジューリングのリファレンス CR
Expand
表3.12 CR のスケジューリング
コンポーネント参照 CR任意このリリースの新機能

NUMA 対応スケジューラー

nrop.yaml

いいえ

いいえ

NUMA 対応スケジューラー

NROPSubscription.yaml

いいえ

いいえ

NUMA 対応スケジューラー

NROPSubscriptionNS.yaml

いいえ

いいえ

NUMA 対応スケジューラー

NROPSubscriptionOperGroup.yaml

いいえ

いいえ

NUMA 対応スケジューラー

sched.yaml

いいえ

いいえ

NUMA 対応スケジューラー

Scheduler.yaml

いいえ

はい

3.3.4.6. その他の参照 CR
Expand
表3.13 その他の CR
コンポーネント参照 CR任意このリリースの新機能

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

control-plane-load-kernel-modules.yaml

はい

いいえ

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

sctp_module_mc.yaml

はい

いいえ

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

worker-load-kernel-modules.yaml

はい

いいえ

クラスターロギング

ClusterLogForwarder.yaml

いいえ

いいえ

クラスターロギング

ClusterLogging.yaml

いいえ

いいえ

クラスターロギング

ClusterLogNS.yaml

いいえ

いいえ

クラスターロギング

ClusterLogOperGroup.yaml

いいえ

いいえ

クラスターロギング

ClusterLogSubscription.yaml

いいえ

いいえ

非接続設定

catalog-source.yaml

いいえ

いいえ

非接続設定

icsp.yaml

いいえ

いいえ

非接続設定

operator-hub.yaml

いいえ

いいえ

監視および可観測性

monitoring-config-cm.yaml

はい

いいえ

電源管理

PerformanceProfile.yaml

いいえ

いいえ

3.3.4.7. YAML リファレンス
3.3.4.7.1. リソースチューニング参照 YAML

control-plane-system-reserved.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: autosizing-master
spec:
  autoSizingReserved: true
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/master: ""

3.3.4.7.2. ストレージ参照 YAML

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

# required
# count: 1
---
apiVersion: v1
kind: Secret
metadata:
  name: rook-ceph-external-cluster-details
  namespace: openshift-storage
type: Opaque
data:
  # encoded content has been made generic
  external_cluster_details: eyJuYW1lIjoicm9vay1jZXBoLW1vbi1lbmRwb2ludHMiLCJraW5kIjoiQ29uZmlnTWFwIiwiZGF0YSI6eyJkYXRhIjoiY2VwaHVzYTE9MS4yLjMuNDo2Nzg5IiwibWF4TW9uSWQiOiIwIiwibWFwcGluZyI6Int9In19LHsibmFtZSI6InJvb2stY2VwaC1tb24iLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJhZG1pbi1zZWNyZXQiOiJhZG1pbi1zZWNyZXQiLCJmc2lkIjoiMTExMTExMTEtMTExMS0xMTExLTExMTEtMTExMTExMTExMTExIiwibW9uLXNlY3JldCI6Im1vbi1zZWNyZXQifX0seyJuYW1lIjoicm9vay1jZXBoLW9wZXJhdG9yLWNyZWRzIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsidXNlcklEIjoiY2xpZW50LmhlYWx0aGNoZWNrZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoibW9uaXRvcmluZy1lbmRwb2ludCIsImtpbmQiOiJDZXBoQ2x1c3RlciIsImRhdGEiOnsiTW9uaXRvcmluZ0VuZHBvaW50IjoiMS4yLjMuNCwxLjIuMy4zLDEuMi4zLjIiLCJNb25pdG9yaW5nUG9ydCI6IjkyODMifX0seyJuYW1lIjoiY2VwaC1yYmQiLCJraW5kIjoiU3RvcmFnZUNsYXNzIiwiZGF0YSI6eyJwb29sIjoib2RmX3Bvb2wifX0seyJuYW1lIjoicm9vay1jc2ktcmJkLW5vZGUiLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJ1c2VySUQiOiJjc2ktcmJkLW5vZGUiLCJ1c2VyS2V5IjoiIn19LHsibmFtZSI6InJvb2stY3NpLXJiZC1wcm92aXNpb25lciIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7InVzZXJJRCI6ImNzaS1yYmQtcHJvdmlzaW9uZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoicm9vay1jc2ktY2VwaGZzLXByb3Zpc2lvbmVyIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsiYWRtaW5JRCI6ImNzaS1jZXBoZnMtcHJvdmlzaW9uZXIiLCJhZG1pbktleSI6IiJ9fSx7Im5hbWUiOiJyb29rLWNzaS1jZXBoZnMtbm9kZSIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7ImFkbWluSUQiOiJjc2ktY2VwaGZzLW5vZGUiLCJhZG1pbktleSI6ImMyVmpjbVYwIn19LHsibmFtZSI6ImNlcGhmcyIsImtpbmQiOiJTdG9yYWdlQ2xhc3MiLCJkYXRhIjp7ImZzTmFtZSI6ImNlcGhmcyIsInBvb2wiOiJtYW5pbGFfZGF0YSJ9fQ==

02-ocs-external-storagecluster.yaml

# required
# count: 1
---
apiVersion: ocs.openshift.io/v1
kind: StorageCluster
metadata:
  name: ocs-external-storagecluster
  namespace: openshift-storage
spec:
  externalStorage:
    enable: true
  labelSelector: {}
status:
  phase: Ready

odfNS.yaml

# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-storage
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

odfOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-storage-operatorgroup
  namespace: openshift-storage
spec:
  targetNamespaces:
    - openshift-storage

odfSubscription.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: odf-operator
  namespace: openshift-storage
spec:
  channel: "stable-4.14"
  name: odf-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
status:
  state: AtLatestKnown

3.3.4.7.3. ネットワーク参照 YAML

Network.yaml

# required
# count: 1
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      gatewayConfig:
        routingViaHost: true
  # additional networks are optional and may alternatively be specified using NetworkAttachmentDefinition CRs
  additionalNetworks: [$additionalNetworks]
  # eg
  #- name: add-net-1
  #  namespace: app-ns-1
  #  rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "add-net-1", "plugins": [{"type": "macvlan", "master": "bond1", "ipam": {}}] }'
  #  type: Raw
  #- name: add-net-2
  #  namespace: app-ns-1
  #  rawCNIConfig: '{ "cniVersion": "0.4.0", "name": "add-net-2", "plugins": [ {"type": "macvlan", "master": "bond1", "mode": "private" },{ "type": "tuning", "name": "tuning-arp" }] }'
  #  type: Raw

  # Enable to use MultiNetworkPolicy CRs
  useMultiNetworkPolicy: true

networkAttachmentDefinition.yaml

# optional
# copies: 0-N
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: $name
  namespace: $ns
spec:
  nodeSelector:
    kubernetes.io/hostname: $nodeName
  config: $config
  #eg
  #config: '{
  #  "cniVersion": "0.3.1",
  #  "name": "external-169",
  #  "type": "vlan",
  #  "master": "ens8f0",
  #  "mode": "bridge",
  #  "vlanid": 169,
  #  "ipam": {
  #    "type": "static",
  #  }
  #}'

addr-pool.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: $name # eg addresspool3
  namespace: metallb-system
  annotations:
    metallb.universe.tf/address-pool: $name # eg addresspool3
spec:
  ##############
  # Expected variation in this configuration
  addresses: [$pools]
  #- 3.3.3.0/24
  autoAssign: true
  ##############

bfd-profile.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BFDProfile
metadata:
  name: bfdprofile
  namespace: metallb-system
spec:
  ################
  # These values may vary. Recommended values are included as default
  receiveInterval: 150 # default 300ms
  transmitInterval: 150 # default 300ms
  #echoInterval: 300 # default 50ms
  detectMultiplier: 10 # default 3
  echoMode: true
  passiveMode: true
  minimumTtl: 5 # default 254
  #
  ################

bgp-advr.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: $name # eg bgpadvertisement-1
  namespace: metallb-system
spec:
  ipAddressPools: [$pool]
  # eg:

  #  - addresspool3
  peers: [$peers]
  # eg:

  #    - peer-one
  # 
  communities: [$communities]
  # Note correlation with address pool, or Community
  # eg:

  #    - bgpcommunity
  #    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100

bgp-peer.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
  name: $name
  namespace: metallb-system
spec:
  peerAddress: $ip # eg 192.168.1.2
  peerASN: $peerasn # eg 64501
  myASN: $myasn # eg 64500
  routerID: $id # eg 10.10.10.10
  bfdProfile: bfdprofile
  passwordSecret: {}

community.yaml

---
apiVersion: metallb.io/v1beta1
kind: Community
metadata:
  name: bgpcommunity
  namespace: metallb-system
spec:
  communities: [$comm]

metallb.yaml

# required
# count: 1
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""

metallbNS.yaml

# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
  name: metallb-system
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

metallbOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system

metallbSubscription.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator-sub
  namespace: metallb-system
spec:
  channel: stable
  name: metallb-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
status:
  state: AtLatestKnown

mc_rootless_pods_selinux.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-setsebool
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Set SELinux boolean for tap cni plugin
            Before=kubelet.service

            [Service]
            Type=oneshot
            ExecStart=/sbin/setsebool container_use_devices=on
            RemainAfterExit=true

            [Install]
            WantedBy=multi-user.target graphical.target
          enabled: true
          name: setsebool.service

NMState.yaml

apiVersion: nmstate.io/v1
kind: NMState
metadata:
  name: nmstate
spec: {}

NMStateNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nmstate
  annotations:
    workload.openshift.io/allowed: management

NMStateOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-nmstate
  namespace: openshift-nmstate
spec:
  targetNamespaces:
    - openshift-nmstate

NMStateSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kubernetes-nmstate-operator
  namespace: openshift-nmstate
spec:
  channel: "stable"
  name: kubernetes-nmstate-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
status:
  state: AtLatestKnown

sriovNetwork.yaml

# optional (though expected for all)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: $name # eg sriov-network-abcd
  namespace: openshift-sriov-network-operator
spec:
  capabilities: "$capabilities" # eg '{"mac": true, "ips": true}'
  ipam: "$ipam" # eg '{ "type": "host-local", "subnet": "10.3.38.0/24" }'
  networkNamespace: $nns # eg cni-test
  resourceName: $resource # eg resourceTest

sriovNetworkNodePolicy.yaml

# optional (though expected in all deployments)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: $name
  namespace: openshift-sriov-network-operator
spec: {} # $spec
# eg
#deviceType: netdevice
#nicSelector:
#  deviceID: "1593"
#  pfNames:
#  - ens8f0np0#0-9
#  rootDevices:
#  - 0000:d8:00.0
#  vendor: "8086"
#nodeSelector:
#  kubernetes.io/hostname: host.sample.lab
#numVfs: 20
#priority: 99
#excludeTopology: true
#resourceName: resourceNameABCD

SriovOperatorConfig.yaml

# required
# count: 1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  enableInjector: true
  enableOperatorWebhook: true
  disableDrain: false
  logLevel: 2

SriovSubscription.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "stable"
  name: sriov-network-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
status:
  state: AtLatestKnown

SriovSubscriptionNS.yaml

# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management

SriovSubscriptionOperGroup.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
    - openshift-sriov-network-operator

3.3.4.7.4. スケジュール参照 YAML

nrop.yaml

# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
    - config:
        # Periodic is the default setting
        infoRefreshMode: Periodic
      machineConfigPoolSelector:
        matchLabels:
          # This label must match the pool(s) you want to run NUMA-aligned workloads
          pools.operator.machineconfiguration.openshift.io/worker: ""

NROPSubscription.yaml

# required
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  channel: "4.14"
  name: numaresources-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace

NROPSubscriptionNS.yaml

# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-numaresources
  annotations:
    workload.openshift.io/allowed: management

NROPSubscriptionOperGroup.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  targetNamespaces:
    - openshift-numaresources

sched.yaml

# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  #cacheResyncPeriod: "0"
  # Image spec should be the latest for the release
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.14.0"
  #logLevel: "Trace"
  schedulerName: topo-aware-scheduler

Scheduler.yaml

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
spec:
  # non-schedulable control plane is the default. This ensures
  # compliance.
  mastersSchedulable: false
  policy:
    name: ""

3.3.4.7.5. その他の参照 YAML

control-plane-load-kernel-modules.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 40-load-kernel-modules-control-plane
spec:
  config:
    # Release info found in https://github.com/coreos/butane/releases
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:,
          mode: 420
          overwrite: true
          path: /etc/modprobe.d/kernel-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwo=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf

sctp_module_mc.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: load-sctp-module
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,c2N0cA==
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

worker-load-kernel-modules.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 40-load-kernel-modules-worker
spec:
  config:
    # Release info found in https://github.com/coreos/butane/releases
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:,
          mode: 420
          overwrite: true
          path: /etc/modprobe.d/kernel-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwo=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf

ClusterLogForwarder.yaml

# required
# count: 1
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
    - type: "kafka"
      name: kafka-open
      url: tcp://10.11.12.13:9092/test
  pipelines:
    - inputRefs:
        - infrastructure
        #- application
        - audit
      labels:
        label1: test1
        label2: test2
        label3: test3
        label4: test4
        label5: test5
      name: all-to-default
      outputRefs:
        - kafka-open

ClusterLogging.yaml

# required
# count: 1
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    type: vector
  managementState: Managed

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  targetNamespaces:
    - openshift-logging

ClusterLogSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
status:
  state: AtLatestKnown

catalog-source.yaml

# required
# count: 1..N
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: redhat-operators-disconnected
  namespace: openshift-marketplace
spec:
  displayName: Red Hat Disconnected Operators Catalog
  image: $imageUrl
  publisher: Red Hat
  sourceType: grpc
#  updateStrategy:
#    registryPoll:
#      interval: 1h
status:
  connectionState:
    lastObservedState: READY

icsp.yaml

# required
# count: 1
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: disconnected-internal-icsp
spec:
  repositoryDigestMirrors: []
#    - $mirrors

operator-hub.yaml

# required
# count: 1
apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true

monitoring-config-cm.yaml

# optional
# count: 1
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    prometheusK8s:
      retention: 15d
      volumeClaimTemplate:
        spec:
          storageClassName: ocs-external-storagecluster-ceph-rbd
          resources:
            requests:
              storage: 100Gi
    alertmanagerMain:
      volumeClaimTemplate:
        spec:
          storageClassName: ocs-external-storagecluster-ceph-rbd
          resources:
            requests:
              storage: 20Gi

PerformanceProfile.yaml

# required
# count: 1
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: $name
  annotations:
    # Some pods want the kernel stack to ignore IPv6 router Advertisement.
    kubeletconfig.experimental: |
      {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
spec:
  cpu:
    # node0 CPUs: 0-17,36-53
    # node1 CPUs: 18-34,54-71
    # siblings: (0,36), (1,37)...
    # we want to reserve the first Core of each NUMA socket
    #
    # no CPU left behind! all-cpus == isolated + reserved
    isolated: $isolated # eg 1-17,19-35,37-53,55-71
    reserved: $reserved # eg 0,18,36,54
  # Guaranteed QoS pods will disable IRQ balancing for cores allocated to the pod.
  # default value of globallyDisableIrqLoadBalancing is false
  globallyDisableIrqLoadBalancing: false
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      # 32GB per numa node
      - count: $count # eg 64
        size: 1G
  machineConfigPoolSelector:
    # For SNO: machineconfiguration.openshift.io/role: 'master'
    pools.operator.machineconfiguration.openshift.io/worker: ''
  nodeSelector:
    # For SNO: node-role.kubernetes.io/master: ""
    node-role.kubernetes.io/worker: ""
  workloadHints:
    realTime: false
    highPowerConsumption: false
    perPodPowerManagement: true
  realTimeKernel:
    enabled: false
  numa:
    # All guaranteed QoS containers get resources from a single NUMA node
    topologyPolicy: "single-numa-node"
  net:
    userLevelNetworking: false

3.3.5. 通信事業者向けコア参照設定ソフトウェア仕様

以下の情報は、通信事業者向けコア参照デザイン仕様 (RDS) 検証済みソフトウェアバージョンを説明しています。

3.3.5.1. ソフトウェアスタック

通信事業者向けコア参照デザイン仕様の検証には、次のソフトウェアバージョンが使用されました。

Expand
表3.14 検証用ソフトウェアバージョン
コンポーネントソフトウェアバージョン

Cluster Logging Operator

6.0

OpenShift Data Foundation

4.16

SR-IOV Operator

4.16

MetalLB

4.16

NMState Operator

4.16

NUMA 対応スケジューラー

4.16

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

クラスターがパフォーマンスとスケーラビリティーの要件を満たすようにするには、テスト済みのオブジェクトの最大数に基づいて環境を計画してください。これらの制限事項を確認することで、サポートされている範囲内で確実に動作する OpenShift Container Platform のデプロイメントを設計できます。

この例示ガイドラインは、可能な限り最大のクラスターを前提としています。小規模なクラスターの場合、最大値はこれより低くなります。指定のしきい値に影響を与える要因には、etcd バージョンやストレージデータ形式などの多数の要因があります。ほとんどの場合、これらの数値を超えると全体的なパフォーマンスは低下しますが、クラスターが故障するとは限りません。

警告

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

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

デプロイメントが継続的にサポートされるようにするには、テスト済みのクラスター最大値を使用してクラスター設定を計画してください。OpenShift Container Platform は、理論上の絶対的なクラスター最大値ではなく、メジャーリリースごとにこれらの具体的な制限を検証することで、環境の安定性を確保します。

注記

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

OpenShift Container Platform は、クラスターの絶対最大値ではなく、テスト済みのクラスター最大値をサポートします。OpenShift Container Platform のバージョン、コントロールプレーンのワークロード、およびネットワークプラグインのすべての組み合わせがテストされているわけではないため、以下の表は、すべてのデプロイメントの規模の絶対的な期待値を表すものではありません。すべての次元で同時に最大値まで拡大することは不可能かもしれない。この表には、特定のワークロードとデプロイメントにおけるテスト済みの最大値が記載されており、同様のデプロイメントで期待できる規模の目安として役立ちます。

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

ノード数

2,000

一時停止 Pod は、2000 ノードスケールで OpenShift Container Platform のコントロールプレーンコンポーネントにストレスをかけるためにデプロイされました。同様の数値にスケーリングできるかどうかは、特定のデプロイメントとワークロードのパラメーターによって異なります。

Pod 数

150,000

ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、およびストレージ要件により異なります。

ノードあたりの Pod 数

2,500

これは、3 台の制御プレーン、2 台のインフラストラクチャーノード、および 26 台のコンピュートノードからなる 31 台のサーバーで設定されるクラスターでテストされました。2,500 のユーザー Pod が必要な場合は、各ノードが 2000 超の Pod を内包できる規模のネットワークを割り当てるために hostPrefix20 に設定し、カスタム kubelet 設定で maxPods2500 に設定する必要があります。詳細は、OCP 4.13 でノードごとに 2500 Pod を実行する を参照してください。

namespace 数

10,000

有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強く推奨します。

ビルド数

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

-

namespace ごとの Pod 数

25,000

システムには、状態遷移への対応として、指定された namespace 内のすべてのオブジェクトに対して反復処理する必要がある制御ループがいくつかあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限は、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。

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

ルーターあたり 2,000

-

シークレットの数

80,000

-

config map の数

90,000

-

サービス数

10,000

各サービスポートと各サービスのバックエンドには、iptables に対応するエントリーがあります。特定のサービスのバックエンドの数は、Endpoints オブジェクトのサイズに影響を与え、システム全体に送信されるデータのサイズに影響を与えます。

namespace ごとのサービス数

5,000

-

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

5,000

-

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

2,000

-

ビルド設定の数

12,000

-

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

1,024

29 台のサーバーで設定されるクラスターでテストを実施しました。内訳は、コントロールプレーン 3 台、インフラストラクチャーノード 2 台、コンピュートノード 24 台です。クラスターには 500 の namespace がありました。OpenShift Container Platform には、OpenShift Container Platform によってインストールされるもの、OpenShift Container Platform と統合する製品、およびユーザーが作成した CRD を含め、合計 1,024 個のカスタムリソース定義 (CRD) という制限があります。作成された CRD の数が 1,024 を超える場合、oc コマンドリクエストのスロットリングが適用される可能性があります。

シナリオ例

例として、OpenShift Container Platform 4.16、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 のクラスターノードリソース消費量
  • メモリーのクラスターノードリソース消費量

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

デプロイメント制限を検証するには、OpenShift Container Platform クラスターの最大値がテストされたクラウドプラットフォームの環境と設定の詳細を確認してください。このリファレンスは、お客様のインフラストラクチャーが、スケーラビリティー制限の検証に使用される特定のシナリオに準拠していることを保証します。

4.2.1. AWS クラウドプラットフォームのクラスター最大数

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

コントロールプレーン/etcd

r5.4xlarge

16

128

gp3

220

3

us-west-2

インフラ

m5.12xlarge

48

192

gp3

100

3

us-west-2

ワークロード

m5.4xlarge

16

64

gp3

500

1

us-west-2

コンピュート

m5.2xlarge

8

32

gp3

100

3/25/250/500

us-west-2

ここでは、以下のようになります。

コントロールプレーン/etcd
etcd はレイテンシーに敏感であるため、コントロールプレーン/etcd ノードでは、ベースライン性能が 3000 IOPS、1 秒あたり 125 MiB の gp3 ディスクを使用します。gp3 ボリュームはバースト性能を使用しません。
インフラ
インフラストラクチャーノードは、モニタリング、Ingress およびレジストリーコンポーネントをホストするために使用され、これにより、それらが大規模に実行する場合に必要とするリソースを十分に確保することができます。
ワークロード

ワークロードノードは、パフォーマンスおよびスケーラビリティーワークロードジェネレーターを実行するために専用に設計されています。

500 GiB というより大きなディスク容量を使用することで、パフォーマンスおよびスケーラビリティーテストの実行中に収集される大量のデータを保存するのに十分なスペースが確保されます。

コンピュート
クラスターは、3、25、250、500 のコンピュートノードという段階的な増加で拡張されます。性能およびスケーラビリティーテストは、指定されたノード数で実行されます。

4.2.2. IBM Power Platform クラスターの最大数

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

コントロールプレーン/etcd

16

32

io1

GiB あたり 120/10 IOPS

3

インフラ

16

64

gp2

120

2

ワークロード

16

256

gp2

120

1

コンピュート

16

64

gp2

120

2-100

ここでは、以下のようになります。

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

4.2.3. IBM Z プラットフォームクラスターの最大規模

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

コントロールプレーン/etcd

8

32

ds8k

300 / LCU 1

3

コンピュート

8

32

ds8k

150 / LCU 2

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

ここでは、以下のようになります。

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

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

インフラストラクチャーが運用要件を満たすようにするには、テスト済みのクラスター最大数に基づいて OpenShift Container Platform 環境を計画してください。これらの検証済みの制限内でクラスターを設計することで、安定性を維持し、デプロイメントのサポートを継続することができます。

重要

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

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

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

環境を計画する際には、次の式を使用して、ノードあたりにいくつの Pod が収容できるかを決定してください。

required pods per cluster / pods per node = total number of nodes needed

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

シナリオ例

クラスターあたり 2200 個の Pod を収容する設定にする場合、ノードあたり最大 500 個の Pod を収容できると仮定すると、少なくとも 5 つのノードが必要になります。計算式は以下のとおりです。

2200 / 500 = 4.4

ノード数を 20 に増やすと、Pod の分布はノードあたり 110 個の Pod に変わります。計算式は以下のとおりです。

2200 / 20 = 110

ここでは、以下のようになります。

required pods per cluster / total number of nodes = expected pods per node

OpenShift Container Platform には、OVN-Kubernetes、DNS、Operator など、複数のシステム Pod が含まれており、これらはデフォルトですべてのコンピュートノード上で実行されます。したがって、上記の式の結果は異なる場合があります。

4.4. アプリケーション要件に合わせて環境計画を立てる方法

インフラストラクチャーがワークロードの要求に効率的に対応できるようにするには、アプリケーションの要件に基づいて環境を計画してください。このように計画を立てることで、パフォーマンスと安定性を維持するために必要なコンピュート、ストレージ、およびネットワークのリソースを特定できます。

アプリケーション環境の例を考えてみましょう。

Expand
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

ノードのインスタンスサイズは、希望に応じて増減を調整できます。ノードのリソースはオーバーコミットされることが多く、デプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。このデプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。運用上の敏捷性やインスタンスあたりのコストなどの要因を考慮する必要があります。

Expand
ノードのタイプ数量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 およびデプロイメントは失敗します。デプロイメントのサービス仕様ファイルのサービスリンクを無効にして、以下を解消します。

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 バイト (2MiB) に設定されています。Kubelet は、名前空間内で実行するようにスケジュールされた各 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 を実行できます。

第5章 クォータと制限範囲の使用

クラスター管理者として、クォータと制限範囲を使用して制約を設定できます。これらの制約は、プロジェクトで使用されるオブジェクトの数、またはコンピュートリソースの量を制限します。

見積もりと制限を活用することで、すべてのプロジェクトにわたってリソースをより適切に管理配分することができます。また、どのプロジェクトもクラスターのサイズに対して適切なリソース量を超えて使用しないようにすることもできます。

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。クォータは、プロジェクト内で作成できるオブジェクトの数を種類ごとに制限することができます。さらに、クォータを設定することで、そのプロジェクト内のリソースが消費する可能性のあるコンピュートリソースとストレージの総量を制限できます。

重要

クォータはクラスター管理者によって設定され、所定プロジェクトにスコープが設定されます。OpenShift Container Platform プロジェクトの所有者は、プロジェクトのクォータを変更できますが、範囲を制限することはできません。OpenShift Container Platform ユーザーは、クォータや制限範囲を変更できません。

5.1. クォータで管理されるリソース

プロジェクトごとの総リソース消費量を制限するには、ResourceQuota オブジェクトを定義します。このオブジェクトを使用することで、種類ごとに作成されるオブジェクトの数を制限できます。プロジェクト内で消費されるコンピュートリソースとストレージの総量を制限することもできます。

以下の表は、クォータが管理する可能性のあるコンピュートリソースとオブジェクトの種類を示しています。

注記

status.phaseFailed または Succeeded の場合、Pod は終了状態になります。

Expand
表5.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 における一時ストレージ制限の合計は、この値を超えることができません。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

Expand
表5.2 クォータで管理されるストレージリソース
リソース名説明

requests.storage

任意の状態のすべての永続ボリューム要求でのストレージ要求の合計は、この値を超えることができません。

persistentvolumeclaims

プロジェクトに存在できる永続ボリューム要求の合計数です。

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

一致するストレージクラスを持つ、任意の状態のすべての永続ボリューム要求でのストレージ要求の合計はこの値を超えることができません。

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

プロジェクトに存在できる、一致するストレージクラスを持つ永続ボリューム要求の合計数です。

Expand
表5.3 クォータで管理されるオブジェクト数
リソース名説明

pods

プロジェクトに存在できる非終了状態の Pod の合計数です。

replicationcontrollers

プロジェクトに存在できるレプリケーションコントローラーの合計数です。

resourcequotas

プロジェクトに存在できるリソースクォータの合計数です。

services

プロジェクトに存在できるサービスの合計数です。

secrets

プロジェクトに存在できるシークレットの合計数です。

configmaps

プロジェクトに存在できる ConfigMap オブジェクトの合計数です。

persistentvolumeclaims

プロジェクトに存在できる永続ボリューム要求の合計数です。

openshift.io/imagestreams

プロジェクトに存在できるイメージストリームの合計数です。

count/<resource>.<group> 構文を使用して、これらの標準の namespace リソースタイプに対してオブジェクトカウントクォータを設定できます。

$ oc create quota <name> --hard=count/<resource>.<group>=<quota>

ここでは、以下のようになります。

<resource>
リソースの名前を指定します。
<group>
該当する場合、API グループを指定します。リソースとその関連 API グループのリストを取得するには、kubectl api-resources コマンドを使用できます。

5.2. 拡張リソースのリソースクォータの設定

nvidia.com/gpu などの拡張リソースの消費を管理するには、requests プレフィックスを使用してリソースクォータを定義します。これらのリソースでは過剰割り当てが禁止されているため、有効な設定を確保するには、要求と制限の両方を明示的に指定する必要があります。

手順

  1. クラスター内のノードで使用可能な GPU の数を確認するには、次のコマンドを使用します。

    $ oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'

    出力例

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

    $ cat gpu-quota.yaml

    出力例

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: gpu-quota
      namespace: nvidia
    spec:
      hard:
        requests.nvidia.com/gpu: 1

  3. 次のコマンドでクォータを作成します。

    $ oc create -f gpu-quota.yaml

    出力例

    resourcequota/gpu-quota created

  4. 次のコマンドを使用して、namespace に正しいクォータが設定されていることを確認します。

    $ oc describe quota gpu-quota -n nvidia

    出力例

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  0     1

  5. 次のコマンドを使用して、単一の GPU を要求する Pod を実行します。

    $ oc create pod gpu-pod.yaml

    出力例

    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 が実行されていることを確認してください。

    $ oc get pods

    出力例

    NAME              READY     STATUS      RESTARTS   AGE
    gpu-pod-s46h7     1/1       Running     0          1m

  7. 次のコマンドを実行して、クォータ Used カウンターが正しいことを確認します。

    $ oc describe quota gpu-quota -n nvidia

    出力例

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  1     1

  8. 次のコマンドを使用して、nvidia namespace に 2 番目の GPU Pod を作成してみます。2 つの GPU があるので、これをノード上で実行することは可能です。

    $ oc create -f gpu-pod.yaml

    出力例

    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 エラーメッセージが表示されるのは、割り当てられている GPU が 1 つであるにもかかわらず、Pod が 2 つ目の GPU を割り当てようとしたためです。これは、許可されているクォータを超えています。

5.3. クォータのスコープ

クォータが適用されるリソースのセットを制限するには、関連するスコープを追加します。この設定では、使用状況の測定範囲を列挙されたスコープの共通部分に限定し、許可された範囲外のリソースを指定すると検証エラーが発生するようにします。

Expand
スコープ説明

Terminating

spec.activeDeadlineSeconds >= 0 の Pod に一致します。

NotTerminating

spec.activeDeadlineSecondsnil の Pod に一致します。

BestEffort

cpu または memory のいずれかに関するサービスの QoS (Quality of Service) が Best Effort の Pod に一致します。

NotBestEffort

cpu および memory に関するサービスの QoS (Quality of Service) が Best Effort ではない Pod に一致します。

BestEffort スコープは、以下のリソースに制限するようにクォータを制限します。

  • pods

TerminatingNotTerminating、および NotBestEffort スコープは、以下のリソースを追跡するようにクォータを制限します。

  • pods
  • memory
  • requests.memory
  • limits.memory
  • cpu
  • requests.cpu
  • limits.cpu
  • ephemeral-storage
  • requests.ephemeral-storage
  • limits.ephemeral-storage
注記

一時ストレージ要求と制限は、テクノロジープレビューとして提供されている一時ストレージを有効にした場合にのみ適用されます。この機能はデフォルトでは無効にされています。

5.5. 管理者のクォータ使用量

プロジェクトが定められた制約内に収まるようにするため、管理者によるクォータの使用状況を監視してください。コンピュートリソースとストレージの総消費量を追跡することで、リソースクォータの 制限に達した、または近づいた時期を特定できます。

クォータの実施

プロジェクトのリソースクォータが最初に作成されると、クォータが最新の使用統計を計算するまで、プロジェクトはクォータ制約に違反する可能性のある新しいリソースを作成する機能を制限します。

クォータが作成され、使用状況の統計が更新されると、プロジェクトは新規コンテンツの作成を許可します。リソースを作成または変更する場合、クォータの使用量はリソースの作成または変更要求があるとすぐに増分します。

リソースを削除する場合、クォータの使用量は、プロジェクトのクォータ統計の次回の完全な再計算時に減分されます。

設定可能な時間によって、クォータクォータが現在のシステム観測値まで減少するまでにかかる時間が決定されます。

プロジェクトの変更がクォータ使用量の上限を超えた場合、サーバーはその操作を拒否し、適切なエラーメッセージをユーザーに返します。エラーメッセージには、違反したクォータ制限と、システムにおける現在の使用統計情報が説明されています。

リクエストと制限の比較

コンピュートリソースをクォータによって割り当てる場合、各コンテナーは CPU、メモリー、および一時ストレージのそれぞれに対して要求値と制限値を指定できます。クォータはこれらの値のいずれも制限できます。

クォータに requests.cpu または requests.memory の値が指定されている場合、そのクォータでは、受信するすべてのコンテナーがこれらのリソースを明示的に要求する必要があります。クォータに limits.cpu または limits.memory の値が指定されている場合、クォータでは、受信するすべてのコンテナーがこれらのリソースに対して明示的な制限を指定する必要があります。

5.5.1. リソースクォータ定義の例

クォータ設定を適切に設定するには、これらのサンプル ResourceQuota 定義を参照してください。これらの YAML の例は、プロジェクトがクラスターポリシーに準拠するように、コンピュートリソース、ストレージ、およびオブジェクト数に厳密な制限を指定する方法を示しています。

core-object-counts.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
# ...

ここでは、以下のようになります。

configmaps
プロジェクト内に存在できる ConfigMap オブジェクトの総数を指定します。
persistentvolumeclaims
プロジェクト内に存在できる永続ボリューム要求 (PVC) の総数を指定します。
replicationcontrollers
プロジェクト内に存在できるレプリケーションコントローラーの総数を指定します。
secrets
プロジェクト内に存在できるシークレットの総数を指定します。
services
プロジェクト内に存在できるサービスの総数を指定します。

openshift-object-counts.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10"
# ...

ここでは、以下のようになります。

openshift.io/imagestreams
プロジェクト内に存在できるイメージストリームの総数を指定します。

compute-resources.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"
    requests.cpu: "1"
    requests.memory: 1Gi
    requests.ephemeral-storage: 2Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    limits.ephemeral-storage: 4Gi
# ...

ここでは、以下のようになります。

pods
プロジェクト内に存在できる、非終端状態にある Pod の総数を指定します。
requests.cpu
非終端状態にあるすべての Pod において、CPU リクエストの合計が 1 コアを超えてはならないことを指定します。
requests.memory
非終端状態にあるすべての Pod において、メモリー要求の合計が 1 Gi を超えてはならないことを指定します。
requests.ephemeral-storage
非終端状態にあるすべての Pod において、一時ストレージ要求の合計が 2 Gi を超えてはならないことを指定します。
limits.cpu
非終端状態にあるすべての Pod において、CPU 制限の合計が 2 コアを超えてはならないことを指定します。
limits.memory
非終端状態にあるすべての Pod において、メモリー制限の合計が 2 Gi を超えてはならないことを指定します。
limits.ephemeral-storage
非終端状態にあるすべての Pod において、一時ストレージ制限の合計が 4 Gi を超えてはならないことを指定します。

besteffort.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1"
  scopes:
  - BestEffort
# ...

ここでは、以下のようになります。

pods
プロジェクト内に存在できる、BestEffort サービス品質を持つ非終端状態の Pod の総数を指定します。
scopes
メモリーまたは CPU のいずれかについて BestEffort の サービス品質を持つ Pod のみに一致するように、クォータに制限を指定します。

compute-resources-long-running.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4"
    limits.cpu: "4"
    limits.memory: "2Gi"
    limits.ephemeral-storage: "4Gi"
  scopes:
  - NotTerminating
# ...

ここでは、以下のようになります。

pods
終了状態ではない Pod の総数を指定します。
limits.cpu
非終端状態にあるすべての Pod において、CPU 制限の合計がこの値を超えてはならないことを指定します。
limits.memory
非終端状態にあるすべての Pod において、メモリー制限の合計がこの値を超えてはならないことを指定します。
limits.ephemeral-storage
非終端状態にあるすべての Pod において、一時ストレージ制限の合計がこの値を超えてはならないことを指定します。
scopes
spec.activeDeadlineSecondsnil に設定されている Pod のみに一致するクォータの制限を指定します。ビルド Pod は、RestartNever ポリシーが適用されない限り NotTerminating になります。

compute-resources-time-bound.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2"
    limits.cpu: "1"
    limits.memory: "1Gi"
    limits.ephemeral-storage: "1Gi"
  scopes:
  - Terminating
# ...

ここでは、以下のようになります。

pods
終了状態ではない Pod の総数を指定します。
limits.cpu
非終端状態にあるすべての Pod において、CPU 制限の合計がこの値を超えてはならないことを指定します。
limits.memory
非終端状態にあるすべての Pod において、メモリー制限の合計がこの値を超えてはならないことを指定します。
limits.ephemeral-storage
非終端状態にあるすべての Pod において、一時ストレージ制限の合計がこの値を超えてはならないことを指定します。
scopes
spec.activeDeadlineSeconds>=0 の Pod のみに一致するクォータの制限を指定します。たとえば、このクォータではビルド Pod に対して課金されますが、Web サーバーやデータベースなどの長時間実行される Pod に対しては課金されません。

storage-consumption.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10"
    requests.storage: "50Gi"
    gold.storageclass.storage.k8s.io/requests.storage: "10Gi"
    silver.storageclass.storage.k8s.io/requests.storage: "20Gi"
    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5"
    bronze.storageclass.storage.k8s.io/requests.storage: "0"
    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0"
# ...

ここでは、以下のようになります。

persistentvolumeclaims
プロジェクト内の PVC の総数を指定します。
requests.storage
プロジェクト内のすべての PVC において、要求されるストレージの合計がこの値を超えてはならないことを指定します。
gold.storageclass.storage.k8s.io/requests.storage
プロジェクト内のすべての PVC において、ゴールドストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。
silver.storageclass.storage.k8s.io/requests.storage
プロジェクト内のすべての PVC において、シルバーストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。
silver.storageclass.storage.k8s.io/persistentvolumeclaims
プロジェクト内の PVC 全体で、銀保管クラスにおける請求の総数がこの値を超えてはならないことを指定します。
bronze.storageclass.storage.k8s.io/requests.storage
プロジェクト内のすべての PVC において、ブロンズストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。この値を 0 に設定すると、ブロンズストレージクラスはストレージを要求できなくなります。
bronze.storageclass.storage.k8s.io/persistentvolumeclaims
プロジェクト内のすべての PVC において、ブロンズストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。この値を 0 に設定すると、ブロンズストレージクラスはクレームを作成できません。

5.5.2. クォータの作成

クォータを作成するには、ファイル内で ResourceQuota オブジェクトを定義し、そのファイルをプロジェクトに適用します。このタスクを実行することで、プロジェクト内のリソース消費量とオブジェクト数を制限し、プロジェクトがクラスターポリシーに準拠するようにすることができます。

手順

  • 特定のプロジェクトにリソース制約を適用するには、OpenShift CLI (oc) を使用して ResourceQuota オブジェクトを作成します。定義ファイルを使用して以下の oc create コマンドを実行すると、その名前空間に指定された総リソース消費量とオブジェクト数の制限が適用されます。

    $ oc create -f <resource_quota_definition> [-n <project_name>]

    ResourceQuota オブジェクトを作成するコマンド例

    $ oc create -f core-object-counts.yaml -n demoproject

5.5.3. オブジェクトカウントクォータの作成

標準的な名前空間付きリソースタイプの消費を管理するには、オブジェクト数のクォータを作成します。OpenShift Container Platform プロジェクト内でオブジェクト数のクォータを作成することで、BuildConfig オブジェクトDeploymentConfig オブジェクトなどのオブジェクト数に明確な制限を設定できます。

リソースクォータを使用する場合、OpenShift Container Platform は、サーバーストレージにオブジェクトが存在する場合、そのオブジェクトをクォータに対して課金します。これらのクォータは、ストレージリソースの枯渇を防ぎます。

手順

  1. リソースのオブジェクトカウントクォータを設定するには、以下のコマンドを実行します。

    $ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>

    オブジェクト数クォータを示す例

    $ oc create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4
    resourcequota "test" created

  2. オブジェクトカウントクォータの詳細なステータスを確認するには、次の oc describe コマンドを使用します。

    $ 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

    この例では、リスト表示されたリソースをクラスター内の各プロジェクトのハード制限に制限します。

5.5.4. クォータの表示

定義されたハードリミットに対する使用統計を監視するには、Web コンソールの クォータ ページに移動します。または、CLI を使用してプロジェクトの詳細なクォータ情報を表示することもできます。

手順

  1. 以下のコマンドを入力して、プロジェクトで定義されているクォータのリストを取得します。

    demoproject というプロジェクトを使用したコマンド例

    $ oc get quota -n demoproject

    出力例

    NAME                AGE
    besteffort          11m
    compute-resources   2m
    core-object-counts  29m

  2. 以下のコマンドを入力して、目標クォータを指定します。

    core-object-counts クォータのコマンド例

    $ 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

5.5.5. クォータの同期期間の設定

リソースが削除された際の同期期間を制御するには、resource- クォータ -sync-period 設定を設定します。/etc/origin/master/master-config.yaml ファイル内のこのパラメーターは、削除されたリソースを反映するためにシステムが使用統計を更新する頻度を決定します。

注記

クォータの使用が再開されるまでは、リソースを再利用しようとした際に問題が発生する可能性があります。

再生成時間の調整は、リソースの作成および自動化が使用される場合のリソース使用状況の判別に役立ちます。

注記

resource-quota-sync-period 設定により、システムパフォーマンスのバランスが保たれます。同期期間を短縮すると、コントローラーに大きな負荷がかかる可能性があります。

手順

  1. リソースが再生されて再び利用可能になるまでの時間を指定するには、resource- クォータ -sync-period 設定を編集します。この設定では、同期間隔を秒単位で設定できます。

    resource- クォータ -sync-period 設定の例

    kubernetesMasterConfig:
      apiLevels:
      - v1beta3
      - v1
      apiServerArguments: null
      controllerArguments:
        resource-quota-sync-period:
          - "10s"
    # ...

  2. 以下のコマンドを入力してコントローラーサービスを再起動し、クラスターに適用してください。

    $ master-restart api
    $ master-restart controllers

5.5.6. リソースの消費クォータを制限する

ユーザーが利用できるリソースの量を制限するには、クォータを設定します。この作業を行うことで、ストレージクラスなどのリソースの無制限な使用を防ぎ、プロジェクトのリソース消費が定義された制限内に収まるようにすることができます。

クォータがリソースを管理していない場合、ユーザーはそのリソースの消費量に制限を受けません。たとえば、gold ストレージクラスに関連するストレージのクォータがない場合、プロジェクトが作成できる gold ストレージの容量はバインドされません。

高コストのコンピュートまたはストレージリソースの場合、管理者はリソースを消費するために明示的なクォータを付与することを要求できます。たとえば、プロジェクトに gold ストレージクラスに関連するストレージのクォータが明示的に付与されていない場合、そのプロジェクトのユーザーはこのタイプのストレージを作成することができません。

手順書中の例では、クォータシステムが PersistentVolumeClaim リソースを作成または更新するすべての操作をどのようにインターセプトするかを示しています。クォータシステムは、クォータによって管理されるリソースのうち、実際に消費されるものをチェックします。プロジェクト内にそれらのリソースをカバーするクォータがない場合、リクエストは拒否されます。この例では、ユーザーがゴールドストレージクラスに関連付けられたストレージを使用する PersistentVolumeClaim リソースを作成し、プロジェクト内に一致するクォータがない場合、リクエストは拒否されます。

手順

  • master-config.yaml ファイルに以下の記述を追加してください。この節では、特定の資源を消費するための明確なクォータが必要です。

    admissionConfig:
      pluginConfig:
        ResourceQuota:
          configuration:
            apiVersion: resourcequota.admission.k8s.io/v1alpha1
            kind: Configuration
            limitedResources:
            - resource: persistentvolumeclaims
            matchContains:
            - gold.storageclass.storage.k8s.io/requests.storage
    # ...

    ここでは、以下のようになります。

    configuration.resource
    デフォルトで消費量が制限されるグループまたはリソースを指定します。
    configuration.matchContains
    デフォルトで制限するグループまたはリソースに関連付けられたクォータによって追跡されるリソースの名前を指定します。

5.7. LimitRange オブジェクト内の制限範囲

オブジェクトレベルでコンピューティングリソースの制約を定義するには、LimitRange オブジェクトを作成します。このオブジェクトを作成することで、個々の Pod、コンテナー、イメージ、または永続ボリューム要求が消費できるリソースの正確な量を指定できます。

すべてのリソース作成および変更要求は、プロジェクトのそれぞれの LimitRange オブジェクトに対して評価されます。リソースが列挙される制約のいずれかに違反する場合、そのリソースは拒否されます。リソースが明示的な値を指定しない場合で、制約がデフォルト値をサポートする場合は、デフォルト値がリソースに適用されます。

CPU とメモリーの制限について、最大値を指定しても最小値を指定しない場合、リソースは最大値よりも多くの CPU とメモリーリソースを消費する可能性があります。

コア制限範囲オブジェクトの定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits"
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2"
        memory: "1Gi"
      min:
        cpu: "200m"
        memory: "6Mi"
    - type: "Container"
      max:
        cpu: "2"
        memory: "1Gi"
      min:
        cpu: "100m"
        memory: "4Mi"
      default:
        cpu: "300m"
        memory: "200Mi"
      defaultRequest:
        cpu: "200m"
        memory: "100Mi"
      maxLimitRequestRatio:
        cpu: "10"
# ...

ここでは、以下のようになります。

metadata.name
制限範囲オブジェクトの名前を指定します。
max.cpu
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大 CPU 量を指定します。
max.memory
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大メモリー量を指定します。
min.cpu
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小 CPU 量を指定します。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
min.memory
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小メモリー量を指定します。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
max.cpu
Pod の単一コンテナーが要求できる CPU の最大量を指定します。
max.memory
Pod の単一コンテナーが要求できるメモリーの最大量を指定します。
min.cpu
Pod の単一コンテナーが要求できる CPU の最小量を指定します。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
max.memory
Pod の単一コンテナーが要求できるメモリーの最小量を指定します。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
default.cpu
Pod 仕様で制限を指定しない場合に、コンテナーのデフォルトの CPU 制限を指定します。
default.memory
Pod の仕様でメモリー制限を指定しない場合に、コンテナーのデフォルトのメモリー制限を指定します。
defaultRequest.cpu
Pod 仕様で要求を指定しない場合に、コンテナーのデフォルトの CPU 要求を指定します。
defaultRequest.memory
Pod 仕様でメモリー要求を指定しない場合に、コンテナーのデフォルトのメモリー要求を指定します。
maxLimitRequestRatio.cpu
コンテナーの最大制限対リクエスト比率を指定します。

OpenShift Container Platform の制限範囲オブジェクトの定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "openshift-resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi
    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20
        openshift.io/images: 30
    - type: "Pod"
      max:
        cpu: "2"
        memory: "1Gi"
        ephemeral-storage: "1Gi"
      min:
        cpu: "1"
        memory: "1Gi"
# ...

ここでは、以下のようになります。

limits.max.storage
内部レジストリーにプッシュできるイメージの最大サイズを指定します。
limits.max.openshift.io/image-tags
イメージストリームの仕様で定義されている、一意のイメージタグの最大数を指定します。
limits.max.openshift.io/images
イメージストリームの状態に関する仕様で定義されている、一意のイメージ参照の最大数を指定します。
type.max.cpu
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大 CPU 量を指定します。
type.max.memory
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大メモリー量を指定します。
type.max.ephemeral-storage
ノード上のすべてのコンテナーにおいて、Pod が要求できる一時ストレージの最大量を指定します。
min.cpu
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小 CPU 量を指定します。重要な情報は、「サポートされる制約」の表を参照してください。
min.memory
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小メモリー量を指定します。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。

コアおよび OpenShift Container Platform リソースの両方を 1 つの制限範囲オブジェクトで指定できます。

5.7.1. コンテナーの制限

LimitRange オブジェクトを作成した後、コンテナーが消費できるリソースの正確な量を指定できます。

コンテナーが消費できるリソースのリストを以下に示します。

  • CPU
  • メモリー

以下の表は、コンテナーでサポートされている制約を示しています。指定されている場合、制約は各コンテナーに対して満たされなければならない。

Expand
制約動作

Min

Min[<resource>]container.resources.requests[<resource>] 以下 (必須)、container/resources.limits[<resource>] 以下 (オプション)

設定で min CPU を定義している場合、要求値はその CPU 値よりも大きくなければなりません。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、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 制約を定義する場合、新規コンテナーには requestlimit 値の両方が必要になります。さらに OpenShift Container Platform は、limitrequest で除算して、制限の要求に対する比率を算出します。結果は、1 を超える整数である必要があります。

たとえば、コンテナーの limit 値が cpu: 500 で、request 値が cpu: 100 である場合、cpu の要求に対する制限の比は 5 になります。この比率は maxLimitRequestRatio 以下である必要があります。

コンテナーが消費できるデフォルトのリソースを以下に示します。

  • Default[<resource>]: 指定がない場合、container.resources.limit[<resource>] を指定された値にデフォルト設定します。
  • Default Requests[<resource>]: 指定がない場合、container.resources.requests[<resource>] を指定された値にデフォルト設定します。

5.7.2. Pod の制限

LimitRange オブジェクトを作成した後、Pod が消費できるリソースの正確な量を指定できます。

Pod は以下のリソースを消費できます。

  • CPU
  • メモリー

以下の表は、Pod でサポートされている制約を示しています。すべての Pod において、以下の動作が成り立つ必要があります。

Expand
制約強制された行動

Min

Min[<resource>]container.resources.requests[<resource>] 以下 (必須)、container.resources.limits[<resource>] 以下min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max 値よりも多くのリソースを消費できます。

Max

container.resources.limits[<resource>] (必須)、Max[<resource>] 以下

MaxLimitRequestRatio

MaxLimitRequestRatio[<resource>] は (container.resources.limits[<resource>] / container.resources.requests[<resource>]) 以下

5.7.3. イメージの制限

LimitRange オブジェクトを作成した後、イメージが消費できるリソースの正確な量を指定できます。

イメージは、以下のリソースを消費する可能性があります。

  • ストレージ
  • openshift.io/Image

以下の表は、イメージに対してサポートされている制約を示しています。指定されている場合、制約は各イメージに対して満たされなければならない。

Expand
表5.4 イメージの制限
制約動作

Max

image.dockerimagemetadata.sizeMax[<resource>] 以下

注記

制限を超える Blob ファイルがレジストリーにアップロードされるのを防ぐには、レジストリーを設定してクォータを適用する必要があります。REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA 環境変数を true に設定する必要があります。デフォルトでは、新規デプロイメントでは、環境変数は true に設定されます。

5.7.4. イメージストリームの制限

LimitRange オブジェクトを作成した後、イメージストリームが消費できるリソースの正確な量を指定できます。

イメージストリームは、以下のリソースを消費する可能性があります。

  • openshift.io/image-tags
  • openshift.io/images
  • openshift.io/ImageStream

openshift.io/image-tags リソースは、一意のストリーム制限を表します。使用可能な参照は、ImageStreamTagImageStreamImage、または DockerImage になります。タグを作成するには、oc tag コマンドと oc import-image コマンドを使用するか、イメージストリームを使用できます。内部参照と外部参照の間に区別はない。ただし、イメージストリーム仕様でタグ付けされた各固有参照は、一度だけカウントされます。このリファレンスは、内部コンテナーイメージレジストリーへのプッシュを一切制限するものではありませんが、タグによる制限には役立ちます。

openshift.io/images リソースは、イメージストリームのステータスに記録される一意のイメージ名を表します。このリソースは、内部レジストリーにプッシュできるイメージの数を制限するのに役立ちます。内部参照か外部参照であるかの区別はありません。

以下の表は、イメージストリームでサポートされている制約を示しています。指定されている場合、制約は各イメージストリームに対して満たされなければならない。

Expand
制約動作

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 はステータスタグにある一意のイメージ名を返します。名前はイメージのダイジェストと等しくなります。

5.7.5. PersistentVolumeClaim の制限

LimitRange オブジェクトを作成した後、PersistentVolumeClaim リソースが消費できるリソースの正確な量を指定できます。

PersistentVolumeClaim リソースはストレージリソースを消費することができます。

以下の表は、永続的なボリューム要求でサポートされている制約を示しています。指定されている場合、制約は各永続ボリューム要求に対して満たされなければならない。

Expand
表5.5 PersistentVolumeClaim の リソース制限
制約強制された行動

Min

Min[<resource>] <= claim.spec.resources.requests[<resource>] (必須)

Max

claim.spec.resources.requests[<resource>] (必須) <= Max[<resource>]

制限範囲オブジェクト定義の例

{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs"
  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi"
        },
        "max": {
          "storage": "50Gi"
        }
      }
    ]
  }
}

ここでは、以下のようになります。

metadata.name
制限範囲オブジェクトの名前を指定します。
limits.min.storage
永続ボリューム要求で要求できるストレージの最小量を指定します。
limits.max.storage
永続ボリューム要求で要求できるストレージの最大量を指定します。

5.9. 範囲制限操作

プロジェクト内で制限範囲を作成、表示、削除できます。

Web コンソールでプロジェクトの Quota ページに移動し、プロジェクトで定義される制限範囲を表示できます。CLI を使用して制限範囲の詳細を表示することもできます。

手順

  • オブジェクトを作成するには、以下のコマンドを入力します。

    $ oc create -f <limit_range_file> -n <project>
  • プロジェクト内に存在する制限範囲オブジェクトのリストを表示するには、次のコマンドを入力します。

    demoproject というプロジェクトを使用したコマンド例

    $ oc get limits -n demoproject

    出力例

    NAME              AGE
    resource-limits   6d

  • 制限範囲を指定するには、次のコマンドを入力します。

    リソース制限 と呼ばれる制限範囲を指定したコマンド例

    $ oc describe limits resource-limits -n demoproject

    出力例

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

  • 制限範囲を削除するには、次のコマンドを入力します。

    $ oc delete limits <limit_name>

第7章 Node Tuning Operator の使用

Node Tuning Operator を説明し、この Operator を使用し、Tuned デーモンのオーケストレーションを実行してノードレベルのチューニングを管理する方法を説明します。

7.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 の一部です。

7.2. Node Tuning Operator 仕様サンプルへのアクセス

このプロセスを使用して Node Tuning Operator 仕様サンプルにアクセスします。

手順

  • 次のコマンドを実行して、Node Tuning Operator 仕様の例にアクセスします。

    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 の将来のバージョンで非推奨になる予定です。

7.3. クラスターに設定されるデフォルトのプロファイル

以下は、クラスターに設定されるデフォルトのプロファイルです。

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 コマンドを使用して、これらのプロファイルの内容を表示できます。

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

7.4. TuneD プロファイルが適用されていることの確認

クラスターノードに適用されている TuneD プロファイルを確認します。

$ oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

出力例

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 オブジェクトに関するステータス情報を取得するには、次のコマンドを実行します。

$ oc get co/node-tuning -n openshift-cluster-node-tuning-operator

出力例

NAME          VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
node-tuning   4.16.1    True        False         True       60m     1/5 Profiles with bootcmdline conflict

ClusterOperator/node-tuning またはプロファイルオブジェクトのステータスが DEGRADED の場合、追加情報が Operator またはオペランドログに提供されます。

7.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 プロファイルおよびそれらの名前をリスト表示します。

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: セクションは、選択基準に基づくプロファイルの推奨項目のリストです。

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

リストの個別項目:

- 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> は、以下のように再帰的に定義されるオプションの一覧です。

- 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 のラベルベースのマッチング

- 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) プロファイルとして機能します。

意志決定ワークフロー

例: マシン設定プールベースのマッチング

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/ocp-tuned/provider を書き込みます。その後、このファイルのコンテンツは TuneD により、プロバイダー provider-<cloud-provider> プロファイル (存在する場合) を読み込むために使用されます。

openshift-control-plane および openshift-node プロファイルの両方の設定を継承する openshift プロファイルは、条件付きプロファイルの読み込みを使用してこの機能を使用するよう更新されるようになりました。現時点で、NTO や TuneD にクラウドプロバイダー固有のプロファイルは含まれていません。ただし、すべてのクラウドプロバイダー固有のクラスターノードに適用されるカスタムプロファイル provider-<cloud-provider> を作成できます。

GCE クラウドプロバイダープロファイルの例

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 プロファイルとその子プロファイルによって上書きされます。

7.6. カスタムチューニングの例

デフォルト CR からの TuneD プロファイルの使用

以下の CR は、ラベル tuned.openshift.io/ingress-node-label を任意の値に設定した状態で OpenShift Container Platform ノードのカスタムノードレベルのチューニングを適用します。

例: openshift-control-plane TuneD プロファイルを使用したカスタムチューニング

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 をクエリーします。

$ 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 プロファイルの使用

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 のオーバーライド

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

7.7. サポートされている 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) ワーカーノードのみサポートします。

7.8. ホステッドクラスターにおけるノードのチューニング設定

ホステッドクラスター内のノードでノードレベルのチューニングを設定するには、Node Tuning Operator を使用できます。ホストされたコントロールプレーンでは、Tuned オブジェクトを含む config map を作成し、ノードプールでそれらの config map を参照することで、ノードのチューニングを設定できます。

手順

  1. チューニングされた有効なマニフェストを含む config map を作成し、ノードプールでマニフェストを参照します。次の例で Tuned マニフェストは、任意の値を持つ tuned-1-node-label ノードラベルを含むノード上で vm.dirty_ratio を 55 に設定するプロファイルを定義します。次の ConfigMap マニフェストを tuned-1.yaml という名前のファイルに保存します。

        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 オブジェクトを作成します。

    $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
  3. ノードプールを編集するか作成して、ノードプールの spec.tuningConfig フィールドで ConfigMap オブジェクトを参照します。この例では、2 つのノードを含む nodepool-1 という名前の NodePool が 1 つだけあることを前提としています。

        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 オブジェクトをリスト表示します。

    $ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    出力例

    NAME       AGE
    default    7m36s
    rendered   7m36s
    tuned-1    65s

  2. ホステッドクラスター内の Profile オブジェクトをリスト表示します。

    $ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    出力例

    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 値を確認します。

    $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio

    出力例

    vm.dirty_ratio = 55

カーネルブートパラメーターの設定が必要な、ホストされたコントロールプレーンでのより高度なチューニングは、Node Tuning Operator を使用することもできます。次の例は、Huge Page が予約されたノードプールを作成する方法を示しています。

手順

  1. サイズが 2 MB の 10 個の Huge Page を作成するための Tuned オブジェクトマニフェストを含む ConfigMap オブジェクトを作成します。この ConfigMap マニフェストを tuned-hugepages.yaml という名前のファイルに保存します。

        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 オブジェクトを作成します。

    $ 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 という名前のファイルに保存します。

    $ 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.upgradeTypeInPlace に設定し、作成した tuned-hugepages ConfigMap オブジェクトを参照するように .spec.tuningConfig を設定します。

        apiVersion: hypershift.openshift.io/v1alpha1
        kind: NodePool
        metadata:
          name: hugepages-nodepool
          namespace: clusters
          ...
        spec:
          management:
            ...
            upgradeType: InPlace
          ...
          tuningConfig:
          - name: tuned-hugepages
    注記

    新しい MachineConfig オブジェクトを適用するときに不要なノードの再作成を回避するには、.spec.management.upgradeTypeInPlace に設定します。Replace アップグレードタイプを使用する場合、ノードは完全に削除され、TuneD オペランドが計算した新しいカーネルブートパラメーターを適用すると、新しいノードでノードを置き換えることができます。

  5. 管理クラスターに NodePool を作成します。

    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml

検証

ノードが使用可能になると、コンテナー化された TuneD デーモンが、適用された TuneD プロファイルに基づいて、必要なカーネルブートパラメーターを計算します。ノードの準備が整い、一度再起動して生成された MachineConfig オブジェクトを適用したら、TuneD プロファイルが適用され、カーネルブートパラメーターが設定されていることを確認できます。

  1. ホステッドクラスター内の Tuned オブジェクトをリスト表示します。

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    出力例

    NAME                 AGE
    default              123m
    hugepages-8dfb1fed   1m23s
    rendered             123m

  2. ホステッドクラスター内の Profile オブジェクトをリスト表示します。

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    出力例

    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 を確認します。

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline

    出力例

    BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50

第8章 CPU Manager および 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 マネージャーを設定する必要があります。

8.1. CPU マネージャーの設定

CPU マネージャーを設定するには、KubeletConfig カスタムリソース (CR) を作成し、それを目的のノードセットに適用します。

手順

  1. 次のコマンドを実行してノードにラベルを付けます。

    # oc label node perf-node.example.com cpumanager=true
  2. すべてのコンピュートノードに対して CPU マネージャーを有効にするには、次のコマンドを実行して CR を編集します。

    # oc edit machineconfigpool worker
  3. custom-kubelet: cpumanager-enabled ラベルを metadata.labels セクションに追加します。

    metadata:
      creationTimestamp: 2020-xx-xxx
      generation: 3
      labels:
        custom-kubelet: cpumanager-enabled
  4. KubeletConfigcpumanager-kubeletconfig.yaml、カスタムリソース (CR) を作成します。直前の手順で作成したラベルを参照し、適切なノードを新規の kubelet 設定で更新します。machineConfigPoolSelector セクションを参照してください。

    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 設定を作成します。

    # oc create -f cpumanager-kubeletconfig.yaml

    これにより、CPU マネージャー機能が kubelet 設定に追加され、必要な場合には Machine Config Operator (MCO) がノードを再起動します。CPU マネージャーを有効にするために再起動する必要はありません。

  6. 次のコマンドを実行して、マージされた kubelet 設定を確認します。

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

    出力例

           "ownerReferences": [
                {
                    "apiVersion": "machineconfiguration.openshift.io/v1",
                    "kind": "KubeletConfig",
                    "name": "cpumanager-enabled",
                    "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
                }
            ]

  7. 次のコマンドを実行して、更新された kubelet.conf ファイルをコンピュートノードで確認します。

    # oc debug node/perf-node.example.com
    sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

    出力例

    cpuManagerPolicy: static        
    1
    
    cpuManagerReconcilePeriod: 5s   
    2

    1
    cpuManagerPolicy は、KubeletConfig CR の作成時に定義されます。
    2
    cpuManagerReconcilePeriod は、KubeletConfig CR の作成時に定義されます。
  8. 次のコマンドを実行してプロジェクトを作成します。

    $ oc new-project <project_name>
  9. コア 1 つまたは複数を要求する Pod を作成します。制限および要求の CPU の値は整数にする必要があります。これは、対象の Pod 専用のコア数です。

    # cat cpumanager-pod.yaml

    出力例

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

    # oc create -f cpumanager-pod.yaml

検証

  1. 次のコマンドを実行して、ラベルを付けたノードに Pod がスケジュールされていることを確認します。

    # oc describe pod cpumanager

    出力例

    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 専用として割り当てられていることを確認します。

    # oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2

    出力例

    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) を取得します。

    # oc debug node/perf-node.example.com
    sh-4.2# systemctl status | grep -B5 pause
    注記

    出力で複数の pause プロセスエントリーが返される場合は、正しい一時停止プロセスを特定する必要があります。

    出力例

    # ├─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 サブディレクトリー内に配置されていることを確認します。

    # cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done
    注記

    他の QoS 階層の Pod は、親 kubepods の子である cgroups に配置されます。

    出力例

    cpuset.cpus 1
    tasks 32706

  5. 次のコマンドを実行して、タスクに許可されている CPU リストを確認します。

    # grep ^Cpus_allowed_list /proc/32706/status

    出力例

     Cpus_allowed_list:    1

  6. システム上の別の Pod が、Guaranteed Pod に割り当てられたコアで実行できないことを確認します。たとえば、besteffort QoS 階層の Pod を検証するには、次のコマンドを実行します。

    # cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    # oc describe node perf-node.example.com

    出力例

    ...
    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 を受け入れますが、これがスケジュールされることはありません。

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

8.2. Topology Manager ポリシー

Topology Manager は、CPU マネージャーや Device Manager などの Hint Provider からトポロジーのヒントを収集し、収集したヒントを使用して Pod リソースを調整することで、すべての Quality of Service (QoS) クラスの Pod リソースを調整します。

Topology Manager は 4 つの割り当てポリシーをサポートしています。これらのポリシーは、cpumanager-enabled という名前の KubeletConfig カスタムリソース (CR) で指定します。

none ポリシー
これはデフォルトのポリシーで、トポロジーの配置は実行しません。
best-effort ポリシー
best-effort トポロジー管理ポリシーが設定された Pod 内の各コンテナーに対して、kubelet が、そのコンテナーの優先される NUMA ノードアフィニティーに従って、必要なすべてのリソースを NUMA ノードに配置しようと試みます。リソース不足のために割り当てが不可能な場合でも、Topology Manager は Pod を許可しますが、その割り当ては他の NUMA ノードと共有されます。
restricted ポリシー
restricted トポロジー管理ポリシーが設定された Pod 内の各コンテナーに対して、kubelet が、要求を満たすことができる NUMA ノードの理論上の最小数を決定します。その数を超える NUMA ノード数が実際の割り当てに必要な場合、Topology Manager は許可を拒否し、Pod を Terminated 状態にします。NUMA ノード数が要求を満たすことができる場合、Topology Manager は Pod を許可し、Pod は実行を開始します。
single-numa-node ポリシー
single-numa-node トポロジー管理ポリシーが設定された Pod 内の各コンテナーに対して、kubelet が、Pod に必要なすべてのリソースを同じ NUMA ノードに割り当てることができる場合に Pod を許可します。リソースを単一の NUMA ノードに割り当てることが不可能な場合、Topology Manager はノードから Pod を拒否します。その結果、Pod は受付の失敗により Terminated 状態になります。

8.3. Topology Manager のセットアップ

Topology Manager を使用するには、cpumanager-enabled という名前の KubeletConfig カスタムリソース (CR) で割り当てポリシーを設定する必要があります。CPU マネージャーをセットアップしている場合は、このファイルが存在している可能性があります。ファイルが存在しない場合は、作成できます。

前提条件

  • CPU マネージャーのポリシーを static に設定します。

手順

Topology Manager をアクティブにするには、以下を実行します。

  1. カスタムリソースで Topology Manager 割り当てポリシーを設定します。

    $ oc edit KubeletConfig cpumanager-enabled
    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
    このパラメーターは、static (小文字の s を使用) にする必要があります。
    2
    選択した Topology Manager 割り当てポリシーを指定します。このポリシーは single-numa-node になります。使用できる値は、defaultbest-effortrestrictedsingle-numa-node です。

8.4. Pod と Topology Manager ポリシーのやり取り

次の Pod 仕様の例は、Topology Manager と Pod のやり取りを示しています。

以下の Pod は、リソース要求や制限が指定されていないために BestEffort QoS クラスで実行されます。

spec:
  containers:
  - name: nginx
    image: nginx

以下の Pod は、要求が制限よりも小さいために Burstable QoS クラスで実行されます。

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

選択したポリシーが none 以外の場合、Topology Manager はすべての Pod を処理し、Guaranteed Qos Pod 仕様に対してのみリソースの配置を適用します。Topology Manager ポリシーが none に設定されている場合、該当するコンテナーが NUMA アフィニティーを考慮せずに使用可能な CPU にピニングされます。これはデフォルトの動作であり、パフォーマンスが重要なワークロードに最適なものではありません。それ以外の値を設定すると、デバイスプラグインのコアリソース (CPU やメモリーなど) からのトポロジー認識情報が使用可能になります。ポリシーが none 以外の値に設定されている場合、Topology Manager はノードのトポロジーに従って、CPU、メモリー、およびデバイスの割り当ての調整を試みます。使用可能な値の詳細は、Topology Manager ポリシー を参照してください。

次の Pod の例は、要求が制限と等しいため、Guaranteed QoS クラスで実行されます。

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 Manager、Device Manager、Memory Manager などの Hint Provider を参照して、Pod のトポロジーヒントを取得します。

Topology Manager はこの情報を使用して、このコンテナーに最適なトポロジーを保管します。この Pod の場合、CPU マネージャーおよび Device Manager は、リソース割り当ての段階でこの保存された情報を使用します。

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

高性能ワークロードを最適な効率でデプロイするには、NUMA 対応スケジューリングを使用してください。この機能は、OpenShift Container Platform クラスター内の基盤となるハードウェアトポロジーに合わせて Pod を配置し、レイテンシーを最小限に抑え、リソース利用率を最大化します。

NUMA Resources Operator を使用すると、同じ NUMA ゾーン内で高性能ワークロードをスケジュールできます。Operator は、利用可能なクラスターノードの NUMA リソースを報告するノードリソースエクスポートエージェントと、ワークロードを管理するセカンダリースケジューラーをデプロイします。

9.1. NUMA について

マルチプロセッサーシステムにおけるレイテンシーを低減するために、Non-Uniform Memory Access (NUMA) アーキテクチャーでは、CPU がリモートメモリーよりも高速にローカルメモリーにアクセスできるようになります。この設計では、プロセッサーに物理的に近いメモリーリソースを優先することで、パフォーマンスを最適化しています。

複数のメモリーコントローラーを備えた CPU は、メモリーが配置されている場所に関係なく、CPU コンプレックス全体で使用可能なメモリーをすべて使用できます。ただし、このように柔軟性が向上したことで、パフォーマンスが犠牲になっています。

NUMA リソーストポロジー とは、NUMA ゾーン 内の CPU、メモリー、および PCI デバイスの相互の相対的な物理的位置関係を指します。NUMA アーキテクチャーでは、NUMA ゾーンは独自のプロセッサーとメモリーを持つ CPU のグループです。同じ場所に配置されたリソースは同一の NUMA ゾーンにあるとされ、ゾーン内の CPU は、そのゾーン外の CPU よりも、そのゾーンのローカルメモリーへ高速にアクセスできます。

NUMA ゾーン外のメモリーを使用してワークロードを処理する CPU は、単一の NUMA ゾーンで処理されるワークロードよりも遅くなります。I/O に制約のあるワークロードの場合、離れた NUMA ゾーンのネットワークインターフェイスにより、情報がアプリケーションに到達する速度が低下します。

アプリケーションは、データと処理を同じ NUMA ゾーン内に含めることで、より優れたパフォーマンスを実現できます。通信ワークロードなどの高パフォーマンスのワークロードとアプリケーションの場合、ワークロードが仕様どおりに動作できるように、クラスターは単一の NUMA ゾーンで Pod ワークロードを処理する必要があります。

9.2. NUMA 対応のスケジューリングについて

レイテンシーに敏感なワークロードや高性能なワークロードを効率的に処理するには、NUMA 対応スケジューリングを使用してください。この機能は、CPU、メモリー、デバイスなどのクラスターコンピュートリソースを同じ NUMA ゾーンに整列させることで、リソース効率を最適化し、コンピュートノードあたりの Pod 密度を向上させます。

Node Tuning Operator のパフォーマンスプロファイルを NUMA 対応スケジューリングと統合することで、CPU アフィニティーをさらに設定し、レイテンシーに敏感なワークロードのパフォーマンスを最適化できます。

デフォルトの OpenShift Container Platform Pod スケジューラーのスケジューリングロジックは、個々の NUMA ゾーンではなく、コンピュートノード全体の利用可能なリソースを考慮します。kubelet トポロジーマネージャーで最も制限的なリソースアライメントが要求された場合、Pod をノードに許可するときにエラー状態が発生する可能性があります。

逆に、最も制限的なリソース調整が要求されていない場合、Pod は適切なリソース調整なしでノードに許可され、パフォーマンスが低下したり予測不能になったりする可能性があります。たとえば、Pod スケジューラーが Pod の要求されたリソースが利用可能かどうか把握せずに保証された Pod ワークロードに対して次善のスケジューリング決定を行うと、Topology Affinity Error ステータスを伴う Pod 作成の暴走が発生する可能性があります。スケジュールの不一致の決定により、Pod の起動が無期限に遅延する可能性があります。また、クラスターの状態とリソースの割り当てによっては、Pod のスケジューリングの決定が適切でないと、起動の試行が失敗するためにクラスターに余分な負荷がかかる可能性があります。

NUMA Resources Operator は、カスタム NUMA リソースのセカンダリースケジューラーおよびその他のリソースをデプロイして、デフォルトの OpenShift Container Platform Pod スケジューラーの欠点を軽減します。次の図は、NUMA 対応 Pod スケジューリングの俯瞰的な概要を示しています。

図9.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 エンドポイントは、ノード上で使用できる割り当て可能なリソースを公開します。

9.3. NUMA リソーススケジューリングストラテジー

高性能ワークロードの配置を最適化するために、セカンダリースケジューラーは NUMA を考慮したスコアリングストラテジーを使用して、最適なコンピュートノードを選択します。このプロセスでは、リソースの可用性に基づいてワークロードを割り当てつつ、ローカルノードマネージャーが最終的なリソースの固定処理を行えるようにします。

高性能ワークロードをスケジューリングする際、セカンダリースケジューラーは、内部の NUMA リソース配分に基づいて、タスクに最適なコンピュートノードを決定します。スケジューラーは NUMA レベルのデータを使用してコンピュートノードを評価して選択しますが、そのノード内での実際のリソースの固定は、ローカルの Topology Manager および CPU マネージャーによって管理されます。

  1. スケジューラーはまず、クラスター全体の基準に基づいて適切なコンピュートノードを選択します。たとえば、taint、ラベル、リソースの可用性などの基準です。
  2. コンピュートノードが選択されると、スケジューラーはその NUMA ノードを評価し、スコアリングストラテジーを適用して、どの NUMA ノードがワークロードを処理するかを決定します。
  3. ワークロードがスケジュールされると、選択された NUMA ノードのリソースが更新され、割り当てが反映されます。

適用されるデフォルトのストラテジーは、LeastAllocated ストラテジーです。このストラテジーでは、利用可能なリソースが最も多く、使用率が最も低い NUMA ノードにワークロードが割り当てられます。このストラテジーの目的は、競合を減らし、ホットスポットを回避するために、NUMA ノード全体にワークロードを分散することです。

次の表に、各ストラテジーとその効果の概要を示します。

Expand
表9.1 スコアリングストラテジーの概要
ストラテジー説明効果

LeastAllocated

利用可能なリソースが最も多い NUMA ゾーンを含むコンピュートノードを優先します。

ワークロードをクラスター全体に分散し、利用可能な余裕が最も大きいノードに割り当てます。

MostAllocated

要求されたリソースがすでに高い利用率を持つ NUMA ゾーンに収まるコンピュートノードを優先します。

すでに利用されているノードにワークロードを集中させることで、他のノードをアイドル状態にする可能性があります。

BalancedAllocation

NUMA ゾーン全体で CPU とメモリーの使用率が最もバランスの取れたコンピュートノードを優先します。

CPU などのリソースタイプが使い果たされる一方で、メモリーなどの別のリソースタイプがアイドル状態になるといった、偏った使用パターンを防ぎます。

9.3.1. LeastAllocated ストラテジーの例

LeastAllocated がデフォルトのストラテジーです。このストラテジーでは、利用可能なリソースが最も多い NUMA ノードにワークロードを割り当て、リソースの競合を最小限に抑え、ワークロードを NUMA ノード全体に分散します。これにより、ホットスポットが削減され、優先度の高いタスクに十分な余裕が確保されます。コンピュートノードに 2 つの NUMA ノードがあり、ワークロードに 4 つの vCPU と 8GB のメモリーが必要だと仮定します。

Expand
表9.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 に割り当てられます。

9.3.2. MostAllocated ストラテジーの例

MostAllocated ストラテジーは、利用可能なリソースが最も少ない NUMA ノード (最も使用されている NUMA ノード) にワークロードを割り当てることで、ワークロードを集約します。この方法により、エネルギー効率や完全な分離を必要とする重要なワークロードのために、他の NUMA ノードを解放できます。この例では、LeastAllocated セクションにリストされている「NUMA ノード初期状態の例」の値を使用します。

このワークロードには、4 つの仮想 CPU と 8 GB のメモリーが必要です。NUMA 1 は NUMA 2 に比べて利用可能なリソースが少ないため、スケジューラーはワークロードを NUMA 1 に割り当て、そのリソースをさらに活用します。一方、NUMA 2 はアイドル状態にするか、その負荷を最小限に抑えます。

9.3.3. BalancedAllocation ストラテジーの例

BalancedAllocation ストラテジーでは、CPU とメモリーのリソース使用率が最もバランスのとれた NUMA ノードにワークロードを割り当てます。目的は、メモリーが十分に使用されていないのに CPU 使用率が高くなるなど、不均衡な使用を防ぐことです。コンピュートノードが以下の NUMA ノード状態を持つと仮定します。

Expand
表9.3 BalancedAllocation の NUMA ノード初期状態の例
NUMA ノードCPU の使用率メモリー使用率BalancedAllocation のスコア

NUMA 1

60%

55%

高 (バランスがとれている)

NUMA 2

80%

20%

低 (バランスがとれていない)

NUMA 1 は、NUMA 2 と比較して CPU とメモリーの使用率がよりバランスがとれています。そのため、BalancedAllocation ストラテジーを適用すると、ワークロードは NUMA 1 に割り当てられます。

9.4. NUMA Resources Operator のインストール

NUMA Resources Operator は、NUMA 対応のワークロードとデプロイメントをスケジュールできるリソースをデプロイします。OpenShift Container Platform CLI または Web コンソールを使用して NUMA Resources Operator をインストールできます。

9.4.1. CLI を使用した NUMA Resources Operator のインストール

高性能ワークロードの NUMA 対応スケジューリングを有効にするには、OpenShift CLI (oc) を使用して NUMA Resources Operator をインストールします。クラスター管理者であれば、Web コンソールを使用せずに Operator を効率的にデプロイできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. NUMA Resources Operator の namespace を作成します。

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-numaresources
      # ...
    2. 以下のコマンドを実行して Namespace CR を作成します。

      $ oc create -f nro-namespace.yaml
  2. NUMA Resources Operator の Operator グループを作成します。

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

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: numaresources-operator
        namespace: openshift-numaresources
      spec:
        targetNamespaces:
        - openshift-numaresources
      # ...
    2. 以下のコマンドを実行して OperatorGroup CR を作成します。

      $ oc create -f nro-operatorgroup.yaml
  3. NUMA Resources Operator のサブスクリプションを作成します。

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: numaresources-operator
        namespace: openshift-numaresources
      spec:
        channel: "4.16"
        name: numaresources-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      # ...
    2. 以下のコマンドを実行して Subscription CR を作成します。

      $ oc create -f nro-sub.yaml

検証

  1. openshift-numaresources namespace の CSV リソースを調べて、インストールが成功したことを確認します。以下のコマンドを実行します。

    $ oc get csv -n openshift-numaresources

    出力例

    NAME                             DISPLAY                  VERSION   REPLACES   PHASE
    numaresources-operator.v4.16.2   numaresources-operator   4.16.2               Succeeded

9.4.2. Web コンソールを使用した NUMA Resources Operator のインストール

高性能ワークロード向けに NUMA 対応スケジューリングを有効にするには、Web コンソールを使用して NUMA Resources Operator をインストールします。クラスター管理者であれば、グラフィカルインターフェイスを通して Operator をデプロイできます。

手順

  1. NUMA Resources Operator の namespace を作成します。

    1. OpenShift Container Platform Web コンソールで、AdministrationNamespaces をクリックします。
    2. Create Namespace をクリックし、Name フィールドに openshift-numaresources と入力して Create をクリックします。
  2. NUMA Resources Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator のリストから numaresources-operator を選択し、Install をクリックします。
    3. Installed Namespaces フィールドで、openshift-numaresources namespace を選択し、Install をクリックします。
  3. オプション: NUMA Resources Operator が正常にインストールされたことを確認します。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. NUMA Resources Operatoropenshift-numaresources namespace にリストされ、StatusInstallSucceeded であることを確認します。

      注記

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

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

      • OperatorsInstalled Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • WorkloadsPods ページに移動し、default プロジェクトの Pod のログを確認します。

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

レイテンシーに敏感なワークロードや高性能なワークロードを効率的に処理するには、OpenShift Container Platform クラスターを NUMA 対応のスケジューリング用に設定してください。このプロセスでは、ネットワーク遅延を最小限に抑え、コンピュートリソースの利用率を最大化するために、Pod を特定の NUMA ゾーンに割り当てます。

通常、遅延の影響を受けやすいワークロードを実行するクラスターは、ワークロードの遅延を最小限に抑え、パフォーマンスを最適化するのに役立つパフォーマンスプロファイルを備えています。NUMA 対応スケジューラーは、使用可能なノードの NUMA リソースと、ノードに適用されるパフォーマンスプロファイル設定に基づいき、ワークロードをデプロイします。NUMA 対応デプロイメントとワークロードのパフォーマンスプロファイルを組み合わせることで、パフォーマンスを最大化するようにワークロードがスケジュールされます。

NUMA Resources Operator を完全に動作させるには、NUMAResourcesOperator カスタムリソースと NUMA 対応のセカンダリー Pod スケジューラーをデプロイする必要があります。

9.5.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 として保存します。

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesOperator
      metadata:
        name: numaresourcesoperator
      spec:
        nodeGroups:
        - machineConfigPoolSelector:
            matchLabels:
              pools.operator.machineconfiguration.openshift.io/worker: ""
      # ...
      • pools.operator.machineconfiguration.openshift.io/worker: NUMA Resources Operator を設定する対象とする MachineConfigPool リソースと一致する値を指定します。たとえば、通信ワークロードを実行することが予想されるノードのセットを指定する worker-cnf という名前の MachineConfigPool リソースを作成したとします。各 NodeGroup は 1 つの MachineConfigPool に完全に一致する必要があります。NodeGroup が複数の MachineConfigPool に一致する設定はサポートされていません。
    2. 以下のコマンドを実行して、NUMAResourcesOperator CR を作成します。

      $ oc create -f nrop.yaml
      注記

      NUMAResourcesOperator を作成すると、対応するマシン設定プールと、関連するノードの再起動がトリガーされます。

  2. オプション: 複数のマシン設定プール (MCP) に対して NUMA 対応スケジューリングを有効にするには、プールごとに個別の NodeGroup を定義します。たとえば、次の例に示すように、NUMAResourcesOperator CR で、worker-cnfworker-ht、および worker-other の 3 つの NodeGroups を定義します。

    複数の NodeGroups を含む NUMAResourcesOperator CR の YAML 定義の例

    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 が正常にデプロイされたことを確認します。

    $ oc get numaresourcesoperators.nodetopology.openshift.io

    出力例

    NAME                    AGE
    numaresourcesoperator   27s

  2. 数分後、次のコマンドを実行して、必要なリソースが正常にデプロイされたことを確認します。

    $ oc get all -n openshift-numaresources

    出力例

    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

9.5.2. NUMA 対応のセカンダリー Pod スケジューラーのデプロイ

高性能ワークロードの配置を最適化するには、NUMA 対応のセカンダリー Pod スケジューラーをデプロイします。このコンポーネントは、Pod を特定の NUMA ゾーンに割り当て、クラスター内での効率的なリソース利用を保証します。

手順

  1. NUMA 対応のカスタム Pod スケジューラーをデプロイする NUMAResourcesScheduler カスタムリソースを作成します。

    1. 次の最小限必要な YAML を nro-scheduler.yaml ファイルに保存します。

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.16"
      # ...
      • spec.imageSpec: 非接続環境では、以下のいずれかの方法でこのイメージの解像度を設定してください。
    2. ImageTagMirrorSet カスタムリソース (CR) を作成します。詳細は、「関連情報」セクションの「イメージレジストリーのリポジトリーミラーリングの設定」を参照してください。
    3. 切断されたレジストリーへの URL を設定してください。
    4. 次のコマンドを実行して、NUMAResourcesScheduler CR を作成します。

      $ oc create -f nro-scheduler.yaml
  2. 数秒後、次のコマンドを実行して、必要なリソースのデプロイメントが成功したことを確認します。

    $ oc get all -n openshift-numaresources

    出力例

    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

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

NUMA Resources Operator を有効にするには、クラスター上で単一の NUMA ノードポリシーを設定します。このポリシーは、パフォーマンスプロファイルを作成するか、KubeletConfig カスタムリソース (CR) を設定することで実装できます。

注記

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

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

9.5.4. パフォーマンスプロファイルの例

パフォーマンスプロファイル作成ツール (PPC) を使用してパフォーマンスプロファイルを作成する方法を理解するには、YAML の例を参照してください。

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: "3"
    reserved: 0-2
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/worker: ""
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  numa:
    topologyPolicy: single-numa-node
  realTimeKernel:
    enabled: true
  workloadHints:
    highPowerConsumption: true
    perPodPowerManagement: false
    realTime: true
  • spec.pools.operator.machineconfiguration.openshift.io/worker:: NUMA Resources Operator を設定する MachineConfigPool の 値と一致する必要がある値を指定します。たとえば、worker-cnf という名前の MachineConfigPool オブジェクトを作成し、通信ワークロードを実行する一連のノードを指定します。MachineConfigPool の値は、後ほど「NUMAResourcesOperator カスタムリソースの作成」で設定する NUMAResourcesOperator CR の machineConfigPoolSelector 値と一致する必要があります。
  • spec.numa.topologyPolicy:: PPC ツールを実行する際に、トポロジー -manager-policy 引数を single-numa-node に設定することで、topologyPolicy フィールドが single-numa-node に設定されるようにします。
注記

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

9.5.5. KubeletConfig CR の作成

単一の NUMA ノードポリシーを設定するには、KubeletConfig カスタムリソース (CR) を作成して適用します。パフォーマンスプロファイルの適用が推奨されますが、代替手段として、クラスター上の設定を手動で管理することも可能です。

手順

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

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

      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      metadata:
        name: worker-tuning
      spec:
        machineConfigPoolSelector:
          matchLabels:
            pools.operator.machineconfiguration.openshift.io/worker: ""
        kubeletConfig:
          cpuManagerPolicy: "static"
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1"
          memoryManagerPolicy: "Static"
          evictionHard:
            memory.available: "100Mi"
          kubeReserved:
            memory: "512Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node"

      ここでは、以下のようになります。

      spec.machineConfigPoolSelector.matchLabels.pools.operator.machineconfiguration.openshift.io/worker
      このラベルが、後ほど NUMAResourcesOperator カスタムリソースの作成で設定する NUMAResourcesOperator CR の machineConfigPoolSelector 設定と一致することを指定します。
      spec.kubeletConfig.cpuManagerPolicy
      静的な 値を指定します。小文字の s を使用する必要があります。
      spec.kubeletConfig.reservedSystemCPUs
      ノードの CPU に基づいて、このフィールドを調整してください。
      spec.kubeletConfig.memoryManagerPolicy
      静的 を指定します。大文字の S を使用する必要があります。
      spec.kubeletConfig.topologyManagerPolicy

      値を single-numa-node として指定します。

      注記

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

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

      $ oc create -f nro-kubeletconfig.yaml
      注記

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

9.5.6. NUMA 対応スケジューラーを使用したワークロードのスケジューリング

NUMA 対応スケジューラーを使用してワークロードをスケジュールするには、必要最小限のリソースを指定するデプロイメント CR を使用します。これにより、クラスターがワークロードを効率的に処理することが保証されます。

NUMA 対応スケジューラーを使用してワークロードをスケジュールする前に、topo-aware-scheduler を 事前にインストールし、NUMAResourcesOperator および NUMAResourcesScheduler CR を適用し、クラスターに一致するパフォーマンスプロファイルまたは kubeletconfig があることを確認してください。

この手順の例では、サンプルワークロードに対して NUMA 対応スケジューリングを使用しています。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次のコマンドを実行して、クラスターにデプロイされている NUMA 対応スケジューラーの名前を取得します。

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

    出力例

    "topo-aware-scheduler"

  2. topo-aware-scheduler という名前のスケジューラーを使用する Deployment CR を作成します。次に例を示します。

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

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: numa-deployment-1
        namespace: openshift-numaresources
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: test
        template:
          metadata:
            labels:
              app: test
          spec:
            schedulerName: topo-aware-scheduler
            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"

      spec.schedulerName: クラスターにデプロイされている NUMA 対応スケジューラーの名前と一致する必要のあるスケジューラー名を指定します (例: topo-aware-scheduler)

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

      $ oc create -f nro-deployment.yaml

検証

  1. デプロイメントが正常に行われたことを確認します。

    $ oc get pods -n openshift-numaresources

    出力例

    NAME                                                READY   STATUS    RESTARTS   AGE
    numa-deployment-1-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 をスケジュールしていることを確認します。

    $ oc describe pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources

    出力例

    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 を実行しているノードを特定します。

      $ oc get pods -n openshift-numaresources -o wide

      出力例

      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 を実行しているノードの名前を指定します。

      $ oc describe noderesourcetopologies.topology.node.k8s.io worker-1

      出力例

      ...
      
      Zones:
        Costs:
          Name:   node-0
          Value:  10
          Name:   node-1
          Value:  21
        Name:     node-0
        Resources:
          Allocatable:  39
          Available:    21
          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

      Resources.Available: 保証された Pod に割り当てられたリソースによって減少した、利用可能な 容量を指定します。保証された Pod によって消費されるリソースは、noderesourcetopologies.topology.node.k8s.io にリスト表示されている使用可能なノードリソースから差し引かれます。

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

    $ oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"

    出力例

    Guaranteed

9.6. NUMA リソース更新のためのポーリング操作の設定

オプションのタスクとして、NUMAResourcesOperator カスタムリソース (CR) の spec.nodeGroups 仕様を設定することで、スケジューリングの動作を改善したり、最適ではないスケジューリング決定のトラブルシューティングを行ったりすることができます。この設定により、デーモンが利用可能な NUMA リソースをポーリングする方法を細かく調整でき、ポーリング操作を高度に制御できます。

設定オプションは以下のとおりです。

  • infoRefreshMode: kubelet をポーリングするためのトリガー条件を決定します。NUMA Resources Operator は、結果として取得した情報を API サーバーに報告します。
  • infoRefreshPeriod: ポーリング更新の間隔を決定します。
  • podsFingerprinting: ノード上で実行されている現在の Pod セットのポイントインタイム情報がポーリング更新で公開されるかどうかを決定します。
注記

podsFingerprinting のデフォルト値は EnabledExclusiveResources です。スケジューラーのパフォーマンスを最適化するには、podsFingerprintingEnabledExclusiveResources または Enabled に設定します。さらに、NUMAResourcesScheduler カスタムリソース (CR) の cacheResyncPeriod を 0 より大きい値に設定します。cacheResyncPeriod 仕様は、ノード上の保留中のリソースを監視することで、より正確なリソースの可用性を報告するのに役立ちます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールしました。

手順

  • NUMAResourcesOperator CR で spec.nodeGroups 仕様を設定します。

    apiVersion: nodetopology.openshift.io/v1
    kind: NUMAResourcesOperator
    metadata:
      name: numaresourcesoperator
    spec:
      nodeGroups:
      - config:
          infoRefreshMode: Periodic
          infoRefreshPeriod: 10s
          podsFingerprinting: Enabled
        name: worker
    # ...
    • spec.nodeGroups.config.infoRefreshMode:: 有効な値は PeriodicEventsPeriodicAndEvents です。Periodic を使用して、infoRefreshPeriod で定義した間隔で kubelet をポーリングします。Events を使用して、Pod のライフサイクルイベントごとに kubelet をポーリングします。両方のメソッドを有効にするには、PeriodicAndEvents を使用します。
    • spec.nodeGroups.config.infoRefreshPeriod:: 定期 更新モードまたは定期更新および イベント 更新モードのポーリング間隔を指定します。リフレッシュモードが Events の場合、このフィールドは無視されます。
    • spec.nodeGroups.config.podsFingerprinting:: 有効な値は EnabledDisabledEnabledExclusiveResources です。NUMAResourcesSchedulercacheResyncPeriod 仕様では、Enabled または EnabledExclusiveResources に設定する必要があります。

検証

  1. NUMA Resources Operator をデプロイした後、次のコマンドを実行して、ノードグループ設定が適用されたことを検証します。

    $ oc get numaresop numaresourcesoperator -o json | jq '.status'

    出力例

          ...
    
            "config": {
            "infoRefreshMode": "Periodic",
            "infoRefreshPeriod": "10s",
            "podsFingerprinting": "Enabled"
          },
          "name": "worker"
    
          ...

9.7. NUMA 対応スケジューリングのトラブルシューティング

NUMA 対応 Pod スケジューリングに関する一般的な問題を解決するには、クラスター設定のトラブルシューティングを行ってください。これらの問題を特定して修正することで、高性能ワークロード向けに Pod が基盤となるハードウェアと最適に連携することが保証されます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 特権のユーザーとしてログインしました。
  • NUMA Resources Operator をインストールし、NUMA 対応のセカンダリースケジューラーをデプロイしました。

手順

  1. 次のコマンドを実行して、noderesourcetopologies CRD がクラスターにデプロイされていることを確認します。

    $ oc get crd | grep noderesourcetopologies

    出力例

    NAME                                                              CREATED AT
    noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

  2. 次のコマンドを実行して、NUMA 対応スケジューラー名が NUMA 対応ワークロードで指定された名前と一致することを確認します。

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

    出力例

    topo-aware-scheduler

  3. NUMA 対応のスケジュール可能なノードに noderesourcetopologies CR が適用されていることを確認します。以下のコマンドを実行します。

    $ oc get noderesourcetopologies.topology.node.k8s.io

    出力例

    NAME                    AGE
    compute-0.example.com   17h
    compute-1.example.com   17h

    注記

    ノードの数は、マシン設定プール (mcp) ワーカー定義によって設定されているワーカーノードの数と等しくなければなりません。

  4. 次のコマンドを実行して、スケジュール可能なすべてのノードの NUMA ゾーンの粒度を確認します。

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

    出力例

    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:
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources:
        - 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: ""
    # ...

    • ゾーン: ゾーン の各スタンザは、単一の NUMA ゾーンのリソースについて説明します。
    • costs.resources: NUMA ゾーンリソースの現在の状態を指定します。items.zones.resources.available 以下に記載されているリソースが、保証された各 Pod に割り当てられた排他的な NUMA ゾーンリソースに対応していることを確認します。

9.7.1. より正確なリソース可用性の報告

より正確なリソース可用性を報告し、トポロジーアフィニティーエラーを最小限に抑えるには、NUMA Resources Operator の cacheResyncPeriod 仕様を有効にします。この設定では、ノード上の保留中のリソースを監視し、スケジューラーキャッシュ内で同期しますが、同期間隔を短くするとネットワーク負荷が増加します。

間隔が短いほど、ネットワーク負荷が大きくなります。デフォルトでは、cacheResyncPeriod 仕様は無効になっています。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      $ oc get NUMAResourcesScheduler

      出力例

      NAME                     AGE
      numaresourcesscheduler   92m

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      出力例

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 次の YAML を nro-scheduler-cacheresync.yaml ファイルに保存します。この例では、ログレベルを Debug に変更します。

    apiVersion: nodetopology.openshift.io/v1
    kind: NUMAResourcesScheduler
    metadata:
      name: numaresourcesscheduler
    spec:
      imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.16"
      cacheResyncPeriod: "5s"
    • spec.cacheResyncPeriod: スケジューラーキャッシュの同期間隔を秒単位で入力します。ほとんどの実装では、5s という値が一般的です。
  3. 次のコマンドを実行して、更新された NUMAResourcesScheduler リソースを作成します。

    $ oc create -f nro-scheduler-cacheresync.yaml

    出力例

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

検証

  1. NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、CRD が正常に作成されたことを確認します。

      $ oc get crd | grep numaresourcesschedulers

      出力例

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      出力例

      NAME                     AGE
      numaresourcesscheduler   3h26m

  2. スケジューラーのログが増加したログレベルを示していることを確認します。

    1. 以下のコマンドを実行して、openshift-numaresources namespace で実行されている Pod のリストを取得します。

      $ oc get pods -n openshift-numaresources

      出力例

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m

    2. 次のコマンドを実行して、セカンダリースケジューラー Pod のログを取得します。

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      出力例

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

9.7.2. 高パフォーマンスワークロードの実行場所の変更

高性能ワークロードの処理を最適化するには、NUMA 対応セカンダリースケジューラーのデフォルトの配置動作を変更します。この設定では、デフォルトのリソース可用性に依存するのではなく、コンピュートノード内の特定の NUMA ノードにワークロードを割り当てることができます。

ワークロードの実行場所を変更する場合は、NUMAResourcesScheduler カスタムリソースに scoringStrategy 設定を追加し、その値を MostAllocated または BalancedAllocation のいずれかに設定します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次の手順を使用して、現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      $ oc get NUMAResourcesScheduler

      出力例

      NAME                     AGE
      numaresourcesscheduler   92m

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      出力例

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 次の YAML を nro-scheduler-mostallocated.yaml ファイルに保存します。この例では、scoringStrategyMostAllocated に変更します。

    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"
    # ...

    spec.imageSpec.scoringStrategy: scoringStrategy の 設定が省略された場合、デフォルトの LeastAllocated が適用されます。

  3. 次のコマンドを実行して、更新された NUMAResourcesScheduler リソースを作成します。

    $ oc create -f nro-scheduler-mostallocated.yaml

    出力例

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

検証

  1. 次の手順を使用して、NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、カスタムリソース定義 (CRD) が正常に作成されたことを確認します。

      $ oc get crd | grep numaresourcesschedulers

      出力例

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      出力例

      NAME                     AGE
      numaresourcesscheduler   3h26m

  2. 次のコマンドを実行して、スケジューラーの関連する ConfigMap リソースを確認し、ScoringStrategy が正しく適用されていることを確認します。

    $ oc get -n openshift-numaresources cm topo-aware-scheduler-config -o yaml | grep scoring -A 1

    出力例

    scoringStrategy:
      type: MostAllocated

9.7.3. NUMA 対応スケジューラーログの確認

NUMA 対応スケジューラーに関する問題のトラブルシューティングを行うには、スケジューラーのログを確認してください。必要に応じて、NUMAResourcesScheduler カスタムリソース (CR) のログレベルを上げて、より詳細な診断データを取得してください。

許容値は NormalDebug、および Trace で、Trace が最も詳細なオプションとなります。

注記

セカンダリースケジューラーのログレベルを変更するには、実行中のスケジューラーリソースを削除し、ログレベルを変更して再デプロイします。このダウンタイム中、スケジューラーは新しいワークロードのスケジューリングに使用できません。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      $ oc get NUMAResourcesScheduler

      出力例

      NAME                     AGE
      numaresourcesscheduler   90m

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      出力例

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 以下の YAML をファイル nro-scheduler-debug.yaml に保存します。この例では、ログレベルを Debug に変更します。

    apiVersion: nodetopology.openshift.io/v1
    kind: NUMAResourcesScheduler
    metadata:
      name: numaresourcesscheduler
    spec:
      imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.16"
      logLevel: Debug
    # ...
  3. 次のコマンドを実行して、更新された Debug ロギング NUMAResourcesScheduler リソースを作成します。

    $ oc create -f nro-scheduler-debug.yaml

    出力例

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

検証

  1. NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、CRD が正常に作成されたことを確認します。

      $ oc get crd | grep numaresourcesschedulers

      出力例

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      出力例

      NAME                     AGE
      numaresourcesscheduler   3h26m

  2. スケジューラーのログが増加したログレベルを示していることを確認します。

    1. 以下のコマンドを実行して、openshift-numaresources namespace で実行されている Pod のリストを取得します。

      $ oc get pods -n openshift-numaresources

      出力例

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m

    2. 次のコマンドを実行して、セカンダリースケジューラー Pod のログを取得します。

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      出力例

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

9.7.4. リソーストポロジーエクスポーターのトラブルシューティング

noderesourcetopologies オブジェクトで予期しない結果が発生した場合は、resource- トポロジー -exporter の ログを確認してください。この診断データをレビューすることで、クラスター内の設定上の問題を特定し、修正することができます。

注記

クラスター内の NUMA リソーストポロジーエクスポーターインスタンスには、参照先のノード名が付けられていることを確認してください。たとえば、worker という名前のコンピュートノードには、worker という名前の対応する noderesourcetopologies オブジェクトが必要です。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. NUMA Resources Operator によって管理されるデーモンセットを取得します。各 daemonset には、NUMAResourcesOperator CR 内に対応する nodeGroup があります。以下のコマンドを実行します。

    $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"

    出力例

    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}

  2. 前のステップの name の値を使用して、対象となる daemonset のラベルを取得します。

    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

    出力例

    {"name":"resource-topology"}

  3. 次のコマンドを実行して、resource-topology ラベルを使用して Pod を取得します。

    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

    出力例

    NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
    numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
    numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com

  4. トラブルシューティングしているノードに対応するワーカー Pod で実行されている resource-topology-exporter コンテナーのログを調べます。以下のコマンドを実行します。

    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

    出力例

    I0221 13:38:18.334140       1 main.go:206] using sysinfo:
    reservedCpus: 0,1
    reservedMemory:
      "0": 1178599424
    I0221 13:38:18.334370       1 main.go:67] === System information ===
    I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
    I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
    I0221 13:38:18.546750       1 main.go:72]
    cpus: allocatable "2-103"
    hugepages-1Gi:
      numa cell 0 -> 6
      numa cell 1 -> 1
    hugepages-2Mi:
      numa cell 0 -> 64
      numa cell 1 -> 128
    memory:
      numa cell 0 -> 45758Mi
      numa cell 1 -> 48372Mi

9.7.5. 欠落しているリソーストポロジーエクスポーター設定マップの修正

リソーストポロジーエクスポーター (RTE) の config map が欠落している問題を修正するには、クラスター内の誤った設定を解決してください。この問題を修正することで、RTE デーモンセットの Pod のログに設定の欠落が示された場合でも、NUMA Resources Operator が正しく機能することが保証されます。

以下のログメッセージの例は、設定が不足していることを示しています。

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

前のログメッセージは、必要な設定を含む kubeletconfig がクラスターに正しく適用されなかったため、RTE configmap が欠落したことを示しています。たとえば、次のクラスターには numaresourcesoperator-worker configmap カスタムリソース (CR) がありません。

$ oc get configmap

出力例:

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 configmapnumaresourcesoperator-worker configmap CR も返します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 特権のユーザーとしてログインしました。
  • NUMA Resources Operator をインストールし、NUMA 対応のセカンダリースケジューラーをデプロイしました。

手順

  1. 次のコマンドを使用して、kubeletconfigspec.machineConfigPoolSelector.matchLabelsMachineConfigPool (mcp) ワーカー CR の metadata.labels の値を比較します。

    1. 次のコマンドを実行して、kubeletconfig ラベルを確認します。

      $ oc get kubeletconfig -o yaml

      出力例

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled

    2. 次のコマンドを実行して、mcp ラベルを確認します。

      $ oc get mcp worker -o yaml

      出力例

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""

      cnf-worker-tuning: enabled ラベルが MachineConfigPool オブジェクトに存在しません。

  2. MachineConfigPool CR を編集して、不足しているラベルを含めます。次に例を示します。

    $ oc edit mcp worker -o yaml

    出力例

    labels:
      machineconfiguration.openshift.io/mco-built-in: ""
      pools.operator.machineconfiguration.openshift.io/worker: ""
      cnf-worker-tuning: enabled

  3. ラベルの変更を適用し、クラスターが更新された設定を適用するのを待ちます。

検証

  • 不足している numaresourcesoperator-worker configmap CR が適用されていることを確認します。

    $ oc get configmap

    出力例

    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

9.7.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 イメージを指定する必要があります。

    $ oc adm must-gather --image=registry.redhat.io/openshift4/numaresources-must-gather-rhel9:v4.16

第10章 スケーラビリティとパフォーマンスの最適化

10.1. ストレージの最適化

ストレージを最適化すると、すべてのリソースでストレージの使用を最小限に抑えることができます。管理者は、ストレージを最適化することで、既存のストレージリソースが効率的に機能できるようにすることができます。

10.1.1. 利用可能な永続ストレージオプション

OpenShift Container Platform 環境を最適化するには、利用可能な永続ストレージオプションを確認してください。これらの選択肢を理解することで、特定のワークロード要件を満たす適切なストレージ設定を選択できます。

Expand
表10.1 利用可能なストレージオプション
ストレージタイプ説明

ブロック

  • ブロックデバイスとしてオペレーティングシステムに公開されます。
  • ストレージを完全に制御する必要があり、ファイルシステムを介さずにファイル上で低レベルで動作するアプリケーションに適しています。
  • ストレージエリアネットワーク (SAN) とも呼ばれる。
  • 共有不可。つまり、このタイプのエンドポイントには一度に 1 つのクライアントしか接続できません。

AWS EBS および VMware vSphere は、OpenShift Container Platform で永続ボリューム (PV) の動的なプロビジョニングをサポートします。

ファイル

  • マウントされるファイルシステムのエクスポートとして、OS に公開されます。
  • ネットワーク接続ストレージ (NAS) とも呼ばれます。
  • 同時実行、レイテンシー、ファイルロックのメカニズムその他の各種機能は、プロトコルおよび実装、ベンダー、スケールによって大きく異なります。

RHEL NFS、NetApp NFS、およびベンダー独自の NFS。

オブジェクト

  • REST API エンドポイント経由でアクセス可能です。
  • OpenShift イメージレジストリーで使用するように設定できます。
  • アプリケーションは、ドライバーをアプリケーションやコンテナーに組み込む必要があります。

AWS S3.

  • ファイル:NetApp NFS は、Trident プラグインを使用する場合、動的な PV プロビジョニングをサポートします。

10.1.4. データストレージ管理

OpenShift Container Platform でデータストレージを効果的に管理するには、コンポーネントがデータを書き込む主要なディレクトリーを確認してください。このリファレンスを参照することで、システムコンポーネントが使用する具体的なパスを特定し、容量要件を計画したり、必要なメンテナンスを実行したりすることができます。

以下の表は、OpenShift Container Platform コンポーネントがデータを書き込むメインディレクトリーの概要を示しています。

Expand
表10.3 OpenShift Container Platform データを保存するメインディレクトリー
ディレクトリー注記サイジング予想される拡張

/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 が永続ボリュームを使用している場合は最小になります。一時ストレージを使用する場合はすぐに拡張する可能性があります。

/var/log

すべてのコンポーネントのログファイルです。

10 から 30 GB。

ログファイルはすぐに拡張する可能性があります。サイズは拡張するディスク別に管理するか、ログローテーションを使用して管理できます。

10.1.5. Microsoft Azure のストレージパフォーマンスの最適化

Microsoft Azure 上で最適なクラスターパフォーマンスを確保するには、OpenShift Container Platform および Kubernetes 用に高速なストレージを設定してください。コントロールプレーンノード上の etcd には、高性能ディスクを優先的に割り当ててください。これらのコンポーネントはディスクのレイテンシーに敏感です。

運用環境の Azure クラスターおよび負荷の高いワークロードを持つクラスターの場合、コントロールプレーンマシン用の仮想マシンオペレーティングシステムディスクは、テスト済みで推奨されている最小スループットである 5000 IOPS/200 MBps を維持できる必要があります。このスループットは、P30 (最低 1 TiB Premium SSD) を使用することで実現できます。Azure および Azure Stack Hub の場合、ディスクパフォーマンスは SSD ディスクサイズに直接依存します。Standard_D8s_v3 仮想マシンまたは他の同様のマシンタイプでサポートされるスループットと 5000 IOPS の目標を達成するには、少なくとも P30 ディスクが必要です。

データ読み取り時のレイテンシーを低く抑え、高い IOPS およびスループットを実現するには、ホストのキャッシュを ReadOnly に設定する必要があります。仮想マシンメモリーまたはローカル SSD ディスクに存在するキャッシュからのデータの読み取りは、blob ストレージにあるディスクからの読み取りよりもはるかに高速です。

10.2. ルーティングの最適化

パフォーマンスを最適化するには、OpenShift Container Platform の HAProxy ルーターをスケールまたは設定してください。この作業を行うことで、効率的な交通管理を確保し、特定の作業負荷要件に対応することができます。

10.2.1. ベースライン Ingress Controller (ルーター) のパフォーマンス

パフォーマンスの基準値を確立するために、OpenShift Container Platform Ingress Controller のロールを確認してください。このコンポーネントは、クラスターのルーターとして、受信トラフィックのエントリーポイントとして機能し、ルートと Ingress を使用して設定されたアプリケーションとサービスにリクエストを転送します。

1 秒に処理される HTTP 要求について、単一の HAProxy ルーターを評価する場合に、パフォーマンスは多くの要因により左右されます。特に以下が含まれます。

  • HTTP keep-alive/close モード
  • ルートタイプ
  • TLS セッション再開のクライアントサポート
  • ターゲットルートごとの同時接続数
  • ターゲットルート数
  • バックエンドサーバーのページサイズ
  • 基礎となるインフラストラクチャー (ネットワーク/SDN ソリューション、CPU など)

特定の環境でのパフォーマンスは異なりますが、Red Hat ラボはサイズが 4 vCPU/16GB RAM のパブリッククラウドインスタンスでテストしています。1kB 静的ページを提供するバックエンドで終端する 100 ルートを処理する単一の HAProxy ルーターは、1 秒あたりに以下の数のトランザクションを処理できます。

HTTP keep-alive モードのシナリオの場合:

Expand
暗号化LoadBalancerServiceHostNetwork

なし

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

HTTP close (keep-alive なし) のシナリオの場合:

Expand
暗号化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 倍のパフォーマンスになることを予想できます。このオーバーヘッドは、パブリッククラウドにある仮想化レイヤーにより発生し、プライベートクラウドベースの仮想化にも多くの場合、該当します。以下の表は、ルーターの背後で使用するアプリケーション数に関するガイドです。

Expand
アプリケーション数アプリケーションタイプ

5-10

静的なファイル/Web サーバーまたはキャッシュプロキシー

100-1000

動的なコンテンツを生成するアプリケーション

通常、HAProxy は、使用しているテクノロジーに応じて、最大 1000 個のアプリケーションのルートをサポートできます。Ingress Controller のパフォーマンスは、言語や静的コンテンツと動的コンテンツの違いを含め、その背後にあるアプリケーションの機能およびパフォーマンスによって制限される可能性があります。

Ingress またはルーターのシャード化は、アプリケーションに対してより多くのルートを提供するために使用され、ルーティング層の水平スケーリングに役立ちます。

10.2.3. Ingress Controller の liveness、準備、および起動プローブの設定

ルーターデプロイメントの正確な状態監視を確保するには、ライブネス、レディネス、およびスタートアッププローブのタイムアウト値を設定してください。この作業を行うことで、OpenShift Container Platform Ingress Controller で使用されるデフォルト設定を、ご使用の環境に合わせて調整できます。

ルーターの liveness および readiness プローブは、デフォルトのタイムアウト値である 1 秒を使用します。これは、ネットワークまたはランタイムのパフォーマンスが著しく低下している場合には短すぎます。プローブのタイムアウトにより、アプリケーション接続を中断する不要なルーターの再起動が発生する可能性があります。より大きなタイムアウト値を設定する機能により、不要で不要な再起動のリスクを減らすことができます。

ルーターコンテナーの livenessProbereadinessProbe、および startupProbe パラメーターの timeoutSeconds 値を更新できます。

Expand
パラメーター説明

livenessProbe

livenessProbe は、Pod が停止していて再起動が必要かどうかを kubelet に報告します。

readinessProbe

readinessProbe は、Pod が正常かどうかを報告します。準備プローブが異常な Pod を報告すると、kubelet は Pod をトラフィックを受け入れる準備ができていないものとしてマークします。その後、その Pod のエンドポイントは準備ができていないとマークされ、このステータスが kube-proxy に伝播されます。ロードバランサーが設定されたクラウドプラットフォームでは、kube-proxy はクラウドロードバランサーと通信して、その Pod を持つノードにトラフィックを送信しません。

startupProbe

startupProbe は、kubelet がルーターの活性と準備のプローブの送信を開始する前に、ルーター Pod の初期化に最大 2 分を与えます。この初期化時間により、多くのルートまたはエンドポイントを持つルーターが時期尚早に再起動するのを防ぐことができます。

重要

タイムアウト設定オプションは、問題を回避するために使用できる高度なチューニング手法です。しかし、これらの問題は最終的には診断されるべきであり、プローブのタイムアウトを引き起こす問題については、サポートケースまたは Jira 課題 を起票する必要がある。

次の例は、デフォルトのルーター展開に直接パッチを適用して、活性プローブと準備プローブに 5 秒のタイムアウトを設定する方法を示しています。

$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

検証

$ 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

10.2.4. HAProxy リロード間隔の設定

ルーターのパフォーマンスを最適化するには、HAProxy のリロード間隔を設定してください。OpenShift Container Platform のルーターは、ルートやエンドポイントへの変更を適用するために HAProxy をリロードし、更新ごとに接続を処理するための新しいプロセスを生成します。

HAProxy は、それらの接続がすべて閉じられるまで、既存の接続を処理するために古いプロセスを実行し続けます。古いプロセスの接続が長く続くと、これらのプロセスはリソースを蓄積して消費する可能性があります。

デフォルトの最小 HAProxy リロード間隔は 5 秒です。spec.tuningOptions.reloadInterval フィールドを使用して Ingress Controller を設定し、より長い最小リロード間隔を設定できます。

警告

最小 HAProxy リロード間隔に大きな値を設定すると、ルートとそのエンドポイントの更新を監視する際にレイテンシーが発生する可能性があります。リスクを軽減するには、更新の許容レイテンシーよりも大きな値を設定しないようにしてください。

手順

  • 次のコマンドを実行して、Ingress Controller のデフォルト最小 HAProxy リロード間隔を 15 秒に変更します。

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'

10.3. ネットワークの最適化

ノード間でトラフィックをトンネルするには、汎用ネットワーク仮想化カプセル化 (Geneve) を使用します。ネットワークインターフェイスコントローラー (NIC) のオフロード機能を使用することで、このネットワークのパフォーマンスを調整できます。

OpenShift SDN は OpenvSwitch、Virtual extensible LAN (VXLAN) トンネル、OpenFlow ルール、iptables を使用します。このネットワークは、ジャンボフレーム、マルチキュー、ethtool 設定を使用して調整できます。

OVN-Kubernetes は、トンネルプロトコルとして VXLAN ではなく Generic Network Virtualization Encapsulation (Geneve) を使用します。このネットワークは、ネットワークインターフェイスコントローラー (NIC) オフロードを使用して調整できます。

OpenShift Container Platform を実行するクラウド、仮想環境、およびベアメタル環境では、最小限の調整でネットワークインターフェイスカード (NIC) の機能の大部分を利用できます。OVN-Kubernetes と Geneve トンネリングを使用する実稼働クラスターは、特別な設定なしで、高スループットのトラフィックを効率的に処理し、スケールアップ (100 Gbps NIC の利用など) およびスケールアウト (NIC の追加など) を行うことができます。

効率の最大化が重要な一部の高パフォーマンス環境では、ターゲットを絞ったパフォーマンスチューニングによって、CPU 使用率を最適化し、オーバーヘッドを削減し、NIC の機能を最大限に活用できます。

最大スループットと CPU 効率が重要な環境では、次の方法を使用してパフォーマンスをさらに最適化できます。

  • iPerf3k8s-netperf などのツールを使用して、ネットワークパフォーマンスを検証します。これらのツールを使用することで、Pod およびノードのインターフェイス全体にわたるスループット、レイテンシー、および 1 秒あたりのパケット数 (PPS) をベンチマークできます。
  • Border Gateway Protocol (BGP) などの OVN-Kubernetes ユーザー定義ネットワーク (UDN) ルーティング手法を評価します。
  • Geneve オフロード対応ネットワークアダプターを使用します。Geneve オフロードは、システムの CPU から、パケットのチェックサム計算と関連の CPU オーバーヘッドを、ネットワークアダプター上の専用のハードウェアに移動します。これにより、CPU サイクルが解放され、Pod やアプリケーションが利用できるようになり、ユーザーはネットワークインフラストラクチャーの帯域幅を最大限に活用できるようになります。

10.3.2. ネットワークでの MTU の最適化

ネットワークパフォーマンスを最適化するには、最大伝送単位 (MTU) の設定を設定してください。ネットワークインターフェイスコントローラー (NIC) の MTU とクラスターネットワークの MTU の関係を理解することで、効率的なデータ伝送を確保し、パケットの断片化を防ぐことができます。

NIC の MTU は OpenShift Container Platform のインストール時に設定します。また、クラスターの MTU の変更は、インストール後のタスクとして実行できます。詳細は、「クラスターネットワーク MTU の変更」を参照してください。

OVN-Kubernetes プラグインを使用するクラスターの場合、MTU はネットワークの NIC がサポートする最大値より少なくとも 100 バイト小さくなければなりません。スループットを最適化する場合は、8900 など、可能な限り大きな値を選択します。レイテンシーを最低限に抑えるために最適化するには、より小さい値を選択します。

重要

クラスターが OVN-Kubernetes プラグインを使用し、ネットワークが NIC を使用してネットワーク経由で断片化されていないジャンボフレームパケットを送受信する場合は、Pod が失敗しないように、NIC の MTU 値として 9000 バイトを指定する必要があります。

OpenShift SDN ネットワークプラグインオーバーレイ MTU は、NIC MTU よりも少なくとも 50 バイト小さくする必要があります。これは、SDN オーバーレイのヘッダーに相当します。したがって、通常のイーサネットネットワークでは、これを 1450 に設定する必要があります。ジャンボフレームイーサネットネットワークでは、これを 8950 に設定する必要があります。これらの値は、NIC に設定された MTU に基づいて、Cluster Network Operator によって自動的に設定される必要があります。したがって、クラスター管理者は通常、これらの値を更新しません。Amazon Web Services (AWS) およびベアメタル環境は、ジャンボフレームイーサネットネットワークをサポートします。この設定は、特に伝送制御プロトコル (TCP) のスループットに役立ちます。

注記

OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。

OVN および Geneve については、MTU は最低でも NIC MTU より 100 バイト少なくなければなりません。

注記

この 50 バイトのオーバーレイヘッダーは、OpenShift SDN ネットワークプラグインに関連します。他の SDN ソリューションの場合はこの値を若干変動させる必要があります。

10.3.4. IPsec の影響

パフォーマンスのオーバーヘッドを考慮するため、IPsec を有効にした場合の影響を確認してください。ノードホスト上でのトラフィックの暗号化と復号化は CPU パワーを消費するため、特定の IP セキュリティーシステムに関係なく、スループットと CPU 使用率の両方に影響を与えます。

IPSec は、NIC に到達する前に IP ペイロードレベルでトラフィックを暗号化して、NIC オフロードに使用されてしまう可能性のあるフィールドを保護します。これは、IPSec が有効になっている場合、一部の NIC アクセラレーション機能が使用できなくなる可能性があることを意味します。この状況は、スループットの低下と CPU 使用率の増加につながります。

10.4. マウント namespace のカプセル化による CPU 使用率の最適化

マウント namespace のカプセル化を使用して kubelet および CRI-O プロセスにプライベート namespace を提供することで、OpenShift Container Platform クラスターでの CPU 使用率を最適化できます。これにより、機能に違いはなく、systemd が使用するクラスター CPU リソースが削減されます。

重要

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

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

10.4.1. マウント namespace のカプセル化

ホストオペレーティングシステムがマウントポイントを常にスキャンするのを防ぐため、カプセル化のプロセスを見直してください。このメカニズムは、Kubernetes のマウントネームスペースを別の場所に移動することで、異なるネームスペース内のプロセスが隔離された状態を維持し、互いのファイルを参照できないようにします。

ホストオペレーティングシステムは 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、およびコンテナーランタイムが単一のマウントネームスペースを共有していることを示しています。

  • 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 の動作は変更されていません。

10.4.2. マウント namespace のカプセル化の設定

クラスターのリソースオーバーヘッドを削減するには、マウント名前空間のカプセル化を設定してください。この設定は、マウントされた名前空間を別の場所に移動することでパフォーマンスを最適化し、ホストオペレーティングシステムがそれらを常にスキャンすることを防ぎます。

注記

マウント名前空間のカプセル化はテクノロジープレビュー機能であり、デフォルトでは無効になっています。この機能を使用するには、手動で有効にする必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次の YAML を使用して、mount_namespace_config.yaml という名前のファイルを作成します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99-kubens-master
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - enabled: true
            name: kubens.service
    ---
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 99-kubens-worker
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - enabled: true
            name: kubens.service
  2. 次のコマンドを実行して、マウント namespace MachineConfig CR を適用します。

    $ oc apply -f mount_namespace_config.yaml

    出力例

    machineconfig.machineconfiguration.openshift.io/99-kubens-master created
    machineconfig.machineconfiguration.openshift.io/99-kubens-worker created

  3. MachineConfig CR がクラスターに適用されるまでには、最大 30 分かかる場合があります。次のコマンドを実行して、MachineConfig CR のステータスをチェックできます。

    $ oc get mcp

    出力例

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master   rendered-master-03d4bc4befb0f4ed3566a2c8f7636751   False     True       False      3              0                   0                     0                      45m
    worker   rendered-worker-10577f6ab0117ed1825f8af2ac687ddf   False     True       False      3              1                   1

  4. 次のコマンドを実行した後、MachineConfig CR がすべてのコントロールプレーンとワーカーノードに正常に適用されるまで待ちます。

    $ oc wait --for=condition=Updated mcp --all --timeout=30m

    出力例

    machineconfigpool.machineconfiguration.openshift.io/master condition met
    machineconfigpool.machineconfiguration.openshift.io/worker condition met

検証

  1. クラスターホストへのデバッグシェルを開きます。

    $ oc debug node/<node_name>
  2. chroot セッションを開きます。

    sh-4.4# chroot /host
  3. systemd マウント namespace を確認します。

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

    出力例

    mnt:[4026531953]

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

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

    出力例

    mnt:[4026531840]

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

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

    出力例

    mnt:[4026531840]

    これらのコマンドは、systemd、kubelet、およびコンテナーランタイムに関連付けられたマウント namespace を返します。OpenShift Container Platform では、コンテナーランタイムは CRI-O です。

    カプセル化は、前述の出力例のように、systemd が kubelet および CRI-O とは異なるマウントネームスペースにある場合に有効になります。3 つのプロセスすべてが同じマウント namespace にある場合、カプセル化は有効ではありません。

10.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 シェルを開きます。以下に例を示します。

    $ ssh core@<node_name>
  2. root ユーザーとして、提供された kubensenter スクリプトを使用してコマンドを実行します。Kubernetes namespace 内で単一のコマンドを実行するには、コマンドと任意の引数を kubensenter スクリプトに提供します。たとえば、Kubernetes namespace 内で findmnt コマンドを実行するには、次のコマンドを実行します。

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

    出力例

    kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
    TARGET                                SOURCE                 FSTYPE     OPTIONS
    /                                     /dev/sda4[/ostree/deploy/rhcos/deploy/32074f0e8e5ec453e56f5a8a7bc9347eaa4172349ceab9c22b709d9d71a3f4b0.0]
    |                                                            xfs        rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota
                                          shm                    tmpfs
    ...

  3. Kubernetes namespace 内で新しいインタラクティブシェルを開始するには、引数を指定せずに kubensenter スクリプトを実行します。

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

    出力例

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

10.4.4. カプセル化された namespace で追加サービスを実行する

kubelet、CRI-O、またはコンテナーによって作成されたマウントポイントを監視ツールで表示できるようにするには、OpenShift Container Platform に付属の kubensenter スクリプトを使用します。このツールを使用することで、Kubernetes マウントポイント内でコマンドを実行でき、既存のツールがカプセル化された名前空間内で確実に動作するようにできます。

kubensenter スクリプトは、マウントカプセル化機能の状態を認識しており、カプセル化が有効になっていない場合でも安全に実行できます。その場合、スクリプトはデフォルトのマウント namespace で提供されたコマンドを実行します。

たとえば、systemd サービスを新しい Kubernetes マウント namespace 内で実行する必要がある場合は、サービスファイルを編集し、kubensenterExecStart= コマンドラインを使用します。

[Unit]
Description=Example service
[Service]
ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2

第11章 ベアメタルホストの管理

OpenShift Container Platform 内でベアメタルホストを直接設定できます。ベアメタルクラスターでノードをプロビジョニングおよび管理するには、Machine および MachineSet カスタムリソース (CR) を使用します。

11.1. ベアメタルホストおよびノードについて

Red Hat Enterprise Linux CoreOS (RHCOS) ベアメタルホストをクラスターのノードとしてプロビジョニングするには、まずベアメタルホストのハードウェアに対応する MachineSet カスタムリソース (CR) オブジェクトを作成します。

ベアメタルホストのコンピュートマシンセットは、お客様の設定に固有のインフラストラクチャーコンポーネントを記述します。特定の Kubernetes ラベルをこれらのコンピュートマシンセットに適用してから、インフラストラクチャーコンポーネントを更新して、それらのマシンでのみ実行されるようにします。

metal3.io/autoscale-to-hosts アノテーションを含む関連する MachineSet CR をスケールアップすると、マシン CR が自動的に作成されます。OpenShift Container Platform は、MachineSet CR で指定されたホストに対応するベアメタルノードをプロビジョニングするために、Machine CR を使用します。

11.2. ベアメタルホストのメンテナンス

クラスターインベントリーが物理インフラストラクチャーを正確に反映するようにするには、OpenShift Container Platform の Web コンソールを使用して、ベアメタルホスト設定の詳細を維持してください。

手順

  1. Web コンソールから、以下の手順を実行してください。

    1. ComputeBare Metal Hosts に移動します。
    2. アクション ドロップダウンメニューからタスクを選択してください。
    3. ベースボード管理コントローラー (BMC) の詳細、ホストのブート MAC アドレス、電源管理の有効化などといった項目を管理します。また、ホストのネットワークインターフェイスおよびドライブの詳細を確認することもできます。
  2. ベアメタルホストをメンテナンスモードに移行します。ホストをメンテナンスモードに移行すると、スケジューラーは対応するベアメタルノードから管理対象のすべてのワークロードを移動します。新しいワークロードは、メンテナンスモードの間はスケジュールされません。
  3. Web コンソールでベアメタルホストのプロビジョニングを解除します。ホストのプロビジョニング解除により以下のアクションが実行されます。

    1. ベアメタルホストの CR に cluster.k8s.io/delete-machine: true という アノテーションを付けます。
    2. 関連するコンピュートマシン群の規模を縮小します。

      注記

      デーモンセットおよび管理対象外の静的 Pod を別のノードに最初に移動することなく、ホストの電源をオフにすると、サービスの中断やデータの損失が生じる場合があります。

11.2.1. Web コンソールを使用したベアメタルホストのクラスターへの追加

物理ハードウェアをクラスターに統合するには、Web コンソールを使用してベアメタルホストを追加できます。これらのホストを追加することで、Web コンソールから直接これらのノードをプロビジョニングおよび管理できるようになります。

前提条件

  • RHCOS クラスターのベアメタルへのインストール
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

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

    注記

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

11.2.2. Web コンソールで YAML を使用してベアメタルホストをクラスターに追加する

ベアメタルホストを記述した YAML ファイルを使用することで、Web コンソールからクラスターにベアメタルホストを追加できます。

前提条件

  • クラスターで使用するために、ベアメタルインフラストラクチャー上に RHCOS コンピュートマシンをインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ベアメタルホスト用の シークレット CR を作成します。

手順

  1. Web コンソールで、ComputeBare Metal Hosts に移動します。
  2. Add HostNew from YAML を選択します。
  3. 以下の YAML をコピーして貼り付け、ホストの詳細で関連フィールドを変更します。

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: <bare_metal_host_name>
    spec:
      online: true
      bmc:
        address: <bmc_address>
        credentialsName: <secret_credentials_name>
        disableCertificateVerification: True
      bootMACAddress: <host_boot_mac_address>
    # ...

    ここでは、以下のようになります。

    spec.bmc.credentialsName
    有効な シークレット CR への参照を指定します。Bare Metal Operator は、credentialsName で参照される有効な Secret がないと、ベアメタルホストを管理できません。秘密情報とその作成方法の詳細は、秘密情報の理解を参照してください。
    spec.bmc.disableCertificateVerification
    クラスターとベースボード管理コントローラー (BMC) 間の TLS ホスト検証を必須とするかどうかを指定します。このフィールドを true に設定すると、TLS ホスト検証が無効になります。
  4. 作成 を選択して YAML ファイルを保存し、新しいベアメタルホストを作成します。
  5. 利用可能なベアメタルホストの数に合わせて、レプリカの数を増やしてください。ComputeMachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシン数を増やします。

    注記

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

11.2.3. 利用可能なベアメタルホストの数に応じてマシンを自動的にスケーリングします。

利用可能な BareMetalHost オブジェクトの数に一致する Machine オブジェクトの数を自動的に作成するには、metal3.io/autoscale-to-hosts アノテーションを MachineSet オブジェクトに追加します。

前提条件

  • クラスターで使用するために、RHCOS ベアメタルコンピュートマシンをインストールし、対応する BareMetalHost オブジェクトを作成します。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. コンピュートマシンセットの自動スケーリングを設定するには、次のコマンドを実行してコンピュートマシンセットにアノテーションを付けます。

    $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'
    • <machineset>: 自動スケーリング用に設定するコンピュートマシンセットの名前を指定します。
    • <any_value> 値を指定します 。true"" などです。
  2. 新しいスケーリングされたマシンが起動するまで待ちます。

    注記

    以下の条件が満たされた場合、BareMetalHost オブジェクトは、Machine オブジェクトが作成された MachineSet に対して引き続きカウントされます。

    • クラスター内にマシンを作成するには、BareMetalHost オブジェクトを使用します。
    • その後、BareMetalHost のラベルまたはセレクターを変更します。

11.2.4. プロビジョナーノードからベアメタルホストを削除する

状況によっては、ベアメタルホストをプロビジョナーノードから一時的に削除したい場合があります。たとえば、利用可能な BareMetalHost オブジェクトの数と一致する Machine オブジェクトの数を管理しないようにするには、MachineSet オブジェクトに baremetalhost.metal3.io/detached アノテーションを追加します。

プロビジョニング中に、OpenShift Container Platform 管理コンソールを使用したり、マシン設定プールの更新の結果としてベアメタルホストの再起動がトリガーされた場合を例に考えてみましょう。この場合、OpenShift Container Platform は統合型 Dell Remote Access Controller (iDRAC) にログインし、ジョブキューの削除を実行します。

注記

このアノテーションは、ProvisionedExternallyProvisioned、または Ready/Available 状態にある BareMetalHost オブジェクトにのみ有効です。

前提条件

  • クラスターで使用するために、RHCOS ベアメタルコンピュートマシンをインストールし、対応する BareMetalHost オブジェクトを作成します。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. コンピュートマシンセットの自動スケーリングを設定するには、次のコマンドを実行してコンピュートマシンセットにアノテーションを付けます。

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

    新しいマシンが起動するまで待ちます。

    注記

    BareMetalHost オブジェクトを使用してクラスター内にマシンを作成し、その後 BareMetalHost の ラベルまたはセレクターが変更された場合でも、BareMetalHost オブジェクトは、マシン オブジェクトが作成された MachineSet に対して引き続きカウントされます。

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

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

11.2.5. Web コンソールを使用してベアメタルホストの電源を切る

Web コンソールからベアメタルクラスターホストの電源をオフにすることができます。ホストの電源を切る前に、そのノードをスケジュール不可としてマークし、ノードからすべての Pod とワークロードをドレインしてください。

前提条件

  • クラスターで使用するために、ベアメタルインフラストラクチャーに RHCOS コンピュートマシンをインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 管理対象ホストを設定し、クラスターホストに Baseboard 管理コンソールの認証情報を追加しました。BMC 認証情報を追加するには、クラスターで Secret カスタムリソース (CR) を適用するか、Web コンソールにログインして管理対象となるようにベアメタルホストを設定します。

手順

  1. Nodes に移動し、電源をオフにするノードを選択します。Actions メニューを展開し、Mark as unschedulable を選択します。
  2. Pod デプロイメントを調整するか、またはノードでワークロードをゼロにスケールダウンして、ノード上で実行中の Pod を手動で削除または再配置します。ドレインプロセスが完了するまで待ちます。
  3. ComputeBare Metal Hosts に移動します。
  4. 電源をオフにするベアメタルホストの Options メニュー を展開し、Power Off を選択します。
  5. Immediate power off を選択します。

11.2.6. CLI を使用してベアメタルホストの電源を切る

OpenShift CLI (oc) を使用してクラスターにパッチを適用することで、ベアメタルクラスターホストの電源をオフにすることができます。ホストの電源を切る前に、そのノードをスケジュール不可としてマークし、ノードからすべての Pod とワークロードをドレインしてください。

前提条件

  • クラスターで使用するために、ベアメタルインフラストラクチャーに RHCOS コンピュートマシンをインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 管理対象ホストを設定し、クラスターホストに Baseboard 管理コンソールの認証情報を追加しました。BMC 認証情報を追加するには、クラスターで Secret カスタムリソース (CR) を適用するか、Web コンソールにログインして管理対象となるようにベアメタルホストを設定します。

手順

  1. 管理対象のベアメタルホストの名前を取得するには、次のコマンドを入力します。

    $ oc get baremetalhosts -n openshift-machine-api -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.provisioning.state}{"\n"}{end}'

    出力例

    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. 以下のコマンドを入力して、ノードをスケジュール不可としてマークします。

    $ oc adm cordon <bare_metal_host>
    • <bare_metal_host>: シャットダウンするホストの名前を指定します。たとえば、worker-2.example.com
  3. 以下のコマンドを入力して、ノード上のすべての Pod をドレインします。

    $ oc adm drain <bare_metal_host> --force=true

    レプリケーションコントローラーでサポートされる Pod は、クラスター内の他の利用可能なノードに再スケジュールされます。

  4. 以下のコマンドを入力して、ベアメタルホストを安全に電源オフします。

    $ oc patch <bare_metal_host> --type json -p '[{"op": "replace", "path": "/spec/online", "value": false}]'
  5. ホストの電源を入れた後、次のコマンドを入力して、ノードをワークロードのスケジュール対象にします。

    $ oc adm uncordon <bare_metal_host>

第12章 Bare Metal Event Relay を使用したベアメタルイベントのモニタリング

重要

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

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

12.1. ベアメタルイベント

重要

Bare Metal Event Relay Operator は非推奨になりました。Bare Metal Event Relay Operator を使用してベアメタルホストを監視する機能は、今後の OpenShift Container Platform リリースでは削除される予定です。

Bare Metal Event Relay を使用して、OpenShift Container Platform クラスターで実行されるアプリケーションを、基礎となるベアメタルホストで生成されるイベントにサブスクライブします。Redfish サービスは、ノードでイベントをパブリッシュし、サブスクライブされたアプリケーションに高度なメッセージキューでイベントを送信します。

ベアメタルイベントは、Distributed Management Task Force (DMTF) のガイダンスに基づいて開発されたオープン Redfish 標準に基づいています。Redfish は、REST API を使用してセキュアな業界標準プロトコルを提供します。このプロトコルは、分散された、コンバージドまたはソフトウェア定義のリソースおよびインフラストラクチャーの管理に使用されます。

Redfish から公開されるハードウェア関連のイベントには、以下が含まれます。

  • 温度制限の違反
  • サーバーステータス
  • fan ステータス

Bare Metal Event Relay Operator をデプロイし、アプリケーションをサービスにサブスクライブして、ベアメタルイベントの使用を開始します。Bare Metal Event Relay Operator は Redfish ベアメタルイベントサービスのライフサイクルをインストールし、管理します。

注記

Bare Metal Event Relay は、ベアメタルインフラストラクチャーにプロビジョニングされる単一ノードクラスターの Redfish 対応デバイスでのみ機能します。

12.2. ベアメタルイベントの仕組み

Bare Metal Event Relay により、ベアメタルクラスターで実行されるアプリケーションが Redfish ハードウェアの変更や障害に迅速に対応することができます。たとえば、温度のしきい値の違反、fan の障害、ディスク損失、電源停止、メモリー障害などが挙げられます。これらのハードウェアイベントは、HTTP トランスポートまたは AMQP メカニズムを使用して配信されます。メッセージングサービスのレイテンシーは 10 ミリ秒から 20 ミリ秒です。

Bare Metal Event Relay により、ハードウェアイベントでパブリッシュ - サブスクライブサービスを使用できます。アプリケーションは、REST API を使用してイベントをサブスクライブできます。Bare Metal Event Relay は、Redfish OpenAPI v1.8 以降に準拠するハードウェアをサポートします。

12.2.1. Bare Metal Event Relay データフロー

以下の図は、ベアメタルイベントのデータフローの例を示しています。

図12.1 Bare Metal Event Relay データフロー

ベアメタルイベントデータフロー
12.2.1.1. Operator 管理の Pod

Operator はカスタムリソースを使用して、HardwareEvent CR を使用して Bare Metal Event Relay およびそのコンポーネントが含まれる Pod を管理します。

12.2.1.2. Bare Metal イベントリレー

起動時に、Bare Metal Event Relay は Redfish API をクエリーし、カスタムレジストリーを含むすべてのメッセージレジストリーをダウンロードします。その後、Bare Metal Event Relay は Redfish ハードウェアからサブスクライブされたイベントを受信し始めます。

Bare Metal Event Relay により、ベアメタルクラスターで実行されるアプリケーションが Redfish ハードウェアの変更や障害に迅速に対応することができます。たとえば、温度のしきい値の違反、fan の障害、ディスク損失、電源停止、メモリー障害などが挙げられます。イベントは HardwareEvent CR を使用してレポートされます。

12.2.1.3. クラウドネイティブイベント

クラウドネイティブイベント (CNE) は、イベントデータの形式を定義する REST API 仕様です。

12.2.1.4. CNCF CloudEvents

CloudEvents は、イベントデータの形式を定義するために Cloud Native Computing Foundation (CNCF) によって開発されたベンダーに依存しない仕様です。

12.2.1.5. HTTP トランスポートまたは AMQP ディスパッチルーター

HTTP トランスポートまたは AMQP ディスパッチルーターは、パブリッシャーとサブスクライバー間のメッセージ配信サービスを行います。

注記

HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。

12.2.1.6. クラウドイベントプロキシーサイドカー

クラウドイベントプロキシーサイドカーコンテナーイメージは O-RAN API 仕様をベースとしており、ハードウェアイベントのパブリッシュ - サブスクライブイベントフレームワークを提供します。

12.2.2. サービスを解析する Redfish メッセージ

Bare Metal Event Relay は Redfish イベントを処理する他に、Message プロパティーなしでイベントのメッセージ解析を提供します。プロキシーは、起動時にハードウェアからベンダー固有のレジストリーを含むすべての Redfish メッセージブローカーをダウンロードします。イベントに Message プロパティーが含まれていない場合、プロキシーは Redfish メッセージレジストリーを使用して Message プロパティーおよび Resolution プロパティーを作成し、イベントをクラウドイベントフレームワークに渡す前にイベントに追加します。このサービスにより、Redfish イベントでメッセージサイズが小さくなり、送信レイテンシーが短縮されます。

12.2.3. CLI を使用した Bare Metal Event リレーのインストール

クラスター管理者は、CLI を使用して Bare Metal Event Relay Operator をインストールできます。

前提条件

  • RedFish 対応ベースボード管理コントローラー (BMC) を持つノードでベアメタルハードウェアにインストールされるクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

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

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-bare-metal-events
        labels:
          name: openshift-bare-metal-events
          openshift.io/cluster-monitoring: "true"
    2. namespace CR を作成します。

      $ oc create -f bare-metal-events-namespace.yaml
  2. Bare Metal Event Relay Operator の Operator グループを作成します。

    1. 以下の YAML を bare-metal-events-operatorgroup.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: bare-metal-event-relay-group
        namespace: openshift-bare-metal-events
      spec:
        targetNamespaces:
        - openshift-bare-metal-events
    2. OperatorGroup CR を作成します。

      $ oc create -f bare-metal-events-operatorgroup.yaml
  3. Bare Metal Event Relay にサブスクライブします。

    1. 以下の YAML を bare-metal-events-sub.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bare-metal-event-relay-subscription
        namespace: openshift-bare-metal-events
      spec:
        channel: "stable"
        name: bare-metal-event-relay
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. Subscription CR を作成します。

      $ oc create -f bare-metal-events-sub.yaml

検証

Bare Metal Event Relay Operator がインストールされていることを確認するには、以下のコマンドを実行します。

$ oc get csv -n openshift-bare-metal-events -o custom-columns=Name:.metadata.name,Phase:.status.phase

12.2.4. Web コンソールを使用した Bare Metal Event リレーのインストール

クラスター管理者は、Web コンソールを使用して Bare Metal Event Relay Operator をインストールできます。

前提条件

  • RedFish 対応ベースボード管理コントローラー (BMC) を持つノードでベアメタルハードウェアにインストールされるクラスター。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. OpenShift Container Platform Web コンソールを使用して Bare Metal Event Relay をインストールします。

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

検証

オプション: 以下のチェックを実行して、Operator が正常にインストールされていることを確認できます。

  1. OperatorsInstalled Operators ページに切り替えます。
  2. StatusInstallSucceeded の状態で、Bare Metal Event Relay がプロジェクトにリスト表示されていることを確認します。

    注記

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

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

  • OperatorsInstalled Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
  • WorkloadsPods ページに移動し、プロジェクト namespace で Pod のログを確認します。

12.3. AMQ メッセージングバスのインストール

ノードのパブリッシャーとサブスクライバー間で Redfish ベアメタルイベント通知を渡すには、ノード上でローカルを実行するように AMQ メッセージングバスをインストールし、設定できます。これは、クラスターで使用するために AMQ Interconnect Operator をインストールして行います。

注記

HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

検証

  1. AMQ Interconnect Operator が利用可能で、必要な Pod が実行されていることを確認します。

    $ oc get pods -n amq-interconnect

    出力例

    NAME                                    READY   STATUS    RESTARTS   AGE
    amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
    interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

  2. 必要な bare-metal-event-relay ベアメタルイベントプロデューサー Pod が openshift-bare-metal-events namespace で実行されていることを確認します。

    $ oc get pods -n openshift-bare-metal-events

    出力例

    NAME                                                            READY   STATUS    RESTARTS   AGE
    hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl     2/2     Running   0          25s

12.4. クラスターノードの Redfish BMC ベアメタルイベントのサブスクライブ

ノードの BMCEventSubscription カスタムリソース (CR) の作成、イベント用の HardwareEvent CR の作成、BMC の Secret CR の作成を行うことで、クラスター内のノードで生成される Redfish BMC イベントにサブスクライブできます。

12.4.1. ベアメタルイベントのサブスクライブ

ベースボード管理コントローラー (BMC) を設定して、ベアメタルイベントを OpenShift Container Platform クラスターで実行されているサブスクライブされたアプリケーションに送信できます。Redfish ベアメタルイベントの例には、デバイス温度の増加やデバイスの削除が含まれます。REST API を使用して、アプリケーションをベアメタルイベントにサブスクライブします。

重要

BMCEventSubscription カスタムリソース (CR) は、Redfish をサポートし、ベンダーインターフェイスが redfish または idrac-redfish に設定されている物理ハードウェアにのみ作成できます。

注記

BMCEventSubscription CR を使用して事前定義された Redfish イベントにサブスクライブします。Redfish 標準は、特定のアラートおよびしきい値を作成するオプションを提供しません。例えば、エンクロージャーの温度が摂氏 40 度を超えたときにアラートイベントを受け取るには、ベンダーの推奨に従ってイベントを手動で設定する必要があります。

BMCEventSubscription CR を使用してノードのベアメタルイベントをサブスクライブするには、以下の手順を行います。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • BMC のユーザー名およびパスワードを取得します。
  • クラスターに Redfish が有効な Baseboard Management Controller (BMC) を持つベアメタルノードをデプロイし、BMC で Redfish イベントを有効にします。

    注記

    特定のハードウェアで Redfish イベントを有効にすることは、この情報の対象範囲外です。特定のハードウェアの Redfish イベントを有効にする方法は、BMC の製造元のドキュメントを参照してください。

手順

  1. 以下の curl コマンドを実行して、ノードのハードウェアで Redfish EventService が有効になっていることを確認します。

    $ curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"

    ここでは、以下のようになります。

    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

    出力例

    {
       "@odata.context": "/redfish/v1/$metadata#EventService.EventService",
       "@odata.id": "/redfish/v1/EventService",
       "@odata.type": "#EventService.v1_0_2.EventService",
       "Actions": {
          "#EventService.SubmitTestEvent": {
             "EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
             "target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
          }
       },
       "DeliveryRetryAttempts": 3,
       "DeliveryRetryIntervalSeconds": 30,
       "Description": "Event Service represents the properties for the service",
       "EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
       "EventTypesForSubscription@odata.count": 5,
       "Id": "EventService",
       "Name": "Event Service",
       "ServiceEnabled": true,
       "Status": {
          "Health": "OK",
          "HealthRollup": "OK",
          "State": "Enabled"
       },
       "Subscriptions": {
          "@odata.id": "/redfish/v1/EventService/Subscriptions"
       }
    }

  2. 以下のコマンドを実行して、クラスターの Bare Metal Event Relay サービスのルートを取得します。

    $ oc get route -n openshift-bare-metal-events

    出力例

    NAME            HOST/PORT   PATH                                                                    SERVICES                 PORT   TERMINATION   WILDCARD
    hw-event-proxy              hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com   hw-event-proxy-service   9087   edge          None

  3. BMCEventSubscription リソースを作成し、Redfish イベントにサブスクライブします。

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

      apiVersion: metal3.io/v1alpha1
      kind: BMCEventSubscription
      metadata:
        name: sub-01
        namespace: openshift-machine-api
      spec:
         hostName: <hostname> 
      1
      
         destination: <proxy_service_url> 
      2
      
         context: ''
      1
      Redfish イベントが生成されるワーカーノードの名前または UUID を指定します。
      2
      ベアメタルイベントプロキシーサービスを指定します (例: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook)。
    2. BMCEventSubscription CR を作成します。

      $ oc create -f bmc_sub.yaml
  4. オプション: BMC イベントサブスクリプションを削除するには、以下のコマンドを実行します。

    $ oc delete -f bmc_sub.yaml
  5. オプション:BMCEventSubscription CR を作成せずに Redfish イベントサブスクリプションを手動で作成するには、BMC のユーザー名およびパスワードを指定して以下の curl コマンドを実行します。

    $ curl -i -k -X POST -H "Content-Type: application/json"  -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v

    ここでは、以下のようになります。

    proxy_service_url
    ベアメタルイベントプロキシーサービスです (例: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook)。
    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

    出力例

    HTTP/1.1 201 Created
    Server: AMI MegaRAC Redfish Service
    Location: /redfish/v1/EventService/Subscriptions/1
    Allow: GET, POST
    Access-Control-Allow-Origin: *
    Access-Control-Expose-Headers: X-Auth-Token
    Access-Control-Allow-Headers: X-Auth-Token
    Access-Control-Allow-Credentials: true
    Cache-Control: no-cache, must-revalidate
    Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
    Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
    Link: </redfish/v1/EventService/Subscriptions>; path=
    ETag: "1651135676"
    Content-Type: application/json; charset=UTF-8
    OData-Version: 4.0
    Content-Length: 614
    Date: Thu, 28 Apr 2022 08:47:57 GMT

12.4.2. curl を使用した Redfish ベアメタルイベントサブスクリプションのクエリー

一部のハードウェアベンダーは Redfish ハードウェアイベントサブスクリプションの量を制限します。curl を使用して Redfish イベントサブスクリプションの数をクエリーできます。

前提条件

  • BMC のユーザー名およびパスワードを取得します。
  • クラスターに Redfish が有効な Baseboard Management Controller (BMC) を持つベアメタルノードをデプロイし、BMC で Redfish ハードウェアイベントを有効にします。

手順

  1. 以下の curl コマンドを実行して、BMC の現在のサブスクリプションを確認します。

    $ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions

    ここでは、以下のようになります。

    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

    出力例

    % Total % Received % Xferd Average Speed Time Time Time Current
    Dload Upload Total Spent Left Speed
    100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
    {
      "@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
      "@odata.etag": ""
      1651137375 "",
      "@odata.id": "/redfish/v1/EventService/Subscriptions",
      "@odata.type": "#EventDestinationCollection.EventDestinationCollection",
      "Description": "Collection for Event Subscriptions",
      "Members": [
      {
        "@odata.id": "/redfish/v1/EventService/Subscriptions/1"
      }],
      "Members@odata.count": 1,
      "Name": "Event Subscriptions Collection"
    }

    この例では、サブスクリプションが 1 つ設定されています (/redfish/v1/EventService/Subscriptions/1)。

  2. オプション: curl/redfish/v1/EventService/Subscriptions/1 サブスクリプションを削除するには、BMC のユーザー名およびパスワードを指定して以下のコマンドを実行します。

    $ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1

    ここでは、以下のようになります。

    bmc_ip_address
    Redfish イベントが生成される BMC の IP アドレスです。

12.4.3. ベアメタルイベントおよびシークレット CR の作成

ベアメタルイベントの使用を開始するには、Redfish ハードウェアが存在するホストの HardwareEvent カスタムリソース (CR) を作成します。ハードウェアイベントと障害は hw-event-proxy ログに報告されます。

前提条件

  • OpenShift Container Platform CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • Bare Metal Event Relay をインストールしている。
  • BMC Redfish ハードウェア用の BMCEventSubscription CR を作成している。

手順

  1. HardwareEvent カスタムリソース (CR) を作成します。

    注記

    複数の HardwareEvent リソースは許可されません。

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

      apiVersion: "event.redhat-cne.org/v1alpha1"
      kind: "HardwareEvent"
      metadata:
        name: "hardware-event"
      spec:
        nodeSelector:
          node-role.kubernetes.io/hw-event: "" 
      1
      
        logLevel: "debug" 
      2
      
        msgParserTimeout: "10" 
      3
      1
      必須。nodeSelector フィールドを使用して、指定されたラベルを持つノードをターゲットにします (例: node-role.kubernetes.io/hw-event: ""
      注記

      OpenShift Container Platform 4.13 以降でベアメタルイベントに HTTP トランスポートを使用する場合、HardwareEvent リソースの spec.transportHost フィールドを設定する必要はありません。ベアメタルイベントに AMQP トランスポートを使用する場合にのみ transportHost を設定します。

      2
      オプション: デフォルト値は debug です。hw-event-proxy ログでログレベルを設定します。fatalerrorwarninginfodebugtrace のログレベルを利用できます。
      3
      オプション: Message Parser のタイムアウト値をミリ秒単位で設定します。メッセージ解析要求がタイムアウト期間内に応答しない場合には、元のハードウェアイベントメッセージはクラウドネイティブイベントフレームワークに渡されます。デフォルト値は 10 です。
    2. クラスターで HardwareEvent CR を適用します。

      $ oc create -f hardware-event.yaml
  2. BMC ユーザー名およびパスワード Secret CR を作成します。これにより、ハードウェアイベントプロキシーがベアメタルホストの Redfish メッセージレジストリーにアクセスできるようになります。

    1. 以下の YAML を hw-event-bmc-secret.yaml ファイルに保存します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: redfish-basic-auth
      type: Opaque
      stringData: 
      1
      
        username: <bmc_username>
        password: <bmc_password>
        # BMC host DNS or IP address
        hostaddr: <bmc_host_ip_address>
      1
      stringData の下に、さまざまな項目のプレーンテキスト値を入力します。
    2. Secret CR を作成します。

      $ oc create -f hw-event-bmc-secret.yaml

12.5. ベアメタルイベント REST API リファレンスへのアプリケーションのサブスクライブ

ベアメタルイベント REST API を使用して、親ノードで生成されるベアメタルイベントにアプリケーションをサブスクライブします。

リソースアドレス /cluster/node/<node_name>/redfish/event を使用して、アプリケーションを Redfish イベントにサブスクライブします。<node_name> は、アプリケーションを実行するクラスターノードに置き換えます。

cloud-event-consumer アプリケーションコンテナーおよび cloud-event-proxy サイドカーコンテナーを別のアプリケーション Pod にデプロイします。cloud-event-consumer アプリケーションは、アプリケーション Pod の cloud-event-proxy コンテナーにサブスクライブします。

次の API エンドポイントを使用して、アプリケーション Pod の http://localhost:8089/api/ocloudNotifications/v1/ にある cloud-event-proxy コンテナーによって投稿された Redfish イベントに cloud-event-consumer アプリケーションをサブスクライブします。

  • /api/ocloudNotifications/v1/subscriptions

    • POST: 新しいサブスクリプションを作成します。
    • GET: サブスクリプションの一覧を取得します。
  • /api/ocloudNotifications/v1/subscriptions/<subscription_id>

    • PUT: 指定されたサブスクリプション ID に新しいステータス ping 要求を作成します。
  • /api/ocloudNotifications/v1/health

    • GET: ocloudNotifications API の正常性ステータスを返します
注記

9089 は、アプリケーション Pod にデプロイされた cloud-event-consumer コンテナーのデフォルトポートです。必要に応じて、アプリケーションに異なるポートを設定できます。

api/ocloudNotifications/v1/subscriptions
HTTP メソッド

GET api/ocloudNotifications/v1/subscriptions

説明

サブスクリプションのリストを返します。サブスクリプションが存在する場合は、サブスクリプションの一覧とともに 200 OK のステータスコードが返されます。

API 応答の例

[
 {
  "id": "ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "endpointUri": "http://localhost:9089/api/ocloudNotifications/v1/dummy",
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
 }
]

HTTP メソッド

POST api/ocloudNotifications/v1/subscriptions

説明

新しいサブスクリプションを作成します。サブスクリプションが正常に作成されるか、すでに存在する場合は、201 Created ステータスコードが返されます。

Expand
表12.1 クエリーパラメーター
パラメーター

subscription

data

ペイロードの例

{
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
  "resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
}

api/ocloudNotifications/v1/subscriptions/<subscription_id>
HTTP メソッド

GET api/ocloudNotifications/v1/subscriptions/<subscription_id>

説明

ID が <subscription_id>のサブスクリプションの詳細を返します。

Expand
表12.2 クエリーパラメーター
パラメーター

<subscription_id>

string

API 応答の例

{
  "id":"ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "endpointUri":"http://localhost:9089/api/ocloudNotifications/v1/dummy",
  "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "resource":"/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
}

api/ocloudNotifications/v1/health/
HTTP メソッド

GET api/ocloudNotifications/v1/health/

説明

ocloudNotifications REST API の正常性ステータスを返します。

API 応答の例

OK

以前に PTP またはベアメタルイベントのコンシューマーアプリケーションをデプロイしている場合は、HTTP メッセージトランスポートを使用するようにアプリケーションを更新する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • PTP Operator または Bare Metal Event Relay を、デフォルトで HTTP トランスポートを使用するバージョン 4.13 以降に更新している。

手順

  1. HTTP トランスポートを使用するようにイベントコンシューマーアプリケーションを更新します。クラウドイベントサイドカーデプロイメントの http-event-publishers 変数を設定します。

    たとえば、PTP イベントが設定されているクラスターでは、以下の YAML スニペットはクラウドイベントサイドカーデプロイメントを示しています。

    containers:
      - name: cloud-event-sidecar
        image: cloud-event-sidecar
        args:
          - "--metrics-addr=127.0.0.1:9091"
          - "--store-path=/store"
          - "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
          - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043" 
    1
    
          - "--api-port=8089"
    1
    PTP Operator は、PTP イベントを生成するホストに対して NODE_NAME を自動的に解決します。compute-1.example.com はその例です。

    ベアメタルイベントが設定されているクラスターでは、クラウドイベントサイドカーデプロイメント CR で http-event-publishers フィールドを hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043 に設定します。

  2. consumer-events-subscription-service サービスをイベントコンシューマーアプリケーションと併せてデプロイします。以下に例を示します。

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret
      name: consumer-events-subscription-service
      namespace: cloud-events
      labels:
        app: consumer-service
    spec:
      ports:
        - name: sub-port
          port: 9043
      selector:
        app: consumer
      clusterIP: None
      sessionAffinity: None
      type: ClusterIP

第13章 huge page を使用してワークロードのメモリー管理を最適化する

特定のワークロードのメモリー管理を最適化するには、huge page を設定します。これらの Linux ベースのシステムページサイズを使用することで、メモリー割り当てを手動で制御し、システムの自動動作を上書きすることができます。

13.1. Huge Page の機能

メモリーマッピングの効率を最適化するには、huge page の機能を理解する必要があります。標準的な 4Ki ブロックとは異なり、huge page はより大きなメモリーセグメントであり、Translation Lookaside Buffer (TLB) ハードウェアキャッシュへのトラッキング負荷を軽減します。

メモリーは Page と呼ばれるブロックで管理されます。ほとんどのシステムでは、1 ページは 4Ki です。1Mi のメモリーは 256 ページに相当し、1Gi のメモリーは 25 万 6000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。Translation Lookaside Buffer (TLB) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが 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 を割り当て、消費することができます。

13.2. Huge Page がアプリケーションによって消費される仕組み

アプリケーションが huge page を使用できるようにするには、ノードは容量を報告するためにこれらのメモリーセグメントを事前に割り当てておく必要があります。ノードは単一サイズの huge page しか事前割り当てできないため、この設定を特定のワークロード要件に合わせる必要があります。

巨大ページは、コンテナーレベルのリソース要件で、リソース名 hugepages-<size> を使用することで消費できます。ここで、size は、特定のノードでサポートされている整数値を使用した最もコンパクトなバイナリー表記です。たとえば、ノードが 2048 KiB のページサイズをサポートしている場合、ノードはスケジュール可能なリソース hugepages-2Mi を公開します。CPU やメモリーとは異なり、Huge Page はオーバーコミットをサポートしません。

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
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
  • spec.containers.resources.limits.huge page-2Mi: ヒュージページ に割り当てるメモリー量を指定します。

    重要

    この値は、ページサイズで乗算した hugepages のメモリー量に指定しないでください。たとえば、huge page サイズが 2 MB の場合、アプリケーションに 100 MB の巨大ページベースの RAM を使用したい場合は、50 個の huge page を割り当てます。OpenShift Container Platform により、計算処理が実行されます。上記の例にあるように、100MB を直接指定できます。

13.2.1. 指定されたサイズの Huge Page の割り当て

プラットフォームによっては、複数の Huge Page サイズをサポートするものもあります。特定のサイズの Huge Page を割り当てるには、Huge Page の起動コマンドパラメーターの前に、Huge Page サイズの選択パラメーター hugepagesz=<size> を指定してください。<size> の値は、バイトで指定する必要があります。その際、オプションでスケール接尾辞 [kKmMgG] を指定できます。デフォルトの Huge Page サイズは、default_hugepagesz=<size> の起動パラメーターで定義できます。

13.2.2. Huge page の要件

  • Huge Page 要求は制限と同じでなければなりません。制限が指定されているにもかかわらず、要求が指定されていない場合には、これがデフォルトになります。
  • Huge Page は、Pod のスコープで分割されます。コンテナーの分割は、今後のバージョンで予定されています。
  • Huge Page がサポートする EmptyDir ボリュームは、Pod 要求よりも多くの Huge Page メモリーを消費することはできません。
  • shmget()SHM_HUGETLB を使用して Huge Page を消費するアプリケーションは、proc/sys/vm/hugetlb_shm_group に一致する補助グループで実行する必要があります。

13.3. Downward API を使用した Huge Page リソースの使用

コンテナーが消費する huge page リソースに関する情報を注入するには、Downward API を使用します。この設定により、アプリケーションは自身のメモリー使用量データを直接取得して使用できるようになります。

リソースの割り当ては、環境変数、ボリュームプラグイン、またはその両方として挿入できます。コンテナーで開発および実行するアプリケーションは、指定されたボリューム内の環境変数またはファイルを読み取ることで、利用可能なリソースを判別できます。

手順

  1. 以下の例のような hugepages-volume-pod.yaml ファイルを作成します。

    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
          valueFrom:
            resourceFieldRef:
              containerName: example
              resource: requests.hugepages-1Gi
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
      - name: podinfo
        downwardAPI:
          items:
            - path: "hugepages_1G_request"
              resourceFieldRef:
                containerName: example
                resource: requests.hugepages-1Gi
                divisor: 1Gi

    ここでは、以下のようになります。

    spec.containers.securityContext.env.name
    requests.hugepages-1Gi から読み込んで使用するリソースを指定し、その値を REQUESTS_HUGEPAGES_1GI 環境変数として公開します。
    spec.volumes.name.items.path
    requests.hugepages-1Gi から読み込んで使用するリソースを指定し、その値をファイル /etc/podinfo/hugepages_1G_request として公開します。
  2. 次のコマンドを入力して、huge page-volume-pod.yaml ファイルから Pod を作成します。

    $ oc create -f hugepages-volume-pod.yaml

検証

  1. REQUESTS_HUGEPAGES_1GI 環境変数の値を確認します。

    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
         -- env | grep REQUESTS_HUGEPAGES_1GI

    出力例

    REQUESTS_HUGEPAGES_1GI=2147483648

  2. /etc/podinfo/hugepages_1G_request ファイルの値を確認します。

    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
         -- cat /etc/podinfo/hugepages_1G_request

    出力例

    2

13.4. 起動時の Huge Page 設定

OpenShift Container Platform クラスター内のノードが特定のワークロード用にメモリーを事前割り当てできるようにするには、起動時に huge page を予約してください。この設定では、システム起動時にメモリーリソースを確保することで、実行時割り当てとは異なる独自の選択肢を提供します。

Huge Page を予約する方法は、ブート時とランタイム時に実行する 2 つの方法があります。ブート時の予約は、メモリーが大幅に断片化されていないために成功する可能性が高くなります。Node Tuning Operator は現在、特定のノード上での huge page の起動時割り当てをサポートしています。

注記

TuneD ブートローダープラグインは、Red Hat Enterprise Linux CoreOS(RHCOS) コンピュートノードのみをサポートしています。

手順

  1. 以下のコマンドを入力して、同じ huge page 設定が必要なすべてのノードにラベルを付けます。

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
  2. 以下の内容でファイルを作成し、これに hugepages-tuned-boottime.yaml という名前を付けます。

    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:
      - machineConfigLabels:
          machineconfiguration.openshift.io/role: "worker-hp"
        priority: 30
        profile: openshift-node-hugepages
    # ...

    ここでは、以下のようになります。

    metadata.name
    huge page にチューニングされたリソースの 名前 を指定します。
    spec.profile
    huge page を割り当てる プロファイル セクションを指定します。
    spec.profile.data
    パラメーターの順序を指定します。プラットフォームによってはさまざまなサイズの huge page をサポートしているため、順番は重要です。
    spec.recommend.machineConfigLabels
    マシン設定プールに基づくマッチングを有効にするかどうかを指定します。
  3. 以下のコマンドを入力して、Tuned huge page オブジェクトを作成します。

    $ oc create -f hugepages-tuned-boottime.yaml
  4. 以下の内容でファイルを作成し、これに hugepages-mcp.yaml という名前を付けます。

    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. マシン設定プールを作成するには、次のコマンドを入力します。

    $ oc create -f hugepages-mcp.yaml

検証

  • 十分な断片化されていないメモリーが存在し、worker-hp マシン設定プール内のすべてのノードに 50 個の 2Mihuge page が割り当てられていることを確認するには、次のコマンドを入力します。

    $ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
    100Mi

13.5. transparent huge page を無効にする

アプリケーションが huge page を単独で処理できる場合は、transparent huge page (THP) を無効にすることで、あらゆる種類のワークロードに対して huge page を最適に処理し、THP が引き起こす可能性のあるパフォーマンス低下リグレッションを回避できます。

THP を無効にすると、huge page の作成、管理、使用のほとんどの側面を自動化しようとするのを防ぐことができます。Node Tuning Operator (NTO) を使用することで THP を無効にできます。

手順

  1. 以下の内容でファイルを作成し、thp-disable-tuned.yaml という名前を付けます。

    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 オブジェクトを作成します。

    $ oc create -f thp-disable-tuned.yaml
  3. アクティブなプロファイルのリストを確認するには、次のコマンドを入力してください。

    $ oc get profile -n openshift-cluster-node-tuning-operator

検証

  • ノードのいずれかにログインし、通常の THP チェックを実行して、ノードがプロファイルを正常に適用したかどうかを確認します。

    $ cat /sys/kernel/mm/transparent_hugepage/enabled

    出力例

    always madvise [never]

第14章 クラスターノードの低レイテンシーチューニングについて

5G ネットワークの性能要件を満たすためには、クラスターノードの低遅延チューニングの原則を確認してください。この設定を使用することで、エッジコンピューティングアプリケーションの混雑を軽減し、可能な限り低いレイテンシーを維持できます。

可能な限りレイテンシーを抑えたネットワークアーキテクチャーを維持することが、5G のネットワークパフォーマンス要件を満たすための鍵となります。平均レイテンシーが 50 ms の 4G テクノロジーと比較して、5G ではレイテンシーを 1 ms 以下に抑えることを目指しています。このレイテンシーの削減により、ワイヤレススループットが 10 倍向上します。

14.1. 低レイテンシーについて

パケットロスゼロが求められる通信事業者向けアプリケーションをサポートするには、低遅延となるように環境を調整してください。この設定によりネットワーク性能の低下が軽減され、システムが厳格な信頼性要件を満たすことが保証されます。

パケットロスをゼロに調整すると、ネットワークのパフォーマンス低下させる固有の問題を軽減することができます。詳細は、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 パーティショニングを可能にする最小限のデフォルトチューニングのみが必要です。レイテンシーが優先されるデータセンターやワークロードの場合でも、消費電力を最適化するための対策が講じられています。最も複雑なケースは、製造機械やソフトウェア無線などのレイテンシーの影響を受けやすい機器に近いクラスターです。この最後のクラスのデプロイメントは、多くの場合、ファーエッジと呼ばれます。ファーエッジデプロイメントの場合、超低レイテンシーが最優先事項であり、電力管理を犠牲にして実現されます。

並列ワークロードのシステムスループットを向上させるには、ハイパースレッディングを使用して、1 つの物理 CPU コアを 2 つの論理コアとして機能させ、独立したスレッドを同時に実行させることができます。デフォルトの OpenShift Container Platform 設定では、ハイパースレッディングが有効になっていることが想定されています。

通信アプリケーションの場合、アプリケーションインフラストラクチャーを設計する際には、レイテンシーを可能な限り最小限に抑えるようにしてください。ハイパースレッディングは、パフォーマンス時間を低下させ、低レイテンシーを必要とする計算集約型ワークロードのスループットに悪影響を及ぼす可能性があります。ハイパースレッディングを無効にすると、予測可能なパフォーマンスが確保され、これらのワークロードの処理時間が短縮されます。

注記

ハイパースレッディングの実装と設定は、OpenShift Container Platform を実行しているハードウェアによって異なります。当該ハードウェアに固有のハイパースレッディング実装の詳細は、関連するホストハードウェアチューニング情報を参照してください。ハイパースレッディングを無効にすると、クラスターのコアあたりのコストが増加する可能性があります。

ノードをチューニングして低レイテンシーを実現するには、クラスターパフォーマンスプロファイルを使用します。インフラストラクチャーおよびアプリケーションコンテナーの CPU を制限したり、huge page やハイパースレッディングを設定したり、レイテンシーの影響を受けやすいプロセスの CPU パーティションを設定したりすることができます。

15.1. パフォーマンスプロファイルの作成

Performance Profile Creator (PPC) ツールを使用して、クラスターパフォーマンスプロファイルを作成できます。PPC は Node Tuning Operator の機能です。

PPC は、クラスターに関する情報とユーザー指定の設定を組み合わせて、ハードウェア、トポロジー、ユースケースに適したパフォーマンスプロファイルを生成します。

注記

パフォーマンスプロファイルは、クラスターが基盤となるハードウェアリソースに直接アクセスできるベアメタル環境にのみ適用されます。シングルノード OpenShift とマルチノードクラスターの両方に対してパフォーマンスプロファイルを設定できます。

以下は、クラスターでパフォーマンスプロファイルを作成して適用するための大まかなワークフローです。

  • パフォーマンス設定の対象となるノードのマシン設定プール (MCP) を作成します。シングルノード OpenShift クラスターでは、クラスター内にノードが 1 つしかないため、master MCP を使用する必要があります。
  • must-gather コマンドを使用してクラスターに関する情報を収集します。
  • 次のいずれかの方法で PPC ツールを使用してパフォーマンスプロファイルを作成します。

    • Podman を使用して PPC ツールを実行します。詳細は、Podman を使用して Performance Profile Creator を実行する を参照してください。
    • Performance Profile Creator ラッパースクリプトの実行の 説明に従って、ラッパースクリプトを使用して PPC ツールを実行します。
  • ユースケースに合わせてパフォーマンスプロファイルを設定し、そのパフォーマンスプロファイルをクラスターに適用します。

15.1.1. Performance Profile Creator の概要

Performance Profile Creator (PPC) はコマンドラインツールであり、Node Tuning Operator に同梱されています。PPC CLI を使用して、クラスターのパフォーマンスプロファイルを作成できます。

最初に、PPC ツールを使用して must-gather データを処理し、次の情報を含むクラスターの主要なパフォーマンス設定を表示できます。

  • 割り当てられた CPU ID でパーティショニングされた NUMA セル
  • ハイパースレッディングノード設定

この情報を使用して、パフォーマンスプロファイルを設定することができます。

PPC ツールにパフォーマンス設定引数を指定して、ハードウェア、トポロジー、およびユースケースに適した提案されたパフォーマンスプロファイルを生成します。

次のいずれかの方法で PPC を実行できます。

  • Podman を使用して PPC を実行する
  • ラッパースクリプトを使用して PPC を実行する
注記

ラッパースクリプトを使用すると、より細かい Podman タスクの一部が実行可能なスクリプトに抽象化されます。たとえば、ラッパースクリプトは、必要なコンテナーイメージをプルして実行したり、コンテナーにディレクトリーをマウントしたり、Podman を介してコンテナーに直接パラメーターを提供したりといったタスクを処理します。どちらの方法でも同じ結果が得られます。

15.1.2. パフォーマンスチューニングの対象となるノードにマシン設定プールを作成する

マルチノードクラスターの場合、マシン設定プール (MCP) を定義して、パフォーマンスプロファイルで設定するターゲットノードを識別できます。

シングルノード OpenShift クラスターでは、クラスター内にノードが 1 つしかないため、master MCP を使用する必要があります。シングルノード OpenShift クラスター用に個別の MCP を作成する必要はありません。

前提条件

  • cluster-admin ロールへのアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、設定用のターゲットノードにラベルを付けます。

    $ oc label node <node_name> node-role.kubernetes.io/worker-cnf=""
    • <node_name>: ノードの名前を指定します。この例では、worker-cnf ラベルを適用します。
  2. ターゲットノードを含む MachineConfigPool リソースを作成します。

    1. MachineConfigPool リソースを定義する YAML ファイルを作成します。

      mcp-worker-cnf.yaml ファイルの例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: worker-cnf
        labels:
          machineconfiguration.openshift.io/role: worker-cnf
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
                 key: machineconfiguration.openshift.io/role,
                 operator: In,
                 values: [worker, worker-cnf],
              }
        paused: false
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker-cnf: ""

      ここでは、以下のようになります。

      metadata.name
      MachineConfigPool リソースの名前を指定します。
      machineconfiguration.openshift.io/role
      マシン設定プールに一意のラベルを指定します。
      node-role.kubernetes.io/worker-cnf
      定義したターゲットラベルを持つノードを指定します。
    2. 次のコマンドを実行して、MachineConfigPool リソースを適用します。

      $ oc apply -f mcp-worker-cnf.yaml

      出力例

      machineconfigpool.machineconfiguration.openshift.io/worker-cnf created

検証

  • 次のコマンドを実行して、クラスター内のマシン設定プールを確認します。

    $ oc get mcp

    出力例

    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

15.1.3. PPC 用のクラスターに関するデータを収集する

Performance Profile Creator (PPC) ツールには must-gather データが必要です。クラスター管理者は、must-gather コマンドを実行し、クラスターに関する情報を取得します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • パフォーマンスプロファイルを使用して設定するターゲット MCP を特定している。

手順

  1. must-gather データを保存するディレクトリーに移動します。
  2. 次のコマンドを実行してクラスター情報を収集します。

    $ oc adm must-gather

    このコマンドは、must-gather.local.1971646453781853027 のような命名形式で、ローカルディレクトリーに must-gather データを含むフォルダーを作成します。

  3. オプション: must-gather ディレクトリーから圧縮ファイルを作成します。

    $ tar cvaf must-gather.tar.gz <must_gather_folder>
    • <must_gather_folder>: must-gather データフォルダーの名前を指定します。

      注記

      Performance Profile Creator ラッパースクリプトを実行している場合は、出力を圧縮する必要があります。

15.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. 次のコマンドを実行して、マシン設定プールを確認します。

    $ oc get mcp

    出力例

    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 に認証します。

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  3. オプション: 次のコマンドを実行して、PPC ツールのヘルプを表示します。

    $ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16 -h

    出力例

    A tool that automates creation of Performance Profiles
    
    Usage:
      performance-profile-creator [flags]
    
    Flags:
          --disable-ht                        Disable Hyperthreading
          --enable-hardware-tuning            Enable setting maximum cpu frequencies
      -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 ツールを実行します。

    $ 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.16 --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 は、出力形式の値を指定します。

      出力例

      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 引数と値を使用します。

    $ 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.16 --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 は、1 つの CPU をオフライン化することを指定します。

      注記

      この例の mcp-name 引数は、コマンド oc get mcp の出力に基づいて worker-cnf に設定されます。シングルノード OpenShift の場合は、--mcp-name=master を使用します。

      出力例

      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 ファイルを確認します。

    $ cat my-performance-profile.yaml

    出力例

    ---
    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. 生成されたプロファイルを適用します。

    $ oc apply -f my-performance-profile.yaml

    出力例

    performanceprofile.performance.openshift.io/performance created

15.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) を作成します。

    $ vi run-perf-profile-creator.sh
  2. ファイルに以下のコードを貼り付けます。

    #!/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.16"
    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. このスクリプトの実行権限を全員に追加します。

    $ chmod a+x run-perf-profile-creator.sh
  4. 次のコマンドを実行して、Podman を使用して registry.redhat.io に認証します。

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  5. オプション: 次のコマンドを実行して、PPC ツールのヘルプを表示します。

    $ ./run-perf-profile-creator.sh -h
    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.20) を使用します。

  6. クラスターに関する情報を表示するには、次のコマンドを実行して、log 引数を指定した PPC ツールを実行します。

    $ ./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 を含むディレクトリーへのパスを指定します。これはラッパースクリプトに必要な引数です。

      出力例

      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. 次のコマンドを実行して、パフォーマンスプロファイルを作成します。この例のコマンドでは、サンプルとなる PPC 引数と値を使用しています。

    $ ./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
    • --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 は、1 つの CPU をオフライン化することを指定します。

      注記

      この例の mcp-name 引数は、コマンド oc get mcp の出力に基づいて worker-cnf に設定されます。シングルノード OpenShift の場合は、--mcp-name=master を使用します。

  8. 次のコマンドを実行して、作成された YAML ファイルを確認します。

    $ cat my-performance-profile.yaml

    出力例

    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. 生成されたプロファイルを適用します。

    $ oc apply -f my-performance-profile.yaml

    出力例

    performanceprofile.performance.openshift.io/performance created

15.1.6. Performance Profile Creator の引数

パフォーマンスプロファイルの生成をカスタマイズするには、Performance Profile Creator の引数を確認してください。これらのコマンドラインオプションを使用することで、CPU 分離や huge page などの特定のチューニングパラメーターを定義し、ワークロードの要件を満たすことができます。

Expand
表15.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 です。

Expand
表15.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 の数。

注記

ゼロより大きい自然数を使用してください。十分な数の論理プロセッサーがオフラインになっていない場合、エラーメッセージがログに記録されます。メッセージは次のとおりです。

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]
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

15.2. リファレンスパフォーマンスプロファイル

次のリファレンスパフォーマンスプロファイルをベースに、独自のカスタムプロファイルを作成してください。

Red Hat OpenStack Platform (RHOSP) で Open vSwitch と Data Plane Development Kit (OVS-DPDK) を使用するクラスターでマシンのパフォーマンスを最大化するには、パフォーマンスプロファイルを使用できます。

次のパフォーマンスプロファイルテンプレートを使用して、デプロイメント用のプロファイルを作成できます。

OVS-DPDK を使用するクラスター用のパフォーマンスプロファイルテンプレート

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 キーの設定に適した値を入力します。

15.2.2. 通信事業者 RAN DU リファレンス設計のパフォーマンスプロファイル

通信事業者の RAN DU ワークロードをホストするために、汎用ハードウェア上の OpenShift Container Platform クラスターのノードレベルのパフォーマンス設定を設定する、事前設定済みの設計パフォーマンスプロファイルを使用できます。

通信事業者 RAN DU リファレンス設計のパフォーマンスプロファイル

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

15.2.3. 通信事業者コアリファレンス設計パフォーマンスプロファイル

通信事業者のコアワークロードをホストするために、汎用ハードウェア上の OpenShift Container Platform クラスターのノードレベルのパフォーマンス設定を設定する、事前設定済みの設計パフォーマンスプロファイルを使用できます。

通信事業者コアリファレンス設計パフォーマンスプロファイル

# required
# count: 1
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: $name
  annotations:
    # Some pods want the kernel stack to ignore IPv6 router Advertisement.
    kubeletconfig.experimental: |
      {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
spec:
  cpu:
    # node0 CPUs: 0-17,36-53
    # node1 CPUs: 18-34,54-71
    # siblings: (0,36), (1,37)...
    # we want to reserve the first Core of each NUMA socket
    #
    # no CPU left behind! all-cpus == isolated + reserved
    isolated: $isolated # eg 1-17,19-35,37-53,55-71
    reserved: $reserved # eg 0,18,36,54
  # Guaranteed QoS pods will disable IRQ balancing for cores allocated to the pod.
  # default value of globallyDisableIrqLoadBalancing is false
  globallyDisableIrqLoadBalancing: false
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      # 32GB per numa node
      - count: $count # eg 64
        size: 1G
  machineConfigPoolSelector:
    # For SNO: machineconfiguration.openshift.io/role: 'master'
    pools.operator.machineconfiguration.openshift.io/worker: ''
  nodeSelector:
    # For SNO: node-role.kubernetes.io/master: ""
    node-role.kubernetes.io/worker: ""
  workloadHints:
    realTime: false
    highPowerConsumption: false
    perPodPowerManagement: true
  realTimeKernel:
    enabled: false
  numa:
    # All guaranteed QoS containers get resources from a single NUMA node
    topologyPolicy: "single-numa-node"
  net:
    userLevelNetworking: false

15.3. サポートされているパフォーマンスプロファイルの API バージョン

Node Tuning Operator は、パフォーマンスプロファイル apiVersion フィールドの v2v1、および v1alpha1 をサポートします。v1 および v1alpha1 API は同一です。v2 API には、デフォルト値の false が設定されたオプションのブール値フィールド globallyDisableIrqLoadBalancing が含まれます。

デバイス割り込み処理を使用するためのパフォーマンスプロファイルのアップグレード

Node Tuning Operator パフォーマンスプロファイルのカスタムリソース定義 (CRD) を v1 または v1alpha1 から v2 にアップグレードする場合、globallyDisableIrqLoadBalancingtrue に設定されます。

注記

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 を使用して変換されます。

15.4. ノードの消費電力とワークロードヒント付きリアルタイム処理

Performance Profile Creator (PPC) ツールを使用すると、環境のハードウェアとトポロジーに適したパフォーマンスプロファイルを作成できます。

次の表は、PPC ツールに関連付けられた power-consumption-mode フラグに設定可能な値と、適用されるワークロードヒントを示しています。

Expand
表15.3 電力消費とリアルタイム設定の組み合わせがレイテンシーに与える影響
Performance Profile Creator の設定ヒント環境説明

デフォルト

workloadHints:
highPowerConsumption: false
realTime: false

レイテンシー要件のない高スループットクラスター

CPU パーティショニングのみで達成されるパフォーマンス。

Low-latency

workloadHints:
highPowerConsumption: false
realTime: true

地域のデータセンター

エネルギー節約と低レイテンシーの両方が望ましい: 電力管理、レイテンシー、スループットの間の妥協。

Ultra-low-latency

workloadHints:
highPowerConsumption: true
realTime: true

ファーエッジクラスター、レイテンシークリティカルなワークロード

消費電力の増加を代償にして、レイテンシーを極限まで最小限に抑え、最大限の決定性を確保するように最適化されています。

Pod ごとの電源管理

workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: true

重要なワークロードと重要でないワークロード

Pod ごとの電源管理が可能です。

通信事業者の RAN DU デプロイメントでは、一般的に以下の設定が使用されます。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: workload-hints
    spec:
      ...
      workloadHints:
        realTime: true
        highPowerConsumption: false
        perPodPowerManagement: false
perPodPowerManagement
システム遅延に影響を与える可能性のある一部のデバッグ機能および監視機能を無効にすることを指定します。
注記

パフォーマンスプロファイルで realTime ワークロードヒントフラグが true に設定されている場合、ピニングされた CPU を持つすべての Guaranteed Pod に、cpu-quota.crio.io: disable アノテーションを追加してください。このアノテーションは、Pod 内のプロセスのパフォーマンスの低下を防ぐために必要です。realTime ワークロードヒントが明示的に設定されていない場合は、デフォルトで true になります。

消費電力とリアルタイム設定の組み合わせがレイテンシーにどのように影響するかについての詳細は、ワークロードヒントの理解を参照してください。

優先度の高いワークロードのレイテンシーやスループットに影響を与えることなく、優先度の高いワークロードと同じ場所にある優先度の低いワークロードを持つノードの省電力を有効にすることができます。ワークロード自体を変更することなく、省電力が可能です。

重要

この機能は、Intel Ice Lake 以降の世代の Intel CPU でサポートされています。プロセッサーの機能は、優先度の高いワークロードのレイテンシーとスループットに影響を与える可能性があります。

前提条件

  • BIOS の C ステートとオペレーティングシステム制御の P ステートを有効にした。

手順

  1. per-pod-power-management 引数を true に設定して PerformanceProfile を生成します。

    $ podman run --entrypoint performance-profile-creator -v \
    /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.16 \
    --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 \
    --per-pod-power-management=true > my-performance-profile.yaml

    per-pod-power-management 引数が true に設定されている場合、power-consumption-mode 引数は default または low-latency にする必要があります。

    perPodPowerManagement を使用した PerformanceProfile の例

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
         name: performance
    spec:
        [.....]
        workloadHints:
            realTime: true
            highPowerConsumption: false
            perPodPowerManagement: true
    # ...

  2. デフォルトの cpufreq ガバナーを、PerformanceProfile カスタムリソース (CR) で追加のカーネル引数として設定します。

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

    ここでは、以下のようになります。

    cpufreq.default_governor=schedutil
    schedutil ガバナーを使用する方法を指定します。オンデマンドガバナーパワーセーブ ガバナーなど、他のガバナーを使用することもできます。
  3. TunedPerformancePatch CR で最大 CPU 周波数を設定します。

    spec:
      profile:
      - data: |
          [sysfs]
          /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x>

    ここでは、以下のようになります。

    /sys/devices/system/cpu/intel_pstate/max_perf_pct
    cpufreq ドライバーが設定できる最大周波数を、サポートされている最大 CPU 周波数に対する割合として制御する max_perf_pct を指定します。この値はすべての CPU に適用されます。サポートされている最大周波数は /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq で確認できます。開始点として、All Cores Turbo 周波数ですべての CPU を制限する割合を使用できます。All Cores Turbo 周波数は、すべてのコアがすべて使用されているときに全コアが実行される周波数です。

15.6. インフラコンテナーおよびアプリケーションコンテナー用 CPU

一般的なハウスキーピングやワークロードタスクは、レイテンシーに敏感なプロセスに影響を与える可能性のある方法で CPU を使用します。デフォルトでは、コンテナーランタイムはすべてのオンライン CPU を使用して、すべてのコンテナーを一緒に実行します。これが原因で、コンテキストスイッチおよびレイテンシーが急増する可能性があります。

CPU をパーティショニングすることで、ノイズの多いプロセスとレイテンシーの影響を受けやすいプロセスを分離し、干渉を防ぐことができます。以下の表は、Node Tuning Operator を使用してノードを調整した後、CPU でプロセスがどのように実行されるかを示しています。

Expand
表15.4 プロセスの CPU 割り当て
プロセスタイプDetails

Burstable および BestEffort Pod

低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。

インフラストラクチャー Pod

低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。

割り込み

予約済み CPU にリダイレクトします (OpenShift Container Platform 4.7 以降ではオプション)

カーネルプロセス

予約済み CPU へのピン

レイテンシーの影響を受けやすいワークロード Pod

分離されたプールからの排他的 CPU の特定のセットへのピン

OS プロセス/systemd サービス

予約済み CPU へのピン

すべての QoS プロセスタイプ (BurstableBestEffort、または 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.16 以降のバージョンでは、ワークロードはオプションで機密としてラベル付けできます。

予約済みパーティションと分離パーティションにどの特定の CPU を使用するかを決定するには、詳細な分析と測定が必要です。デバイスやメモリーの NUMA アフィニティーなどの要因が作用しています。選択は、ワークロードアーキテクチャーと特定のユースケースにも依存します。

重要

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

ハウスキーピングタスクとワークロードが相互に干渉しないようにするには、パフォーマンスプロファイルの spec セクションで CPU の 2 つのグループを指定します。

  • isolated - アプリケーションコンテナーワークロードの CPU を指定します。これらの CPU のレイテンシーが一番低くなります。このグループのプロセスには割り込みがないため、DPDK ゼロパケットロスの帯域幅がより高くなります。
  • reserved - クラスターおよびオペレーティングシステムのハウスキーピング業務用の CPU を指定します。reserved グループのスレッドは、ビジーであることが多いです。reserved グループでレイテンシーの影響を受けやすいアプリケーションを実行しないでください。レイテンシーの影響を受けやすいアプリケーションは、isolated グループで実行されます。

15.7. インフラストラクチャーおよびアプリケーションコンテナーの CPU の制限

クラスターの安定性とパフォーマンスを最適化するために、インフラストラクチャーコンテナーとアプリケーションコンテナーに割り当てる CPU を制限してください。この設定により、ワークロードが特定の CPU セットに分離され、重要なシステムコンポーネントとユーザーアプリケーション間のリソース競合が防止されます。

手順

  1. 環境のハードウェアとトポロジーに適したパフォーマンスプロファイルを作成します。次の例では、インフラストラクチャーコンテナーとアプリケーションコンテナー用に予約および分離する CPU を指定して、予約済み および 分離済みの パラメーターを追加します。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: infra-cpus
    spec:
      cpu:
        reserved: "0-4,9"
        isolated: "5-8"
      nodeSelector:
        node-role.kubernetes.io/worker: ""
    # ...

    ここでは、以下のようになります。

    spec.cpu.reserved
    インフラストラクチャーコンテナーがクラスターおよびオペレーティングシステムの保守管理タスクを実行するために使用する CPU を指定します。
    spec.cpu.isolated
    アプリケーションコンテナーがワークロードを実行するために使用する CPU を指定します。
    spec.nodeSelector
    パフォーマンスプロファイルを特定のノードに適用するためのノードセレクターを指定します。オプションのパラメーター。

15.8. クラスターのハイパースレッディングの設定

OpenShift Container Platform クラスターのハイパースレッディングを設定するには、パフォーマンスプロファイル内の CPU スレッド数を、予約済みまたは分離された CPU プールに設定されているのと同じコア数に設定します。

注記

パフォーマンスプロファイルを設定してからホストのハイパースレッディング設定を変更する場合は、PerformanceProfile YAML の CPU isolated フィールドと reserved フィールドを新しい設定に合わせて更新してください。

警告

以前に有効にしたホストのハイパースレッディング設定を無効にすると、PerformanceProfile YAML にリストされている CPU コアの ID が正しくなくなる可能性があります。この設定が間違っていると、リスト表示される CPU が見つからなくなるため、ノードが利用できなくなる可能性があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 設定する必要のあるホストのどの CPU でどのスレッドが実行されているかを確認します。

    クラスターにログインして以下のコマンドを実行し、ホスト CPU で実行されているスレッドを表示できます。

    $ lscpu --all --extended

    出力例

    CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
    0   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    1   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    2   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    3   0    0      3    3:3:3:0       yes    4800.0000 400.0000
    4   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    5   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    6   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    7   0    0      3    3:3:3:0       yes    4800.0000 400.0000

    この例では、4 つの物理 CPU コアで 8 つの論理 CPU コアが実行されています。CPU0 および CPU4 は物理コアの Core0 で実行されており、CPU1 および CPU5 は物理コア 1 で実行されています。または、特定の物理 CPU コア (以下の例では cpu0) に設定されているスレッドを表示するには、シェルプロンプトを開いて次のコマンドを実行します。

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

    出力例

    0-4

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

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

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

    重要

    ハイパースレッディングは、ほとんどの Intel プロセッサーでデフォルトで有効になっています。ハイパースレッディングが有効な場合、特定のコアで処理されるすべてのスレッドを分離するか、同じコアで処理する必要があります。

    ハイパースレッディングが有効な場合、保証されたすべての Pod が、Pod の障害を引き起こす可能性がある "ノイジーネイバー" 状況を回避するために、同時マルチスレッディング (SMT) レベルの倍数を使用する必要があります。詳細は、Static policy options を参照してください。

15.9. 低レイテンシーアプリケーション用のハイパースレッディングの無効化

低レイテンシー処理用にクラスターを設定する場合は、クラスターをデプロイする前に、ハイパースレッディングを無効にするかどうかを検討してください。

ハイパースレッディングを無効にするには、次の手順を実行します。

手順

  • ハードウェアとトポロジーに適したパフォーマンスプロファイルを作成します。次の例では、nosmt を 追加のカーネル引数として設定しています。

    パフォーマンスプロファイルの例

    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 を使用します。

15.10. Guaranteed Pod の分離された CPU のデバイス割り込み処理の管理

Node Tuning Operator は、ホスト CPU を、Pod Infra コンテナーを含むクラスターとオペレーティングシステムのハウスキーピング業務用の予約 CPU と、ワークロードを実行するアプリケーションコンテナー用の分離 CPU に分割して管理することができます。これらのタスクを完了することで、低遅延ワークロード用の CPU を独立したワークロードとして設定できます。

デバイスの割り込みは、Guaranteed Pod が実行されている CPU を除き、CPU のオーバーロードを防ぐためにすべての分離された CPU および予約された CPU 間で負荷が分散されます。Guaranteed Pod の CPU は、関連するアノテーションが Pod に設定されている場合にデバイス割り込みを処理できなくなります。

パフォーマンスプロファイルで、globallyDisableIrqLoadBalancing は、デバイス割り込みが処理されるかどうかを管理するために使用されます。特定のワークロードでは、予約された CPU は、デバイスの割り込みを処理するのに常に十分な訳ではないため、デバイスの割り込みは分離された CPU でグローバルに無効化されていません。デフォルトでは、Node Tuning Operator は分離された CPU でのデバイス割り込みを無効にしません。

15.10.1. ノードの有効な IRQ アフィニティー設定の確認

実際の割り込み処理を確認するには、ノードの有効な IRQ アフィニティー設定を特定します。一部の IRQ コントローラーはアフィニティー設定をサポートしておらず、IRQ マスクがすべてのオンライン CPU を公開している場合でも、実質的に CPU 0 で動作します。

以下は、IRQ アフィニティー設定がサポートされていないことを Red Hat が認識しているドライバーとハードウェアの例です。このリストはすべてを網羅しているわけではありません。

  • megaraid_sas などの一部の RAID コントローラードライバー
  • 多くの不揮発性メモリーエクスプレス (NVMe) ドライバー
  • 一部の LAN on Motherboard (LOM) ネットワークコントローラー
  • managed_irqs を使用するドライバー
注記

IRQ アフィニティー設定をサポートしない理由は、プロセッサーの種類、IRQ コントローラー、マザーボードの回路接続などに関連している可能性があります。

分離された CPU に有効な IRQ アフィニティーが設定されている場合は、一部のハードウェアまたはドライバーで IRQ アフィニティー設定がサポートされていないことを示唆している可能性があります。有効なアフィニティーを見つけるには、ホストにログインし、次のコマンドを実行します。

$ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;

出力例

/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 に割り当てられることもあります。managed_irqs の詳細は、マネージド割り込みのアフィニティーは、たとえ対象が分離された CPU であっても変更できませんを参照してください。

15.10.2. ノード割り込みアフィニティーの設定

デバイス割り込み要求 (IRQ) を受信するコアを制御するには、クラスターノードで IRQ 動的負荷分散を設定します。この設定により、割り込み処理を特定の CPU に分離できるため、レイテンシーに敏感なワークロードでも安定したパフォーマンスを確保できます。

前提条件

  • コアを分離するには、すべてのサーバーハードウェアコンポーネントが IRQ アフィニティーをサポートしている必要があります。サーバーのハードウェアコンポーネントが IRQ アフィニティーをサポートしているかどうかを確認するには、サーバーのハードウェア仕様を参照するか、ハードウェアプロバイダーに問い合わせてください。

手順

  1. cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
  2. パフォーマンスプロファイルの apiVersionperformance.openshift.io/v2 を使用するように設定します。
  3. globallyDisableIrqLoadBalancing フィールドを削除するか、これを false に設定します。
  4. 適切な分離された CPU と予約された CPU を設定します。以下のスニペットは、2 つの CPU を確保するプロファイルを示しています。IRQ 負荷分散は、isolated CPU セットで実行されている Pod に対して有効になります。

    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 の制限」を参照してください。

15.11. huge page の設定

特定のノードに huge page を事前割り当てするには、Node Tuning Operator を使用します。この設定により、OpenShift Container Platform クラスターは、必要なワークロードのために必要なメモリーリソースを確実に確保します。

OpenShift Container Platform は、Huge Page を作成し、割り当てる方法を提供します。Node Tuning Operator は、パフォーマンスプロファイルを使用して、これをより簡単に行う方法を提供します。

手順

  • パフォーマンスプロファイルの hugepages.pages セクションで、サイズカウント、およびオプションで ノード の複数のブロックを指定します。

    設定例

    hugepages:
       defaultHugepagesSize: "1G"
       pages:
       - size:  "1G"
         count:  4
         node:  0
    # ...

    ここでは、以下のようになります。

    hugepages.pages.node

    huge page が割り当てられる NUMA ノードを 指定します。node を省略すると、ページはすべての NUMA ノード間で均等に分散されます。

    注記

    更新が完了したことを示す関連するマシン設定プールのステータスを待機します。

    これらは、Huge Page を割り当てるのに必要な唯一の設定手順です。

検証

  • 設定を確認するには、ノード上の /proc/meminfo ファイルを参照します。

    $ oc debug node/ip-10-0-141-105.ec2.internal
    # grep -i huge /proc/meminfo

    出力例

    AnonHugePages:    ###### ##
    ShmemHugePages:        0 kB
    HugePages_Total:       2
    HugePages_Free:        2
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       #### ##
    Hugetlb:            #### ##

  • 新規サイズを報告するには、oc describe を使用します。

    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge

    出力例

                                       hugepages-1g=true
     hugepages-###:  ###
     hugepages-###:  ###

15.11.1. 複数の Huge Page サイズの割り当て

同じコンテナーで異なるサイズの Huge Page を要求できます。このタスクを実行することで、異なる huge page サイズを必要とするコンテナーで設定される、より複雑な Pod を定義できます。

次の例は、1G2M の サイズを定義する方法を示しています。Node Tuning Operator はノード上で両方のサイズを設定します。

手順

  • PerformanceProfile オブジェクトを編集して、huge page の 1G および 2M サイズを定義します。Node Tuning Operator はノード上で両方のサイズを設定します。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
        name: example-performance-profile
    #...
    spec:
      hugepages:
        defaultHugepagesSize: 1G
        pages:
        - count: 1024
          node: 0
          size: 2M
        - count: 4
          node: 1
          size: 1G
    # ...

15.12. Node Tuning Operator を使用した NIC キューの削減

Node Tuning Operator は、NIC キューを削減してパフォーマンスを向上させるのに役立ちます。パフォーマンスプロファイルを使用して調整を行い、さまざまなネットワークデバイスのキューをカスタマイズできます。

15.12.1. パフォーマンスプロファイルによる NIC キューの調整

ネットワークトラフィックの処理を最適化するには、パフォーマンスプロファイルを使用して、各ネットワークデバイスのキュー数を調整してください。この設定を使用することで、特定のワークロード要件に合わせてネットワーク設定を調整できます。

パフォーマンスプロファイルを使用すると、各ネットワークデバイスのキュー数を調整できます。

サポート対象のネットワークデバイスは以下のとおりです。

  • 非仮想ネットワークデバイス
  • 複数のキュー (チャネル) をサポートするネットワークデバイス

サポート対象外のネットワークデバイスは以下の通りです。

  • Pure Software ネットワークインターフェイス
  • ブロックデバイス
  • Intel DPDK Virtual Function

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. cluster-admin 権限を持つユーザーとして、Node Tuning Operator を実行する OpenShift Container Platform クラスターにログインします。
  2. お使いのハードウェアとトポロジーに適したパフォーマンスプロファイルを作成して適用します。プロファイルの作成に関するガイダンスは、「パフォーマンスプロファイルの作成」セクションを参照してください。
  3. この作成したパフォーマンスプロファイルを編集します。

    $ oc edit -f <your_profile_name>.yaml
  4. spec フィールドに net オブジェクトを設定します。オブジェクトリストには、以下の 2 つのフィールドを含めることができます。

    • userLevelNetworking は、ブール値フラグとして指定される必須フィールドです。userLevelNetworkingtrue の場合、サポートされているすべてのデバイスのキュー数は、予約された CPU 数に設定されます。デフォルトは false です。
    • devices は、キューを予約 CPU 数に設定するデバイスのリストを指定する任意のフィールドです。デバイスリストに何も指定しないと、設定がすべてのネットワークデバイスに適用されます。設定は以下のとおりです。

      • interfaceName: このフィールドはインターフェイス名を指定し、正または負のシェルスタイルのワイルドカードをサポートします。

        • ワイルドカード構文の例: <string> .*
        • 負のルールには、感嘆符のプリフィックスが付きます。除外リスト以外のすべてのデバイスにネットキューの変更を適用するには、!<device> を使用します (例: !eno1)。
      • vendorID: 16 ビット (16 進数) として表されるネットワークデバイスベンダー ID。接頭辞は 0x です。
      • deviceID: 16 ビット (16 進数) として表されるネットワークデバイス ID (モデル)。接頭辞は 0x です。

        注記

        deviceID が指定されている場合は、vendorID も定義する必要があります。デバイスエントリー interfaceNamevendorID、または vendorIDdeviceID のペアで指定されているすべてのデバイス識別子に一致するデバイスは、ネットワークデバイスとしての資格があります。その後、このネットワークデバイスは net キュー数が予約 CPU 数に設定されます。

        2 つ以上のデバイスを指定すると、net キュー数は、それらのいずれかに一致する net デバイスに設定されます。

  5. このパフォーマンスプロファイルの例を使用して、キュー数をすべてのデバイスの予約 CPU 数に設定します。

    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 数にキュー数を設定します。

    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 数にキュー数を設定します。

    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 数にキュー数を設定します。

    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. このパフォーマンスプロファイルの例を使用して、インターフェイス名 eth00x1af4vendorID、および 0x1000deviceID を持つすべてのデバイスの予約 CPU 数にキュー数を設定します。

    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. 更新されたパフォーマンスプロファイルを適用します。

    $ oc apply -f <your_profile_name>.yaml

15.12.2. キューステータスの確認

パフォーマンスプロファイルの変更が有効になっていることを確認するには、キューの状態を確認してください。これらの例を確認することで、特定のチューニング設定がお客様の環境に正しく適用されていることを確認できます。

このセクションでは、いくつかの例を使用して、さまざまなパフォーマンスプロファイルと、変更が適用されていることを確認する方法を説明します。

例 1

例 1 は、サポートされている すべての デバイスに対して、予約済み CPU 数(2) に設定されているネットキュー数を示しています。

パフォーマンスプロファイルの関連セクションは次のとおりです。

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
# ...

次のコマンドは、デバイスに関連付けられているキューの状態を表示します。

注記

パフォーマンスプロファイルが適用されたノードで、以下のコマンドを実行します。

$ ethtool -l <device>

プロファイルを適用する前にキューの状態を確認するには、次のコマンドを使用します。

$ ethtool -l ens4

出力例

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

プロファイル適用後のキューの状態を確認するには、次のコマンドを使用します。

$ ethtool -l ens4

出力例

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

  • 結合: サポートされている すべての デバイスの予約済み CPU の合計数が 2 であることを示す結合チャネルを指定します。これは、パフォーマンスプロファイルでの設定内容と一致します。
例 2

例 2 は、特定の ベンダー ID を持つサポートされている すべての ネットワークデバイスに対して、ネットワークキューカウントが予約済み CPU カウント(2) に設定されることを示しています。

パフォーマンスプロファイルの関連セクションは次のとおりです。

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1
      isolated: 2-8
    net:
      userLevelNetworking: true
      devices:
      - vendorID = 0x1af4
# ...

次のコマンドは、デバイスに関連付けられているキューの状態を表示します。

注記

パフォーマンスプロファイルが適用されたノードで、以下のコマンドを実行します。

$ ethtool -l <device>

プロファイル適用後のキューの状態を確認するには、次のコマンドを使用します。

$ ethtool -l ens4

出力例

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

  • 結合: vendorID=0x1af4 を持つすべてのサポート対象デバイスの予約済み CPU の合計数が 2 であることを指定します。たとえば、vendorID=0x1af4 のネットワークデバイス ens2 が別に存在する場合に、このデバイスも合計で 2 つの net キューを持ちます。これは、パフォーマンスプロファイルでの設定内容と一致します。
例 3

例 3 は、定義されたデバイス識別子のいずれかに一致するサポートされている すべての ネットワークデバイスに対して、ネットワークキューカウントが予約済み CPU カウント(2) に設定されることを示しています。udevadm info コマンドで、デバイスの詳細なレポートを確認できます。以下の例では、デバイスは以下のようになります。

# udevadm info -p /sys/class/net/ens4
...
E: ID_MODEL_ID=0x1000
E: ID_VENDOR_ID=0x1af4
E: INTERFACE=ens4
...
# udevadm info -p /sys/class/net/eth0
...
E: ID_MODEL_ID=0x1002
E: ID_VENDOR_ID=0x1001
E: INTERFACE=eth0
...

interfaceNameeth0 のデバイスの場合に net キューを 2 に、vendorID=0x1af4 を持つデバイスには、以下のパフォーマンスプロファイルを設定します。

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
# ...

プロファイル適用後のキューの状態を確認するには、次のコマンドを使用します。

$ ethtool -l ens4

出力例

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

  • 結合: vendorID=0x1af4 を持つすべてのサポート対象デバイスの予約済み CPU の合計数を 2 に設定します。

    たとえば、vendorID=0x1af4 のネットワークデバイス ens2 が別に存在する場合に、このデバイスも合計で 2 つの net キューを持ちます。同様に、interfaceNameeth0 のデバイスには、合計 net キューが 2 に設定されます。

15.12.3. NIC キューの調整に関するロギング

NIC キューの調整を確認するには、Tuned デーモンのログを確認してください。これらのログには、割り当てられたデバイスの詳細を示すメッセージが記録されるため、システムが設定変更を正しく適用したことを確認できます。

以下のメッセージは、/var/log/tuned/tuned.log ファイルに記録される場合があります。

  • 正常に割り当てられたデバイスの詳細を示す INFO メッセージが記録されます。

    INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
  • 割り当てることのできるデバイスがない場合は、WARNING メッセージが記録されます。

    WARNING  tuned.plugins.base: instance net_test: no matching devices available

第16章 リアルタイムおよび低レイテンシーワークロードのプロビジョニング

OpenShift Container Platform アプリケーションの低遅延と安定した応答時間を実現するには、Node Tuning Operator を使用してください。この Operator は、高性能コンピューティングワークロード向けにクラスターを最適化するための自動チューニングを実行します。

このような変更を行うには、パフォーマンスプロファイル設定を使用します。

kernel-rt へのカーネルの更新、Pod インフラコンテナーを含むクラスターおよびオペレーティングシステムのハウスキーピング作業用 CPU の予約、アプリケーションコンテナーがワークロードを実行するための CPU の分離、未使用の CPU の無効化による電力消費削減を行うことができます。

注記

アプリケーションを作成するときは、RHEL for Real Time プロセスおよびスレッド に記載されている一般的な推奨事項に従ってください。

16.1. 低遅延ワークロードをコンピュートノードにスケジュールする

低遅延ワークロードを実行するには、リアルタイム機能を設定するパフォーマンスプロファイルに関連付けられたコンピュートノードにワークロードをスケジュールします。これにより、ノードがアプリケーション固有のタイミングおよびパフォーマンス要件を満たすように調整されることが保証されます。

注記

ワークロードを特定のノードにスケジュールするには、Pod カスタムリソース (CR) のラベルセレクターを使用します。ラベルセレクターは、Node Tuning Operator によって低レイテンシー用に設定されたマシン設定プールに割り当てられているノードと一致している必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • クラスターに、低遅延ワークロード向けにコンピュートノードを調整するパフォーマンスプロファイルを適用しました。

手順

  1. 低レイテンシーのワークロード用の Pod CR を作成し、クラスターに適用します。次に例を示します。

    リアルタイム処理を使用するように設定した Pod 仕様の例

    apiVersion: v1
    kind: Pod
    metadata:
      name: dynamic-low-latency-pod
      annotations:
        cpu-quota.crio.io: "disable"
        cpu-load-balancing.crio.io: "disable"
        irq-load-balancing.crio.io: "disable"
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: dynamic-low-latency-pod
        image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.16"
        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: ""
      runtimeClassName: performance-dynamic-low-latency-profile 
    1
    
    # ...

    以下は、

    metadata.annotations.cpu-quota.crio.io
    Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。
    metadata.annotations.cpu-load-balancing.crio.io
    CPU 負荷分散を無効にします。
    metadata.annotations.irq-load-balancing.crio.io
    ノード上の Pod を割り込み処理から除外します。
    spec.nodeSelector.node-role.kubernetes.io/worker-cnf
    nodeSelector ラベルは、Node CR で指定したラベルと一致している必要があります。
    spec.runtimeClassName
    runtimeClassName は、クラスターで設定したパフォーマンスプロファイルの名前と一致している必要があります。
  2. Pod の runtimeClassName を performance-<profile_name> の形式で入力します。<profile_name> は PerformanceProfile YAML の name です。前述の YAML の例では、名前はperformance-dynamic-low-latency-profile です。
  3. Pod が正常に実行されていることを確認します。ステータスは 実行中 である必要があり、正しい cnf-worker ノードが設定されている必要があります。

    $ oc get pod -o wide

    予想される出力

    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 を取得します。

    $ oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

    予想される出力

    Cpus_allowed_list:  2-3

検証

ノードの設定が正しく適用されていることを確認します。

  1. ノードにログインして設定を確認します。

    $ oc debug node/<node-name>
  2. ノードのファイルシステムを使用できることを確認します。

    sh-4.4# chroot /host

    予想される出力

    sh-4.4#

  3. デフォルトのシステム CPU アフィニティーマスクに、CPU 2 や 3 などの dynamic-low-latency-pod CPU が含まれていないことを確認します。

    sh-4.4# cat /proc/irq/default_smp_affinity

    出力例

    33

  4. システムの IRQ が dynamic-low-latency-pod CPU で実行されるように設定されていないことを確認します。

    sh-4.4# find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    出力例

    /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 を必要とするアプリケーションと組み合わせて実行プローブを使用すると、レイテンシーが急上昇する可能性があります。代わりに、適切に設定されたネットワークプローブのセットなど、他のプローブを使用してください。

16.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 を作成します。

    $ oc create namespace qos-example
    • qos-example: qos-example の サンプル名前空間を指定します。

      出力例

      namespace/qos-example created

  2. Pod リソースを作成します。

    1. Pod リソースを定義する YAML ファイルを作成します。

      qos-example.yaml ファイルの例

      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
          resources:
            limits:
              memory: "200Mi"
              cpu: "1"
            requests:
              memory: "200Mi"
              cpu: "1"
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: [ALL]

      ここでは、以下のようになります。

      spec.containers.image
      hello-openshift イメージなどの公開イメージを指定します。
      spec.containers.resources.limits.memory
      メモリー制限を 200MB に指定します。
      spec.containers.resources.limits.cpu
      CPU 数を 1 に制限することを指定します。
      spec.containers.resources.requests.memory
      200MB のメモリー要求を指定します。
      spec.containers.resources.requests.cpu

      CPU 要求数として 1 を指定します。

      注記

      コンテナーのメモリー制限を指定しても、メモリー要求を指定しなかった場合、OpenShift Container Platform によって制限に合わせてメモリー要求が自動的に割り当てられます。同様に、コンテナーの CPU 制限を指定しても、CPU 要求を指定しなかった場合、OpenShift Container Platform によって制限に合わせて CPU 要求が自動的に割り当てられます。

    2. 次のコマンドを実行して、Pod リソースを作成します。

      $ oc apply -f qos-example.yaml --namespace=qos-example

      出力例

      pod/qos-demo created

検証

  • 次のコマンドを実行して、Pod の qosClass 値を表示します。

    $ oc get pod qos-demo --namespace=qos-example --output=yaml | grep qosClass

    出力例

        qosClass: Guaranteed

16.3. Pod の CPU 負荷分散の無効化

パフォーマンスを最適化するには、Pod の CPU 負荷分散を無効または有効にしてください。CRI-O はこの機能を実装しており、特定の要件が満たされた場合にのみ設定を適用します。

CPU 負荷分散を無効または有効にする機能は CRI-O レベルで実装されます。CRI-O のコードは、以下の要件を満たす場合にのみ CPU の負荷分散を無効または有効にします。

  • Pod は performance-<profile-name> ランタイムクラスを使用する必要があります。以下に示すように、パフォーマンスプロファイルのステータスを確認して、適切な名前を取得できます。

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    ...
    status:
      ...
      runtimeClass: performance-manual

Node Tuning Operator は、関連ノード下での高性能ランタイムハンドラー config snippet の作成と、クラスター下での高性能ランタイムクラスの作成を担当します。このスニペットには、CPU 負荷分散の設定機能を有効にする点を除いて、デフォルトのランタイムハンドラーと同じ内容が含まれています。

Pod の CPU 負荷分散を無効にするには、Pod 仕様に以下のフィールドが含まれる必要があります。

apiVersion: v1
kind: Pod
metadata:
  #...
  annotations:
    #...
    cpu-load-balancing.crio.io: "disable"
    #...
  #...
spec:
  #...
  runtimeClassName: performance-<profile_name>
  #...
注記

CPU マネージャーの静的ポリシーが有効にされている場合に、CPU 全体を使用する Guaranteed QoS を持つ Pod について CPU 負荷分散を無効にします。これ以外の場合に CPU 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。

16.4. 優先度の高い Pod の省電力モードの無効化

ノードで省電力設定を使用している場合に優先度の高いワークロードを保護するには、Pod レベルでパフォーマンス設定を適用してください。これにより、設定が Pod で使用されるすべてのコアに適用され、パフォーマンスの安定性が維持されます。

Pod レベルで P ステートと C ステートを無効にすることで、優先度の高いワークロードを設定して、最高のパフォーマンスと最小の待機時間を実現できます。

Expand
表16.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 設定をオーバーライドします。

    優先度の高いワークロードアノテーションの例

    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 を再起動してアノテーションを適用します。

16.5. CPU CFS クォータの無効化

レイテンシーに敏感なワークロードにおける CPU スロットリングを防ぐには、CPU CFS クォータを無効にしてください。この設定により、Pod はノード上の未割り当ての CPU リソースを使用できるため、アプリケーションの一貫したパフォーマンスが確保されます。

手順

  • ピニングされた Pod の CPU スロットリングを除外するには、cpu-quota.crio.io: "disable" アノテーションを使用して Pod を作成します。このアノテーションは、Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。

    cpu-quota.crio.io を無効にした Pod 仕様の例

    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 クォータを無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響を与える可能性があります。

16.6. ピニングされたコンテナーが実行されている CPU の割り込み処理の無効化

ワークロードの低レイテンシーを実現するために、一部のコンテナーでは、コンテナーのピニング先の CPU がデバイス割り込みを処理しないようにする必要があります。irq-load-balancing.crio.io Pod アノテーションを使用すると、デバイス割り込みを、ピン留めされたコンテナーが実行されている CPU で処理するかどうかを制御できます。

個々の Pod に属するコンテナーがピニングされている CPU の割り込み処理を無効にするには、パフォーマンスプロファイルで globallyDisableIrqLoadBalancingfalse に設定されていることを確認します。Pod 仕様で、irq-load-balancing.crio.io Pod アノテーションを 無効 に設定します。次の例を参照してください。

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      irq-load-balancing.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

第17章 低レイテンシーノードのチューニングステータスのデバッグ

PerformanceProfile の カスタムリソース (CR) ステータスフィールドを使用して、クラスターノードのチューニングステータスを報告したり、レイテンシーの問題をデバッグしたりします。

17.1. 低レイテンシー CNF チューニングステータスのデバッグ

チューニングの状態を報告したり、レイテンシーの劣化問題をデバッグしたりするには、PerformanceProfile カスタムリソース (CR) のステータスフィールドを使用します。これらのフィールドは、Operator のリコンシリエーション機能の条件を記述しており、設定の状態を確認するのに役立ちます。

パフォーマンスプロファイルに割り当てられるマシン設定プールのステータスが degraded 状態になると典型的な問題が発生する可能性があり、これにより PerformanceProfile のステータスが低下します。この場合、マシン設定プールは失敗メッセージを発行します。

Node Tuning Operator には performanceProfile.spec.status.Conditions ステータスフィールドが含まれています。

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
すべてのマシン設定とチューニング済みプロファイルが正常に作成され、NTO、MCO、Kubelet など、それらを処理するクラスターコンポーネントで利用可能になりました。
Upgradeable
Operator によって維持されるリソースは、アップグレードを実行する際に安全な状態にあるかどうかを示します。
Progressing
パフォーマンスプロファイルからのデプロイメントプロセスが開始されたことを示します。
Degraded

以下の場合にエラーを示します。

  • パーマンスプロファイルの検証に失敗しました。
  • すべての関連するコンポーネントの作成が完了しませんでした。

これらのタイプには、それぞれ以下のフィールドが含まれます。

Status
特定のタイプの状態 (true または false)。
Timestamp
トランザクションのタイムスタンプ。
Reason string
マシンの読み取り可能な理由。
Message string
状態とエラーの詳細を説明する人が判読できる理由 (ある場合)。

17.2. マシン設定プール

特定のノードにパフォーマンスプロファイルを適用するには、それらをマシン設定プール (MCP) に関連付けます。MCP は、カーネル引数、huge page、リアルタイムカーネルなどのチューニング更新のステータスを追跡し、クラスター設定が正しく適用されるようにします。

Performance Profile コントローラーは MCP の変更を監視し、それに応じてパフォーマンスプロファイルのステータスを更新します。

MCP は、Degraded の場合に限りパフォーマンスプロファイルステータスに返し、performanceProfile.status.condition.Degraded = true になります。

手順

  1. 以下のコマンドを入力して、関連付けられているマシン設定プールの状態を確認してください。出力例は、パフォーマンスプロファイルと、それに関連付けられたマシン設定プール (worker-cnf) が劣化状態にあることを示しています。

    # oc get mcp

    出力例

    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 の 記述 セクションにその理由が記載されています。

    # oc describe mcp worker-cnf

    出力例

      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. オプション: パフォーマンスプロファイルに対して oc describe コマンドを実行して、劣化状態の状態を確認することもできます。出力例では、パフォーマンスプロファイル ステータス フィールドが degraded = true とマークされています。

    # oc describe performanceprofiles performance

    出力例

    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

17.3. must-gather ツールについて

クラスターの問題をデバッグするには、oc adm must-gather CLI コマンドを使用します。このツールは、トラブルシューティングに必要な可能性が最も高い診断情報を収集し、分析に必要なデータを確実に提供します。

oc adm must-gather CLI コマンドは、クラスターから以下の情報を収集します。

  • リソース定義
  • 監査ログ
  • サービスログ

--image 引数を指定してコマンドを実行する際にイメージを指定できます。イメージを指定する際、ツールはその機能または製品に関連するデータを収集します。oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

17.4. Red Hat サポート向けの低レイテンシーのチューニングデバッグデータの収集

サポートケースを開設する際に、低遅延設定の問題をデバッグするには、must-gather ツールを使用して Red Hat サポート向けの診断情報を収集してください。このコマンドは、OpenShift Container Platform クラスターから、ノードチューニングや NUMA トポロジーなどの重要なデータを収集します。

迅速なサポートを得るには、OpenShift Container Platform と低レイテンシーチューニングの両方の診断情報を提供してください。

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 OpenShift CLI (oc) がインストールされました。

手順

  1. must-gather データを保存するディレクトリーに移動します。
  2. 次のコマンドを実行してデバッグ情報を収集します。

    $ oc adm must-gather

    出力例

    [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 オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

    $ tar cvaf must-gather.tar.gz must-gather-local.5421342344627712289//
    • must-gather-local.5421342344627712289//: この値を、must-gather ツールによって作成されたディレクトリー名に置き換えてください。

      注記

      圧縮ファイルを作成して、サポートケースにデータを添付したり、パフォーマンスプロファイルの作成時に Performance Profile Creator ラッパースクリプトで使用したりできます。

  4. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。

第18章 プラットフォーム検証のためのレイテンシーテストの実行

Cloud-native Network Functions (CNF) テストイメージを使用して、CNF ワークロードの実行に必要なすべてのコンポーネントがインストールされている CNF 対応の OpenShift Container Platform クラスターでレイテンシーテストを実行できます。レイテンシーテストを実行して、ワークロードのノードチューニングを検証します。

cnf-tests コンテナーイメージは、registry.redhat.io/openshift4/cnf-tests-rhel9:v4.20 で入手できます。

18.1. レイテンシーテストを実行するための前提条件

レイテンシーテストを実行するには、クラスターが次の要件を満たしている必要があります。

  • 必要な CNF 設定をすべて適用した。これには、リファレンス設計仕様 (RDS) またはお客様固有の要件に基づく PerformanceProfile クラスターおよびその他の設定が含まれます。
  • podman login コマンドを使用して、カスタマーポータルの認証情報で registry.redhat.io にログインした。

18.2. レイテンシーの測定

システム遅延を正確に測定するには、cnf-tests イメージに含まれている hwlatdetectcyclictest、および oslat ツールを使用してください。これらのメトリクスを評価することで、環境におけるパフォーマンスの遅延を特定し、解決するのに役立ちます。

各ツールには特定の用途があります。信頼できるテスト結果を得るために、ツールを順番に使用します。

hwlatdetect
ベアメタルハードウェアが達成できるベースラインを測定します。次のレイテンシーテストに進む前に、hwlatdetect によって報告されるレイテンシーが必要なしきい値を満たしていることを確認してください。これは、オペレーティングシステムのチューニングによってハードウェアレイテンシーのスパイクを修正することはできないためです。
cyclictest
hwlatdetect が検証に合格した後、リアルタイムのカーネルスケジューラーのレイテンシーを検証します。cyclictest ツールは繰り返しタイマーをスケジュールし、希望のトリガー時間と実際のトリガーの時間の違いを測定します。この違いは、割り込みまたはプロセスの優先度によって生じるチューニングで、基本的な問題を発見できます。ツールはリアルタイムカーネルで実行する必要があります。
oslat
CPU 集約型 DPDK アプリケーションと同様に動作し、CPU の高いデータ処理をシミュレーションするビジーループにすべての中断と中断を測定します。

テストでは、次の環境変数が導入されます。

Expand
表18.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.timeoutLATENCY_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 マイクロ秒の最大許容遅延で実行されます。

18.3. レイテンシーテストの実行

クラスターレイテンシーテストを実行して、Cloud-native Network Functions (CNF) ワークロードのノードチューニングを検証します。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

この手順では 、hwlatdetectcyclictestoslat の 3 つの個別テストを実行します。各テストの詳細は、それぞれのセクションを参照してください。

手順

  1. kubeconfig ファイルを含むディレクトリーでシェルプロンプトを開きます。

    現在のディレクトリーにある kubeconfig ファイルとそれに関連する $KUBECONFIG 環境変数を含むテストイメージを提供し、ボリュームを介してマウントします。これにより、実行中のコンテナーがコンテナー内から kubeconfig ファイルを使用できるようになります。

    注記

    次のコマンドにより、ローカルの kubeconfig が cnf-tests コンテナー内の kubeconfig/kubeconfig にマウントされ、クラスターにアクセスできるようになります。

  2. レイテンシーテストを実行するために、次のコマンドを実行します。必要に応じて変数値を置き換えます。

    $ 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-rhel9:v4.16 /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 秒) 実行する必要があります。

18.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 テストを実行するには、変数値を適切に置き換えて、次のコマンドを実行します。

    $ 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-rhel9:v4.16 \
    /usr/bin/test-run.sh --ginkgo.focus="hwlatdetect" --ginkgo.v --ginkgo.timeout="24h"

    hwlatdetect テストは 10 分間 (600 秒) 実行されます。観測された最大レイテンシーが MAXIMUM_LATENCY (20 μs) よりも低い場合、テストは正常に実行されます。

    結果がレイテンシーのしきい値を超えると、テストは失敗します。

    重要

    テストの際には、上記のように、より短い期間を使用してテストを実行できます。ただし、最終的な検証と有効な結果を得るには、テストを少なくとも 12 時間 (43200 秒) 実行する必要があります。

    障害出力の例

    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
                Sample window:     10000000us
                Sample width:      950000us
             Non-sampling period:  9050000us
                Output File:       None
    
        Starting test
        test finished
        Max Latency: 326us
        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

    • レイテンシーしきい値: MAXIMUM_LATENCY または HWLATDETECT_MAXIMUM_LATENCY 環境変数を使用して、レイテンシーしきい値を設定できます。
    • 最大遅延時間: テスト中に測定された最大遅延時間値。

18.3.2. hwlatdetect テスト結果の例

テスト中に加えられた変更の影響を追跡するために、各実行時の生データと、最適な設定を組み合わせたセットを収集してください。これらのメトリクスを保持することで、テスト結果の包括的な履歴が得られます。

以下のタイプの結果をキャプチャーできます。

  • テスト中に行われた変更への影響の履歴を作成するために、各実行後に収集される大まかな結果
  • 最良の結果と設定を備えたラフテストの組み合わせセット

良い結果の例

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 ツールは、サンプルが指定されたしきい値を超えた場合にのみ出力を提供します。

悪い結果の例

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 によって報告されたレイテンシーが必要なしきい値を満たしていることを確認してください。ハードウェアによって生じるレイテンシーを修正するには、システムベンダーのサポートに連絡しないといけない場合があります。

すべての遅延スパイクがハードウェアに関連しているわけではありません。ワークロードの要件を満たすようにホストファームウェアを調整してください。詳細は、システムチューニングのためのファームウェアパラメーターの設定を参照してください。

18.3.3. cyclictest の実行

指定された CPU 上でリアルタイムのカーネルスケジューラーのレイテンシーを測定するには、cyclictest ツールを実行します。これらのメトリクスを評価することで、実行遅延を特定し、高性能な運用に向けてシステムを最適化できます。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

前提条件

  • レイテンシーテストを実行するための前提条件を確認した。

手順

  • cyclictest を実行するには、次のコマンドを実行し、必要に応じて変数の値を置き換えます。

    $ 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-rhel9:v4.16 \
    /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 秒) 実行する必要があります。

    障害出力の例

    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.3.4. サイクルテスト結果の例

レイテンシーテストの結果を正確に解釈するには、メトリクスを自社のワークロード要件と照らし合わせて評価してください。許容されるパフォーマンスのしきい値は、4G DU ワークロードを実行しているか、5G DU ワークロードを実行しているかによって大きく異なります。

次の例は、4G DU ワークロードでは許容範囲内であるが、5G DU ワークロードでは許容範囲外となる最大 18μs のスパイクを示しています。

良い結果の例

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:

悪い結果の例

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

18.3.5. oslat の実行

クラスターが CPU 負荷の高いデータ処理をどのように処理するかを評価するには、oslat テストを実行してください。この診断ツールは、CPU 負荷の高い DPDK アプリケーションをシミュレートし、システムの中断やパフォーマンスの低下を測定します。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

前提条件

  • レイテンシーテストを実行するための前提条件を確認した。

手順

  • oslat テストを実行するには、変数値を適切に置き換えて、次のコマンドを実行します。

    $ 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-rhel9:v4.16 \
    /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 秒) 実行する必要があります。

    障害出力の例

    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
    この例では、測定されたレイテンシーが最大許容値を超えています。

18.4. レイテンシーテストの失敗レポートの生成

テストの失敗を分析し、パフォーマンスの問題をトラブルシューティングするために、JUnit のレイテンシーテスト出力とテスト失敗レポートを生成します。この診断データを分析することで、システムに遅延が発生している箇所を正確に特定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • レポートがダンプされる場所へのパスを --report パラメーターを渡すことで、クラスターの状態とトラブルシューティング用のリソースに関する情報を含むテスト失敗レポートを作成します。

    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \
    -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel9:v4.16 \
    /usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v
    • <report_folder_path>: レポートが生成されるフォルダーへのパスを指定します。

18.5. JUnit レイテンシーテストレポートの生成

システムのパフォーマンスを分析し、実行遅延を追跡するには、JUnit レイテンシーテストレポートを生成します。この診断出力を確認することで、クラスター内の設定上の問題やパフォーマンスのボトルネックを特定するのに役立ちます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • レポートがダンプされる場所へのパスとともに --junit パラメーターを渡すことにより、JUnit 準拠の XML レポートを作成します。

    注記

    このコマンドを実行する前に、junit フォルダーを作成する必要があります。

    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junit:/junit \
    -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel9:v4.16 \
    /usr/bin/test-run.sh --ginkgo.junit-report junit/<file_name>.xml --ginkgo.v

    ここでは、以下のようになります。

    file_name
    XML レポートファイルの名前。

18.6. 単一ノードの OpenShift クラスターでレイテンシーテストを実行する

ノードのチューニングを検証し、パフォーマンスの遅延を特定するには、シングルノードの OpenShift クラスターでレイテンシーテストを実行します。これらのメトリクスを評価することで、高性能ワークロード向けに環境が最適化されていることを確認できます。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。podman コマンドを機能させるには、作成したボリュームに :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • Node Tuning Operator を使用してクラスターパフォーマンスプロファイルを適用しました。

手順

  • 単一ノードの OpenShift クラスターでレイテンシーテストを実行するには、次のコマンドを実行します。

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e LATENCY_TEST_RUNTIME=<time_in_seconds> registry.redhat.io/openshift4/cnf-tests-rhel9:v4.16 \
    /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
    注記

    各テストのデフォルトの実行時間は 300 秒です。有効なレイテンシーテスト結果を得るには、LATENCY_TEST_RUNTIME 変数を更新してテストを少なくとも 12 時間実行してください。

    バケットのレイテンシー検証ステップを実行するには、最大レイテンシーを指定する必要があります。最大レイテンシー変数の詳細は、「レイテンシーの測定」セクションの表を参照してください。

    テストスイートの実行後に、未解決のリソースすべてがクリーンアップされます。

18.7. 切断されたクラスターでのレイテンシーテストの実行

CNF テストイメージは、外部レジストリーに到達できない切断されたクラスターでテストを実行できます。これには、次の 2 つの手順が必要です。

  1. cnf-tests イメージをカスタム切断レジストリーにミラーリングします。
  2. カスタムの切断されたレジストリーからイメージを使用するようにテストに指示します。

18.7.1. クラスターからアクセスできるカスタムレジストリーへのイメージのミラーリング

クラスターから必要なイメージにアクセスできるようにするには、それらをカスタムレジストリーにミラーリングします。この同期を実行することで、デプロイメントに必要なコンテナーファイルが確実に揃います。これは、ネットワークが制限されている環境や接続が切断されている環境で特に役立ちます。

mirror 実行ファイルがイメージに同梱されており、テストイメージをローカルレジストリーにミラーリングするために oc が必要とする入力を提供します。

手順

  1. クラスターおよび registry.redhat.io にアクセスできる中間マシンから、以下のコマンドを実行してください。

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel9:v4.16 \
    /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

    ここでは、以下のようになります。

    <disconnected_registry>
    設定した切断ミラーレジストリーを指定します。例: my.local.registry:5000/
  2. cnf-tests イメージを非接続レジストリーにミラーリングしたら、テスト実行時にイメージを取得するために使用されていた元のレジストリーを、次の例のようなコマンドで上書きする必要があります。

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e IMAGE_REGISTRY="<disconnected_registry>" \
    -e CNF_TESTS_IMAGE="cnf-tests-rhel9:v4.16" \
    -e LATENCY_TEST_RUNTIME=<time_in_seconds> \
    <disconnected_registry>/cnf-tests-rhel9:v4.16 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"

18.7.2. カスタムレジストリーからのイメージを使用するためのテストの設定

CNF_TESTS_IMAGE 変数IMAGE_REGISTRY 変数を使用して、カスタムテストイメージとイメージレジストリーを使用することで、レイテンシーテストを実行できます。

手順

  • レイテンシーテストでカスタムテストイメージとイメージレジストリーを使用するように設定するには、次の例のようなコマンドを実行します。

    $ 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-rhel9:v4.16 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"

    ここでは、以下のようになります。

    <custom_image_registry>
    カスタムイメージレジストリーを指定します。例: custom.registry:5000/
    <custom_cnf-tests_image>
    カスタムの cnf-tests イメージを指定します。たとえば、custom-cnf-tests-image:latest のように 指定します。

18.7.3. クラスター OpenShift イメージレジストリーへのイメージのミラーリング

コンテナーイメージをデプロイメント用にローカルで利用可能にするには、OpenShift に組み込まれているイメージレジストリーにイメージをミラーリングします。この統合コンポーネントは、OpenShift Container Platform クラスター上で標準ワークロードとして実行され、必要なファイルへの継続的なアクセスを保証します。

手順

  1. レジストリーをルートで公開することで、レジストリーへの外部アクセスを取得します。このタスクは、次の例のようなコマンドを実行することで実行できます。

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. レジストリーエンドポイントを取得するには、次の例のようなコマンドを実行します。

    $ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
  3. イメージを公開するための名前空間を作成するには、次の例のようなコマンドを実行します。

    $ oc create ns cnftests
  4. イメージストリームを、テストに使用されるすべての namespace で利用可能にします。これは、テスト namespace が cnf-tests イメージストリームからイメージを取得できるようにするために必要です。以下の例と同様のコマンドを実行してください。

    $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
  5. 以下の例のようなコマンドを実行して、docker シークレット名を取得します。

    $ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
  6. 以下の例のようなコマンドを実行して、docker 認証トークンを取得します。

    $ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')
  7. dockerauth.json ファイルを作成します。次に例を示します。

    $ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json
  8. 次のようなコマンドを実行して、イメージを反転させます。

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel9:v4.16 \
    /usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
    -a=$(pwd)/dockerauth.json -f -
  9. テストを実行するには、次の例のようなコマンドを実行してください。

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

18.7.4. 異なるテストイメージセットのミラーリング

オプションで、レイテンシーテスト用にミラーリングされるデフォルトのアップストリームイメージを変更できます。

手順

  1. mirror コマンドは、デフォルトでアップストリームイメージをミラーリングしようとします。これは、以下の形式のファイルをイメージに渡すことで上書きできます。

    [
        {
            "registry": "public.registry.io:5000",
            "image": "imageforcnftests:4.16"
        }
    ]
  2. ファイルを mirror コマンドに渡します。たとえば、images.json としてローカルに保存します。以下のコマンドでは、ローカルパスはコンテナー内の /kubeconfig にマウントされ、これを mirror コマンドに渡すことができます。

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel9:v4.16 /usr/bin/mirror \
    --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
    |  oc image mirror -f -

18.8. cnf-tests コンテナーでのエラーのトラブルシューティング

レイテンシーテスト実行時のエラーをトラブルシューティングするには、cnf-tests コンテナー内からクラスターにアクセスできることを確認してください。この接続性を確保することで、よくあるテスト実行時のエラーが解消されます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • 次のコマンドを実行して、cnf-tests コンテナー内からクラスターにアクセスできることを確認します。

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel9:v4.16 \
    oc get nodes

    このコマンドが機能しない場合は、DNS 間のスパン、MTU サイズ、またはファイアウォールアクセスに関連するエラーが発生している可能性があります。

高遅延環境におけるクラスターの安定性を向上させるには、ワーカーの遅延プロファイルを適用してください。これらのプロファイルは、ネットワーク遅延が発生してもノードが健全で応答性を維持できるように、Kubelet のタイミングパラメーターを調整します。

クラスター管理者が遅延テストを実行してプラットフォームを検証した際に、遅延が大きい場合でも安定性を確保するために、クラスターの動作を調整する必要性が判明することがあります。

クラスター管理者が変更する必要があるのは、ファイルに記録されている 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 つのパラメーターセットが含まれています。パラメーターは、遅延の増加に対するクラスターの反応を制御するように、慎重に調整された値で事前定義されています。試験により手作業で最良の値を見つける必要はありません。

クラスターのインストール時、またはクラスターネットワークのレイテンシーの増加に気付いたときはいつでも、ワーカーレイテンシープロファイルを設定できます。

19.1. ワーカーレイテンシープロファイルについて

以下の情報を確認して、ワーカーレイテンシープロファイルについて理解を深めてください。ワーカーレイテンシープロファイルを使用すると、手動で最適な値を決定する必要なく、レイテンシーの問題に対するクラスターの反応を制御できます。

ワーカーレイテンシープロファイルは、4 つの異なるカテゴリーからなる慎重に調整されたパラメーターです。これらの値を実装する 4 つのパラメーターは、node-status-update-frequencynode-monitor-grace-perioddefault-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 に従って実行されます。ノードに taint がない場合、そのノードは 300 秒以内に削除されます (Kube API Serverdefault-not-ready-toleration-seconds および default-unreachable-toleration-seconds 設定)。

Expand
プロファイルコンポーネントパラメーター

デフォルト

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 分間でエビクションプロセスが開始されます。

Expand
プロファイルコンポーネントパラメーター

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 分間でエビクションプロセスが開始されます。

Expand
プロファイルコンポーネントパラメーター

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

注記

レイテンシープロファイルは、カスタムのマシン設定プールをサポートしていません。デフォルトのワーカーマシン設定プールのみをサポートしていします。

19.2. クラスター作成時にワーカー遅延プロファイルを実装する

高遅延環境におけるクラスターの安定性を確保するため、クラスター作成時にワーカーの遅延プロファイルを実装してください。

重要

インストールプログラムの設定を編集するには、まず openshift-install create manifests コマンドを使用して、デフォルトのノードマニフェストとその他のマニフェスト YAML ファイルを作成します。このファイル構造がなければ、workerLatencyProfile は追加できません。インストール先のプラットフォームにはさまざまな要件があります。該当するプラットフォームのドキュメントで、インストールセクションを参照してください。

手順

  1. インストール環境に適したフォルダー名を使用して、クラスター構築に必要なマニフェストを作成します。
  2. config.node を定義する YAML ファイルを作成します。ファイルは manifests ディレクトリーに置く必要があります。
  3. 初めてマニフェストで workerLatencyProfile を定義する際には、クラスターの作成時に DefaultMediumUpdateAverageReaction、または LowUpdateSlowReaction マニフェストのいずれかを指定します。

検証

  • 以下のコマンドを実行して、マニフェストファイルを表示してください。コマンドの出力には、マニフェストファイルに spec.workerLatencyProfileデフォルト 値が作成されたことが示されるはずです。

    $ openshift-install create manifests --dir=<cluster_install_dir>
  • <cluster_install_dir>: クラスターをインストールしたディレクトリーを指定します。
  • マニフェストを編集し、以下のコマンドを入力して値を追加します。以下のコマンド例は、vi エディターを使用して、Default という workerLatencyProfile 値が追加されたマニフェストファイルの例を示します。

    $ vi <cluster_install_dir>/manifests/config-node-default-profile.yaml
  • <cluster_install_dir>: クラスターをインストールしたディレクトリーを指定します。

    出力例

    apiVersion: config.openshift.io/v1
    kind: Node
    metadata:
    name: cluster
    spec:
    workerLatencyProfile: "Default"
    # ...

19.3. ワーカーレイテンシープロファイルの使用と変更

node.config オブジェクトを編集することで、ネットワークレイテンシーに対応するために、ワーカーのレイテンシープロファイルをいつでも変更できます。この設定により、制御プレーンとコンピュートノード間のネットワークレイテンシーが変動した場合でも、クラスターが適切に動作させることができます。

ワーカーレイテンシープロファイルは、一度に 1 つずつ移行する必要があります。たとえば、Default プロファイルから LowUpdateSlowReaction ワーカーレイテンシープロファイルに直接移行することはできません。Default ワーカーレイテンシープロファイルから、MediumUpdateAverageReaction プロファイル、そして LowUpdateSlowReaction プロファイルへと移行する必要があります。同様に、Default プロファイルに戻る場合は、まずロープロファイルからミディアムプロファイルに移行し、次に Default に移行する必要があります。

注記

OpenShift Container Platform クラスターのインストール時にワーカーレイテンシープロファイルを設定することもできます。

手順

  1. 中規模のワーカーのレイテンシープロファイルに移動します。

    1. node.config オブジェクトを編集します。

      $ oc edit nodes.config/cluster
    2. spec.workerLatencyProfile: MediumUpdateAverageReaction を追加します。

      node.config オブジェクトの例

      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
      # ...

      ここでは、以下のようになります。

      spec.workerLatencyProfile.MediumUpdateAverageReaction
      中程度のワーカーレイテンシーポリシーを使用することを指定します。

      変更が適用されている間は、各コンピュートノードでのスケジューリングは無効になります。

  2. 必要に応じて、ワーカーのレイテンシーが低いプロファイルに移動します。

    1. node.config オブジェクトを編集します。

      $ oc edit nodes.config/cluster
    2. spec.workerLatencyProfile の値を LowUpdateSlowReaction に変更します。

      node.config オブジェクトの例

      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
      # ...

      ここでは、以下のようになります。

      spec.workerLatencyProfile.LowUpdateSlowReaction
      ワーカーのレイテンシーを低く抑えるポリシーを使用することを指定します。

      変更が適用されている間は、各コンピュートノードでのスケジューリングは無効になります。

検証

  • 全ノードが Ready 状態に戻ると、以下のコマンドを使用して Kubernetes Controller Manager を確認し、これが適用されていることを確認できます。

    $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

    出力例

    # ...
        - lastTransitionTime: "2022-07-11T19:47:10Z"
          reason: ProfileUpdated
          status: "False"
          type: WorkerLatencyProfileProgressing
        - lastTransitionTime: "2022-07-11T19:47:10Z"
          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"
    # ...

    ここでは、以下のようになります。

    status.message: all static pod revision(s) have updated latency profile
    プロファイルが適用され、アクティブであることを指定します。

    ミディアムプロファイルからデフォルト、またはデフォルトからミディアムに変更する場合、node.config オブジェクトを編集し、spec.workerLatencyProfile パラメーターを適切な値に設定します。

19.4. ワーカーレイテンシープロファイルの結果値を表示します

コンピュートノードの設定を確認するには、それらのノード用に設定されたワーカーレイテンシープロファイルの結果値を表示します。これにより、高遅延環境向けに Kubelet のパラメーターが正しく調整されることが保証され、システムの安定性を確認するのに役立ちます。

以下の手順では、サンプルコマンドを使用して、ノード用に設定されているワーカーレイテンシープロファイルの値を表示します。

手順

  1. Kube API サーバーによる default-not-ready-toleration-seconds および default-unreachable-toleration-seconds フィールドの出力を確認します。

    $ oc get KubeAPIServer -o yaml | grep -A 1 default-

    出力例

    default-not-ready-toleration-seconds:
    - "300"
    default-unreachable-toleration-seconds:
    - "300"

  2. Kube Controller Manager からの node-monitor-grace-period フィールドの値を確認します。

    $ oc get KubeControllerManager -o yaml | grep -A 1 node-monitor

    出力例

    node-monitor-grace-period:
    - 40s

  3. 以下のコマンドを入力して、Kubelet の nodeStatusUpdateFrequency の 値を確認してください。デバッグシェル内のルートディレクトリーとしてディレクトリー /host を設定します。ルートディレクトリーを /host に変更することで、ホストの実行可能パスに含まれるバイナリーを実行できるようになります。

    $ oc debug node/<compute_node_name>
    $ chroot /host
    # cat /etc/kubernetes/kubelet.conf|grep nodeStatusUpdateFrequency

    出力例

    “nodeStatusUpdateFrequency”: “10s”

    これらの出力は、Worker Latency Profile のタイミング変数のセットを検証します。

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

プラットフォームプロセスがアプリケーションの動作を妨害しないようにするには、ワークロードパーティショニングを設定してください。これにより、OpenShift Container Platform のサービスとインフラストラクチャー Pod が予約済みの 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 による拡張リソースの要件により、リクエストと制限の値は同じになります。ただし、ワークロードパーティショニングによって変更されたアノテーションは、必要な制限を正しく反映します。

注記

拡張リソースはオーバーコミットできないため、コンテナー仕様にリクエストと制限の両方が存在する場合は、リクエストと制限が等しくなければなりません。

20.1. ワークロードパーティショニングの有効化

クラスター管理 Pod を特定の CPU アフィニティーに分割するには、ワークロードパーティショニングを有効にします。この設定により、管理 Pod はパフォーマンスプロファイルで定義された予約済み CPU 制限内で動作することが保証され、お客様ワークロード用に割り当てられたリソースを消費することが防止されます。

プラットフォーム用に確保する CPU コア数を計算する際には、ワークロードパーティショニングを使用するインストール後の Operator についても考慮してください。

ワークロード分割は、標準の Kubernetes スケジューリング機能を使用して、ユーザーワークロードをプラットフォームワークロードから分離します。

注記

ワークロードパーティショニングを有効にできるのは、クラスターのインストール時のみです。インストール後にワークロードパーティショニングを無効にすることはできません。ただし、予約済み CPU および 分離済み CPU の CPU 設定は、インストール後に変更できます。

この手順は、クラスター全体でワークロードのパーティショニングを有効にする方法を示しています。

手順

  • install-config.yaml ファイルに、追加フィールド cpuPartitioningMode を追加し、それを AllNodes に設定します。

    apiVersion: v1
    baseDomain: devcluster.openshift.com
    cpuPartitioningMode: AllNodes
    compute:
      - architecture: amd64
        hyperthreading: Enabled
        name: worker
        platform: {}
        replicas: 3
    controlPlane:
      architecture: amd64
      hyperthreading: Enabled
      name: master
      platform: {}
      replicas: 3
    • cpuPartitioningMode: インストール時に CPU パーティショニング用に設定するクラスターを指定します。デフォルト値は None で、インストール時に CPU パーティショニングが有効にならないことを保証します。

20.2. パフォーマンスプロファイルとワークロードパーティショニング

ワークロードパーティショニングを有効にするには、パフォーマンスプロファイルを適用します。この設定では、分離された CPU と予約済みの CPU を指定し、お客様ワークロードがプラットフォームプロセスによる中断を受けることなく、専用コア上で実行されるようにします。

適切に設定されたパフォーマンスプロファイルは、isolated および reserved CPU を指定します。Performance Profile Creator (PPC) ツールを使用してパフォーマンスプロファイルを作成します。

パフォーマンスプロファイル設定のサンプル

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

Expand
表20.1 シングルノード OpenShift クラスターの PerformanceProfile CR オプション
PerformanceProfile CR フィールド説明

metadata.name

name が、関連する GitOps ZTP カスタムリソース (CR) に設定されている次のフィールドと一致していることを確認してください。

  • TunedPerformancePatch.yamlinclude=openshift-node-performance-${PerformanceProfile.metadata.name}
  • validatorCRs/informDuValidator.yamlname: 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) を設定します。
  • nodehugepages が割り当てられた NUMA ノード (node) に設定します。

spec.realTimeKernel

リアルタイムカーネルを使用するには、enabledtrue に設定します。

spec.workloadHints

workloadHints を使用して、各種ワークロードの最上位フラグのセットを定義します。この例では、クラスターが低レイテンシーかつ高パフォーマンスになるように設定されています。

第21章 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 のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

21.1. Node Observability Operator のワークフロー

次のワークフローは、Node Observability Operator を使用してプロファイリングデータをクエリーする方法の概要を示しています。

  1. Node Observability Operator を OpenShift Container Platform クラスターにインストールします。
  2. NodeObservability カスタムリソースを作成して、選択したワーカーノードで CRI-O プロファイリングを有効にします。
  3. プロファイリングクエリーを実行して、プロファイリングデータを生成します。

21.2. Node Observability Operator のインストール

Node Observability Operator は、デフォルトでは OpenShift Container Platform にインストールされていません。OpenShift Container Platform CLI または Web コンソールを使用して、Node Observability Operator をインストールできます。

21.2.1. CLI を使用した Node Observability Operator のインストール

OpenShift CLI(oc) を使用して、Node Observability Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 次のコマンドを実行して、Node Observability Operator が使用可能であることを確認します。

    $ oc get packagemanifests -n openshift-marketplace node-observability-operator

    出力例

    NAME                            CATALOG                AGE
    node-observability-operator     Red Hat Operators      9h

  2. 次のコマンドを実行して、node-observability-operator namespace を作成します。

    $ oc new-project node-observability-operator
  3. OperatorGroup オブジェクト YAML ファイルを作成します。

    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 にサブスクライブします。

    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. 次のコマンドを実行して、インストールプラン名を表示します。

    $ oc -n node-observability-operator get sub node-observability-operator -o yaml | yq '.status.installplan.name'

    出力例

    install-dt54w

  2. 次のコマンドを実行して、インストールプランのステータスを確認します。

    $ oc -n node-observability-operator get ip <install_plan_name> -o yaml | yq '.status.phase'

    <install_plan_name> は、前のコマンドの出力から取得したインストール計画名です。

    出力例

    COMPLETE

  3. Node Observability Operator が稼働していることを確認します。

    $ oc get deploy -n node-observability-operator

    出力例

    NAME                                            READY   UP-TO-DATE  AVAILABLE   AGE
    node-observability-operator-controller-manager  1/1     1           1           40h

21.2.2. Web コンソールを使用した Node Observability Operator のインストール

Node Observability Operator は、OpenShift Container Platform コンソールからインストールできます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. 管理者のナビゲーションパネルで、OperatorsOperatorHub をデプロイメントします。
  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. 管理者のナビゲーションパネルで、OperatorsInstalled Operators をデプロイメントします。
  2. Node Observability Operator が Operators リストにリストされていることを確認します。

CRI-O および Kubelet プロファイリングデータの収集に使用する、Node Observability カスタムリソースを作成します。

21.3.1. Node Observability カスタムリソースの作成

プロファイリングクエリーを実行する前に、NodeObservability カスタムリソース (CR) を作成して実行する必要があります。一致する NodeObservability CR を実行すると、必要なマシン設定およびマシン設定プール CR が作成され、nodeSelector に一致するワーカーノードで CRI-O プロファイリングを有効にします。

重要

ワーカーノードで CRI-O プロファイリングが有効になっていない場合、NodeObservabilityMachineConfig リソースが作成されます。NodeObservability CR で指定された nodeSelector に一致するワーカーノードが再起動します。完了するまでに 10 分以上かかる場合があります。

注記

Kubelet プロファイリングはデフォルトで有効になっています。

ノードの CRI-O unix ソケットは、エージェント Pod にマウントされます。これにより、エージェントは CRI-O と通信して pprof 要求を実行できます。同様に、kubelet-serving-ca 証明書チェーンはエージェント Pod にマウントされ、エージェントとノードの kubelet エンドポイント間の安全な通信を可能にします。

前提条件

  • Node Observability Operator をインストールしました。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform CLI にログインします。

    $ oc login -u kubeadmin https://<HOSTNAME>:6443
  2. 次のコマンドを実行して、node-observability-operator namespace に切り替えます。

    $ oc project node-observability-operator
  3. 次のテキストを含む nodeobservability.yaml という名前の CR ファイルを作成します。

        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 を実行します。

    oc apply -f nodeobservability.yaml

    出力例

    nodeobservability.olm.openshift.io/cluster created

  5. 次のコマンドを実行して、NodeObservability CR のステータスを確認します。

    $ oc get nob/cluster -o yaml | yq '.status.conditions'

    出力例

    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 のときに完了します。

21.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 リソースファイルを作成します。

    apiVersion: nodeobservability.olm.openshift.io/v1alpha2
    kind: NodeObservabilityRun
    metadata:
      name: nodeobservabilityrun
    spec:
      nodeObservabilityRef:
        name: cluster
  2. NodeObservabilityRun リソースを実行して、プロファイリングクエリーをトリガーします。

    $ oc apply -f nodeobservabilityrun.yaml
  3. 次のコマンドを実行して、NodeObservabilityRun のステータスを確認します。

    $ oc get nodeobservabilityrun nodeobservabilityrun -o yaml  | yq '.status.conditions'

    出力例

    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 パスからプロファイリングデータを取得します。

    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

21.4. Node Observability Operator スクリプト

スクリプトを作成すると、現在の Node Observability Operator および Node Observability Agent を使用して、事前設定された bash スクリプトを実行できます。

これらのスクリプトは、CPU 負荷、メモリーの逼迫、ワーカーノードの問題などの主要なメトリクスを監視します。sar レポートとカスタムパフォーマンスメトリクスも収集します。

21.4.1. スクリプト用のノード監視カスタムリソースを作成する

スクリプトを実行する前に、NodeObservability カスタムリソース (CR) を作成して実行する必要があります。NodeObservability CR を実行すると、nodeSelector ラベルに一致するコンピュートノード上でエージェントがスクリプトモードで有効になります。

前提条件

  • Node Observability Operator をインストールしました。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform クラスターにログインします。

    $ oc login -u kubeadmin https://<host_name>:6443
  2. 次のコマンドを実行して、node-observability-operator namespace に切り替えます。

    $ oc project node-observability-operator
  3. 次の内容を含む nodeobservability.yaml という名前のファイルを作成します。

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

    $ oc apply -f nodeobservability.yaml

    出力例

    nodeobservability.olm.openshift.io/cluster created

  5. 次のコマンドを実行して、NodeObservability CR のステータスを確認します。

    $ oc get nob/cluster -o yaml | yq '.status.conditions'

    出力例

    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 の実行は、reasonReadystatus"True". の場合に完了します。

21.4.2. Node Observability Operator スクリプトの設定

前提条件

  • Node Observability Operator をインストールしました。
  • NodeObservability カスタムリソース (CR) を作成しました。
  • cluster-admin 権限でクラスターにアクセスできる。

手順

  1. 次の内容を含む、nodeobservabilityrun-script.yaml という名前のファイルを作成します。

    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 リソースを作成することで、スクリプトをトリガーします。

    $ oc apply -f nodeobservabilityrun-script.yaml
  3. 次のコマンドを実行して、NodeObservabilityRun スクリプトのステータスを確認します。

    $ oc get nodeobservabilityrun nodeobservabilityrun-script -o yaml  | yq '.status.conditions'

    出力例

    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

    StatusTrueTypeFinished になると、スクリプトの作成は完了です。

  4. 次の bash スクリプトを実行して、コンテナーのルートパスからスクリプトデータを取得します。

    #!/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
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る