VMを移動したら通信が切れる。それが「常識」だったはずだ
サーバーの引っ越し作業には、いつも一瞬の「痛み」が伴う。物理サーバーであれ仮想マシン（VM）であれ、稼働中のワークロードを別のホストに移動させれば、TCPセッションは途切れ、クライアントは再接続を強いられる。これがインフラ運用の当たり前の前提だった。
ところが、KubernetesのエコシステムでVMを動かす仕組みであるKubeVirtと、そのネットワークを担うCalicoを組み合わせると、この前提そのものが崩れる。ノードを跨いでVMをライブマイグレーションしても、TCPのシーケンス番号は途切れず、クライアントとの接続は維持されたままになる。
この記事では、KubeVirt ライブマイグレーションがなぜ通信を切らずに実現できるのか、CalicoのIP永続化の仕組みと、VMware移行先の選択肢としての実務的な意味を整理する。
KubernetesがPodに割り当てるIPは「使い捨て」が前提だった
まず、なぜこれが技術的に「驚き」なのかを理解するために、Kubernetesの標準的な挙動を確認しておく。
Kubernetesのデフォルトのネットワークモデルでは、Podが再作成されるたびに、クラスタのPod CIDRプールから新しいIPアドレスが割り当てられる。コンテナワークロードにとってこれは合理的な設計だ。Podは基本的にステートレスであり、Service やIngressの背後に隠れているため、IPアドレス自体が変わっても支障はない。
しかしVMはそうはいかない。VM内部で動くアプリケーションは、固定IPを前提にTCP接続を張っていたり、他システムからそのIPで直接名指しでアクセスされていたりする。KubernetesのPodと同じ感覚でVMのIPを毎回使い捨てにすると、移行のたびにVM内のサービスが停止してしまう。
CalicoはVM名でIPを「縛る」
この問題を解くのがCalicoのIPAM（IPアドレス管理）の工夫だ。Calico公式ドキュメントによれば、CalicoはKubeVirtのVMをブリッジバインディングモードでPodネットワークに接続し、VMはCalicoがPodに割り当てたものと同じIPアドレスを使用する。ポイントは、そのIP予約の紐付け先が「Pod名」ではなく「VM（VMI）の識別情報」になっている点だ。
Tigera（Calico開発元）のブログでも、Kubernetesのデフォルトのポッドネットワーキング（クラスタのPod CIDRから新しいIPを割り当てる方式）に頼るのではなく、VMの元のレイヤー2セグメント（IPアドレス・VLAN・MACアドレス）をノードレベルのブリッジ経由でクラスタに直接持ち込む手法が解説されている。これにより、Podが再作成されても、あるいはノードを跨いで移行しても、同一のVMには一貫して同じIPアドレスが結びつく。
TCP接続は本当に途切れないのか — GARPとルート収束の裏側
「同じIPが維持される」ことと、「通信が途切れない」ことは、実は別の話だ。IPが同じでも、そのIP宛のパケットが正しく新しいノードに届かなければ意味がない。ここで効いてくるのが、ルーティングの収束スピードだ。
Tigeraのブログ「KubeVirt Live Migration Done Right」が解説する仕組みはこうだ。
- VMが宛先ノードで起動を完了すると、VM自身が「このIPは私が所有しており、このノードにいる」と宣言するGratuitous ARP（GARP）パケットをブロードキャストする
- CalicoのデータプレーンエージェントであるFelixがこのGARPを検知し、宛先ノード経由でそのVMのIP宛の高優先度ルートを即座にBGPでアドバタイズする
- 移行中は送信元・宛先の両ノードが一時的に同じIPのルートを保持するが、宛先ノードのルートには高いメトリック優先度が設定されているため、トラフィックは送信元Podが完全にクリーンアップされる前から新しいノードへ転送され始める
この「優先度による上書き」戦略により、TCPのシーケンス番号が途切れることなく、クライアントとの接続を維持したまま移行が完了する。ちなみに、ライブマイグレーションが機能するためには構成上の前提条件があり、CalicoはブリッジバインディングモードかつオーバーレイなしのBGPネットワーキングを要求する。VXLANやIP-in-IPといったオーバーレイ方式は現時点では未対応で、将来のリリースでの対応が予定されている。
なぜ「Felix」がこの役割を担えるのか
Felixは各ノードに常駐するデータプレーンエージェントで、通常はルーティングテーブルの管理やネットワークポリシーの適用を担っている。VM移行のようなイベント駆動の処理も、この常駐エージェントが既にノード単位で稼働しているからこそ、追加のオーケストレーション層なしに素早く反応できる。CNIレベルでKubernetes APIの移行イベントを監視し、VMが実際に移動する前から宛先ノードのネットワーク設定（ポリシー・ルート・インターフェース）を先回りして準備しておく設計になっている。
なぜ今KubeVirtが注目されるのか — VMware値上げという現実
技術的な面白さだけでなく、KubeVirtが急速に存在感を増している背景には、はっきりとしたビジネス上の事情がある。
Broadcomが2023年末に約690億ドルでVMwareを買収して以降、NextPlatformの報道によれば、ライセンス価格が300〜1,000パーセント上昇し、永続ライセンスからサブスクリプション型へのシフトが進んだ。これを受けて多くの顧客がNutanixやRed Hatなど競合の仮想化基盤を検討し始めている。Broadcom自身もこの顧客離反への対抗策として、VMware Cloud Foundation（VCF）にKubernetesサポートを強化し、CNCF関連プロジェクトの統合を進めている状況だ。
こうした流れの中で、KubeVirtは「レガシーVM資産をコード変更なしにKubernetes上へ持ち込む」選択肢として存在感を増している。Cloudflareの技術ブログでは、大規模障害シミュレーションのための仮想クラスタ構築、開発者向けのネットワークエミュレーション環境、カーネル開発者向けの検証環境、ビルドパイプライン用のスケーラブルなVM群など、コンテナだけでは代替しづらい用途にKubeVirtを本番活用している事例が紹介されている。マネージドKubernetesサービスを提供するCivoも、自社のスーパークラスタ基盤上でKubeVirtを稼働させることで、コンテナとVMのワークロードを単一の統合インフラで管理している。
プロジェクトの成熟度という観点でも、KubeVirtは着実に前進している。CNCFの公式ブログは2026年3月にリリースされたv1.8で、機密仮想マシン向けのIntel TDX対応や、複数ハイパーバイザーバックエンドへの対応拡大を報告している。SiliconAngleの報道によれば、KubeVirtは現在CNCFのIncubatingステータスからGraduation（卒業）を目指しており、Nvidia・Intel・AMDといったチップメーカーや、IBM・Microsoft・Red Hatなど大手企業がクロスインダストリーで開発に貢献している。
とはいえ、導入すれば万事解決というわけではない。Spectro Cloudの分析は、ブリッジネットワークでのライブマイグレーション中のネットワーク中断、CNIプラグインとの組み合わせによるMACアドレス割り当ての問題、VM内部の観測性ギャップなど、本番運用に伴う現実的な課題も指摘している。同調査では、ユーザーの45%が永続ストレージの設定に、43%がVM形式の変換作業に苦労していると報告されている。ネットワーク設計を正しく組めば通信は途切れないが、そこに至るまでの構成・運用ノウハウの蓄積は決して軽くない。
標準Kubernetesだからこそ実現できる設計
ここまで見てきたIP永続化・BGPルート収束の仕組みは、KubeVirtやCalico単体の特別な機能ではなく、CNCFエコシステムの中で標準化されたコンポーネント同士が連携することで成立している。VMとコンテナが同じKubernetesクラスタ上で共存し、しかも移行時にネットワークが切れないという設計は、独自仕様のプロプライエタリな仮想化基盤では実現しにくい。標準K8s・CNCFエコシステムに準拠しているからこそ手に入る恩恵だ。
こうしたCNCF認定のエコシステムをそのまま活用できる基盤として、K3sベースのマネージドKubernetesであるKuboがある。EKSやAKSのような高コスト・高複雑性・ベンダーロックインの三重苦を抱えることなく、標準Kubernetesの機能をそのまま使える設計思想は、この記事で解説したネットワーク設計とも地続きだ。
VMware資産のライセンス値上げに直面し、Kubernetesベースの基盤への移行を検討しているインフラエンジニアであれば、Kubo CloudがPure Kubernetes（標準K8s・ベンダーロックインなし）を掲げている点は参考になるはずだ。AWS/Azureの知識やこれまでの資産をそのまま活かしながら、EKS比で大幅にコストを抑えた運用が可能になる。
一方で、金融・医療・製造業など、VM資産を含むワークロードをデータ主権の制約下で運用する必要がある組織には、Kubo On-Premiseという選択肢もある。Air-Gapped環境への対応や完全自社管理を前提とした設計は、VMware資産をオンプレミスで維持しながらKubernetesエコシステムへ段階的に移行したいケースに向いている。
まとめ
KubernetesにおけるVMのライブマイグレーションは、単に「VMをコンテナと同じ場所で動かせるようになった」という話にとどまらない。CalicoのIP永続化、GARPによる即時通知、Felixによる高優先度BGPルート広報という、複数のコンポーネントが精密に連携することで初めて「通信を切らない移行」が実現している。
同時に、VMware買収後のライセンス値上げという外部要因が、この技術への関心を後押ししている現実もある。ネットワーク設計の正しさと、移行に伴う運用ノウハウの両方を理解した上で選択肢を検討することが、この分野で失敗しないための前提条件になる。
標準Kubernetesのエコシステムをそのまま活かせる基盤を探しているなら、Kuboのお問い合わせから相談してみるのも一つの選択肢だ。