Internet Infrastructure Review（IIR）Vol.67
2025年9月

3. フォーカス・リサーチ（1）

脱VMwareへの回答 〜Kubernetesと仮想環境の親密な関係〜

3.1 業界を揺るがすVMware問題

昨年から「脱VMware」を巡る議論が絶えません。曰く、VMwareのライセンス価格が高騰しており他仮想化基盤への見直しを検討すべきだ。曰く、ベンダーの論理が優先され既存顧客がないがしろにされているのではないか。本当でしょうか？

様々な条件が影響するため一概には言えませんが、仮想化市場全体を見渡してニュートラルに評価すれば、同社の行動は主戦場となるスイートパッケージをVMwareにおいても主力に位置付け、顧客をより高付加価値で競争力のあるパッケージへ誘導しようとしている、と見ることができます。見方によっては、競合他社と戦略的な差異が少なくなったと言えるでしょう。特定の他社製品に肩入れするわけではありませんが、ラインナップにしろ、価格にしろ、適正化を図ったと表現しても違和感はないように感じます。もっとも、それに伴っておそらくボリュームゾーンであろうシンプルなパッケージのユーザを中心に大きく割を食うことになり、コスト上昇の影響を被ることになったのは変わらぬ事実です。

そこで対策案を検討するわけですが、安直にライセンス費用だけにフォーカスして代替製品への見直しを検討すれば、期待した結果が得られるかは甚だ疑問です。何しろ、VMwareの製品としての魅力が損なわれたわけではないのですから。バージョンアップによって望まない機能変更が行われたり、信頼が失われるような問題を起こしたのであればともかく、これは純粋にコストの問題です。仮にライセンス費用の面で有利な選択肢を見いだせたとしても、いまだ仮想化市場の第一人者であるVMwareと比較して機能、安定性、将来性、その他多くの要素について遜色のない条件を満たさなければなりません。更に、脱VMwareを実行するには大規模なマイグレーションコストが発生します。ともすれば、そのコストは期待していたコストダウン効果を相殺してしまうかもしれません。

つまり、脱VMwareを成功させるには、コストメリットだけに着目するのではなく、VMware以上に優れたプラットフォームとは何か？を考える必要があるのです。もしそれらを両立させることができれば、ライセンス問題への回答となるだけでなく、プラットフォームの世代交代が自社ビジネスに競争力をもたらすことでしょう。

この非常に困難なチャレンジに対する1つの回答としてIIJが取り組んでいるのが、VMwareからKubernetesへのマイグレーションです。オープンソースを最大限に活用し、自社開発のKubernetesディストリビューションIKE（IIJ Kubernetes Engine）をVMwareの代替に位置付け、大きくライセンスコストを削減すると共に、IaaS層では実現し得ない運用の効率化、品質の向上などを実現するというものです。

3.2 あらゆるワークロードを飲み込むKubernetes

ある程度クラウドネイティブ技術に通じているエンジニアであっても、その多くはKubernetesを「コンテナオーケストレータ」と捉えていると思います。実際、大半のKubernetesはコンテナのオーケストレーションに利用されているはずです。しかし、近年はコンテナに限らずVMのオーケストレータとしても徐々に採用が進んでいることをご存じでしょうか。既に良く知っているという方は相当な通と言えるでしょう。クラウドネイティブの推進者を自認する筆者ですら、技術的には成熟しつつあるものの、実環境での採用まではまだ時間がかかるだろうと感じていたぐらいです。

ところが、VMwareを震源とするプラットフォーム見直し議論の中でKubernetesが最有力後継者へと躍り出ることになり、大きく潮目が変わったように思えます。これはIIJに限った話ではなく、IT業界全体の潮流であるとも感じています。

