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


OpenShift Container Platform 4.17

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

Red Hat OpenShift Documentation Team

概要

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

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

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

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

注記

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

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

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

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

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

Telco RAN DU 仕様

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

計画、最適化、測定

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

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

Node Tuning Operator の使用

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

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

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

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

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

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

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

ワークロードの分割

Node Observability Operator の使用

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

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

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

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

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

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

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

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

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

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

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

注記

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

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

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

重要

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

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

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

    注記

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

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

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

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

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

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

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

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

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

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

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

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

  • 最新バージョンの Red Hat Best Practices for Kubernetes に準拠した Cloud-native Network Functions (CNF) を開発します。
  • 高性能ネットワークには SR-IOV を使用します。
  • exec プローブは控えめに使用し、他の適切なオプションが利用できない場合にのみ使用してください。

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

    注記

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

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

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

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

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

    注記

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

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

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

リソース利用

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

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

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

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

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

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

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

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

    重要

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

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

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

CPU の使用率

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

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

使用されているメモリー

16G 未満

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

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

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

注記

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

重要

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

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

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

3.2.3.1. ホストファームウェアのチューニング
このリリースの新機能
  • GitOps ZTP を使用してデプロイしたマネージドクラスターのホストファームウェア設定を行えるようになりました。
説明
初期クラスターデプロイメント中に最適なパフォーマンスが得られるようにホストファームウェア設定を調整します。マネージドクラスターホストのファームウェア設定は、SiteConfig CR と GitOps ZTP を使用してマネージドクラスターをデプロイするときに作成される BareMetalHost カスタムリソース (CR) としてハブクラスターで使用できます。
制限と要件
  • ハイパースレッディングを有効にする必要がある
エンジニアリングに関する考慮事項
  • パフォーマンスを最大限に高めるためにすべての設定を調整します。
  • 省電力用に調整されていない限り、すべての設定は最大のパフォーマンスが得られるものと予想されます。
  • 必要に応じて、省電力用にパフォーマンスを犠牲にしてホストファームウェアを調整できます。
  • Secure Boot を有効にします。セキュアブートを有効にすると、署名されたカーネルモジュールのみがカーネルによってロードされます。ツリー外のドライバーはサポートされていません。
3.2.3.2. Node Tuning Operator
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

パフォーマンスプロファイルを作成して、クラスターのパフォーマンスをチューニングします。

重要

RAN DU ユースケースでは、低レイテンシーのパフォーマンスを実現するためにクラスターをチューニングする必要があります。

制限と要件

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

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

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

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

cpuPartitioningMode: AllNodes 設定を使用してクラスターのデプロイメント中にワークロードのパーティショニングを有効にする場合、PerformanceProfile CR で予約された CPU セットには、オペレーティングシステム、割り込み、および OpenShift プラットフォーム Pod に十分な CPU が含まれている必要があります。

重要

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

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

3.2.3.3. PTP Operator
このリリースの新機能
  • Precision Time Protocol (PTP) 高速イベント REST API の新しいバージョン 2 が利用可能になりました。コンシューマーアプリケーションは、PTP イベントプロデューサーサイドカーのイベント REST API に直接サブスクライブできるようになりました。PTP 高速イベント REST API v2 は、O-RAN O-Cloud Notification API Specification for Event Consumers 3.0 に準拠しています。PtpOperatorConfig リソースの ptpEventConfig.apiVersion フィールドを設定することで、API バージョンを変更できます。
説明

クラスターノードでの PTP のサポートと設定に関する詳細は、「vDU アプリケーションのワークロードに推奨されるシングルノード OpenShift クラスター設定」を参照してください。DU ノードは次のモードで実行できます。

  • グランドマスタークロックまたは境界クロック (T-BC) に同期された通常のクロック (OC) として実行。
  • シングルまたはデュアルカード E810 NIC をサポートする、GPS から同期されるグランドマスタークロック (T-GM) として実行。
  • E810 NIC をサポートするデュアル境界クロック (NIC ごとに 1 つ) として実行。
  • 異なる NIC に複数のタイムソースがある場合に、高可用性 (HA) システムクロックを備えた T-BC として実行。
  • オプション: 無線ユニット (RU) の境界クロックとして実行。
制限と要件
  • デュアル NIC および HA の場合、境界クロックは 2 つに制限されます。
  • T-GM の場合、E810 カード設定は 2 枚に制限されます。
エンジニアリングに関する考慮事項
  • 通常クロック、境界クロック、高可用性システムクロックを備えた境界クロック、およびグランドマスタークロックの設定が提供されます。
  • PTP 高速イベント通知は ConfigMap CR を使用して PTP イベントサブスクリプションを保存します。
  • PTP イベント REST API v2 には、リソースパスに含まれるすべての下位階層リソースに対するグローバルサブスクリプションがありません。利用可能なさまざまなイベントタイプのコンシューマーアプリケーションを、個別にサブスクライブします。
3.2.3.4. SR-IOV Operator
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
SR-IOV Operator は、SR-IOV CNI およびデバイスプラグインをプロビジョニングおよび設定します。netdevice (カーネル VF) デバイスと vfio (DPDK) デバイスの両方がサポートされており、RAN 使用モデルに適用できます。
制限と要件
  • OpenShift Container Platform 対応デバイスを使用する
  • BIOS での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウン検出が必要な場合は、プロトコルレベルでこれを設定する必要があります。
  • セキュアブートまたはカーネルロックダウンを使用したファームウェア更新をサポートしていない NIC は、アプリケーションワークロードに必要な Virtual Function (VF) の数をサポートするために十分な VF で事前に設定されている必要があります。

    注記

    文書化されていない disablePlugins オプションを使用して、サポートされていない NIC の SR-IOV Operator プラグインを無効化することを推奨します。

エンジニアリングに関する考慮事項
  • vfio ドライバータイプの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーションで追加のセカンダリーネットワークを有効にするために使用されます。
  • SriovNetwork および SriovNetworkNodePolicy カスタムリソース (CR) の設定と数は、顧客によって異なることが予想されます。
  • IOMMU カーネルのコマンドライン設定は、インストール時に MachineConfig CR で適用されます。これにより、SriovOperator CR がノードを追加するときにノードの再起動が発生しなくなります。
  • 並列でノードをドレインするための SR-IOV サポートは、シングルノードの OpenShift クラスターには適用されません。
  • デプロイメントから SriovOperatorConfig CR を除外すると、CR は自動的に作成されません。
  • ワークロードを特定のノードにピン留めまたは制限するシナリオでは、SR-IOV 並列ノードドレイン機能によって Pod の再スケジュールは行われません。このようなシナリオでは、SR-IOV Operator は並列ノードドレイン機能を無効にします。
3.2.3.5. ロギング
このリリースの新機能
  • Cluster Logging Operator 6.0 はこのリリースの新機能です。既存の実装を更新して、新しいバージョンの API に適応させます。
説明
ログ記録を使用して、リモート分析のために遠端のエッジノードからログを収集します。推奨されるログコレクターは Vector です。
エンジニアリングに関する考慮事項
  • たとえば、インフラストラクチャーを超えたログや、アプリケーションワークロードからの監査ログを処理するには、追加のログ記録レートに基づいて追加の CPU とネットワーク帯域幅が必要になります。
  • OpenShift Container Platform 4.14 以降では、Vector が参照ログコレクターになります。

    注記

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

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

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

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

3.2.3.9. LVM Storage
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
注記

論理ボリュームマネージャー (LVM) ストレージはオプションのコンポーネントです。

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

説明
LVM Storage は、ブロックおよびファイルストレージの動的なプロビジョニングを提供します。LVM Storage は、アプリケーションが PVC リソースとして使用できるローカルデバイスから論理ボリュームを作成します。ボリューム拡張やスナップショットも可能です。
制限と要件
  • シングルノードの OpenShift クラスターでは、永続ストレージは LVM ストレージまたはローカルストレージのいずれかによって提供される必要があり、両方によって提供される必要はありません。
  • ボリュームスナップショットはリファレンス設定から除外されます。
エンジニアリングに関する考慮事項
  • LVM Storage は、RAN DU ユースケースのローカルストレージ実装として使用できます。LVM Storage をストレージソリューションとして使用すると、Local Storage Operator が置き換えられ、必要な CPU がプラットフォームのオーバーヘッドとして管理パーティションに割り当てられます。参照設定には、これらのストレージソリューションのいずれか 1 つを含める必要がありますが、両方を含めることはできません。
  • ストレージ要件を満たす十分なディスクまたはパーティションが利用可能であることを確認します。
3.2.3.10. ワークロードの分割
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
ワークロードパーティショニングは、DU プロファイルの一部である OpenShift プラットフォームと Day 2 Operator Pod を予約済み CPU セットに固定し、予約済み CPU をノードアカウンティングから削除します。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。
制限と要件
  • Pod を管理パーティションに適用できるようにするには、NamespacePod CR にアノテーションを付ける必要がある
  • CPU 制限のある Pod をパーティションに割り当てることはできません。これは、ミューテーションによって Pod の QoS が変わる可能性があるためです。
  • 管理パーティションに割り当てることができる CPU の最小数の詳細は、ノードチューニング Operator を参照してください。
エンジニアリングに関する考慮事項
  • ワークロードパーティショニングでは、すべての管理 Pod を予約済みコアにピン固定します。オペレーティングシステム、管理 Pod、およびワークロードの開始、ノードの再起動、またはその他のシステムイベントの発生時に発生する CPU 使用率の予想される急増を考慮して、予約セットに十分な数のコアを割り当てる必要があります。
3.2.3.11. クラスターのチューニング
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
インストール前に有効または無効にできるオプションのコンポーネントの完全なリストは、「クラスター機能」を参照してください。
制限と要件
  • インストーラーによるプロビジョニングのインストール方法では、クラスター機能は使用できません。
  • すべてのプラットフォームチューニング設定を適用する必要があります。次の表に、必要なプラットフォームチューニング設定を示します。

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

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

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

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

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

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

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

      注記

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

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

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

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

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

    Console Operator を無効にする

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

エンジニアリングに関する考慮事項
  • OpenShift Container Platform 4.16 以降では、PerformanceProfile CR が適用されても、クラスターは自動的に cgroups v1 に戻りません。クラスター上で実行されているワークロードに cgroups v1 が必要な場合は、cgroups v1 を使用するようにクラスターを設定する必要があります。

    注記

    cgroups v1 を設定する必要がある場合は、初期クラスターデプロイメントの一部として設定を行います。

3.2.3.12. マシン設定
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
制限と要件
  • CRI-O ワイプ無効化 MachineConfig は、定義されたメンテナンスウィンドウ内のスケジュールされたメンテナンス時以外は、ディスク上のイメージが静的であると想定します。イメージが静的であることを保証するには、Pod の imagePullPolicy フィールドを Always に設定しないでください。

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

    コンテナーランタイム

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

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

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

    SCTP

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

    kdump

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

    注記

    kdump を有効にするリファレンス CR では、リファレンス設定に含まれるドライバーとカーネルモジュールのセットに基づいて、メモリー予約が増加します。

    CRI-O ワイプ無効化

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

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

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

    RCU 通常の systemd サービス

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

    ワンショット時間同期

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

3.2.3.13. 通信事業者向け RAN DU デプロイメントコンポーネント

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

3.2.3.13.1. Red Hat Advanced Cluster Management
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

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

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

制限と要件
  • ArgoCD アプリケーションごとに 300 個の SiteConfig CR。複数のアプリケーションを使用することで、単一のハブクラスターでサポートされるクラスターの最大数を実現できます。
  • 単一のハブクラスターは、各クラスターに 5 つの Policy CR がバインドされた、最大 3500 個のデプロイされたシングルノード OpenShift クラスターをサポートします。
エンジニアリングに関する考慮事項
  • RHACM ポリシーハブ側テンプレートを使用して、クラスター設定をより適切にスケーリングします。グループおよびクラスターごとの値がテンプレートに置き換えられる単一のグループポリシーまたは少数の一般的なグループポリシーを使用することで、ポリシーの数を大幅に削減できます。
  • クラスター固有の設定: マネージドクラスターには通常、個々のクラスターに固有の設定値がいくつかあります。これらの設定は、クラスター名に基づいて ConfigMap CR から取得された値を使用して、RHACM ポリシーハブ側テンプレートを使用して管理する必要があります。
  • マネージドクラスターの CPU リソースを節約するには、クラスターの GitOps ZTP インストール後に、静的設定を適用するポリシーをマネージドクラスターからアンバインドする必要があります。
3.2.3.13.2. Topology Aware Lifecycle Manager
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
Topology Aware Lifecycle Manager (TALM) は、ハブクラスター上でのみ実行され、変更 (クラスターおよび Operator のアップグレード、設定などを含む) がネットワークにロールアウトされる方法を管理するための Operator です。
制限と要件
  • TALM は 400 のバッチでの同時クラスターデプロイメントをサポートします。
  • 事前キャッシュおよびバックアップ機能は、シングルノードの OpenShift クラスターのみを対象としています。
エンジニアリングに関する考慮事項
  • ran.openshift.io/ztp-deploy-wave アノテーションを持つポリシーのみが、クラスターの初期インストール時に TALM によって自動的に適用されます。
  • さらに ClusterGroupUpgrade CR を作成して、TALM が修復するポリシーを制御できます。
3.2.3.13.3. GitOps および GitOps ZTP プラグイン
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

注記

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

複数のバージョンごとのポリシーを同時に維持するには、Git を使用してソース CR とポリシー CR (PolicyGenTemplate または PolicyGenerator) のバージョンを管理します。

参照 CR とカスタム CR を別のディレクトリーに保存します。これを行うと、カスタム CR に触れることなく、ディレクトリーのすべてのコンテンツを簡単に置き換えるだけで、参照 CR にパッチを適用して更新できます。

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

    注記

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

  • SiteConfig CR の extraManifestPath フィールドは、OpenShift Container Platform 4.15 以降では非推奨です。代わりに新しい extraManifests.searchPaths フィールドを使用してください。
エンジニアリングに関する考慮事項
  • マルチノードクラスターのアップグレードの場合、paused フィールドを true に設定することで、メンテナンスウィンドウ中に MachineConfigPool (MCP) CR を一時停止できます。MCP CR で maxUnavailable 設定を設定することで、同時に更新される MCP ごとのノード数を増やすことができます。MaxUnavailable フィールドは、MachineConfig の更新中に同時に使用できなくなるプール内のノードのパーセンテージを定義します。maxUnavailable を最大許容値に設定します。これにより、アップグレード中にクラスター内で再起動する回数が減り、アップグレード時間が短縮されます。最終的に MCP CR の一時停止を解除すると、変更されたすべての設定が 1 回の再起動で適用されます。
  • クラスターのインストール中に、paused フィールドを true に設定し、maxUnavailable を 100% に設定することで、カスタム MCP CR を一時停止し、インストール時間を短縮できます。
  • コンテンツを更新するときに混乱や意図しないファイルの上書きを避けるため、/source-crs フォルダー内のユーザー指定の CR と Git 内の追加マニフェストには、一意で区別できる名前を使用します。
  • SiteConfig CR では、複数の追加マニフェストパスが許可されます。複数のディレクトリーパスで同じ名前のファイルが見つかった場合は、最後に見つかったファイルが優先されます。これにより、バージョン固有の Day 0 マニフェスト (追加マニフェスト) の完全なセットを Git に配置し、SiteConfig CR から参照できるようになります。この機能を使用すると、複数の OpenShift Container Platform バージョンをマネージドクラスターに同時にデプロイできます。
3.2.3.13.4. Agent-based Installer
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

注記

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

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

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

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

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

注記

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

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

クラスターロギング

ClusterLogForwarder.yaml

いいえ

いいえ

クラスターロギング

ClusterLogNS.yaml

いいえ

いいえ

クラスターロギング

ClusterLogOperGroup.yaml

いいえ

いいえ

クラスターロギング

ClusterLogServiceAccount.yaml

いいえ

はい

クラスターロギング

ClusterLogServiceAccountAuditBinding.yaml

いいえ

はい

クラスターロギング

ClusterLogServiceAccountInfrastructureBinding.yaml

いいえ

はい

クラスターロギング

ClusterLogSubscription.yaml

いいえ

いいえ

LifeCycle Agent Operator

ImageBasedUpgrade.yaml

はい

いいえ

LifeCycle Agent Operator

LcaSubscription.yaml

はい

いいえ

LifeCycle Agent Operator

LcaSubscriptionNS.yaml

はい

いいえ

LifeCycle Agent Operator

LcaSubscriptionOperGroup.yaml

はい

いいえ

Local Storage Operator

StorageClass.yaml

はい

いいえ

Local Storage Operator

StorageLV.yaml

はい

いいえ

Local Storage Operator

StorageNS.yaml

はい

いいえ

Local Storage Operator

StorageOperGroup.yaml

はい

いいえ

Local Storage Operator

StorageSubscription.yaml

はい

いいえ

LVM Operator

LVMOperatorStatus.yaml

はい

いいえ

LVM Operator

StorageLVMCluster.yaml

はい

いいえ

LVM Operator

StorageLVMSubscription.yaml

はい

いいえ

LVM Operator

StorageLVMSubscriptionNS.yaml

はい

いいえ

LVM Operator

StorageLVMSubscriptionOperGroup.yaml

はい

いいえ

Node Tuning Operator

PerformanceProfile.yaml

いいえ

いいえ

Node Tuning Operator

TunedPerformancePatch.yaml

いいえ

いいえ

PTP 高速イベント通知

PtpConfigBoundaryForEvent.yaml

はい

いいえ

PTP 高速イベント通知

PtpConfigForHAForEvent.yaml

はい

いいえ

PTP 高速イベント通知

PtpConfigMasterForEvent.yaml

はい

いいえ

PTP 高速イベント通知

PtpConfigSlaveForEvent.yaml

はい

いいえ

PTP Operator - 高可用性

PtpConfigBoundary.yaml

いいえ

いいえ

PTP Operator - 高可用性

PtpConfigForHA.yaml

いいえ

いいえ

PTP Operator

PtpConfigDualCardGmWpc.yaml

いいえ

いいえ

PTP Operator

PtpConfigGmWpc.yaml

いいえ

いいえ

PTP Operator

PtpConfigSlave.yaml

いいえ

いいえ

PTP Operator

PtpOperatorConfig.yaml

いいえ

いいえ

PTP Operator

PtpOperatorConfigForEvent.yaml

いいえ

いいえ

PTP Operator

PtpSubscription.yaml

いいえ

