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"
cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" irq-load-balancing.crio.io: "disable"Copy to Clipboard Copied! Toggle word wrap Toggle overflow PerformanceProfile.workloadHints.perPodPowerManagementを使用して Pod ごとの電源管理を有効にすると、保証された QoS Pod で CPU をフルに使用する必要がある場合は、次のアノテーションも Pod に添付する必要があります。cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"
cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- エンジニアリングに関する考慮事項
-
必要な最小予約容量 (
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
$ mkdir -p ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C out
$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C outCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
outディレクトリーのフォルダー構造は次のとおりです。通信事業者向けコア CR は、out/telco-core-rds/ディレクトリーで表示できます。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
networkAttachmentDefinition.yaml
addr-pool.yaml
bfd-profile.yaml
bgp-advr.yaml
bgp-peer.yaml
community.yaml
metallb.yaml
metallbNS.yaml
metallbOperGroup.yaml
metallbSubscription.yaml
mc_rootless_pods_selinux.yaml
NMState.yaml
apiVersion: nmstate.io/v1
kind: NMState
metadata:
name: nmstate
spec: {}
apiVersion: nmstate.io/v1
kind: NMState
metadata:
name: nmstate
spec: {}
NMStateNS.yaml
NMStateOperGroup.yaml
NMStateSubscription.yaml
sriovNetwork.yaml
sriovNetworkNodePolicy.yaml
SriovOperatorConfig.yaml
SriovSubscription.yaml
SriovSubscriptionNS.yaml
SriovSubscriptionOperGroup.yaml
3.3.4.8.2. ノード設定リファレンス YAML リンクのコピーリンクがクリップボードにコピーされました!
control-plane-load-kernel-modules.yaml
sctp_module_mc.yaml
worker-load-kernel-modules.yaml
mount_namespace_config_master.yaml
mount_namespace_config_worker.yaml
kdump-master.yaml
kdump-worker.yaml
3.3.4.8.3. その他の参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
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.8.4. リソースチューニングリファレンス YAML リンクのコピーリンクがクリップボードにコピーされました!
control-plane-system-reserved.yaml
3.3.4.8.5. スケジュール参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
nrop.yaml
NROPSubscription.yaml
NROPSubscriptionNS.yaml
NROPSubscriptionOperGroup.yaml
sched.yaml
Scheduler.yaml
3.3.4.8.6. ストレージ参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
01-rook-ceph-external-cluster-details.secret.yaml
02-ocs-external-storagecluster.yaml
odfNS.yaml
odfOperGroup.yaml
odfSubscription.yaml
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 |