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


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

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

3.3.1.1. OpenShift Container Platform 4.15 の Telco Core 向け機能

OpenShift Container Platform 4.15 に含まれ、Telco Core リファレンスデザイン仕様 (RDS) で活用される次の機能が追加または更新されました。

Expand
表3.9 OpenShift Container Platform 4.15 の Telco Core の新機能
機能説明

IPv6 ネットワークのマルチネットワークポリシーのサポート

IPv6 ネットワーク用のマルチネットワークポリシーを作成できるようになりました。詳細は、IPv6 ネットワークでの multi-network ポリシーのサポート を参照してください。

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

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

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

Use model architecture

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

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

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

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

クラスター

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

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

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

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

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

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

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

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

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

ワーカーノード
  • ワーカーノードは、Intel 第 3 世代 Xeon (IceLake) プロセッサー以降で実行します。あるいは、Skylake またはそれ以前のプロセッサーを使用している場合は、Spectre などのシリコンセキュリティー脆弱性の緩和策を無効にする必要があります。無効にしないと、トランザクションパフォーマンスが 40% も大幅に低下する可能性があります。
  • ワーカーノードで IRQ バランシングが有効になっています。PerformanceProfile は、globallyDisableIrqLoadBalancing: false を設定します。保証された QoS Pod には、「参照コア設計コンポーネント」セクションの「CPU パーティショニングとパフォーマンスチューニング」サブセクションで説明されているように、分離を保証するためのアノテーションが付けられます。
全ノード
  • ハイパースレッディングがすべてのノードで有効になっている
  • CPU アーキテクチャーは x86_64 のみ
  • ノードは標準 (非 RT) カーネルを実行している
  • ノードはワークロード分割用に設定されていない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
    irq-load-balancing.crio.io: "disable"
    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 を予約する必要はありません。

3.3.3.2. Service Mesh

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

3.3.3.3. ネットワーク

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

3.3.3.3.1. Cluster Network Operator (CNO)
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

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

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

制限と要件
  • IPv6 サポートには OVN-Kubernetes が必要です。
  • 大規模 MTU クラスターをサポートするには、接続されたネットワーク機器を同じ値またはそれ以上の値に設定する必要があります。
エンジニアリングに関する考慮事項
  • Pod の Egress トラフィックは、routingViaHost オプションを使用してカーネルルーティングテーブルによって処理されます。ホストに適切な静的ルートを設定する必要があります。
3.3.3.3.2. ロードバランサー
このリリースの新機能
  • このリリースではリファレンス設計の更新はありません。
説明

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

一部のユースケースでは、ステートフルロードバランシングなど、MetalLB では利用できない機能が必要になる場合があります。必要に応じて、外部のサードパーティーロードバランサーを使用できます。外部ロードバランサーの選択と設定は、この仕様の範囲外です。外部のサードパーティーロードバランサーを使用する場合、統合作業には、すべてのパフォーマンスとリソース使用率の要件が満たされていることを確認するための十分な分析を含める必要があります。

制限と要件
  • ステートフルロードバランシングは MetalLB ではサポートされていません。これがワークロード CNF の要件である場合は、代替ロードバランサー実装を使用する必要があります。
  • ネットワークインフラストラクチャーでは、外部 IP アドレスがクライアントからクラスターのホストネットワークにルーティング可能であることを保証する必要があります。
エンジニアリングに関する考慮事項
  • MetalLB は、コアユースケースモデルの BGP モードでのみ使用されます。
  • コア使用モデルの場合、MetalLB は、ローカルゲートウェイモードで使用される OVN-Kubernetes ネットワークプロバイダーでのみサポートされます。「Cluster Network Operator」セクションの routingViaHost を参照してください。
  • MetalLB での BGP 設定は、ネットワークとピアの要件によって異なります。
  • アドレスプールは必要に応じて設定でき、アドレス、集約長、自動割り当て、その他の関連パラメーターを変更できます。
  • 双方向転送検出 (BFD) プロファイルのパラメーターの値は、デフォルトに近い値に維持する必要があります。値が短いと、誤検出が発生し、パフォーマンスに影響する可能性があります。
3.3.3.3.3. SR-IOV
このリリースの変更点
  • MultiNetworkPolicy リソースを SR-IOV ネットワークに適用して、ネットワーク到達可能性ポリシーを適用できるようになりました。
  • QinQ が SR-IOV Network Operator でサポートされるようになりました。これはテクニカルプレビュー機能です。
  • SR-IOV VF は、CNI を調整するときに、'allmulti' フラグを介してすべてのマルチキャストトラフィックを受信できるようになりました。これにより、Pod の Security Context Constraints (SCC) に NET_ADMIN 機能を追加する必要がなくなり、Pod の潜在的な脆弱性を最小限に抑えてセキュリティーが強化されます。

    説明
    SR-IOV を使用すると、物理ネットワークインターフェイス (PF) を複数の Virtual Function (VF) に分割できます。その後、VF を複数の Pod に割り当てることで、Pod を分離したまま、より高いスループットパフォーマンスを実現できます。SR-IOV Network Operator は、SR-IOV CNI、ネットワークデバイスプラグイン、および SR-IOV スタックのその他のコンポーネントをプロビジョニングおよび管理します。
    制限と要件
  • サポートされているネットワークインターフェイスコントローラーは、サポートされているデバイス に記載されています。
  • BIOS での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウンの検出が必要な場合は、プロトコルレベルで実行する必要があります。
  • MultiNetworkPolicy CR は、netdevice ネットワークにのみ適用できます。これは、実装では vfio インターフェイスを管理できない iptables ツールが使用されるためです。

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

3.3.3.4. ロギング

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

3.3.3.5. 電源管理

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

パフォーマンスプロファイル を使用して、クラスターを高電力モード、低電力モード、または混合モードで設定できます。電源モードの選択は、クラスター上で実行しているワークロードの特性、特にレイテンシーに対する敏感さによって異なります。Pod ごとの電源管理 C ステート機能を使用して、低レイテンシー Pod の最大遅延を設定します。

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

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

3.3.3.6. ストレージ

概要

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

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

注記

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

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

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

3.3.3.7. モニタリング

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

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

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

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

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

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

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

3.3.3.8. スケジューリング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
  • スケジューラーは、特定のワークロードに対して適切なノードを選択するロールを担う、クラスター全体のコンポーネントです。これはプラットフォームの中核部分であり、一般的なデプロイメントシナリオでは特別な設定は必要ありません。ただし、次のセクションで説明する具体的な使用例はほとんどありません。NUMA 対応スケジューリングは、NUMA リソース Operator を通じて有効にできます。詳細は、「NUMA 対応ワークロードのスケジューリング」を参照してください。
制限と要件
  • デフォルトのスケジューラーはワークロードの NUMA 局所性を理解しません。ワーカーノード上のすべての空きリソースの合計のみを認識します。これにより、Topology Manager ポリシーsingle-numa-node または restricted に設定されているノードにスケジュールされた場合にワークロードが拒否される可能性があります。

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

3.3.3.9. インストール

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

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

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

3.3.3.10. セキュリティー

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

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

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

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

3.3.3.11. スケーラビリティー

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

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

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

制限と要件
  • クラスターは少なくとも 120 ノードまで拡張可能
エンジニアリングに関する考慮事項
該当なし

3.3.3.12. 追加の設定

3.3.3.12.1. 非接続環境
説明

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

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

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

  • sctp
  • ip_gre
  • ip6_tables
  • ip6t_REJECT
  • ip6table_filter
  • ip6table_mangle
  • iptable_filter
  • iptable_mangle
  • iptable_nat
  • xt_multiport
  • xt_owner
  • xt_REDIRECT
  • xt_statistic
  • xt_TCPMSS
制限と要件
  • これらのカーネルモジュールを通じて利用可能な機能の使用は、CPU 負荷、システムパフォーマンス、および KPI を維持する能力への影響を判断するためにユーザーが分析する必要があります。
注記

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

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

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

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

3.3.4.1. リソース調整参照 CR

Expand
表3.10 リソース調整 CR
コンポーネント参照 CR任意このリリースの新機能

システム予約容量

control-plane-system-reserved.yaml

はい

いいえ

システム予約容量

pid-limits-cr.yaml

はい

いいえ

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

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

外部 ODF 設定

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

いいえ

はい