いいえ

PTP Operator

PtpSubscriptionNS.yaml

いいえ

いいえ

PTP Operator

PtpSubscriptionOperGroup.yaml

いいえ

いいえ

SR-IOV FEC Operator

AcceleratorsNS.yaml

はい

いいえ

SR-IOV FEC Operator

AcceleratorsOperGroup.yaml

はい

いいえ

SR-IOV FEC Operator

AcceleratorsSubscription.yaml

はい

いいえ

SR-IOV FEC Operator

SriovFecClusterConfig.yaml

はい

いいえ

SR-IOV Operator

SriovNetwork.yaml

いいえ

いいえ

SR-IOV Operator

SriovNetworkNodePolicy.yaml

いいえ

いいえ

SR-IOV Operator

SriovOperatorConfig.yaml

いいえ

いいえ

SR-IOV Operator

SriovOperatorConfigForSNO.yaml

いいえ

いいえ

SR-IOV Operator

SriovSubscription.yaml

いいえ

いいえ

SR-IOV Operator

SriovSubscriptionNS.yaml

いいえ

いいえ

SR-IOV Operator

SriovSubscriptionOperGroup.yaml

いいえ

いいえ

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

コンポーザブル OpenShift

example-sno.yaml

いいえ

いいえ

コンソールの無効化

ConsoleOperatorDisable.yaml

はい

いいえ

非接続レジストリー

09-openshift-marketplace-ns.yaml

いいえ

いいえ

非接続レジストリー

DefaultCatsrc.yaml

いいえ

いいえ

非接続レジストリー

DisableOLMPprof.yaml

いいえ

いいえ

非接続レジストリー

DisconnectedICSP.yaml

いいえ

いいえ

非接続レジストリー

OperatorHub.yaml

OperatorHub は、シングルノード OpenShift では必須であり、マルチノードクラスターではオプションです。

いいえ

モニタリング設定

ReduceMonitoringFootprint.yaml

いいえ

いいえ

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

DisableSnoNetworkDiag.yaml

いいえ

いいえ

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

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

enable-crun-master.yaml

いいえ

いいえ

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

enable-crun-worker.yaml

いいえ

いいえ

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

99-crio-disable-wipe-master.yaml

いいえ

いいえ

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

99-crio-disable-wipe-worker.yaml

いいえ

いいえ

Kdump を有効にする

06-kdump-master.yaml

いいえ

いいえ

Kdump を有効にする

06-kdump-worker.yaml

いいえ

いいえ

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

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

いいえ

いいえ

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

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

いいえ

いいえ

ワンショット時間同期

99-sync-time-once-master.yaml

いいえ

いいえ

ワンショット時間同期

99-sync-time-once-worker.yaml

いいえ

いいえ

SCTP

03-sctp-machine-config-master.yaml

はい

いいえ

SCTP

03-sctp-machine-config-worker.yaml

はい

いいえ

RCU を通常に設定する

08-set-rcu-normal-master.yaml

いいえ

いいえ

RCU を通常に設定する

08-set-rcu-normal-worker.yaml

いいえ

いいえ

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

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

いいえ

いいえ

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

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

いいえ

いいえ

3.2.4.4. YAML リファレンス

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

3.2.4.4.1. Day 2 Operator 参照 YAML

ClusterLogForwarder.yaml

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
  # outputs: $outputs
  # pipelines: $pipelines
  serviceAccount:
    name: logcollector
#apiVersion: "observability.openshift.io/v1"
#kind: ClusterLogForwarder
#metadata:
#  name: instance
#  namespace: openshift-logging
# spec:
#   outputs:
#   - type: "kafka"
#     name: kafka-open
#     # below url is an example
#     kafka:
#       url: tcp://10.46.55.190:9092/test
#   filters:
#   - name: test-labels
#     type: openshiftLabels
#     openshiftLabels:
#       label1: test1
#       label2: test2
#       label3: test3
#       label4: test4
#   pipelines:
#   - name: all-to-default
#     inputRefs:
#     - audit
#     - infrastructure
#     filterRefs:
#     - test-labels
#     outputRefs:
#     - kafka-open
#   serviceAccount:
#     name: logcollector
Copy to Clipboard Toggle word wrap

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  targetNamespaces:
    - openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccount.yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: logcollector
  namespace: openshift-logging
  annotations: {}
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountAuditBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-audit-logs-binding
  annotations: {}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-audit-logs
subjects:
  - kind: ServiceAccount
    name: logcollector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountInfrastructureBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-infrastructure-logs-binding
  annotations: {}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-infrastructure-logs
subjects:
  - kind: ServiceAccount
    name: logcollector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogSubscription.yaml

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

ImageBasedUpgrade.yaml

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

LcaSubscription.yaml

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

LcaSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-lifecycle-agent
  annotations:
    workload.openshift.io/allowed: management
  labels:
    kubernetes.io/metadata.name: openshift-lifecycle-agent
Copy to Clipboard Toggle word wrap

LcaSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: lifecycle-agent
  namespace: openshift-lifecycle-agent
  annotations: {}
spec:
  targetNamespaces:
    - openshift-lifecycle-agent
Copy to Clipboard Toggle word wrap

StorageClass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations: {}
  name: example-storage-class
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
Copy to Clipboard Toggle word wrap

StorageLV.yaml

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

StorageNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-local-storage
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

StorageOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-local-storage
  namespace: openshift-local-storage
  annotations: {}
spec:
  targetNamespaces:
    - openshift-local-storage
Copy to Clipboard Toggle word wrap

StorageSubscription.yaml

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

LVMOperatorStatus.yaml

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

StorageLVMCluster.yaml

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

StorageLVMSubscription.yaml

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

StorageLVMSubscriptionNS.yaml

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

StorageLVMSubscriptionOperGroup.yaml

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

PerformanceProfile.yaml

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ''
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false
Copy to Clipboard Toggle word wrap

TunedPerformancePatch.yaml

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

PtpConfigBoundaryForEvent.yaml

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

PtpConfigForHAForEvent.yaml

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

PtpConfigMasterForEvent.yaml

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

PtpConfigSlaveForEvent.yaml

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

PtpConfigBoundary.yaml

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

PtpConfigForHA.yaml

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

PtpConfigDualCardGmWpc.yaml

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

PtpConfigGmWpc.yaml

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

PtpConfigSlave.yaml

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

PtpOperatorConfig.yaml

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

PtpOperatorConfigForEvent.yaml

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

PtpSubscription.yaml

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

PtpSubscriptionNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"
Copy to Clipboard Toggle word wrap

PtpSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
  annotations: {}
spec:
  targetNamespaces:
    - openshift-ptp
Copy to Clipboard Toggle word wrap

AcceleratorsNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: vran-acceleration-operators
  annotations: {}
Copy to Clipboard Toggle word wrap

AcceleratorsOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: vran-operators
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  targetNamespaces:
    - vran-acceleration-operators
Copy to Clipboard Toggle word wrap

AcceleratorsSubscription.yaml

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

SriovFecClusterConfig.yaml

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

SriovNetwork.yaml

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

SriovNetworkNodePolicy.yaml

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

SriovOperatorConfig.yaml

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

SriovOperatorConfigForSNO.yaml

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

SriovSubscription.yaml

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

SriovSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

SriovSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  targetNamespaces:
    - openshift-sriov-network-operator
Copy to Clipboard Toggle word wrap

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

example-sno.yaml

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

ConsoleOperatorDisable.yaml

apiVersion: operator.openshift.io/v1
kind: Console
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "false"
    include.release.openshift.io/self-managed-high-availability: "false"
    include.release.openshift.io/single-node-developer: "false"
    release.openshift.io/create-only: "true"
  name: cluster
spec:
  logLevel: Normal
  managementState: Removed
  operatorLogLevel: Normal
Copy to Clipboard Toggle word wrap

09-openshift-marketplace-ns.yaml

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

DefaultCatsrc.yaml

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

DisableOLMPprof.yaml

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

DisconnectedICSP.yaml

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

OperatorHub.yaml

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
  annotations: {}
spec:
  disableAllDefaultSources: true
Copy to Clipboard Toggle word wrap

ReduceMonitoringFootprint.yaml

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

DisableSnoNetworkDiag.yaml

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  annotations: {}
spec:
  disableNetworkDiagnostics: true
Copy to Clipboard Toggle word wrap

3.2.4.4.3. マシン設定参照 YAML

enable-crun-master.yaml

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

enable-crun-worker.yaml

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

99-crio-disable-wipe-master.yaml

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

99-crio-disable-wipe-worker.yaml

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

06-kdump-master.yaml

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

06-kdump-worker.yaml

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

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

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

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

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

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

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

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

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

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

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

99-sync-time-once-master.yaml

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

99-sync-time-once-worker.yaml

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

03-sctp-machine-config-master.yaml

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

03-sctp-machine-config-worker.yaml

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

08-set-rcu-normal-master.yaml

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

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

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

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

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

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

            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: set-rcu-normal.service
Copy to Clipboard Toggle word wrap

08-set-rcu-normal-worker.yaml

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

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

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

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

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

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

            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: set-rcu-normal.service
Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

4.17

Cluster Logging Operator

6.0

Local Storage Operator

4.17

OpenShift API for Data Protection (OADP)

1.4.1

PTP Operator

4.17

SRIOV Operator

4.17

SRIOV-FEC Operator

2.9

Lifecycle Agent

4.17

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

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

4.17

Red Hat Advanced Cluster Management (RHACM)

2.11

GitOps ZTP プラグイン

4.17

Red Hat OpenShift GitOps

1.13

Topology Aware Lifecycle Manager (TALM)

4.17

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

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

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

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

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

通信事業者向けコアクラスターサービスベースのアーキテクチャーは、次のコンポーネントで構成されます。

  • Network data analytics functions (NWDAF)
  • Network slice selection functions (NSFF)
  • Authentication server functions (AUSF)
  • Unified data managements (UDM)
  • Network repository functions (NRF)
  • Network exposure functions (NEF)
  • Application functions (AF)
  • Access and mobility functions (AMF)
  • Session management functions (SMF)
  • Policy control functions (PCF)
  • Charging functions (CHF)
  • User equipment (UE)
  • Radio access network (RAN)
  • User plane functions (UPF)
  • Data plane networking (DN)

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

Telco コアクラスターは、標準の 3 つのコントロールプレーンクラスターとして設定され、ワーカーノードは標準の非リアルタイム (RT) カーネルで設定します。

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

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

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

Use model architecture

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

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

クラスター

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

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

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

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

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

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

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

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

次のエンジニアリング上の考慮事項は、通信事業者向けコア共通使用モデルに関連しています。

ワーカーノード
  • ワーカーノードは、Intel 第 3 世代 Xeon (IceLake) プロセッサー以降で実行する必要があります。

    注記

    または、ワーカーノードに Skylake 以前のプロセッサーが搭載されている場合は、Spectre などのシリコンセキュリティー脆弱性に対する軽減策を無効にする必要があります。これを怠ると、トランザクションのパフォーマンスが 40% 低下する可能性があります。

  • ワーカーノードの IRQ バランスを有効にします。PerformanceProfile カスタムリソース (CR) の globallyDisableIrqLoadBalancing フィールドを false に設定します。Pod が確実に分離されるように、QoS クラス Guaranteed で Pod にアノテーションを付けます。詳細は、「CPU のパーティショニングとパフォーマンスチューニング」を参照してください。
クラスター内のすべてのノード
  • すべてのノードに対してハイパースレッディングを有効にします。
  • CPU アーキテクチャーが x86_64 のみであることを確認します。
  • ノードが標準 (非 RT) カーネルを実行していることを確認します。
  • ノードがワークロードのパーティション分割用に設定されていないことを確認します。
電源管理とパフォーマンス
  • 電源管理と最大パフォーマンスとの間のバランスは、クラスター内の MachineConfigPool リソースによって異なります。
Cluster scaling
  • クラスターノードの数を少なくとも 120 ノードにスケーリングします。
CPU パーティショニング
  • CPU パーティショニングは、クラスター内の MachineConfigPool CR ごとに 1 つずつ、PerformanceProfile CR を使用して設定されます。詳細は、「CPU のパーティショニングとパフォーマンスチューニング」を参照してください。
3.3.2.1.2. アプリケーションワークロード

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

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

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

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

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

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

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

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

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

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

3.3.3.1. CPU のパーティショニングとパフォーマンスチューニング
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
CPU パーティショニングにより、機密性の高いワークロードを一般的な目的、補助プロセス、割り込み、およびドライバー作業キューから分離して、パフォーマンスとレイテンシーを向上させることができます。
制限と要件
  • オペレーティングシステムでは、カーネルネットワークを含むすべてのサポートタスクを実行するために、一定量の CPU が必要です。

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

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

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

通信事業者向けコアのクラウドネイティブ機能 (CNF) には通常、サービスメッシュの実装が必要です。

注記

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

3.3.3.3. ネットワーク
このリリースの新機能
  • 通信事業者向けコア検証は、ボンディング、MACVLAN、IPVLAN、および SR-IOV ネットワークシナリオによって拡張されました。
説明
  • クラスターはデュアルスタック IP 設定 (IPv4 と IPv6) で設定されます。
  • 検証された物理ネットワーク設定は、2 つのデュアルポート NIC で構成されます。1 つの NIC はプライマリー CNI (OVN-Kubernetes) と IPVLAN および MACVLAN トラフィック間で共有され、2 番目の NIC は SR-IOV VF ベースの Pod トラフィック専用になります。
  • 2 つの NIC ポートが接続された active-active LACP IEEE 802.3ad 設定で、Linux ボンディングインターフェイス (bond0) が作成されます。

    注記

    トップオブラックネットワーク機器は、マルチシャーシリンクアグリゲーション (mLAG) テクノロジーをサポートし、そのように設定されている必要があります。

  • VLAN インターフェイスは、プライマリー CNI を含め、bond0 の上に作成されます。
  • ボンディングおよび VLAN インターフェイスは、ネットワーク設定中のインストール時に作成されます。プライマリー CNI が使用する VLAN (VLAN0) とは別に、Kubernetes NMState Operator を使用して Day 2 に他の VLAN を作成できます。
  • MACVLAN および IPVLAN インターフェイスは、対応する CNI を使用して作成されます。同じ基本インターフェイスを共有することはありません。
  • SR-IOV VF は SR-IOV Network Operator によって管理されます。次の図は、SR-IOV NIC 共有の概要を示しています。

    図3.4 SR-IOV NIC 共有

3.3.3.4. Cluster Network Operator
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
Cluster Network Operator (CNO) は、OpenShift Container Platform クラスターのインストール中に、デフォルトの OVN-Kubernetes ネットワークプラグインを含むクラスターネットワークコンポーネントをデプロイおよび管理します。これにより、プライマリーインターフェイスの MTU 設定、Pod の Egress にノードルーティングテーブルを使用するための OVN ゲートウェイモード、および MACVLAN などの追加のセカンダリーネットワークを設定できます。
制限と要件
  • IPv6 サポートには OVN-Kubernetes が必要です。
  • 大規模 MTU クラスターをサポートするには、接続されたネットワーク機器を同じ値またはそれ以上の値に設定する必要があります。
  • MACVLAN と IPVLAN は、同じ基礎カーネルメカニズム、具体的には rx_handler に依存しているため、同じメインインターフェイス上に配置できません。このハンドラーを使用すると、ホストが受信パケットを処理する前にサードパーティーモジュールが受信パケットを処理できるようになります。このようなハンドラーは、ネットワークインターフェイスごとに 1 つだけ登録できます。MACVLAN と IPVLAN は両方とも、機能するために独自の rx_handler を登録する必要があるため、競合が発生し、同じインターフェイス上で共存することはできません。詳細は、ipvlan/ipvlan_main.c#L82 および net/macvlan.c#L1260 を参照してください。
  • 代替の NIC 設定としては、共有 NIC を複数の NIC に分割したり、単一のデュアルポート NIC を使用したりすることが挙げられます。

    重要

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

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

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

注記

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

制限と要件
  • ステートフルロードバランシングは MetalLB ではサポートされていません。これがワークロード CNF の要件である場合は、代替ロードバランサー実装を使用する必要があります。
  • ネットワークインフラストラクチャーでは、外部 IP アドレスがクライアントからクラスターのホストネットワークにルーティング可能であることを保証する必要があります。
エンジニアリングに関する考慮事項
  • MetalLB は、コアユースケースモデルの BGP モードでのみ使用されます。
  • コア使用モデルの場合、MetalLB は、ローカルゲートウェイモードで使用される OVN-Kubernetes ネットワークプロバイダーでのみサポートされます。「Cluster Network Operator」セクションの routingViaHost を参照してください。
  • MetalLB での BGP 設定は、ネットワークとピアの要件によって異なります。
  • アドレスプールは必要に応じて設定でき、アドレス、集約長、自動割り当て、その他の関連パラメーターを変更できます。
  • MetalLB はルートのアナウンスにのみ BGP を使用します。このモードでは、transmitInterval および minimumTtl パラメーターのみが関連します。BFD プロファイル内の他のパラメーターは、デフォルト設定に近いままにしておく必要があります。値が短いとエラーが発生し、パフォーマンスに影響する可能性があります。
3.3.3.6. SR-IOV
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
SR-IOV を使用すると、物理ネットワークインターフェイス (PF) を複数の Virtual Function (VF) に分割できます。その後、VF を複数の Pod に割り当てることで、Pod を分離したまま、より高いスループットパフォーマンスを実現できます。SR-IOV Network Operator は、SR-IOV CNI、ネットワークデバイスプラグイン、および SR-IOV スタックのその他のコンポーネントをプロビジョニングおよび管理します。
制限と要件
  • サポートされているネットワークインターフェイスコントローラーは、「サポートされるデバイス」にリスト表示されています。
  • SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウンの検出が必要な場合は、プロトコルレベルで実行する必要があります。
  • MultiNetworkPolicy CR は、netdevice ネットワークにのみ適用できます。これは、実装では vfio インターフェイスを管理できない iptables ツールが使用されるためです。
エンジニアリングに関する考慮事項
  • vfio モードの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーション用に追加のセカンダリーネットワークを有効にするために使用されます。
  • デプロイメントから SriovOperatorConfig CR を除外すると、CR は自動的に作成されません。
  • セキュアブートまたはカーネルロックダウン下でのファームウェア更新をサポートしない NIC は、アプリケーションワークロードに必要な VF の数をサポートするために十分な VF を有効にして事前設定する必要があります。

    注記

    これらの NIC の SR-IOV Network Operator プラグインは、文書化されていない disablePlugins オプションを使用して無効化することを推奨します。

