3.3. 通信事業者向けコアリファレンス設計仕様
3.3.1. Telco core 4.17 リファレンス設計の概要 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者向けコアリファレンス設計仕様 (RDS) は、通信事業者向けコアワークロードをホストするために、コモディティーハードウェア上で実行する OpenShift Container Platform クラスターを設定します。
3.3.1.1. 通信事業者向けコアクラスターサービスベースのアーキテクチャーとネットワークトポロジー リンクのコピーリンクがクリップボードにコピーされました!
通信事業者向けコアリファレンス設計仕様 (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、カーネルネットワーキング、負荷分散などのソリューションを使用できます。
通信事業者向けコア使用モデルアーキテクチャー
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 パーティショニングは、クラスター内の
MachineConfigPoolCR ごとに 1 つずつ、PerformanceProfileCR を使用して設定されます。詳細は、「CPU のパーティショニングとパフォーマンスチューニング」を参照してください。
-
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 の排他的使用は保証されません。ワークロードは、他のワークロード、オペレーティングシステムデーモン、またはカーネルタスクによってプリエンプトされる可能性があります。
-
保証された QoS Pod が使用される可能性がありますが、
実行可能な代替手段がない限り、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"PerformanceProfile.workloadHints.perPodPowerManagementを使用して Pod ごとの電源管理を有効にすると、保証された QoS Pod で CPU をフルに使用する必要がある場合は、次のアノテーションも Pod に添付する必要があります。cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"
- エンジニアリングに関する考慮事項
-
必要な最小予約容量 (
systemReserved) は、"Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes?" のガイダンスに従ってください。 - 実際に必要な予約済み CPU 容量は、クラスターの設定とワークロードの属性によって異なります。
- この予約済み CPU 値は、フルコア (2 ハイパースレッド) の配置に切り上げられる必要があります。
- CPU パーティショニングを変更すると、MCP 内のノードがドレインされ、再起動されます。
- 予約された CPU は OpenShift ノードの割り当て可能な容量から削除されるため、Pod 密度が低下します。
- ワークロードがリアルタイム対応である場合は、リアルタイムワークロードヒントを有効にする必要があります。
- Interrupt Request (IRQ) アフィニティーをサポートしていないハードウェアは、分離された CPU に影響を与えます。CPU QoS が保証された Pod が割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートする必要があります。
-
OVS は、ネットワークトラフィックのニーズに合わせて
cpuset設定を動的に管理します。プライマリー CNI で高いネットワークスループットを処理するために追加の CPU を予約する必要はありません。 - クラスター上で実行されているワークロードに cgroups v1 が必要な場合は、初期クラスターデプロイメントの一環として cgroups v1 を使用するようにノードを設定できます。詳細は、「インストール時の Linux cgroup v1 の有効化」を参照してください。
-
必要な最小予約容量 (
3.3.3.2. Service Mesh リンクのコピーリンクがクリップボードにコピーされました!
- 説明
通信事業者向けコアのクラウドネイティブ機能 (CNF) には通常、サービスメッシュの実装が必要です。
注記特定のサービスメッシュ機能とパフォーマンス要件は、アプリケーションによって異なります。Service Mesh の実装と設定の選択は、このドキュメントの範囲外です。実装では、Pod ネットワーキングで導入される追加のレイテンシーなど、サービスメッシュがクラスターリソースの使用状況とパフォーマンスに与える影響を考慮する必要があります。
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オプションを使用してカーネルルーティングテーブルによって処理されます。ホストに適切な静的ルートを設定する必要があります。
-
Pod の Egress トラフィックは、
3.3.3.5. ロードバランサー リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの新機能
-
OpenShift Container Platform 4.17 では、
frr-k8sがデフォルトで完全にサポートされる Border Gateway Protocol (BGP) バックエンドになりました。非推奨となったfrrBGP モードは引き続き利用可能です。frr-k8sバックエンドを使用するには、クラスターをアップグレードする必要があります。
-
OpenShift Container Platform 4.17 では、
- 説明
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 からリンク状態の更新を受信しません。リンクダウンの検出が必要な場合は、プロトコルレベルで実行する必要があります。
-
MultiNetworkPolicyCR は、netdeviceネットワークにのみ適用できます。これは、実装ではvfioインターフェイスを管理できないiptablesツールが使用されるためです。
- エンジニアリングに関する考慮事項
-
vfioモードの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーション用に追加のセカンダリーネットワークを有効にするために使用されます。 -
デプロイメントから
SriovOperatorConfigCR を除外すると、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 インターフェイスが設定されます。
-
初期ネットワーク設定は、インストール CR の
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 を備えた
GuaranteedQoS Pod でのみ使用できます。
-
レイテンシー: レイテンシーの影響を受けやすいワークロードが要件を満たすようにするには、高電力設定または Pod ごとの電源管理設定のいずれかが必要になります。Pod ごとの電源管理は、専用の固定 CPU を備えた
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 ストレージサービスによって提供されます。
- 制限と要件
- IPv4/IPv6 デュアルスタックネットワーク環境では、OpenShift Data Foundation は IPv4 アドレスを使用します。詳細は、IPv4 を使用した OpenShift Data Foundation による OpenShift デュアルスタックのサポート を参照してください。
- エンジニアリングに関する考慮事項
- 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またはClusterInstanceCR を使用して定義します。- 制限と要件
- クラスターのサイズ設定 で指定された制限に従ってクラスターのサイズを設定します。
- RHACM のスケーリング制限については、パフォーマンスおよびスケーラビリティー で説明されています。
- エンジニアリングに関する考慮事項
- RHACM ポリシーハブ側テンプレートを使用して、クラスター設定をより適切にスケーリングします。グループおよびクラスターごとの値がテンプレートに置き換えられる単一のグループポリシーまたは少数の一般的なグループポリシーを使用することで、ポリシーの数を大幅に削減できます。
-
クラスター固有の設定: マネージドクラスターには通常、個々のクラスターに固有の設定値がいくつかあります。これらの設定は、クラスター名に基づいて
ConfigMapCR から取得された値を使用して、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 によって自動的に適用されます。 -
さらに
ClusterGroupUpgradeCR を作成して、TALM が修復するポリシーを制御できます。
-
3.3.3.11.3. GitOps および GitOps ZTP プラグイン リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの新機能
- このリリースではリファレンス設計の更新はありません。
- 説明
GitOps および GitOps ZTP プラグインは、クラスターのデプロイメントと設定を管理するための GitOps ベースのインフラストラクチャーを提供します。クラスターの定義と設定は、Git で宣言的な状態として維持されます。
ClusterInstanceCR をハブクラスターに適用すると、SiteConfigOperator がそれをインストール CR としてレンダリングします。または、GitOps ZTP プラグインを使用して、SiteConfigCR から直接インストール CR を生成することもできます。GitOps ZTP プラグインは、PolicyGenTemplateCR に基づいて、ポリシー内の設定 CR を自動的にラップすることをサポートします。注記ベースライン参照設定 CR を使用して、マネージドクラスターに OpenShift Container Platform の複数のバージョンをデプロイおよび管理できます。ベースライン CR と並行してカスタム CR を使用できます。
複数のバージョンごとのポリシーを同時に維持するには、Git を使用してソース CR とポリシー CR (
PolicyGenTemplateまたはPolicyGenerator) のバージョンを管理します。参照 CR とカスタム CR を別のディレクトリーに保存します。これを行うと、カスタム CR に触れることなく、ディレクトリーのすべてのコンテンツを簡単に置き換えるだけで、参照 CR にパッチを適用して更新できます。
- 制限
-
ArgoCD アプリケーションごとに 300 個の
SiteConfigCR。複数のアプリケーションを使用することで、単一のハブクラスターでサポートされるクラスターの最大数を実現できます。 -
Git の
/source-crsフォルダー内のコンテンツは、GitOps ZTP プラグインコンテナーで提供されるコンテンツを上書きします。検索パスでは Git が優先されます。 kustomization.yamlファイルと同じディレクトリーに/source-crsフォルダーを追加します。このフォルダーには、ジェネレーターとしてPolicyGenTemplateが含まれています。注記このコンテキストでは、
/source-crsディレクトリーの代替の場所はサポートされていません。-
SiteConfigCR のextraManifestPathフィールドは、OpenShift Container Platform 4.15 以降では非推奨です。代わりに新しいextraManifests.searchPathsフィールドを使用してください。
-
ArgoCD アプリケーションごとに 300 個の
- エンジニアリングに関する考慮事項
-
マルチノードクラスターのアップグレードの場合、
pausedフィールドをtrueに設定することで、メンテナンスウィンドウ中にMachineConfigPool(MCP) CR を一時停止できます。MCPCR でmaxUnavailable設定を設定することで、同時に更新されるMCPごとのノード数を増やすことができます。MaxUnavailableフィールドは、MachineConfigの更新中に同時に使用できなくなるプール内のノードのパーセンテージを定義します。maxUnavailableを最大許容値に設定します。これにより、アップグレード中にクラスター内で再起動する回数が減り、アップグレード時間が短縮されます。最終的にMCPCR の一時停止を解除すると、変更されたすべての設定が 1 回の再起動で適用されます。 -
クラスターのインストール中に、
pausedフィールドをtrueに設定し、maxUnavailableを 100% に設定することで、カスタムMCPCR を一時停止し、インストール時間を短縮できます。 -
コンテンツを更新するときに混乱や意図しないファイルの上書きを避けるため、
/source-crsフォルダー内のユーザー指定の CR と Git 内の追加マニフェストには、一意で区別できる名前を使用します。 -
SiteConfigCR では、複数の追加マニフェストパスが許可されます。複数のディレクトリーパスで同じ名前のファイルが見つかった場合は、最後に見つかったファイルが優先されます。これにより、バージョン固有の Day 0 マニフェスト (追加マニフェスト) の完全なセットを Git に配置し、SiteConfigCR から参照できるようになります。この機能を使用すると、複数の 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 を使用する必要があります。
KubeletConfigCR のmachineConfigPoolSelectorフィールドを使用して、NUMA 調整スケジューリングが必要なすべてのノードを選択します。
- すべてのマシン設定プールは、一貫したハードウェア設定を持つ必要があります。たとえば、すべてのノードは同じ NUMA ゾーン数を持つことが期待されます。
- エンジニアリングに関する考慮事項
- Pod では、正しいスケジュールと分離のためにアノテーションが必要になる場合があります。アノテーションの詳細は、「CPU パーティショニングとパフォーマンスチューニング」を参照してください。
-
SriovNetworkNodePolicyCR の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 を満たす能力への影響を判断する必要があります。
- エンジニアリングに関する考慮事項
MachineConfigCR を使用して次のカーネルモジュールをインストールします。これらのモジュールは、クラウドネイティブ関数 (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またはrestrictedSCC を使用して実行する必要があります。 -
Seccomp: すべての Pod は、
RuntimeDefault(またはより強力な) seccomp プロファイルを使用して実行する必要があります。 - ルートレス DPDK Pod: 多くのユーザープレーンネットワーキング (DPDK) CNF では、Pod をルート権限で実行する必要があります。この機能を使用すると、ルート権限がなくても、準拠した DPDK Pod を実行できます。ルートレス DPDK Pod は、ルートレス Pod 内にタップデバイスを作成し、DPDK アプリケーションからカーネルにトラフィックを挿入します。
- ストレージ: ストレージネットワークは分離されており、他のクラスターネットワークにルーティングできないようにする必要があります。詳細は、「ストレージ」セクションを参照してください。
-
SecurityContextConstraints (SCC): すべてのワークロード Pod は、
- 制限と要件
ルートレス DPDK Pod には、次の追加の設定手順が必要です。
-
container_tSELinux コンテキストを使用して TAP プラグインを設定します。 -
ホスト上で
container_use_devicesSELinux ブール値を有効にします。
-
- エンジニアリングに関する考慮事項
-
ルートレス DPDK Pod のサポートの場合、TAP デバイスを作成するには、ホスト上で SELinux ブール値
container_use_devicesを有効にする必要があります。これにより、短期から中期の使用では許容できるセキュリティーリスクが発生します。他の解決策も検討されます。
-
ルートレス DPDK Pod のサポートの場合、TAP デバイスを作成するには、ホスト上で SELinux ブール値
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$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C out
検証
outディレクトリーのフォルダー構造は次のとおりです。通信事業者向けコア CR は、out/telco-core-rds/ディレクトリーで表示できます。出力例
out/ └── telco-core-rds ├── configuration │ └── reference-crs │ ├── optional │ │ ├── logging │ │ ├── networking │ │ │ └── multus │ │ │ └── tap_cni │ │ ├── other │ │ └── tuning │ └── required │ ├── networking │ │ ├── metallb │ │ ├── multinetworkpolicy │ │ └── sriov │ ├── other │ ├── performance │ ├── scheduling │ └── storage │ └── odf-external └── install
3.3.4.2. ネットワーク参照 CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| Baseline | はい | いいえ | |
| Baseline | はい | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| Multus - ルートレス DPDK Pod 用の Tap CNI | いいえ | いいえ | |
| NMState Operator | いいえ | いいえ | |
| NMState Operator | いいえ | いいえ | |
| NMState Operator | いいえ | いいえ | |
| NMState Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ |
3.3.4.3. ノード設定リファレンス CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| 追加のカーネルモジュール | はい | いいえ | |
| 追加のカーネルモジュール | はい | いいえ | |
| 追加のカーネルモジュール | はい | いいえ | |
| コンテナーマウント namespace の非表示 | いいえ | はい | |
| コンテナーマウント namespace の非表示 | いいえ | はい | |
| Kdump を有効にする | いいえ | はい | |
| Kdump を有効にする | いいえ | はい |
3.3.4.4. その他の参照 CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| クラスターロギング | はい | いいえ | |
| クラスターロギング | はい | いいえ | |
| クラスターロギング | はい | いいえ | |
| クラスターロギング | はい | はい | |
| クラスターロギング | はい | はい | |
| クラスターロギング | はい | はい | |
| クラスターロギング | はい | いいえ | |
| 切断設定 | いいえ | いいえ | |
| 切断設定 | いいえ | いいえ | |
| 切断設定 | いいえ | いいえ | |
| 監視および可観測性 | はい | いいえ | |
| 電源管理 | いいえ | いいえ |
3.3.4.5. リソースチューニングリファレンス CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| システム予約容量 | はい | いいえ |
3.3.4.6. スケジューリング参照 CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| NUMA 対応スケジューラー | いいえ | いいえ | |
| NUMA 対応スケジューラー | いいえ | いいえ | |
| NUMA 対応スケジューラー | いいえ | いいえ | |
| NUMA 対応スケジューラー | いいえ | いいえ | |
| NUMA 対応スケジューラー | いいえ | いいえ | |
| NUMA 対応スケジューラー | いいえ | いいえ |
3.3.4.7. ストレージ参照 CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| 外部 ODF 設定 | いいえ | いいえ | |
| 外部 ODF 設定 | いいえ | いいえ | |
| 外部 ODF 設定 | いいえ | いいえ | |
| 外部 ODF 設定 | いいえ | いいえ | |
| 外部 ODF 設定 | いいえ | いいえ |
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
networkAttachmentDefinition.yaml
# optional
# copies: 0-N
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: $name
namespace: $ns
spec:
nodeSelector:
kubernetes.io/hostname: $nodeName
config: $config
#eg
#config: '{
# "cniVersion": "0.3.1",
# "name": "external-169",
# "type": "vlan",
# "master": "ens8f0",
# "mode": "bridge",
# "vlanid": 169,
# "ipam": {
# "type": "static",
# }
#}'
addr-pool.yaml
# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: $name # eg addresspool3
namespace: metallb-system
spec:
##############
# Expected variation in this configuration
addresses: [$pools]
#- 3.3.3.0/24
autoAssign: true
##############
bfd-profile.yaml
# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BFDProfile
metadata:
name: $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
#
################
bgp-advr.yaml
# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
name: $name # eg bgpadvertisement-1
namespace: metallb-system
spec:
ipAddressPools: [$pool]
# eg:
# - addresspool3
peers: [$peers]
# eg:
# - peer-one
#
communities: [$communities]
# Note correlation with address pool, or Community
# eg:
# - bgpcommunity
# - 65535:65282
aggregationLength: 32
aggregationLengthV6: 128
localPref: 100
bgp-peer.yaml
# required
# count: 1-N
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
name: $name
namespace: metallb-system
spec:
peerAddress: $ip # eg 192.168.1.2
peerASN: $peerasn # eg 64501
myASN: $myasn # eg 64500
routerID: $id # eg 10.10.10.10
bfdProfile: $bfdprofile # e.g. bfdprofile
passwordSecret: {}
community.yaml
---
apiVersion: metallb.io/v1beta1
kind: Community
metadata:
name: $name # e.g. bgpcommunity
namespace: metallb-system
spec:
communities: [$comm]
metallb.yaml
# required
# count: 1
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
name: metallb
namespace: metallb-system
spec: {}
#nodeSelector:
# node-role.kubernetes.io/worker: ""
metallbNS.yaml
# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
name: metallb-system
annotations:
workload.openshift.io/allowed: management
labels:
openshift.io/cluster-monitoring: "true"
metallbOperGroup.yaml
# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: metallb-operator
namespace: metallb-system
metallbSubscription.yaml
# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: metallb-operator-sub
namespace: metallb-system
spec:
channel: stable
name: metallb-operator
source: redhat-operators-disconnected
sourceNamespace: openshift-marketplace
installPlanApproval: Automatic
status:
state: AtLatestKnown
mc_rootless_pods_selinux.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 99-worker-setsebool
spec:
config:
ignition:
version: 3.2.0
systemd:
units:
- contents: |
[Unit]
Description=Set SELinux boolean for tap cni plugin
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=/sbin/setsebool container_use_devices=on
RemainAfterExit=true
[Install]
WantedBy=multi-user.target graphical.target
enabled: true
name: setsebool.service
NMState.yaml
apiVersion: nmstate.io/v1
kind: NMState
metadata:
name: nmstate
spec: {}
NMStateNS.yaml
apiVersion: v1
kind: Namespace
metadata:
name: openshift-nmstate
annotations:
workload.openshift.io/allowed: management
NMStateOperGroup.yaml
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: openshift-nmstate
namespace: openshift-nmstate
spec:
targetNamespaces:
- openshift-nmstate
NMStateSubscription.yaml
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: kubernetes-nmstate-operator
namespace: openshift-nmstate
spec:
channel: "stable"
name: kubernetes-nmstate-operator
source: redhat-operators-disconnected
sourceNamespace: openshift-marketplace
installPlanApproval: Automatic
status:
state: AtLatestKnown
sriovNetwork.yaml
# optional (though expected for all)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
name: $name # eg sriov-network-abcd
namespace: openshift-sriov-network-operator
spec:
capabilities: "$capabilities" # eg '{"mac": true, "ips": true}'
ipam: "$ipam" # eg '{ "type": "host-local", "subnet": "10.3.38.0/24" }'
networkNamespace: $nns # eg cni-test
resourceName: $resource # eg resourceTest
sriovNetworkNodePolicy.yaml
# optional (though expected in all deployments)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: $name
namespace: openshift-sriov-network-operator
spec: {} # $spec
# eg
#deviceType: netdevice
#nicSelector:
# deviceID: "1593"
# pfNames:
# - ens8f0np0#0-9
# rootDevices:
# - 0000:d8:00.0
# vendor: "8086"
#nodeSelector:
# kubernetes.io/hostname: host.sample.lab
#numVfs: 20
#priority: 99
#excludeTopology: true
#resourceName: resourceNameABCD
SriovOperatorConfig.yaml
# required
# count: 1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
name: default
namespace: openshift-sriov-network-operator
spec:
configDaemonNodeSelector:
node-role.kubernetes.io/worker: ""
enableInjector: true
enableOperatorWebhook: true
disableDrain: false
logLevel: 2
SriovSubscription.yaml
# required: yes
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: sriov-network-operator-subscription
namespace: openshift-sriov-network-operator
spec:
channel: "stable"
name: sriov-network-operator
source: redhat-operators-disconnected
sourceNamespace: openshift-marketplace
installPlanApproval: Automatic
status:
state: AtLatestKnown
SriovSubscriptionNS.yaml
# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
name: openshift-sriov-network-operator
annotations:
workload.openshift.io/allowed: management
SriovSubscriptionOperGroup.yaml
# required: yes
# count: 1
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: sriov-network-operators
namespace: openshift-sriov-network-operator
spec:
targetNamespaces:
- openshift-sriov-network-operator
3.3.4.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
sctp_module_mc.yaml
# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: load-sctp-module
spec:
config:
ignition:
version: 2.2.0
storage:
files:
- contents:
source: data:,
verification: {}
filesystem: root
mode: 420
path: /etc/modprobe.d/sctp-blacklist.conf
- contents:
source: data:text/plain;charset=utf-8;base64,c2N0cA==
filesystem: root
mode: 420
path: /etc/modules-load.d/sctp-load.conf
worker-load-kernel-modules.yaml
# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 40-load-kernel-modules-worker
spec:
config:
# Release info found in https://github.com/coreos/butane/releases
ignition:
version: 3.2.0
storage:
files:
- contents:
source: data:,
mode: 420
overwrite: true
path: /etc/modprobe.d/kernel-blacklist.conf
- contents:
source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwo=
mode: 420
overwrite: true
path: /etc/modules-load.d/kernel-load.conf
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
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
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
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
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
ClusterLogNS.yaml
---
apiVersion: v1
kind: Namespace
metadata:
name: openshift-logging
annotations:
workload.openshift.io/allowed: management
ClusterLogOperGroup.yaml
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: cluster-logging
namespace: openshift-logging
spec:
targetNamespaces:
- openshift-logging
ClusterLogServiceAccount.yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: collector
namespace: openshift-logging
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
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
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
catalog-source.yaml
# required
# count: 1..N
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: redhat-operators-disconnected
namespace: openshift-marketplace
spec:
displayName: Red Hat Disconnected Operators Catalog
image: $imageUrl
publisher: Red Hat
sourceType: grpc
# updateStrategy:
# registryPoll:
# interval: 1h
status:
connectionState:
lastObservedState: READY
icsp.yaml
# required
# count: 1
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
name: disconnected-internal-icsp
spec:
repositoryDigestMirrors: []
# - $mirrors
operator-hub.yaml
# required
# count: 1
apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
name: cluster
spec:
disableAllDefaultSources: true
monitoring-config-cm.yaml
# optional
# count: 1
---
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-monitoring-config
namespace: openshift-monitoring
data:
config.yaml: |
prometheusK8s:
retention: 15d
volumeClaimTemplate:
spec:
storageClassName: ocs-external-storagecluster-ceph-rbd
resources:
requests:
storage: 100Gi
alertmanagerMain:
volumeClaimTemplate:
spec:
storageClassName: ocs-external-storagecluster-ceph-rbd
resources:
requests:
storage: 20Gi
PerformanceProfile.yaml
# required
# count: 1
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
name: $name
annotations:
# Some pods want the kernel stack to ignore IPv6 router Advertisement.
kubeletconfig.experimental: |
{"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
spec:
cpu:
# node0 CPUs: 0-17,36-53
# node1 CPUs: 18-34,54-71
# siblings: (0,36), (1,37)...
# we want to reserve the first Core of each NUMA socket
#
# no CPU left behind! all-cpus == isolated + reserved
isolated: $isolated # eg 1-17,19-35,37-53,55-71
reserved: $reserved # eg 0,18,36,54
# Guaranteed QoS pods will disable IRQ balancing for cores allocated to the pod.
# default value of globallyDisableIrqLoadBalancing is false
globallyDisableIrqLoadBalancing: false
hugepages:
defaultHugepagesSize: 1G
pages:
# 32GB per numa node
- count: $count # eg 64
size: 1G
#machineConfigPoolSelector: {}
# 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
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: ""
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: ""
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
NROPSubscriptionNS.yaml
# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
name: openshift-numaresources
annotations:
workload.openshift.io/allowed: management
NROPSubscriptionOperGroup.yaml
# required: yes
# count: 1
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: numaresources-operator
namespace: openshift-numaresources
spec:
targetNamespaces:
- openshift-numaresources
sched.yaml
# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
name: numaresourcesscheduler
spec:
#cacheResyncPeriod: "0"
# Image spec should be the latest for the release
imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.17.0"
#logLevel: "Trace"
schedulerName: topo-aware-scheduler
Scheduler.yaml
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
name: cluster
spec:
# non-schedulable control plane is the default. This ensures
# compliance.
mastersSchedulable: false
policy:
name: ""
3.3.4.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==
02-ocs-external-storagecluster.yaml
# required
# count: 1
---
apiVersion: ocs.openshift.io/v1
kind: StorageCluster
metadata:
name: ocs-external-storagecluster
namespace: openshift-storage
spec:
externalStorage:
enable: true
labelSelector: {}
status:
phase: Ready
odfNS.yaml
# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
name: openshift-storage
annotations:
workload.openshift.io/allowed: management
labels:
openshift.io/cluster-monitoring: "true"
odfOperGroup.yaml
# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: openshift-storage-operatorgroup
namespace: openshift-storage
spec:
targetNamespaces:
- openshift-storage
odfSubscription.yaml
# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: odf-operator
namespace: openshift-storage
spec:
channel: "stable-4.14"
name: odf-operator
source: redhat-operators-disconnected
sourceNamespace: openshift-marketplace
installPlanApproval: Automatic
status:
state: AtLatestKnown
3.3.5. 通信事業者向けコアリファレンス設計ソフトウェア仕様 リンクのコピーリンクがクリップボードにコピーされました!
以下の情報は、通信事業者向けコアリファレンス設計仕様 (RDS) 検証済みソフトウェアバージョンを説明しています。
3.3.5.1. 通信事業者向けコアリファレンス設計ソフトウェア仕様 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat 通信事業者向けコア 4.17 ソリューションは、OpenShift Container Platform クラスター用の次の Red Hat ソフトウェア製品を使用して検証されています。
| コンポーネント | ソフトウェアバージョン |
|---|---|
| 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 |