外部 ODF 設定

02-ocs-external-storagecluster.yaml

いいえ

いいえ

外部 ODF 設定

odfNS.yaml

いいえ

いいえ

外部 ODF 設定

odfOperGroup.yaml

いいえ

いいえ

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

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

Baseline

Network.yaml

いいえ

いいえ

ベースライン

networkAttachmentDefinition.yaml

はい

はい

ロードバランサー

addr-pool.yaml

いいえ

いいえ

ロードバランサー

bfd-profile.yaml

いいえ

いいえ

ロードバランサー

bgp-advr.yaml

いいえ

いいえ

ロードバランサー

bgp-peer.yaml

いいえ

いいえ

ロードバランサー

metallb.yaml

いいえ

いいえ

ロードバランサー

metallbNS.yaml

はい

いいえ

ロードバランサー

metallbOperGroup.yaml

はい

いいえ

ロードバランサー

metallbSubscription.yaml

いいえ

いいえ

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

mc_rootless_pods_selinux.yaml

いいえ

いいえ

NMState Operator

NMState.yaml

はい

はい

NMState Operator

NMStateNS.yaml

はい

はい

NMState Operator

NMStateOperGroup.yaml

はい

はい

NMState Operator

NMStateSubscription.yaml

はい

はい

SR-IOV Network Operator

sriovNetwork.yaml

はい

いいえ

SR-IOV Network Operator

sriovNetworkNodePolicy.yaml

いいえ

はい

SR-IOV Network Operator

SriovOperatorConfig.yaml

いいえ

はい

SR-IOV Network Operator

SriovSubscription.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscriptionNS.yaml

いいえ

いいえ

SR-IOV Network Operator

SriovSubscriptionOperGroup.yaml

いいえ

いいえ

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

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

NUMA 対応スケジューラー

nrop.yaml

いいえ

いいえ

NUMA 対応スケジューラー

sched.yaml

いいえ

いいえ

3.3.4.5. その他の参照 CR

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

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

control-plane-load-kernel-modules.yaml

はい

いいえ

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

sctp_module_mc.yaml

はい

いいえ

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

worker-load-kernel-modules.yaml

はい

いいえ

クラスターロギング

ClusterLogForwarder.yaml

いいえ

いいえ

クラスターロギング

ClusterLogging.yaml

いいえ

いいえ

クラスターロギング

ClusterLogNS.yaml

いいえ

いいえ

クラスターロギング

ClusterLogOperGroup.yaml

いいえ

いいえ

クラスターロギング

ClusterLogSubscription.yaml

いいえ

はい

非接続設定

catalog-source.yaml

いいえ

いいえ

切断設定

icsp.yaml

いいえ

いいえ

非接続設定

operator-hub.yaml

いいえ

いいえ

監視および可観測性

monitoring-config-cm.yaml

はい

いいえ

電源管理

PerformanceProfile.yaml

いいえ

いいえ

3.3.4.6. YAML リファレンス

3.3.4.6.1. リソースチューニング参照 YAML

control-plane-system-reserved.yaml

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

pid-limits-cr.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: 99-change-pidslimit-custom
spec:
  machineConfigPoolSelector:
    matchLabels:
      # Set to appropriate MCP
      pools.operator.machineconfiguration.openshift.io/master: ""
  containerRuntimeConfig:
    pidsLimit: $pidsLimit
    # Example:
    #pidsLimit: 4096
Copy to Clipboard Toggle word wrap

3.3.4.6.2. ストレージ参照 YAML

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

# required
# count: 1
---
apiVersion: v1
kind: Secret
metadata:
  name: rook-ceph-external-cluster-details
  namespace: openshift-storage