3.3.3.7. NMState Operator
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
NMState Operator は、クラスターノード間でネットワーク設定を実行するための Kubernetes API を提供します。
制限と要件
該当なし
エンジニアリングに関する考慮事項
  • 初期ネットワーク設定は、インストール CR の NMStateConfig コンテンツを使用して適用されます。NMState Operator は、ネットワーク更新に必要な場合にのみ使用されます。
  • SR-IOV Virtual Function がホストネットワークに使用される場合は、NodeNetworkConfigurationPolicy を使用する NMState Operator を使用して、VLAN や MTU などの VF インターフェイスが設定されます。
3.3.3.8. ロギング
このリリースの新機能
  • Cluster Logging Operator 6.0 はこのリリースの新機能です。既存の実装を更新して、新しいバージョンの API に適応させます。
説明
Cluster Logging Operator を使用すると、リモートアーカイブと分析のために、ノードからログを収集して送信できます。参照設定では、Kafka を使用して監査ログとインフラストラクチャーログをリモートアーカイブに送信します。
制限と要件
該当なし
エンジニアリングに関する考慮事項
  • クラスターの CPU 使用率の影響は、生成されるログの数またはサイズと、設定されたログフィルタリングの量によって決まります。
  • 参照設定には、アプリケーションログの送信は含まれません。設定にアプリケーションログを含めるには、アプリケーションのログ記録レートを評価し、予約セットに十分な追加の CPU リソースを割り当てる必要があります。
3.3.3.9. 電源管理
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
Performance Profile を使用して、高電力モード、低電力モード、または混合モードでクラスターを設定します。電源モードの選択は、クラスター上で実行しているワークロードの特性、特にレイテンシーに対する敏感さによって異なります。
制限と要件
  • 電源設定は、C ステートや P ステートの有効化など、適切な BIOS 設定に依存します。設定はハードウェアベンダーによって異なります。
エンジニアリングに関する考慮事項
  • レイテンシー: レイテンシーの影響を受けやすいワークロードが要件を満たすようにするには、高電力設定または Pod ごとの電源管理設定のいずれかが必要になります。Pod ごとの電源管理は、専用の固定 CPU を備えた Guaranteed QoS Pod でのみ使用できます。
3.3.3.10. ストレージ

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

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

    注記

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

3.3.3.11. 通信事業者向けコアデプロイメントコンポーネント

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

3.3.3.11.1. Red Hat Advanced Cluster Management
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

Topology Aware Lifecycle Manager (TALM) によって管理される RHACM ポリシーコントローラーを使用してポリシーを適用します。

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

制限と要件
エンジニアリングに関する考慮事項
  • RHACM ポリシーハブ側テンプレートを使用して、クラスター設定をより適切にスケーリングします。グループおよびクラスターごとの値がテンプレートに置き換えられる単一のグループポリシーまたは少数の一般的なグループポリシーを使用することで、ポリシーの数を大幅に削減できます。
  • クラスター固有の設定: マネージドクラスターには通常、個々のクラスターに固有の設定値がいくつかあります。これらの設定は、クラスター名に基づいて ConfigMap CR から取得された値を使用して、RHACM ポリシーハブ側テンプレートを使用して管理する必要があります。
3.3.3.11.2. Topology Aware Lifecycle Manager
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
Topology Aware Lifecycle Manager (TALM) は、ハブクラスター上でのみ実行され、変更 (クラスターおよび Operator のアップグレード、設定などを含む) がネットワークにロールアウトされる方法を管理するための Operator です。
制限と要件
  • TALM は 400 のバッチでの同時クラスターデプロイメントをサポートします。
  • 事前キャッシュおよびバックアップ機能は、シングルノードの OpenShift クラスターのみを対象としています。
エンジニアリングに関する考慮事項
  • ran.openshift.io/ztp-deploy-wave アノテーションを持つポリシーのみが、クラスターの初期インストール時に TALM によって自動的に適用されます。
  • さらに ClusterGroupUpgrade CR を作成して、TALM が修復するポリシーを制御できます。
3.3.3.11.3. GitOps および GitOps ZTP プラグイン
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

注記

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

複数のバージョンごとのポリシーを同時に維持するには、Git を使用してソース CR とポリシー CR (PolicyGenTemplate または PolicyGenerator) のバージョンを管理します。

参照 CR とカスタム CR を別のディレクトリーに保存します。これを行うと、カスタム CR に触れることなく、ディレクトリーのすべてのコンテンツを簡単に置き換えるだけで、参照 CR にパッチを適用して更新できます。

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

    注記

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

  • SiteConfig CR の extraManifestPath フィールドは、OpenShift Container Platform 4.15 以降では非推奨です。代わりに新しい extraManifests.searchPaths フィールドを使用してください。
エンジニアリングに関する考慮事項
  • マルチノードクラスターのアップグレードの場合、paused フィールドを true に設定することで、メンテナンスウィンドウ中に MachineConfigPool (MCP) CR を一時停止できます。MCP CR で maxUnavailable 設定を設定することで、同時に更新される MCP ごとのノード数を増やすことができます。MaxUnavailable フィールドは、MachineConfig の更新中に同時に使用できなくなるプール内のノードのパーセンテージを定義します。maxUnavailable を最大許容値に設定します。これにより、アップグレード中にクラスター内で再起動する回数が減り、アップグレード時間が短縮されます。最終的に MCP CR の一時停止を解除すると、変更されたすべての設定が 1 回の再起動で適用されます。
  • クラスターのインストール中に、paused フィールドを true に設定し、maxUnavailable を 100% に設定することで、カスタム MCP CR を一時停止し、インストール時間を短縮できます。
  • コンテンツを更新するときに混乱や意図しないファイルの上書きを避けるため、/source-crs フォルダー内のユーザー指定の CR と Git 内の追加マニフェストには、一意で区別できる名前を使用します。
  • SiteConfig CR では、複数の追加マニフェストパスが許可されます。複数のディレクトリーパスで同じ名前のファイルが見つかった場合は、最後に見つかったファイルが優先されます。これにより、バージョン固有の Day 0 マニフェスト (追加マニフェスト) の完全なセットを Git に配置し、SiteConfig CR から参照できるようになります。この機能を使用すると、複数の OpenShift Container Platform バージョンをマネージドクラスターに同時にデプロイできます。
3.3.3.11.4. Agent-based Installer
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

インストールを管理するための追加のサーバーや仮想マシンを必要とせずに、Agent-based Installer (ABI) を使用して、ベアメタルサーバーに通信事業者向けコアクラスターをインストールできます。ABI は非接続環境でのインストールをサポートします。ABI では、宣言型カスタムリソース (CR) を使用してクラスターをインストールします。

注記

Agent-based Installer はオプションのコンポーネントです。推奨されるインストール方法は、Red Hat Advanced Cluster Management または Kubernetes Operator のマルチクラスターエンジンを使用することです。

制限と要件
  • 非接続環境でエージェントベースのインストールを実行するには、必要なすべてのコンテンツがミラーリングされた切断されたミラーレジストリーが必要です。
エンジニアリングに関する考慮事項
  • ネットワーク設定は、クラスターのインストール中に NMState カスタムリソース (CR) として適用する必要があります。
3.3.3.12. モニタリング
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

注記

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

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

    • たとえば、6 個の CPU を要求し、NUMA ノードごとに 4 個の CPU を持つ空のノードにスケジュールされている Pod を考えてみましょう。ノードの割り当て可能な合計容量は 8 CPU であり、スケジューラーはそこに Pod を配置します。ただし、各 NUMA ノードで使用できる CPU は 4 つしかないため、ノードのローカルアドミッションは失敗します。
    • 複数の NUMA ノードを持つすべてのクラスターでは、NUMA Resources Operator を使用する必要があります。KubeletConfig CR の machineConfigPoolSelector フィールドを使用して、NUMA 調整スケジューリングが必要なすべてのノードを選択します。
  • すべてのマシン設定プールは、一貫したハードウェア設定を持つ必要があります。たとえば、すべてのノードは同じ NUMA ゾーン数を持つことが期待されます。
エンジニアリングに関する考慮事項
  • Pod では、正しいスケジュールと分離のためにアノテーションが必要になる場合があります。アノテーションの詳細は、「CPU パーティショニングとパフォーマンスチューニング」を参照してください。
  • SriovNetworkNodePolicy CR の excludeTopology フィールドを使用して、スケジューリング中に SR-IOV Virtual Function NUMA アフィニティーを無視するように設定できます。
3.3.3.14. ノード設定
このリリースの新機能
  • コンテナーマウント namespace のカプセル化と kdump が、通信事業者向けコア RDS で利用できるようになりました。
説明
  • コンテナーマウント namespace のカプセル化により、システムマウントスキャンが削減され、kubelet と CRI-O から見えるコンテナーマウント namespace が作成されます。
  • kdump は、カーネルパニックが発生したときにデバッグ情報をキャプチャーする、デフォルトで有効になっているオプションの設定です。kdump を有効にするリファレンス CR には、リファレンス設定に含まれるドライバーとカーネルモジュールのセットに基づいて、メモリー予約が増加します。
制限と要件
  • kdump とコンテナーマウント namespace のカプセル化は、追加のカーネルモジュールを通じて使用できるようになります。これらのモジュールを分析して、CPU 負荷、システムパフォーマンス、必要な KPI を満たす能力への影響を判断する必要があります。
エンジニアリングに関する考慮事項
  • MachineConfig CR を使用して次のカーネルモジュールをインストールします。これらのモジュールは、クラウドネイティブ関数 (CNF) に拡張カーネル機能を提供します。

    • sctp
    • ip_gre
    • ip6_tables
    • ip6t_REJECT
    • ip6table_filter
    • ip6table_mangle
    • iptable_filter
    • iptable_mangle
    • iptable_nat
    • xt_multiport
    • xt_owner
    • xt_REDIRECT
    • xt_statistic
    • xt_TCPMSS
3.3.3.15. ホストファームウェアとブートローダーの設定
このリリースの新機能
  • セキュアブートは、通信事業者向けコアリファレンス設計で設定されたクラスターホストに推奨されるようになりました。
エンジニアリングに関する考慮事項
  • 推奨される設定は、セキュアブートを有効にすることです。

    注記

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

3.3.3.16. 非接続環境
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明
通信事業者向けコアクラスターは、インターネットに直接アクセスできないネットワークにインストールされることが想定されています。クラスターのインストール、設定、および Operator に必要なすべてのコンテナーイメージは、切断されたレジストリーで利用できる必要があります。これには、OpenShift Container Platform イメージ、Day 2 Operator Lifecycle Manager (OLM) Operator イメージ、およびアプリケーションワークロードイメージが含まれます。
制限と要件
  • すべてのカスタム CatalogSources には一意の名前が必要です。デフォルトのカタログ名を再利用しないでください。
  • 有効なタイムソースは、クラスターのインストールの一部として設定する必要があります。
3.3.3.17. セキュリティー
このリリースの新機能
  • セキュアブートホストファームウェア設定が、通信事業者向けコアクラスターに推奨されるようになりました。詳細は、「ホストファームウェアとブートローダーの設定」を参照してください。
説明

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

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

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

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

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

3.3.4.1. 通信事業者向けコア参照デザイン設定 CR の抽出

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

前提条件

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

手順

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

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

検証

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

    出力例

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

3.3.4.2. ネットワーク参照 CR
Expand
表3.9 ネットワーク CR
コンポーネント参照 CR任意このリリースの新機能

Baseline

Network.yaml

はい

いいえ

Baseline

networkAttachmentDefinition.yaml

はい

いいえ

ロードバランサー

addr-pool.yaml

いいえ

いいえ

ロードバランサー

bfd-profile.yaml

いいえ

いいえ

ロードバランサー

bgp-advr.yaml

いいえ

いいえ

ロードバランサー

bgp-peer.yaml

いいえ

いいえ

ロードバランサー

community.yaml

いいえ

いいえ

ロードバランサー

metallb.yaml

いいえ

いいえ

ロードバランサー

metallbNS.yaml

いいえ

いいえ

ロードバランサー

metallbOperGroup.yaml

いいえ

いいえ

ロードバランサー

metallbSubscription.yaml

いいえ

いいえ

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

mc_rootless_pods_selinux.yaml

いいえ

いいえ

NMState Operator

NMState.yaml

いいえ

いいえ

NMState Operator

NMStateNS.yaml

いいえ

いいえ

NMState Operator

NMStateOperGroup.yaml

いいえ

いいえ

NMState Operator

NMStateSubscription.yaml

いいえ

いいえ

SR-IOV Network Operator

sriovNetwork.yaml

いいえ

いいえ

SR-IOV Network Operator

sriovNetworkNodePolicy.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovOperatorConfig.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscription.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscriptionNS.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscriptionOperGroup.yaml

いいえ

いいえ

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

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

control-plane-load-kernel-modules.yaml

はい

いいえ

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

sctp_module_mc.yaml

はい

いいえ

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

worker-load-kernel-modules.yaml

はい

いいえ

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

mount_namespace_config_master.yaml

いいえ

はい

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

mount_namespace_config_worker.yaml

いいえ

はい

Kdump を有効にする

kdump-master.yaml

いいえ

はい

Kdump を有効にする

kdump-worker.yaml

いいえ

はい

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

クラスターロギング

ClusterLogForwarder.yaml

はい

いいえ

クラスターロギング

ClusterLogNS.yaml

はい

いいえ

クラスターロギング

ClusterLogOperGroup.yaml

はい

いいえ

クラスターロギング

ClusterLogServiceAccount.yaml

はい

はい

クラスターロギング

ClusterLogServiceAccountAuditBinding.yaml

はい

はい

クラスターロギング

ClusterLogServiceAccountInfrastructureBinding.yaml

はい

はい

クラスターロギング

ClusterLogSubscription.yaml

はい

いいえ

切断設定

catalog-source.yaml

いいえ

いいえ

切断設定

icsp.yaml

いいえ

いいえ

切断設定

operator-hub.yaml

いいえ

いいえ

監視および可観測性

monitoring-config-cm.yaml

はい

いいえ

電源管理

PerformanceProfile.yaml

いいえ

いいえ

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

システム予約容量

control-plane-system-reserved.yaml

はい

いいえ

3.3.4.6. スケジューリング参照 CR
Expand
表3.13 CR のスケジューリング
コンポーネント参照 CR任意このリリースの新機能

NUMA 対応スケジューラー

nrop.yaml

いいえ

いいえ

NUMA 対応スケジューラー

NROPSubscription.yaml

いいえ

いいえ

NUMA 対応スケジューラー

NROPSubscriptionNS.yaml

いいえ

いいえ

NUMA 対応スケジューラー

NROPSubscriptionOperGroup.yaml

いいえ

いいえ

NUMA 対応スケジューラー

sched.yaml

いいえ

いいえ

NUMA 対応スケジューラー

Scheduler.yaml

いいえ

いいえ

3.3.4.7. ストレージ参照 CR
Expand
表3.14 ストレージ CR
コンポーネント参照 CR任意このリリースの新機能

外部 ODF 設定

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

いいえ

いいえ

外部 ODF 設定

02-ocs-external-storagecluster.yaml

いいえ

いいえ

外部 ODF 設定

odfNS.yaml

いいえ

いいえ

外部 ODF 設定

odfOperGroup.yaml

いいえ

いいえ

外部 ODF 設定

odfSubscription.yaml

いいえ

いいえ

3.3.4.8. YAML リファレンス
3.3.4.8.1. ネットワーク参照 YAML

Network.yaml

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

  # Enable to use MultiNetworkPolicy CRs
  useMultiNetworkPolicy: true
Copy to Clipboard Toggle word wrap

networkAttachmentDefinition.yaml

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

addr-pool.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: $name # eg addresspool3
  namespace: metallb-system
spec:
  ##############
  # Expected variation in this configuration
  addresses: [$pools]
  #- 3.3.3.0/24
  autoAssign: true
  ##############
Copy to Clipboard Toggle word wrap

bfd-profile.yaml

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

bgp-advr.yaml

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

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

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

  #    - bgpcommunity
  #    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100
Copy to Clipboard Toggle word wrap

bgp-peer.yaml

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

community.yaml

---
apiVersion: metallb.io/v1beta1
kind: Community
metadata:
  name: $name # e.g. bgpcommunity
  namespace: metallb-system
spec:
  communities: [$comm]
Copy to Clipboard Toggle word wrap

metallb.yaml

# required
# count: 1
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec: {}
#nodeSelector:
#  node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap

metallbNS.yaml

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

metallbOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system
Copy to Clipboard Toggle word wrap

metallbSubscription.yaml

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

mc_rootless_pods_selinux.yaml

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

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

            [Install]
            WantedBy=multi-user.target graphical.target
          enabled: true
          name: setsebool.service
Copy to Clipboard Toggle word wrap

NMState.yaml

apiVersion: nmstate.io/v1
kind: NMState
metadata:
  name: nmstate
spec: {}
Copy to Clipboard Toggle word wrap

NMStateNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nmstate
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

NMStateOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-nmstate
  namespace: openshift-nmstate
spec:
  targetNamespaces:
    - openshift-nmstate
Copy to Clipboard Toggle word wrap

NMStateSubscription.yaml

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

sriovNetwork.yaml

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

sriovNetworkNodePolicy.yaml

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

SriovOperatorConfig.yaml

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

SriovSubscription.yaml

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

SriovSubscriptionNS.yaml

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

SriovSubscriptionOperGroup.yaml

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

3.3.4.8.2. ノード設定リファレンス YAML

control-plane-load-kernel-modules.yaml

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

sctp_module_mc.yaml

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

worker-load-kernel-modules.yaml

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

mount_namespace_config_master.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
Copy to Clipboard Toggle word wrap

mount_namespace_config_worker.yaml

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
Copy to Clipboard Toggle word wrap

kdump-master.yaml

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

kdump-worker.yaml

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

3.3.4.8.3. その他の参照 YAML

ClusterLogForwarder.yaml

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  # outputs: $outputs
  # pipelines: $pipelines
  serviceAccount:
    name: collector
#apiVersion: "observability.openshift.io/v1"
#kind: ClusterLogForwarder
#metadata:
#  name: instance
#  namespace: openshift-logging
# spec:
#   outputs:
#   - type: "kafka"
#     name: kafka-open
#     # below url is an example
#     kafka:
#       url: tcp://10.11.12.13:9092/test
#   filters:
#   - name: test-labels
#     type: openshiftLabels
#     openshiftLabels:
#       label1: test1
#       label2: test2
#       label3: test3
#       label4: test4
#   pipelines:
#   - name: all-to-default
#     inputRefs:
#     - audit
#     - infrastructure
#     filterRefs:
#     - test-labels
#     outputRefs:
#     - kafka-open
#   serviceAccount:
#     name: collector
Copy to Clipboard Toggle word wrap

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  targetNamespaces:
    - openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccount.yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: collector
  namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountAuditBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-audit-logs-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-audit-logs
subjects:
  - kind: ServiceAccount
    name: collector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountInfrastructureBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-infrastructure-logs-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-infrastructure-logs
subjects:
  - kind: ServiceAccount
    name: collector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogSubscription.yaml

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

catalog-source.yaml

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

icsp.yaml

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

operator-hub.yaml

# required
# count: 1
apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true
Copy to Clipboard Toggle word wrap

monitoring-config-cm.yaml

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

PerformanceProfile.yaml

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

3.3.4.8.4. リソースチューニングリファレンス YAML

control-plane-system-reserved.yaml

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

3.3.4.8.5. スケジュール参照 YAML

nrop.yaml

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

NROPSubscription.yaml

# required
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  channel: "4.17"
  name: numaresources-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

NROPSubscriptionNS.yaml

# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-numaresources
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

NROPSubscriptionOperGroup.yaml

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

sched.yaml

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

Scheduler.yaml

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

3.3.4.8.6. ストレージ参照 YAML

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

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

02-ocs-external-storagecluster.yaml

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

odfNS.yaml

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

odfOperGroup.yaml

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

odfSubscription.yaml

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

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

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

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

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

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

Cluster Logging Operator

6.0

OpenShift Data Foundation

4.17

SR-IOV Operator

4.17

MetalLB

4.17

NMState Operator

4.17

NUMA 対応スケジューラー

4.17

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

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

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

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

警告

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

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

注記

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

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

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

ノード数

2,000 [1]

Pod の数[2]

150,000

ノードあたりの Pod 数

2,500 [3]

コアあたりの Pod 数

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

namespace の数[4]

10,000

ビルド数

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

namespace ごとの Pod の数[5]

25,000

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

ルーターあたり 2,000

シークレットの数

80,000

config map の数

90,000

サービスの数[6]

10,000

namespace ごとのサービス数

5,000

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

5,000

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

2,000

ビルド設定の数

12,000

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

1,024 [7]

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

4.1.1. シナリオ例

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

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

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

  • ノードあたりの Pod 数
  • Pod あたりのコンテナー数
  • 使用されるプローブのタイプ (liveness/readiness、exec/http など)
  • ネットワークポリシーの数
  • プロジェクトまたは namespace の数
  • プロジェクトあたりのイメージストリーム数
  • プロジェクトあたりのビルド数
  • サービス/エンドポイントの数とタイプ
  • ルート数
  • シャード数
  • シークレットの数
  • config map の数
  • API 呼び出しのレート、またはクラスターの “チャーン“。これは、クラスター設定内で物事が変化する速さの推定値です。

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

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

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

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

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

r5.4xlarge

16

128

gp3

220

3

us-west-2

インフラ [2]

m5.12xlarge

48

192

gp3

100

3

us-west-2

ワークロード [3]

m5.4xlarge

16

64

gp3

500 [4]

1

us-west-2

コンピュート

m5.2xlarge

8

32

gp3

100

3/25/250/500 [5]

us-west-2

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

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

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

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

16

32

io1

GiB あたり 120/10 IOPS

3

インフラ [2]

16

64

gp2

120

2

ワークロード [3]

16

256

gp2

120 [4]

1

コンピュート

16

64

gp2

120

2 から 100 [5]

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

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

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

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

8

32

ds8k

300 / LCU 1

3

コンピュート [1,3]

8

32

ds8k

150 / LCU 2

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

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

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

重要

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

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

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

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

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

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

シナリオ例

クラスターごとに 2200 の Pod のあるクラスターのスコープを設定する場合、ノードごとに最大 500 の Pod があることを前提として、最低でも 5 つのノードが必要になります。

2200 / 500 = 4.4
Copy to Clipboard Toggle word wrap

ノード数を 20 に増やす場合は、Pod 配分がノードごとに 110 の Pod に変わります。

2200 / 20 = 110
Copy to Clipboard Toggle word wrap

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

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

OpenShift Container Platform には、OVN-Kubernetes、DNS、Operators など、デフォルトですべてのワーカーノードで実行するいくつかのシステム Pod が付属しています。したがって、上記の式の結果は異なる場合があります。

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

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

Expand
Pod タイプPod 数最大メモリーCPU コア数永続ストレージ

apache

100

500 MB

0.5

1 GB

node.js

200

1 GB

1

1 GB

postgresql

100

1 GB

2

10 GB

JBoss EAP

100

1 GB

1

1 GB

推定要件: CPU コア 550 個、メモリー 450GB およびストレージ 1.4TB

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

Expand
ノードのタイプ数量CPURAM (GB)

ノード (オプション 1)

100

4

16

ノード (オプション 2)

50

8

32

ノード (オプション 3)

25

16

64

アプリケーションによってはオーバーコミットの環境に適しているものもあれば、そうでないものもあります。たとえば、Java アプリケーションや Huge Page を使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境は一般的な比率として約 30 % オーバーコミットされています。

アプリケーション Pod は環境変数または DNS のいずれかを使用してサービスにアクセスできます。環境変数を使用する場合、それぞれのアクティブなサービスについて、変数が Pod がノードで実行される際に kubelet によって挿入されます。クラスター対応の DNS サーバーは、Kubernetes API で新規サービスの有無を監視し、それぞれに DNS レコードのセットを作成します。DNS がクラスター全体で有効にされている場合、すべての Pod は DNS 名でサービスを自動的に解決できるはずです。DNS を使用したサービス検出は、5000 サービスを超える使用できる場合があります。サービス検出に環境変数を使用する場合、引数のリストは namespace で 5000 サービスを超える場合の許可される長さを超えると、Pod およびデプロイメントは失敗します。デプロイメントのサービス仕様ファイルのサービスリンクを無効にして、以下を解消します。

---
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: apps.openshift.io/v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    clusterIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template
Copy to Clipboard Toggle word wrap

namespace で実行できるアプリケーション Pod の数は、環境変数がサービス検出に使用される場合にサービスの数およびサービス名の長さによって異なります。システムの ARG_MAX は、新規プロセスの引数の最大の長さを定義し、デフォルトで 2097152 バイト (2 MiB) に設定されます。Kubelet は、以下を含む namespace で実行するようにスケジュールされる各 Pod に環境変数を挿入します。

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

引数の長さが許可される値を超え、サービス名の文字数がこれに影響する場合、namespace の Pod は起動に失敗し始めます。たとえば、5000 サービスを含む namespace では、サービス名の制限は 33 文字であり、これにより namespace で 5000 Pod を実行できます。

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

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。

クラスター管理者は、クォータと制限範囲を使用して制約を設定し、プロジェクトで使用されるオブジェクトの数やコンピュートリソースの量を制限できます。これは、管理者がすべてのプロジェクトでリソースの効果的な管理および割り当てを実行し、いずれのプロジェクトでの使用量がクラスターサイズに対して適切な量を超えることのないようにするのに役立ちます。

重要

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

以下のセクションは、クォータおよび制限範囲の設定を確認し、それらの制約対象や、独自の Pod およびコンテナーでコンピュートリソースを要求し、制限する方法を理解するのに役立ちます。

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

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。

以下では、クォータで管理できる一連のコンピュートリソースとオブジェクトタイプを説明します。

注記

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

Expand
表5.1 クォータで管理されるコンピュートリソース
リソース名説明

cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値であり、相互に置き換え可能なものとして使用できます。

memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません。memory および requests.memory は同じ値であり、相互に置き換え可能なものとして使用できます。

ephemeral-storage

非終了状態のすべての Pod におけるローカルの一時ストレージ要求の合計は、この値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

requests.cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値であり、相互に置き換え可能なものとして使用できます。

requests.memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません。memory および requests.memory は同じ値であり、相互に置き換え可能なものとして使用できます。

requests.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ要求の合計は、この値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

limits.cpu

非終了状態のすべての Pod での CPU 制限の合計はこの値を超えることができません。

limits.memory

非終了状態のすべての Pod でのメモリー制限の合計はこの値を超えることができません。

limits.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ制限の合計は、この値を超えることができません。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

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

requests.storage

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

persistentvolumeclaims

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

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

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

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

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

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

pods

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

replicationcontrollers

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

resourcequotas

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

services

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

secrets

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

configmaps

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

persistentvolumeclaims

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

openshift.io/imagestreams

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

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

$ oc create quota <name> --hard=count/<resource>.<group>=<quota> 
1
Copy to Clipboard Toggle word wrap
1 1
<resource> はリソースの名前であり、<group> は API グループです (該当する場合)。リソースおよびそれらの関連付けられた API グループのリストに kubectl api-resources コマンドを使用します。

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

リソースのオーバーコミットは拡張リソースには許可されません。そのため、クォータで同じ拡張リソースの requests および limits を指定する必要があります。現時点で、接頭辞 requests. のあるクォータ項目のみが拡張リソースに許可されます。以下は、GPU リソース nvidia.com/gpu のリソースクォータを設定する方法のシナリオ例です。

手順

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

    $ oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'
    Copy to Clipboard Toggle word wrap

    出力例

                        openshift.com/gpu-accelerator=true
    Capacity:
     nvidia.com/gpu:  2
    Allocatable:
     nvidia.com/gpu:  2
     nvidia.com/gpu:  0           0
    Copy to Clipboard Toggle word wrap

    この例では、2 つの GPU が利用可能です。

  2. このコマンドを使用して、namespace nvidia にクォータを設定します。この例では、クォータは 1 です。

    $ cat gpu-quota.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: gpu-quota
      namespace: nvidia
    spec:
      hard:
        requests.nvidia.com/gpu: 1
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f gpu-quota.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    resourcequota/gpu-quota created
    Copy to Clipboard Toggle word wrap

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

    $ oc describe quota gpu-quota -n nvidia
    Copy to Clipboard Toggle word wrap

    出力例

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  0     1
    Copy to Clipboard Toggle word wrap

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

    $ oc create pod gpu-pod.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: gpu-pod-s46h7
      namespace: nvidia
    spec:
      restartPolicy: OnFailure
      containers:
      - name: rhel7-gpu-pod
        image: rhel7
        env:
          - name: NVIDIA_VISIBLE_DEVICES
            value: all
          - name: NVIDIA_DRIVER_CAPABILITIES
            value: "compute,utility"
          - name: NVIDIA_REQUIRE_CUDA
            value: "cuda>=5.0"
    
        command: ["sleep"]
        args: ["infinity"]
    
        resources:
          limits:
            nvidia.com/gpu: 1
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを使用して、Pod が実行されていることを確認します。

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    出力例

    NAME              READY     STATUS      RESTARTS   AGE
    gpu-pod-s46h7     1/1       Running     0          1m
    Copy to Clipboard Toggle word wrap

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

    $ oc describe quota gpu-quota -n nvidia
    Copy to Clipboard Toggle word wrap

    出力例

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  1     1
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f gpu-pod.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1
    Copy to Clipboard Toggle word wrap

    この Forbidden エラーメッセージは、クォータが 1 GPU であり、この Pod がクォータを超える 2 番目の GPU を割り当てようとしたために発生します。

5.1.2. クォータのスコープ

各クォータには スコープ のセットが関連付けられます。クォータは、列挙されたスコープの交差部分に一致する場合にのみリソースの使用状況を測定します。

スコープをクォータに追加すると、クォータが適用されるリソースのセットを制限できます。許可されるセット以外のリソースを設定すると、検証エラーが発生します。

Expand
スコープ説明

Terminating

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

NotTerminating

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

BestEffort

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

otBestEffort

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

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

  • pods

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

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

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

関連情報

コンピュートリソースの詳細は、クォータによって管理されるリソース を参照してください。

コンピュートリソースのコミットについての詳細は、Quality of Service (QoS) クラス を参照してください。

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

5.2.1. クォータの実施

プロジェクトのリソースクォータが最初に作成されると、プロジェクトは、更新された使用状況の統計情報が計算されるまでクォータ制約の違反を引き起こす可能性のある新規リソースの作成機能を制限します。

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

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

設定可能な時間を指定して、クォータ使用量の統計値を現在確認されるシステム値まで下げるのに必要な時間を決定します。

プロジェクト変更がクォータ使用制限を超える場合、サーバーはそのアクションを拒否し、クォータ制約を違反していること、およびシステムで現在確認される使用量の統計値を示す適切なエラーメッセージがユーザーに返されます。

5.2.2. リクエストと制限の比較

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

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

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

core-object-counts.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10" 
1

    persistentvolumeclaims: "4" 
2

    replicationcontrollers: "20" 
3

    secrets: "10" 
4

    services: "10" 
5
Copy to Clipboard Toggle word wrap

1
プロジェクトに存在できる ConfigMap オブジェクトの合計数です。
2
プロジェクトに存在できる永続ボリューム要求 (PVC) の合計数です。
3
プロジェクトに存在できるレプリケーションコントローラーの合計数です。
4
プロジェクトに存在できるシークレットの合計数です。
5
プロジェクトに存在できるサービスの合計数です。

openshift-object-counts.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10" 
1
Copy to Clipboard Toggle word wrap

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

compute-resources.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" 
1

    requests.cpu: "1" 
2

    requests.memory: 1Gi 
3

    requests.ephemeral-storage: 2Gi 
4

    limits.cpu: "2" 
5

    limits.memory: 2Gi 
6

    limits.ephemeral-storage: 4Gi 
7
Copy to Clipboard Toggle word wrap

1
プロジェクトに存在できる非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 要求の合計は 1 コアを超えることができません。
3
非終了状態のすべての Pod において、メモリー要求の合計は 1 Gi を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ要求の合計は 2 Gi を超えることができません。
5
非終了状態のすべての Pod において、CPU 制限の合計は 2 コアを超えることができません。
6
非終了状態のすべての Pod において、メモリー制限の合計は 2 Gi を超えることができません。
7
非終了状態のすべての Pod において、一時ストレージ制限の合計は 4 Gi を超えることができません。

besteffort.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1" 
1

  scopes:
  - BestEffort 
2
Copy to Clipboard Toggle word wrap

1
プロジェクトに存在できる QoS (Quality of Service) が BestEffort の非終了状態の Pod の合計数です
2
クォータを、メモリーまたは CPU のいずれかの QoS (Quality of Service) が BestEffort の一致する Pod のみに制限します。

compute-resources-long-running.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4" 
1

    limits.cpu: "4" 
2

    limits.memory: "2Gi" 
3

    limits.ephemeral-storage: "4Gi" 
4

  scopes:
  - NotTerminating 
5
Copy to Clipboard Toggle word wrap

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。
5
クォータを spec.activeDeadlineSecondsnil に設定されている一致する Pod のみに制限します。ビルド Pod は、RestartNever ポリシーが適用されない場合に NotTerminating になります。

compute-resources-time-bound.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2" 
1

    limits.cpu: "1" 
2

    limits.memory: "1Gi" 
3

    limits.ephemeral-storage: "1Gi" 
4

  scopes:
  - Terminating 
5
Copy to Clipboard Toggle word wrap

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。
5
クォータを spec.activeDeadlineSeconds >=0 に設定されている一致する Pod のみに制限します。たとえば、このクォータではビルド Pod に対して課金されますが、Web サーバーやデータベースなどの長時間実行される Pod に対しては課金されません。

storage-consumption.yaml の例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10" 
1

    requests.storage: "50Gi" 
2

    gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 
3

    silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 
4

    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 
5

    bronze.storageclass.storage.k8s.io/requests.storage: "0" 
6

    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 
7
Copy to Clipboard Toggle word wrap

1
プロジェクト内の永続ボリューム要求の合計数です。
2
プロジェクトのすべての永続ボリューム要求において、要求されるストレージの合計はこの値を超えることができません。
3
プロジェクトのすべての永続ボリューム要求において、gold ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
4
プロジェクトのすべての永続ボリューム要求において、silver ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
5
プロジェクトのすべての永続ボリューム要求において、silver ストレージクラスの要求の合計数はこの値を超えることができません。
6
プロジェクトのすべての永続ボリューム要求において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合、bronze ストレージクラスはストレージを要求できないことを意味します。
7
プロジェクトのすべての永続ボリューム要求において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合は、bronze ストレージクラスでは要求を作成できないことを意味します。

5.2.4. クォータの作成

クォータを作成するには、まずファイルでクォータを定義します。次に、そのファイルを使用してプロジェクトに適用します。これを説明するリンクは、関連情報セクションを参照してください。

$ oc create -f <resource_quota_definition> [-n <project_name>]
Copy to Clipboard Toggle word wrap

以下は、core-object-counts.yaml リソースクォータ定義と demoproject プロジェクト名を使用した例です。

$ oc create -f core-object-counts.yaml -n demoproject
Copy to Clipboard Toggle word wrap

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

BuildConfig および DeploymentConfig などの、OpenShift Container Platform の標準的な namespace を使用しているリソースタイプのすべてにオブジェクトカウントクォータを作成できます。オブジェクトクォータカウントは、定義されたクォータをすべての標準的な namespace を使用しているリソースタイプに設定します。

リソースクォータの使用時に、オブジェクトがサーバーストレージにある場合、そのオブジェクトはクォータに基づいてチャージされます。以下のクォータのタイプはストレージリソースが使い切られることから保護するのに役立ちます。

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

$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>
Copy to Clipboard Toggle word wrap

オブジェクトカウントクォータの表示例:

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

$ oc describe quota test
Name:                         test
Namespace:                    quota
Resource                      Used  Hard
--------                      ----  ----
count/deployments.extensions  0     2
count/pods                    0     3
count/replicasets.extensions  0     4
count/secrets                 0     4
Copy to Clipboard Toggle word wrap

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

5.2.6. クォータの表示

Web コンソールでプロジェクトの Quota ページに移動し、プロジェクトのクォータで定義されるハード制限に関連する使用状況の統計情報を表示できます。

CLI を使用してクォータの詳細を表示することもできます。

  1. 最初に、プロジェクトで定義されたクォータのリストを取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

    $ oc get quota -n demoproject
    NAME                AGE
    besteffort          11m
    compute-resources   2m
    core-object-counts  29m
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

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

