Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

4.6. 通信事業者 RAN DU リファレンス設計のコンポーネント

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

図4.2 通信事業者 RAN DU リファレンス設計のコンポーネント

通信事業者 RAN DU リファレンス設計のコンポーネントを示す図
View larger image
通信事業者 RAN DU リファレンス設計のコンポーネントを示す図
注記

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

重要

ツリー外のドライバーはサポートされていません。5G RAN アプリケーションコンポーネントは、RAN DU プロファイルに含まれておらず、アプリケーションに割り当てられたリソース (CPU) に合わせて設計する必要があります。

4.6.1. ホストファームウェアのチューニング
リンクのコピー

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

初期クラスターデプロイメント中に最適なパフォーマンスが得られるようにホストファームウェア設定を調整します。詳細は、「vDU アプリケーションのワークロードに推奨されるシングルノード OpenShift クラスター設定」を参照してください。初期デプロイ時にホストファームウェアにチューニング設定を適用します。詳細は、「GitOps ZTP によるホストファームウェア設定の管理」を参照してください。マネージドクラスターホストのファームウェア設定は、ハブクラスターで個別の BareMetalHost カスタムリソース (CR) として使用できます。この CR は、ClusterInstance CR と GitOps ZTP を使用してマネージドクラスターをデプロイするときに作成されます。

注記

ClusterInstance CR は、指定のリファレンス CR example-sno.yaml に基づいて作成してください。

制限と要件
  • ホストファームウェア設定でハイパースレッディングを有効にする必要があります。
エンジニアリングに関する考慮事項
  • パフォーマンスを最大限に高めるために、すべてのファームウェア設定を調整します。
  • 省電力用に調整されていない限り、すべての設定は最大のパフォーマンスが得られるものと予想されます。
  • 必要に応じて、省電力用にパフォーマンスを犠牲にしてホストファームウェアを調整できます。
  • Secure Boot を有効にします。セキュアブートを有効にすると、署名されたカーネルモジュールのみがカーネルによってロードされます。ツリー外のドライバーはサポートされていません。

4.6.2. Kubelet 設定
リンクのコピー

一部の CNF ワークロードは、システム全体の安全な sysctl のリストではない sysctl を利用します。通常、ネットワーク sysctl には namespace が使用され、以下の形式で、PerformanceProfile カスタムリソース(CR)の kubeletconfig.experimental アノテーションを使用して有効にすることができます。

