第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 のネットワーク再設定のステージ
- 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を設定することはできません。 - 作成されるルーティングテーブルに、設定されたゲートウェイを経由するデフォルトルートと、重複または競合するルートを含めることはできません。
- クラスターではプロキシーネットワーク設定を使用できません。
- イメージベースのアップグレードとネットワーク再設定を同時に実行することはできません。