リソースのセットが削除される際に、リソースの同期期間が/etc/origin/master/master-config.yaml ファイルの resource-quota-sync-period 設定によって決定されます。

クォータの使用状況が復元される前に、ユーザーがリソースの再使用を試行すると問題が発生する場合があります。resource-quota-sync-period 設定を変更して、リソースセットの再生成が所定の期間 (秒単位) に実行され、リソースを再度利用可能にすることができます。

resource-quota-sync-period 設定例

kubernetesMasterConfig:
  apiLevels:
  - v1beta3
  - v1
  apiServerArguments: null
  controllerArguments:
    resource-quota-sync-period:
      - "10s"
Copy to Clipboard Toggle word wrap

変更を加えたら、コントローラーサービスを再起動して変更を適用します。

$ master-restart api
$ master-restart controllers
Copy to Clipboard Toggle word wrap

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

注記

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

5.2.8. リソースを消費するための明示的なクォータ

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

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

特定リソースの消費における明示的なクォータが必要となるようにするには、以下のスタンザを master-config.yaml に追加する必要があります。

admissionConfig:
  pluginConfig:
    ResourceQuota:
      configuration:
        apiVersion: resourcequota.admission.k8s.io/v1alpha1
        kind: Configuration
        limitedResources:
        - resource: persistentvolumeclaims 
1

        matchContains:
        - gold.storageclass.storage.k8s.io/requests.storage 
2
Copy to Clipboard Toggle word wrap
1
デフォルトで消費が制限されるグループまたはリソース。
2
デフォルトで制限対象となる、グループ/リソースに関連付けられたクォータで追跡されるリソースの名前です。

上記の例では、クォータシステムは PersistentVolumeClaim を作成するか、または更新するすべての操作をインターセプトします。クォータによって制御されるリソースの消費を確認します。プロジェクト内にそれらのリソースをカバーするクォータがない場合、リクエストは拒否されます。この例では、ユーザーがゴールドストレージクラスに関連付けられたストレージを使用する PersistentVolumeClaim を作成し、プロジェクト内に一致するクォータがない場合、リクエストは拒否されます。

関連情報

クォータを設定するために必要なファイルを作成する方法の例については、クォータによって管理されるリソース を参照してください。

クォータによって管理されるコンピュートリソース を割り当てる方法の説明。

プロジェクトリソースの制限とクォータの管理については、プロジェクトの使用 を参照してください。

プロジェクトにクォータが定義されている場合は、クラスター設定の考慮事項について デプロイメントについて を参照してください。

5.3. 制限範囲の設定

LimitRange オブジェクトによって定義される制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、および永続ボリューム要求レベルでのコンピュートリソース制約を定義します。制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、または永続ボリューム要求が消費できるリソースの量を指定します。

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

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

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

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits" 
1

spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2" 
2

        memory: "1Gi" 
3

      min:
        cpu: "200m" 
4

        memory: "6Mi" 
5

    - type: "Container"
      max:
        cpu: "2" 
6

        memory: "1Gi" 
7

      min:
        cpu: "100m" 
8

        memory: "4Mi" 
9

      default:
        cpu: "300m" 
10

        memory: "200Mi" 
11

      defaultRequest:
        cpu: "200m" 
12

        memory: "100Mi" 
13

      maxLimitRequestRatio:
        cpu: "10" 
14
Copy to Clipboard Toggle word wrap

1
制限範囲オブジェクトの名前です。
2
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。
3
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。
4
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
5
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
6
Pod の単一コンテナーが要求できる CPU の最大量です。
7
Pod の単一コンテナーが要求できるメモリーの最大量です。
8
Pod の単一コンテナーが要求できる CPU の最小量です。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
9
Pod の単一コンテナーが要求できるメモリーの最小量です。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
10
Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトの CPU 制限。
11
Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトのメモリー制限。
12
Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトの CPU 要求。
13
Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトのメモリー要求。
14
コンテナーの要求に対する制限の最大比率。

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

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "openshift-resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi 
1

    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20 
2

        openshift.io/images: 30 
3

    - type: "Pod"
      max:
        cpu: "2" 
4

        memory: "1Gi" 
5

        ephemeral-storage: "1Gi" 
6

      min:
        cpu: "1" 
7

        memory: "1Gi" 
8
Copy to Clipboard Toggle word wrap

1
内部レジストリーにプッシュできるイメージの最大サイズ。
2
イメージストリームの仕様で定義される一意のイメージタグの最大数。
3
イメージストリームのステータスについて仕様で定義される一意のイメージ参照の最大数。
4
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。
5
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。
6
すべてのコンテナーにわたって、Pod がノード上で要求できる一時ストレージの最大量。
7
すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。重要な情報は、「サポートされる制約」の表を参照してください。
8
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min0 に設定すると、結果の制限がなく、Pod は max メモリー値を超える量を消費することができます。

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

5.3.1. コンテナーの制限

サポートされるリソース:

  • CPU
  • メモリー

サポートされる制約

コンテナーごとに設定されます。 指定される場合、以下を満たしている必要があります。

コンテナー

Expand
制約動作

Min

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

設定で min CPU を定義している場合、要求値はその CPU 値よりも大きくなければなりません。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max 値よりも多くのリソースを消費できます。

Max

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

設定で max CPU を定義している場合、CPU 要求値を定義する必要はありません。ただし、制限範囲で指定される最大 CPU 制約を満たす制限を設定する必要があります。

MaxLimitRequestRatio

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

制限範囲で maxLimitRequestRatio 制約を定義する場合、新規コンテナーには requestlimit 値の両方が必要になります。さらに OpenShift Container Platform は、limitrequest で除算して、制限の要求に対する比率を算出します。結果は、1 を超える整数である必要があります。

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

サポートされるデフォルト:

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

5.3.2. Pod の制限

サポートされるリソース:

  • CPU
  • メモリー

サポートされる制約:

Pod のすべてのコンテナーにおいて、以下を満たしている必要があります。

Expand
表5.4 Pod
制約実施される動作

Min

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

Max

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

MaxLimitRequestRatio

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

5.3.3. イメージの制限

サポートされるリソース:

  • ストレージ

リソースタイプ名:

  • openshift.io/Image

イメージごとに設定されます。 指定される場合、以下が一致している必要があります。

Expand
表5.5 イメージ
制約動作

Max

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

注記

制限を超える Blob がレジストリーにアップロードされないようにするために、クォータを実施するようレジストリーを設定する必要があります。REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA 環境変数を true に設定する必要があります。デフォルトでは、新規デプロイメントでは、環境変数は true に設定されます。

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

サポートされるリソース:

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

リソースタイプ名:

  • openshift.io/ImageStream

イメージストリームごとに設定されます。 指定される場合、以下が一致している必要があります。

Expand
表5.6 ImageStream
制約動作

Max[openshift.io/image-tags]

length( uniqueimagetags( imagestream.spec.tags ) )Max[openshift.io/image-tags] 以下

uniqueimagetags は、指定された仕様タグのイメージへの一意の参照を返します。

Max[openshift.io/images]

length( uniqueimages( imagestream.status.tags ) )Max[openshift.io/images] 以下

uniqueimages はステータスタグにある一意のイメージ名を返します。名前はイメージのダイジェストと等しくなります。

5.3.5. イメージ参照のカウント

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

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

5.3.6. PersistentVolumeClaim の制限

サポートされるリソース:

  • ストレージ

サポートされる制約:

プロジェクトのすべての永続ボリューム要求において、以下が一致している必要があります。

Expand
表5.7 Pod
制約実施される動作

Min

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

Max

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

Limit Range オブジェクトの定義

{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs" 
1

  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi" 
2

        },
        "max": {
          "storage": "50Gi" 
3

        }
      }
    ]
  }
}
Copy to Clipboard Toggle word wrap

1
制限範囲オブジェクトの名前です。
2
永続ボリューム要求で要求できるストレージの最小量です。
3
永続ボリューム要求で要求できるストレージの最大量です。

関連情報

ストリームの制限の詳細は、イメージストリームの管理 を参照してください。

詳細は、ストリーム制限 を参照してください。

詳細は、コンピュートリソースの制約 を参照してください。

CPU とメモリーの測定方法の詳細は、推奨されるコントロールプレーンのプラクティス を参照してください。

一時ストレージの制限とリクエストを指定できます。この機能の詳細は、一時ストレージについて を参照してください。

5.4. 範囲制限操作

5.4.1. 制限範囲の作成

ここでは、制限範囲を作成するための手順の例を示します。

手順

  1. オブジェクトを作成します。

    $ oc create -f <limit_range_file> -n <project>
    Copy to Clipboard Toggle word wrap

5.4.2. 制限を表示する

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

手順

  1. プロジェクトで定義される制限範囲オブジェクトのリストを取得します。たとえば、demoproject というプロジェクトの場合:

    $ oc get limits -n demoproject
    Copy to Clipboard Toggle word wrap

    出力例

    NAME              AGE
    resource-limits   6d
    Copy to Clipboard Toggle word wrap

  2. 制限範囲を記述します。たとえば、resource-limits という制限範囲の場合:

    $ oc describe limits resource-limits -n demoproject
    Copy to Clipboard Toggle word wrap

    出力例

    Name:                           resource-limits
    Namespace:                      demoproject
    Type                            Resource                Min     Max     Default Request Default Limit   Max Limit/Request Ratio
    ----                            --------                ---     ---     --------------- -------------   -----------------------
    Pod                             cpu                     200m    2       -               -               -
    Pod                             memory                  6Mi     1Gi     -               -               -
    Container                       cpu                     100m    2       200m            300m            10
    Container                       memory                  4Mi     1Gi     100Mi           200Mi           -
    openshift.io/Image              storage                 -       1Gi     -               -               -
    openshift.io/ImageStream        openshift.io/image      -       12      -               -               -
    openshift.io/ImageStream        openshift.io/image-tags -       10      -               -               -
    Copy to Clipboard Toggle word wrap

5.4.3. 制限範囲の削除

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

+

$ oc delete limits <limit_name>
Copy to Clipboard Toggle word wrap

S

関連情報

ユーザーが作成できるプロジェクト数に対するさまざまな制限の適用、制限の管理、プロジェクトリソースのクォータに関する詳細は、プロジェクトごとのリソースクォータ を参照してください。

第7章 Node Tuning Operator の使用

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

7.1. Node Tuning Operator について

Node Tuning Operator は、TuneD デーモンを調整することでノードレベルのチューニングを管理し、Performance Profile コントローラーを使用して低レイテンシーのパフォーマンスを実現するのに役立ちます。ほとんどの高パフォーマンスアプリケーションでは、一定レベルのカーネルのチューニングが必要です。Node Tuning Operator は、ノードレベルの sysctl の統一された管理インターフェイスをユーザーに提供し、ユーザーが指定するカスタムチューニングを追加できるよう柔軟性を提供します。

Operator は、コンテナー化された OpenShift Container Platform の TuneD デーモンを Kubernetes デーモンセットとして管理します。これにより、カスタムチューニング仕様が、デーモンが認識する形式でクラスターで実行されるすべてのコンテナー化された TuneD デーモンに渡されます。デーモンは、ノードごとに 1 つずつ、クラスターのすべてのノードで実行されます。

コンテナー化された TuneD デーモンによって適用されるノードレベルの設定は、プロファイルの変更をトリガーするイベントで、または終了シグナルの受信および処理によってコンテナー化された TuneD デーモンが正常に終了する際にロールバックされます。

Node Tuning Operator は、パフォーマンスプロファイルコントローラーを使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現します。

クラスター管理者は、以下のようなノードレベルの設定を定義するパフォーマンスプロファイルを設定します。

  • カーネルを kernel-rt に更新します。
  • ハウスキーピング用の CPU を選択します。
  • 実行中のワークロード用の CPU を選択します。

Node Tuning Operator は、バージョン 4.1 以降における標準的な OpenShift Container Platform インストールの一部となっています。

注記

OpenShift Container Platform の以前のバージョンでは、Performance Addon Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。

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

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

手順

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

    oc get tuned.tuned.openshift.io/default -o yaml -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

デフォルトの CR は、OpenShift Container Platform プラットフォームの標準的なノードレベルのチューニングを提供することを目的としており、Operator 管理の状態を設定するためにのみ変更できます。デフォルト CR へのその他のカスタム変更は、Operator によって上書きされます。カスタムチューニングの場合は、独自のチューニングされた CR を作成します。新規に作成された CR は、ノード/Pod ラベルおよびプロファイルの優先順位に基づいて OpenShift Container Platform ノードに適用されるデフォルトの CR およびカスタムチューニングと組み合わされます。

警告

特定の状況で Pod ラベルのサポートは必要なチューニングを自動的に配信する便利な方法ですが、この方法は推奨されず、とくに大規模なクラスターにおいて注意が必要です。デフォルトの調整された CR は Pod ラベル一致のない状態で提供されます。カスタムプロファイルが Pod ラベル一致のある状態で作成される場合、この機能はその時点で有効になります。Pod ラベル機能は、Node Tuning Operator の将来のバージョンで非推奨になる予定です。

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

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

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/ocp-tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40
Copy to Clipboard Toggle word wrap

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 ^ {} \;
Copy to Clipboard Toggle word wrap

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

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

$ oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
Copy to Clipboard Toggle word wrap

出力例

NAME             TUNED                     APPLIED   DEGRADED   AGE
master-0         openshift-control-plane   True      False      6h33m
master-1         openshift-control-plane   True      False      6h33m
master-2         openshift-control-plane   True      False      6h33m
worker-a         openshift-node            True      False      6h28m
worker-b         openshift-node            True      False      6h28m
Copy to Clipboard Toggle word wrap

  • NAME: Profile オブジェクトの名前。ノードごとに Profile オブジェクトが 1 つあり、それぞれの名前が一致します。
  • TUNED: 適用する任意の TuneD プロファイルの名前。
  • APPLIED: TuneD デーモンが任意のプロファイルを適用する場合は True。(true/False/Unknown)。
  • DEGRADED: TuneD プロファイルのアプリケーション中にエラーが報告される場合は True (True/False/Unknown)
  • AGE: Profile オブジェクトの作成からの経過時間。

ClusterOperator/node-tuning オブジェクトには、Operator とそのノードエージェントの状態に関する有用な情報も含まれています。たとえば、Operator の設定ミスは、ClusterOperator/node-tuning ステータスメッセージによって報告されます。

ClusterOperator/node-tuning オブジェクトに関するステータス情報を取得するには、次のコマンドを実行します。

$ oc get co/node-tuning -n openshift-cluster-node-tuning-operator
Copy to Clipboard Toggle word wrap

出力例

NAME          VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
node-tuning   4.17.1    True        False         True       60m     1/5 Profiles with bootcmdline conflict
Copy to Clipboard Toggle word wrap

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

7.5. カスタムチューニング仕様

Operator のカスタムリソース (CR) には 2 つの重要なセクションがあります。1 つ目のセクションの profile: は TuneD プロファイルおよびそれらの名前のリストです。2 つ目の recommend: は、プロファイル選択ロジックを定義します。

複数のカスタムチューニング仕様は、Operator の namespace に複数の CR として共存できます。新規 CR の存在または古い CR の削除は Operator によって検出されます。既存のカスタムチューニング仕様はすべてマージされ、コンテナー化された TuneD デーモンの適切なオブジェクトは更新されます。

管理状態

Operator 管理の状態は、デフォルトの Tuned CR を調整して設定されます。デフォルトで、Operator は Managed 状態であり、spec.managementState フィールドはデフォルトの Tuned CR に表示されません。Operator Management 状態の有効な値は以下のとおりです。

  • Managed: Operator は設定リソースが更新されるとそのオペランドを更新します。
  • Unmanaged: Operator は設定リソースへの変更を無視します。
  • Removed: Operator は Operator がプロビジョニングしたオペランドおよびリソースを削除します。

プロファイルデータ

profile: セクションは、TuneD プロファイルおよびそれらの名前をリスト表示します。

profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings
Copy to Clipboard Toggle word wrap

推奨プロファイル

profile: 選択ロジックは、CR の recommend: セクションによって定義されます。recommend: セクションは、選択基準に基づくプロファイルの推奨項目のリストです。

recommend:
<recommend-item-1>
# ...
<recommend-item-n>
Copy to Clipboard Toggle word wrap

リストの個別項目:

- machineConfigLabels: 
1

    <mcLabels> 
2

  match: 
3

    <match> 
4

  priority: <priority> 
5

  profile: <tuned_profile_name> 
6

  operand: 
7

    debug: <bool> 
8

    tunedConfig:
      reapply_sysctl: <bool> 
9
Copy to Clipboard Toggle word wrap
1
オプション:
2
キー/値の MachineConfig ラベルのディクショナリー。キーは一意である必要があります。
3
省略する場合は、優先度の高いプロファイルが最初に一致するか、machineConfigLabels が設定されていない限り、プロファイルの一致が想定されます。
4
オプションのリスト。
5
プロファイルの順序付けの優先度。数値が小さいほど優先度が高くなります (0 が最も高い優先度になります)。
6
一致に適用する TuneD プロファイル。例: tuned_profile_1
7
オプションのオペランド設定。
8
TuneD デーモンのデバッグオンまたはオフを有効にします。オプションは、オンの場合は true、オフの場合は false です。デフォルトは false です。
9
TuneD デーモンの reapply_sysctl 機能をオンまたはオフにします。オプションは on で true、オフの場合は false です。

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

- label: <label_name> 
1

  value: <label_value> 
2

  type: <label_type> 
3

    <match> 
4
Copy to Clipboard Toggle word wrap
1
ノードまたは Pod のラベル名。
2
オプションのノードまたは Pod のラベルの値。省略されている場合も、<label_name> があるだけで一致条件を満たします。
3
オプションのオブジェクトタイプ (node または pod)。省略されている場合は、node が想定されます。
4
オプションの <match> リスト。

<match> が省略されない場合、ネストされたすべての <match> セクションが true に評価される必要もあります。そうでない場合には false が想定され、それぞれの <match> セクションのあるプロファイルは適用されず、推奨されません。そのため、ネスト化 (子の <match> セクション) は論理 AND 演算子として機能します。これとは逆に、<match> 一覧のいずれかの項目が一致する場合は、<match> の一覧全体が true に評価されます。そのため、リストは論理 OR 演算子として機能します。

machineConfigLabels が定義されている場合は、マシン設定プールベースのマッチングが指定の recommend: 一覧の項目に対してオンになります。<mcLabels> はマシン設定のラベルを指定します。マシン設定は、プロファイル <tuned_profile_name> についてカーネル起動パラメーターなどのホスト設定を適用するために自動的に作成されます。この場合は、マシン設定セレクターが <mcLabels> に一致するすべてのマシン設定プールを検索し、プロファイル <tuned_profile_name> を確認されるマシン設定プールが割り当てられるすべてのノードに設定する必要があります。マスターロールとワーカーのロールの両方を持つノードをターゲットにするには、マスターロールを使用する必要があります。

リスト項目の match および machineConfigLabels は論理 OR 演算子によって接続されます。match 項目は、最初にショートサーキット方式で評価されます。そのため、true と評価される場合、machineConfigLabels 項目は考慮されません。

重要

マシン設定プールベースのマッチングを使用する場合は、同じハードウェア設定を持つノードを同じマシン設定プールにグループ化することが推奨されます。この方法に従わない場合は、TuneD オペランドが同じマシン設定プールを共有する 2 つ以上のノードの競合するカーネルパラメーターを計算する可能性があります。

例: ノードまたは Pod のラベルベースのマッチング

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node
Copy to Clipboard Toggle word wrap

上記のコンテナー化された 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
Copy to Clipboard Toggle word wrap

ノードの再起動を最小限にするには、ターゲットノードにマシン設定プールのノードセレクターが一致するラベルを使用してラベルを付け、上記の Tuned CR を作成してから、最後にカスタムのマシン設定プール自体を作成します。

クラウドプロバイダー固有の TuneD プロファイル

この機能により、すべてのクラウドプロバイダー固有のノードに、OpenShift Container Platform クラスター上の特定のクラウドプロバイダーに合わせて特別に調整された TuneD プロファイルを簡単に割り当てることができます。これは、追加のノードラベルを追加したり、ノードをマシン設定プールにグループ化したりせずに実行できます。

この機能は、<cloud-provider>://<cloud-provider-specific-id> の形式で spec.providerID ノードオブジェクト値を利用して、NTO オペランドコンテナーの <cloud-provider> の値で /var/lib/tuned/provider ファイルを書き込みます。その後、このファイルのコンテンツは TuneD により、プロバイダー provider-<cloud-provider> プロファイル (存在する場合) を読み込むために使用されます。

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

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

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
Copy to Clipboard Toggle word wrap

注記

プロファイルの継承により、provider-<cloud-provider> プロファイルで指定された設定は、openshift プロファイルとその子プロファイルによって上書きされます。

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

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

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

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

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress
Copy to Clipboard Toggle word wrap

重要

カスタムプロファイル作成者は、デフォルトの 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|^.*/||'
Copy to Clipboard Toggle word wrap

このコマンドで取得したプロファイル名をカスタムのチューニング仕様で使用できます。

例: 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
Copy to Clipboard Toggle word wrap

ビルトインの 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
Copy to Clipboard Toggle word wrap

7.7. サポートされている TuneD デーモンプラグイン

[main] セクションを除き、以下の TuneD プラグインは、Tuned CR の profile: セクションで定義されたカスタムプロファイルを使用する場合にサポートされます。

  • audio
  • cpu
  • disk
  • eeepc_she
  • modules
  • mounts
  • net
  • scheduler
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • usb
  • video
  • vm
  • bootloader

これらのプラグインの一部によって提供される動的チューニング機能の中に、サポートされていない機能があります。以下の TuneD プラグインは現時点でサポートされていません。

  • script
  • systemd
注記

TuneD ブートローダープラグインは、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーノードのみサポートします。

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

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

手順

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

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: tuned-1
          namespace: clusters
        data:
          tuning: |
            apiVersion: tuned.openshift.io/v1
            kind: Tuned
            metadata:
              name: tuned-1
              namespace: openshift-cluster-node-tuning-operator
            spec:
              profile:
              - data: |
                  [main]
                  summary=Custom OpenShift profile
                  include=openshift-node
                  [sysctl]
                  vm.dirty_ratio="55"
                name: tuned-1-profile
              recommend:
              - priority: 20
                profile: tuned-1-profile
    Copy to Clipboard Toggle word wrap
    注記

    Tuned 仕様の spec.recommend セクションのエントリーにラベルを追加しない場合は、ノードプールベースのマッチングが想定されるため、spec.recommend セクションの最も優先度の高いプロファイルがプール内のノードに適用されます。Tuned .spec.recommend.match セクションでラベル値を設定することにより、よりきめ細かいノードラベルベースのマッチングを実現できますが、ノードプールの .spec.management.upgradeType 値を InPlace に設定しない限り、ノードラベルはアップグレード中に保持されません。

  2. 管理クラスターに ConfigMap オブジェクトを作成します。

    $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
    Copy to Clipboard Toggle word wrap
  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:
        ...
    Copy to Clipboard Toggle word wrap
    注記

    複数のノードプールで同じ 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
    Copy to Clipboard Toggle word wrap

    出力例

    NAME       AGE
    default    7m36s
    rendered   7m36s
    tuned-1    65s
    Copy to Clipboard Toggle word wrap

  2. ホストされたクラスター内の Profile オブジェクトを一覧表示します。

    $ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           TUNED            APPLIED   DEGRADED   AGE
    nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
    nodepool-1-worker-2            tuned-1-profile  True      False      7m14s
    Copy to Clipboard Toggle word wrap

    注記

    カスタムプロファイルが作成されていない場合は、openshift-node プロファイルがデフォルトで適用されます。

  3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを開始し、sysctl 値を確認します。

    $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
    Copy to Clipboard Toggle word wrap

    出力例

    vm.dirty_ratio = 55
    Copy to Clipboard Toggle word wrap

カーネルブートパラメーターの設定が必要な、ホストされたコントロールプレーンでのより高度なチューニングについては、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
    Copy to Clipboard Toggle word wrap
    注記

    .spec.recommend.match フィールドは意図的に空白のままにしています。この場合、この Tuned オブジェクトは、この ConfigMap オブジェクトが参照されているノードプール内のすべてのノードに適用されます。同じハードウェア設定を持つノードを同じノードプールにグループ化します。そうしないと、TuneD オペランドは、同じノードプールを共有する 2 つ以上のノードに対して競合するカーネルパラメーターを計算する可能性があります。

  2. 管理クラスターに ConfigMap オブジェクトを作成します。

    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <management_cluster_kubeconfig> を管理クラスターの kubeconfig ファイルの名前に置き換えます。
  3. NodePool マニフェスト YAML ファイルを作成し、NodePool のアップグレードタイプをカスタマイズして、spec.tuningConfig セクションで作成した ConfigMap オブジェクトを参照します。NodePool マニフェストを作成し、hcp CLI を使用して hugepages-nodepool.yaml という名前のファイルに保存します。

    $ hcp create nodepool aws \
      --cluster-name <hosted_cluster_name> \
    1
    
      --name <nodepool_name> \
    2
    
      --node-count <nodepool_replicas> \
    3
    
      --instance-type <instance_type> \
    4
    
      --render > hugepages-nodepool.yaml
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <nodepool_name> をノードプールの名前に置き換えます。
    3
    <nodepool_replicas> をノードプールのレプリカの数 (例: 2) に置き換えます。
    4
    <instance_type> をインスタンスタイプ (例: m5.2xlarge) に置き換えます。
    注記

    hcp create コマンドの --render フラグはシークレットをレンダリングしません。シークレットをレンダリングするには、hcp create コマンドで --render フラグと --render-sensitive フラグの両方を使用する必要があります。

  4. hugepages-nodepool.yaml ファイルで、.spec.management.upgradeTypeInPlace に設定し、作成した tuned-hugepages ConfigMap オブジェクトを参照するように .spec.tuningConfig を設定します。

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

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

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

    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml
    Copy to Clipboard Toggle word wrap

検証

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

  1. ホストされたクラスター内の Tuned オブジェクトを一覧表示します。

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                 AGE
    default              123m
    hugepages-8dfb1fed   1m23s
    rendered             123m
    Copy to Clipboard Toggle word wrap

  2. ホストされたクラスター内の Profile オブジェクトを一覧表示します。

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           TUNED                      APPLIED   DEGRADED   AGE
    nodepool-1-worker-1            openshift-node             True      False      132m
    nodepool-1-worker-2            openshift-node             True      False      131m
    hugepages-nodepool-worker-1    openshift-node-hugepages   True      False      4m8s
    hugepages-nodepool-worker-2    openshift-node-hugepages   True      False      3m57s
    Copy to Clipboard Toggle word wrap

    新しい NodePool の両方のワーカーノードには、openshift-node-hugepages プロファイルが適用されています。

  3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを起動し、/proc/cmdline を確認します。

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
    Copy to Clipboard Toggle word wrap

    出力例

    BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50
    Copy to Clipboard Toggle word wrap

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

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

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

手順

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

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

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

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

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 
    1
    
         cpuManagerReconcilePeriod: 5s 
    2
    Copy to Clipboard Toggle word wrap
    1
    ポリシーを指定します。
    • noneこのポリシーは、既存のデフォルト CPU アフィニティースキームを明示的に有効にし、スケジューラーが自動的に実行するもの以外のアフィニティーを提供しません。これはデフォルトポリシーになります。
    • staticこのポリシーは、整数の CPU 要求を持つ保証された Pod 内のコンテナーを許可します。また、ノードの排他的 CPU へのアクセスも制限します。static の場合は、小文字 の s を使用する必要があります。
    2
    オプション: CPU マネージャーの調整頻度を指定します。デフォルトは 5s です。
  5. 次のコマンドを実行して、動的 kubelet 設定を作成します。

    # oc create -f cpumanager-kubeletconfig.yaml
    Copy to Clipboard Toggle word wrap

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

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

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
    Copy to Clipboard Toggle word wrap

    出力例

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

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

    # oc debug node/perf-node.example.com
    sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager
    Copy to Clipboard Toggle word wrap

    出力例

    cpuManagerPolicy: static        
    1
    
    cpuManagerReconcilePeriod: 5s   
    2
    Copy to Clipboard Toggle word wrap

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

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

    # cat cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: cpumanager-
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: cpumanager
        image: gcr.io/google_containers/pause:3.2
        resources:
          requests:
            cpu: 1
            memory: "1G"
          limits:
            cpu: 1
            memory: "1G"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: [ALL]
      nodeSelector:
        cpumanager: "true"
    Copy to Clipboard Toggle word wrap

  10. Pod を作成します。

    # oc create -f cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

検証

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

    # oc describe pod cpumanager
    Copy to Clipboard Toggle word wrap

    出力例

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、CPU が Pod 専用として割り当てられていることを確認します。

    # oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE    NAME                CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
    cpuman       cpumanager-mlrrz    1 (28%)       1 (28%)     1G (13%)         1G (13%)       27m
    Copy to Clipboard Toggle word wrap

  3. cgroups が正しく設定されていることを確認します。次のコマンドを実行して、pause プロセスのプロセス ID (PID) を取得します。

    # oc debug node/perf-node.example.com
    Copy to Clipboard Toggle word wrap
    sh-4.2# systemctl status | grep -B5 pause
    Copy to Clipboard Toggle word wrap
    注記

    出力で複数の 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
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、サービス品質 (QoS) 層 (Guaranteed) の Pod が kubepods.slice サブディレクトリー内に配置されていることを確認します。

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

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

    出力例

    cpuset.cpus 1
    tasks 32706
    Copy to Clipboard Toggle word wrap

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

    # grep ^Cpus_allowed_list /proc/32706/status
    Copy to Clipboard Toggle word wrap

    出力例

     Cpus_allowed_list:    1
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap
    # oc describe node perf-node.example.com
    Copy to Clipboard Toggle word wrap

    出力例

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)
    Copy to Clipboard Toggle word wrap

    この仮想マシンには、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
    Copy to Clipboard Toggle word wrap

8.2. Topology Manager ポリシー

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

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

none ポリシー
これはデフォルトのポリシーで、トポロジーの配置は実行しません。
best-effort ポリシー
best-effort トポロジー管理ポリシーを持つ Pod のそれぞれのコンテナーの場合、kubelet は各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は、そのコンテナーの推奨される NUMA ノードのアフィニティーを保存します。アフィニティーが優先されない場合、Topology Manager はこれを保管し、ノードに対して Pod を許可します。
restricted ポリシー
restricted トポロジー管理ポリシーを持つ Pod のそれぞれのコンテナーの場合、kubelet は各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は、そのコンテナーの推奨される NUMA ノードのアフィニティーを保存します。アフィニティーが優先されない場合、Topology Manager はこの Pod をノードから拒否します。これにより、Pod が Pod の受付の失敗により Terminated 状態になります。
single-numa-node ポリシー
single-numa-node トポロジー管理ポリシーがある Pod のそれぞれのコンテナーの場合、kubelet は各 Hint Provider を呼び出してそれらのリソースの可用性を検出します。この情報を使用して、Topology Manager は単一の NUMA ノードのアフィニティーが可能かどうかを判別します。可能である場合、Pod はノードに許可されます。単一の NUMA ノードアフィニティーが使用できない場合には、Topology Manager は Pod をノードから拒否します。これにより、Pod は Pod の受付失敗と共に Terminated (終了) 状態になります。

8.3. Topology Manager のセットアップ

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

前提条件

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

手順

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

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

    $ oc edit KubeletConfig cpumanager-enabled
    Copy to Clipboard Toggle word wrap
    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 
    1
    
         cpuManagerReconcilePeriod: 5s
         topologyManagerPolicy: single-numa-node 
    2
    Copy to Clipboard Toggle word wrap
    1
    このパラメーターは、小文字の sstatic にする必要があります。
    2
    選択した Topology Manager 割り当てポリシーを指定します。このポリシーは single-numa-node になります。使用できる値は、defaultbest-effortrestrictedsingle-numa-node です。

8.4. Pod の Topology Manager ポリシーとの対話

以下のサンプル Pod 仕様は、Pod の Topology Manger との対話を説明しています。

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

spec:
  containers:
  - name: nginx
    image: nginx
Copy to Clipboard Toggle word wrap

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

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
Copy to Clipboard Toggle word wrap

選択したポリシーが none 以外の場合は、Topology Manager はこれらの Pod 仕様のいずれかも考慮しません。

以下の最後のサンプル 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"
Copy to Clipboard Toggle word wrap

Topology Manager はこの Pod を考慮します。Topology Manager はヒントプロバイダー (CPU マネージャーおよび Device Manager ) を参照して、Pod のトポロジーヒントを取得します。

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

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

NUMA 対応のスケジューリングと、それを使用して OpenShift Container Platform クラスターに高パフォーマンスのワークロードをデプロイする方法を学びます。

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

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

NUMA の概要

Non-Uniform Memory Access (NUMA) は、異なる CPU が異なるメモリー領域に異なる速度でアクセスできるようにするコンピュートプラットフォームアーキテクチャーです。NUMA リソーストポロジーは、コンピュートノード内の相互に関連する CPU、メモリー、および PCI デバイスの位置を指しています。共同配置されたリソースは、同じ NUMA ゾーン にあるとされています。高性能アプリケーションの場合、クラスターは単一の NUMA ゾーンで Pod ワークロードを処理する必要があります。

パフォーマンスに関する考慮事項

NUMA アーキテクチャーにより、複数のメモリーコントローラーを備えた CPU は、メモリーが配置されている場所に関係なく、CPU コンプレックス全体で使用可能なメモリーを使用できます。これにより、パフォーマンスを犠牲にして柔軟性を高めることができます。NUMA ゾーン外のメモリーを使用してワークロードを処理する CPU は、単一の NUMA ゾーンで処理されるワークロードよりも遅くなります。また、I/O に制約のあるワークロードの場合、離れた NUMA ゾーンのネットワークインターフェイスにより、情報がアプリケーションに到達する速度が低下します。通信ワークロードなどの高性能ワークロードは、これらの条件下では仕様どおりに動作できません。

NUMA 対応のスケジューリング

NUMA 対応のスケジューリングは、要求されたクラスターコンピュートリソース (CPU、メモリー、デバイス) を同じ NUMA ゾーンに配置して、レイテンシーの影響を受けやすいワークロードや高性能なワークロードを効率的に処理します。また、NUMA 対応のスケジューリングにより、コンピュートノードあたりの Pod 密度を向上させ、リソース効率を高めています。

Node Tuning Operator との統合

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

デフォルトのスケジューリングロジック

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

NUMA 対応の Pod スケジューリングの図

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

図9.1 NUMA 対応スケジューリングの概要

NodeResourceTopology API
NodeResourceTopology API は、各コンピュートノードで使用可能な NUMA ゾーンリソースを記述します。
NUMA 対応スケジューラー
NUMA 対応のセカンダリースケジューラーは、利用可能な NUMA ゾーンに関する情報を NodeResourceTopology API から受け取り、最適に処理できるノードで高パフォーマンスのワークロードをスケジュールします。
ノードトポロジーエクスポーター
ノードトポロジーエクスポーターは、各コンピュートノードで使用可能な NUMA ゾーンリソースを NodeResourceTopology API に公開します。ノードトポロジーエクスポーターデーモンは、PodResources API を使用して、kubelet からのリソース割り当てを追跡します。
PodResources API

PodResources API は各ノードに対してローカルであり、リソーストポロジーと利用可能なリソースを kubelet に公開します。

注記

PodResources API の List エンドポイントは、特定のコンテナーに割り当てられた排他的な CPU を公開します。API は、共有プールに属する CPU は公開しません。

GetAllocatableResources エンドポイントは、ノード上で使用できる割り当て可能なリソースを公開します。

関連情報

9.2. NUMA Resources Operator のインストール

NUMA Resources Operator は、NUMA 対応のワークロードとデプロイメントをスケジュールできるリソースをデプロイします。OpenShift Container Platform CLI または Web コンソールを使用して NUMA Resources Operator をインストールできます。

9.2.1. CLI を使用した NUMA Resources Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. NUMA Resources Operator の namespace を作成します。

    1. 以下の YAML を nro-namespace.yaml ファイルに保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-numaresources
      Copy to Clipboard Toggle word wrap
    2. 以下のコマンドを実行して Namespace CR を作成します。

      $ oc create -f nro-namespace.yaml
      Copy to Clipboard Toggle word wrap
  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
      Copy to Clipboard Toggle word wrap
    2. 以下のコマンドを実行して OperatorGroup CR を作成します。

      $ oc create -f nro-operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  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.17"
        name: numaresources-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
    2. 以下のコマンドを実行して Subscription CR を作成します。

      $ oc create -f nro-sub.yaml
      Copy to Clipboard Toggle word wrap

検証

  1. openshift-numaresources namespace の CSV リソースを調べて、インストールが成功したことを確認します。以下のコマンドを実行します。

    $ oc get csv -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             DISPLAY                  VERSION   REPLACES   PHASE
    numaresources-operator.v4.17.2   numaresources-operator   4.17.2               Succeeded
    Copy to Clipboard Toggle word wrap

9.2.2. Web コンソールを使用した NUMA Resources Operator のインストール

クラスター管理者は、Web コンソールを使用して NUMA Resources Operator をインストールできます。

手順

  1. NUMA Resources Operator の namespace を作成します。

    1. OpenShift Container Platform Web コンソールで、AdministrationNamespaces をクリックします。
    2. Create Namespace をクリックし、Name フィールドに openshift-numaresources と入力して Create をクリックします。
  2. NUMA Resources Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
    2. 利用可能な Operator のリストから numaresources-operator を選択し、Install をクリックします。
    3. Installed Namespaces フィールドで、openshift-umaresources namespace を選択して Install をクリックします。
  3. オプション: NUMA Resources Operator が正常にインストールされたことを確認します。

    1. OperatorsInstalled Operators ページに切り替えます。
    2. NUMA Resources Operatoropenshift-umaresources namespace にリストされ、StatusInstallSucceeded であることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • OperatorsInstalled Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • WorkloadsPods ページに移動し、default プロジェクトの Pod のログを確認します。

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

通常、遅延の影響を受けやすいワークロードを実行するクラスターは、ワークロードの遅延を最小限に抑え、パフォーマンスを最適化するのに役立つパフォーマンスプロファイルを備えています。NUMA 対応スケジューラーは、使用可能なノードの NUMA リソースと、ノードに適用されるパフォーマンスプロファイル設定に基づいき、ワークロードをデプロイします。NUMA 対応デプロイメントとワークロードのパフォーマンスプロファイルを組み合わせることで、パフォーマンスを最大化するようにワークロードがスケジュールされます。

NUMA Resources Operator を完全に動作させるには、NUMAResourcesOperator カスタムリソースと NUMA 対応のセカンダリー Pod スケジューラーをデプロイする必要があります。

9.3.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: "" 
      1
      Copy to Clipboard Toggle word wrap
      1
      これは、NUMA Resources Operator を設定する MachineConfigPool と一致する必要があります。たとえば、通信ワークロードを実行することが期待されるノードのセットを指定する、worker-cnf という名前の MachineConfigPool を作成したとします。
    2. 以下のコマンドを実行して、NUMAResourcesOperator CR を作成します。

      $ oc create -f nrop.yaml
      Copy to Clipboard Toggle word wrap
      注記

      NUMAResourcesOperator を作成すると、対応するマシン設定プールと、関連するノードの再起動がトリガーされます。

検証

  1. 以下のコマンドを実行して、NUMA Resources Operator が正常にデプロイされたことを確認します。

    $ oc get numaresourcesoperators.nodetopology.openshift.io
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                    AGE
    numaresourcesoperator   27s
    Copy to Clipboard Toggle word wrap

  2. 数分後、次のコマンドを実行して、必要なリソースが正常にデプロイされたことを確認します。

    $ oc get all -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                    READY   STATUS    RESTARTS   AGE
    pod/numaresources-controller-manager-7d9d84c58d-qk2mr   1/1     Running   0          12m
    pod/numaresourcesoperator-worker-7d96r                  2/2     Running   0          97s
    pod/numaresourcesoperator-worker-crsht                  2/2     Running   0          97s
    pod/numaresourcesoperator-worker-jp9mw                  2/2     Running   0          97s
    Copy to Clipboard Toggle word wrap

9.3.2. NUMA 対応のセカンダリー Pod スケジューラーのデプロイ

NUMA Resources Operator をインストールした後、次の手順に従って NUMA 対応のセカンダリー Pod スケジューラーをデプロイします。

手順

  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.17" 
      1
      Copy to Clipboard Toggle word wrap
      1
      非接続環境では、次のいずれかの方法でこのイメージの解像度を設定してください。
      • ImageTagMirrorSet カスタムリソース (CR) を作成する。詳細は、「関連情報」セクションの「イメージレジストリーのリポジトリーミラーリングの設定」を参照してください。
      • 切断されたレジストリーへの URL を設定する。
    2. 次のコマンドを実行して、NUMAResourcesScheduler CR を作成します。

      $ oc create -f nro-scheduler.yaml
      Copy to Clipboard Toggle word wrap
  2. 数秒後、次のコマンドを実行して、必要なリソースのデプロイメントが成功したことを確認します。

    $ oc get all -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                    READY   STATUS    RESTARTS   AGE
    pod/numaresources-controller-manager-7d9d84c58d-qk2mr   1/1     Running   0          12m
    pod/numaresourcesoperator-worker-7d96r                  2/2     Running   0          97s
    pod/numaresourcesoperator-worker-crsht                  2/2     Running   0          97s
    pod/numaresourcesoperator-worker-jp9mw                  2/2     Running   0          97s
    pod/secondary-scheduler-847cb74f84-9whlm                1/1     Running   0          10m
    
    NAME                                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
    daemonset.apps/numaresourcesoperator-worker   3         3         3       3            3           node-role.kubernetes.io/worker=   98s
    
    NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/numaresources-controller-manager   1/1     1            1           12m
    deployment.apps/secondary-scheduler                1/1     1            1           10m
    
    NAME                                                          DESIRED   CURRENT   READY   AGE
    replicaset.apps/numaresources-controller-manager-7d9d84c58d   1         1         1       12m
    replicaset.apps/secondary-scheduler-847cb74f84                1         1         1       10m
    Copy to Clipboard Toggle word wrap

9.3.3. 単一の NUMA ノードポリシーの設定

NUMA Resources Operator では、クラスター上に単一の NUMA ノードポリシーを設定する必要があります。この設定を行うには、パフォーマンスプロファイルを作成して適用するか、KubeletConfig を設定するという 2 つの方法があります。

注記

単一の NUMA ノードポリシーの設定方法としては、パフォーマンスプロファイルを適用する方法が推奨されます。パフォーマンスプロファイルの作成には、Performance Profile Creator (PPC) ツールを使用できます。クラスター上にパフォーマンスプロファイルを作成すると、KubeletConfigtuned プロファイルなどの他のチューニングコンポーネントが自動的に作成されます。

パフォーマンスプロファイルの作成の詳細は、「関連情報」セクションの「Performance Profile Creator の概要」を参照してください。

9.3.4. パフォーマンスプロファイルの例

この YAML の例は、Performance Profile Creator (PPC) ツールを使用して作成されたパフォーマンスプロファイルを示しています。

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: "3"
    reserved: 0-2
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/worker: "" 
1

  nodeSelector:
    node-role.kubernetes.io/worker: ""
  numa:
    topologyPolicy: single-numa-node 
2

  realTimeKernel:
    enabled: true
  workloadHints:
    highPowerConsumption: true
    perPodPowerManagement: false
    realTime: true
Copy to Clipboard Toggle word wrap
1
これは、NUMA Resources Operator を設定する MachineConfigPool と一致する必要があります。たとえば、通信ワークロードを実行するノードのセットを指定する、worker-cnf という名前の MachineConfigPool を作成したとします。
2
topologyPolicysingle-numa-node に設定する必要があります。PPC ツールを実行するときに topology-manager-policy 引数を single-numa-node に設定して、確実に設定するようにします。

9.3.5. KubeletConfig CRD の作成

単一の NUMA ノードポリシーの設定方法としては、パフォーマンスプロファイルを適用する方法が推奨されます。もう 1 つの方法は、次の手順に示すように、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: "" 
      1
      
        kubeletConfig:
          cpuManagerPolicy: "static" 
      2
      
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1" 
      3
      
          memoryManagerPolicy: "Static" 
      4
      
          evictionHard:
            memory.available: "100Mi"
          kubeReserved:
            memory: "512Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node" 
      5
      Copy to Clipboard Toggle word wrap
      1
      このラベルを、NUMAResourcesOperator CR の machineConfigPoolSelector と一致するように調整します。
      2
      cpuManagerPolicy の場合、static は小文字の s を使用する必要があります。
      3
      ノード上の CPU に基づいて調整します。
      4
      memoryManagerPolicy の場合、Static は大文字の S を使用する必要があります。
      5
      topologyManagerPolicysingle-numa-node に設定する必要があります。
    2. 以下のコマンドを実行して KubeletConfig CR を作成します。

      $ oc create -f nro-kubeletconfig.yaml
      Copy to Clipboard Toggle word wrap
      注記

      パフォーマンスプロファイルまたは KubeletConfig を適用すると、ノードの再起動が自動的にトリガーされます。再起動がトリガーされない場合は、ノードグループに対応する KubeletConfig のラベルを確認して、問題のトラブルシューティングを実施できます。

9.3.6. NUMA 対応スケジューラーを使用したワークロードのスケジューリング

topo-aware-scheduler をインストールし、NUMAResourcesOperator および NUMAResourcesScheduler CR を適用し、クラスターが一致するパフォーマンスプロファイルまたは kubeletconfig を含むようになったので、ワークロードを処理する必要最小限のリソースを指定するデプロイメント CR を使用して、NUMA 対応スケジューラーでワークロードをスケジュールできます。

次のデプロイメント例では、サンプルワークロードに NUMA 対応のスケジューリングを使用します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次のコマンドを実行して、クラスターにデプロイされている NUMA 対応スケジューラーの名前を取得します。

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
    Copy to Clipboard Toggle word wrap

    出力例

    "topo-aware-scheduler"
    Copy to Clipboard Toggle word wrap

  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 
      1
      
            containers:
            - name: ctnr
              image: quay.io/openshifttest/hello-openshift:openshift
              imagePullPolicy: IfNotPresent
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "10"
                requests:
                  memory: "100Mi"
                  cpu: "10"
            - name: ctnr2
              image: registry.access.redhat.com/rhel:latest
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args: [ "while true; do sleep 1h; done;" ]
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "8"
                requests:
                  memory: "100Mi"
                  cpu: "8"
      Copy to Clipboard Toggle word wrap
      1
      schedulerName は、クラスターにデプロイされている NUMA 対応のスケジューラーの名前 (topo-aware-scheduler など) と一致する必要があります。
    2. 次のコマンドを実行して、Deployment CR を作成します。

      $ oc create -f nro-deployment.yaml
      Copy to Clipboard Toggle word wrap

検証

  1. デプロイメントが正常に行われたことを確認します。

    $ oc get pods -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                READY   STATUS    RESTARTS   AGE
    numa-deployment-1-6c4f5bdb84-wgn6g                  2/2     Running   0          5m2s
    numaresources-controller-manager-7d9d84c58d-4v65j   1/1     Running   0          18m
    numaresourcesoperator-worker-7d96r                  2/2     Running   4          43m
    numaresourcesoperator-worker-crsht                  2/2     Running   2          43m
    numaresourcesoperator-worker-jp9mw                  2/2     Running   2          43m
    secondary-scheduler-847cb74f84-fpncj                1/1     Running   0          18m
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、topo-aware-scheduler がデプロイされた Pod をスケジュールしていることを確認します。

    $ oc describe pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    出力例

    Events:
      Type    Reason          Age    From                  Message
      ----    ------          ----   ----                  -------
      Normal  Scheduled       4m45s  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-6c4f5bdb84-wgn6g to worker-1
    Copy to Clipboard Toggle word wrap

    注記

    スケジューリングに使用可能なリソースよりも多くのリソースを要求するデプロイメントは、MinimumReplicasUnavailable エラーで失敗します。必要なリソースが利用可能になると、デプロイメントは成功します。Pod は、必要なリソースが利用可能になるまで Pending 状態のままになります。

  3. ノードに割り当てられる予定のリソースが一覧表示されていることを確認します。

    1. 次のコマンドを実行して、デプロイメント Pod を実行しているノードを特定します。

      $ oc get pods -n openshift-numaresources -o wide
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
      numa-deployment-1-6c4f5bdb84-wgn6g   0/2     Running   0          82m   10.128.2.50   worker-1   <none>  <none>
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行します。このとき、デプロイメント Pod を実行しているノードの名前を指定します。

      $ oc describe noderesourcetopologies.topology.node.k8s.io worker-1
      Copy to Clipboard Toggle word wrap

      出力例

      ...
      
      Zones:
        Costs:
          Name:   node-0
          Value:  10
          Name:   node-1
          Value:  21
        Name:     node-0
        Resources:
          Allocatable:  39
          Available:    21 
      1
      
          Capacity:     40
          Name:         cpu
          Allocatable:  6442450944
          Available:    6442450944
          Capacity:     6442450944
          Name:         hugepages-1Gi
          Allocatable:  134217728
          Available:    134217728
          Capacity:     134217728
          Name:         hugepages-2Mi
          Allocatable:  262415904768
          Available:    262206189568
          Capacity:     270146007040
          Name:         memory
        Type:           Node
      Copy to Clipboard Toggle word wrap

      1
      保証された Pod に割り当てられたリソースが原因で、Available な容量が減少しています。

      保証された Pod によって消費されるリソースは、noderesourcetopologies.topology.node.k8s.io にリスト表示されている使用可能なノードリソースから差し引かれます。

  4. Best-effort または Burstable のサービス品質 (qosClass) を持つ Pod のリソース割り当てが、noderesourcetopologies.topology.node.k8s.io の NUMA ノードリソースに反映されていません。Pod の消費リソースがノードリソースの計算に反映されない場合は、Pod の qosClassGuaranteed で、CPU 要求が 10 進値ではなく整数値であることを確認してください。次のコマンドを実行すると、Pod の qosClassGuaranteed であることを確認できます。

    $ oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"
    Copy to Clipboard Toggle word wrap

    出力例

    Guaranteed
    Copy to Clipboard Toggle word wrap

9.4. オプション: NUMA リソース更新のポーリング操作の設定

nodeGroup 内の NUMA Resources Operator によって制御されるデーモンは、リソースをポーリングして、利用可能な NUMA リソースに関する更新を取得します。NUMAResourcesOperator カスタムリソース (CR) で spec.nodeGroups 仕様を設定することで、これらのデーモンのポーリング操作を微調整できます。これにより、ポーリング操作の高度な制御が可能になります。これらの仕様を設定して、スケジューリング動作を改善し、最適ではないスケジューリング決定のトラブルシューティングを行います。

設定オプションは次のとおりです。

  • infoRefreshMode: kubelet をポーリングするためのトリガー条件を決定します。NUMA Resources Operator は、結果として取得した情報を API サーバーに報告します。
  • infoRefreshPeriod: ポーリング更新の間隔を決定します。
  • podsFingerprinting: ノード上で実行されている現在の Pod セットのポイントインタイム情報がポーリング更新で公開されるかどうかを決定します。

    注記

    podsFingerprinting のデフォルト値は EnabledExclusiveResources です。スケジューラーのパフォーマンスを最適化するには、podsFingerprintingEnabledExclusiveResources または Enabled に設定します。さらに、NUMAResourcesScheduler カスタムリソース (CR) の cacheResyncPeriod を 0 より大きい値に設定します。cacheResyncPeriod 仕様は、ノード上の保留中のリソースを監視することで、より正確なリソースの可用性を報告するのに役立ちます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールしている。

手順

  • NUMAResourcesOperator CR で spec.nodeGroups 仕様を設定します。

    apiVersion: nodetopology.openshift.io/v1
    kind: NUMAResourcesOperator
    metadata:
      name: numaresourcesoperator
    spec:
      nodeGroups:
      - config:
          infoRefreshMode: Periodic 
    1
    
          infoRefreshPeriod: 10s 
    2
    
          podsFingerprinting: Enabled 
    3
    
        name: worker
    Copy to Clipboard Toggle word wrap
    1
    有効な値は PeriodicEventsPeriodicAndEvents です。Periodic を使用して、infoRefreshPeriod で定義した間隔で kubelet をポーリングします。Events を使用して、Pod のライフサイクルイベントごとに kubelet をポーリングします。両方のメソッドを有効にするには、PeriodicAndEvents を使用します。
    2
    Periodic または PeriodicAndEvents リフレッシュモードのポーリング間隔を定義します。リフレッシュモードが Events の場合、このフィールドは無視されます。
    3
    有効な値は、EnabledDisabled、および EnabledExclusiveResources です。NUMAResourcesSchedulercacheResyncPeriod 仕様では、Enabled または EnabledExclusiveResources に設定する必要があります。

検証

  1. NUMA Resources Operator をデプロイした後、次のコマンドを実行して、ノードグループ設定が適用されたことを検証します。

    $ oc get numaresop numaresourcesoperator -o json | jq '.status'
    Copy to Clipboard Toggle word wrap

    出力例

          ...
    
            "config": {
            "infoRefreshMode": "Periodic",
            "infoRefreshPeriod": "10s",
            "podsFingerprinting": "Enabled"
          },
          "name": "worker"
    
          ...
    Copy to Clipboard Toggle word wrap

9.5. NUMA 対応スケジューリングのトラブルシューティング

NUMA 対応の Pod スケジューリングに関する一般的な問題をトラブルシューティングするには、次の手順を実行します。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールし、NUMA 対応のセカンダリースケジューラーをデプロイします。