allowedUnsafeSysctls を示すスニペット例

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: {{ .metadata.name }}
  annotations:kubeletconfig.experimental: |
      {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
# ...
Copy to Clipboard Toggle word wrap

注記

これらの sysctl には namespace が使用されますが、Pod は Pod の記述で指定される制限を超えてメモリーやその他のリソースを消費することを可能にします。これらの sysctl がプラットフォームリソースが枯渇しないようにする必要があります。

詳細は、コンテナーでの sysctl の使用を参照してください。

4.6.3. CPU パーティショニングとパフォーマンスチューニング
リンクのコピー

このリリースの変更点

  • PerformanceProfile オブジェクトおよび TunedPerformancePatch オブジェクトが更新され、aarch64 アーキテクチャーを完全にサポートするようになりました。

    • 以前 TunedPerformancePatch オブジェクトに追加のパッチを適用した場合は、代わりに ran-du-performance プロファイルを含む新しいパフォーマンスプロファイルに、これらのパッチを変換する必要があります。エンジニアリングに関する考慮事項セクションを参照してください。
説明
RAN DU 使用モデルには、低レイテンシーのパフォーマンスに PerformanceProfile CR を使用したクラスターパフォーマンスチューニングと、RAN 固有のチューニングを追加する TunedPerformancePatch CR が含まれています。x86_64 および aarch64 CPU アーキテクチャーの両方に、参照 PerformanceProfile が提供されます。提供された単一の TunedPerformancePatch オブジェクトは、CPU アーキテクチャーを自動的に検出し、必要な追加のチューニングを実行します。RAN DU ユースケースでは、低レイテンシーのパフォーマンスを実現するためにクラスターをチューニングする必要があります。Node Tuning Operator は、PerformanceProfile および TunedPerformancePatch CR を調整します。

PerformanceProfile CR を使用したノードのチューニングの詳細は、「パフォーマンスプロファイルを使用した低レイテンシーを実現するためのノードのチューニング」を参照してください。

制限と要件

通信事業者 RAN DU プロファイルの PerformanceProfile CR で次の設定を設定する必要があります。

  • x86_64 では、4 以上の予約済みの cpuset を、arch64 上の 4 つのハイパースレッド(2 コア)、以下の CPU のいずれかに 4 つのコアを設定します。

    • 最大のパフォーマンスが得られるようにチューニングされたホストファームウェアを備えた Intel 第 3 世代 Xeon (IceLake) 2.20 GHz 以上の CPU
    • AMD EPYC Zen 4 CPU (Genoa、Bergamo)

    • ARM CPU (Neoverse)

      注記

      パフォーマンスへの潜在的な影響を判断するために、Pod ごとの電源管理などの機能を評価することを推奨します。

  • x86_64:

    • 予約済み cpuset を設定し、含まれる各コアの両方のハイパースレッドシブリングを含めます。予約されていないコアは、ワークロードのスケジュールに割り当て可能な CPU として使用できます。
    • ハイパースレッドシブリングが予約済みコアと分離されたコアに分割されていないことを確認します。
    • 予約済みおよび分離された CPU に、CPU 内の全コアの全スレッドが含まれていることを確認します。
    • 予約済み CPU セットに各 NUMA ノードの Core 0 を含めます。
    • hugepage サイズを 1G に設定します。

  • aarch64:

    • 予約 CPU セットには最初の 4 コアを使用します（以上）。
    • hugepage サイズを 512M に設定します。
  • デフォルトで管理ワークロードパーティションの一部として設定されている OpenShift Container Platform Pod のみを予約済みコアにピニングします。
  • ハードウェアベンダーから推奨されている場合は、hardwareTuning セクションを使用して、予約済み CPU と分離された CPU の最大 CPU 周波数を設定します。
エンジニアリングに関する考慮事項

  • リアルタイム(RT)カーネル

    • x86_64 で完全なパフォーマンスメトリクスに到達するには、x86_64/PerformanceProfile.yaml 設定のデフォルトである RT カーネルを使用する必要があります。

      • 必要に応じて、パフォーマンスに対する影響とともに、RT 以外のカーネルを選択できます。
    • aarch64 では、RAN DU ユースケースでは、aarch64/PerformanceProfile.yaml 設定でのデフォルトである 64k-pagesize 非RT カーネルのみが推奨されます。
  • 設定する huge page の数は、アプリケーションのワークロード要件によって異なります。このパラメーターの変動は予想され、許容されます。
  • 選択したハードウェアとシステムで使用されている追加コンポーネントに基づいて、予約済みおよび分離された CPU セットの設定が変更されることが予想されます。この変更が指定の制限を満たしている必要があります。
  • IRQ アフィニティーをサポートしていないハードウェアは、分離された CPU に影響します。CPU 全体が保証される QoS を持つ Pod で、割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートしている必要があります。
  • ワークロードの分割を有効にするには、デプロイ中に cpuPartitioningMode を AllNodes に設定し、PerformanceProfile CR を使用してオペレーティングシステム、割り込み、および OpenShift Container Platform Pod をサポートするのに十分な CPU を割り当てます。
  • x86_64 では、PerformanceProfile CR には、vfio_pci 用の追加のカーネル引数設定が含まれています。この引数は、FEC アクセラレーターなどのデバイスをサポートするために含まれています。ワークロードに必要ない場合には除外できます。

  • aarch64 では、プラットフォームのニーズに応じて PerformanceProfile を調整する必要があります。

    • Grace Hopper システムには、次のカーネルコマンドライン引数が必要です。

      • acpi_power_meter.force_cap_on=y
      • module_blacklist=nouveau
      • PCI=realloc=off
      • PCI=pcie_bus_safe
    • 他の ARM プラットフォームの場合は、iommu.passthrough=1 または pci=reallocを有効にする必要がある場合があります。

  • 拡張および拡張 TunedPerformancePatch.yaml:

    • TunedPerformancePatch.yaml では、ran-du-performance と、ran-du-performance -architecture-common という名前のアーキテクチャー対応の RAN チューニングプロファイルと、共通 ポリシーによって自動的に選択される追加の archichitecture 固有の子ポリシーというデフォルトのトップレベル tuned プロファイルが導入されています。
    • デフォルトでは、rust-du-performance プロファイルは 優先度 18 に設定され、PerformanceProfile で作成されたプロファイル openshift-node-performance-openshift-node-performance-profile と ran-du-performance -architecture-commonの両方が含まれます。

    • PerformanceProfile オブジェクトの名前をカスタマイズした場合は、PerformanceProfile CR によって作成された tuned プロファイルの名前の変更と ran-du-performance-architecture-common RAN チューニングプロファイルを含むチューニングされたオブジェクトを新たに作成する必要があります。優先度 は 18 未満でなければなりません。たとえば、PerformanceProfile オブジェクトの名前が change-this-name の場合には、次のようにします。 

      apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: custom-performance-profile-override
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
    - name: custom-performance-profile-x
      data: |
        [main]
        summary=Override of the default ran-du performance tuning to adjust for our renamed PerformanceProfile
        include=openshift-node-performance-change-this-name,ran-du-performance-architecture-common
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: "master"
      priority: 15
      profile: custom-performance-profile-x
      Copy to Clipboard Toggle word wrap
    • さらに上書きするには、オプションの TunedPowerCustom.yaml 設定ファイルには、オーバーレイしたり、直接編集したりせずに、提供された TunedPerformancePatch.yaml を拡張する方法が示されます。ran-du-performance という名前の最上位 tuned プロファイルを含む追加の tuned プロファイルを作成すると、推奨 セクションで 優先順位 が低くなり、追加の設定を簡単に追加できます。
    • Node Tuning Operator についての詳細は、ノードチューニング Operator の使用を参照してください。

4.6.4. PTP Operator
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
クラスターノードで Precision Time Protocol (PTP)を設定します。PTP は、NTP などの他のクロック同期プロトコルと比較して、RAN 環境の正確なタイミングと信頼性を確保します。
サポートには以下が含まれます
  • Grandmaster clock (T-GM): GPS を使用してローカルクロックを同期し、他のデバイスに時刻同期を提供します。
  • 境界クロック(T-BC): 別の PTP ソースから時刻を受信し、それを他のデバイスに再配布します。
  • 通常のクロック(T-TSC): 別の PTP タイムプロバイダーからローカルクロックを同期します。

設定の変更により、より長い時間分散および高可用性(HA)のための複数の NIC 設定が可能になり、HTTP を介したオプションの高速イベント通知が可能になります。

制限と要件

  • 次の telco のユースケースの PTP G.8275.1 プロファイルをサポートします。

    • T-GM のユースケース：

      • 最大 3 Westport チャネル NIC に制限されます。
      • 追加の NIC を同期するために、SMA 接続で 1 つの NIC カードに GNSS 入力が必要です。
      • HA サポート N/A

    • T-BC のユースケース：

      • 最大 2 つの NIC に制限されます。
      • システムクロック HA サポートは、2-NIC 設定では任意です。

    • T-TSC のユースケース：

      • 単一の NIC のみに限定されます。
      • システムクロック HA サポートは、アクティブ/スタンバイ 2 ポート設定では任意です。
  • ログ削減は、true または 強化された 状態で有効にする必要があります。
エンジニアリングに関する考慮事項
  • RAN DU RDS の設定は、通常クロック、境界クロック、グランドマスタークロック、および高可用性デュアル NIC 境界クロック用に提供されています。
  • PTP 高速イベント通知は、ConfigMap CR を使用してサブスクライバーの詳細を保持します。
  • O-RAN 仕様で説明されている階層型イベントサブスクリプションは、PTP イベントではサポートされていません。
  • PTP 高速イベント REST API v1 はライフサイクルが終了しました。

4.6.5. SR-IOV Operator
リンクのコピー

このリリースの変更点
説明
SR-IOV Operator は、SR-IOV CNI およびデバイスプラグインをプロビジョニングおよび設定します。netdevice (カーネル VF) デバイスと vfio (DPDK) デバイスの両方がサポートされており、RAN DU 使用モデルに適用できます。
制限と要件
  • OpenShift Container Platform でサポートされているデバイスを使用します。詳細は、「サポート対象のデバイス」を参照してください。
  • ホストファームウェア設定での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウン検出が必要な場合は、プロトコルレベルでこれを設定する必要があります。
エンジニアリングに関する考慮事項
  • vfio ドライバータイプの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーションで追加のセカンダリーネットワークを有効にするために使用されます。
  • SriovNetwork および SriovNetworkNodePolicy カスタムリソース (CR) の設定と数は、顧客によって異なることが予想されます。
  • IOMMU カーネルのコマンドライン設定は、インストール時に MachineConfig CR で適用されます。これにより、SriovOperator CR がノードを追加するときにノードの再起動が発生しなくなります。
  • 並列でノードをドレインするための SR-IOV サポートは、シングルノードの OpenShift クラスターには適用されません。
  • デプロイメントに SriovOperatorConfig CR を含める必要があります。この CR は自動的に作成されません。この CR は、初期デプロイ時に適用されるリファレンス設定ポリシーに含まれています。
  • ワークロードを特定のノードにピニングまたは制限する場合、SR-IOV 並列ノードドレイン機能によって Pod の再スケジュールが行われません。このような場合、SR-IOV Operator によって並列ノードドレイン機能が無効化されます。
  • セキュアブートまたはカーネルロックダウン中のファームウェア更新をサポートしていない NIC は、アプリケーションワークロードに必要な Virtual Function (VF) の数をサポートするのに十分な VF で事前に設定する必要があります。Mellanox NIC の場合、SR-IOV Network Operator で Mellanox ベンダープラグインを無効にする必要があります。詳細は、「セキュアブートが有効な場合における Mellanox カードでの SR-IOV Network Operator の設定」を参照してください。

  • Pod の起動後に Virtual Function の MTU 値を変更する場合、SriovNetworkNodePolicy CR の MTU フィールドを設定しないでください。代わりに、Network Manager を設定するか、カスタムの systemd スクリプトを使用して、Physical Function の MTU を適切な値に設定します。以下に例を示します。 

    # ip link set dev <physical_function> mtu 9000
    Copy to Clipboard Toggle word wrap

4.6.6. ロギング
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
ロギングを使用して、リモート分析のためにファーエッジのノードからログを収集します。推奨されるログコレクターは Vector です。
エンジニアリングに関する考慮事項
  • たとえば、インフラストラクチャー以外のログや、アプリケーションワークロードからの監査ログを処理するには、ロギングレートの増加に応じて CPU とネットワーク帯域幅の追加が必要になります。
  • OpenShift Container Platform 4.14 以降では、Vector がリファレンスログコレクターです。RAN 使用モデルでの fluentd の使用は非推奨です。

4.6.7. SRIOV-FEC Operator
リンクのコピー

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

  • FEC Operator v2.7.0 以降:

    • セキュアブートがサポートされています。
    • PF の vfio ドライバーでは、Pod に注入される vfio-token を使用する必要があります。Pod 内のアプリケーションは、EAL パラメーター --vfio-vf-token を使用して VF トークンを DPDK に渡すことができます。
エンジニアリングに関する考慮事項
  • SRIOV-FEC Operator は、分離された CPU セットの CPU コアを使用します。
  • たとえば、検証ポリシーを拡張することによって、アプリケーションデプロイメントの事前チェックの一部として FEC の準備を検証できます。

4.6.8. Lifecycle Agent
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Lifecycle Agent は、シングルノード OpenShift クラスターのイメージベースのアップグレードを実行するためのローカルのライフサイクル管理サービスを提供します。イメージベースのアップグレードは、シングルノード OpenShift クラスターに推奨されるアップグレード方法です。
制限と要件
  • Lifecycle Agent は、マルチノードクラスターまたは追加のワーカーを持つシングルノードの OpenShift クラスターには適用されません。
  • Lifecycle Agent には、クラスターのインストール時に作成する永続ボリュームが必要です。

パーティション要件の詳細は、「GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定」を参照してください。

4.6.9. Local Storage Operator
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Local Storage Operator を使用して、アプリケーションで PVC リソースとして使用できる永続ボリュームを作成できます。作成する PV リソースの数とタイプは、要件によって異なります。
エンジニアリングに関する考慮事項
  • PV を作成する前に、PV CR のバッキングストレージを作成します。これは、パーティション、ローカルボリューム、LVM ボリューム、または完全なディスクにすることができます。
  • ディスクとパーティションが正しく割り当てられていることを確認するには、各デバイスへのアクセスに使用されるハードウェアパス別に LocalVolume CR 内のデバイスリストを参照します (例: /dev/disk/by-path/<id>)。論理名 (例: /dev/sda) は、ノードの再起動後も一貫性が保たれるとは限りません。

4.6.10. Logical Volume Manager Storage
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
論理ボリュームマネージャー (LVM) ストレージはオプションのコンポーネントです。アプリケーションが永続ボリューム要求 (PVC) リソースとして使用できる論理ボリュームをローカルデバイスから作成することにより、ブロックストレージとファイルストレージの両方の動的なプロビジョニングを提供します。ボリューム拡張やスナップショットも可能です。設定例は、RDS の StorageLVMCluster.yaml ファイルで提供されています。
制限と要件
  • シングルノードの OpenShift クラスターでは、永続ストレージは LVM ストレージまたはローカルストレージのいずれかによって提供される必要があり、両方によって提供される必要はありません。
  • ボリュームスナップショットはリファレンス設定から除外されます。
エンジニアリングに関する考慮事項
  • LVM Storage は、RAN DU ユースケースのローカルストレージ実装として使用できます。LVM Storage をストレージソリューションとして使用すると、Local Storage Operator が置き換えられ、必要な CPU がプラットフォームのオーバーヘッドとして管理パーティションに割り当てられます。リファレンス設定には、これらのストレージソリューションのいずれか 1 つを含める必要がありますが、両方を含めることはできません。
  • ストレージ要件を満たす十分なディスクまたはパーティションが利用可能であることを確認します。

4.6.11. ワークロードパーティショニング
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
ワークロードパーティショニングは、DU プロファイルに含まれる OpenShift Container Platform Pod と Day 2 Operator Pod を予約済み CPU セットにピニングし、予約済み CPU をノードの計算から除外します。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。ワークロードパーティショニングは、インストールパラメーターの機能セット cpuPartitioningMode: AllNodes によって有効化されます。管理パーティションコアのセットは、PerformanceProfile CR で設定する予約済み CPU セットを使用して設定されます。
制限と要件
  • Pod を管理パーティションに適用できるようにするには、Namespace と Pod CR にアノテーションを付ける必要がある
  • CPU 制限のある Pod をパーティションに割り当てることはできません。これは、ミューテーションによって Pod の QoS が変わる可能性があるためです。
  • 管理パーティションに割り当てることができる CPU の最小数の詳細は、「Node Tuning Operator」を参照してください。
エンジニアリングに関する考慮事項
  • ワークロードパーティショニングは、すべての管理 Pod を予約済みコアにピニングします。オペレーティングシステム、管理 Pod、およびワークロードの開始、ノードの再起動、またはその他のシステムイベントの発生時に発生する CPU 使用率の予想される急増を考慮して、予約セットに十分な数のコアを割り当てる必要があります。

4.6.12. クラスターのチューニング
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
クラスター機能を使用して無効にできるコンポーネントの完全なリストは、「クラスター機能」を参照してください。
制限と要件
  • インストーラーによるプロビジョニングのインストール方法では、クラスター機能は使用できません。

次の表に、必要なプラットフォームチューニング設定を示します。

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

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

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

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

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

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

  • ローカルの alertmanager コンポーネントおよび telemeter コンポーネントを無効にします。
  • RHACM の可観測性を使用する際、アラートをハブクラスターに転送するには、適切な additionalAlertManagerConfigs CR で CR を拡張する必要があります。
  • RHACM 可観測性は、デフォルトのデータ値を、クラスターチューニング参照 CR の一部として提供されるモニタリング設定 ConfigMap CR を組み合わせたものです。このマージの結果、ポリシーはコンプライアンス違反になります。指定された設定が RHACM データ値を上書きまたはマージされないようにするには、この ConfigMap CR の RHACM 管理を無効にできます。これにより、ポリシーが準拠した状態に保たれます。詳細は、Telco ハブ参照仕様の可観測性セクションを参照してください。

  • Prometheus の保持期間を 24 時間に短縮します。

    注記

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

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

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

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

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

Console Operator を無効にする

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

エンジニアリングに関する考慮事項

4.6.13. マシン設定
リンクのコピー

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
制限と要件
  • CRI-O ワイプ無効化 MachineConfig CR は、定義されたメンテナンス期間内のスケジュールされたメンテナンス時以外は、ディスク上のイメージが静的であると想定します。イメージが静的になるように、Pod の imagePullPolicy フィールドを Always に設定することは避けてください。
  • この表の設定 CR は、特に記載がない限り必須のコンポーネントです。
Expand
表4.5 マシン設定オプション
機能説明

コンテナーランタイム

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

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

kubelet のハウスキーピングとエビクションモニタリングの頻度を減らし、CPU 使用率を削減します。

SCTP

任意の設定 (デフォルトで有効)

Kdump

オプション設定 (デフォルトで有効): カーネルパニックが発生したときに kdump がデバッグ情報をキャプチャーできるようにします。kdump を有効にするリファレンス CR では、リファレンス設定に含まれるドライバーとカーネルモジュールのセットに基づいて、メモリー予約量が増加します。

CRI-O ワイプ無効化

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

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

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

RCU Normal の設定

システムの起動が完了した後に rcu_normal を設定する systemd サービス

ワンショット時間同期

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat