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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat