第18章 シングルノード OpenShift のネットワーク再設定


18.1. シングルノード OpenShift のネットワーク再設定について

Lifecycle Agent を使用すると、完全な再デプロイを実行しなくても、シングルノード OpenShift クラスターのネットワーク設定を変更できます。これは、障害復旧や接続先ネットワークの切り替えなど、多くのエッジコンピューティングのユースケースにとって非常に重要です。

18.1.1. シングルノード OpenShift のネットワーク再設定のユースケース

ネットワークのファーエッジにおいて、シングルノード OpenShift クラスターのコアネットワークを変更することは、多くのシナリオで不可欠な操作です。

たとえば、障害復旧、モバイルデプロイメント、ネットワーク移行などの際には、ノードの IP アドレス、ゲートウェイ、DNS サーバー、VLAN 設定を変更する必要が生じる場合があります。しかし、これらの操作は高いリスクを伴います。設定ミスによってクラスターにアクセスできなくなり、完全な再デプロイが必要になる可能性があるためです。

Lifecycle Agent は、IPConfig カスタムリソース (CR) を使用して、クラスター全体を再デプロイすることなく、これらの変更を安全に実行する宣言的なステージ駆動型ワークフローを提供します。

以下のユースケースは、シングルノード OpenShift のネットワーク再設定の主要なシナリオを示しています。

障害復旧
サイトの障害や大規模な接続変更の後、シングルノード OpenShift クラスターは、場合によって別のアップリンクネットワークに移行する必要があります。たとえば、プライマリーの 5G IPv6 ネットワークがダウンした場合に備えて、IPv4 衛星接続をバックアップとして使用するようにクラスターを再設定することができます。
一時的なモバイルデプロイメント
移動式基地局や新しい基地局などのモバイルインフラストラクチャーは、多くの場合、一時的なネットワーク接続に依存しています。これらのクラスターは、アップリンクネットワーク間を移動する際に再設定できます。
IoT ネットワークの移行
遠隔地に設置された IoT ゲートウェイクラスターは、ISP の切り替えや施設全体の IP アドレス範囲の変更など、基盤となるネットワークインフラストラクチャーが変更された場合に再設定できます。
ネットワーク統合と機器のアップグレード
ネットワーク統合やインフラストラクチャーのアップグレードの際に、シングルノード OpenShift クラスターを、決定論的で可逆的なプロセスと最小限のダウンタイムで、新しい L2 または L3 環境に移行できます。

18.1.2. シングルノード OpenShift のネットワーク再設定のワークフロー

Lifecycle Agent は、IPConfig CR の spec.stage フィールドによって制御されるステージ駆動型ワークフローを使用します。このワークフローは 3 つのステージで構成されます。

図18.1 シングルノード OpenShift のネットワーク再設定のステージ

シングルノード OpenShift のネットワーク再設定のステージ
Idle ステージ
最初と最後のステージです。このステージでは、Lifecycle Agent がヘルスチェックを実行し、クリーンアップ操作を行い、設定変更のためにクラスターを準備します。設定が正常に完了した後に Idle 状態へ移行することが、ロールバック機能を削除する最終確定ポイントとなります。
Config ステージ
ネットワーク再設定を 2 つのフェーズで実行します。Pre-pivot フェーズでは、新しい stateroot (更新されたネットワーク設定を含む起動可能なシステム状態) を準備し、その状態に再起動します。Post-pivot フェーズでは、ネットワークの変更を適用し、証明書を再生成し、クラスターが安定するまで待機します。
Rollback ステージ

以前の stateroot に再起動します。ロールバックは手動で実行することも、障害発生時に自動的にロールバックするように設定することもできます。

ネットワーク再設定フローでは、新しい stateroot で新しい設定を準備する間、現在起動中の stateroot をロールバックターゲットとして保持します。そのため、変更を確定するまで元の設定をロールバック用に保持でき、IP アドレスの変更に必要な再起動が 1 回だけで済むほか、以前の stateroot がすでに準備されているため、ロールバック処理が高速になります。

18.1.3. サポートされているネットワークプロパティーの変更

IPConfig CR は、以下のネットワークプロパティーの変更をサポートしています。

  • シングルスタックまたはデュアルスタッククラスターの IPv4 および IPv6 アドレスの変更
  • マシンネットワークの CIDR の変更
  • デフォルトゲートウェイの変更
  • DNS サーバーリストの更新
  • br-ex アップリンクパス上のオプションの VLAN ID 変更
  • デュアルスタッククラスターで IPv4 または IPv6 をフィルタリングするための、オプションの DNS 応答フィルタリング設定の変更

18.1.4. ネットワーク再設定に関する要件と制限

IPConfig CR を使用したネットワーク再設定には、以下の要件があります。

  • クラスターが、シングルノード OpenShift クラスターである必要があります。
  • Lifecycle Agent がインストールされている必要があります。
  • ベースラインとなる dnsmasq MachineConfig リソースが存在している必要があります。これは、Agent-based Installer (ABI)、マルチクラスターエンジン (MCE)、Red Hat Advanced Cluster Management (RHACM) など、Assisted Installer によって直接または間接的にインストールされたシングルノード OpenShift によって自動的にインストールされます。
  • ネットワーク再設定を開始する前に、すべてのクラスター Operator が利用可能である必要があります。

IPConfig CR を使用したネットワーク再設定には、以下の制限があります。

  • デュアルスタッククラスターの場合は、ノードごとに 1 つの IPv4 アドレスと 1 つの IPv6 アドレスだけがサポートされています。
  • サポートされている NIC は 1 つだけです。ボンディングやリンクアグリゲーションはサポートされていません。
  • br-ex アップリンクパスでは、最大 1 つの VLAN ID を設定できます。
  • ホストネットワーク上で静的ネットワーク設定を行う必要があります。DHCP はサポートされていません。
  • VLAN 設定がまだ存在しないクラスターに VLAN を追加することはできません。
  • アドレスを変更せずにゲートウェイやマシンネットワークを変更することはサポートされていません。
  • IP アドレスを 1 つ以上変更せずに DNS サーバーを変更することはサポートされていません。
  • IPv6 専用クラスターに spec.ipv4 を設定することや、IPv4 専用クラスターに spec.ipv6 を設定することはできません。
  • 作成されるルーティングテーブルに、設定されたゲートウェイを経由するデフォルトルートと、重複または競合するルートを含めることはできません。
  • クラスターではプロキシーネットワーク設定を使用できません。
  • イメージベースのアップグレードとネットワーク再設定を同時に実行することはできません。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る