KubernetesがVMwareの代替プロダクトとして注目を集めるに至った理由は枚挙にいとまがありません。技術的な理由があることはもちろんですが、それ以上に信頼性によるところが大きいように感じます。例えば、Linux Foundationによってベンダーニュートラルに運営され、ベンダーロックインの不安が少ないオープンソースプロジェクトであること。ハードウェアベンダー、ソフトウェアベンダーにかかわらず、広くIT業界全体から支持されエコスシステムが急速に成長していること。その結果、サーバOSにおけるLinuxと同様に、Kubernetesがオーケストレータのデファクトスタンダードと見なされるようになり、長期的な投資を決断できる存在となったこと。そうした積み重ねが信頼を獲得してきたのです。

もっとも、Kubernetesの役割がコンテナのオーケストレータにとどまるのであれば、主流と見なされることはなかったかもしれません。サーバサイドシステムでコンテナの採用が急増しているとはいえ、VMとコンテナのどちらがプライマリであるかと問われれば、現時点では明らかにVMだからです。ただ逆に、将来を考えるとVMしか管理できないプラットフォームがいつまでも主流であり続ける可能性は高くはないでしょう。VMとコンテナを同等のワークロードとして扱うことができるKubernetesに注目が集まるのは必然と言えます。

3.3 IIJにおけるKubernetesプラットフォームIKE

段階的にVMwareからKubernetesへのマイグレーションを進めているIIJですが、早い段階で脱VMwareの手段としてKubernetesを選択できたのは、既にコンテナプラットフォームとしてKubernetesの運用経験を十分に積んでいるからです。もし、脱VMwareを契機に初めてKubernetesの運用に取り組んだのだとしたら、少なからず躊躇したことでしょう。

というのも、Kubernetesの運用ノウハウは一朝一夕に身に付けられるものではないからです。Kubernetesはクラウド時代のOSに例えられるように、サーバ、ネットワーク、ストレージといったシステムリソースに対する調停者です。しかも、OSのように1台のサーバに閉じた制御ではなく、データセンターに収められた大規模なあらゆるシステムが連携して協調するように1つのKubernetesによって管理されます。そのために、Kubernetesは物理的なシステムを隠蔽し、あたかもデータセンターを1つの巨大なリソースプールであるかのように抽象化します。そして、利用者はパブリッククラウドを利用する場合と同じように、あらゆる操作でKubernetesを通じて指示を出すことになります。これこそがKubernetesを活用するモチベーションの1つなのですが、こうして抽象化されたシステムの設計と運用を行うには、熟練のエンジニアであっても既存の知識が十分に生かせるとは限りません。一方、Kubernetesだけに詳しくなったところで、それはオペレーションの能力が身に付くだけで、システムを運用する能力が身に付くわけではありません。Kubernetesを利用しても結局のところ最終的にはハードウェアの制御に行き着くため、Kubernetesへの操作が実システムに対してどのように反映されるのかを理解できなければ、やはり十分な品質での運用は困難だからです。このような話はVMwareのような仮想化基盤を利用しても同様に存在するのですが、Kubernetesはより抽象化のレベルが高い分だけ更に複雑と言えます。

一方、IIJがサービス基盤としてKubernetesを導入したのは2018年のことです。当時はKubernetes v1.9を利用しており、今よりもはるかにシンプルなシステムにすぎませんでした。それが今では23回のアップグレードを施されてv1.32にまで至りました。その間にKubernetesそのものだけでなく、当初から稼働していた多くのプラグインやコントローラ類はアップグレードされたり、差し替えられたりして、初期に存在していたKubernetesクラスタの構成要素のほとんどは跡形もありません。にもかかわらず、古くからこのKubernetesクラスタ上で稼働していた数々のワークロードは、いまだに安定して運用が続けられているのです。

これは非常に重要なポイントです。Kubernetesにはマイナーバージョンアップのたびに数多くの機能が追加されていますが、それでも致命的に互換性が失われるようなことは7年間1度も起きていないことを意味するからです。更に、低レイヤーで見ればハードウェアもソフトウェアも実装は大きく変化しているにもかかわらず、Kubernetes上のシステムへの影響は非常に軽微であったということは、Kubernetesによる抽象化が効果的に機能していることの証明でもあります。これはKubernetesの継続性、安定性、拡張性、将来性が高いレベルで実現されており、今後についても期待ができるということです。

