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

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

OpenShift Container Platform 4.20

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

概要

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

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

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

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

注記

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

1.1. パフォーマンスとスケーラビリティの推奨プラクティス
リンクのコピー

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

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

1.2. 通信事業者リファレンス設計仕様
リンクのコピー

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

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

1.3. 計画、最適化、測定
リンクのコピー

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

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

Node Tuning Operator の使用

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

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

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

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

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

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

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

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

Node Observability Operator の使用

第2章 パフォーマンスとスケーラビリティの推奨プラクティス
リンクのコピー

2.2. コントロールプレーンマシン用に、より大きな AWS インスタンスタイプを選択する
リンクのコピー

Amazon Web Services (AWS) クラスター内のコントロールプレーンマシンがより多くのリソースを必要とする場合は、コントロールプレーンマシンが使用するより大きな AWS インスタンスタイプを選択できます。

注記

コントロールプレーンマシンセットを使用するクラスターの手順は、コントロールプレーンマシンセットを使用しないクラスターの手順とは異なります。

クラスター内の ControlPlaneMachineSet CR の状態が不明な場合は、CR の状態を確認できます。

コントロールプレーンマシンセットのカスタムリソース (CR) の仕様を更新することで、コントロールプレーンマシンが使用する Amazon Web Services (AWS) インスタンスタイプを変更できます。

前提条件

  • AWS クラスターは、コントロールプレーンマシンセットを使用します。

手順

  1. providerSpec フィールドの下で以下の行を編集します。 

    providerSpec:
  value:
    ...
    instanceType: <compatible_aws_instance_type>
    • <compatible_aws_instance_type>: 前の選択と同じベースを持つ、より大きな AWS インスタンスタイプを指定します。たとえば、m6i.xlarge を m6i.2xlarge または m6i.4xlarge に変更できます。
  2. 変更を保存します。

2.2.3. AWS コンソールを使用して Amazon Web Services インスタンスタイプを変更する
リンクのコピー

AWS コンソールでインスタンスタイプを更新することにより、コントロールプレーンマシンが使用するアマゾンウェブサービス (AWS) インスタンスタイプを変更できます。

前提条件

  • クラスターの EC2 インスタンスを変更するために必要なアクセス許可を持つ AWS コンソールにアクセスできます。
  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできます。

手順

  1. AWS コンソールを開き、コントロールプレーンマシンのインスタンスを取得します。

  2. コントロールプレーンマシンインスタンスを 1 つ選択します。

    1. 選択したコントロールプレーンマシンについて、etcd スナップショットを作成して etcd データをバックアップします。詳細は、「etcd のバックアップ」を参照してください。
    2. AWS コンソールで、コントロールプレーンマシンインスタンスを停止します。
    3. 停止したインスタンスを選択し、Actions → Instance Settings → Change instance type をクリックします。
    4. インスタンスをより大きなタイプに変更し、タイプが前の選択と同じベースであることを確認して、変更を適用します。たとえば、m6i.xlarge を m6i.2xlarge または m6i.4xlarge に変更できます。
    5. インスタンスを起動します。
    6. OpenShift Container Platform クラスターにインスタンスに対応する Machine オブジェクトがある場合、AWS コンソールで設定されたインスタンスタイプと一致するようにオブジェクトのインスタンスタイプを更新します。
  3. コントロールプレーンマシンごとにこのプロセスを繰り返します。

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

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

3.1. 通信事業者コア RDS 4.20 使用モデルの概要
リンクのコピー

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

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

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

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

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

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

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

3.3. リファレンス設計の範囲
リンクのコピー

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

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

注記

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

3.4. リファレンス設計からの逸脱
リンクのコピー

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

重要

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

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

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

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

    注記

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

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

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

クラスタートポロジー

通信事業者コアリファレンス設計は、次の 2 つの異なるクラスター設定バリアントをサポートしています。

  • スケジュール不可能なコントロールプレーン。このバリアントでは、ユーザーワークロードをマスターノード上で実行することが厳密に禁止されています。

  • スケジュール可能なコントロールプレーン。このバリアントでは、リソース使用率を最適化するために、ユーザーワークロードをマスターノード上で実行することが許可されます。このバリアントはベアメタルコントロールプレーンノードにのみ適用され、インストール時に設定する必要があります。

    バリアントに関係なく、すべてのクラスターは次の要件に準拠する必要があります。

  • 3 つ以上のノードで構成される可用性の高いコントロールプレーン。
  • 複数のマシン設定プールを使用すること。
ストレージ
通信事業者コアのユースケースでは、外部ストレージソリューションによって提供される可用性の高い永続ストレージが必要です。外部ストレージへのアクセスを管理するために OpenShift Data Foundation が使用される場合があります。
ネットワーク

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

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

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

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

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

3.6. デプロイ計画
リンクのコピー

MachineConfigPools (MCP) カスタムリソース (CR) を使用すると、お客様の計画のパラメーターに基づいて、通信事業者コアクラスター内のワーカーノードを別々のノードグループに分割できます。デプロイとアップグレードの時間を最小限に抑えるには、そして何よりもクラスターのアップグレード中に通信事業者グレードのサービスが中断されるの最小限に抑えるには、MCP を使用した慎重なデプロイ計画が欠かせません。

説明

通信事業者コアクラスターは、MachineConfigPools (MCP) を使用して、たとえばハードウェアプロファイルの違いに応じて、ワーカーノードをさらに個別の役割に分割できます。これは各役割のカスタムチューニングを可能にするだけでなく、通信事業者コアクラスターのデプロイやアップグレードを高速化するうえでも重要な役割を果たします。複数の MCP を使用すると、1 つまたは複数のメンテナンス期間にわたってクラスターのアップグレードを適切に計画できます。これは非常に重要です。計画が慎重に策定されていないと、通信事業者グレードのサービスが影響を受ける可能性があるためです。

クラスターをアップグレードする際には、コントロールプレーンのアップグレード中に MCP を一時停止できます。詳細は、「カナリアロールアウト更新の実行」を参照してください。これにより、MCP の一時停止が解除されるまで、ワーカーノードが再起動されず、実行中のワークロードが影響を受けなくなります。

慎重な MCP 計画を使用することで、ノードセットのアップグレードのタイミングと順序をいつでも制御できます。MCP を使用して通信事業者クラスターのアップグレードを計画する方法の詳細は、「更新前にノードに MachineConfigPool ラベルを適用する」を参照してください。

最初のデプロイを開始する前に、MCP に関する次のエンジニアリング上のに関する考慮事項に留意してください。

PerformanceProfile と Tuned プロファイルの関連付け:

PerformanceProfiles を使用する場合は、各 Machine Config Pool (MCP) を 1 つの PerformanceProfile 定義または Tuned プロファイル定義にリンクする必要があることに注意してください。したがって、複数の MCP で必要な設定が同じである場合も、各 MCP に専用の PerformanceProfile 定義が必要です。

MCP のラベル付けストラテジーの計画:

次のような要因に応じて、ワーカーノードを分割するための適切なストラテジーを使用して、MCP のラベル付けを計画してください。

  • ワーカーノードのタイプ: 同じハードウェアプロファイルを持つノードのグループを指定します。たとえば、コントロールプレーンのネットワーク機能 (NF) 用のワーカーや、ユーザーデータプレーンの NF 用のワーカーなどです。
  • ワーカーノードタイプごとのワーカーノードの数。
  • 同じハードウェアプロファイルに必要な MCP の最小数は 1 です。ただし、大規模なクラスターの場合は、それよりも多くなる可能性があります。たとえば、各ステップで影響を受けるクラスター容量の割合を小さくし、よりきめ細かいアップグレードをサポートするために、ハードウェアプロファイルごとに、より多くの MCP を設計することができます。

  • MCP 内のノードの更新ストラテジーは、アップグレード要件と選択した maxUnavailable 値によって決まります。

    • 許可されるメンテナンス期間の数。
    • メンテナンス期間の長さ。
    • ワーカーノードの合計数。
    • MCP に必要な maxUnavailable (同時に更新されるノードの数)。

  • 以下の点に関連する、ワーカーノードの CNF 要件:

    • アップグレード中に必要な Pod ごとの最小可用性。これは Pod Disruption Budget (PDB) を使用して設定します。PDB は、アップグレード中に通信事業者のサービスレベルアグリーメント (SLA) を維持するために不可欠です。PDB の詳細は、「起動している必要がある Pod の数を Pod Disruption Budget を使用して指定する方法について」を参照してください。
    • Pod ごとに必要な真の最低限の高可用性。これにより、各レプリカが別々のハードウェア上で稼働するようにします。
    • Pod のアフィニティーおよびアンチアフィニティーのリンク: Pod のアフィニティーとアンチアフィニティーの使用方法に関する詳細は、「アフィニティールールとアンチアフィニティールールを使用して、他の Pod を基準にして Pod を配置する」を参照してください。
  • アップグレードメンテナンス期間の長さと数。これは通信事業者グレードのサービスに影響を与える可能性があります。

3.7. ゾーン
リンクのコピー

高可用性 (HA) を確保し、アップグレード時間を短縮するには、複数のノードの同時中断に対応するようにクラスターを設計することが不可欠です。OpenShift Container Platform と Kubernetes は、よく知られたラベル topology.kubernetes.io/zone を使用して、共通の障害ドメインの影響を受けるノードのプールを作成します。トポロジー (アベイラビリティー) ゾーン用にノードにアノテーションを付けることにより、高可用性ワークロードを分散させることができます。その結果、各ゾーンが HA のためにレプリケートされた Pod のセットからレプリカを 1 つだけ保持するようになります。この分散により、1 つのゾーンが失われても HA の制約に違反せず、最小限のサービス可用性が維持されます。OpenShift Container Platform および Kubernetes は、すべてのレプリカ構成要素 (Service、ReplicaSet、StatefulSet、または ReplicationController) に対して、デフォルトの TopologySpreadConstraint を適用します。この制約は、topology.kubernetes.io/zone ラベルに基づいてレプリカを分散させます。このようなデフォルト動作により、ワークロード Pod の仕様を変更することなく、ゾーンベースの分散を適用できます。

通常、クラスターのアップグレードでは、基盤となる OS が更新されるため、ノードの中断が発生します。大規模なクラスターでは、アップグレードを迅速に、できるだけ少ないメンテナンス期間中に完了するために、複数のノードを同時に更新する必要があります。ゾーンを使用して Pod の分散を確実にすることで、(十分な予備容量があれば) 高可用性とサービス可用性を維持しながら、ゾーン内のすべてのノードに同時にアップグレードを適用できます。推奨されるクラスター設計は、前述の考慮事項に基づいてノードを複数の MCP に分割し、1 つの MCP 内のすべてのノードに、他の MCP に割り当てられたゾーンとは区別される単一のゾーンとしてラベル付けすることです。この方法を使用すると、MCP 内のすべてのノードを同時に更新できます。

ライフサイクルフック (readiness、liveness、startup、および pre-stop) は、アプリケーションの可用性を確保するうえで重要な役割を果たします。特にアップグレードの場合、pre-stop フックにより、アプリケーションはノードから退避させられる前に、中断に備えるための必要な手順を実行できます。

制限と要件
  • デフォルトの TopologySpreadConstraints (TSC) は、明示的な TSC が指定されていない場合にのみ適用されます。Pod に明示的な TSC がある場合は、ゾーンベースの分散を必ず適用してください。
  • クラスターには、MCP の同時更新に耐えられるだけの十分な予備容量が必要です。十分にない場合は、MCP の maxUnavailable を 100% 未満に設定する必要があります。
  • MCP 内のすべてのノードを同時に更新できるかどうかは、さらに、ワークロードの設計と、そのレベルの中断が発生しても要求されるサービスレベルを維持できるかどうかよって決まります。
エンジニアリングに関する考慮事項
  • Pod の drain (Pod の退避) 時間がノードの更新時間に大きな影響を与える可能性があります。Pod の迅速な drain が可能なワークロード設計を確保してください。

  • 高可用性要件を強制するには、PodDisruptionBudgets (PDB) を使用します。

    • アプリケーションの継続的な可用性を保証するには、クラスター設計で、ワークロードの Pod を分散するのに十分な数の個別のゾーンを使用する必要があります。

      • Pod が十分な数のゾーンに分散されている場合、1 つのゾーンが失われても、Pod Disruption Budget (PDB) で許可されているよりも多くの Pod がダウンすることはありません。
      • ゾーン数が少なすぎるか、スケジューリング制約が厳しいために Pod が適切に分散されていない場合、ゾーン障害によって PDB 違反が発生し、結果としてサービス停止が発生します。
      • さらに、この不十分な分散により、通常は並行して実行されるアップグレードが、PDB 違反を回避するためにゆっくりと順番に (部分的に逐次的に) 実行せざるを得なくなり、メンテナンス時間が大幅に長くなる可能性があります。
    • PDB の中断許容 Pod 数が 0 に設定されている場合、ノードの drain がブロックされ、管理者の介入が必要になります。高速かつ自動的なアップグレードの場合は、このパターンを避ける必要があります。

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

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

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

    • 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 でサポートされている場合)。
    • Intel Sierra Forest CPU (OpenShift Container Platform でサポートされている場合)。
    • ワーカーノードで IRQ バランシングを有効にします。PerformanceProfile CR は globallyDisableIrqLoadBalancing パラメーターの値を false に設定します。Guaranteed QoS Pod には、「CPU のパーティショニングとパフォーマンスチューニング」の説明のとおり、分離を実現するためのアノテーションが付けられます。

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

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

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

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

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

    • コントロールプレーンとワーカーノードの予約済み CPU の最小数は、NUMA ノードあたり 2 CPU (4 ハイパースレッド) です。
    • DPDK 以外のネットワークトラフィックに使用する NIC は、最大 32 個の RX/TX キューを使用するように設定する必要があります。

    • 多数の Pod やその他のリソースを持つノードでは、追加の予約済み CPU が必要になる場合があります。残りの CPU はユーザーのワークロードに使用できます。

      注記

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

3.8.1. アプリケーションワークロード
リンクのコピー

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

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

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

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

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

  • OpenShift Container Platform 4.19 以降、cgroup v1 がサポートされなくなり、削除されました。すべてのワークロードに cgroup v2 との互換性がある必要があります。詳細は、Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads を参照してください。
  • CNF アプリケーションを、最新バージョンの Red Hat Best Practices for Kubernetes に準拠させる必要があります。

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

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

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

    • CNF が CPU ピニングを使用する場合は、exec プローブを使用しないでください。httpGet や tcpSocket などの他のプローブ実装を使用します。
    • exec プローブを使用する必要がある場合は、exec プローブの頻度と量を制限します。exec プローブの最大数は 10 未満に維持し、頻度は 10 秒以上にする必要があります。
    • startup プローブは、安定状態の動作時には大量のリソースを使用しないため、使用できます。exec プローブの制限は、主に liveness および readiness プローブに適用されます。exec プローブはプロセスのフォークを必要とするため、他のプローブタイプと比較して管理コアの CPU 使用率が大幅に高くなります。
  • アップグレードやノードのメンテナンス中など、Pod が中断される前にアプリケーションワークロードが必要な操作を実行できるようにするには、pre-stop フックを使用します。このフックを使用すると、Pod が状態を永続ストレージに保存したり、サービスからトラフィックをオフロードしたり、他の Pod にシグナルを送信したりできるようになります。

3.8.2. シグナリングワークロード
リンクのコピー

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

3.9. 通信事業者コア RDS のコンポーネント
リンクのコピー

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

3.9.1. CPU パーティショニングとパフォーマンスチューニング
リンクのコピー

このリリースの変更点
  • RPS の無効化 - Pod ネットワークのリソース使用量をアプリケーション CPU で考慮
  • スケジュール可能なコントロールプレーンノード上のコントロールプレーンの分離強化
  • NUMA Resources Operator におけるスケジュール可能なコントロールプレーンのサポート
  • 通信事業者コアクラスターのアップグレードに関する追加のガイダンス
説明
CPU パーティショニングは、機密性の高いワークロードを、汎用タスク、割り込み、およびドライバー作業キューから分離することで、パフォーマンスを向上させ、レイテンシーを削減します。このような補助的なプロセスに割り当てられた CPU のことを、次のセクションでは 予約済み CPU と呼びます。ハイパースレッディングが有効なシステムでは、CPU は 1 つのハイパースレッドになります。
制限と要件

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

    • ユーザープレーンネットワークアプリケーション (DPDK) のみを備えたシステムでは、オペレーティングシステムとインフラストラクチャーコンポーネント用に、少なくとも 1 つのコア (ハイパースレッディングが有効な場合は 2 つのハイパースレッド) が予約されている必要があります。
  • ハイパースレッディングが有効なシステムでは、コアシブリングスレッドが常に同じ CPU プール内にある必要があります。
  • 予約済みコアと分離されたコアのセットには、すべての CPU コアが含まれている必要があります。
  • 各 NUMA ノードのコア 0 は、予約済み CPU セットに含める必要があります。
  • 低レイテンシーのワークロードでは、割り込み、カーネルスケジューラー、またはプラットフォームの他の部分による影響を受けないように特別な設定が必要です。

詳細は、「パフォーマンスプロファイルの作成」を参照してください。

エンジニアリングに関する考慮事項
  • OpenShift 4.19 以降、cgroup v1 がサポートされなくなり、削除されました。すべてのワークロードに cgroup v2 との互換性がある必要があります。詳細は、Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads を参照してください。
  • 必要な最小予約容量 (systemReserved) については、Which amount of CPU and memory are recommended to reserve for the system in OCP 4 nodes? のガイダンスに従ってください。
  • スケジュール可能なコントロールプレーンの場合、推奨される最小予約容量は少なくとも 16 個の CPU です。
  • 実際に必要な予約済み CPU 容量は、クラスターの設定とワークロードの属性によって異なります。
  • 予約済み CPU の値は、フルコア (2 ハイパースレッド) に合わせて切り上げる必要があります。
  • CPU パーティショニングを変更すると、関連するマシン設定プールに含まれるノードが drain され、再起動されます。
  • 予約済み CPU は Pod 密度を低下させます。予約済み CPU は、OpenShift Container Platform ノードの割り当て可能な容量から削除されるためです。

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

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

  • コア数の多いシステムでは、irdma カーネルモジュールが原因で、割り込みベクトルの割り当てが多くなりすぎる可能性があります。この状態を防ぐために、リファレンス設定では、PerformanceProfile リソースのカーネルコマンドライン引数によるこのカーネルモジュールの読み込みを除外します。通常、コアワークロードではこのカーネルモジュールは必要ありません。

    注記

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

3.9.2. スケジュール可能なコントロールプレーン上のワークロード
リンクのコピー

コントロールプレーンノードでのワークロードの有効化

スケジュール可能なコントロールプレーンを有効にすると、コントロールプレーンノードでワークロードを実行し、ベアメタルマシン上のアイドル状態の CPU 容量を活用してコストを削減できます。この機能は、ベアメタルコントロールプレーンノードを持つクラスターにのみ適用されます。

この機能には 2 つの異なる要素があります。

  1. コントロールプレーンノードでのワークロードの許可: この機能は、クラスターの初期インストール後に設定できます。そのため、コントロールプレーンノードでワークロードを実行する必要がある場合に有効にできます。
  2. ワークロードパーティショニングの有効化: これは、コントロールプレーンを通常のワークロードによる干渉から保護し、クラスターの安定性と信頼性を確保するための重要な分離手段です。ワークロードパーティショニングは、"Day 0" のクラスターの初期インストール時に設定する必要があり、後で有効にすることはできません。

コントロールプレーンノードでワークロードを実行する予定の場合は、まず初期セットアップ時にワークロードパーティショニングを有効にする必要があります。その後、スケジュール可能なコントロールプレーン機能を有効にできます。

ワークロードの特性と制限

アプリケーションがコアクラスターの機能に干渉しないことを確認するために、ワークロードをテストして検証する必要があります。CPU やネットワークに大きな負荷をかけない軽量のコンテナーから始めることを推奨します。

特定のワークロードは、クラスタの安定性に対するリスクがあるため、コントロールプレーンノード上での実行が許可されていません。これには、カーネル引数またはシステムのグローバル sysctl を再設定するワークロードが含まれます。このようなワークロードにより、クラスターに予期しない結果が生じる可能性があるためです。

安定性を確保するには、以下を遵守する必要があります。

  • すべての主要なワークロードに、必ずメモリー制限を定義してください。これにより、メモリーリークが発生した場合もコントロールプレーンが保護されます。
  • exec プローブを頻繁に使用するなどして、予約済みの CPU に過度の負荷をかけないようにしてください。
  • カーネルベースのネットワークを多用することは避けてください。OVS などのソフトウェアネットワークコンポーネントにより、予約済み CPU の負荷が増加する可能性があるためです。
NUMA Resources Operator のサポート
NUMA Resources Operator は、コントロールプレーンノードでの使用がサポートされています。Operator の機能上の動作は変わりません。

3.9.3. Service Mesh
リンクのコピー

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

3.9.4. ネットワーク
リンクのコピー

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

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

通信事業者コアリファレンス設計のネットワーク設定の概要
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
注記

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

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

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

    1. NodeNetworkConfigurationPolicy CR を使用して、ノード上の VLAN インターフェイスと特定のカーネル IP ルートを設定します。
    2. VLAN ごとに MetalLB BGPPeer CR を作成して、リモート BGP ルーターとのピアリングを確立します。
    3. MetalLB BGPAdvertisement CR を定義して、選択した BGPPeer リソースのリストにアドバタイズする IP アドレスプールを指定します。次の図は、特定のサービス IP アドレスを、特定の VLAN インターフェイスを介して外部にアドバタイズする方法を示しています。サービスルートは、BGPAdvertisement CR で定義され、IPAddressPool1 および BGPPeer1 フィールドの値を使用して設定されます。

図3.3 通信事業者コアリファレンス設計の MetalLB サービス分離

通信事業者コアリファレンス設計の MetalLB サービス分離
3.9.4.1. Cluster Network Operator
リンクのコピー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

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

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

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

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

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

  • 代替の NIC 設定としては、共有 NIC を複数の NIC に分割したり、単一のデュアルポート NIC を使用したりすることが考えられます。ただし、これらはテストおよび検証されていません。
  • シングルスタック IP 設定のクラスターは検証されていません。

  • EgressIP

    • EgressIP のフェイルオーバー時間は、Network CR の reachabilityTotalTimeoutSeconds パラメーターによって決まります。このパラメーターは、選択された Egress ノードに到達できないことを検出するために使用されるプローブの頻度を決定します。このパラメーターの推奨値は 1 秒です。
    • EgressIP が複数の Egress ノードで設定されている場合、フェイルオーバー時間が数秒以上になることが予想されます。
    • 追加のネットワークインターフェイスを持つノードでは、EgressIP トラフィックは、EgressIP アドレスが割り当てられているインターフェイスを介して送信されます。「Egress IP アドレスの設定」を参照してください。
  • Pod レベルの SR-IOV ボンディングモードを active-backup に設定し、miimon の値を設定する必要があります (100 を推奨)。
エンジニアリングに関する考慮事項
  • Pod の Egress トラフィックは、routingViaHost オプションを使用してカーネルルーティングテーブルによって管理されます。ホストに適切な静的ルートを設定する必要があります。
3.9.4.2. ロードバランサー
リンクのコピー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
重要

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

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

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

    • アドレス、アグリゲーション長、自動割り当てなどのバリエーションを使用してアドレスプールを設定できます。
    • MetalLB はルートのアナウンスにのみ BGP を使用します。このモードでは、transmitInterval および minimumTtl パラメーターのみが関連します。BFD プロファイル内の他のパラメーターは、デフォルトに近い値にしておく必要があります。値を短くすると、検出漏れが発生し、パフォーマンスに影響する可能性があるためです。
3.9.4.3. SR-IOV
リンクのコピー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
SR-IOV を使用すると、Physical Function (PF) を複数の Virtual Function (VF) に分割できます。その後、VF を複数の Pod に割り当てることで、Pod を分離したまま、より高いスループットパフォーマンスを実現できます。SR-IOV Network Operator は、SR-IOV CNI、ネットワークデバイスプラグイン、および SR-IOV スタックのその他のコンポーネントをプロビジョニングおよび管理します。
制限と要件
  • 特定のネットワークインターフェイスだけがサポートされています。詳細は、「サポートされるデバイス」を参照してください。
  • SR-IOV と IOMMU の有効化: SR-IOV Network Operator により、カーネルコマンドラインで IOMMU が自動的に有効化されます。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウンの検出が必要な場合は、プロトコルレベルで実行する必要があります。
  • MultiNetworkPolicy CR は、netdevice ネットワークにのみ適用できます。これは、vfio インターフェイスを管理できない iptables が実装で使用されるためです。
エンジニアリングに関する考慮事項
  • vfio モードの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーション用に追加のセカンダリーネットワークを有効にするために使用されます。
  • SriovOperatorConfig CR を明示的に作成する必要があります。この CR はリファレンス設定ポリシーに含まれているため、初期デプロイ時に作成されます。
  • UEFI セキュアブートまたはカーネルロックダウンを使用したファームウェア更新をサポートしていない NIC は、アプリケーションワークロードに必要な数の Virtual Function (VF) をサポートするために、十分な数の VF を有効にして事前設定する必要があります。Mellanox NIC の場合、SR-IOV Network Operator で Mellanox ベンダープラグインを無効にする必要があります。詳細は、「SR-IOV ネットワークデバイスの設定」を参照してください。
  • Pod の起動後に VF の MTU 値を変更する場合、SriovNetworkNodePolicy の MTU フィールドを設定しないでください。代わりに、Kubernetes NMState Operator を使用して、関連する PF の MTU を設定してください。
3.9.4.4. NMState Operator
リンクのコピー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Kubernetes NMState Operator は、クラスターノード全体でステートドリブンのネットワーク設定を実行するための Kubernetes API を提供します。これにより、ネットワークインターフェイス設定、静的 IP と DNS、VLAN、トランク、ボンディング、静的ルート、MTU、およびセカンダリーインターフェイスでの無差別モードの有効化が可能になります。クラスターノードは、各ノードのネットワークインターフェイスの状態を API サーバーに定期的に報告します。
制限と要件
該当なし
エンジニアリングに関する考慮事項
  • 初期ネットワーク設定は、インストール CR の NMStateConfig コンテンツを使用して適用されます。NMState Operator は、ネットワーク更新に必要な場合にのみ使用されます。
  • SR-IOV の Virtual Function がホストネットワークに使用される場合、NMState Operator (nodeNetworkConfigurationPolicy CR) を使用して、VLAN や MTU などの VF インターフェイスが設定されます。

3.9.5. ロギング
リンクのコピー

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

3.9.6. 電源管理
リンクのコピー

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

3.9.7. ストレージ
リンクのコピー

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

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

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

注記

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

3.9.7.1. OpenShift Data Foundation
リンクのコピー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

OpenShift Data Foundation は、コンテナー向けのソフトウェア定義ストレージサービスです。OpenShift Data Foundation は、次のどちらかのモードでデプロイできます。

  • 内部モード: OpenShift Data Foundation のソフトウェアコンポーネントが、他のコンテナー化されたアプリケーションとともに、OpenShift Container Platform クラスターノード上にソフトウェアコンテナーとして直接デプロイされます。
  • 外部モード: OpenShift Data Foundation は専用のストレージクラスター (通常は Red Hat Enterprise Linux (RHEL) 上で実行される別の Red Hat Ceph Storage クラスター) にデプロイされます。

これらのストレージサービスは、アプリケーションワークロードクラスターの外部で実行されます。

通信事業者コアクラスターの場合、ストレージのサポートは、次の理由により、外部モードで実行される OpenShift Data Foundation ストレージサービスによって提供されます。

  • OpenShift Container Platform の操作と Ceph の操作間の依存関係を分離することで、OpenShift Container Platform と OpenShift Data Foundation を独立して更新できます。
  • 通信事業者コアのユースケースでは、ストレージと OpenShift Container Platform インフラストラクチャー層の操作機能を分離することが、お客様の要件として一般的に求められています。
  • 外部の Red Hat Ceph Storage クラスターは、同じリージョンにデプロイされた複数の OpenShift Container Platform クラスターで再利用できます。

OpenShift Data Foundation は、セカンダリー CNI ネットワークを使用したストレージトラフィックの分離をサポートします。

制限と要件
  • IPv4/IPv6 デュアルスタックネットワーク環境では、OpenShift Data Foundation は IPv4 アドレスを使用します。詳細は、IPv6 サポート を参照してください。
エンジニアリングに関する考慮事項
  • OpenShift Data Foundation ネットワークトラフィックは、VLAN 分離などを使用して、専用ネットワーク上の他のトラフィックから分離する必要があります。
  • 十分なスループット、帯域幅、およびパフォーマンス KPI を確保するために、複数の OpenShift Container Platform クラスターを外部の OpenShift Data Foundation クラスターに接続する前に、ワークロード要件のスコープを設定する必要があります。
3.9.7.2. 追加のストレージソリューション
リンクのコピー

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

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

3.9.8. 通信事業者コアデプロイメントのコンポーネント
リンクのコピー

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

3.9.8.1. Red Hat Advanced Cluster Management
リンクのコピー
このリリースの変更点
  • ポリシーを管理し、マネージドクラスターにデプロイするには、RHACM と PolicyGenerator CR を使用する方法が推奨されます。これは、この目的のために PolicyGenTemplate CR を使用することに代わる方法です。
説明

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

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

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

制限と要件
エンジニアリングに関する考慮事項
  • インストール、サイト、またはデプロイメントごとに固有のコンテンツを持つ複数のクラスターを管理する場合は、RHACM ハブテンプレートを使用することを強く推奨します。RHACM ハブテンプレートを使用すると、インストールごとに固有の値を指定しながら、一貫したポリシーセットをクラスターに適用できます。
3.9.8.2. Topology Aware Lifecycle Manager
リンクのコピー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

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

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

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

    注記

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

  • OpenShift Container Platform、Day-2 OLM Operator、カスタム設定を含むアップグレードのオーケストレーションは、これらの更新を記述するポリシーを含む ClusterGroupUpgrade (CGU) CR を使用して実行できます。

    • EUS から EUS へのアップグレードは、連鎖した CGU CR を使用してオーケストレーションできます。
    • MCP の一時停止の制御は、コントロールプレーンとワーカーノード全体のアップグレードをロールアウトするために、CGU CR のポリシーを通じて管理できます。
3.9.8.3. GitOps Operator および ZTP プラグイン
リンクのコピー
このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

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

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

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

重要

クラスターのインストールには、ZTP プラグイン方式を使用した SiteConfig カスタムリソースよりも ClusterInstance CR を使用する方が推奨されます。

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

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

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

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

    注記

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

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

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

    注記

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

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

3.9.9. モニタリング
リンクのコピー

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

OpenShift Container Platform には Cluster Monitoring Operator (CMO) がデフォルトで含まれています。CMO は、プラットフォームコンポーネントと、必要に応じてユーザープロジェクトのモニタリング (メトリクス、ダッシュボード、アラート) を提供します。管理者は、デフォルトのログ保持期間、カスタムアラートルールなどをカスタマイズできます。

モニタリングスタックの設定は、cluster-monitoring-config ConfigMap 内の単一の文字列値を通じて行われます。このリファレンスチューニングは、以下に示す 2 つの要件の内容を統合したものです。

  • Prometheus 設定は、アラートの集約のためにアラートを ACM ハブクラスターに転送するように拡張されています。必要に応じて、この設定を拡張して追加の場所に転送することもできます。

  • Prometheus の保持期間をデフォルトより短縮します。主要なメトリクスのストレージはクラスターの外部にあることが想定されています。コアクラスター上のメトリクスストレージは、その中央ストアのバックアップとして使用され、またローカルでのトラブルシューティングのために利用可能であることが想定されています。

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

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

3.9.10. スケジューリング
リンクのコピー

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

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

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

制限と要件

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

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

3.9.11. ノード設定
リンクのコピー

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

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

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

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

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

    • sctp
    • ip_gre
    • nf_tables
    • nf_conntrack
    • nft_ct
    • nft_limit
    • nft_log
    • nft_nat
    • nft_chain_nat
    • nf_reject_ipv4
    • nf_reject_ipv6
    • nfnetlink_log

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

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

    Kdump の有効化

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

3.9.12. ホストファームウェアとブートローダーの設定
リンクのコピー

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

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

    注記

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

3.9.13. Kubelet 設定
リンクのコピー

CNF ワークロードによっては、システム全体の安全な sysctl のリストに含まれていない sysctl を使用するものもあります。通常、ネットワーク関連の sysctl は namespace で分離されており、PerformanceProfile 内の kubeletconfig.experimental アノテーションを allowedUnsafeSysctls という形式の JSON 文字列として使用することで有効にできます。

allowedUnsafeSysctls を示すサンプルスニペット

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: {{ .metadata.name }}
  annotations:kubeletconfig.experimental: |
      {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
# ...

注記

これらは namespace で分離されていますが、Pod がその詳細で指定された制限を超えてメモリーやその他のリソースを消費することを許容する可能性があります。これらの sysctl がプラットフォームリソースを使い果たさないようにする必要があります。

3.9.14. 非接続環境
リンクのコピー

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

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

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

3.9.15. Agent-based Installer
リンクのコピー

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

通信事業者コアクラスターをインストールする際には、Red Hat Advanced Cluster Management を使用することが推奨されます。Agent Based Installer (ABI) は、OpenShift の独立したインストールフローであり、クラスターをデプロイするための既存のインフラストラクチャーがない環境で使用されます。ABI を使用すると、インストールの管理に追加のサーバーや仮想マシンを必要とせずに、ベアメタルサーバーに OpenShift Container Platform をインストールできます。ただし、継続的なライフサイクル管理、監視、自動化は提供されません。ラップトップなどの任意のシステムで ABI を実行すると、ISO インストールイメージを生成できます。ISO は、クラスターのコントロールプレーンノードのインストールメディアとして使用されます。コントロールプレーンノードの API インターフェイスにネットワーク経由で接続できるシステムであれば、どこからでも ABI を使用して進行状況を監視できます。

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

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

3.9.16. セキュリティー
リンクのコピー

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

通信事業者のお客様は、セキュリティーを重視しており、複数の攻撃ベクトルに対してクラスターを強化する必要があります。OpenShift Container Platform には、クラスターを保護する単一のコンポーネントや機能はありません。以下では、通信事業者コア RDS で取り上げる使用モデルのさまざまなセキュリティー指向の機能と設定を説明します。

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

OpenShift Container Platform クラスターノードにカスタムの nftables ファイアウォールルールを実装する場合、サポートされている実装方法について、Red Hat ナレッジベースソリューションの記事 Custom nftable firewall rules in OpenShift Container Platform を参照してください。この記事は、OpenShift Container Platform 環境でネットワークセキュリティーポリシーの管理を担当するクラスター管理者を対象としています。

この方法を導入する前に、次のような運用上の影響を慎重に検討することが重要です。

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

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

    注記

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

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

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

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

3.9.17. スケーラビリティー
リンクのコピー

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

3.10. 通信事業者コアリファレンス設定の CR
リンクのコピー

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

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

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

前提条件

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

手順

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

    $ podman login registry.redhat.io

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

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

検証

  • out ディレクトリーのディレクトリー構造は次のとおりです。次のコマンドを実行すると、out/telco-core-rds/ ディレクトリー内の通信事業者コア CR を表示できます。 

    $ tree -L 4

    出力例

    .
├── configuration
│   ├── compare.sh
│   ├── core-baseline.yaml
│   ├── core-finish.yaml
│   ├── core-overlay.yaml
│   ├── core-upgrade.yaml
│   ├── kustomization.yaml
│   ├── Makefile
│   ├── ns.yaml
│   ├── README.md
│   ├── reference-crs
│   │   ├── custom-manifests
│   │   │   ├── mcp-worker-1.yaml
│   │   │   ├── mcp-worker-2.yaml
│   │   │   ├── mcp-worker-3.yaml
│   │   │   └── README.md
│   │   ├── optional
│   │   │   ├── logging
│   │   │   ├── networking
│   │   │   ├── other
│   │   │   └── tuning
│   │   └── required
│   │       ├── networking
│   │       ├── other
│   │       ├── performance
│   │       ├── scheduling
│   │       └── storage
│   ├── reference-crs-kube-compare
│   │   ├── compare_ignore
│   │   ├── comparison-overrides.yaml
│   │   ├── metadata.yaml
│   │   ├── optional
│   │   │   ├── logging
│   │   │   ├── networking
│   │   │   ├── other
│   │   │   └── tuning
│   │   ├── ReferenceVersionCheck.yaml
│   │   ├── required
│   │   │   ├── networking
│   │   │   ├── other
│   │   │   ├── performance
│   │   │   ├── scheduling
│   │   │   └── storage
│   │   ├── unordered_list.tmpl
│   │   └── version_match.tmpl
│   └── template-values
│       ├── hw-types.yaml
│       └── regional.yaml
├── install
│   ├── custom-manifests
│   │   ├── mcp-worker-1.yaml
│   │   ├── mcp-worker-2.yaml
│   │   └── mcp-worker-3.yaml
│   ├── example-standard.yaml
│   ├── extra-manifests
│   │   ├── control-plane-load-kernel-modules.yaml
│   │   ├── kdump-master.yaml
│   │   ├── kdump-worker.yaml
│   │   ├── mc_rootless_pods_selinux.yaml
│   │   ├── mount_namespace_config_master.yaml
│   │   ├── mount_namespace_config_worker.yaml
│   │   ├── sctp_module_mc.yaml
│   │   └── worker-load-kernel-modules.yaml
│   └── README.md
└── README.md

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

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

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

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

前提条件

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

手順

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

    $ podman login registry.redhat.io

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

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

    次のコマンドを実行すると、out/telco-core-rds/configuration/reference-crs-kube-compare ディレクトリー内のリファレンス設定を表示できます。 

    $ tree -L 2

  3. 出力例 

    .
├── compare_ignore
├── comparison-overrides.yaml
├── metadata.yaml
    1 
    
├── optional
    2 
    
│   ├── logging
│   ├── networking
│   ├── other
│   └── tuning
├── ReferenceVersionCheck.yaml
├── required
    3 
    
│   ├── networking
│   ├── other
│   ├── performance
│   ├── scheduling
│   └── storage
├── unordered_list.tmpl
└── version_match.tmpl
    1
    リファレンス設定用の設定ファイル。
    2
    任意のテンプレート用のディレクトリー。
    3
    必須のテンプレート用のディレクトリー。

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

    $ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml

    出力例

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

...

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

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

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

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

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

3.10.3. ノード設定のリファレンス CR
リンクのコピー

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

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

control-plane-load-kernel-modules.yaml

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

いいえ

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

sctp_module_mc.yaml

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

いいえ

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

worker-load-kernel-modules.yaml

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

いいえ

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

mount_namespace_config_master.yaml

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

いいえ

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

mount_namespace_config_worker.yaml

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

いいえ

Kdump の有効化

kdump-master.yaml

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

いいえ

Kdump の有効化

kdump-worker.yaml

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

いいえ

3.10.4. クラスターインフラストラクチャーのリファレンス CR
リンクのコピー

Expand
表3.3 クラスターインフラストラクチャー CR
コンポーネントリファレンス CR説明任意

クラスターロギング

ClusterLogForwarder.yaml

指定されたサービスアカウントを使用してログ転送インスタンスを設定し、設定が有効であることを検証します。

はい

クラスターロギング

ClusterLogNS.yaml

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

はい

クラスターロギング

ClusterLogOperGroup.yaml

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

はい

クラスターロギング

ClusterLogServiceAccount.yaml

クラスターロギングのサービスアカウントを設定します。

はい

クラスターロギング

ClusterLogServiceAccountAuditBinding.yaml

ログコレクターのサービスアカウントに collect-audit-logs クラスターロールを付与します。

はい

クラスターロギング

ClusterLogServiceAccountInfrastructureBinding.yaml

コレクターのサービスアカウントがインフラストラクチャーリソースからログを収集できるようにします。

はい

クラスターロギング

ClusterLogSubscription.yaml

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

はい

非接続設定

catalog-source.yaml

非接続環境用の Red Hat Operator カタログを定義します。

いいえ

非接続設定

idms.yaml

非接続レジストリーのミラーリングされるリポジトリーダイジェストのリストを定義します。

いいえ

非接続設定

operator-hub.yaml

すべてのデフォルトのソースを無効にする OperatorHub 設定を定義します。

いいえ

監視および可観測性

monitoring-config-cm.yaml

Prometheus と Alertmanager の保存と保持を設定します。

はい

電源管理

PerformanceProfile.yaml

選択したノードのパフォーマンスを最適化するために、CPU 分離、huge page 設定、ワークロードヒントを指定して、パフォーマンスプロファイルリソースを定義します。

いいえ

3.10.5. リソースチューニングのリファレンス CR
リンクのコピー

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

システム予約容量

control-plane-system-reserved.yaml

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

はい

3.10.6. ネットワークのリファレンス CR
リンクのコピー

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

ベースライン

Network.yaml

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

いいえ

ベースライン

networkAttachmentDefinition.yaml

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

はい

ロードバランサー

addr-pool.yaml

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

いいえ

ロードバランサー

bfd-profile.yaml

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

いいえ

ロードバランサー

bgp-advr.yaml

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

いいえ

ロードバランサー

bgp-peer.yaml

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

いいえ

ロードバランサー

community.yaml

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

いいえ

ロードバランサー

metallb.yaml

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

いいえ

ロードバランサー

metallbNS.yaml

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

いいえ

ロードバランサー

metallbOperGroup.yaml

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

いいえ

ロードバランサー

metallbSubscription.yaml

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

いいえ

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

mc_rootless_pods_selinux.yaml

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

はい

NMState Operator

NMState.yaml

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

いいえ

NMState Operator

NMStateNS.yaml

NMState Operator の namespace を作成します。

いいえ

NMState Operator

NMStateOperGroup.yaml

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

いいえ

NMState Operator

NMStateSubscription.yaml

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

いいえ

SR-IOV Network Operator

sriovNetwork.yaml

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

いいえ

SR-IOV Network Operator

sriovNetworkNodePolicy.yaml

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

いいえ

SR-IOV Network Operator

SriovOperatorConfig.yaml

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

いいえ

SR-IOV Network Operator

SriovSubscription.yaml

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

いいえ

SR-IOV Network Operator

SriovSubscriptionNS.yaml

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

いいえ

SR-IOV Network Operator

SriovSubscriptionOperGroup.yaml

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

いいえ

3.10.7. スケジューリングのリファレンス CR
リンクのコピー

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

NUMA 対応スケジューラー

nrop.yaml

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

いいえ

NUMA 対応スケジューラー

NROPSubscription.yaml

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

いいえ

NUMA 対応スケジューラー

NROPSubscriptionNS.yaml

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

いいえ

NUMA 対応スケジューラー

NROPSubscriptionOperGroup.yaml

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

いいえ

NUMA 対応スケジューラー

sched.yaml

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

いいえ

NUMA 対応スケジューラー

Scheduler.yaml

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

いいえ

3.10.8. ストレージのリファレンス CR
リンクのコピー

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

外部 ODF 設定

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

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

いいえ

外部 ODF 設定

02-ocs-external-storagecluster.yaml

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

いいえ

外部 ODF 設定

odfNS.yaml

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

いいえ

外部 ODF 設定

odfOperGroup.yaml

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

いいえ

3.11. 通信事業者コアリファレンス設定のソフトウェア仕様
リンクのコピー

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

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

Red Hat Advanced Cluster Management (RHACM)

2.14

Red Hat OpenShift GitOps

1.18

Cluster Logging Operator

6.2

OpenShift Data Foundation

4.19

SR-IOV Network Operator

4.20

MetalLB

4.20

NMState Operator

4.20

NUMA 対応スケジューラー

4.20

  • Red Hat Advanced Cluster Management (RHACM) は、対応する Red Hat Advanced Cluster Management (RHACM) バージョンがリリースされると、2.15 に更新されます。
  • OpenShift Data Foundation は、対応する OpenShift Data Foundation バージョン (4.20) がリリースされると、4.20 に更新されます。

第4章 通信事業者向け RAN DU リファレンス設計仕様
リンクのコピー

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

使用モデルとシステムレベルの情報を使用して、マネージドシングルノード OpenShift クラスターの通信事業者 RAN DU ワークロード、クラスターリソース、および最小ハードウェア仕様を計画してください。

個々のコンポーネントの具体的な制限、要件、およびエンジニアリングに関する考慮事項は、それぞれのセクションで説明します。

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

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

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

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

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

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

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

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

4.1.1. RAN DU でサポートされている CPU アーキテクチャー
リンクのコピー

Expand
表4.1 RAN DU でサポートされている CPU アーキテクチャー
アーキテクチャーリアルタイムカーネル非リアルタイムカーネル

x86_64

はい

はい

aarch64

いいえ

はい

4.2. リファレンス設計の範囲
リンクのコピー

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

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

注記

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

4.3. リファレンス設計からの逸脱
リンクのコピー

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

重要

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

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

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

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

    注記

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

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

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

注記

telco RAN DU RDS KPI テスト結果の詳細は、telco RAN DU 4.20 リファレンス設計仕様 KPI テスト結果を 参照してください。この情報は顧客とパートナーのみが利用できます。

クラスタートポロジー

RAN DU ワークロードに推奨されるトポロジーは、シングルノードの OpenShift です。DU ワークロードは、必要に応じて、3 ノードコンパクトクラスター、高可用性 (3 つのコントロールプレーン + n 個のワーカーノード)、SNO+1 など、他のクラスタートポロジーでも実行できます。SNO+1 トポロジーよりも、複数の SNO クラスター、または可用性の高い 3 ノードコンパクトクラスターが推奨されます。

標準のクラスタートポロジーの場合 (3+n)、混合アーキテクチャークラスターは次の場合にのみ許可されます。

  • すべてのコントロールプレーンノードが x86_64 である。
  • すべてのワーカーノードが aarch64 である。

リモートワーカーノード (RWN) クラスタートポロジーは、このリファレンス設計仕様では推奨されておらず、設計仕様の対象外です。RWN は、RAN DU などのサービスレベルアグリーメント要件が厳しいワークロードにとって次の欠点があるため、検討対象から除外されています。

  • イメージベースのアップグレードと、その機能によって提供される高速アップグレードやロールバック機能などのメリットがサポートされていない。
  • Day 2 Operator への更新がすべての RWN に同時に影響し、ローリング更新を実行することができない。
  • コントロールプレーンの損失 (障害シナリオ) が発生すると、コントロールプレーンによってサービスが提供されるサイトの数が多いため、全体的なサービスの可用性に非常に大きな影響が及ぶ。
  • 監視猶予期間および toleration のタイムアウトを超える期間にわたり、RWN とコントロールプレーン間のネットワーク接続が失われると、Pod のエビクションが発生し、サービス停止につながる可能性がある。
  • コンテナーイメージの事前キャッシュがサポートされていない。
  • ワークロードアフィニティーの複雑さの増大。
RAN DU でサポートされているクラスタートポロジー
Expand
表4.2 RAN DU でサポートされているクラスタートポロジー
アーキテクチャーSNOSNO+13 ノードStandardRWN

x86_64

はい

はい

はい

はい

いいえ

aarch64

はい

いいえ

いいえ

いいえ

いいえ

mixed

該当なし

いいえ

いいえ

はい

いいえ

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

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

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

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

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

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

リファレンスアプリケーションワークロードの特性
  1. vRAN アプリケーション (管理および制御機能を含む) 用に、5 つの namespace にわたって 75 個の Pod と、Pod あたり 4 つのコンテナーを使用します。
  2. namespace ごとに 30 個の ConfigMap CR と 30 個の Secret CR を作成します。
  3. exec プローブは使用しません。

  4. セカンダリーネットワークを使用します。

    注記

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

    $ query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
  5. アプリケーションログは、プラットフォームのログコレクターによって収集されません。
  6. プライマリー CNI の総トラフィックは最大 30 Mbps、セカンダリーネットワークでは最大 5 Gbps です。
ハブクラスター管理の特性

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

  1. 最大 10 個の RHACM 設定ポリシーを使用します。これは、Red Hat が提供する 5 個のポリシーと、準拠評価間隔が 10 分以上の最大 5 個のカスタム設定ポリシーで構成されます。
  2. クラスターポリシーで、最小限の数 (最大 10 個) のマネージドクラスターテンプレートを使用します。ハブ側のテンプレーティングを使用します。
  3. policyController を除いて RHACM アドオンを無効にし、デフォルト設定で可観測性を設定します。

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

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

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

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

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

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

16 G 未満

 

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

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

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

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

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

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

      注記

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

注記

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

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

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

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

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

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

重要

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

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

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

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

注記

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

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

4.6.2. Kubelet 設定
リンクのコピー

CNF ワークロードによっては、システム全体の安全な sysctl のリストに含まれていない sysctl を使用するものもあります。通常、ネットワーク関連の sysctl は namespace で分離されており、PerformanceProfile カスタムリソース (CR) の kubeletconfig.experimental アノテーションを次の形式の JSON 文字列として使用することで有効にできます。

allowedUnsafeSysctls を示すサンプルスニペット

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: {{ .metadata.name }}
  annotations:kubeletconfig.experimental: |
      {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
# ...

注記

これらの sysctl は namespace で分離されていますが、Pod がその詳細で指定された制限を超えてメモリーやその他のリソースを消費することを許容する可能性があります。これらの sysctl がプラットフォームリソースを使い果たさないようにする必要があります。

詳細は、「コンテナーでの sysctl の使用」を参照してください。

4.6.3. CPU パーティショニングとパフォーマンスチューニング
リンクのコピー

このリリースの変更点

  • PerformanceProfile および TunedPerformancePatch オブジェクトが更新され、aarch64 アーキテクチャーを完全にサポートするようになりました。

    • 以前に TunedPerformancePatch オブジェクトに追加のパッチを適用していた場合は、それらのパッチを、代わりに ran-du-performance プロファイルを含む新しいパフォーマンスプロファイルに変換する必要があります。「エンジニアリングに関する考慮事項」セクションを参照してください。
説明
RAN DU 使用モデルには、低遅延パフォーマンスを実現する PerformanceProfile CR を使用したクラスターパフォーマンスチューニングと、RAN 固有の追加のチューニングを追加する TunedPerformancePatch CR が含まれます。リファレンス PerformanceProfile は、x86_64 および aarch64 CPU アーキテクチャー用のものが提供されています。提供される単一の TunedPerformancePatch オブジェクトが、CPU アーキテクチャーを自動的に検出し、必要となる追加のチューニングを実行します。RAN DU ユースケースでは、低レイテンシーのパフォーマンスを実現するためにクラスターをチューニングする必要があります。PerformanceProfile および TunedPerformancePatch CR は、Node Tuning Operator によってリコンサイルされます。

PerformanceProfile CR を使用したノードのチューニングの詳細は、「パフォーマンスプロファイルを使用した低レイテンシーを実現するためのノードのチューニング」を参照してください。

制限と要件

通信事業者 RAN DU プロファイルの PerformanceProfile CR で次の設定を設定する必要があります。

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

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

    • ARM CPU (Neoverse)

      注記

      パフォーマンスへの潜在的な影響を判断するために、Pod ごとの電源管理などの機能を評価することを推奨します。

  • x86_64:

    • 予約済み cpuset を設定し、含まれる各コアの両方のハイパースレッドシブリングを含めます。予約されていないコアは、ワークロードのスケジュールに割り当て可能な CPU として使用できます。
    • ハイパースレッドシブリングが予約済みコアと分離されたコアに分割されていないことを確認します。
    • 予約済みおよび分離された CPU に、CPU 内の全コアの全スレッドが含まれていることを確認します。
    • 予約済み CPU セットに各 NUMA ノードの Core 0 を含めます。
    • huge page のサイズを 1G に設定します。

  • aarch64:

    • 予約済み CPU セットに最初の 4 つのコア (またはそれ以上) を使用します。
    • huge page のサイズを 512M に設定します。
  • デフォルトで管理ワークロードパーティションの一部として設定されている OpenShift Container Platform Pod のみを予約済みコアにピニングします。
  • ハードウェアベンダーから推奨されている場合は、hardwareTuning セクションを使用して、予約済み CPU と分離された CPU の最大 CPU 周波数を設定します。
エンジニアリングに関する考慮事項

  • RealTime (RT) カーネル

    • x86_64 では、最大限のパフォーマンスメトリクスを達成するには、RT カーネルを使用する必要があります。これは x86_64/PerformanceProfile.yaml 設定のデフォルトです。

      • 必要に応じて、パフォーマンスに相応の影響が及びますが、非 RT カーネルを選択することもできます。
    • aarch64 では、RAN DU ユースケースには 64k ページサイズの非 RT カーネルのみが推奨されます。これは aarch64/PerformanceProfile.yaml 設定のデフォルトです。
  • 設定する huge page の数は、アプリケーションのワークロード要件によって異なります。このパラメーターの変動は予想され、許容されます。
  • 選択したハードウェアとシステムで使用されている追加コンポーネントに基づいて、予約済みおよび分離された CPU セットの設定が変更されることが予想されます。この変更が指定の制限を満たしている必要があります。
  • IRQ アフィニティーをサポートしていないハードウェアは、分離された CPU に影響します。CPU 全体が保証される QoS を持つ Pod で、割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートしている必要があります。
  • ワークロードパーティショニングを有効にするには、デプロイ時に cpuPartitioningMode を AllNodes に設定し、PerformanceProfile CR を使用して、オペレーティングシステム、割り込み、および OpenShift Container Platform Pod をサポートするのに十分な CPU を割り当てます。
  • x86_64 では、PerformanceProfile CR に vfio_pci 用の追加のカーネル引数設定が含まれています。この引数は、FEC アクセラレーターなどのデバイスをサポートするために含まれています。ワークロードに必要ない場合には除外できます。

  • aarch64 では、プラットフォームのニーズに応じて PerformanceProfile を調整する必要があります。

    • Grace Hopper システムの場合、次のカーネルコマンドライン引数が必要です。

      • acpi_power_meter.force_cap_on=y
      • module_blacklist=nouveau
      • pci=realloc=off
      • pci=pcie_bus_safe
    • その他の ARM プラットフォームでは、iommu.passthrough=1 または pci=realloc を有効にする必要がある場合があります。

  • TunedPerformancePatch.yaml の拡張と補強:

    • TunedPerformancePatch.yaml は、ran-du-performance という名前のデフォルトの最上位 tuned プロファイルと、ran-du-performance-architecture-common という名前のアーキテクチャー対応の RAN チューニングプロファイル、および共通ポリシーによって自動的に選択されるアーキテクチャー固有の追加の子ポリシーを導入します。
    • デフォルトでは、ran-du-performance プロファイルは、priority レベル 18 に設定されており、PerformanceProfile によって作成されたプロファイル openshift-node-performance-openshift-node-performance-profile と ran-du-performance-architecture-common の両方を含んでいます。

    • PerformanceProfile オブジェクトの名前をカスタマイズした場合は、PerformanceProfile CR によって作成された tuned プロファイルの名前変更と、ran-du-performance-architecture-common RAN チューニングプロファイルを含む新しい tuned オブジェクトを作成する必要があります。priority は 18 未満である必要があります。たとえば、PerformanceProfile オブジェクトの名前が change-this-name の場合、次のようにします。 

      apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: custom-performance-profile-override
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
    - name: custom-performance-profile-x
      data: |
        [main]
        summary=Override of the default ran-du performance tuning to adjust for our renamed PerformanceProfile
        include=openshift-node-performance-change-this-name,ran-du-performance-architecture-common
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: "master"
      priority: 15
      profile: custom-performance-profile-x
    • さらにオーバーライドする場合は、オプションの TunedPowerCustom.yaml 設定ファイルに、提供される TunedPerformancePatch.yaml をオーバーレイしたり直接編集したりせずに拡張する方法が例示されています。追加の tuned プロファイルを作成し、そのプロファイルに ran-du-performance という名前の最上位 tuned プロファイルを含めて、recommend セクションでより小さな priority の数値を指定することで、設定を簡単に追加できます。
    • Node Tuning Operator の詳細は、「Node Tuning Operator の使用」を参照してください。

4.6.4. PTP Operator
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
クラスターノードで Precision Time Protocol (PTP) を設定します。PTP は、NTP などの他のクロック同期プロトコルと比較して、RAN 環境において正確なタイミングと信頼性を確保します。
サポートされる内容
  • グランドマスタークロック (T-GM): GPS を使用してローカルクロックを同期し、他のデバイスに時刻同期を提供します。
  • 境界クロック (T-BC): 別の PTP ソースから時間を受信し、他のデバイスに再配信します。
  • 通常クロック (T-TSC): 別の PTP タイムプロバイダーからのローカルクロックを同期します。

設定を変えることで、時刻配信の改善や高可用性 (HA) のために、複数の NIC を設定し、必要に応じて HTTP 経由の高速イベント通知を利用することができます。

制限と要件

  • 次の通信事業者ユースケース用の PTP G.8275.1 プロファイルをサポートしています。

    • T-GM のユースケース:

      • Westport チャネル NIC は最大 3 枚までに制限されます。
      • 1 枚の NIC カードに GNSS 入力が必要で、追加の NIC を同期するには SMA 接続が必要です。
      • HA サポートなし

    • T-BC のユースケース:

      • NIC は最大 2 枚までに制限されます。
      • 2 NIC 構成では、システムクロックの HA サポートは任意です。

    • T-TSC のユースケース:

      • NIC は 1 枚までに制限されます。
      • アクティブ/スタンバイ 2 ポート構成では、システムクロックの HA サポートは任意です。
  • true または enhanced でログ削減を有効にする必要があります。
エンジニアリングに関する考慮事項

  • * RAN DU RDS 設定例は次のとおりです。

    • T-GM、T-BC、および T-TSC
    • HA の有無によるバリエーション
  • PTP 高速イベント通知は、ConfigMap CR を使用してサブスクライバーの詳細を保持します。
  • O-RAN 仕様で説明されている階層型イベントサブスクリプションは、PTP イベントではサポートされていません。
  • PTP 高速イベント REST API v1 はライフサイクルが終了しました。

4.6.5. SR-IOV Operator
リンクのコピー

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

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

    # ip link set dev <physical_function> mtu 9000

4.6.6. ロギング
リンクのコピー

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

4.6.7. SRIOV-FEC Operator
リンクのコピー

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

  • FEC Operator v2.7.0 以降:

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

4.6.8. Lifecycle Agent
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Lifecycle Agent は、シングルノード OpenShift クラスターのイメージベースのアップグレードを実行するためのローカルのライフサイクル管理サービスを提供します。イメージベースのアップグレードは、シングルノード OpenShift クラスターに推奨されるアップグレード方法です。
制限と要件
  • Lifecycle Agent は、マルチノードクラスターまたは追加のワーカーを持つシングルノードの OpenShift クラスターには適用されません。
  • Lifecycle Agent には、クラスターのインストール時に作成する永続ボリュームが必要です。

パーティション要件の詳細は、「GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定」を参照してください。

4.6.9. Local Storage Operator
リンクのコピー

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

4.6.10. Logical Volume Manager Storage
リンクのコピー

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

4.6.11. ワークロードパーティショニング
リンクのコピー

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

4.6.12. クラスターのチューニング
リンクのコピー

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

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

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

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

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

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

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

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

  • ローカルの alertmanager コンポーネントおよび telemeter コンポーネントを無効にします。
  • RHACM の可観測性を使用する際、アラートをハブクラスターに転送するには、適切な additionalAlertManagerConfigs CR で CR を拡張する必要があります。
  • RHACM の可観測性は、そのデフォルトのデータ値と、クラスターチューニング用のリファレンス CR 群の一部として提供されるモニタリング設定用の ConfigMap CR を結合します。この結合により、ポリシーが準拠していない状態になります。提供される設定の上書きや、RHACM データ値との結合を避けるには、この ConfigMap CR の RHACM 管理を無効にできます。これにより、ポリシーの準拠が維持されます。詳細は、通信事業者ハブリファレンス設計仕様の「可観測性」セクションを参照してください。

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

    注記

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

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

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

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

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

Console Operator を無効にする

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

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

4.6.13. マシン設定
リンクのコピー

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

コンテナーランタイム

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

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

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

SCTP

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

Kdump

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

CRI-O ワイプ無効化

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

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

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

RCU Normal の設定

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

ワンショット時間同期

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

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

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

4.7.1. Red Hat Advanced Cluster Management
リンクのコピー

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

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

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

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

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

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

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

4.7.2. SiteConfig Operator
リンクのコピー

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

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

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

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

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

4.7.3. Topology Aware Lifecycle Manager
リンクのコピー

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

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

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

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

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

4.7.4. GitOps Operator および GitOps ZTP
リンクのコピー

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

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

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

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

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

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

4.7.5. Agent-based Installer
リンクのコピー

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

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

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

注記

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

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

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

クラスター機能

example-sno.yaml

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

いいえ

コンソールの無効化

cluster-tuning/console-disable/ConsoleOperatorDisable.yaml

Console Operator を無効にします。

いいえ

非接続レジストリー

extra-manifest/09-openshift-marketplace-ns.yaml

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

いいえ

非接続レジストリー

disconnected-registry/DefaultCatsrc.yaml

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

いいえ

非接続レジストリー

cluster-tuning/DisableOLMPprof.yaml

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

いいえ

非接続レジストリー

disconnected-registry/DisconnectedIDMS.yaml

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

いいえ

非接続レジストリー

cluster-tuning/operator-hub/OperatorHub.yaml

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

いいえ

モニタリング設定

cluster-tuning/monitoring-configuration/ReduceMonitoringFootprint.yaml

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

いいえ

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

cluster-tuning/disabling-network-diagnostics/DisableSnoNetworkDiag.yaml

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

いいえ

4.8.2. Day 2 Operator のリファレンス CR
リンクのコピー

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

Cluster Logging Operator

cluster-logging/ClusterLogForwarder.yaml

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

いいえ

Cluster Logging Operator

cluster-logging/ClusterLogNS.yaml

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

いいえ

Cluster Logging Operator

cluster-logging/ClusterLogOperGroup.yaml

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

いいえ

Cluster Logging Operator

cluster-logging/ClusterLogServiceAccount.yaml

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

いいえ

Cluster Logging Operator

cluster-logging/ClusterLogServiceAccountAuditBinding.yaml

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

いいえ

Cluster Logging Operator

cluster-logging/ClusterLogServiceAccountInfrastructureBinding.yaml

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

いいえ

Cluster Logging Operator

cluster-logging/ClusterLogSubscription.yaml

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

いいえ

Lifecycle Agent

ibu/ImageBasedUpgrade.yaml

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

はい

Lifecycle Agent

lca/LcaSubscription.yaml

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

はい

Lifecycle Agent

lca/LcaSubscriptionNS.yaml

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

はい

Lifecycle Agent

lca/LcaSubscriptionOperGroup.yaml

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

はい

Local Storage Operator

storage-lso/StorageClass.yaml

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

いいえ

Local Storage Operator

storage/StorageLV.yaml

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

いいえ

Local Storage Operator

storage-lso/StorageNS.yaml

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

いいえ

Local Storage Operator

storage-lso/StorageOperGroup.yaml

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

いいえ

Local Storage Operator

storage-lso/StorageSubscription.yaml

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

いいえ

LVM Operator

storage-lvm/LVMOperatorStatus.yaml

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

はい

LVM Operator

storage-lvm/StorageLVMCluster.yaml

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

いいえ

LVM Operator

storage-lvm/StorageLVMSubscription.yaml

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

いいえ

LVM Operator

storage-lvm/StorageLVMSubscriptionNS.yaml

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

いいえ

LVM Operator

storage-lvm/StorageLVMSubscriptionOperGroup.yaml

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

いいえ

Node Tuning Operator

node-tuning-operator/aarch64/PerformanceProfile.yaml

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

いいえ

Node Tuning Operator

node-tuning-operator/x86_64/PerformanceProfile.yaml

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

いいえ

Node Tuning Operator

node-tuning-operator/TunedPerformancePatch.yaml

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

いいえ

Node Tuning Operator

node-tuning-operator/TunedPowerCustom.yaml

TunedPerformancePatch の上に、オーバーレイとして追加の省電力モードチューニングを適用します。

いいえ

PTP 高速イベント通知

ptp-operator/configuration/PtpConfigBoundaryForEvent.yaml

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

いいえ

PTP 高速イベント通知

ptp-operator/configuration/PtpConfigForHAForEvent.yaml

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

いいえ

PTP 高速イベント通知

ptp-operator/configuration/PtpConfigMasterForEvent.yaml

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

いいえ

PTP 高速イベント通知

ptp-operator/configuration/PtpConfigSlaveForEvent.yaml

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

いいえ

PTP 高速イベント通知

ptp-operator/PtpOperatorConfigForEvent.yaml

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

いいえ

PTP Operator

ptp-operator/configuration/PtpConfigBoundary.yaml

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

いいえ

PTP Operator

ptp-operator/configuration/PtpConfigDualCardGmWpc.yaml

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

いいえ

PTP Operator

ptp-operator/configuration/PtpConfigThreeCardGmWpc.yaml

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

いいえ

PTP Operator

ptp-operator/configuration/PtpConfigGmWpc.yaml

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

いいえ

PTP Operator

ptp-operator/configuration/PtpConfigSlave.yaml

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

いいえ

PTP Operator

ptp-operator/configuration/PtpConfigDualFollower.yaml

アクティブ/スタンバイ設定で 2 つのインターフェイスを持つ PTP 通常クロックの PTP 設定を指定します。クラスターのロールに依存します。

いいえ

PTP Operator

ptp-operator/PtpOperatorConfig.yaml

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

いいえ

PTP Operator

ptp-operator/PtpSubscription.yaml

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

いいえ

PTP Operator

ptp-operator/PtpSubscriptionNS.yaml

PTP Operator の namespace を設定します。

いいえ

PTP Operator

ptp-operator/PtpSubscriptionOperGroup.yaml

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

いいえ

PTP Operator (高可用性)

ptp-operator/configuration/PtpConfigBoundary.yaml

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

いいえ

PTP Operator (高可用性)

ptp-operator/configuration/PtpConfigForHA.yaml

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

いいえ

SR-IOV FEC Operator

sriov-fec-operator/AcceleratorsNS.yaml

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

はい

SR-IOV FEC Operator

sriov-fec-operator/AcceleratorsOperGroup.yaml

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

はい

SR-IOV FEC Operator

sriov-fec-operator/AcceleratorsSubscription.yaml

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

はい

SR-IOV FEC Operator

sriov-fec-operator/SriovFecClusterConfig.yaml

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

はい

SR-IOV Operator

sriov-operator/SriovNetwork.yaml

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

いいえ

SR-IOV Operator

sriov-operator/SriovNetworkNodePolicy.yaml

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

いいえ

SR-IOV Operator

sriov-operator/SriovOperatorConfig.yaml

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

いいえ

SR-IOV Operator

sriov-operator/SriovOperatorConfigForSNO.yaml

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

いいえ

SR-IOV Operator

sriov-operator/SriovSubscription.yaml

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

いいえ

SR-IOV Operator

sriov-operator/SriovSubscriptionNS.yaml

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

いいえ

SR-IOV Operator

sriov-operator/SriovSubscriptionOperGroup.yaml

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

いいえ

4.8.3. マシン設定のリファレンス CR
リンクのコピー

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

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

optional-extra-manifest/enable-crun-master.yaml

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

いいえ

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

optional-extra-manifest/enable-crun-worker.yaml

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

いいえ

CRI-O ワイプ無効化

extra-manifest/99-crio-disable-wipe-master.yaml

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

いいえ

CRI-O ワイプ無効化

extra-manifest/99-crio-disable-wipe-worker.yaml

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

いいえ

Kdump の有効化

extra-manifest/06-kdump-master.yaml

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

いいえ

Kdump の有効化

extra-manifest/06-kdump-worker.yaml

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

いいえ

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

extra-manifest/01-container-mount-ns-and-kubelet-conf-master.yaml

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

いいえ

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

extra-manifest/01-container-mount-ns-and-kubelet-conf-worker.yaml

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

いいえ

ワンショット時間同期

extra-manifest/99-sync-time-once-master.yaml

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

いいえ

ワンショット時間同期

extra-manifest/99-sync-time-once-worker.yaml

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

いいえ

SCTP

extra-manifest/03-sctp-machine-config-master.yaml

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

はい

SCTP

extra-manifest/03-sctp-machine-config-worker.yaml

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

はい

RCU normal の設定

extra-manifest/08-set-rcu-normal-master.yaml

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

いいえ

RCU normal の設定

extra-manifest/08-set-rcu-normal-worker.yaml

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

いいえ

SRIOV 関連のカーネル引数

extra-manifest/07-sriov-related-kernel-args-master.yaml

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

いいえ

SRIOV 関連のカーネル引数

extra-manifest/07-sriov-related-kernel-args-worker.yaml

ワーカーノードで SR-IOV サポートを有効にします。

いいえ

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

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

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

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

前提条件

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

手順

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

    $ podman login registry.redhat.io

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

    $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20
     
    $ mkdir -p ./out
     
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20 extract /home/ztp --tar | tar x -C ./out

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

    $ oc cluster-compare -r out/reference/metadata.yaml

    出力例

    ...

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

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

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

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

...

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

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

4.10. 通信事業者 RAN DU 4.20 の検証済みソフトウェアコンポーネント
リンクのコピー

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

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

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

4.19

Cluster Logging Operator

6.2

Local Storage Operator

4.20

OpenShift API for Data Protection (OADP)

1.5

PTP Operator

4.20

SR-IOV Operator

4.20

SRIOV-FEC Operator

2.11

Lifecycle Agent

4.20

第5章 通信事業者ハブリファレンス設計仕様
リンクのコピー

通信事業者ハブリファレンス設計仕様 (RDS) は、通信事業者の環境で OpenShift Container Platform クラスター群をデプロイおよび運用するハブクラスターの設定を表したものです。

5.1. リファレンス設計の範囲
リンクのコピー

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

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

注記

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

5.2. リファレンス設計からの逸脱
リンクのコピー

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

重要

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

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

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

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

    注記

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

5.3. ハブクラスターのアーキテクチャーの概要
リンクのコピー

管理ハブクラスターで実行される機能とコンポーネントは、ハブアンドスポークトポロジー内に存在する他の多数のクラスターを管理するために使用します。ハブクラスターは、デプロイされたクラスター群の設定、ライフサイクル、および可観測性を管理するための、可用性の高い一元的なインターフェイスを提供します。

注記

管理ハブのすべての機能は、専用の OpenShift Container Platform クラスターにデプロイすることも、既存のクラスターに共存するアプリケーションとしてデプロイすることもできます。

マネージドクラスターのライフサイクル
ハブクラスターは、Day 2 Operator を組み合わせて使用し、GitOps 手法を使用してクラスター群をデプロイおよび設定するために必要なインフラストラクチャーを提供します。デプロイされたクラスターの稼働期間中、アップグレードのさらなる管理、クラスターの数のスケーリング、ノードの置き換え、およびその他のライフサイクル管理機能を、宣言的に定義してロールアウトできます。クラスター群全体のロールアウトのタイミングと進行を制御できます。
モニタリング
ハブクラスターは、RHACM Operator の主要機能である可観測性を通じて、マネージドクラスターの監視とステータスレポートを提供します。これには、ガバナンスポリシーフレームワークを介した集約されたメトリクス、アラート、コンプライアンス監視が含まれます。

通信事業者管理ハブのリファレンス設計仕様 (RDS) と、関連するリファレンスカスタムリソース (CR) は、通信事業者が管理するクラスターインフラストラクチャーのライフサイクルをデプロイ、設定、管理するための方法を表したものです。この方法は、通信事業者エンジニアリングおよび QE チームによって検証されています。このリファレンス設定には、OpenShift Container Platform 上のハブクラスターコンポーネントのインストールと設定が含まれます。

図5.1 ハブクラスターリファレンス設計のコンポーネント

通信事業者ハブクラスターリファレンス設計のコンポーネント

図5.2 ハブクラスターリファレンス設計のアーキテクチャー

通信事業者ハブクラスター RDS のアーキテクチャー

5.4. 通信事業者管理ハブクラスターの使用モデル
リンクのコピー

ハブクラスターは、通信事業者のアプリケーションおよびワークロードクラスターに対して、マネージド型のクラスターのインストール、設定、可観測性、および継続的なライフサイクル管理を提供します。

5.5. ハブクラスターのスケーリングターゲット
リンクのコピー

ハブクラスターのリソース要件は、ハブによって管理されるクラスターの数、マネージドクラスターごとに使用されるポリシーの数、および Red Hat Advanced Cluster Management (RHACM) で設定されている機能セットの影響を直接受けます。

ハブクラスターリファレンス設定では、次の条件下で最大 3500 個のマネージドシングルノード OpenShift クラスターをサポートできます。

  • 各クラスターに 5 つのポリシーがあり、ハブ側のテンプレートで 10 分間の評価間隔が設定されている。

  • 次の RHACM アドオンだけが有効である。

    • ポリシーコントローラー
    • デフォルト設定の可観測性
  • GitOps ZTP を使用して、一度に最大 500 個のクラスターを一括でマネージドクラスターにデプロイする。

リファレンス設定は、複数のマネージドクラスタートポロジーが混在する場合のデプロイと管理も検証されています。具体的な制限は、クラスタートポロジーの組み合わせや有効な RHACM の機能などによって異なります。トポロジーが混在する場合、リファレンスハブ設定は、1,200 個のシングルノード OpenShift クラスター、400 個のコンパクトクラスター (コントロールプレーンとコンピュートノードを組み合わせた 3 ノード)、および 230 個の標準クラスター (コントロールプレーン 3 個とワーカーノード 2 個) の組み合わせを使用して検証されています。

このリファレンス仕様に準拠するハブクラスターは、ArgoCD アプリケーションごとに 1000 個のシングルノード ClusterInstance CR の同期をサポートできます。複数のアプリケーションを使用すると、1 つのハブクラスターでサポートされるクラスターの最大数を実現できます。

注記

規模決定に関する具体的な要件は、クラスターのトポロジーとワークロードの影響を大きく受けます。詳細は、「ストレージ要件」を参照してください。実際のマネージドクラスター群の特性に合わせてクラスターの規模を調整してください。

5.6. ハブクラスターのリソース使用量
リンクのコピー

次の条件でハブクラスターをデプロイする場合のリソース使用量を測定しました。

  • 3500 個のシングルノード OpenShift クラスターを管理する際の負荷を基準となる負荷とする。
  • 管理ハブ用の 3 ノードコンパクトクラスターをデュアルソケットのベアメタルサーバーで実行する。
  • ネットワーク障害として、往復レイテンシー 50 ミリ秒、帯域幅制限 100 Mbps、パケットロス 0.02% が発生すると想定する。
  • 可観測性が有効でない。
  • ローカルストレージのみを使用する。
Expand
表5.1 リソース利用量の値
メトリクスピーク測定値

OpenShift プラットフォームの CPU

106 コア (ノードあたり最大 52 コア)

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

504 G (ノードあたり最大 168 G)

5.7. ハブクラスターのトポロジー
リンクのコピー

実稼働環境では、管理機能の高可用性を維持するために、OpenShift Container Platform ハブクラスターの高可用性が求められます。

制限と要件

ハブクラスターには、高可用性クラスタートポロジーを使用します。次に例を示します。

  • コンパクト (コントロールプレーンとコンピュートノードを組み合わせた 3 ノード)
  • 標準 (3 つのコントロールプレーンノード + N 個のコンピュートノード)
エンジニアリングに関する考慮事項
  • 非実稼働環境では、シングルノード OpenShift クラスターを、一部の限られたハブクラスター機能に使用できます。
  • Red Hat OpenShift Data Foundation などの特定の機能は、シングルノード OpenShift ではサポートされていません。この構成では、一部のハブクラスター機能を使用できない可能性があります。
  • オプションのコンピュートノードの数は、具体的なユースケースの規模に応じて異なります。
  • コンピュートノードは必要に応じて後で追加できます。

5.8. ハブクラスターのネットワーク
リンクのコピー

リファレンスハブクラスターは、インターネットへの直接アクセスが不可能な、非接続のネットワーク環境で動作するように設計されています。すべての OpenShift Container Platform クラスターと同様に、ハブクラスターは、すべての OpenShift および Day 2 Operator Lifecycle Manager (OLM) イメージをホストするイメージレジストリーへのアクセスを必要とします。

ハブクラスターは、IPv6 および IPv4 ネットワークのデュアルスタックネットワークをサポートしています。IPv6 はエッジまたはファーエッジのネットワークセグメントでは一般的ですが、データセンターの従来の機器では IPv4 がより一般的に使用されています。

制限と要件

  • インストール方法に関係なく、ハブクラスターに対して次のネットワークタイプを設定する必要があります。

    • clusterNetwork
    • serviceNetwork
    • machineNetwork

  • ハブクラスターには次の IP アドレスを設定する必要があります。

    • apiVIP
    • ingressVIP
注記

上記のネットワーク設定では、選択したアーキテクチャーと DHCP 設定に応じて、一部の値が必須になる場合や、自動的に割り当てられる場合があります。

  • OpenShift Container Platform のデフォルトのネットワークプロバイダーである OVN-Kubernetes を使用する必要があります。

  • マネージドクラスターとハブクラスター間のネットワークが、Red Hat Advanced Cluster Management (RHACM) ドキュメントのネットワーク要件を満たしている必要があります。次に例を示します。

    • ハブクラスターが、マネージドクラスター API サービス、Ironic Python エージェント、およびベースボード管理コントローラー (BMC) ポートにアクセスできる。
    • マネージドクラスターが、ハブクラスターの API サービス、Ingress IP、およびコントロールプレーンノードの IP アドレスにアクセスできる。
    • マネージドクラスターの BMC が、ハブクラスターのコントロールプレーンノードの IP アドレスにアクセスできる。

  • ハブクラスターの稼働期間全体を通じて、イメージレジストリーがアクセス可能である必要があります。

    • 必要なすべてのコンテナーイメージを、インターネット非接続環境のレジストリーにミラーリングする必要があります。デプロイメントに必要なすべての OpenShift リリースおよび OLM Operator リリースイメージは、レジストリーにミラーリングする必要があります。ミラーリング設定の例は、リファレンスにある imageset-config.yaml ファイルを参照してください。このファイルは、必要なバージョンを含めるように更新する必要があります。ミラーリングされたバージョンを参照する ClusterImageSet カスタムリソースのみが、クラスターデプロイメントをサポートします。
    • ハブクラスターを、非接続環境のレジストリーを使用するように設定する必要があります。
    • ハブクラスターは独自のイメージレジストリーをホストできません。レジストリーは、たとえば電源障害がすべてのクラスターノードに影響を及ぼすような環境でも、使用可能である必要があるためです。
エンジニアリングに関する考慮事項
  • ハブクラスターをデプロイするときは、適切なサイズの CIDR 範囲を定義してください。

5.9. ハブクラスターのメモリーと CPU の要件
リンクのコピー

ハブクラスターのメモリーと CPU の要件は、ハブクラスターの設定、クラスター上のリソースの数、およびマネージドクラスターの数によって異なります。

制限と要件
  • ハブクラスターが OpenShift Container Platform および Red Hat Advanced Cluster Management (RHACM) のメモリーと CPU の基本的な要件を満たしていることを確認してください。
エンジニアリングに関する考慮事項
  • 通信事業者ハブクラスターをデプロイする前に、クラスターホストがクラスター要件を満たしていることを確認してください。

マネージドクラスターの数のスケーリングに関する詳細は、「ハブクラスターのスケーリングターゲット」を参照してください。

5.10. ハブクラスターのストレージ要件
リンクのコピー

管理ハブクラスターに必要なストレージの合計量は、クラスターにデプロイされる各アプリケーションのストレージ要件によって異なります。高可用性を持つ PersistentVolume リソースを介したストレージを必要とする主なコンポーネントについては、次のセクションで説明します。

注記

基盤となる OpenShift Container Platform インストールに必要なストレージは、以下の要件とは別です。

5.10.1. Assisted Service
リンクのコピー

Assisted Service は、マルチクラスターエンジンと Red Hat Advanced Cluster Management (RHACM) とともにデプロイされます。

注記

以下の数字は推定値です。より正確な結果を得るには、値を調整してください。推定値が不正確である可能性を考慮して、結果に設計マージン (例: +20%) を加算してください。

Expand
表5.2 Assisted Service のストレージ要件
永続ボリュームリソース容量 (GB)

imageStorage

30

filesystemStorage

709

dataBaseStorage

0.7

  • imageStorage と filesystemStorage は、MultiClusterEngine カスタムリソースのドキュメントの 中央インフラストラクチャー管理を有効にする方法 セクションで説明されている方法で計算されます。
  • dataBaseStorage は、クラスタートポロジー、インストール中に発生するイベント数、ハードウェアおよび設定特性など、さまざまな要因に基づいた経験的な推定値のみによって計算されます。各ホストは 200KB 未満の容量しか使用しません。

5.10.2. RHACM の可観測性
リンクのコピー

クラスターの可観測性は、マルチクラスターエンジンと Red Hat Advanced Cluster Management (RHACM) によって提供されます。

  • 可観測性のストレージには、メトリクスを長期保存するために、いくつかの PV リソースと S3 互換のバケットストレージが必要です。
  • ストレージ要件の計算は複雑であり、マネージドクラスター固有のワークロードと特性によって異なります。PV リソースと S3 バケットの要件は、データ保持、マネージドクラスターの数、マネージドクラスターのワークロードなど、さまざまな要素によって異なります。
  • RHACM 容量計画リポジトリーの可観測性サイズ計算ツールを使用して、可観測性に必要なストレージを見積もってください。計算ツールを使用して可観測性のストレージ要件を見積もる方法は、Red Hat ナレッジベース記事 Calculating storage need for MultiClusterHub Observability on telco environments を参照してください。以下の表では、通信事業者 RAN DU RDS とハブクラスター RDS から得られた値を参考入力値として使用しています。
注記

以下の数値は概算値です。より正確な結果を得るには、値を調整してください。推定値が不正確である可能性を考慮して、結果に設計マージン (例: +20%) を加算してください。

ストレージ要件は、各コンポーネントごとのレプリカ数に大きく依存します。RHACM MultiCluster オブザーバビリティー カスタムリソースを使用すると、レプリカ数に対応するオブザーバビリティスタックのサイズ設定を行うことができます。以下のサイズ値は、デフォルトサイズに基づいています。

Expand
表5.3 クラスターの要件
容量計画に使用する入力値データソース値の例

コントロールプレーンノードの数

ハブクラスター RDS (スケール) と通信事業者 RAN DU RDS (トポロジー)

3500

追加のワーカーノードの数

ハブクラスター RDS (スケール) と通信事業者 RAN DU RDS (トポロジー)

0

データの保存日数

ハブクラスター RDS

15

クラスターあたりの Pod の総数

通信事業者 RAN DU RDS

120

namespace の数 (OpenShift Container Platform を除く)

通信事業者 RAN DU RDS

4

1 時間あたりのメトリクスサンプル数

デフォルト値

12

レシーバー永続ボリューム (PV) に保持される時間数

デフォルト値

24

これらの入力値を、Red Hat ナレッジベース記事 Calculating storage need for MultiClusterHub Observability on telco environments で紹介されているサイズ計算ツールで使用すると、次のストレージ要件が明らかになります。

Expand
表5.4 ストレージ要件
alertmanager PVthanos receive PVthanos compact PV

レプリカ 1 つあたり

合計

レプリカ 1 つあたり

合計

合計

10 GiB

30 GiB

10 GiB

30 GiB

100 GiB

Expand
表5.5 ストレージ要件
thanos rule PVthanos store PVオブジェクトバケット

レプリカ 1 つあたり

合計

レプリカ 1 つあたり

合計

合計

30 GiB

90 GiB

100 GiB

300 GiB

310 GiB

  • ダウンサンプリングが有効になっている場合、MCO カスタムリソースで オブジェクトバケット サイズを設定することはできません。このオプションは将来的に利用可能になる可能性があります。

5.10.3. ストレージに関する考慮事項
リンクのコピー

制限と要件
  • OpenShift Container Platform および Red Hat Advanced Cluster Management (RHACM) の最小制限が適用されます。
  • ストレージバックエンドにより高可用性を確保する必要があります。ハブクラスターリファレンス設定では、Red Hat OpenShift Data Foundation を通じてストレージを提供します。
  • オブジェクトバケットストレージは、OpenShift Data Foundation を通じて提供されます。
エンジニアリングに関する考慮事項
  • etcd ストレージには、低レイテンシーで高スループットの SSD または NVMe ディスクを使用してください。
  • OpenShift Data Foundation を使用するには、特に再インストール前に、ストレージディスクがクリーンであることを確認してください。詳細は、関連情報を参照してください。

  • 通信事業者ハブクラスターのストレージソリューションは OpenShift Data Foundation です。

    • Local Storage Operator は、ハブクラスター上の他のコンポーネントが必要とするブロック、ファイル、およびオブジェクトストレージを提供するために、OpenShift Data Foundation で使用されるストレージクラスをサポートしています。
  • Local Storage Operator の LocalVolume 設定には、OpenShift Data Foundation を以前使用していたハブクラスターノードの再インストールをサポートするために、forceWipeDevicesAndDestroyAllData: true 設定が含まれています。

5.10.4. Git リポジトリー
リンクのコピー

通信事業者管理ハブクラスターは、さまざまな通信事業者アプリケーション用の OpenShift クラスターの設定をインストールおよび管理するために、GitOps 主導の手法をサポートしています。この手法を実現するには、クラスター定義と設定アーティファクトの信頼できる情報源として機能する、アクセス可能な Git リポジトリーが必要です。

Red Hat は商用サポート付きの Git サーバーを提供していません。実稼働環境で提供している既存の Git サーバーを利用できます。たとえば、セルフホスト型 Git サーバーの Gitea や Gogs を使用できます。

通常、Git リポジトリーはハブクラスターの外部にある実稼働ネットワークで提供されます。大規模なデプロイメントでは、複数のハブクラスターで同じ Git リポジトリーを使用することで、マネージドクラスターの定義を維持できます。この方法を使用すると、ネットワーク全体の状態を簡単に確認できます。Git リポジトリーは、クラスター定義の信頼できる情報源として、障害発生時にも高可用性を保ち、回復可能である必要があります。

注記

障害復旧とマルチハブを考慮して、Git リポジトリーはハブクラスターとは別に運用してください。

制限と要件
  • マネージドクラスターのインストール、設定、ライフサイクル管理など、ハブクラスターの GitOps ZTP 機能をサポートするには、Git リポジトリーが必要です。
  • Git リポジトリーは管理クラスターからアクセスできる必要があります。
エンジニアリングに関する考慮事項
  • Git リポジトリーは、継続的デプロイメントを実現し、適用する設定の信頼できる唯一の情報源を確保するために、GitOps Operator によって使用されます。

5.11. ハブクラスターへの OpenShift Container Platform のインストール
リンクのコピー

説明

リファレンス設計では、ハブクラスターに OpenShift Container Platform をインストールする方法として、Agent-based Installer を使用します。

Agent-based Installer は、追加の一元的なインフラストラクチャーなしでインストール機能を提供します。Agent-based Installer は ISO イメージを作成します。管理者はこのイメージをインストールするサーバーにマウントします。サーバーを起動すると、OpenShift Container Platform が、Red Hat OpenShift GitOps Operator など、必要に応じて提供される追加のマニフェストとともにインストールされます。

注記

他のインストール方法を使用して、ハブクラスターに OpenShift Container Platform をインストールすることもできます。

ハブクラスター機能が既存の OpenShift Container Platform クラスターに適用されている場合、Agent-based Installer によるインストールは必要ありません。残りの手順、つまり Day 2 Operator をインストールし、これらの機能用にクラスターを設定する手順は同じです。OpenShift Container Platform のインストールが完了したら、追加の Operator のセットとその設定をハブクラスターにインストールする必要があります。

リファレンス設定には、すべてのカスタムリソース (CR) が含まれています。CR は手動で適用できます。次に例を示します。 

$ oc apply -f <reference_cr>

リファレンス設定を Git リポジトリーに追加し、ArgoCD を使用して適用することもできます。

注記

CR を手動で適用する場合は、必ず依存関係の順序に従って CR を適用してください。たとえば、namespace の後に Operator を適用し、Operator の後に設定を適用してください。

制限と要件
  • Agent-based Installer には、必要なすべての OpenShift Container Platform および Day 2 Operator イメージを含むアクセス可能なイメージリポジトリーが必要です。
  • Agent-based Installer は、特定の OpenShift リリースと特定のクラスターの詳細に基づいて ISO イメージをビルドします。2 番目のハブをインストールするには、別の ISO イメージをビルドする必要があります。
エンジニアリングに関する考慮事項
  • Agent-based Installer は、ベースラインの OpenShift Container Platform インストールを提供します。クラスターをインストールした後、Day 2 Operator およびその他の設定 CR を適用してください。
  • リファレンス設定は、非接続環境での Agent-based Installer のインストールに対応しています。
  • インストール時に、一部の追加マニフェストのセットを提供できます。

5.12. ハブクラスターの Day 2 Operator
リンクのコピー

管理ハブクラスターは、一連の Day 2 Operator を利用して、重要な管理サービスとインフラストラクチャーを提供します。クラスター群に含まれるマネージドクラスターのバージョンセットと一致する Operator バージョンを使用してください。

Day 2 Operator は、Operator Lifecycle Manager (OLM) と Subscription カスタムリソース (CR) を使用してインストールします。Subscription CR では、インストールする特定の Day 2 Operator、Operator が含まれるカタログ、および Operator の適切なバージョンチャネルを指定します。デフォルトでは、OLM が Operator をインストールし、チャネルで利用可能な最新の z-stream バージョンを使用して Operator を最新の状態に維持することを試みます。Subscription は、すべてデフォルトで installPlanApproval: Automatic 値を使用して設定されます。この設定では、新しい Operator バージョンがカタログとチャネルで利用可能になると、OLM によってそのバージョンが自動的にインストールされます。

注記

installPlanApproval を Automatic に設定すると、カタログインデックスが更新され、新しい Operator バージョンが追加されたときに、定められたメンテナンス期間外で Operator が更新されるリスクが生じます。非接続環境で、厳選された Operator とバージョンのセットをカタログ内で構築および維持している場合は、バージョン更新用に新しいカタログインデックスを作成する方法を採用すると、Operator が誤って更新されるリスクが大幅に軽減されます。ただし、このリスクをさらに軽減する必要がある場合は、Subscription CR を installPlanApproval: Manual に設定すると、管理者による明示的な承認なしで Operator が更新されるのを防ぐことができます。

制限と要件
  • 通信事業者ハブクラスターをアップグレードする場合、OpenShift Container Platform および Operator のバージョンが、関連するすべての互換性マトリックスの要件を満たしている必要があります。

5.13. 可観測性
リンクのコピー

Red Hat Advanced Cluster Management (RHACM) のマルチクラスターエンジンの可観測性コンポーネントは、すべてのマネージドクラスターのメトリクスとアラートを、一元的に集約して視覚化します。この監視サービスでは、パフォーマンスとデータ分析のバランスをとるために、ダウンサンプリングにより収集頻度を下げて集約された一部のメトリクスのリストを保持しています。ハブのメトリクスには、事前設定されたさまざまなダッシュボードからアクセスできます。

可観測性のインストール

オブザーバビリティサービスを有効化および設定するための主要なカスタムリソース (CR) は、Multicluster オブザーバビリティー CR であり、以下の設定を定義します。

  • 設定可能な保持設定
  • さまざまなコンポーネント (thanos receive、thanos compact、thanos rule、thanos store シャーディング、alertmanager) のストレージ

  • マネージドクラスターのモニタリング設定のチューニングを可能にする metadata.annotations.mco-disable-alerting="true" アノテーション

    注記

    この設定がない場合、可観測性コンポーネントがマネージドクラスターのモニタリング設定の実行を試みます。上記の値を設定すると、希望の設定と、アラート転送に必要な可観測性設定を、マネージドクラスター監視用の ConfigMap オブジェクトにマージできます。可観測性サービスが有効な場合、RHACM は各マネージドクラスターにワークロードをデプロイし、ローカルのモニタリングによって生成されたメトリクスとアラートをハブクラスターにプッシュします。マネージドクラスターからハブに転送されるメトリクスとアラートは、open-cluster-management-addon-observability namespace の ConfigMap CR によって定義されます。カスタムメトリクスを指定することもできます。詳細は、カスタムメトリクスの追加 を参照してください。

Alertmananger の設定
  • ハブクラスターは、メールなどの外部システムにアラートをプッシュするように設定できる Observability Alertmanager を備えています。Alertmanager はデフォルトで有効になっています。
  • アラート転送を設定する必要があります。
  • Alertmanager が有効になっているが設定されていない場合、ハブの Alertmanager はアラートを外部に転送しません。
  • 可観測性が有効な場合、ハブの Alertmanager を含む任意のエンドポイントにアラートを送信するようにマネージドクラスターを設定できます。
  • マネージドクラスターがアラートを外部ソースに転送するように設定されている場合、アラートはハブクラスター Alertmanager を経由してルーティングされません。
  • アラートの状態はメトリクスとして利用できます。
  • 可観測性が有効な場合、マネージドクラスターのアラートの状態は、ハブクラスターに転送されるメトリクスの一部に含まれ、可観測性ダッシュボードを通じて提供されます。
制限と要件
  • 可観測性には、長期間のメトリクス用に永続的なオブジェクトストレージが必要です。詳細は、「ストレージ要件」を参照してください。
エンジニアリングに関する考慮事項
  • メトリクスの転送は、すべてのメトリクスデータの一部だけが対象です。これには、observability-metrics-allowlist config map で定義されたメトリクスと、ユーザーが追加したカスタムメトリクスのみが含まれます。
  • メトリクスはダウンサンプリングにより頻度を下げて転送されます。メトリクスは、5 分間隔 (または MultiClusterObservability CR 設定で定義された間隔) で最新のデータポイントを取得して転送されます。
  • ネットワークが停止すると、その期間中にハブクラスターに転送されたメトリクスが失われる可能性があります。この問題は、マネージドクラスターからプロバイダーネットワーク内の外部メトリクスコレクターにメトリクスを直接転送すれば、軽減されます。フル分解能のメトリクスは、マネージドクラスターで利用できます。
  • ハブのデフォルトのメトリクスダッシュボードに加えて、ユーザーはカスタムダッシュボードを定義できます。
  • リファレンス設定は、3500 個のシングルノード OpenShift クラスターのハブクラスターによる 15 日間分のメトリクスを保存する前提でサイズが設定されています。より長い保持期間、またはその他のマネージドクラスタートポロジーやサイズ設定が必要な場合は、ストレージ計算を更新し、十分なストレージ容量を維持する必要があります。新しい値の計算の詳細は、「ストレージ要件」を参照してください。

5.14. マネージドクラスターのライフサイクル管理
リンクのコピー

ネットワークのファーエッジにあるサイトをプロビジョニングおよび管理するには、1 つのハブクラスターにより多数のマネージドクラスターを管理するハブアンドスポークアーキテクチャーで、GitOps ZTP を使用します。

スポーククラスターのライフサイクル管理は、OpenShift Container Platform のインストールを含むクラスターのデプロイと、クラスターの設定という 2 つの異なる段階に分けられます。

5.14.1. マネージドクラスターのデプロイ
リンクのコピー

説明
Red Hat Advanced Cluster Management (RHACM) 2.12 以降では、SiteConfig Operator を使用する方法が、マネージドクラスターのデプロイ方法として推奨されます。SiteConfig Operator は、クラスターを定義するパラメーターと、クラスターがデプロイされる方法を分離する統合された ClusterInstance API を提供します。SiteConfig Operator は、ClusterInstance カスタムリソース (CR) のデータを使用してインスタンス化される一連のクラスターテンプレートを使用して、インストールマニフェストを動的に生成します。GitOps の手法に則り、ClusterInstance CR は ArgoCD を介して Git リポジトリーから取得されます。ClusterInstance CR は、Assisted Installer またはマルチクラスターエンジンで使用可能なイメージベースのインストールを使用してクラスターのインストールを開始するのに使用できます。
制限と要件
  • SiteConfig CR を処理する SiteConfig ArgoCD プラグインは、OpenShift Container Platform 4.18 から非推奨になりました。
  • Cluster デプロイメントには、ルートファイルシステムとリリース固有の RHCOS ライブ ISO イメージをホストする HTTP サーバーが必要です。デプロイされる各 OpenShift リリースに対応する各 ISO イメージは、ハブクラスターおよびデプロイされた各スポーククラスターからアクセス可能である必要があります。AgentServiceConfig CR には、HTTP サーバー上に存在する ISO イメージのみを含めてください。
  • デプロイ済みのすべてのスポーククラスターからアクセス可能な、すべての OpenShift および Day-2 Operator Lifecycle Manager (OLM) オペレータイメージをホストするコンテナーレジストリー。ハブ設定には Kustomize オーバーレイが含まれています。これらを使用して、切断されたコンテナーレジストリーに TLS 証明書と認証情報を提供します。
エンジニアリングに関する考慮事項
  • クラスターのベースボード管理コントローラー (BMC) のログイン情報を使用して、Secret CR を作成する必要があります。この Secret CR は、SiteConfig CR で参照されます。Vault などのシークレットストアとの統合を使用して、シークレットを管理できます。
  • SiteConfig Operator は、デプロイ方法の分離と Git および非 Git ワークフローの統合を提供するだけでなく、より優れたスケーラビリティー、カスタムテンプレートの使用による柔軟性の向上、高度なトラブルシューティング機能も提供します。

5.14.2. マネージドクラスターの更新
リンクのコピー

説明

アップグレードするクラスターを対象とする Policy カスタムリソース (CR) で必要なバージョンを宣言することで、OpenShift Container Platform のバージョン、Day 2 Operator、およびマネージドクラスターの設定をアップグレードできます。

ポリシーコントローラーにより、ポリシーへの準拠状況が定期的にチェックされます。結果が非準拠の場合は、違反レポートが作成されます。ポリシー修復アクションが enforce に設定されている場合、更新されたポリシーに従って違反が修復されます。ポリシー修復アクションが inform に設定されている場合、非準拠ステータスが報告された段階でプロセスが終了します。アップグレードを開始する責任は、適切なメンテナンス期間中にアップグレードを実行できるように、ユーザーに委ねられます。

Topology Aware Lifecycle Manager (TALM) は、クラスター群のライフサイクル全体にわたってアップグレードや設定のロールアウトを管理する機能により、Red Hat Advanced Cluster Management (RHACM) を拡張します。その動作は段階的であり、限られたサイズのクラスターバッチごとに行われます。OpenShift Container Platform または Day 2 Operators のアップグレードが必要な場合、TALM は一連のポリシーを段階的に実行し、それらを "enforce" ポリシーに切り替えて、マネージドクラスターに設定をプッシュすることで、更新を段階的にロールアウトします。

TALM が修復計画を作成するために使用するカスタムリソース (CR) は、ClusterGroupUpgrade CR です。

シングルノード OpenShift クラスターの場合、プラットフォームバージョンの代替アップグレードパスとして、Lifecycle Agent を使用したイメージベースのアップグレード (IBU) を使用できます。IBU は、専用のシードクラスターから生成された OCI イメージを使用して、ターゲットクラスターにシングルノード OpenShift をインストールします。

TALM は、ImageBasedGroupUpgrade CR を使用して、特定された一連のクラスターにイメージベースのアップグレードをロールアウトします。

制限と要件
  • シングルノード OpenShift クラスターの場合、イメージベースのアップグレードを使用して、OpenShift Container Platform <4.y> から <4.y+2> および <4.y.z> から <4.y.z+n> に直接アップグレードできます。
  • イメージベースのアップグレードでは、クラスターが実行されているハードウェアプラットフォーム専用のカスタムイメージを使用します。ハードウェアプラットフォームによって必要なシードイメージが異なります。
エンジニアリングに関する考慮事項
  • エッジデプロイメントでは、変更のタイミングとロールアウトを管理することで、マネージドクラスターの中断を最小限に抑えることができます。自動適用をトリガーせずにコンプライアンスを監視するには、すべてのポリシーを inform に設定します。同様に、予定されているメンテナンス期間外で更新が行われないように、Day 2 Operator サブスクリプションを手動に設定します。
  • シングルノード OpenShift クラスターの場合、推奨されるアップグレード方法は、イメージベースのアップグレードです。

  • マルチノードクラスターのアップグレードの場合、アップグレード時間を短縮するために、次の MachineConfigPool CR 設定を検討してください。

    • paused フィールドを true に設定して、メンテナンス期間中に、ノードへの設定のデプロイを一時停止します。
    • maxUnavailable フィールドを調整して、プール内で同時に更新できるノードの数を制御します。MaxUnavailable フィールドは、MachineConfig オブジェクトの更新中に、同時に利用不可状態になってもよいプール内のノードの割合を定義します。maxUnavailable を最大許容値に設定します。これにより、アップグレード中にクラスター内で再起動する回数が減り、アップグレード時間が短縮されます。
    • paused フィールドを false に設定して、設定のデプロイを再開します。設定の変更は 1 回の再起動で適用されます。
  • クラスターのインストール中に、paused フィールドを true に設定し、maxUnavailable を 100% に設定して MachineConfigPool CR を一時停止すると、インストール時間を短縮できます。

5.15. ハブクラスターの障害復旧
リンクのコピー

通常、ハブクラスターが失われても、マネージドクラスターでサービスが停止することはありません。ハブクラスターによって提供される機能 (ハブクラスターを介して実行される可観測性、設定、ライフサイクル管理の更新など) は失われます。

制限と要件
  • バックアップ、復元、および障害復旧は、クラスターのバックアップおよび復元 Operator によって提供されます。この Operator は OpenShift API for Data Protection (OADP) Operator に依存しています。
エンジニアリングに関する考慮事項
  • 設定に応じて、クラスターのバックアップおよび復元 Operator をハブクラスターのサードパーティーリソースに拡張できます。
  • Red Hat Advanced Cluster Management (RHACM) では、クラスターのバックアップおよび復元 Operator はデフォルトでは有効になっていません。リファレンス設定ではこの機能を有効にします。

5.16. ハブクラスターのコンポーネント
リンクのコピー

5.16.1. Red Hat Advanced Cluster Management (RHACM)
リンクのコピー

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

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

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

  • RHACM のマルチクラスターエンジンコンポーネントを使用したゼロタッチプロビジョニング (ZTP) とクラスターの継続的なスケーリング。
  • RHACM ポリシーコントローラーを介した設定、アップグレード、およびクラスターのステータス。
  • RHACM は、マネージドクラスターのインストール中に、ClusterInstance CR を通じて設定されたとおりに個々のノードにラベルを適用できます。
  • RHACM の Topology Aware Lifecycle Manager コンポーネントは、マネージドクラスターへの設定変更を段階的にロールアウトします。
  • RHACM のマルチクラスターエンジンの可観測性コンポーネントは、選択的な監視、ダッシュボード、アラート、およびメトリクスを提供します。

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

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

注記

RHACM のマルチクラスターエンジンの可観測性コンポーネントを使用すると、すべてのマネージドクラスターの健全性とステータスを一元的に表示できます。デフォルトでは、すべてのマネージドクラスターは、Cluster Monitoring Operator (CMO) によって作成されたメトリクスとアラートを可観測性に送信することができます。詳細は、「可観測性」を参照してください。

制限と要件
  • 1 つのハブクラスターによって管理されるクラスターの数の制限に関する詳細は、「通信事業者管理ハブクラスターの使用モデル」を参照してください。

  • ハブによって実際に管理できるマネージドクラスターの数は、次のようなさまざまな要因によって異なります。

    • 各マネージドクラスターにおけるリソースの可用性
    • ポリシーの複雑さとクラスターのサイズ
    • ネットワーク使用量
    • ワークロードの要求と分散
  • ハブとマネージドクラスターの間に、十分な双方向接続が確立されている必要があります。
エンジニアリングに関する考慮事項
  • サードパーティーのリソースを含めるようにクラスターのバックアップおよび復元 Operator を設定できます。
  • ポリシーを通じて設定を定義するときは、RHACM ハブ側のテンプレートを使用することを強く推奨します。この機能は、クラスターごとまたはグループごとに有効にすることで、クラスター群の管理に必要なポリシーの数を削減します。たとえば、地域のコンテンツやハードウェアタイプのコンテンツをポリシーでテンプレート化し、クラスターまたはグループごとに置換します。
  • マネージドクラスターには、通常、個々のクラスターに固有の設定値がいくつかあります。このような設定値は、クラスター名に基づいて ConfigMap CR から取得した値を使用して、RHACM ポリシーハブ側のテンプレートを使用して管理してください。

5.16.2. Topology Aware Lifecycle Manager
リンクのコピー

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

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

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

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

    • オプションの事前キャッシュ設定は、PreCachingConfig CR を使用して指定します。
    • イメージのフィルタリングを設定して未使用のコンテンツを除外できます。
    • 事前キャッシュの前後に、定義された容量要件パラメーターを使用してストレージが検証されます。
制限と要件
  • TALM は、500 個のバッチでの同時クラスターアップグレードをサポートしています。
  • 事前キャッシュは、シングルノード OpenShift クラスタートポロジーに限られています。
エンジニアリングに関する考慮事項
  • PreCachingConfig カスタムリソース (CR) は任意です。OpenShift Container Platform や OLM などのプラットフォーム関連のイメージのみを事前キャッシュする場合、これを作成する必要はありません。
  • TALM は、Red Hat Advanced Cluster Management のポリシーによるハブ側テンプレートの使用をサポートしています。

5.16.3. GitOps Operator および GitOps ZTP
リンクのコピー

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

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

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

制限と要件
  • クラスターまたはノードの削除時に、マネージドクラスターとその関連リソースを一貫して完全にクリーンアップするには、バックグラウンド削除モードを使用するように ArgoCD を設定する必要があります。
エンジニアリングに関する考慮事項
  • コンテンツを更新するときに混乱や意図しない上書きを避けるために、source-crs ディレクトリーと追加のマニフェスト内のカスタム CR には、一意で区別できる名前を使用してください。
  • リファレンスソース CR をカスタム CR と別のディレクトリーに保存します。これにより、必要に応じてリファレンス CR を簡単に更新できるようになります。
  • 複数のバージョンに対応し、OpenShift Container Platform の各バージョンに対して一貫したポリシーが生成されるように、すべてのソース CR とポリシー作成 CR を、バージョン管理された Git リポジトリーに保存してください。

5.16.4. Local Storage Operator
リンクのコピー

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

5.16.5. Red Hat OpenShift Data Foundation
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Red Hat OpenShift Data Foundation は、ハブクラスターにファイル、ブロック、およびオブジェクトストレージサービスを提供します。
制限と要件
  • 内部モードの Red Hat OpenShift Data Foundation (ODF) では、必要な基盤となるストレージを提供するストレージクラスを Local Storage Operator が定義する必要があります。
  • 通信事業者管理クラスターの計画を立てる際には、ODF インフラストラクチャーとネットワーク要件を考慮してください。
  • デュアルスタックのサポートは限定的です。ODF IPv4 はデュアルスタッククラスターでサポートされています。
エンジニアリングに関する考慮事項
  • ストレージ容量が不足すると回復が困難になる可能性があるため、容量の警告にはすぐに対処してください。容量のプランニング を参照してください。

5.16.6. ロギング
リンクのコピー

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

5.16.7. OpenShift API for Data Protection
リンクのコピー

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

バックアップ機能が有効な場合、OpenShift API for Data Protection (OADP) Operator は Red Hat Advanced Cluster Management (RHACM) によって自動的にインストールされ、管理されます。

OADP Operator は、OpenShift Container Platform クラスター内のワークロードのバックアップと復元を容易にします。アップストリームのオープンソースプロジェクト Velero をベースとしており、永続ボリュームを含む特定のプロジェクトの Kubernetes リソースをすべてバックアップおよび復元できます。

ハブクラスターに OADP Operator を配置することは必須ではありません。しかし、ハブクラスターのクラスターバックアップ、障害復旧、および高可用性アーキテクチャーのために、これを配置することを強く推奨します。RHACM の障害復旧ソリューションを使用するには、OADP Operator を有効にする必要があります。リファレンス設定では、RHACM Operator によって提供される MultiClusterHub カスタムリソース (CR) を介してバックアップ (OADP) が有効になります。

制限と要件
  • クラスターには OADP の 1 つのバージョンのみインストールできます。RHACM の障害復旧機能には、RHACM によってインストールされたバージョンを使用する必要があります。
エンジニアリングに関する考慮事項
  • このリリースではエンジニアリングに関する考慮事項の更新はありません。

5.17. 通信事業者ハブリファレンス設計の設定 CR の抽出
リンクのコピー

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

前提条件

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

手順

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

    $ podman login registry.redhat.io

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

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

検証

  • out ディレクトリーのディレクトリー構造は次のとおりです。次のコマンドを実行すると、out/telco-hub-rds/ ディレクトリー内の通信事業者ハブ CR を表示できます。 

    $ tree -L 4 out/telco-hub-rds/

    出力例

    out/telco-hub-rds/
├── configuration
│   ├── example-overlays-config
│   │   ├── acm
│   │   │   ├── acmMirrorRegistryCM-patch.yaml
│   │   │   ├── kustomization.yaml
│   │   │   ├── options-agentserviceconfig-patch.yaml
│   │   │   └── storage-mco-patch.yaml
│   │   ├── gitops
│   │   │   ├── argocd-tls-certs-cm-patch.yaml
│   │   │   ├── init-argocd-app.yaml
│   │   │   └── kustomization.yaml
│   │   ├── logging
│   │   │   ├── cluster-log-forwarder-patch.yaml
│   │   │   ├── kustomization.yaml
│   │   │   └── README.md
│   │   ├── lso
│   │   │   ├── kustomization.yaml
│   │   │   └── local-storage-disks-patch.yaml
│   │   ├── odf
│   │   │   ├── kustomization.yaml
│   │   │   └── options-storage-cluster.yaml
│   │   └── registry
│   │       ├── catalog-source-image-patch.yaml
│   │       ├── idms-operator-mirrors-patch.yaml
│   │       ├── idms-release-mirrors-patch.yaml
│   │       ├── itms-generic-mirrors-patch.yaml
│   │       ├── itms-release-mirrors-patch.yaml
│   │       ├── kustomization.yaml
│   │       └── registry-ca-patch.yaml
│   ├── kustomization.yaml
│   ├── README.md
│   └── reference-crs
│       ├── kustomization.yaml
│       ├── optional
│       │   ├── logging
│       │   ├── lso
│       │   └── odf-internal
│       └── required
│           ├── acm
│           ├── gitops
│           ├── registry
│           └── talm
├── install
│   ├── mirror-registry
│   │   ├── imageset-config.yaml
│   │   └── README.md
│   └── openshift
│       ├── agent-config.yaml
│       └── install-config.yaml
└── scripts
    └── check_current_versions.sh

5.18. ハブクラスターのリファレンス設定 CR
リンクのコピー

以下のセクションでは、4.20 の通信事業者管理ハブ参照設定における各カスタムリソース (CR) について簡単に説明します。

5.19. Red Hat Advanced Cluster Management (RHACM) の CR
リンクのコピー

Expand
表5.6 RHACM CR
コンポーネントリファレンス CR説明任意

RHACM

acmAgentServiceConfig.yaml

可観測性コンポーネントが Thanos に接続できるように、Object Bucket Claim からシークレットへのデータのコピーを管理するポリシーを作成します。

いいえ

RHACM

acmMCE.yaml

ACM に必要な MultiCluster Engine 設定を定義します。

いいえ

RHACM

acmMCH.yaml

MultiClusterHub を 高可用性設定にし、各種コンポーネントを有効にし、Open Cluster Management のインストール設定を指定します。

いいえ

RHACM

acmMirrorRegistryCM.yaml

multicluster-engine namespace 内の multicluster-engine によって使用されるさまざまな Red Hat および OpenShift Container Platform レジストリーの SSL 証明書とミラーレジストリー設定を定義します。

いいえ

RHACM

acmNS.yaml

クラスター監視を有効にするためのラベルを使用して open-cluster-management namespace を定義します。

いいえ

RHACM

acmOperGroup.yaml

open-cluster-management 名前空間の OperatorGroup を定義し、同じ名前空間を対象とします。

いいえ

RHACM

acmPerfSearch.yaml

さまざまなパラメーターと API 設定を定義して、Open Cluster Management の検索を設定します。

いいえ

RHACM

acmProvisioning.yaml

すべての namespace を監視するように、metal3.io/v1alpha1 API バージョンでプロビジョニングリソースを設定します。

いいえ

RHACM

acmSubscription.yaml

インストールプランの自動承認を使用して RHACM Operator にサブスクライブします。

いいえ

RHACM

observabilityMCO.yaml

複数のクラスターにわたる可観測性とアラートを管理するために MultiClusterObservability を設定します。

いいえ

RHACM

observabilityNS.yaml

open-cluster-management-observability namespace を作成します。

いいえ

RHACM

observabilityOBC.yaml

open-cluster-management-observability namespace に ObjectBucketClaim CR を作成します。

いいえ

RHACM

observabilitySecret.yaml

コンテナー設定の詳細を保存するために、open-cluster-management- オブザーバビリティー 名前空間に シークレット CR を作成します。

いいえ

RHACM

pullSecretMCSB.yaml

プルシークレットポリシー用の ManagedClusterSetBinding を作成します。

いいえ

RHACM

pullSecretPlacementBinding.yaml

プルシークレットポリシーに必要な PlacementBinding を作成します。

いいえ

RHACM

pullSecretPlacement.yaml

プルシークレットポリシーに必要なローカルクラスターに対する配置を作成します。

いいえ

RHACM

pullSecretPolicy.yaml

グローバルプルシークレットを可観測性関連の namespace にコピーするためのポリシーを作成します。

いいえ

RHACM

thanosSecretPlacementBinding.yaml

Thanos の秘密ポリシーに必要な PlacementBinding を作成します。

いいえ

RHACM

thanosSecretPlacement.yaml

Thanos シークレットポリシーに必要なローカルクラスターに対する配置を作成します。

いいえ

RHACM

thanosSecretPolicy.yaml

可観測性コンポーネントが Thanos に接続できるように、Object Bucket Claim からシークレットにデータをコピーするポリシーを作成します。

いいえ

TALM

talmSubscription.yaml

TALM の Subscription CR を作成します。

いいえ

5.20. ストレージのリファレンス CR
リンクのコピー

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

Local Storage Operator

lsoLocalVolume.yaml

ローカルストレージ設定とノード選択基準を指定する LocalVolume CR を定義します。

はい

Local Storage Operator

lsoNS.yaml

openshift-local-storage namespace を定義します。

はい

Local Storage Operator

lsoOperatorGroup.yaml

openshift-local-storage namespace の OperatorGroup を定義します。

はい

Local Storage Operator

lsoSubscription.yaml

Local Storage Operator の Subscription CR を定義します。

はい

OpenShift Data Foundation

odfNS.yaml

ワークロード管理およびクラスター監視用の特定のアノテーションとラベルを使用して openshift-storage namespace を定義します。

はい

OpenShift Data Foundation

odfOperatorGroup.yaml

openshift-storage namespace の OperatorGroup を定義します。

はい

OpenShift Data Foundation

odfReady.yaml

ODF デプロイメントの準備状況を検証するためのリソースを定義します。

はい

OpenShift Data Foundation

odfSubscription.yaml

OpenShift Data Foundation Operator への OpenShift Container Platform サブスクリプションを設定し、Operator の名前、namespace、チャネル、承認ストラテジーなどのインストールの詳細を指定します。

はい

5.21. GitOps ゼロタッチプロビジョニング (ZTP) のリファレンス CR
リンクのコピー

Expand
表5.8 GitOps ZTP CR
コンポーネントリファレンス CR説明任意

GitOps Operator

argocd-ssh-known-hosts-cm.yaml

非接続環境で ArgoCD によって使用される SSH の known hosts を保存するための ConfigMap CR を定義します。

いいえ

GitOps Operator

addPluginsMCSB.yaml

GitOps Operator のパッチ適用に使用されるポリシーの ManagedClusterSetBinding を定義します。

いいえ

GitOps Operator

addPluginsPolicyNS.yaml

GitOps プラグインポリシーの名前空間。

いいえ

GitOps Operator

addPluginsPolicyPlacementBinding.yaml

GitOps プラグインポリシーの PlacementBinding を 定義します。

いいえ

GitOps Operator

addPluginsPolicyPlacement.yaml

GitOps プラグインポリシーのローカルクラスターに対する配置 CR を定義します。

いいえ

GitOps Operator

addPluginsPolicy.yaml

GitOps コントローラーに ArgoCD カスタムプラグインを追加するためのポリシーを定義します。

いいえ

GitOps Operator

argocd-application.yaml

GitOps 管理用の ArgoCD アプリケーションを定義します。

いいえ

GitOps Operator

argocd-tls-certs-cm.yaml

ArgoCD TLS 証明書管理用の ConfigMap CR を定義します。

いいえ

GitOps Operator

clusterrole.yaml

GitOps Operator に権限を付与する ClusterRole CR を定義します。

いいえ

GitOps Operator

clusterrolebinding.yaml

ClusterRole CR を ArgoCD コントローラーの ServiceAccount CR にバインドします。

いいえ

GitOps Operator

gitopsNS.yaml

クラスター監視用のラベルを使用して openshift-gitops-operator namespace を定義します。

いいえ

GitOps Operator

gitopsOperatorGroup.yaml

openshift-gitops-operator 名前空間に、デフォルトのアップグレードストラテジーを持つ OperatorGroup を 定義します。

いいえ

GitOps Operator

gitopsSubscription.yaml

インストールプランの自動承認とソースの詳細を指定して、OpenShift Container Platform GitOps Operator のサブスクリプションを定義します。

いいえ

GitOps Operator

ztp-repo.yaml

ZTP マニフェストと設定の Git リポジトリーを定義します。

いいえ

GitOps アプリケーション

app-project.yaml

クラスターおよび namespace リソースのリソースホワイトリストと宛先ルールを指定して、ArgoCD AppProject CR を定義します。

いいえ

GitOps アプリケーション

clusters-app.yaml

指定された Git リポジトリーからのクラスター設定のデプロイを管理するための namespace と ArgoCD アプリケーションを定義します。

いいえ

GitOps アプリケーション

gitops-cluster-rolebinding.yaml

openshift-gitops 名前空間内の openshift-gitops-argocd-application-controller サービスアカウントに cluster-admin ロールを付与する ClusterRoleBinding CR を定義します。

いいえ

GitOps アプリケーション

gitops-policy-rolebinding.yaml

cluster-manager-admin クラスターロールを ArgoCD アプリケーションコントローラーの ServiceAccount CR にバインドします。

いいえ

GitOps アプリケーション

policies-app-project.yaml

クラスターおよび namespace リソースのホワイトリストと宛先を指定して、Argo CD AppProject リソースを定義します。

いいえ

GitOps アプリケーション

policies-app.yaml

ポリシー管理のための名前空間と ArgoCD アプリケーションを定義します。

いいえ

5.22. ロギングのリファレンス CR
リンクのコピー

Expand
表5.9 ロギング CR
コンポーネントリファレンス CR説明任意

Cluster Logging Operator

clusterLogForwarder.yaml

設定済みの出力にログを送信する ClusterLogForwarder CR を定義します。

はい

Cluster Logging Operator

clusterLogNS.yaml

Cluster Logging Operator の namespace を設定します。

はい

Cluster Logging Operator

clusterLogOperGroup.yaml

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

はい

Cluster Logging Operator

clusterLogServiceAccount.yaml

Cluster Logging Operator コンポーネントによって使用される ServiceAccount CR を定義します。

はい

Cluster Logging Operator

clusterLogServiceAccountAuditBinding.yaml

クラスターロギング用の ServiceAccount CR を監査ログ関連のロールにバインドします。

はい

Cluster Logging Operator

clusterLogServiceAccountInfrastructureBinding.yaml

クラスターロギング用の ServiceAccount CR をインフラストラクチャーログ関連のロールにバインドします。

はい

Cluster Logging Operator

clusterLogSubscription.yaml

Cluster Logging Operator をインストールおよび管理するためのサブスクリプションを定義します。

はい

5.23. コンテナーレジストリーのリファレンス CR
リンクのコピー

Expand
表5.10 コンテナーレジストリー CR
コンポーネントリファレンス CR説明任意

レジストリー

catalog-source.yaml

ミラーリングされた Operator カタログのために、CatalogSource CR を定義します。

いいえ

レジストリー

idms-operator.yaml

ミラーリングされた Operator イメージのイメージダイジェスト MirrorSet Operator CR を定義します。

いいえ

レジストリー

idms-release.yaml

OpenShift Container Platform リリースイメージのイメージダイジェスト MirrorSet CR を定義します。

いいえ

レジストリー

image-config.yaml

イメージレジストリーとポリシーを管理するためのイメージ設定 CR を定義します。

いいえ

レジストリー

itms-generic.yaml

非接続レジストリー内のミラーリングされたイメージのイメージタグ MirrorSet CR を定義します。

いいえ

レジストリー

itms-release.yaml

OpenShift Container Platform リリースイメージのイメージタグ MirrorSet CR を定義します。

いいえ

レジストリー

operator-hub.yaml

オフラインカタログソース用の OperatorHub CR を設定します。

いいえ

レジストリー

registry-ca.yaml

レジストリーの CA 証明書を含む ConfigMap CR を定義します。

いいえ

5.24. イメージミラーリング参照 CR
リンクのコピー

Expand
表5.11 イメージミラーリング CR
コンポーネントリファレンス CR説明任意

設定ミラーリン CR

imageset-config.yaml

OpenShift Container Platform のチャネルと Operator パッケージをミラーリングするための ImageSetConfiguration CR を定義し、バージョンとターゲットカタログを指定します。

いいえ

5.25. インストールのリファレンス CR
リンクのコピー

Expand
表5.12 インストール CR
コンポーネントリファレンス CR説明任意

エージェントベースのインストール

agent-config.yaml

この agent-config.yaml テンプレートを使用して、エージェントベースのインストーラーを設定し、インストール対象ホストのネットワーク設定とデバイス設定を指定します。

いいえ

エージェントベースのインストール

install-config.yaml

この install-config.yaml テンプレートを使用して、ネットワーク、コントロールプレーン、コンピュートノード、ミラーレジストリーなど、ハブクラスターのインストールを設定します。

いいえ

5.26. 通信事業者ハブリファレンス設定のソフトウェア仕様
リンクのコピー

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

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

OpenShift Container Platform

4.20

Red Hat Advanced Cluster Management (RHACM)

2.15

Local Storage Operator

4.20

Red Hat OpenShift Data Foundation (ODF)

4.20

Red Hat OpenShift GitOps

1.18

GitOps ゼロタッチプロビジョニング (ZTP) プラグイン

4.20

multicluster engine Operator PolicyGenerator プラグイン

2.10

Topology Aware Lifecycle Manager (TALM)

4.20

Cluster Logging Operator

6.2

OpenShift API for Data Protection (OADP)

RHACM のリリースと同じバージョン番号

第6章 クラスター設定の比較
リンクのコピー

6.1. cluster-compare について
リンクのコピー

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

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

6.1.1. cluster-compare プラグインの概要
リンクのコピー

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

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

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

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

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

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

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

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

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

cluster-compare プラグインの概要

6.1.2. リファレンス設定について
リンクのコピー

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

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

├── metadata.yaml
1 

├── optional
2 

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

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

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

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

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

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

6.2. cluster-compare プラグインのインストール
リンクのコピー

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

6.2.1. cluster-compare プラグインのインストール
リンクのコピー

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

前提条件

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

手順

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

    $ podman login registry.redhat.io

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

    $ podman create --name cca registry.redhat.io/openshift4/kube-compare-artifacts-rhel9:latest

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

    $ podman cp cca:/usr/share/openshift/<arch>/kube-compare.<rhel_version> <directory_on_path>/kubectl-cluster_compare

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

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

検証

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

    $ oc cluster-compare -h

    出力例

    Compare a known valid reference configuration and a set of specific cluster configuration CRs.

...

Usage:
  compare -r <Reference File>

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

 ...

6.3. cluster-compare プラグインの使用
リンクのコピー

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

6.3.1. ライブクラスターでの cluster-compare プラグインの使用
リンクのコピー

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

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

注記

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

前提条件

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

手順

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

    $ oc cluster-compare -r <path_to_reference_config>/metadata.yaml

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

      出力例

      ...

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

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

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

…

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

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

コマンドに -o junit を追加して、junit 形式で出力を取得します。以下に例を示します。 

$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -o junit

junit の出力には次のタイプの結果が含まれています。

  • 完全に一致した各テンプレートに対する合格の結果。
  • 差異の検出や必須のカスタムリソース (CR) の欠落に対する不合格の結果。
  • ユーザーのオーバーライドメカニズムを使用してパッチが適用された差異に対するスキップの結果。

6.3.2. must-gather データでの cluster-compare プラグインの使用
リンクのコピー

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

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

注記

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

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

手順

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

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

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

      出力例

      ...

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

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

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

…

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

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

コマンドに -o junit を追加して、junit 形式で出力を取得します。以下に例を示します。 

$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -f "must-gather*/*/cluster-scoped-resources","must-gather*/*/namespaces" -R -o junit

junit の出力には次のタイプの結果が含まれています。

  • 完全に一致した各テンプレートに対する合格の結果。
  • 差異の検出や必須のカスタムリソース (CR) の欠落に対する不合格の結果。
  • ユーザーのオーバーライドメカニズムを使用してパッチが適用された差異に対するスキップの結果。

6.3.3. cluster-compare プラグインのオプションのリファレンス
リンクのコピー

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

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

-A、--all-resources

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

--concurrency

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

-c、--diff-config

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

-f、--filename

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

--generate-override-for

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

--show-template-functions

使用可能なテンプレート関数を表示します。

注記

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

-h、--help

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

-k、--kustomize

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

-o、--output

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

--override-reason

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

-p、--overrides

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

-R、--recursive

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

-r、--reference

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

--show-managed-fields

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

-v、--verbose

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

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

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

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

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

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

前提条件

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

手順

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

    $ podman login registry.redhat.io

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

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

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

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

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

    $ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml

    出力例

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

...

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

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

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

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

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

コマンドに -o junit を追加して、junit 形式で出力を取得します。以下に例を示します。 

$ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml -o junit

junit の出力には次のタイプの結果が含まれています。

  • 完全に一致した各テンプレートに対する合格の結果。
  • 差異の検出や必須のカスタムリソース (CR) の欠落に対する不合格の結果。
  • ユーザーのオーバーライドメカニズムを使用してパッチが適用された差異に対するスキップの結果。

6.4. リファレンス設定の作成
リンクのコピー

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

6.4.1. metadata.yaml ファイルの構造
リンクのコピー

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

metadata.yaml ファイルの例

apiVersion: v2
parts:
1 

  - name: Part1
2 

    components:
      - name: Component1
3 

        <component1_configuration>
4 

  - name: Part2
      - name: Component2
        <component2_configuration>

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

6.4.2. テンプレートの関係の設定
リンクのコピー

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

手順

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

    metadata.yaml ファイルの例

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

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

6.4.3. テンプレートで想定内の差異を設定する
リンクのコピー

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

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

手順

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

    apiVersion: v2
kind: Service
metadata:
  name: frontend
    1 
    
  namespace: {{ .metadata.namespace }}
    2 
    
  labels:
    app: guestbook
    tier: frontend
spec:
  {{- if and .spec.type (eq (.spec.type) "NodePort" "LoadBalancer") }}
  type: {{.spec.type }}
    3 
    
  {{- else }}
  type: should be NodePort or LoadBalancer
  {{- end }}
  ports:
  - port: 80
  selector:
    app: guestbook
    {{- if .spec.selector.tier }}
    4 
    
    tier: frontend
    {{- end }}
    1
    指定の値と一致する必要がある必須フィールドを設定します。
    2
    任意の値を持つことができる必須フィールドを設定します。
    3
    .spec.type フィールドの検証を設定します。
    4
    任意のフィールドを設定します。
6.4.3.1. リファレンステンプレート関数
リンクのコピー

cluster-compare プラグインは、env 関数と expandenv 関数を除くすべての sprig ライブラリー関数をサポートします。sprig ライブラリー関数の完全なリストは、「Sprig Function Documentation」を参照してください。

次の表は、cluster-compare プラグインの追加のテンプレート関数を説明しています。

Expand
表6.2 追加の cluster-compare テンプレート関数
機能説明例

fromJson

受信した文字列を構造化 JSON オブジェクトとして解析します。

value: {{ obj := spec.jsontext | fromJson }}{{ obj.field }}

fromJsonArray

受信した文字列を構造化 JSON 配列として解析します。

value: {{ obj := spec.jsontext | fromJson}}{{ index $obj 0 }}

fromYaml

受信した文字列を構造化 YAML オブジェクトとして解析します。

value: {{ obj := spec.yamltext | fromYaml }}{{ obj.field }}

fromYamlArray

受信した文字列を構造化 YAML 配列として解析します。

value: {{ obj := spec.yamltext | fromYaml}}{{ index $obj 0 }

toJson

オブジェクトタイプを保持しながら、受信したデータを JSON 形式でレンダリングします。

jsonstring: {{ $variable | toJson }}

toToml

受信した文字列を構造化 TOML データとしてレンダリングします。

tomlstring: {{ $variable | toToml }}

toYaml

オブジェクトタイプを保持しながら、受信したデータを YAML 形式でレンダリングします。

単純なスカラー値の場合: value: {{ $data | toYaml }}

リストまたはディクショナリーの場合: value: {{ $dict | toYaml | nindent 2 }}

doNotMatch

通常はマッチするテンプレートでも、クラスターリソースとマッチしないようにします。テンプレート内でこの関数を使用すると、条件に応じて特定のリソースを相関付けから除外できます。--verbose フラグを付けて実行すると、指定した理由がログに記録されます。doNotMatch により除外されたテンプレートが、比較で不合格とみなされることはありません。

この関数は、テンプレートで固定の名前または namespace が指定されていない場合に特に便利です。このような場合、doNotMatch 関数を使用すると、labels や annotations などの他のフィールドに基づいて特定のリソースを除外できます。

{{ if $condition }}{{ doNotMatch $reason }}{{ end }}

lookupCRs

指定されたパラメーターにマッチするオブジェクトの配列を返します。たとえば、lookupCRs $apiVersion $kind $namespace $name などです。

$namespace パラメーターが空の文字列 ("") または * の場合、この関数はすべての namespace にマッチします。クラスタースコープのオブジェクトの場合、この関数は namespace のないオブジェクトにマッチします。

$name が空の文字列または * の場合、この関数はすべての名前付きオブジェクトにマッチします。

-

lookupCR

パラメーターにマッチする単一のオブジェクトを返します。複数のオブジェクトがマッチする場合、この関数は何も返しません。この関数は lookupCRs 関数と同じ引数を取ります。

-

次の例は、lookupCRs 関数を使用して、マッチする複数のリソースから値を取得してレンダリングする方法を示しています。

lookupCRs を使用した config map の例

kind: ConfigMap
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-settings
  namespace: kubernetes-dashboard
data:
  dashboard: {{ index (lookupCR "apps/v1" "Deployment" "kubernetes-dashboard" "kubernetes-dashboard") "metadata" "name" \| toYaml }}
  metrics: {{ (lookupCR "apps/v1" "Deployment" "kubernetes-dashboard" "dashboard-metrics-scraper").metadata.name \| toYaml }}

次の例は、lookupCR 関数を使用して、マッチする単一のリソースから特定の値を取得して使用する方法を示しています。

lookupCR を使用した config map の例

kind: ConfigMap
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-settings
  namespace: kubernetes-dashboard
data:
  {{- $objlist := lookupCRs "apps/v1" "Deployment" "kubernetes-dashboard" "*" }}
  {{- $dashboardName := "unknown" }}
  {{- $metricsName := "unknown" }}
  {{- range $obj := $objlist }}
    {{- $appname := index $obj "metadata" "labels" "k8s-app" }}
    {{- if contains "metrics" $appname }}
      {{- $metricsName = $obj.metadata.name }}
    {{- end }}
    {{- if eq "kubernetes-dashboard" $appname }}
      {{- $dashboardName = $obj.metadata.name }}
    {{- end }}
  {{- end }}
  dashboard: {{ $dashboardName }}
  metrics: {{ $metricsName }}

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

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

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

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

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

    注記

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

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

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

手順

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

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

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

手順

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

    metadata.yaml ファイルの例

    apiVersion: v2
parts:

#...

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

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

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

手順

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

    metadata.yaml ファイルの例

    apiVersion: v2
parts:
  - name: Part1
    components:
      - name: Component1
        - path: deployment.yaml
          config:
            fieldsToOmitRefs:
              - deployments
    1 
    

#...

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

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

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

6.4.4.4. デフォルトの除外グループを設定して特定のフィールドを除外する
リンクのコピー

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

手順

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

    metadata.yaml ファイルの例

    apiVersion: v2
parts:

#...

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

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

6.4.5. テンプレートフィールドのインライン検証の設定
リンクのコピー

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

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

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

インライン検証に regex または capturegroups 関数のいずれかを使用する場合、cluster-compare プラグインは、テンプレート内の複数のフィールドにわたって、同じ名前のキャプチャーグループが同じ値を持つことを強制します。つまり、(?<username>[a-z0-9]+) などの名前付きキャプチャーグループが複数のフィールドに現れる場合、そのグループの値がテンプレート全体で一貫している必要があります。

6.4.5.1. 正規表現関数を使用したインライン検証の設定
リンクのコピー

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

手順

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

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

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

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

マルチライン文字列を含むフィールドをより正確に検証するには、capturegroups インライン関数を使用します。この関数は、複数のフィールドにわたって、同じ名前のキャプチャーグループが同じ値を持つことを確認します。

手順

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

    apiVersion: v2
parts:
- name: Part1
  components:
  - name: Example
    allOf:
    - path: example.yaml
      config:
        perField:
        - pathToKey: data.username
    1 
    
          inlineDiffFunc: regex
    2 
    
        - pathToKey: spec.bigTextBlock
    3 
    
          inlineDiffFunc: capturegroups
    4
    1
    インライン検証の対象とするフィールドを指定します。
    2
    キャプチャーグループを使用したインライン検証を有効にします。
    3
    キャプチャーグループ検証の対象とするマルチラインフィールドを指定します。
    4
    キャプチャーグループを使用したインライン検証を有効にします。

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

    apiVersion: v1
kind: ConfigMap
metadata:
  namespace: dashboard
data:
  username: "(?<username>[a-z0-9]+)"
    1 
    
  bigTextBlock: |-
    This static content outside of a capture group should match exactly.
    Here is a username capture group: (?<username>[a-z0-9]+).
    It should match this capture group: (?<username>[a-z0-9]+).
    1
    data.username フィールドのユーザー名の値と bigTextBlock でキャプチャーされた値が一致しない場合、cluster-compare プラグインは不一致に関する警告を出力します。

    不一致に関する警告を含む出力例:

    WARNING: Capturegroup (?<username>…) matched multiple values: « mismatchuser | exampleuser »

6.4.6. 出力の説明の設定
リンクのコピー

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

手順

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

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

6.5. リファレンス設定の高度なカスタマイズ
リンクのコピー

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

警告

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

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

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

6.5.1. CR とテンプレート間の手動マッチングの設定
リンクのコピー

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

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

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

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

手順

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

    user-config.yaml ファイルの例

    correlationSettings:
    1 
    
   manualCorrelation:
    2 
    
      correlationPairs:
    3 
    
        ptp.openshift.io/v1_PtpConfig_openshift-ptp_grandmaster: optional/ptp-config/PtpOperatorConfig.yaml
    4 
    
        ptp.openshift.io/v1_PtpOperatorConfig_openshift-ptp_default: optional/ptp-config/PtpOperatorConfig.yaml

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

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

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

6.5.2. リファレンス設定へのパッチ適用
リンクのコピー

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

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

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

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

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

手順

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

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

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

      注記

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

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

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

    patch-config ファイルの例

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

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

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

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

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

      出力例

      ...

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

...

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

6.5.2.2. パッチファイルの手動作成
リンクのコピー

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

注記

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

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

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

手順

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

    patch-config の例

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

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

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

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

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

      出力例

      ...

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

...

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

6.6. cluster-compare のトラブルシューティング
リンクのコピー

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

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

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

手順

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

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

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

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

手順

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

第7章 オブジェクトの最大値に合わせた環境計画
リンクのコピー

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

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

警告

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

7.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 を内包できる規模のネットワークを割り当てるために hostPrefix を 20 に設定し、カスタム kubelet 設定で maxPods を 2500 に設定する必要があります。詳細は、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、メモリー、およびディスクがシステムにあることが前提となっています。

デフォルトの 2 ルーターデプロイメントあたりのルート数

9,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.20、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 のクラスターノードリソース消費量
  • メモリーのクラスターノードリソース消費量

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

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

7.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 のコンピュートノードという段階的な増加で拡張されます。性能およびスケーラビリティーテストは、指定されたノード数で実行されます。

7.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 およびレジストリーコンポーネントをホストするために使用され、これにより、それらが大規模に実行する場合に必要とするリソースを十分に確保することができます。
ワークロード
ワークロードノードは、パフォーマンスとスケーラビリティーのワークロードジェネレーターを実行するための専用ノードです。
作業負荷.120
パフォーマンスおよびスケーラビリティーのテストの実行中に収集される大容量のデータを保存するのに十分な領域を確保できるように、大きなディスクサイズが使用されます。
2 から 100 までを計算します。
クラスターは反復でスケーリングされます。

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

7.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 が含まれており、これらはデフォルトで全てのコンピュートノード上で実行されます。したがって、上記の式の結果は異なる場合があります。

7.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 を実行できます。

第8章 クォータと制限範囲の使用
リンクのコピー

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

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

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

重要

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

8.1. クォータで管理されるリソース
リンクのコピー

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

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

注記

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

Expand
表8.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
表8.2 クォータで管理されるストレージリソース
リソース名説明

requests.storage

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

persistentvolumeclaims

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

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

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

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

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

Expand
表8.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 コマンドを使用できます。

8.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 を割り当てようとしたためです。これは、許可されているクォータを超えています。

8.3. クォータのスコープ
リンクのコピー

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

Expand
スコープ説明

Terminating

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

NotTerminating

spec.activeDeadlineSeconds が nil の Pod に一致します。

BestEffort

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

NotBestEffort

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

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

  • pods

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

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

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

8.5. 管理者のクォータ使用量
リンクのコピー

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

クォータの実施

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

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

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

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

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

リクエストと制限の比較

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

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

8.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.activeDeadlineSeconds が nil に設定されている 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 に設定すると、ブロンズストレージクラスはクレームを作成できません。

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

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

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

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

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

8.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
# ...

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

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

8.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
制限範囲オブジェクトの名前を指定します。
最大 CPU
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大 CPU 量を指定します。
最大メモリー
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大メモリー量を指定します。
最小 CPU
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小 CPU 量を指定します。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
最小メモリー
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小メモリー量を指定します。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
最大 CPU
Pod 内の単一コンテナーが要求できる最大 CPU 量を指定します。
最大メモリー
Pod 内の単一コンテナーが要求できる最大メモリー量を指定します。
最小 CPU
Pod 内の単一コンテナーが要求できる最小 CPU 量を指定します。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
最大メモリー
Pod 内の単一コンテナーが要求できる最小メモリー量を指定します。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
デフォルト.CPU
Pod 仕様で制限を指定しない場合に、コンテナーのデフォルトの CPU 制限を指定します。
デフォルトメモリー
Pod の仕様でメモリー制限を指定しない場合に、コンテナーのデフォルトのメモリー制限を指定します。
defaultRequest.cpu
Pod 仕様で要求を指定しない場合に、コンテナーのデフォルトの CPU 要求を指定します。
デフォルトリクエストのメモリー
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.openshift.io/image-tags
イメージストリームの仕様で定義されている、一意のイメージタグの最大数を指定します。
limits.max.openshift.io/images
イメージストリームの状態に関する仕様で定義されている、一意のイメージ参照の最大数を指定します。
タイプ.最大 CPU
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大 CPU 量を指定します。
タイプ.最大メモリー
ノード上のすべてのコンテナーにおいて、Pod が要求できる最大メモリー量を指定します。
タイプ.最大一時ストレージ
ノード上のすべてのコンテナーにおいて、Pod が要求できる一時ストレージの最大量を指定します。
最小 CPU
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小 CPU 量を指定します。重要な情報は、「サポートされる制約」の表を参照してください。
最小メモリー
ノード上のすべてのコンテナーにおいて、Pod が要求できる最小メモリー量を指定します。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。

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

8.7.1. コンテナーの制限
リンクのコピー

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

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

  • CPU
  • メモリー

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

Expand
制約動作

Min

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

設定で min CPU を定義している場合、要求値はその CPU 値よりも大きくなければなりません。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max 値よりも多くのリソースを消費できます。

Max

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

設定で max CPU を定義している場合、CPU 要求値を定義する必要はありません。ただし、制限範囲で指定される最大 CPU 制約を満たす制限を設定する必要があります。

MaxLimitRequestRatio

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

制限範囲で maxLimitRequestRatio 制約を定義する場合、新規コンテナーには request と limit 値の両方が必要になります。さらに OpenShift Container Platform は、limit を request で除算して、制限の要求に対する比率を算出します。結果は、1 を超える整数である必要があります。

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

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

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

8.7.2. Pod の制限
リンクのコピー

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

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

  • CPU
  • メモリー

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

Expand
制約強制された行動

Min

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

Max

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

MaxLimitRequestRatio

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

8.7.3. イメージの制限
リンクのコピー

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

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

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

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

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

Max

image.dockerimagemetadata.size は Max[<resource>] 以下

注記

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

8.7.4. イメージストリームの制限
リンクのコピー

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

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

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

openshift.io/image-tags リソースは、一意のストリーム制限を表します。使用可能な参照は、ImageStreamTag、ImageStreamImage、または 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 はステータスタグにある一意のイメージ名を返します。名前はイメージのダイジェストと等しくなります。

8.7.5. PersistentVolumeClaim の制限
リンクのコピー

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

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

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

Expand
表8.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
制限範囲オブジェクトの名前を指定します。
制限.最小ストレージ
永続ボリューム要求で要求できる最小ストレージ容量を指定します。
制限.最大ストレージ
永続ボリューム要求で要求できるストレージの最大容量を指定します。

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

第10章 Node Tuning Operator の使用
リンクのコピー

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

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

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

10.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 ^ {} \;

10.4. TuneD プロファイルが適用されていることの確認
リンクのコピー

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

手順

  1. クラスターノードに適用されている 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 オブジェクトの作成からの経過時間。

  2. ClusterOperator/node-tuning オブジェクトの状態情報を取得するには、次のコマンドを実行します。 

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

    出力例

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

    ClusterOperator/node-tuning オブジェクトには、Operator とそのノードエージェントの状態に関する有用な情報も含まれています。たとえば、Operator の設定ミスは、ClusterOperator/node-tuning ステータスメッセージによって報告されます。

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

10.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:
    <mcLabels>
  match:
    <match>
  priority: <priority>
  profile: <tuned_profile_name>
  operand:
    debug: <bool>
    tunedConfig:
      reapply_sysctl: <bool>

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

  • machineConfigLabels: オプション。
  • <mcLabels>: キーと値のペアで 設定される MachineConfig ラベルのディクショナリー。キーは一意である必要があります。
  • match: 省略した場合、より高い優先順位のプロファイルが先に一致するか、machineConfigLabels が設定されていない限り、プロファイルの一致が想定されます。
  • <match>: オプションのリスト。
  • <priority>: プロファイルの順序付けの優先順位。数値が小さいほど優先度が高くなります (0 が最も高い優先度になります)。
  • <tuned_profile_name>: 試合に適用する TuneD プロファイル。たとえば、tuned_profile_1 です。
  • operand: オプションのオペランド設定。
  • debug:TuneD デーモンのデバッグを有効または無効にします。オプションは、オンの場合は true、オフの場合は false です。デフォルトは false です。
  • reapply_sysctl: TuneD デーモンの reapply_sysctl 機能を有効または無効にします。オプションは on で true、オフの場合は false です。

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

- label: <label_name>
  value: <label_value>
  type: <label_type>
    <match>

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

  • <label_name>: ノードまたは Pod のラベル名。
  • <label_value>: オプションのノードまたは Pod のラベル値。省略されている場合も、<label_name> があるだけで一致条件を満たします。
  • <label_type>: オプションのオブジェクトタイプ (ノード または Pod)。省略されている場合は、node が想定されます。
  • <match>: オプションの <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 プロファイルとその子プロファイルによって上書きされます。

10.6. カスタムチューニングの例
リンクのコピー

以下の例は、Node Tuning Operator を使用して OpenShift Container Platform ノードのカスタムチューニング設定を行う方法を示しています。

デフォルト 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

10.7. チューニング変更の適用の延期
リンクのコピー

管理者は、Node Tuning Operator (NTO) を使用して、実行中のシステム上のカスタムリソース (CR) を更新し、チューニングの変更を行います。たとえば、チューニングするオブジェクトの [sysctl] セクションで sysctl パラメーターを更新または追加することがあります。管理者がチューニングの変更を適用すると、NTO は TuneD にすべての設定を再処理するように要求します。その結果、チューニングされるプロセスですべてのチューニングがロールバックされてから再適用されます。

レイテンシーの影響を受けやすいアプリケーションでは、パフォーマンスが一時的に低下する可能性があるため、TuneD プロファイルの削除と再適用が許容されない場合があります。これは、CPU パーティショニングを実行し、パフォーマンスプロファイルを使用してプロセスまたは割り込みのアフィニティーを管理する設定の場合に特に重要です。この問題を回避するために、OpenShift Container Platform ではチューニングの変更を適用するための新しい方法が導入されました。OpenShift Container Platform 4.17 より前は、利用できる方法は immediate だけでした。この方法では、変更がすぐに適用され、多くの場合、チューニングされた再起動がトリガーされていました。

これに加えて次の方法がサポートされています。

  • always: すべての変更が次回のノードの再起動時に適用されます。
  • update: チューニングの変更によって TuneD プロファイルが変更されると、デフォルトですぐに適用され、できるだけ早く反映されます。チューニングの変更によって TuneD プロファイルが変更されず、プロファイルの値がその場で変更された場合、変更は always として処理されます。

この機能を有効にするには、アノテーション tuned.openshift.io/deferred を追加します。次の表は、アノテーションに使用できる値をまとめたものです。

Expand
アノテーション値説明

missing

変更がすぐに適用されます。

always

変更が次回のノードの再起動時に適用されます。

update

変更によってプロファイルが変更された場合はすぐに適用されます。それ以外の場合は次のノードの再起動時に適用されます。

次の例は、always 方式を使用して kernel.shmmni sysctl パラメーターに変更を適用する方法を示しています。

例

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  annotations:
    tuned.openshift.io/deferred: "always"
spec:
  profile:
    - name: performance-patch
      data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-performance
        [sysctl]
        kernel.shmmni=8192
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: worker-cnf
      priority: 19
      profile: performance-patch

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

  • include ディレクティブは、openshift-node-performance-performance プロファイルを継承するために使用します。これは、プロファイルから必要な設定が欠落するのを防ぐためのベストプラクティスです。
  • kernel.shmmni sysctl パラメーターを 8192 に変更します。
  • machineConfigLabels フィールドは、worker-cnf ロールをターゲットにするために使用します。プロファイルが正しいノードにのみ適用されるように、MachineConfigPool リソースを設定します。
注記

Topology Aware Lifecycle Manager を使用すると、スポーククラスター群全体の再起動を制御し、チューニングの変更を遅らせて適用できます。再起動の調整の詳細は、「設定変更のための再起動の調整」を参照してください。

10.7.1. チューニング変更の適用の延期: 例
リンクのコピー

次の実例では、Node Tuning Operator を使用してチューニング変更の適用を延期する方法を説明します。

前提条件

  • cluster-admin ロールへのアクセス権がある。
  • クラスターにパフォーマンスプロファイルを適用した。
  • プロファイルが指定のノードにのみ適用されるように、MachineConfigPool リソース (worker-cnf など) が設定されている。

手順

  1. 次のコマンドを実行して、クラスターに現在適用されているプロファイルを確認します。 

    $ oc -n openshift-cluster-node-tuning-operator get tuned

    出力例

    NAME                                     AGE
default                                  63m
openshift-node-performance-performance   21m

  2. 次のコマンドを実行して、クラスター内のマシン設定プールを確認します。 

    $ oc get mcp

    出力例

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-79a26af9f78ced61fa8ccd309d3c859c       True      False      False      3              3                   3                     0                      157m
worker       rendered-worker-d9352e91a1b14de7ef453fa54480ce0e       True      False      False      2              2                   2                     0                      157m
worker-cnf   rendered-worker-cnf-f398fc4fcb2b20104a51e744b8247272   True      False      False      1              1                   1                     0                      92m

  3. 次のコマンドを実行して、現在適用されているパフォーマンスプロファイルの情報を表示します。 

    $ oc describe performanceprofile performance | grep Tuned

    出力例

    Tuned:                   openshift-cluster-node-tuning-operator/openshift-node-performance-performance

  4. kernel.shmmni sysctl パラメーターの既存の値を確認します。

    1. 次のコマンドを実行してノード名を表示します。 

      $ oc get nodes

      出力例

      NAME                          STATUS   ROLES                  AGE    VERSION
ip-10-0-26-151.ec2.internal   Ready    worker,worker-cnf      116m   v1.30.6
ip-10-0-46-60.ec2.internal    Ready    worker                 115m   v1.30.6
ip-10-0-52-141.ec2.internal   Ready    control-plane,master   123m   v1.30.6
ip-10-0-6-97.ec2.internal     Ready    control-plane,master   121m   v1.30.6
ip-10-0-86-145.ec2.internal   Ready    worker                 117m   v1.30.6
ip-10-0-92-228.ec2.internal   Ready    control-plane,master   123m   v1.30.6

    2. 次のコマンドを実行して、ノード ip-10-0-32-74.ec2.internal の kernel.shmmni sysctl パラメーターの現在の値を表示します。 

      $ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host sysctl kernel.shmmni

      出力例

      kernel.shmmni = 4096

  5. kernel.shmmni sysctl パラメーターを 8192 に変更するプロファイルパッチ (例: perf-patch.yaml) を作成します。次の設定を適用し、always 方式を使用して、変更の適用を新しい手動再起動まで延期します。 

    apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  annotations:
    tuned.openshift.io/deferred: "always"
spec:
  profile:
    - name: performance-patch
      data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-performance
        [sysctl]
        kernel.shmmni=8192
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: worker-cnf
      priority: 19
      profile: performance-patch

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

    • include ディレクティブは、openshift-node-performance-performance プロファイルを継承するために使用します。これは、プロファイルから必要な設定が欠落するのを防ぐためのベストプラクティスです。
    • kernel.shmmni sysctl パラメーターを 8192 に変更します。
    • machineConfigLabels フィールドは、worker-cnf ロールをターゲットにするために使用します。

  6. 次のコマンドを実行してプロファイルのパッチを適用します。 

    $ oc apply -f perf-patch.yaml

  7. 次のコマンドを実行して、プロファイルのパッチが次のノードの再起動を待機していることを確認します。 

    $ oc -n openshift-cluster-node-tuning-operator get profile

    出力例

    NAME                          TUNED                     APPLIED   DEGRADED   MESSAGE                                                                            AGE
ip-10-0-26-151.ec2.internal   performance-patch         False     True       The TuneD daemon profile is waiting for the next node restart: performance-patch   126m
ip-10-0-46-60.ec2.internal    openshift-node            True      False      TuneD profile applied.                                                             125m
ip-10-0-52-141.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             130m
ip-10-0-6-97.ec2.internal     openshift-control-plane   True      False      TuneD profile applied.                                                             130m
ip-10-0-86-145.ec2.internal   openshift-node            True      False      TuneD profile applied.                                                             126m
ip-10-0-92-228.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             130m

  8. 再起動する前に、kernel.shmmni sysctl パラメーターの値が変更されていないことを確認します。

    1. 次のコマンドを実行して、ノード ip-10-0-26-151.ec2.internal の kernel.shmmni sysctl パラメーターへの performance-patch の変更が適用されていないことを確認します。 

      $ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host sysctl kernel.shmmni

      出力例

      kernel.shmmni = 4096

  9. 次のコマンドを実行して、ノード ip-10-0-26-151.ec2.internal を再起動し、必要な変更を適用します。 

    $ oc debug node/ip-10-0-26-151.ec2.internal  -q -- chroot host reboot&

  10. 別のターミナルウィンドウで次のコマンドを実行して、ノードが再起動したことを確認します。 

    $ watch oc get nodes

    ノード ip-10-0-26-151.ec2.internal が Ready 状態に戻るまで待ちます。

  11. 次のコマンドを実行して、プロファイルのパッチが次のノードの再起動を待機していることを確認します。 

    $ oc -n openshift-cluster-node-tuning-operator get profile

    出力例

    NAME                          TUNED                     APPLIED   DEGRADED   MESSAGE                                                                            AGE
ip-10-0-20-251.ec2.internal   performance-patch         True      False      TuneD profile applied.                                                             3h3m
ip-10-0-30-148.ec2.internal   openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
ip-10-0-32-74.ec2.internal    openshift-node            True      True       TuneD profile applied.                                                             179m
ip-10-0-33-49.ec2.internal    openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
ip-10-0-84-72.ec2.internal    openshift-control-plane   True      False      TuneD profile applied.                                                             3h8m
ip-10-0-93-89.ec2.internal    openshift-node            True      False      TuneD profile applied.                                                             179m

  12. 再起動後に kernel.shmmni sysctl パラメーターの値が変更されたことを確認します。

    1. 次のコマンドを実行して、kernel.shmmni sysctl パラメーターの変更がノード ip-10-0-32-74.ec2.internal に適用されていることを確認します。 

      $ oc debug node/ip-10-0-32-74.ec2.internal  -q -- chroot host sysctl kernel.shmmni

      出力例

      kernel.shmmni = 8192

      注記

      もう一度再起動すると、kernel.shmmni sysctl パラメーターの元の値が復元されます。

10.8. サポートされている TuneD デーモンプラグイン
リンクのコピー

[main] セクションを除き、以下の TuneD プラグインは、Tuned CR の profile: セクションで定義されたカスタムプロファイルを使用する場合にサポートされます。

  • audio
  • cpu
  • disk
  • eeepc_she
  • modules
  • mounts
  • net
  • scheduler
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • usb
  • video
  • vm
  • bootloader

これらのプラグインの一部によって提供される動的チューニング機能の中に、サポートされていない機能があります。以下の TuneD プラグインは現時点でサポートされていません。

  • script
  • systemd
注記

TuneD ブートローダープラグインは、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーノードのみサポートします。

関連情報

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

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

手順

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

        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

    <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> \
  --name <nodepool_name> \
  --node-count <nodepool_replicas> \
  --instance-type <instance_type> \
  --render > hugepages-nodepool.yaml

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

    • <hosted_cluster_name>: ホステッドクラスターの名前。
    • <nodepool_name>: ノードプールの名前。
    • <nodepool_replicas>: ノードプールレプリカの数。たとえば、2 です。
    • <instance_type>: インスタンスのタイプ。例: m5.2xlarge。
    注記

    hcp create コマンドの --render フラグはシークレットをレンダリングしません。シークレットをレンダリングするには、hcp create コマンドで --render フラグと --render-sensitive フラグの両方を使用する必要があります。

  4. hugepages-nodepool.yaml ファイルで、.spec.management.upgradeType を InPlace に設定し、作成した tuned-hugepages ConfigMap オブジェクトを参照するように .spec.tuningConfig を設定します。 

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

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

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

    $ 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

第11章 CPU マネージャーおよび Topology Manager の使用
リンクのコピー

CPU マネージャーは、CPU グループを管理して、ワークロードを特定の CPU に制限します。

CPU マネージャーは、以下のような属性が含まれるワークロードに有用です。

  • できるだけ長い CPU 時間が必要な場合
  • プロセッサーのキャッシュミスの影響を受ける場合
  • レイテンシーが低いネットワークアプリケーションの場合
  • 他のプロセスと連携し、単一のプロセッサーキャッシュを共有することに利点がある場合

Topology Manager は、CPU マネージャー、デバイスマネージャー、およびその他の Hint Provider からヒントを収集し、同じ Non-Uniform Memory Access (NUMA) ノード上のすべての QoS (Quality of Service) クラスについて CPU、SR-IOV VF、その他デバイスリソースなどの Pod リソースを調整します。

Topology Manager は、収集したヒントのトポロジー情報を使用し、設定される Topology Manager ポリシーおよび要求される Pod リソースに基づいて、pod がノードから許可されるか、拒否されるかどうかを判別します。

Topology Manager は、ハードウェアアクセラレーターを使用して低遅延 (latency-critical) の実行と高スループットの並列計算をサポートするワークロードの場合に役立ちます。

Topology Manager を使用するには、static ポリシーで CPU マネージャーを設定する必要があります。

11.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. KubeletConfig、cpumanager-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
     cpuManagerReconcilePeriod: 5s

    • cpuManagerPolicy は ポリシーを指定します。

      • noneこのポリシーは、既存のデフォルト CPU アフィニティースキームを明示的に有効にし、スケジューラーが自動的に実行するもの以外のアフィニティーを提供しません。これはデフォルトポリシーになります。
      • staticこのポリシーは、整数の CPU 要求を持つ保証された Pod 内のコンテナーを許可します。また、ノードの排他的 CPU へのアクセスも制限します。static の場合は、小文字の s を使用する必要があります。
    • cpuManagerReconcilePeriod はオプションです。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
cpuManagerReconcilePeriod: 5s
    • cpuManagerPolicy は、KubeletConfig CR の作成時に定義されます。
    • 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

11.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 状態になります。

11.3. Topology Manager のセットアップ
リンクのコピー

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

前提条件

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

手順

  1. Topology Manager を有効にするには、カスタムリソースで 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
     cpuManagerReconcilePeriod: 5s
     topologyManagerPolicy: single-numa-node
    • cpuManagerPolicy は 小文字の s で 静的で ある必要があります。
    • topologyManagerPolicy は、選択した Topology Manager 割り当てポリシーを指定します。この例では、ポリシーは single-numa-node です。使用できる値は、default、best-effort、restricted、single-numa-node です。

11.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"

選択されたポリシーが なし 以外の場合、Topology Manager はすべての Pod を処理し、保証付き 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 は、リソース割り当ての段階でこの保存された情報を使用します。

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

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

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

12.1. NUMA について
リンクのコピー

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

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

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

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

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

12.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 スケジューリングの俯瞰的な概要を示しています。

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

12.3. NUMA リソーススケジューリングストラテジー
リンクのコピー

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

高性能ワークロードをスケジューリングする際、セカンダリースケジューラーは、内部の NUMA リソース配分に基づいて、タスクに最適なコンピュートノードを決定します。スケジューラーは NUMA レベルのデータを使用してコンピュートノードを評価して選択しますが、そのノード内での実際のリソースの固定は、ローカルの Topology Manager および CPU マネージャーによって管理されます。

NUMA 対応クラスターで高パフォーマンスワークロードがスケジュールされるときには、次の手順が実行されます。

  1. ノードフィルタリング: スケジューラーはまずクラスター全体をフィルタリングして、実行可能な ノードの候補リストを作成します。ノードは、ラベルの一致、taint や toleration 範囲の遵守、そして重要な点として、特定の NUMA ゾーン内に十分な利用可能なリソースがあることなど、すべての要件を満たしている場合にのみ保持されます。ノードがワークロードの NUMA アフィニティーを満たせない場合、そのノードはこの段階で除外されます。
  2. ノード選択: 適切なノードの候補リストが作成されると、スケジューラーはそれらを評価して最適なノードを見つけます。スケジューラーは、NUMA を考慮したスコアリングストラテジーを適用して、リソース配分に基づいてこれらの候補をランク付けします。最も高いスコアを獲得したノードが、ワークロードの割り当て先として選択される。
  3. ローカル割り当て:Pod がコンピュートノードに割り当てられると、ノードレベルのコンポーネント (CPU、メモリー、デバイス、トポロジーマネージャー) が特定の CPU とメモリーの権限のある割り当てを実行します。スケジューラーはこの最終選択に影響を与えません。

以下の表は、OpenShift Container Platform のさまざまなストラテジーとその結果の概要を示しています。

Expand
表12.1 スコアリングストラテジーの概要
ストラテジー説明効果

LeastAllocated

利用可能なリソースが最も多い NUMA ゾーンを含むコンピュートノードを優先します。

ワークロードをクラスター全体に分散し、利用可能な余裕が最も大きいノードに割り当てます。

MostAllocated

要求されたリソースがすでに高い利用率を持つ NUMA ゾーンに収まるコンピュートノードを優先します。

すでに利用されているノードにワークロードを集中させることで、他のノードをアイドル状態にする可能性があります。

BalancedAllocation

NUMA ゾーン全体で CPU とメモリーの使用率が最もバランスの取れたコンピュートノードを優先します。

CPU などのリソースタイプが使い果たされる一方で、メモリーなどの別のリソースタイプがアイドル状態になるといった、偏った使用パターンを防ぎます。

12.4. NUMA Resources Operator のインストール
リンクのコピー

NUMA Resources Operator は、NUMA 対応のワークロードとデプロイメントをスケジュールできるリソースをデプロイします。OpenShift Container Platform CLI または Web コンソールを使用して NUMA Resources Operator をインストールできます。

12.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.20"
  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.20.2   numaresources-operator   4.20.2               Succeeded

12.4.2. Web コンソールを使用した NUMA Resources Operator のインストール
リンクのコピー

高性能ワークロード向けに NUMA 対応スケジューリングを有効にするには、Web コンソールを使用して NUMA Resources Operator をインストールします。クラスター管理者であれば、グラフィカルインターフェイスを通して Operator をデプロイできます。

手順

  1. NUMA Resources Operator の namespace を作成します。

    1. OpenShift Container Platform Web コンソールで、Administration → Namespaces をクリックします。
    2. Create Namespace をクリックし、Name フィールドに openshift-numaresources と入力して Create をクリックします。

  2. NUMA Resources Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、Ecosystem → Software Catalog をクリックします。
    2. 利用可能な Operator のリストから numaresources-operator を選択し、Install をクリックします。
    3. Installed Namespaces フィールドで、openshift-numaresources namespace を選択し、Install をクリックします。

  3. オプション: NUMA Resources Operator が正常にインストールされたことを確認します。

    1. Ecosystem → Installed Operators ページに切り替えます。

    2. NUMA Resources Operator が openshift-numaresources namespace にリストされ、Status が InstallSucceeded であることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • Ecosystem → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • Workloads → Pods ページに移動し、default プロジェクトの Pod のログを確認します。

12.5. 単一の NUMA ノードポリシーの設定
リンクのコピー

NUMA Resources Operator を有効にするには、クラスター上で単一の NUMA ノードポリシーを設定します。このポリシーは、パフォーマンスプロファイルを作成するか、KubeletConfig カスタムリソース (CR) を設定することで実装できます。

注記

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

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

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

NUMA 対応セカンダリースケジューラーの高可用性を確保するため、NUMA Resources Operator は制御プレーンノード上にスケジューラーレプリカを自動的に作成します。Operator は、NUMAResourcesScheduler カスタムリソース (CR) の spec.replicas フィールドを使用してこの設定を管理します。

重要

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

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

デフォルトでは、NUMA Resources Operator は、コントロールプレーンノードごとに 1 つのスケジューラーレプリカ (最大 3 つのレプリカ) を作成して、HA モードを自動的に有効にします。

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

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

次のいずれかの方法を使用して、スケジューラーの動作を制御できます。

  • レプリカの数をカスタマイズします。
  • NUMA 対応スケジューリングを無効にします。
12.5.1.1. スケジューラーレプリカのカスタマイズ
リンクのコピー

NUMAResourcesScheduler カスタムリソースの spec.replicas フィールドを更新することで、スケジューラーレプリカの具体的な数を設定できます。この設定は、デフォルトの HA 動作を上書きします。

手順

  1. 例として、レプリカの数を 2 に設定する custom-ha.yaml という名前の次の YAML を使用して、NUMAResourcesScheduler CR を作成します。 

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

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

    $ oc apply -f custom-ha.yaml
12.5.1.2. NUMA 対応スケジューリングの無効化
リンクのコピー

NUMA 対応スケジューラーを無効にすると、実行中のすべてのスケジューラー Pod が停止し、新しい Pod の起動も防止されます。

手順

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

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

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

    $ oc apply -f nro-disable-scheduler.yaml
12.5.1.3. スケジューラーの高可用性 (HA) ステータスの検証
リンクのコピー

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

手順

  1. 次のコマンドを実行して、スケジューラー Pod だけをリスト表示します。 

    $ oc get pods -n openshift-numaresources -l app=secondary-scheduler

    予想される出力

    NAME                                   READY   STATUS    RESTARTS   AGE
secondary-scheduler-5b8c9d479d-2r4p5   1/1     Running   0          5m
secondary-scheduler-5b8c9d479d-k2f3p   1/1     Running   0          5m
secondary-scheduler-5b8c9d479d-q8c7b   1/1     Running   0          5m

    デフォルトの HA モードを使用すると、Pod の数がコントロールプレーンノードの数と等しくなります。標準的な高可用性 (HA) 設定の OpenShift Container Platform クラスターは、通常 3 つのコントロールプレーンノードを持ち、そのため 3 つの Pod が表示されます。レプリカをカスタマイズ した場合、Pod の数は設定した値と一致します。スケジューラーを無効化 した場合、このラベルが付いた実行中の Pod はありません。

    注記

    NUMA 対応スケジューラーでは、レプリカの上限が 3 つに制限されています。Hosted Control Plane クラスターでは、スケジューラー Pod はホスト型クラスターのコンピュートノード上で実行されます。

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

    $ oc get deployment secondary-scheduler -n openshift-numaresources

    出力例

    NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
secondary-scheduler   3/3     3            3           5m

    この出力の 3/3 は、期待される 3 つのレプリカのうち 3 つが準備完了状態であることを示しています。

  3. より詳細な情報を得るには、次のコマンドを実行します。 

    $ oc describe deployment secondary-scheduler -n openshift-numaresources

    出力例

    Replicas:        3 desired | 3 updated | 3 total | 3 available | 0 unavailable

    Replicas 行に、デプロイメントが 3 つのレプリカで設定されており、3 つとも更新済みで使用可能であることが表示されます。

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

パフォーマンスプロファイル作成ツール (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 ツールを実行する際に、topology-manager-policy 引数 を single-numa-node に設定することで、topologyPolicy フィールドが single-numa-node に設定されるようにします。

注記

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

12.5.3. 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 を作成し、NodePool の spec.config フィールド内でその ConfigMap を参照する必要があります。

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

      $ oc create -f nro-kubeletconfig.yaml
      注記

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

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

レイテンシーに敏感なワークロードや高性能なワークロードを効率的に処理するには、OpenShift Container Platform クラスターを NUMA 対応のスケジューリング用に設定してください。このプロセスでは、ネットワーク遅延を最小限に抑え、コンピュートリソースの利用率を最大化するために、Pod を特定の NUMA ゾーンに割り当てます。

通常、遅延の影響を受けやすいワークロードを実行するクラスターは、ワークロードの遅延を最小限に抑え、パフォーマンスを最適化するのに役立つパフォーマンスプロファイルを備えています。NUMA 対応スケジューラーは、使用可能なノードの NUMA リソースと、ノードに適用されるパフォーマンスプロファイル設定に基づいき、ワークロードをデプロイします。NUMA 対応デプロイメントとワークロードのパフォーマンスプロファイルを組み合わせることで、パフォーマンスを最大化するようにワークロードがスケジュールされます。

NUMA Resources Operator を完全に動作させるには、NUMAResourcesOperator カスタムリソースと NUMA 対応のセカンダリー Pod スケジューラーをデプロイする必要があります。

12.6.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 リソースを作成したとします。nodeGroups 仕様を設定する際は、参照する各 MachineConfigPool リソースが、一意の nodeSelector ラベルを持つノードを対象としていることを確認してください。この nodeSelector ラベルは、その特定のノードセットにのみ適用されるべきです。トポロジーを考慮したスケジューリングで管理するノードは、単一の MachineConfigPool リソースに関連付けられている必要があります。したがって、各 ノードグループは 必ず 1 つの MachineConfigPool リソースと一致する必要があり、複数のプールに一致する設定はサポートされていません。

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

      $ oc create -f nrop.yaml

  2. オプション: 複数のマシン設定プール (MCP) に対して NUMA 対応スケジューリングを有効にするには、プールごとに個別の NodeGroup を定義します。たとえば、次の例に示すように、NUMAResourcesOperator CR で、worker-cnf、worker-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

12.6.2. Hosted Control Plane 用の NUMAResourcesOperator カスタムリソースの作成
リンクのコピー

NUMA Resources Operator をインストールした後、NUMAResourcesOperator カスタムリソース (CR) を作成します。CR は、デーモンセットや API など、Hosted Control Plane 上の NUMA 対応スケジューラーをサポートするために必要なすべてのクラスターインフラストラクチャーをインストールするように NUMA Resources Operator に指示します。

重要

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

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

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールしました。

手順

  1. 次のコマンドを実行して、管理クラスターの kubeconfig ファイルをエクスポートします。 

    $ export KUBECONFIG=<path-to-management-cluster-kubeconfig>

  2. 次のコマンドを実行して、クラスターの node-pool-name を見つけます。 

    $ oc --kubeconfig="$MGMT_KUBECONFIG" get np -A

    出力例

    NAMESPACE   NAME                     CLUSTER       DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    democluster-us-east-1a   democluster   1               1               False         False        4.20.0    False             False

    node-pool-name は出力の NAME フィールドです。この例では、node-pool-name は democluster-us-east-1a です。

  3. 少なくとも次の内容を含む、nrop-hcp.yaml という名前の YAML ファイルを作成します。 

    apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
  - poolName: democluster-us-east-1a
# ...
    • spec.nodeGroups.poolName: プール名 を指定します。この例では、前の手順で取得した ノードプール名 (node-pool-name) を示しています。

  4. 管理クラスターで次のコマンドを実行して、利用可能なシークレットをリスト表示します。 

    $ oc get secrets -n clusters

    出力例

    NAME                              TYPE                      DATA   AGE
builder-dockercfg-25qpp           kubernetes.io/dockercfg   1      128m
default-dockercfg-mkvlz           kubernetes.io/dockercfg   1      128m
democluster-admin-kubeconfig      Opaque                    1      127m
democluster-etcd-encryption-key   Opaque                    1      128m
democluster-kubeadmin-password    Opaque                    1      126m
democluster-pull-secret           Opaque                    1      128m
deployer-dockercfg-8lfpd          kubernetes.io/dockercfg   1      128m

  5. 次のコマンドを実行して、ホステッドクラスターの kubeconfig ファイルを抽出します。 

    $ oc get secret <SECRET_NAME> -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig

    例

    $ oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig

  6. 次のコマンドを実行して、ホステッドクラスターの kubeconfig ファイルをエクスポートします。 

    $ export HC_KUBECONFIG=<path_to_hosted-cluster-kubeconfig>

  7. ホステッドクラスターで次のコマンドを実行して、NUMAResourcesOperator CR を作成します。 

    $ oc create -f nrop-hcp.yaml

検証

  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-democluster-7d96r             2/2     Running   0          97s
pod/numaresourcesoperator-democluster-crsht             2/2     Running   0          97s
pod/numaresourcesoperator-democluster-jp9mw             2/2     Running   0          97s

12.6.3. 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.20"
# ...
      • spec.imageSpec: 非接続環境では、以下のいずれかの方法でこのイメージの解像度を設定してください。
    2. ImageTagMirrorSet カスタムリソース (CR) を作成します。詳細は、「関連情報」セクションの「イメージレジストリーのリポジトリーミラーリングの設定」を参照してください。
    3. 切断されたレジストリーへの URL を設定してください。

    4. 次のコマンドを実行して、NUMAResourcesScheduler CR を作成します。 

      $ oc create -f nro-scheduler.yaml
      注記

      Hosted Control Plane クラスターでは、Hosted Control Plane ノードでこのコマンドを実行します。

  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

12.6.4. 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 の qosClass が Guaranteed で、CPU 要求が 10 進値ではなく整数値であることを確認してください。次のコマンドを実行すると、Pod の qosClass が Guaranteed であることを確認できます。 

    $ oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"

    出力例

    Guaranteed

12.7. NUMA Resources Operator によるスケジュール可能なコントロールプレーンノードのサポート
リンクのコピー

スケジューリング可能なコントロールプレーンノードを有効にして、ユーザー定義の Pod を実行できるようにすることで、ノードを実質的にハイブリッドなコントロールプレーンノードとコンピュートノードに変えることができます。この設定は、コンパクトクラスターなど、リソースが制限された環境で特に役立ちます。

NUMA Resources Operator を有効にすると、トポロジーを考慮したスケジューリングをノードに適用してワークロードを保証し、最適な NUMA アフィニティーに従って Pod が配置されるようにします。

従来、OpenShift Container Platform のコントロールプレーンノードは、重要なクラスターサービスを実行するための専用ノードでした。スケジュール可能なコントロールプレーンノードを有効にすると、ユーザー定義の Pod をコントロールプレーンノードにスケジュールできるようになります。

schedulers.config.openshift.io リソースで mastersSchedulable フィールドを true に設定することで、コントロールプレーンノードをスケジュール可能にすることができます。

注記

スケジュール可能なコントロールプレーンノードを有効にする場合は、重要なインフラストラクチャー Pod をリソース不足から保護するために、ワークロードパーティショニングを有効にすることを強く推奨します。このプロセスにより、ovnkube-node プロセスなどのインフラストラクチャーコンポーネントが、専用の予約済み CPU に制限されます。しかし、OVS の動的ピニング機能は、ピニングされていない CPU を正しく特定して使用するために、ovnkube-node が burstable/best-effort Pod 用に指定された CPU にアクセスできることに依存しています。ワークロードパーティショニングが予約済み CPU の CPU アフィニティーを使用して ovnkube-node プロセスを設定すると、この動的ピニングメカニズムが機能しなくなります。

NUMA Resources Operator は、特定の NUMA アフィニティーを必要とするワークロードに対して、トポロジーを考慮したスケジューリングを提供します。コントロールプレーンノードがスケジューリング可能になると、Operator の管理機能をコンピュートノードと同様に、コントロールプレーンノードにも適用できるようになります。これにより、NUMA 対応 Pod は、制御プレーンノードであろうとコンピュートノードであろうと、最適な NUMA トポロジーを持つノードに配置されることが保証されます。

NUMA Resources Operator を設定する場合、その管理範囲はカスタムリソース (CR) の nodeGroups フィールドによって決まります。この原則は、コンパクトクラスターとマルチノードクラスターの両方に適用されます。

コンパクトクラスター
コンパクトクラスターでは、すべてのノードがスケジュール可能なコントロールプレーンノードとして設定されます。クラスター内のすべてのノードを管理するように NUMA Resources Operator を設定できます。デプロイ手順に従ってプロセスの詳細を確認してください。
マルチノード OpenShift (MNO) クラスター
マルチノードの OpenShift Container Platform クラスターでは、既存のコンピュートノードに加えて、コントロールプレーンノードもスケジュール可能になります。これらのノードを管理するには、NUMAResourcesOperator CR で制御プレーンノードとコンピュートノード用に個別の ノードグループ を定義することで、NUMA Resources Operator を設定できます。これにより、NUMA Resources Operator は、リソースの利用可能性と NUMA トポロジーに基づいて、両方のノードセットに Pod を正しくスケジュールできるようになります。
注記

パフォーマンスプロファイルを変更すると、多くの場合、コントロールプレーンノードのリブートがトリガーされます。コントロールプレーンノード上のより厳格な Pod Disruption Budget (PDB) により、クラスターの耐障害性メカニズムがアクティブ化されます。これらのメカニズムは、たとえば CrashLoopBackOff 状態の Pod など、保護されているが正常ではない Pod の強制退避を防止します。強制退避は、リブートプロセス中に Machine Config Pool (MCP) が停止する原因となります。

この動作により MCP が停止した場合、問題を解決してコントロールプレーンのアップグレードを完了するには介入が必要です。

管理者には、解決するための 2 つのオプションがあります。

  1. 必要な退避を許可するために、PDB 制限を一時的に緩和します。
  2. 正常ではない Pod を手動で削除し、MCP による調整を強制して drain プロセスを続行します。

12.7.1. スケジュール可能なコントロールプレーンノードにおける NUMA Resources Operator の設定
リンクのコピー

コントロールプレーンノードでワークロードを実行するには、NUMA Resources Operator (NROP) を設定して、それらをスケジューリング可能なものとして管理するようにします。この設定は、コンパクトなクラスターや、制御プレーンノードがコンピュートノードとしても機能するマルチノード OpenShift (MNO) 環境に最適です。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールしている。

手順

  1. コントロールプレーンノードでトポロジーを考慮したスケジューリング (TAS) を有効にするには、まずノードをスケジュール可能に設定します。これにより、NUMA Resources Operator が Pod をデプロイして管理できるようになります。この操作を行わないと、Operator がコントロールプレーンノードから NUMA トポロジー情報を収集するために必要な Pod をデプロイできません。コントロールプレーンノードをスケジュール可能にするには、次の手順に従います。

    1. 次のコマンドを実行して、schedulers.config.openshift.io リソースを編集します。 

      $ oc edit schedulers.config.openshift.io cluster

    2. エディターで、mastersSchedulable フィールドを true に設定し、保存してエディターを終了します。 

      apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: "2019-09-10T03:04:05Z"
  generation: 1
  name: cluster
  resourceVersion: "433"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: a636d30a-d377-11e9-88d4-0a60097bee62
spec:
  mastersSchedulable: true
status: {}
#...

  2. NUMA Resources Operator を設定するには、クラスターに単一の NUMAResourcesOperator カスタムリソース (CR) を作成する必要があります。この CR 内の nodeGroups 設定で、Operator が管理する必要があるノードプールを指定します。

    注記

    nodeGroups を設定する前に、指定するノードプールがセクション 12.5「単一の NUMA ノードポリシーの設定」で詳述されているすべての前提条件を満たしていることを確認してください。NUMA Resources Operator は、グループ内のすべてのノードが同一であることを要求します。条件を満たしていないノードがあると、NUMA Resources Operator がプール全体に対して期待されるトポロジー対応のスケジューリングを実行できなくなります。

    NUMA Resources Operator の管理対象とするノードセットは、重複しないものであれば複数指定できます。これらの各セットは、別々のマシン設定プール (MCP) に対応している必要があります。NUMA Resources Operator は、指定されたノードグループ内のスケジュール可能なコントロールプレーンノードを管理します。

    1. コンパクトクラスターの場合、コンパクトクラスターのマスターノードもスケジュール可能なノードであるため、マスタープールのみを指定します。NUMAResourcesOperator CR に次の nodeGroups 設定を作成します。 

      apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
    - poolName: master
# ...
      注記

      master プールに加えてワーカープールを備えたコンパクトクラスターを構成することは避けてください。この構成によりクラスターの機能が損なわれたり Operator の機能が影響を受けることはありませんが、冗長または重複した Pod が発生し、システムに不要なノイズが発生する可能性があります。この場合、ワーカープールは実質的に無意味な空の MCP であるため、何の役にも立ちません。

    2. コントロールプレーンノードとコンピュートノードの両方がスケジュール可能な MNO クラスターの場合、NUMA Resources Operator を設定して複数の ノードグループ を管理するオプションがあります。NUMAResourcesOperator CR の nodeGroups リストに対応する MCP を追加することで、対象とするノードを指定できます。設定は具体的な要件によって完全に異なります。たとえば、master プールと worker-cnf プールの両方を管理するには、NUMAResourcesOperator CR に次の nodeGroups 設定を作成します。 

      apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
    - poolName: master
    - poolName: worker-cnf
# ...
      注記

      このリストをカスタマイズして、トポロジーを考慮したスケジューリングによる管理のために、任意の組み合わせのノードグループを含めることができます。重複した保留状態の Pod の発生を防ぐために、設定内の各 poolName が、一意のノードセレクターラベルを持つ MachineConfigPool (MCP) に対応していることを確認する必要があります。ラベルは特定のプール内のノードにのみ適用する必要があり、クラスター内の他のノードのラベルと重複してはなりません。worker-cnf MCP は、通信事業者ワークロードを実行するノードのセットを指定するものです。

    3. クラスターの設定に合わせて NUMAResourcesOperator CR の nodeGroups フィールドを更新したら、次のコマンドを実行して変更を適用します。 

      $ oc apply -f <filename>.yaml
      注記

      <filename>.yaml は、設定ファイルの名前に置き換えます。

検証

設定を適用した後、次のチェックを実行して、NUMA Resources Operator がスケジュール可能なコントロールプレーンノードを正しく管理していることを確認します。

  1. 次のコマンドを実行して、コントロールプレーンノードがワーカーロールを持ち、スケジュール可能であることを確認します。 

    $ oc get nodes

    出力例:

    NAME                STATUS   ROLES                         AGE     VERSION
worker-0            Ready    worker,worker-cnf             100m    v1.33.3
worker-1            Ready    worker                        93m     v1.33.3
master-0            Ready    control-plane,master,worker   108m    v1.33.3
master-1            Ready    control-plane,master,worker   107m    v1.33.3
master-2            Ready    control-plane,master,worker   107m    v1.33.3
worker-2            Ready    worker                        100m    v1.33.3

  2. 次のコマンドを実行して、NUMA Resources Operator の Pod が目的のノードで実行されていることを確認します。CR で指定したノードグループごとに numaresourcesoperator Pod が表示されます。 

    $ oc get pods -n openshift-numaresources -o wide

    出力例:

    NAME                                               READY   STATUS    RESTARTS   AGE     IP            NODE       NOMINATED NODE   READINESS GATES
numaresources-controller-manager-bdbdd574-xx6bw    1/1     Running   0          49m     10.130.0.17   master-0   <none>           <none>
numaresourcesoperator-master-lprrh                 2/2     Running   0          20m     10.130.0.20   master-0   <none>           2/2
numaresourcesoperator-master-qk6k4                 2/2     Running   0          20m     10.129.0.50   master-2   <none>           2/2
numaresourcesoperator-master-zm79n                 2/2     Running   0          20m     10.128.0.44   master-1   <none>           2/2
numaresourcesoperator-worker-cnf-gqlmd             2/2     Running   0          4m27s   10.128.2.21   worker-0   <none>           2/2

  3. 次のコマンドを実行して、NUMA Resources Operator により、指定したグループに含まれるすべてのノードの NUMA トポロジーデータが収集および報告されたことを確認します。 

    $ oc get noderesourcetopologies.topology.node.k8s.io

    出力例:

    NAME          AGE
worker-0      6m11s
master-0      22m
master-1      21m
master-2      21m

    あるノードの NodeResourceTopology リソースが存在すれば、それは NUMA Resources Operator がそのノードにデータ収集用の Pod をスケジュールできた証拠であり、トポロジーを考慮したスケジューリングが有効であることを示しています。

  4. 次のコマンドを実行して、1 つのノードリソーストポロジーを調べます。 

    $ oc get noderesourcetopologies <master_node_name> -o yaml

    出力例:

    apiVersion: topology.node.k8s.io/v1alpha2
attributes:
- name: nodeTopologyPodsFingerprint
  value: pfp0v001ef46db3751d8e999
- name: nodeTopologyPodsFingerprintMethod
  value: with-exclusive-resources
- name: topologyManagerScope
  value: container
- name: topologyManagerPolicy
  value: single-numa-node
kind: NodeResourceTopology
metadata:
  annotations:
    k8stopoawareschedwg/rte-update: periodic
    topology.node.k8s.io/fingerprint: pfp0v001ef46db3751d8e999
  creationTimestamp: "2025-09-23T10:18:34Z"
  generation: 1
  name: master-0
  resourceVersion: "58173"
  uid: 35c0d27e-7d9f-43d3-bab9-2ebc0d385861
zones:
- costs:
  - name: node-0
    value: 10
  name: node-0
  resources:
  - allocatable: "3"
    available: "2"
    capacity: "4"
    name: cpu
  - allocatable: "1476189952"
    available: "1378189952"
    capacity: "1576189952"
    name: memory
  type: Node
# ...

    マスターロールを持つノードにこのリソースが存在すれば、それは NUMA Resources Operator がそのノードに検出用 Pod をデプロイできたことを示しています。検出用 Pod は NUMA トポロジーデータを収集するものであり、スケジュール可能とされているノードにのみスケジュールできます。

    この出力から、マスターノードをスケジュール可能にする手順が成功したことがわかります。NUMA Resources Operator により、そのコントロールプレーンノードの NUMA 関連情報が収集および報告されるようになったためです。

12.8. NUMA リソース更新のためのポーリング操作の設定
リンクのコピー

オプションのタスクとして、NUMAResourcesOperator カスタムリソース (CR) の spec.nodeGroups 仕様を設定することで、スケジューリングの動作を改善したり、最適ではないスケジューリング決定のトラブルシューティングを行ったりすることができます。この設定により、デーモンが利用可能な NUMA リソースをポーリングする方法を細かく調整でき、ポーリング操作を高度に制御できます。

設定オプションは以下のとおりです。

  • infoRefreshMode: kubelet をポーリングするためのトリガー条件を決定します。NUMA Resources Operator は、結果として取得した情報を API サーバーに報告します。
  • infoRefreshPeriod: ポーリング更新の間隔を決定します。
  • podsFingerprinting: ノード上で実行されている現在の Pod セットのポイントインタイム情報がポーリング更新で公開されるかどうかを決定します。
注記

podsFingerprinting のデフォルト値は EnabledExclusiveResources です。スケジューラーのパフォーマンスを最適化するには、podsFingerprinting を EnabledExclusiveResources または Enabled に設定します。さらに、NUMAResourcesScheduler カスタムリソース (CR) の cacheResyncPeriod を 0 より大きい値に設定します。cacheResyncPeriod 仕様は、ノード上の保留中のリソースを監視することで、より正確なリソースの可用性を報告するのに役立ちます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールしました。

手順

  • NUMAResourcesOperator CR で spec.nodeGroups 仕様を設定します。 

    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
    有効な値は Periodic、Events、PeriodicAndEvents です。Periodic を使用して、infoRefreshPeriod で定義した間隔で kubelet をポーリングします。Events を使用して、Pod のライフサイクルイベントごとに kubelet をポーリングします。両方のメソッドを有効にするには、PeriodicAndEvents を使用します。
    spec.nodeGroups.config.infoRefreshPeriod
    定期更新 モードまたは 定期更新＆イベント 更新モードのポーリング間隔を指定します。リフレッシュモードが Events の場合、このフィールドは無視されます。
    spec.nodeGroups.config.podsFingerprinting
    有効な値は、Enabled、Disabled、および EnabledExclusiveResources です。NUMAResourcesScheduler の cacheResyncPeriod 仕様では、Enabled または EnabledExclusiveResources に設定する必要があります。

検証

  1. NUMA Resources Operator をデプロイした後、次のコマンドを実行して、ノードグループ設定が適用されたことを検証します。 

    $ oc get numaresop numaresourcesoperator -o json | jq '.status'

    出力例

          ...

        "config": {
        "infoRefreshMode": "Periodic",
        "infoRefreshPeriod": "10s",
        "podsFingerprinting": "Enabled"
      },
      "name": "worker"

      ...

12.9. 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 ゾーンリソースに対応していることを確認します。

12.9.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.20"
  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"

12.9.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 ファイルに保存します。この例では、scoringStrategy を MostAllocated に変更します。 

    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

12.9.3. NUMA 対応スケジューラーログの確認
リンクのコピー

NUMA 対応スケジューラーに関する問題のトラブルシューティングを行うには、スケジューラーのログを確認してください。必要に応じて、NUMAResourcesScheduler カスタムリソース (CR) のログレベルを上げて、より詳細な診断データを取得してください。

許容値は Normal、Debug、および 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.20"
  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"

12.9.4. リソーストポロジーエクスポーターのトラブルシューティング
リンクのコピー

noderesourcetopologies オブジェクトで予期しない結果が発生した場合は、resource-topology-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

12.9.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 configmap は numaresourcesoperator-worker configmap CR も返します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 特権のユーザーとしてログインしました。
  • NUMA Resources Operator をインストールし、NUMA 対応のセカンダリースケジューラーをデプロイしました。

手順

  1. 次のコマンドを使用して、kubeletconfig の spec.machineConfigPoolSelector.matchLabels と MachineConfigPool (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

12.9.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.20

第13章 スケーラビリティとパフォーマンスの最適化
リンクのコピー

13.1. ストレージの最適化
リンクのコピー

ストレージを最適化すると、すべてのリソースでストレージの使用を最小限に抑えることができます。管理者として、ストレージを最適化することで、既存のストレージリソースが効率的に動作するようにすることができます。

13.1.1. 利用可能な永続ストレージオプション
リンクのコピー

OpenShift Container Platform 環境を最適化するには、利用可能な永続ストレージオプションを確認してください。これらの選択肢を理解することで、特定のワークロード要件を満たす適切なストレージ設定を選択できます。

Expand
表13.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 プロビジョニングをサポートします。

13.1.4. データストレージ管理
リンクのコピー

OpenShift Container Platform でデータストレージを効果的に管理するには、コンポーネントがデータを書き込む主要なディレクトリーを確認してください。

以下の表は、OpenShift Container Platform コンポーネントがデータを書き込むメインディレクトリーの概要を示しています。

Expand
表13.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。

ログファイルはすぐに拡張する可能性があります。サイズは拡張するディスク別に管理するか、ログローテーションを使用して管理できます。

13.1.5. Microsoft Azure のストレージパフォーマンスの最適化
リンクのコピー

Microsoft Azure 上で最適なクラスターパフォーマンスを確保するには、OpenShift Container Platform および Kubernetes 用に高速なストレージを設定してください。Red Hat は、特にコントロールプレーンノード上の 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 ストレージにあるディスクからの読み取りよりもはるかに高速です。

13.2. ルーティングの最適化
リンクのコピー

OpenShift Container Platform の HAProxy ルーターをスケーリングまたは設定することで、ルーティングパフォーマンスを最適化できます。

13.2.1. ベースライン Ingress Controller (ルーター) のパフォーマンス
リンクのコピー

OpenShift Container Platform Ingress Controller (ルーター) は、ルートとイングレスを使用して設定されたアプリケーションやサービスのイングレストラフィックのイングレスポイントとして使用できます。

1 秒に処理される HTTP 要求について、単一の HAProxy ルーターを評価する場合に、パフォーマンスは多くの要因により左右されます。特に以下が含まれます。

  • HTTP keep-alive/close モード
  • ルートタイプ
  • TLS セッション再開のクライアントサポート
  • ターゲットルートごとの同時接続数
  • ターゲットルート数
  • バックエンドサーバーのページサイズ
  • 基盤となるインフラストラクチャー (ネットワーク、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 またはルーターのシャード化は、アプリケーションに対してより多くのルートを提供するために使用され、ルーティング層の水平スケーリングに役立ちます。

13.2.3. Ingress Controller の liveness、準備、および起動プローブの設定
リンクのコピー

クラスター管理者として、OpenShift Container Platform Ingress Controller (ルーター) によって管理されるルーターデプロイメントの kubelet の liveness、レディネス、および起動プローブのタイムアウト値を設定できます。より大きなタイムアウト値を設定する機能により、不要で不要な再起動のリスクを減らすことができます。

ルーターの liveness および readiness プローブは、デフォルトのタイムアウト値である 1 秒を使用します。これは、ネットワークまたはランタイムのパフォーマンスが著しく低下している場合には短すぎます。プローブのタイムアウトにより、アプリケーション接続を中断する不要なルーターの再起動が発生する可能性があります。

ルーターコンテナーの livenessProbe、readinessProbe、および 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

13.2.4. HAProxy リロード間隔の設定
リンクのコピー

HAProxy のリロード間隔を設定することで、HAProxy がリロードされた際に、更新された設定を使用して新しい接続を処理する新しいプロセスを生成するようにできます。

ルートまたはルートに関連付けられたエンドポイントを更新すると、OpenShift Container Platform ルーターは HAProxy の設定を更新します。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"}}}'

13.3. ネットワークの最適化
リンクのコピー

ノード間でトラフィックをトンネルするには、汎用ネットワーク仮想化カプセル化 (Geneve) を使用します。ネットワークインターフェイスコントローラー (NIC) のオフロード機能を使用することで、ネットワークを最適化できます。

Geneve は、ネットワークを 4096 から 1600 万以上に増加したり、物理ネットワーク全体でレイヤー 2 接続を実現したりするなど、VLAN を超える利点を提供します。これにより、異なるシステム上で実行されている場合でも、サービスの背後にある Pod すべてが相互に通信できるようになります。

OpenShift Container Platform を実行するクラウド、仮想環境、およびベアメタル環境では、最小限の調整でネットワークインターフェイスカード (NIC) の機能の大部分を利用できます。OVN-Kubernetes と Geneve トンネリングを使用する実稼働クラスターは、特別な設定なしで、高スループットのトラフィックを効率的に処理し、スケールアップ (100 Gbps NIC の利用など) およびスケールアウト (NIC の追加など) を行うことができます。

効率の最大化が重要な一部の高パフォーマンス環境では、ターゲットを絞ったパフォーマンスチューニングによって、CPU 使用率を最適化し、オーバーヘッドを削減し、NIC の機能を最大限に活用できます。

最大スループットと CPU 効率が重要な環境では、次の方法を使用してパフォーマンスをさらに最適化できます。

  • iPerf3 や k8s-netperf などのツールを使用して、ネットワークパフォーマンスを検証します。これらのツールを使用することで、Pod およびノードのインターフェイス全体にわたるスループット、レイテンシー、および 1 秒あたりのパケット数 (PPS) をベンチマークできます。
  • Border Gateway Protocol (BGP) などの OVN-Kubernetes ユーザー定義ネットワーク (UDN) ルーティング手法を評価します。
  • Geneve オフロード対応ネットワークアダプターを使用します。Geneve オフロードは、システムの CPU から、パケットのチェックサム計算と関連の CPU オーバーヘッドを、ネットワークアダプター上の専用のハードウェアに移動します。これにより、CPU サイクルが解放され、Pod やアプリケーションが利用できるようになり、ユーザーはネットワークインフラストラクチャーの帯域幅を最大限に活用できるようになります。

13.3.2. ネットワークでの MTU の最適化
リンクのコピー

ネットワークの MTU 値を最適化することで、スループットの向上や低遅延化を実現できます。

重要な Maximum Transmission Unit (MTU) が 2 つあります。1 つはネットワークインターフェイスコントローラー (NIC) MTU で、もう 1 つはクラスターネットワーク MTU です。

NIC の MTU は OpenShift Container Platform のインストール時に設定します。また、クラスターの MTU の変更は、インストール後のタスクとして実行できます。詳細は、「クラスターネットワーク MTU の変更」を参照してください。

OVN-Kubernetes プラグインを使用するクラスターの場合、MTU はネットワークの NIC がサポートする最大値より少なくとも 100 バイト小さくなければなりません。スループットを最適化する場合は、8900 など、可能な限り大きな値を選択します。レイテンシーを最低限に抑えるために最適化するには、より小さい値を選択します。

重要

クラスターが OVN-Kubernetes プラグインを使用し、ネットワークが NIC を使用してネットワーク経由で断片化されていないジャンボフレームパケットを送受信する場合は、Pod が失敗しないように、NIC の MTU 値として 9000 バイトを指定する必要があります。

13.3.4. IPsec の影響
リンクのコピー

ノードホストの暗号化と復号化には CPU パワーが消費されるため、暗号化が有効になっている場合、使用されている IP セキュリティーシステムの種類に関係なく、ノードのスループットと CPU 使用率の両方にパフォーマンスの影響が出ます。パフォーマンスのオーバーヘッドを考慮するため、IPsec を有効にした場合の影響を確認してください。

IPSec は、NIC に到達する前に IP ペイロードレベルでトラフィックを暗号化して、NIC オフロードに使用されてしまう可能性のあるフィールドを保護します。これは、IPSec が有効になっている場合、一部の NIC アクセラレーション機能が使用できなくなる可能性があることを意味します。この状況は、スループットの低下と CPU 使用率の増加につながります。

13.4. マウント namespace のカプセル化による CPU 使用率の最適化
リンクのコピー

マウント namespace のカプセル化を使用して kubelet および CRI-O プロセスにプライベート namespace を提供することで、OpenShift Container Platform クラスターでの CPU 使用率を最適化できます。これにより、機能に違いはなく、systemd が使用するクラスター CPU リソースが削減されます。

重要

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

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

13.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 の動作は変更されていません。

13.4.2. マウント namespace のカプセル化の設定
リンクのコピー

クラスターがより少ないリソースオーバーヘッドで実行されるように、マウント 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 にある場合、カプセル化は有効ではありません。

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

13.4.4. カプセル化された namespace で追加サービスを実行する
リンクのコピー

OpenShift Container Platform に付属する kubensenter スクリプトを使用することで、既存のツールを Kubernetes マウントポイント内で追加のコマンドを実行するように適応させることができます。

ホスト OS で実行する機能に依存し、kubelet、CRI-O、またはコンテナー自体によって作成されたマウントポイントを表示できる監視ツールは、これらのマウントポイントを表示するためにコンテナーマウント namespace に入る必要があります。

kubensenter スクリプトは、マウントカプセル化機能の状態を認識しており、カプセル化が有効になっていない場合でも安全に実行できます。その場合、スクリプトはデフォルトのマウント namespace で提供されたコマンドを実行します。

たとえば、systemd サービスを新しい Kubernetes マウント namespace 内で実行する必要がある場合は、サービスファイルを編集し、kubensenter で ExecStart= コマンドラインを使用します。 

[Unit]
Description=Example service
[Service]
ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2

第14章 ベアメタルホストの管理
リンクのコピー

OpenShift Container Platform 内でベアメタルホストを直接設定できます。ベアメタルクラスターでノードをプロビジョニングおよび管理するには、Machine および MachineSet カスタムリソース (CR) を使用します。

14.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 を使用します。

14.2. ベアメタルホストのメンテナンス
リンクのコピー

クラスターインベントリーが物理インフラストラクチャーを正確に反映するようにするには、OpenShift Container Platform の Web コンソールを使用して、ベアメタルホスト設定の詳細を維持してください。

手順

  1. Web コンソールから、以下の手順を実行してください。

    1. Compute → Bare Metal Hosts に移動します。
    2. アクション ドロップダウンメニューからタスクを選択してください。
    3. ベースボード管理コントローラー (BMC) の詳細、ホストのブート MAC アドレス、電源管理の有効化などといった項目を管理します。また、ホストのネットワークインターフェイスおよびドライブの詳細を確認することもできます。
  2. ベアメタルホストをメンテナンスモードに移行します。ホストをメンテナンスモードに移行すると、スケジューラーは対応するベアメタルノードから管理対象のすべてのワークロードを移動します。新しいワークロードは、メンテナンスモードの間はスケジュールされません。

  3. Web コンソールでベアメタルホストのプロビジョニングを解除します。ホストのプロビジョニング解除により以下のアクションが実行されます。

    1. ベアメタルホストの CR に cluster.k8s.io/delete-machine: true を アノテーションとして追加します。

    2. 関連するコンピュートマシン群の規模を縮小します。

      注記

      デーモンセットおよび管理対象外の静的 Pod を別のノードに最初に移動することなく、ホストの電源をオフにすると、サービスの中断やデータの損失が生じる場合があります。

14.2.1. Web コンソールを使用したベアメタルホストのクラスターへの追加
リンクのコピー

物理ハードウェアをクラスターに統合するには、Web コンソールを使用してベアメタルホストを追加できます。これらのホストを追加することで、Web コンソールから直接これらのノードをプロビジョニングおよび管理できるようになります。

前提条件

  • RHCOS クラスターのベアメタルへのインストール
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Web コンソールで、Compute → Bare Metal Hosts に移動します。
  2. Add Host → New with Dialog を選択します。
  3. 新規ベアメタルホストの一意の名前を指定します。
  4. Boot MAC address を設定します。
  5. Baseboard Management Console (BMC) Address を設定します。
  6. ホストのベースボード管理コントローラー (BMC) のユーザー認証情報を入力します。
  7. 作成後にホストの電源をオンにすることを選択し、Create を選択します。

  8. 利用可能なベアメタルホストの数に一致するようにレプリカ数をスケールアップします。Compute → MachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシンレプリカ数を増やします。

    注記

    oc scale コマンドと適切なベアメタルコンピュートマシンセットを使用することで、ベアメタルノードの数を管理することもできます。

14.2.2. Web コンソールで YAML を使用してベアメタルホストをクラスターに追加する
リンクのコピー

ベアメタルホストを記述した YAML ファイルを使用することで、Web コンソールからクラスターにベアメタルホストを追加できます。

前提条件

  • クラスターで使用するために、ベアメタルインフラストラクチャー上に RHCOS コンピュートマシンをインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ベアメタルホスト用の シークレット CR を作成します。

手順

  1. Web コンソールで、Compute → Bare Metal Hosts に移動します。
  2. Add Host → New 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. レプリカの数を、利用可能なベアメタルホストの数に合わせて増やす。Compute → MachineSets に移動し、Actions ドロップダウンメニューから Edit Machine count を選択してクラスター内のマシン数を増やします。

    注記

    oc scale コマンドと適切なベアメタルコンピュートマシンセットを使用することで、ベアメタルノードの数を管理することもできます。

14.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 のラベルまたはセレクターを変更します。

14.2.4. プロビジョナーノードからベアメタルホストを削除する
リンクのコピー

状況によっては、ベアメタルホストをプロビジョナーノードから一時的に削除したい場合があります。たとえば、利用可能な BareMetalHost オブジェクトの数と一致する Machine オブジェクトの数を管理しないようにするには、MachineSet オブジェクトに baremetalhost.metal3.io/detached アノテーションを追加します。

プロビジョニング中に、OpenShift Container Platform 管理コンソールを使用したり、マシン設定プールの更新の結果としてベアメタルホストの再起動がトリガーされた場合を例に考えてみましょう。この場合、OpenShift Container Platform は統合型 Dell Remote Access Controller (iDRAC) にログインし、ジョブキューの削除を実行します。

注記

このアノテーションは、Provisioned、ExternallyProvisioned、または 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-'

14.2.5. Web コンソールを使用してベアメタルホストの電源を切る
リンクのコピー

Web コンソールからベアメタルクラスターホストの電源をオフにすることができます。ホストの電源を切る前に、ノードをスケジュール不可としてマークし、ノードからすべての Pod とワークロードをドレインしてください。

前提条件

  • クラスターで使用するために、ベアメタルインフラストラクチャーに RHCOS コンピュートマシンをインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 管理対象ホストを設定し、クラスターホストに Baseboard 管理コンソールの認証情報を追加しました。BMC 認証情報を追加するには、クラスターで Secret カスタムリソース (CR) を適用するか、Web コンソールにログインして管理対象となるようにベアメタルホストを設定します。

手順

  1. Nodes に移動し、電源をオフにするノードを選択します。Actions メニューを展開し、Mark as unschedulable を選択します。
  2. Pod デプロイメントを調整するか、またはノードでワークロードをゼロにスケールダウンして、ノード上で実行中の Pod を手動で削除または再配置します。ドレインプロセスが完了するまで待ちます。
  3. Compute → Bare Metal Hosts に移動します。
  4. 電源をオフにするベアメタルホストの Options メニュー を展開し、Power Off を選択します。
  5. Immediate power off を選択します。

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

第15章 huge page を使用してワークロードのメモリー管理を最適化する
リンクのコピー

特定のワークロードのメモリー管理を最適化するには、huge page を設定します。これらの Linux ベースのシステムページサイズを使用することで、メモリー割り当てを手動で制御し、システムの自動動作を上書きすることができます。

15.1. Huge Page の機能
リンクのコピー

メモリーマッピングの効率を最適化するには、huge page の機能を理解する必要があります。標準的な 4Ki ブロックとは異なり、huge page はより大きなメモリーセグメントであり、変換ルックアサイドバッファー (TLB) ハードウェアキャッシュへのトラッキング負荷を軽減します。

メモリーは Page と呼ばれるブロックで管理されます。ほとんどのシステムでは、1 ページは 4 キロバイト (Ki) です。1 メガバイト (Mi) のメモリーは 256 ページに相当し、1 ギガバイト (Gi) のメモリーは 25 万 6000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (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 の代わりに事前割り当てられた huge page を使用するように設計されているか、または推奨されている場合があります。

OpenShift Container Platform では、Pod のアプリケーションが事前に割り当てられた Huge Page を割り当て、消費することができます。

15.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 を直接指定できます。

15.2.1. 指定されたサイズの Huge Page の割り当て
リンクのコピー

プラットフォームによっては、複数の Huge Page サイズをサポートするものもあります。特定のサイズの Huge Page を割り当てるには、Huge Page の起動コマンドパラメーターの前に、Huge Page サイズの選択パラメーター hugepagesz=<size> を指定してください。<size> の値は、バイトで指定する必要があります。その際、オプションでスケール接尾辞 [kKmMgG] を指定できます。デフォルトの Huge Page サイズは、default_hugepagesz=<size> の起動パラメーターで定義できます。

15.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 に一致する補助グループで実行する必要があります。

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

15.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 にチューニングされたリソースの 名前 を指定します。
    仕様プロファイル
    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

15.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]

第16章 クラスターノードの低レイテンシーチューニングについて
リンクのコピー

まずクラスターノードの低遅延チューニングを理解することで、エッジコンピューティングを重要なロールとして活用し、通信事業者や 5G ネットワークアプリケーションにおける遅延や輻輳の問題を軽減し、アプリケーションのパフォーマンスを向上させることができます。

可能な限りレイテンシーを抑えたネットワークアーキテクチャーを維持することが、5G のネットワークパフォーマンス要件を満たすための鍵となります。平均レイテンシーが 50 ms の 4G テクノロジーと比較して、5G ではレイテンシーを 1 ms 以下に抑えることを目指しています。このレイテンシーの削減により、ワイヤレススループットが 10 倍向上します。

16.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 パーティショニングを可能にする最小限のデフォルトチューニングのみが必要です。レイテンシーが優先されるデータセンターやワークロードの場合でも、消費電力を最適化するための対策が講じられています。最も複雑なケースは、製造機械やソフトウェア無線などのレイテンシーの影響を受けやすい機器に近いクラスターです。この最後のクラスのデプロイメントは、多くの場合、ファーエッジと呼ばれます。ファーエッジデプロイメントの場合、超低レイテンシーが最優先事項であり、電力管理を犠牲にして実現されます。

Intel のプロセッサー技術であるハイパースレッディングを使用すると、物理的な CPU プロセッサーコアを 2 つの論理コアとして機能させ、2 つの独立したスレッドを同時に実行できます。

ハイパースレッディングにより、並列処理が有効な特定のワークロードタイプでシステムスループットが向上します。デフォルトの OpenShift Container Platform 設定では、ハイパースレッディングが有効になっていることが想定されています。

通信アプリケーションの場合、アプリケーションインフラストラクチャーを設計する際には、レイテンシーを可能な限り最小限に抑えるようにしてください。ハイパースレッディングは、パフォーマンス時間を低下させ、低レイテンシーを必要とする計算集約型ワークロードのスループットに悪影響を及ぼす可能性があります。ハイパースレッディングを無効にすると、予測可能なパフォーマンスが確保され、これらのワークロードの処理時間が短縮されます。

注記

ハイパースレッディングの実装と設定は、OpenShift Container Platform を実行しているハードウェアによって異なります。当該ハードウェアに固有のハイパースレッディング実装の詳細は、関連するホストハードウェアチューニング情報を参照してください。ハイパースレッディングを無効にすると、クラスターのコアあたりのコストが増加する可能性があります。

ノードをチューニングして低レイテンシーを実現するには、クラスターパフォーマンスプロファイルを使用します。インフラストラクチャーおよびアプリケーションコンテナーの CPU を制限したり、huge page やハイパースレッディングを設定したり、レイテンシーの影響を受けやすいプロセスの CPU パーティションを設定したりすることができます。

17.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 ツールを実行します。
  • ユースケースに合わせてパフォーマンスプロファイルを設定し、そのパフォーマンスプロファイルをクラスターに適用します。

17.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 を介してコンテナーに直接パラメーターを提供したりといったタスクを処理します。どちらの方法でも同じ結果が得られます。

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

17.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 ラッパースクリプトを実行している場合は、出力を圧縮する必要があります。

17.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.20 -h

    出力例

    A tool that automates creation of Performance Profiles

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  info        requires --must-gather-dir-path, ignores other arguments. [Valid values: log,json]

Usage:
  performance-profile-creator [flags]
performance-profile-creator [command]

Flags:
      --disable-ht                        Disable Hyperthreading
      --enable-hardware-tuning            Enable setting maximum cpu frequencies
  -h, --help                              help for performance-profile-creator
      --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

Use "performance-profile-creator [command] --help" for more information about a command.

  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.20 info --must-gather-dir-path /must-gather
    • --entrypoint performance-profile-creator は、podman への新しいエントリーポイントとして、パフォーマンスプロファイルクリエーターを定義します。

    • -v <path_to_must_gather> は、次のいずれかのコンポーネントへのパスを指定します。

      • must-gather データが含まれるディレクトリー。

      • must-gather の展開された .tar ファイルを含む既存のディレクトリー

        出力例

        level=info msg="Nodes names targeted by master pool are: "
level=info msg="Nodes names targeted by worker-cnf pool are: host2.example.com "
level=info msg="Nodes names targeted by worker pool are: host.example.com host1.example.com "
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.20 --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
  net:
    userLevelNetworking: false
  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

17.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.20"
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

17.1.6. Performance Profile Creator の引数
リンクのコピー

パフォーマンスプロファイルの生成をカスタマイズするには、Performance Profile Creator の引数を確認してください。

Expand
表17.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
表17.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。

17.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: ''
  realTimeKernel:
    enabled: false
    globallyDisableIrqLoadBalancing: true

CPU_ISOLATED キー、CPU_RESERVED キー、および HUGEPAGES_COUNT キーの設定に適した値を入力します。

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

17.2.3. 通信事業者コアリファレンス設計パフォーマンスプロファイル
リンクのコピー

通信事業者のコアワークロードをホストするために、汎用ハードウェア上の OpenShift Container Platform クラスターのノードレベルのパフォーマンス設定を設定する、事前設定済みの設計パフォーマンスプロファイルを使用できます。

通信事業者コアリファレンス設計パフォーマンスプロファイル

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

17.3. サポートされているパフォーマンスプロファイルの API バージョン
リンクのコピー

Node Tuning Operator は、パフォーマンスプロファイル apiVersion フィールドの v2、v1、および v1alpha1 をサポートします。v1 および v1alpha1 API は同一です。v2 API には、デフォルト値の false が設定されたオプションのブール値フィールド globallyDisableIrqLoadBalancing が含まれます。

デバイス割り込み処理を使用するためのパフォーマンスプロファイルのアップグレード

Node Tuning Operator パフォーマンスプロファイルのカスタムリソース定義 (CRD) を v1 または v1alpha1 から v2 にアップグレードする場合、globallyDisableIrqLoadBalancing は true に設定されます。

注記

globallyDisableIrqLoadBalancing は、IRQ ロードバランシングを分離 CPU セットに対して無効にするかどうかを切り替えます。このオプションを true に設定すると、分離 CPU セットの IRQ ロードバランシングが無効になります。オプションを false に設定すると、IRQ をすべての CPU 間でバランスさせることができます。

Node Tuning Operator API の v1alpha1 から v1 へのアップグレード
Node Tuning Operator API バージョンを v1alpha1 から v1 にアップグレードする場合、v1alpha1 パフォーマンスプロファイルは "None" 変換ストラテジーを使用してオンザフライで変換され、API バージョン v1 の Node Tuning Operator に提供されます。
Node Tuning Operator API の v1alpha1 または v1 から v2 へのアップグレード
古い Node Tuning Operator API バージョンからアップグレードする場合、既存の v1 および v1alpha1 パフォーマンスプロファイルは、globallyDisableIrqLoadBalancing フィールドに true の値を挿入する変換 Webhook を使用して変換されます。

17.4. ノードの消費電力とワークロードヒントによるリアルタイム処理
リンクのコピー

Performance Profile Creator (PPC) ツールを使用すると、環境のハードウェアとトポロジーに適したパフォーマンスプロファイルを作成できます。

次の表は、PPC ツールに関連付けられた power-consumption-mode フラグに設定可能な値と、適用されるワークロードヒントを示しています。

Expand
表17.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.20 \
--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 周波数は、すべてのコアがすべて使用されているときに全コアが実行される周波数です。

17.6. インフラコンテナーおよびアプリケーションコンテナー用 CPU
リンクのコピー

一般的なハウスキーピングやワークロードタスクは、レイテンシーに敏感なプロセスに影響を与える可能性のある方法で CPU を使用します。デフォルトでは、コンテナーランタイムはすべてのオンライン CPU を使用して、すべてのコンテナーを一緒に実行します。これが原因で、コンテキストスイッチおよびレイテンシーが急増する可能性があります。

CPU をパーティショニングすることで、ノイズの多いプロセスとレイテンシーの影響を受けやすいプロセスを分離し、干渉を防ぐことができます。以下の表は、Node Tuning Operator を使用してノードを調整した後、CPU でプロセスがどのように実行されるかを示しています。

Expand
表17.4 プロセスの CPU 割り当て
プロセスタイプDetails

Burstable および BestEffort Pod

低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。

インフラストラクチャー Pod

低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。

割り込み

予約済み CPU にリダイレクトします (OpenShift Container Platform 4.7 以降ではオプション)

カーネルプロセス

予約済み CPU へのピン

レイテンシーの影響を受けやすいワークロード Pod

分離されたプールからの排他的 CPU の特定のセットへのピン

OS プロセス/systemd サービス

予約済み CPU へのピン

すべての QoS プロセスタイプ (Burstable、BestEffort、または Guaranteed) の Pod に割り当て可能なノード上のコアの容量は、分離されたプールの容量と同じです。予約済みプールの容量は、クラスターおよびオペレーティングシステムのハウスキーピング業務で使用するためにノードの合計コア容量から削除されます。

例 1
ノードは 100 コアの容量を備えています。クラスター管理者は、パフォーマンスプロファイルを使用して、50 コアを分離プールに割り当て、50 コアを予約プールに割り当てます。クラスター管理者は、25 コアを QoS Guaranteed Pod に割り当て、25 コアを BestEffort または Burstable Pod に割り当てます。これは、分離されたプールの容量と一致します。
例 2
ノードは 100 コアの容量を備えています。クラスター管理者は、パフォーマンスプロファイルを使用して、50 コアを分離プールに割り当て、50 コアを予約プールに割り当てます。クラスター管理者は、50 個のコアを QoS Guaranteed Pod に割り当て、1 個のコアを BestEffort または Burstable Pod に割り当てます。これは、分離されたプールの容量を 1 コア超えています。CPU 容量が不十分なため、Pod のスケジューリングが失敗します。

使用する正確なパーティショニングパターンは、ハードウェア、ワークロードの特性、予想されるシステム負荷などの多くの要因によって異なります。いくつかのサンプルユースケースは次のとおりです。

  • レイテンシーの影響を受けやすいワークロードがネットワークインターフェイスコントローラー (NIC) などの特定のハードウェアを使用する場合は、分離されたプール内の CPU が、このハードウェアにできるだけ近いことを確認してください。少なくとも、ワークロードを同じ Non-Uniform Memory Access (NUMA) ノードに配置する必要があります。
  • 予約済みプールは、すべての割り込みを処理するために使用されます。システムネットワークに依存する場合は、すべての着信パケット割り込みを処理するために、十分なサイズの予約プールを割り当てます。4.20 以降のバージョンでは、必要に応じて、ワークロードに機密のラベルを付けることができます。

予約済みパーティションと分離パーティションにどの特定の CPU を使用するかを決定するには、詳細な分析と測定が必要です。デバイスやメモリーの NUMA アフィニティーなどの要因が作用しています。選択は、ワークロードアーキテクチャーと特定のユースケースにも依存します。

重要

予約済みの CPU プールと分離された CPU プールは重複してはならず、これらは共に、ワーカーノードの利用可能なすべてのコアに広がる必要があります。

ハウスキーピングタスクとワークロードが相互に干渉しないようにするには、パフォーマンスプロファイルの spec セクションで CPU の 2 つのグループを指定します。

  • isolated - アプリケーションコンテナーワークロードの CPU を指定します。これらの CPU のレイテンシーが一番低くなります。このグループのプロセスには割り込みがないため、DPDK ゼロパケットロスの帯域幅がより高くなります。
  • reserved - クラスターおよびオペレーティングシステムのハウスキーピング業務用の CPU を指定します。reserved グループのスレッドは、ビジーであることが多いです。reserved グループでレイテンシーの影響を受けやすいアプリケーションを実行しないでください。レイテンシーの影響を受けやすいアプリケーションは、isolated グループで実行されます。

17.7. インフラストラクチャーコンテナーとアプリケーションコンテナー用に 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
    パフォーマンスプロファイルを特定のノードに適用するためのノードセレクターを指定します。オプションのパラメーター。

17.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 を参照してください。

17.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 を使用します。

17.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 でのデバイス割り込みを無効にしません。

17.10.1. ノードの有効な IRQ アフィニティー設定の確認
リンクのコピー

一部の IRQ コントローラーは IRQ アフィニティー設定をサポートしておらず、常にすべてのオンライン CPU を IRQ マスクとして公開する場合があります。これらの IRQ コントローラーは実質的に CPU 0 上で動作するため、ノードの有効な IRQ アフィニティー設定を見つける必要があります。

以下は、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 であっても変更できませんを参照してください。

17.10.2. ノード割り込みアフィニティーの設定
リンクのコピー

どのコアがデバイス割り込み要求 (IRQ) を受信できるかを制御するために、IRQ 動的負荷分散用にクラスターノードを設定します。

前提条件

  • コアを分離するには、すべてのサーバーハードウェアコンポーネントが IRQ アフィニティーをサポートしている必要があります。サーバーのハードウェアコンポーネントが IRQ アフィニティーをサポートしているかどうかを確認するには、サーバーのハードウェア仕様を参照するか、ハードウェアプロバイダーにお問い合わせください。

手順

  1. cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
  2. パフォーマンスプロファイルの apiVersion を performance.openshift.io/v2 を使用するように設定します。
  3. globallyDisableIrqLoadBalancing フィールドを削除するか、これを false に設定します。

  4. 適切な分離された CPU と予約された CPU を設定します。以下のスニペットは、2 つの CPU を確保するプロファイルを示しています。IRQ 負荷分散は、isolated CPU セットで実行されている Pod に対して有効になります。 

    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 パーティショニングを参照してください。

17.11. メモリーページサイズの設定
リンクのコピー

システム管理者は、メモリーページサイズを設定することにより、ワークロード要件に合わせてより効率的なメモリー管理を特定のノードに実装できます。Node Tuning Operator は、パフォーマンスプロファイルを使用して、huge page とカーネルページサイズを設定する方法を提供します。

17.11.1. カーネルページサイズの設定
リンクのコピー

特定のノードのカーネルページサイズを設定するには、パフォーマンスプロファイルの kernelPageSize 仕様を使用します。メモリーを大量に消費する高パフォーマンスのワークロードには、大きなカーネルページサイズを指定してください。

注記

x86_64 または AMD64 アーキテクチャーのノードの場合、kernelPageSize 仕様には 4k のみを指定できます。AArch64 アーキテクチャーのノードの場合、kernelPageSize 仕様には 4k または 64k を指定できます。64k オプションを使用するには、リアルタイムカーネルを無効にする必要があります。デフォルト値は 4k です。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. PerformanceProfile リソースを定義する YAML ファイルを作成して、カーネルページサイズを設定するノードを対象とするパフォーマンスプロファイルを作成します。

    pp-kernel-pages.yaml ファイルの例

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
    name: example-performance-profile
#...
spec:
    kernelPageSize: "64k"
    realTimeKernel:
        enabled: false
    nodeSelector:
        node-role.kubernetes.io/worker: ""

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

    spec.kernelPageSize
    カーネルページサイズを 64k に指定します。AArch64 アーキテクチャーのノードには 64k のみ指定できます。デフォルト値は 4k です。
    spec.realTimeKernel.enabled:false
    リアルタイムカーネルを無効にするかどうかを指定します。false に設定すると、カーネルが無効になります。64k カーネルページサイズオプションを使用するには、リアルタイムカーネルを無効にする必要があります。
    spec.nodeSelector.node-role.kubernetes.io/worker
    ワーカーの ロールを持つターゲットノードを指定します。

  2. パフォーマンスプロファイルをクラスターに適用します。 

    $ oc create -f pp-kernel-pages.yaml

    出力例

    performanceprofile.performance.openshift.io/example-performance-profile created

検証

  1. 次のコマンドを実行して、パフォーマンスプロファイルを適用したノードでデバッグセッションを開始します。 

    $ oc debug node/<node_name>
    • <node_name>: <node_name> を、パフォーマンスプロファイルが適用されているノードの名前に置き換えてください。

  2. 次のコマンドを実行して、カーネルページサイズがパフォーマンスプロファイルで指定した値に設定されていることを確認します。 

    $ getconf PAGESIZE

    出力例

    65536

17.11.2. Huge Page の設定
リンクのコピー

OpenShift Container Platform クラスターで使用される huge page はノードに事前に割り当てる必要があるため、Node Tuning Operator を使用して特定のノードに huge page を割り当ててください。

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

17.11.3. 複数の Huge Page サイズの割り当て
リンクのコピー

同じコンテナーで異なるサイズの Huge Page を要求できます。このタスクを実行することで、異なる huge page サイズを必要とするコンテナーで設定される、より複雑な Pod を定義できます。

次の例は、1G と 2M の サイズを定義する方法を示しています。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
# ...

17.12. Node Tuning Operator を使用した NIC キューの削減
リンクのコピー

Node Tuning Operator は、NIC キューを削減してパフォーマンスを向上させるのに役立ちます。パフォーマンスプロファイルを使用して調整を行い、さまざまなネットワークデバイスのキューをカスタマイズできます。

17.12.1. パフォーマンスプロファイルによる NIC キューの調整
リンクのコピー

パフォーマンスプロファイルを使用すると、各ネットワークデバイスのキュー数を調整できます。Node Tuning Operator を使用することで、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 は、ブール値フラグとして指定される必須フィールドです。userLevelNetworking が true の場合、サポートされているすべてのデバイスのキュー数は、予約された CPU 数に設定されます。デフォルトは false です。

    • devices は、キューを予約 CPU 数に設定するデバイスのリストを指定する任意のフィールドです。デバイスリストに何も指定しないと、設定がすべてのネットワークデバイスに適用されます。設定は以下のとおりです。

      • interfaceName: このフィールドはインターフェイス名を指定し、正または負のシェルスタイルのワイルドカードをサポートします。

        • ワイルドカード構文の例: <string> .*
        • 負のルールには、感嘆符のプリフィックスが付きます。除外リスト以外のすべてのデバイスにネットキューの変更を適用するには、!<device> を使用します (例: !eno1)。
      • vendorID: 16 ビット (16 進数) として表されるネットワークデバイスベンダー ID。接頭辞は 0x です。

      • deviceID: 16 ビット (16 進数) として表されるネットワークデバイス ID (モデル)。接頭辞は 0x です。

        注記

        deviceID が指定されている場合は、vendorID も定義する必要があります。デバイスエントリー interfaceName、vendorID、または vendorID と deviceID のペアで指定されているすべてのデバイス識別子に一致するデバイスは、ネットワークデバイスとしての資格があります。その後、このネットワークデバイスは net キュー数が予約 CPU 数に設定されます。

        2 つ以上のデバイスを指定すると、net キュー数は、それらのいずれかに一致する net デバイスに設定されます。

  5. このパフォーマンスプロファイルの例を使用して、キュー数をすべてのデバイスの予約 CPU 数に設定します。 

    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. このパフォーマンスプロファイルの例を使用して、インターフェイス名 eth0、0x1af4 の vendorID、および 0x1000 の deviceID を持つすべてのデバイスの予約 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

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

interfaceName が eth0 のデバイスの場合に 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 キューを持ちます。同様に、interfaceName が eth0 のデバイスには、合計 net キューが 2 に設定されます。

17.12.3. NIC キューの調整に関するロギング
リンクのコピー

NIC キューの調整を確認するには、Tuned デーモンのログを確認してください。これらのログメッセージには、それぞれの 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

低レイテンシーを実現するために、パフォーマンスプロファイルを適用して Hosted Control Plane をチューニングします。パフォーマンスプロファイルを使用すると、インフラストラクチャーおよびアプリケーションコンテナーの CPU を制限したり、レイテンシーの影響を受けやすいプロセスに対して huge page、ハイパースレッディング、CPU パーティションを設定できます。

18.1. Hosted Control Plane のパフォーマンスプロファイルの作成
リンクのコピー

Performance Profile Creator (PPC) ツールを使用して、クラスターパフォーマンスプロファイルを作成できます。PPC は Node Tuning Operator の機能です。

PPC は、クラスターに関する情報とユーザー指定の設定を組み合わせて、ハードウェア、トポロジー、ユースケースに適したパフォーマンスプロファイルを生成します。以下の高レベルなワークフローは、クラスターにパフォーマンスプロファイルを作成して適用します。

  1. must-gather コマンドを使用して、クラスターに関する情報を収集します。
  2. PPC ツールを使用してパフォーマンスプロファイルを作成します。
  3. パフォーマンスプロファイルをクラスターに適用します。

18.1.1. PPC 用に Hosted Control Plane クラスターに関するデータを収集する
リンクのコピー

Performance Profile Creator (PPC) ツールには must-gather データが必要です。クラスター管理者は、must-gather コマンドを実行し、クラスターに関する情報を取得します。

前提条件

  • 管理クラスターへの cluster-admin ロールアクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、管理クラスターの kubeconfig ファイルをエクスポートします。 

    $ export MGMT_KUBECONFIG=<path_to_mgmt_kubeconfig>

  2. 次のコマンドを実行して、すべての namespace のノードプールをすべてリスト表示します。 

    $ oc --kubeconfig="$MGMT_KUBECONFIG" get np -A

    出力例

    NAMESPACE   NAME                     CLUSTER       DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    democluster-us-east-1a   democluster   1               1               False         False        4.17.0    False             True

    • 出力には、NodePool リソースが定義されている管理クラスター内の namespace である clusters が表示されます。
    • NodePool リソースの名前 (例: democluster-us-east-1a)。
    • この NodePool が属する HostedCluster。たとえば、democluster などです。

  3. 管理クラスターで次のコマンドを実行して、利用可能なシークレットをリスト表示します。 

    $ oc get secrets -n clusters

    出力例

    NAME                              TYPE                      DATA   AGE
builder-dockercfg-25qpp           kubernetes.io/dockercfg   1      128m
default-dockercfg-mkvlz           kubernetes.io/dockercfg   1      128m
democluster-admin-kubeconfig      Opaque                    1      127m
democluster-etcd-encryption-key   Opaque                    1      128m
democluster-kubeadmin-password    Opaque                    1      126m
democluster-pull-secret           Opaque                    1      128m
deployer-dockercfg-8lfpd          kubernetes.io/dockercfg   1      128m

  4. 次のコマンドを実行して、ホステッドクラスターの kubeconfig ファイルを抽出します。 

    $ oc get secret <secret_name> -n <cluster_namespace> -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig

    例

    $ oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig

  5. ホステッドクラスターの must-gather バンドルを作成するために、別のターミナルウィンドウを開き、次のコマンドを実行します。

    1. ホステッドクラスターの kubeconfig ファイルをエクスポートします。 

      $ export HC_KUBECONFIG=<path_to_hosted_cluster_kubeconfig>

      例

      $ export HC_KUBECONFIG=~/hostedcpkube/hosted-cluster-kubeconfig

    2. must-gather データを保存するディレクトリーに移動します。

    3. ホステッドクラスターのトラブルシューティングデータを収集します。 

      $ oc --kubeconfig="$HC_KUBECONFIG" adm must-gather

    4. 作業ディレクトリーに作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。 

      $ tar -czvf must-gather.tar.gz must-gather.local.1203869488012141147

18.1.2. Podman を使用してホステッドクラスターで Performance Profile Creator を実行する
リンクのコピー

クラスター管理者は、Podman と Performance Profile Creator (PPC) ツールを使用してパフォーマンスプロファイルを作成できます。

PPC の引数の詳細は、「Performance Profile Creator の引数」を参照してください。

PPC ツールは、ホステッドクラスターを認識するように設計されています。ツールは must-gather データからホステッドクラスターを検出すると、自動的に次の操作を実行します。

  • マシン設定プール (MCP) が存在しないことを認識します。
  • MCP の代わりに、ノードプールをコンピュートノード設定の信頼できるソースとして使用します。
  • 特定のプールを対象とする場合を除き、node-pool-name 値を明示的に指定する必要はありません。
重要

PPC は、ホステッドクラスターからの must-gather データを使用して、パフォーマンスプロファイルを作成します。パフォーマンス設定の対象となるノードのラベルを変更するなど、クラスターに変更を加えた場合は、PPC を再度実行する前に、must-gather データを再作成する必要があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • ホステッドクラスターがインストールされている。
  • Podman と OpenShift CLI (oc) がインストールされている。
  • Node Tuning Operator イメージにアクセスできる。
  • クラスターの must-gather データにアクセスできる。

手順

  1. ホステッドクラスターで、次のコマンドを実行して、Podman を使用して registry.redhat.io に認証します。 

    $ podman login registry.redhat.io
     
    Username: <user_name>
Password: <password>

  2. 次のコマンドを実行して、ホステッドクラスターにパフォーマンスプロファイルを作成します。この例では、サンプルの 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.20 \
    --must-gather-dir-path /must-gather \
    --reserved-cpu-count=2 \
    --rt-kernel=false \
    --split-reserved-cpus-across-numa=false \
    --topology-manager-policy=single-numa-node \
    --node-pool-name=democluster-us-east-1a \
    --power-consumption-mode=ultra-low-latency \
    --offlined-cpu-count=1 \
    > my-hosted-cp-performance-profile.yaml

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

    /path/to/must-gather:/must-gather:z
    oc adm must-gather の出力が作成されたローカルディレクトリーをコンテナーにマウントするように指定します。
    予約済み CPU 数=2
    予約済み CPU 数を 2 に指定します。
    rt-kernel=false
    リアルタイムカーネルを無効にするかどうかを指定します。false に設定すると、カーネルが無効になります。
    split-reserved-cpus-across-numa=false
    CPU を NUMA ノード間で分割するかどうかを指定します。false に設定すると、CPU 分割が無効になります。
    トポロジーマネージャーポリシー=単一 NUMA ノード
    NUMA トポロジーポリシーを指定します。NUMA Resources Operator をインストールする場合、これを single-numa-node に設定する必要があります。
    消費電力モード=超低遅延
    消費電力の増加を代償にして、レイテンシーを最小限に抑えることを指定します。
    オフライン CPU 数=1
    1 つの CPU をオフライン化することを指定します。

    出力例

    level=info msg="Nodes names targeted by democluster-us-east-1a pool are: ip-10-0-129-110.ec2.internal "
level=info msg="NUMA cell(s): 1"
level=info msg="NUMA cell 0 : [0 2 1 3]"
level=info msg="CPU(s): 4"
level=info msg="2 reserved CPUs allocated: 0,2 "
level=info msg="1 isolated CPUs allocated: 1"
level=info msg="Additional Kernel Args based on configuration: []

  3. 次のコマンドを実行して、作成された YAML ファイルを確認します。 

    $ cat my-hosted-cp-performance-profile

    出力例

    ---
apiVersion: v1
data:
  tuning: |
    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      creationTimestamp: null
      name: performance
    spec:
      cpu:
        isolated: "1"
        offlined: "3"
        reserved: 0,2
      net:
        userLevelNetworking: false
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      numa:
        topologyPolicy: single-numa-node
      realTimeKernel:
        enabled: false
      workloadHints:
        highPowerConsumption: true
        perPodPowerManagement: false
        realTime: true
    status: {}
kind: ConfigMap
metadata:
  name: performance
  namespace: clusters

18.1.3. ホステッドクラスターでの低レイテンシーチューニングの設定
リンクのコピー

ホステッドクラスター内のノードでパフォーマンスプロファイルを使用して低レイテンシーを設定するには、Node Tuning Operator を使用できます。Hosted Control Plane では、Tuned オブジェクトを含む config map を作成し、ノードプールでその config map を参照することで、低レイテンシーのチューニングを設定できます。

この場合の Tuned オブジェクトは、ノードプール内のノードに適用するパフォーマンスプロファイルを定義する PerformanceProfile オブジェクトです。

手順

  1. 次のコマンドを実行して、管理クラスターの kubeconfig ファイルをエクスポートします。 

    $ export MGMT_KUBECONFIG=<path_to_mgmt_kubeconfig>

  2. 次のコマンドを実行して、管理クラスターに ConfigMap オブジェクトを作成します。 

    $ oc --kubeconfig="$MGMT_KUBECONFIG" apply -f my-hosted-cp-performance-profile.yaml

  3. 次のコマンドを実行して、clusters namespace の NodePool オブジェクトを編集します。spec.tuningConfig フィールドを追加して、作成したパフォーマンスプロファイルの名前をそのフィールドに追加します。 

    $ oc edit np -n clusters
     
    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  annotations:
    hypershift.openshift.io/nodePoolCurrentConfig: 2f752a2c
    hypershift.openshift.io/nodePoolCurrentConfigVersion: 998aa3ce
    hypershift.openshift.io/nodePoolPlatformMachineTemplate: democluster-us-east-1a-3dff55ec
  creationTimestamp: "2025-04-09T09:41:55Z"
  finalizers:
  - hypershift.openshift.io/finalizer
  generation: 1
  labels:
    hypershift.openshift.io/auto-created-for-infra: democluster
  name: democluster-us-east-1a
  namespace: clusters
  ownerReferences:
  - apiVersion: hypershift.openshift.io/v1beta1
    kind: HostedCluster
    name: democluster
    uid: af77e390-c289-433c-9d29-3aee8e5dc76f
  resourceVersion: "53056"
  uid: 11efa47c-5a7b-476c-85cf-a274f748a868
spec:
  tuningConfig:
  - name: performance
  arch: amd64
  clusterName: democluster
  management:
    注記

    複数のノードプールで同じプロファイルを参照できます。Hosted Control Plane では、Node Tuning Operator により、Tuned カスタムリソースを区別するために、リソースの名前にノードプール名と namespace のハッシュが追加されます。変更を加えると、設定の変更が必要であることがシステムによって検出され、そのプール内のノードのローリング更新が開始し、新しい設定が適用されます。

検証

  1. 次のコマンドを実行して、すべての namespace のノードプールをすべてリスト表示します。 

    $ oc --kubeconfig="$MGMT_KUBECONFIG" get np -A

    出力例

    NAMESPACE   NAME                     CLUSTER       DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    democluster-us-east-1a   democluster   1               1               False         False        4.17.0    False             True

    注記

    UPDATINGCONFIG フィールドは、ノードプールの設定が更新中かどうかを示します。この更新中は、ノードプールのステータスの UPDATINGCONFIG フィールドが True になります。UPDATINGCONFIG フィールドが False に戻った場合に限り、新しい設定が完全に適用されたとみなされます。

  2. 次のコマンドを実行して、clusters-democluster namespace 内のすべての config map をリスト表示します。 

    $ oc --kubeconfig="$MGMT_KUBECONFIG" get cm -n clusters-democluster

    出力例

    NAME                                                 DATA   AGE
aggregator-client-ca                                 1      69m
auth-config                                          1      68m
aws-cloud-config                                     1      68m
aws-ebs-csi-driver-trusted-ca-bundle                 1      66m
...                                                  1      67m
kubelet-client-ca                                    1      69m
kubeletconfig-performance-democluster-us-east-1a     1      22m
...
ovnkube-identity-cm                                  2      66m
performance-democluster-us-east-1a                   1      22m
...
tuned-performance-democluster-us-east-1a             1      22m

    この出力には、kubeletconfig kubeletconfig-performance-democluster-us-east-1a とパフォーマンスプロファイル performance-democluster-us-east-1a が作成されたことが示されています。Node Tuning Operator により、Tuned オブジェクトがホステッドクラスターに同期されます。どの Tuned オブジェクトが定義されているか、どのプロファイルが各ノードに適用されているかを確認できます。

  3. 次のコマンドを実行して、管理クラスターで使用可能なシークレットをリスト表示します。 

    $ oc get secrets -n clusters

    出力例

    NAME                              TYPE                      DATA   AGE
builder-dockercfg-25qpp           kubernetes.io/dockercfg   1      128m
default-dockercfg-mkvlz           kubernetes.io/dockercfg   1      128m
democluster-admin-kubeconfig      Opaque                    1      127m
democluster-etcd-encryption-key   Opaque                    1      128m
democluster-kubeadmin-password    Opaque                    1      126m
democluster-pull-secret           Opaque                    1      128m
deployer-dockercfg-8lfpd          kubernetes.io/dockercfg   1      128m

  4. 次のコマンドを実行して、ホステッドクラスターの kubeconfig ファイルを抽出します。 

    $ oc get secret <secret_name> -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig

    例

    $ oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig

  5. 次のコマンドを実行して、ホステッドクラスターの kubeconfig をエクスポートします。 

    $ export HC_KUBECONFIG=<path_to_hosted-cluster-kubeconfig>

  6. 次のコマンドを実行して、kubeletconfig がホステッドクラスターにミラーリングされていることを確認します。 

    $ oc --kubeconfig="$HC_KUBECONFIG" get cm -n openshift-config-managed | grep kubelet

    出力例

    kubelet-serving-ca                            			1   79m
kubeletconfig-performance-democluster-us-east-1a		1   15m

  7. 次のコマンドを実行して、ホステッドクラスターに single-numa-node ポリシーが設定されていることを確認します。 

    $ oc --kubeconfig="$HC_KUBECONFIG" get cm kubeletconfig-performance-democluster-us-east-1a -o yaml -n openshift-config-managed | grep single

    出力例

        topologyManagerPolicy: single-numa-node

第19章 リアルタイムおよび低レイテンシーワークロードのプロビジョニング
リンクのコピー

組織が高性能コンピューティングと低遅延かつ予測可能なレイテンシーを必要とする場合、特に金融業界や通信業界においては、Node Tuning Operator を使用して自動チューニングを実装することで、OpenShift Container Platform アプリケーションの低レイテンシー性能と一貫した応答時間を実現できます。

このような変更を行うには、パフォーマンスプロファイル設定を使用します。

kernel-rt へのカーネルの更新、Pod インフラコンテナーを含むクラスターおよびオペレーティングシステムのハウスキーピング作業用 CPU の予約、アプリケーションコンテナーがワークロードを実行するための CPU の分離、未使用の CPU の無効化による電力消費削減を行うことができます。

注記

アプリケーションを作成するときは、RHEL for Real Time プロセスおよびスレッド に記載されている一般的な推奨事項に従ってください。

19.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.20"
    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 を必要とするアプリケーションと組み合わせて実行プローブを使用すると、レイテンシーが急上昇する可能性があります。代わりに、適切に設定されたネットワークプローブのセットなど、他のプローブを使用してください。

19.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]

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

      仕様コンテナーイメージ
      hello-openshift イメージなどの公開イメージを指定します。
      spec.containers.resources.limits.memory
      メモリー制限を 200MB に指定します。
      spec.containers.resources.limits.cpu
      CPU 数を 1 に制限することを指定します。
      仕様.コンテナー.リソース.リクエスト.メモリー
      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

19.3. Pod の CPU 負荷分散の無効化
リンクのコピー

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 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。

19.4. 優先度の高い Pod の省電力モードの無効化
リンクのコピー

ノードで省電力設定を使用している場合に優先度の高いワークロードを保護するには、Pod レベルでパフォーマンス設定を適用してください。これにより、設定が Pod で使用されるすべてのコアに適用され、パフォーマンスの安定性が維持されます。

Pod レベルで P ステートと C ステートを無効にすることで、優先度の高いワークロードを設定して、最高のパフォーマンスと最小の待機時間を実現できます。

Expand
表19.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 を再起動してアノテーションを適用します。

19.5. CPU CFS クォータの無効化
リンクのコピー

ピニングされた Pod の CPU スロットリングを除外するには、cpu-quota.crio.io: "disable" アノテーションを使用して Pod を作成します。このアノテーションは、Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。

手順

  • ピニングされた 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 クォータを無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響を与える可能性があります。

19.6. ピニングされたコンテナーが実行されている CPU の割り込み処理の無効化
リンクのコピー

ワークロードの低レイテンシーを実現するために、一部のコンテナーでは、コンテナーのピニング先の CPU がデバイス割り込みを処理しないようにする必要があります。irq-load-balancing.crio.io Pod アノテーションを使用すると、デバイス割り込みを、ピン留めされたコンテナーが実行されている CPU で処理するかどうかを制御できます。

個々の Pod に属するコンテナーがピニングされている CPU の割り込み処理を無効にするには、パフォーマンスプロファイルで globallyDisableIrqLoadBalancing が false に設定されていることを確認します。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>
...

第20章 低レイテンシーノードのチューニングステータスのデバッグ
リンクのコピー

PerformanceProfile の カスタムリソース (CR) ステータスフィールドを使用して、クラスターノードのチューニングステータスを報告したり、レイテンシーの問題をデバッグしたりします。

20.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
状態とエラーの詳細を説明する人が判読できる理由 (ある場合)。

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

20.3. must-gather ツールについて
リンクのコピー

クラスターの問題をデバッグするには、oc adm must-gather CLI コマンドを使用します。このツールは、トラブルシューティングに必要な可能性が最も高い診断情報を収集し、分析に必要なデータを確実に提供します。

oc adm must-gather CLI コマンドは、クラスターから以下の情報を収集します。

  • リソース定義
  • 監査ログ
  • サービスログ

--image 引数を指定してコマンドを実行する際にイメージを指定できます。イメージを指定する際、ツールはその機能または製品に関連するデータを収集します。oc adm must-gather を実行すると、新しい Pod がクラスターに作成されます。データは Pod で収集され、must-gather.local で始まる新規ディレクトリーに保存されます。このディレクトリーは、現行の作業ディレクトリーに作成されます。

20.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 カスタマーポータル で作成したサポートケースに添付します。

第21章 プラットフォーム検証のためのレイテンシーテストの実行
リンクのコピー

Cloud-native Network Functions (CNF) テストイメージを使用して、CNF ワークロードの実行に必要なすべてのコンポーネントがインストールされている CNF 対応の OpenShift Container Platform クラスターでレイテンシーテストを実行できます。レイテンシーテストを実行して、ワークロードのノードチューニングを検証します。

cnf-tests コンテナーイメージは、registry.redhat.io/openshift4/cnf-tests-rhel9:v4.20 で入手できます。

21.1. レイテンシーテストを実行するための前提条件
リンクのコピー

レイテンシーテストを実行するには、クラスターが次の要件を満たしている必要があります。

  • 必要な CNF 設定をすべて適用した。これには、リファレンス設計仕様 (RDS) またはお客様固有の要件に基づく PerformanceProfile クラスターおよびその他の設定が含まれます。
  • podman login コマンドを使用して、カスタマーポータルの認証情報で registry.redhat.io にログインした。

21.2. レイテンシーの測定
リンクのコピー

システム遅延を正確に測定するには、cnf-tests イメージに含まれている hwlatdetect、cyclictest、および oslat ツールを使用してください。これらのメトリクスを評価することで、環境におけるパフォーマンスの遅延を特定し、解決するのに役立ちます。

各ツールには特定の用途があります。信頼できるテスト結果を得るために、ツールを順番に使用します。

hwlatdetect
ベアメタルハードウェアが達成できるベースラインを測定します。次のレイテンシーテストに進む前に、hwlatdetect によって報告されるレイテンシーが必要なしきい値を満たしていることを確認してください。これは、オペレーティングシステムのチューニングによってハードウェアレイテンシーのスパイクを修正することはできないためです。
cyclictest
hwlatdetect が検証に合格した後、リアルタイムのカーネルスケジューラーのレイテンシーを検証します。cyclictest ツールは繰り返しタイマーをスケジュールし、希望のトリガー時間と実際のトリガーの時間の違いを測定します。この違いは、割り込みまたはプロセスの優先度によって生じるチューニングで、基本的な問題を発見できます。ツールはリアルタイムカーネルで実行する必要があります。
oslat
CPU 集約型 DPDK アプリケーションと同様に動作し、CPU の高いデータ処理をシミュレーションするビジーループにすべての中断と中断を測定します。

テストでは、次の環境変数が導入されます。

Expand
表21.1 レイテンシーテスト環境変数
環境変数説明

LATENCY_TEST_DELAY

テストの実行を開始するまでの時間を秒単位で指定します。この変数を使用すると、CPU マネージャーの調整ループでデフォルトの CPU プールを更新できるようになります。デフォルト値は 0 です。

LATENCY_TEST_CPUS

レイテンシーテストを実行する Pod が使用する CPU の数を指定します。変数を設定しない場合、デフォルト設定にはすべての分離された CPU が含まれます。

LATENCY_TEST_RUNTIME

レイテンシーテストを実行する必要がある時間を秒単位で指定します。デフォルト値は 300 秒です。

注記

レイテンシーテストが完了する前に Ginkgo 2.0 テストスイートがタイムアウトしないようにするには、-ginkgo.timeout フラグを LATENCY_TEST_RUNTIME + 2 分より大きい値に設定します。LATENCY_TEST_DELAY 値も設定する場合は、-ginkgo.timeout を LATENCY_TEST_RUNTIME + LATENCY_TEST_DELAY + 2 分より大きい値に設定する必要があります。Ginkgo 2.0 テストスイートのデフォルトのタイムアウト値は 1 時間です。

HWLATDETECT_MAXIMUM_LATENCY

ワークロードとオペレーティングシステムの最大許容ハードウェアレイテンシーをマイクロ秒単位で指定します。HWLATDETECT_MAXIMUM_LATENCY または MAXIMUM_LATENCY の値を設定しない場合、ツールはデフォルトの予想しきい値 (20μs) とツール自体の実際の最大レイテンシーを比較します。次に、テストはそれに応じて失敗または成功します。

CYCLICTEST_MAXIMUM_LATENCY

cyclictest の実行中に、ウェイクアップする前にすべてのスレッドが期待する最大レイテンシーをマイクロ秒単位で指定します。CYCLICTEST_MAXIMUM_LATENCY または MAXIMUM_LATENCY の値を設定しない場合、ツールは予想される最大レイテンシーと実際の最大レイテンシーの比較をスキップします。

OSLAT_MAXIMUM_LATENCY

oslat テスト結果の最大許容レイテンシーをマイクロ秒単位で指定します。OSLAT_MAXIMUM_LATENCY または MAXIMUM_LATENCY の値を設定しない場合、ツールは予想される最大レイテンシーと実際の最大レイテンシーの比較をスキップします。

MAXIMUM_LATENCY

最大許容レイテンシーをマイクロ秒単位で指定する統合変数。利用可能なすべてのレイテンシーツールに適用できます。

注記

レイテンシーツールに固有の変数は、統合された変数よりも優先されます。たとえば、OSLAT_MAXIMUM_LATENCY が 30 マイクロ秒に設定され、MAXIMUM_LATENCY が 10 マイクロ秒に設定されている場合、oslat テストは 30 マイクロ秒の最大許容遅延で実行されます。

21.3. レイテンシーテストの実行
リンクのコピー

クラスターレイテンシーテストを実行して、Cloud-native Network Functions (CNF) ワークロードのノードチューニングを検証します。

注記

非 root または非特権ユーザーとして podman コマンドを実行すると、パスのマウントが permission denied エラーで失敗する場合があります。ローカルのオペレーティングシステムと SELinux 設定によっては、ホームディレクトリーから podman コマンドを実行すると、問題が発生することがあります。podman コマンドを機能させるには、home/<username> ディレクトリー以外のフォルダーからコマンドを実行し、ボリュームの作成に :Z を追加します。たとえば、-v $(pwd)/:/kubeconfig:Z です。これにより、podman は適切な SELinux の再ラベル付けを行うことができます。

この手順では 、hwlatdetect、cyclictest、oslat の 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.20 /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 秒) 実行する必要があります。

21.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.20 \
/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 環境変数を使用して、レイテンシーしきい値を設定できます。
    • 最大遅延時間: テスト中に測定された最大遅延時間値。

21.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 によって報告されたレイテンシーが必要なしきい値を満たしていることを確認してください。ハードウェアによって生じるレイテンシーを修正するには、システムベンダーのサポートに連絡しないといけない場合があります。

すべての遅延スパイクがハードウェアに関連しているわけではありません。ワークロードの要件を満たすようにホストファームウェアを調整してください。詳細は、システムチューニングのためのファームウェアパラメーターの設定を参照してください。

21.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.20 \
/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

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

21.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.20 \
/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
    この例では、測定されたレイテンシーが最大許容値を超えています。

21.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.20 \
/usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v
    • <report_folder_path>: レポートが生成されるフォルダーへのパスを指定します。

21.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.20 \
/usr/bin/test-run.sh --ginkgo.junit-report junit/<file_name>.xml --ginkgo.v

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

    file_name
    XML レポートファイルの名前。

21.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.20 \
/usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
    注記

    各テストのデフォルトの実行時間は 300 秒です。有効なレイテンシーテスト結果を得るには、LATENCY_TEST_RUNTIME 変数を更新してテストを少なくとも 12 時間実行してください。

    バケットのレイテンシー検証ステップを実行するには、最大レイテンシーを指定する必要があります。最大レイテンシー変数の詳細は、「レイテンシーの測定」セクションの表を参照してください。

    テストスイートの実行後に、未解決のリソースすべてがクリーンアップされます。

21.7. 切断されたクラスターでのレイテンシーテストの実行
リンクのコピー

CNF テストイメージは、外部レジストリーに到達できない切断されたクラスターでテストを実行できます。これには、次の 2 つの手順が必要です。

  1. cnf-tests イメージをカスタム切断レジストリーにミラーリングします。
  2. カスタムの切断されたレジストリーからイメージを使用するようにテストに指示します。

21.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.20 \
/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.20" \
-e LATENCY_TEST_RUNTIME=<time_in_seconds> \
<disconnected_registry>/cnf-tests-rhel9:v4.20 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"

21.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.20 /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。

21.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.20 \
/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"

21.7.4. 異なるテストイメージセットのミラーリング
リンクのコピー

オプションで、レイテンシーテスト用にミラーリングされるデフォルトのアップストリームイメージを変更できます。

手順

  1. mirror コマンドは、デフォルトでアップストリームイメージをミラーリングしようとします。これは、以下の形式のファイルをイメージに渡すことで上書きできます。 

    [
    {
        "registry": "public.registry.io:5000",
        "image": "imageforcnftests:4.20"
    }
]

  2. ファイルを mirror コマンドに渡します。たとえば、images.json としてローカルに保存します。以下のコマンドでは、ローカルパスはコンテナー内の /kubeconfig にマウントされ、これを mirror コマンドに渡すことができます。 

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
registry.redhat.io/openshift4/cnf-tests-rhel9:v4.20 /usr/bin/mirror \
--registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
|  oc image mirror -f -

21.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.20 \
oc get nodes

    このコマンドが機能しない場合は、DNS 間のスパン、MTU サイズ、またはファイアウォールアクセスに関連するエラーが発生している可能性があります。

高遅延環境におけるクラスターの安定性を向上させるには、ワーカーの遅延プロファイルを適用してください。

クラスター管理者としてプラットフォーム検証のためにレイテンシーテストを実施した場合、高レイテンシーの場合でも安定性を確保するためにクラスターの動作を調整する必要があることに気づくかもしれません。

クラスター管理者として変更する必要があるのは、ファイルに記録されている 1 つのパラメーターのみです。このパラメーターは、監視プロセスがステータスを読み取り、クラスターの状態を解釈する方法に影響を与える 4 つのパラメーターを制御します。1 つのパラメーターのみを変更し、サポートしやすく簡単な方法でクラスターをチューニングできます。

Kubelet プロセスは、クラスターの健全性を監視する上での出発点です。Kubelet は、OpenShift Container Platform クラスター内のすべてのノードのステータス値を設定します。Kubernetes コントローラーマネージャー (kube controller) は、デフォルトで 10 秒ごとにステータス値を読み取ります。ノードのステータス値を読み取ることができない場合、設定期間が経過すると、kube controller とそのノードとの接続が失われます。デフォルトの動作は次のとおりです。

  1. コントロールプレーン上のノードコントローラーは、ノードの状態を 不健康 に更新し、ノードの 準備完了 状態を 不明と マークします。
  2. この操作に応じて、スケジューラーはそのノードへの Pod のスケジューリングを停止します。
  3. ノードライフサイクルコントローラーが、NoExecute effect を持つ node.kubernetes.io/unreachable taint をノードに追加し、デフォルトでノード上のすべての Pod を 5 分後に退避するようにスケジュールします。

この動作は、ネットワークが遅延の問題を起こしやすい場合、特にネットワークエッジにノードがある場合に問題が発生する可能性があります。場合によっては、ネットワークの遅延が原因で、Kubernetes コントローラーマネージャーが正常なノードから更新を受信できないことがあります。Kubelet は、ノードが正常であっても、ノードから Pod を削除します。

この問題を回避するには、ワーカーレイテンシープロファイル を使用して、Kubelet と Kubernetes コントローラーマネージャーがアクションを実行する前にステータスの更新を待機する頻度を調整できます。これらの調整により、コントロールプレーンとワーカーノード間のネットワーク遅延が最適でない場合に、クラスターが適切に動作するようになります。

これらのワーカーレイテンシープロファイルには、3 つのパラメーターセットが含まれています。パラメーターは、遅延の増加に対するクラスターの反応を制御するように、慎重に調整された値で事前定義されています。試験により手作業で最良の値を見つける必要はありません。

クラスターのインストール時、またはクラスターネットワークのレイテンシーの増加に気付いたときはいつでも、ワーカーレイテンシープロファイルを設定できます。

22.1. ワーカーレイテンシープロファイルについて
リンクのコピー

以下の情報を確認して、ワーカーレイテンシープロファイルについて理解を深めてください。ワーカーレイテンシープロファイルを使用すると、手動で最適な値を決定する必要なく、レイテンシーの問題に対するクラスターの反応を制御できます。

ワーカーレイテンシープロファイルは、4 つの異なるカテゴリーからなる慎重に調整されたパラメーターです。これらの値を実装する 4 つのパラメーターは、node-status-update-frequency、node-monitor-grace-period、default-not-ready-toleration-seconds、および default-unreachable-toleration-seconds です。

重要

これらのパラメーターの手動設定はサポートされていません。パラメーター設定が正しくないと、クラスターの安定性に悪影響が及びます。

すべてのワーカーレイテンシープロファイルは、次のパラメーターを設定します。

node-status-update-frequency
kubelet がノードのステータスを API サーバーにポストする頻度を指定します。
node-monitor-grace-period
Kubernetes コントローラーマネージャーが、ノードを異常とマークし、node.kubernetes.io/not-ready または node.kubernetes.io/unreachable taint をノードに追加する前に、kubelet からの更新を待機する時間を秒単位で指定します。
default-not-ready-toleration-seconds
ノードを異常とマークした後、Kube API Server Operator がそのノードから Pod を削除するまでに待機する時間を秒単位で指定します。
default-unreachable-toleration-seconds
ノードを到達不能とマークした後、Kube API Server Operator がそのノードから Pod を削除するまでに待機する時間を秒単位で指定します。

次の Operator は、ワーカーレイテンシープロファイルの変更を監視し、それに応じて対応します。

  • Machine Config Operator (MCO) は、コンピュートノード上の ノードステータス更新頻度 パラメーターを更新します。
  • 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 Server の default-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

注記

レイテンシープロファイルは、カスタムのマシン設定プールをサポートしていません。デフォルトのワーカーマシン設定プールのみをサポートしていします。

22.2. クラスター作成時にワーカー遅延プロファイルを実装する
リンクのコピー

クラスター作成時にワーカーのレイテンシープロファイルを実装することで、最適な値を手動で決定する方法に頼ることなく、レイテンシーの問題に対するクラスターの反応を制御できます。

重要

インストールプログラムの設定を編集するには、まず openshift-install create manifests コマンドを使用して、デフォルトのノードマニフェストとその他のマニフェスト YAML ファイルを作成します。このファイル構造がなければ、workerLatencyProfile は追加できません。インストール先のプラットフォームにはさまざまな要件があります。該当するプラットフォームのドキュメントで、インストールセクションを参照してください。

手順

  1. インストール環境に適したフォルダー名を使用して、クラスター構築に必要なマニフェストを作成します。
  2. config.node を定義する YAML ファイルを作成します。ファイルは manifests ディレクトリーに置く必要があります。
  3. 初めてマニフェストで workerLatencyProfile を定義する際には、クラスターの作成時に Default、MediumUpdateAverageReaction、または 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"
# ...

22.3. ワーカーレイテンシープロファイルの使用と変更
リンクのコピー

node.config オブジェクトを編集することで、ネットワーク遅延に対応するために、ワーカーの遅延プロファイルをいつでも変更できます。この設定により、制御プレーンとコンピュートノード間のネットワーク遅延が変動した場合でも、クラスターが適切に動作することを保証できます。

ワーカーレイテンシープロファイルは、一度に 1 つずつ移行する必要があります。たとえば、Default プロファイルから LowUpdateSlowReaction ワーカーレイテンシープロファイルに直接移行することはできません。デフォルトの ワーカーレイテンシープロファイルから、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: すべての静的 Pod リビジョンでレイテンシープロファイルが更新されました
    プロファイルが適用され、アクティブであることを指定します。

    ミディアムプロファイルからデフォルト、またはデフォルトからミディアムに変更する場合、node.config オブジェクトを編集し、spec.workerLatencyProfile パラメーターを適切な値に設定します。

22.4. ワーカーレイテンシープロファイルの結果値を表示します
リンクのコピー

特定のコマンドを実行することで、ワーカーのレイテンシープロファイルの値を表示できます。その後、表示された値の情報の正確性を確認できます。

手順

  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 のタイミング変数のセットを検証します。

第23章 ワークロードパーティショニング
リンクのコピー

プラットフォームプロセスがアプリケーションの動作を妨害しないようにするには、ワークロードパーティショニングを設定してください。これにより、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 による拡張リソースの要件により、リクエストと制限の値は同じになります。ただし、ワークロードパーティショニングによって変更されたアノテーションは、必要な制限を正しく反映します。

注記

拡張リソースはオーバーコミットできないため、コンテナー仕様にリクエストと制限の両方が存在する場合は、リクエストと制限が等しくなければなりません。

23.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 パーティショニングが有効にならないことを保証します。

23.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
表23.1 シングルノード OpenShift クラスターの PerformanceProfile CR オプション
PerformanceProfile CR フィールド説明

metadata.name

name が、関連する GitOps ZTP カスタムリソース (CR) に設定されている次のフィールドと一致していることを確認してください。

  • TunedPerformancePatch.yaml の include=openshift-node-performance-${PerformanceProfile.metadata.name}
  • validatorCRs/informDuValidator.yaml の name: 50-performance-${PerformanceProfile.metadata.name}

spec.additionalKernelArgs

"efi=runtime" は、クラスターホストの UEFI セキュアブートを設定します。

spec.cpu.isolated

分離された CPU を設定します。すべてのハイパースレッディングペアが一致していることを確認します。

重要

予約済みおよび分離された CPU プールは重複してはならず、いずれも使用可能なすべてのコア全体にわたる必要があります。考慮されていない CPU コアは、システムで未定義の動作を引き起こします。

spec.cpu.reserved

予約済みの CPU を設定します。ワークロードの分割が有効になっている場合、システムプロセス、カーネルスレッド、およびシステムコンテナースレッドは、これらの CPU に制限されます。分離されていないすべての CPU を予約する必要があります。

spec.hugepages.pages

  • huge page の数 (count) を設定します。
  • huge page のサイズ (size) を設定します。
  • node を hugepages が割り当てられた NUMA ノード (node) に設定します。

spec.realTimeKernel

リアルタイムカーネルを使用するには、enabled を true に設定します。

spec.workloadHints

workloadHints を使用して、各種ワークロードの最上位フラグのセットを定義します。この例では、クラスターが低レイテンシーかつ高パフォーマンスになるように設定されています。

第24章 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 のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

24.1. Node Observability Operator のワークフロー
リンクのコピー

次のワークフローは、Node Observability Operator を使用してプロファイリングデータをクエリーする方法の概要を示しています。

  1. Node Observability Operator を OpenShift Container Platform クラスターにインストールします。
  2. NodeObservability カスタムリソースを作成して、選択したワーカーノードで CRI-O プロファイリングを有効にします。
  3. プロファイリングクエリーを実行して、プロファイリングデータを生成します。

24.2. Node Observability Operator のインストール
リンクのコピー

Node Observability Operator は、デフォルトでは OpenShift Container Platform にインストールされていません。OpenShift Container Platform CLI または Web コンソールを使用して、Node Observability Operator をインストールできます。

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

24.2.2. Web コンソールを使用した Node Observability Operator のインストール
リンクのコピー

Node Observability Operator は、OpenShift Container Platform コンソールからインストールできます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. 管理者のナビゲーションパネルで、Ecosystem → Software Catalog を選択します。
  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. 管理者のナビゲーションパネルで、Ecosystem → Installed Operators を展開します。
  2. Node Observability Operator が Operators リストにリストされていることを確認します。

CRI-O および Kubelet プロファイリングデータの収集に使用する、Node Observability カスタムリソースを作成します。

24.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
    spec:
      nodeSelector:
        kubernetes.io/hostname: <node_hostname>
      type: crio-kubelet

    ここでは、以下のようになります。

    cluster
    クラスターごとに NodeObservability CR が 1 つしかないため、名前を cluster として指定する必要があります。
    <node_hostname>
    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 のときに完了します。

24.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

24.4. Node Observability Operator スクリプト
リンクのコピー

スクリプトを作成すると、現在の Node Observability Operator および Node Observability Agent を使用して、事前設定された bash スクリプトを実行できます。

これらのスクリプトは、CPU 負荷、メモリーの逼迫、ワーカーノードの問題などの主要なメトリクスを監視します。sar レポートとカスタムパフォーマンスメトリクスも収集します。

24.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
    spec:
      nodeSelector:
        kubernetes.io/hostname: <node_hostname>
      type: scripting

    ここでは、以下のようになります。

    cluster
    クラスターごとに NodeObservability CR が 1 つしかないため、名前を cluster として指定する必要があります。
    <node_hostname>
    Node Observability エージェントをデプロイする必要があるノードを指定します。
    スクリプト作成
    エージェントをスクリプトモードでデプロイするには、タイプを 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 の実行は、reason が Ready、status が "True". の場合に完了します。

24.4.2. Node Observability Operator スクリプトの設定
リンクのコピー

ノードオブザーバビリティー 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

    Status が True、Type が Finished になると、スクリプトの作成は完了です。

  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 ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る