手順

  1. 次のコマンドを実行して、noderesourcetopologies CRD がクラスターにデプロイされていることを確認します。

    $ oc get crd | grep noderesourcetopologies
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                              CREATED AT
    noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、NUMA 対応スケジューラー名が NUMA 対応ワークロードで指定された名前と一致することを確認します。

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
    Copy to Clipboard Toggle word wrap

    出力例

    topo-aware-scheduler
    Copy to Clipboard Toggle word wrap

  3. NUMA 対応のスケジュール可能なノードに noderesourcetopologies CR が適用されていることを確認します。以下のコマンドを実行します。

    $ oc get noderesourcetopologies.topology.node.k8s.io
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                    AGE
    compute-0.example.com   17h
    compute-1.example.com   17h
    Copy to Clipboard Toggle word wrap

    注記

    ノードの数は、マシン設定プール (mcp) ワーカー定義によって設定されているワーカーノードの数と等しくなければなりません。

  4. 次のコマンドを実行して、スケジュール可能なすべてのノードの NUMA ゾーンの粒度を確認します。

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: v1
    items:
    - apiVersion: topology.node.k8s.io/v1
      kind: NodeResourceTopology
      metadata:
        annotations:
          k8stopoawareschedwg/rte-update: periodic
        creationTimestamp: "2022-06-16T08:55:38Z"
        generation: 63760
        name: worker-0
        resourceVersion: "8450223"
        uid: 8b77be46-08c0-4074-927b-d49361471590
      topologyPolicies:
      - SingleNUMANodeContainerLevel
      zones:
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources:
        - allocatable: "38"
          available: "38"
          capacity: "40"
          name: cpu
        - allocatable: "134217728"
          available: "134217728"
          capacity: "134217728"
          name: hugepages-2Mi
        - allocatable: "262352048128"
          available: "262352048128"
          capacity: "270107316224"
          name: memory
        - allocatable: "6442450944"
          available: "6442450944"
          capacity: "6442450944"
          name: hugepages-1Gi
        type: Node
      - costs:
        - name: node-0
          value: 21
        - name: node-1
          value: 10
        name: node-1
        resources:
        - allocatable: "268435456"
          available: "268435456"
          capacity: "268435456"
          name: hugepages-2Mi
        - allocatable: "269231067136"
          available: "269231067136"
          capacity: "270573244416"
          name: memory
        - allocatable: "40"
          available: "40"
          capacity: "40"
          name: cpu
        - allocatable: "1073741824"
          available: "1073741824"
          capacity: "1073741824"
          name: hugepages-1Gi
        type: Node
    - apiVersion: topology.node.k8s.io/v1
      kind: NodeResourceTopology
      metadata:
        annotations:
          k8stopoawareschedwg/rte-update: periodic
        creationTimestamp: "2022-06-16T08:55:37Z"
        generation: 62061
        name: worker-1
        resourceVersion: "8450129"
        uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
      topologyPolicies:
      - SingleNUMANodeContainerLevel
      zones: 
    1
    
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources: 
    2
    
        - allocatable: "38"
          available: "38"
          capacity: "40"
          name: cpu
        - allocatable: "6442450944"
          available: "6442450944"
          capacity: "6442450944"
          name: hugepages-1Gi
        - allocatable: "134217728"
          available: "134217728"
          capacity: "134217728"
          name: hugepages-2Mi
        - allocatable: "262391033856"
          available: "262391033856"
          capacity: "270146301952"
          name: memory
        type: Node
      - costs:
        - name: node-0
          value: 21
        - name: node-1
          value: 10
        name: node-1
        resources:
        - allocatable: "40"
          available: "40"
          capacity: "40"
          name: cpu
        - allocatable: "1073741824"
          available: "1073741824"
          capacity: "1073741824"
          name: hugepages-1Gi
        - allocatable: "268435456"
          available: "268435456"
          capacity: "268435456"
          name: hugepages-2Mi
        - allocatable: "269192085504"
          available: "269192085504"
          capacity: "270534262784"
          name: memory
        type: Node
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
    Copy to Clipboard Toggle word wrap

    1
    zones 以下の各スタンザは、単一の NUMA ゾーンのリソースを記述しています。
    2
    resources は、NUMA ゾーンリソースの現在の状態を記述しています。items.zones.resources.available 以下に記載されているリソースが、保証された各 Pod に割り当てられた排他的な NUMA ゾーンリソースに対応していることを確認します。

9.5.1. より正確なリソース可用性の報告

cacheResyncPeriod 仕様を有効にすると、NUMA Resources Operator は、ノード上の保留中のリソースを監視し、定義された間隔でスケジューラーキャッシュ内のこの情報を同期することで、より正確なリソース可用性を報告できます。これは、次善のスケジューリング決定が引き起こす Topology Affinity Error エラーを最小限に抑えるのにも役立ちます。間隔が短いほど、ネットワーク負荷が大きくなります。デフォルトでは、cacheResyncPeriod 仕様は無効になっています。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      $ oc get NUMAResourcesScheduler
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                     AGE
      numaresourcesscheduler   92m
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler
      Copy to Clipboard Toggle word wrap

      出力例

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
      Copy to Clipboard Toggle word wrap

  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.17"
      cacheResyncPeriod: "5s" 
    1
    Copy to Clipboard Toggle word wrap
    1
    スケジューラーキャッシュの同期間隔を秒単位の値で入力します。ほとんどの実装におけるこの値は、5 が一般的です。
  3. 次のコマンドを実行して、更新された NUMAResourcesScheduler リソースを作成します。

    $ oc create -f nro-scheduler-cacheresync.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
    Copy to Clipboard Toggle word wrap

検証手順

  1. NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、CRD が正常に作成されたことを確認します。

      $ oc get crd | grep numaresourcesschedulers
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      $ oc get numaresourcesschedulers.nodetopology.openshift.io
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                     AGE
      numaresourcesscheduler   3h26m
      Copy to Clipboard Toggle word wrap

  2. スケジューラーのログが増加したログレベルを示していることを確認します。

    1. 以下のコマンドを実行して、openshift-numaresources namespace で実行されている Pod のリストを取得します。

      $ oc get pods -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、セカンダリースケジューラー Pod のログを取得します。

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      出力例

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      Copy to Clipboard Toggle word wrap

9.5.2. NUMA 対応スケジューラーログの確認

ログを確認して、NUMA 対応スケジューラーの問題をトラブルシューティングします。必要に応じて、NUMAResourcesScheduler リソースの spec.logLevel フィールドを変更して、スケジューラーのログレベルを上げることができます。許容値は NormalDebug、および Trace で、Trace が最も詳細なオプションとなります。

注記

セカンダリースケジューラーのログレベルを変更するには、実行中のスケジューラーリソースを削除し、ログレベルを変更して再デプロイします。このダウンタイム中、スケジューラーは新しいワークロードのスケジューリングに使用できません。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 現在実行中の NUMAResourcesScheduler リソースを削除します。

    1. 次のコマンドを実行して、アクティブな NUMAResourcesScheduler を取得します。

      $ oc get NUMAResourcesScheduler
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                     AGE
      numaresourcesscheduler   90m
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、セカンダリースケジューラーリソースを削除します。

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler
      Copy to Clipboard Toggle word wrap

      出力例

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
      Copy to Clipboard Toggle word wrap

  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.17"
      logLevel: Debug
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、更新された Debug ロギング NUMAResourcesScheduler リソースを作成します。

    $ oc create -f nro-scheduler-debug.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
    Copy to Clipboard Toggle word wrap

検証手順

  1. NUMA 対応スケジューラーが正常にデプロイされたことを確認します。

    1. 次のコマンドを実行して、CRD が正常に作成されたことを確認します。

      $ oc get crd | grep numaresourcesschedulers
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、新しいカスタムスケジューラーが使用可能であることを確認します。

      $ oc get numaresourcesschedulers.nodetopology.openshift.io
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                     AGE
      numaresourcesscheduler   3h26m
      Copy to Clipboard Toggle word wrap

  2. スケジューラーのログが増加したログレベルを示していることを確認します。

    1. 以下のコマンドを実行して、openshift-numaresources namespace で実行されている Pod のリストを取得します。

      $ oc get pods -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、セカンダリースケジューラー Pod のログを取得します。

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      出力例

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      Copy to Clipboard Toggle word wrap

9.5.3. リソーストポロジーエクスポーターのトラブルシューティング

対応する resource-topology-exporter ログを調べて、予期しない結果が発生している noderesourcetopologies オブジェクトをトラブルシューティングします。

注記

クラスター内の 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]}"
    Copy to Clipboard Toggle word wrap

    出力例

    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}
    Copy to Clipboard Toggle word wrap

  2. 前のステップの name の値を使用して、対象となる daemonset のラベルを取得します。

    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"
    Copy to Clipboard Toggle word wrap

    出力例

    {"name":"resource-topology"}
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、resource-topology ラベルを使用して Pod を取得します。

    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
    numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
    numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com
    Copy to Clipboard Toggle word wrap

  4. トラブルシューティングしているノードに対応するワーカー Pod で実行されている resource-topology-exporter コンテナーのログを調べます。以下のコマンドを実行します。

    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c
    Copy to Clipboard Toggle word wrap

    出力例

    I0221 13:38:18.334140       1 main.go:206] using sysinfo:
    reservedCpus: 0,1
    reservedMemory:
      "0": 1178599424
    I0221 13:38:18.334370       1 main.go:67] === System information ===
    I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
    I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
    I0221 13:38:18.546750       1 main.go:72]
    cpus: allocatable "2-103"
    hugepages-1Gi:
      numa cell 0 -> 6
      numa cell 1 -> 1
    hugepages-2Mi:
      numa cell 0 -> 64
      numa cell 1 -> 128
    memory:
      numa cell 0 -> 45758Mi
      numa cell 1 -> 48372Mi
    Copy to Clipboard Toggle word wrap

9.5.4. 欠落しているリソーストポロジーエクスポーター設定マップの修正

クラスター設定が正しく設定されていないクラスターに NUMA Resources Operator をインストールすると、場合によっては、Operator はアクティブとして表示されますが、リソーストポロジーエクスポーター (RTE) デーモンセット Pod のログには、RTE の設定が欠落していると表示されます。以下に例を示します。

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"
Copy to Clipboard Toggle word wrap

このログメッセージは、必要な設定の kubeletconfig がクラスターに適切に適用されなかったため、RTE configmap が欠落していることを示しています。たとえば、次のクラスターには numaresourcesoperator-worker configmap カスタムリソース (CR) がありません。

$ oc get configmap
Copy to Clipboard Toggle word wrap

出力例

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h
Copy to Clipboard Toggle word wrap

正しく設定されたクラスターでは、oc get configmapnumaresourcesoperator-worker configmap CR も返します。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • NUMA Resources Operator をインストールし、NUMA 対応のセカンダリースケジューラーをデプロイします。

手順

  1. 次のコマンドを使用して、kubeletconfigspec.machineConfigPoolSelector.matchLabelsMachineConfigPool (mcp) ワーカー CR の metadata.labels の値を比較します。

    1. 次のコマンドを実行して、kubeletconfig ラベルを確認します。

      $ oc get kubeletconfig -o yaml
      Copy to Clipboard Toggle word wrap

      出力例

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、mcp ラベルを確認します。

      $ oc get mcp worker -o yaml
      Copy to Clipboard Toggle word wrap

      出力例

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""
      Copy to Clipboard Toggle word wrap

      cnf-worker-tuning: enabled ラベルが MachineConfigPool オブジェクトに存在しません。

  2. MachineConfigPool CR を編集して、不足しているラベルを含めます。次に例を示します。

    $ oc edit mcp worker -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    labels:
      machineconfiguration.openshift.io/mco-built-in: ""
      pools.operator.machineconfiguration.openshift.io/worker: ""
      cnf-worker-tuning: enabled
    Copy to Clipboard Toggle word wrap

  3. ラベルの変更を適用し、クラスターが更新された設定を適用するのを待ちます。以下のコマンドを実行します。

検証

  • 不足している numaresourcesoperator-worker configmap CR が適用されていることを確認します。

    $ oc get configmap
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           DATA   AGE
    0e2a6bd3.openshift-kni.io      0      6d21h
    kube-root-ca.crt               1      6d21h
    numaresourcesoperator-worker   1      5m
    openshift-service-ca.crt       1      6d21h
    topo-aware-scheduler-config    1      6d18h
    Copy to Clipboard Toggle word wrap

9.5.5. 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/numaresources-must-gather/numaresources-must-gather-rhel9:v4.17
    Copy to Clipboard Toggle word wrap

第10章 スケーラビリティとパフォーマンスの最適化

10.1. ストレージの最適化

ストレージを最適化すると、すべてのリソースでストレージの使用を最小限に抑えることができます。管理者は、ストレージを最適化することで、既存のストレージリソースが効率的に機能できるようにすることができます。

10.1.1. 利用可能な永続ストレージオプション

永続ストレージオプションについて理解し、OpenShift Container Platform 環境を最適化できるようにします。

Expand
表10.1 利用可能なストレージオプション
ストレージタイプ説明

ブロック

  • ブロックデバイスとしてオペレーティングシステムに公開されます。
  • ストレージを完全に制御し、ファイルシステムを通過してファイルの低いレベルで操作する必要のあるアプリケーションに適しています。
  • ストレージエリアネットワーク (SAN) とも呼ばれます。
  • 共有できません。 一度に 1 つのクライアントだけがこのタイプのエンドポイントをマウントできるという意味です。

AWS EBS および VMware vSphere は、OpenShift Container Platform で永続ボリューム (PV) の動的なプロビジョニングをサポートします。

ファイル

  • マウントされるファイルシステムのエクスポートとして、OS に公開されます。
  • ネットワークアタッチストレージ (NAS) とも呼ばれます。
  • 同時実行、レイテンシー、ファイルロックのメカニズムその他の各種機能は、プロトコルおよび実装、ベンダー、スケールによって大きく異なります。

RHEL NFS、NetApp NFS [1]、および Vendor NFS

オブジェクト

  • REST API エンドポイント経由でアクセスできます。
  • OpenShift イメージレジストリーで使用するように設定できます。
  • アプリケーションは、ドライバーをアプリケーションやコンテナーに組み込む必要があります。

AWS S3

  1. NetApp NFS は Trident を使用する場合に動的 PV のプロビジョニングをサポートします。

10.1.3. データストレージ管理

以下の表は、OpenShift Container Platform コンポーネントがデータを書き込むメインディレクトリーの概要を示しています。

Expand
表10.3 OpenShift Container Platform データを保存するメインディレクトリー
ディレクトリー注記サイジング予想される拡張

/var/log

すべてのコンポーネントのログファイルです。

10 から 30 GB。

ログファイルはすぐに拡張する可能性があります。サイズは拡張するディスク別に管理するか、ログローテーションを使用して管理できます。

/var/lib/etcd

データベースを保存する際に etcd ストレージに使用されます。

20 GB 未満。

データベースは、最大 8 GB まで拡張できます。

環境と共に徐々に拡張します。メタデータのみを格納します。

メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。

/var/lib/containers

これは CRI-O ランタイムのマウントポイントです。アクティブなコンテナーランタイム (Pod を含む) およびローカルイメージのストレージに使用されるストレージです。レジストリーストレージには使用されません。

16 GB メモリーの場合、1 ノードにつき 50 GB。このサイジングは、クラスターの最小要件の決定には使用しないでください。

メモリーに 8 GB が追加されるたびに 20-25 GB を追加します。

拡張は実行中のコンテナーの容量によって制限されます。

/var/lib/kubelet

Pod の一時ボリュームストレージです。これには、ランタイムにコンテナーにマウントされる外部のすべての内容が含まれます。環境変数、kube シークレット、および永続ボリュームでサポートされていないデータボリュームが含まれます。

変動あり。

ストレージを必要とする Pod が永続ボリュームを使用している場合は最小になります。一時ストレージを使用する場合はすぐに拡張する可能性があります。

10.1.4. Microsoft Azure のストレージパフォーマンスの最適化

OpenShift Container Platform と Kubernetes は、ディスクのパフォーマンスの影響を受けるため、特にコントロールプレーンノードの etcd には、より高速なストレージが推奨されます。

実稼働の Azure クラスターとワークロードが集中するクラスターの場合、コントロールプレーンマシンの仮想マシンオペレーティングシステムディスクは、テスト済みの推奨最小スループットである 5000 IOPS/200MBps を維持できなければなりません。このスループットは、P30 (最低 1 TiB Premium SSD) を使用することで実現できます。Azure および Azure Stack Hub の場合、ディスクパフォーマンスは SSD ディスクサイズに直接依存します。Standard_D8s_v3 仮想マシンまたは他の同様のマシンタイプでサポートされるスループットと 5000 IOPS の目標を達成するには、少なくとも P30 ディスクが必要です。

データ読み取り時のレイテンシーを低く抑え、高い IOPS およびスループットを実現するには、ホストのキャッシュを ReadOnly に設定する必要があります。仮想マシンメモリーまたはローカル SSD ディスクに存在するキャッシュからのデータの読み取りは、blob ストレージにあるディスクからの読み取りよりもはるかに高速です。

10.2. ルーティングの最適化

OpenShift Container Platform HAProxy ルーターは、パフォーマンスを最適化するためにスケーリングまたは設定できます。

10.2.1. ベースライン Ingress Controller (ルーター) のパフォーマンス

OpenShift Container Platform Ingress コントローラー (ルーター) は、ルートとイングレスを使用して設定されたアプリケーションとサービスのイングレストラフィックのイングレスポイントです。

1 秒に処理される HTTP 要求について、単一の HAProxy ルーターを評価する場合に、パフォーマンスは多くの要因により左右されます。特に以下が含まれます。

  • HTTP keep-alive/close モード
  • ルートタイプ
  • TLS セッション再開のクライアントサポート
  • ターゲットルートごとの同時接続数
  • ターゲットルート数
  • バックエンドサーバーのページサイズ
  • 基盤となるインフラストラクチャー (ネットワーク、CPU など)

特定の環境でのパフォーマンスは異なりますが、Red Hat ラボはサイズが 4 vCPU/16GB RAM のパブリッククラウドインスタンスでテストしています。1kB 静的ページを提供するバックエンドで終端する 100 ルートを処理する単一の HAProxy ルーターは、1 秒あたりに以下の数のトランザクションを処理できます。

HTTP keep-alive モードのシナリオの場合:

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 またはルーターのシャード化は、アプリケーションに対してより多くのルートを提供するために使用され、ルーティング層の水平スケーリングに役立ちます。

Ingress シャーディングの詳細は、ルートラベルを使用した Ingress Controller のシャーディング設定 および namespace ラベルを使用した Ingress Controller のシャーディング設定 を参照してください。

Ingress Controller のデプロイメントは、スレッドの Ingress Controller スレッド数の設定、タイムアウトの Ingress Controller 設定パラメーター、および Ingress Controller 仕様のその他のチューニング設定に記載されている情報を使用して変更できます。

10.2.2. Ingress Controller の liveness、準備、および起動プローブの設定

クラスター管理者は、OpenShift Container Platform Ingress Controller (ルーター) によって管理されるルーター展開の kubelet の活性、準備、およびスタートアッププローブのタイムアウト値を設定できます。ルーターの liveness および readiness プローブは、デフォルトのタイムアウト値である 1 秒を使用します。これは、ネットワークまたはランタイムのパフォーマンスが著しく低下している場合には短すぎます。プローブのタイムアウトにより、アプリケーション接続を中断する不要なルーターの再起動が発生する可能性があります。より大きなタイムアウト値を設定する機能により、不要で不要な再起動のリスクを減らすことができます。

ルーターコンテナーの livenessProbereadinessProbe、および startupProbe パラメーターの