もっとも、それは自然に実現したわけではなく、アップグレードのたびにその内容と影響範囲を詳細に把握し、適切なアップグレードを行ってきた結果です。その過程で蓄積された経験が脱VMwareにおいても大いに役立っています。もちろん、もっと短時間でKubernetesの運用スキルを身に付ける方法はいくらでもあると思いますが、自信が付くにはある程度の時間を要するものです。

3.4 KubernetesでVMを扱う際の課題はネットワークにあり

十分に知見が蓄積されているとはいえ、実のところIIJにとってもKubernetesにVMをデプロイし始めたのはまだ1年前のことです。評価を始めた際にはコンテナ用KubernetesとVM用Kubernetesを設備から分けることも視野に入れていましたが、そのような考慮はまったく不要であることがすぐに分かりました。それどころか、コンテナとVMを用途に応じて使い分け、混在してシステムを構成できることこそがKubernetesのメリットであるとすら言えます。それほどまでにKubevirtによって実現される環境は素晴らしく、誤解を恐れず言えば、Pod（コンテナを起動する際に利用するリソース）をVirtualMachine（VMを起動する際に利用するリソース）に読み替えるだけで、ほとんどのKubernetesの機能をVMに対しても活用可能です。

PodとVirtualMachineを同等のワークロードとして扱えることのメリットは計り知れません。

• Kubernetesが発展していくと、2倍の手間をかけることなく、その恩恵をコンテナでもVMでも享受できる
• オンプレミスでKubernetesを扱う場合、コンテナ用とVM用で設備を分けずに済むため稼働率を高く維持できる
• PodとVirtualMachineは同じネットワーク（pod network）に接続されるため、相互運用が容易
• VMとして構築されていたシステムをコンテナでリプレースすることが容易。VMからコンテナへのマイグレーションパスとしても有用

ただし、脱VMwareの手段としてKubernetesを選択したとき、課題がないわけではありません。既存の多くのKubernetes環境では、Kubernetesクラスタごとに1つだけ用意されたネットワーク（pod network）にすべてのコンテナとVMを接続する構成が一般的です。一方、VMを中心に運用されている環境ではL2ネットワークが複数用意され、アプリケーションごとに独立したネットワークを利用する構成が珍しくありません。Kubernetes上でも同等のネットワークを用意することは可能ですが、今のところ一般的ではありませんし、L2ネットワークの実現手段がインフラに依存したりプロプライエタリなネットワーク製品に依存することも多く、慎重な検討が求められます。複雑なネットワーク構成が求められる場合、既存のKubernetesクラスタの拡張だけでは対応できず、脱VMware専用Kubernetesクラスタを必要とするかもしれません。

ただ、課題らしい課題がネットワークに集中していることは朗報と言えるでしょう。KubernetesユーザにとってもVMを利用するために身に付けるべきスキルは本当に少なく、ごくわずかなトレーニングだけで利用可能です。運用する立場としてはそうもいきませんが、プラットフォームエンジニアだけが苦労すれば済むのであればむしろ冥利に尽きるというものです。

脱VMwareはまだ道半ばではありますが、Kubernetesが1つの回答になり得るのは間違いありません。ただし、要件がワークロードごとに千差万別であることは言うまでもなく、正しい選択が複数存在することもまた間違いありません。お客様へ価値あるサービスをご提供するに当たり、固定観念にとらわれず、最適な選択をしていきたいものです。

3. フォーカス・リサーチ（1）
脱VMwareへの回答 〜Kubernetesと仮想環境の親密な関係〜

• 3.1 業界を揺るがすVMware問題
• 3.2 あらゆるワークロードを飲み込むKubernetes
• 3.3 IIJにおけるKubernetesプラットフォームIKE
• 3.4 KubernetesでVMを扱う際の課題はネットワークにあり