type: Opaque
data:
  # encoded content has been made generic
  external_cluster_details: eyJuYW1lIjoicm9vay1jZXBoLW1vbi1lbmRwb2ludHMiLCJraW5kIjoiQ29uZmlnTWFwIiwiZGF0YSI6eyJkYXRhIjoiY2VwaHVzYTE9MS4yLjMuNDo2Nzg5IiwibWF4TW9uSWQiOiIwIiwibWFwcGluZyI6Int9In19LHsibmFtZSI6InJvb2stY2VwaC1tb24iLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJhZG1pbi1zZWNyZXQiOiJhZG1pbi1zZWNyZXQiLCJmc2lkIjoiMTExMTExMTEtMTExMS0xMTExLTExMTEtMTExMTExMTExMTExIiwibW9uLXNlY3JldCI6Im1vbi1zZWNyZXQifX0seyJuYW1lIjoicm9vay1jZXBoLW9wZXJhdG9yLWNyZWRzIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsidXNlcklEIjoiY2xpZW50LmhlYWx0aGNoZWNrZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoibW9uaXRvcmluZy1lbmRwb2ludCIsImtpbmQiOiJDZXBoQ2x1c3RlciIsImRhdGEiOnsiTW9uaXRvcmluZ0VuZHBvaW50IjoiMS4yLjMuNCwxLjIuMy4zLDEuMi4zLjIiLCJNb25pdG9yaW5nUG9ydCI6IjkyODMifX0seyJuYW1lIjoiY2VwaC1yYmQiLCJraW5kIjoiU3RvcmFnZUNsYXNzIiwiZGF0YSI6eyJwb29sIjoib2RmX3Bvb2wifX0seyJuYW1lIjoicm9vay1jc2ktcmJkLW5vZGUiLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJ1c2VySUQiOiJjc2ktcmJkLW5vZGUiLCJ1c2VyS2V5IjoiIn19LHsibmFtZSI6InJvb2stY3NpLXJiZC1wcm92aXNpb25lciIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7InVzZXJJRCI6ImNzaS1yYmQtcHJvdmlzaW9uZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoicm9vay1jc2ktY2VwaGZzLXByb3Zpc2lvbmVyIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsiYWRtaW5JRCI6ImNzaS1jZXBoZnMtcHJvdmlzaW9uZXIiLCJhZG1pbktleSI6IiJ9fSx7Im5hbWUiOiJyb29rLWNzaS1jZXBoZnMtbm9kZSIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7ImFkbWluSUQiOiJjc2ktY2VwaGZzLW5vZGUiLCJhZG1pbktleSI6ImMyVmpjbVYwIn19LHsibmFtZSI6ImNlcGhmcyIsImtpbmQiOiJTdG9yYWdlQ2xhc3MiLCJkYXRhIjp7ImZzTmFtZSI6ImNlcGhmcyIsInBvb2wiOiJtYW5pbGFfZGF0YSJ9fQ==
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: {}
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

3.3.4.6.3. ネットワーク参照 YAML

Network.yaml

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

  # Enable to use MultiNetworkPolicy CRs
  useMultiNetworkPolicy: true
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
  annotations:
    metallb.universe.tf/address-pool: $name # eg addresspool3
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: 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.
  # eg:

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

bgp-peer.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
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
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
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
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
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.6.4. スケジュール参照 YAML

nrop.yaml

# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
    - config:
        # Periodic is the default setting
        infoRefreshMode: Periodic
      machineConfigPoolSelector:
        matchLabels:
          # This label must match the pool(s) you want to run NUMA-aligned workloads
          pools.operator.machineconfiguration.openshift.io/worker: ""
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.14.0"
  #logLevel: "Trace"
  schedulerName: topo-aware-scheduler
Copy to Clipboard Toggle word wrap

3.3.4.6.5. その他の参照 YAML

control-plane-load-kernel-modules.yaml

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

ClusterLogForwarder.yaml

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

ClusterLogging.yaml

# required
# count: 1
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    type: vector
  managementState: Managed
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

ClusterLogSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
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: |
    k8sPrometheusAdapter:
      dedicatedServiceMonitors:
        enabled: true
    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:
    # For SNO: machineconfiguration.openshift.io/role: 'master'
    pools.operator.machineconfiguration.openshift.io/worker: ''
  nodeSelector:
    # For SNO: node-role.kubernetes.io/master: ""
    node-role.kubernetes.io/worker: ""
  workloadHints:
    realTime: false
    highPowerConsumption: false
    perPodPowerManagement: true
  realTimeKernel:
    enabled: false
  numa:
    # All guaranteed QoS containers get resources from a single NUMA node
    topologyPolicy: "single-numa-node"
  net:
    userLevelNetworking: false
Copy to Clipboard Toggle word wrap

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る