Kubernetes を前提とした仮想化アーキテクチャ – VM とコンテナの責務を分ける

Kubernetes が一般化したことで、インフラ設計では「仮想マシンを使うのか、コンテナを使うのか」という話になりがちです。

しかし、実際の基盤設計では、VM と Kubernetes は単純な競合関係ではありません。多くの環境では、物理サーバー、仮想化基盤、仮想マシン、OS、Kubernetes、コンテナ、アプリケーションが階層として重なります。

重要なのは、どちらを選ぶかではありません。どの層を主語にして、どの責務をどこに持たせるかです。

VM と Kubernetes を対立させない

仮想マシンは、OS 単位の境界を作る技術です。カーネル、ネットワーク設定、ディスク、セキュリティ境界、障害範囲を VM 単位で分けられます。

Kubernetes は、アプリケーションの配置、再起動、スケール、Service、ConfigMap、Secret、Ingress、Pod 間通信などを扱うための基盤です。つまり、OS より上のアプリケーション運用を標準化する層です。

このため、VM と Kubernetes は同じ問題を解いているわけではありません。VM はノードや境界を作り、Kubernetes はその上でアプリケーションを運用する、と考える方が自然です。

何を主語にするかで見え方が変わる

Kubernetes を前提とした仮想化アーキテクチャでは、何を主語にするかで抽象と具体が変わります。

主語	VM の見え方	Kubernetes の見え方
物理基盤	物理リソースを分割する単位	VM 上で動く上位の運用基盤
VM 基盤	OS とノード境界を作る単位	VM 群の上に載るアプリケーション基盤
Kubernetes	Node を構成する実体	Pod / Service / CNI / CSI を扱う主役
アプリケーション	直接は見えにくい下位基盤	デプロイ、スケール、設定、サービス公開の単位

同じ VM でも、物理基盤を主語にすればリソース分割の単位です。Kubernetes を主語にすれば Node の実体です。アプリケーションを主語にすれば、普段は直接意識しない下位基盤になります。

そのため、VM と Kubernetes の関係を考える時は、どのレイヤーを主語にしているのかを明確にする必要があります。主語が曖昧なまま議論すると、VMware 代替なのか、Kubernetes の拡張なのか、アプリケーション運用基盤なのかが混ざります。

仮想化は抽象化であり責務境界である

仮想化とは、単に仮想マシンを動かすことではありません。複雑な物理構造や運用対象を、扱いやすい単位に置き換える抽象化です。

VLAN は物理ネットワークを論理的に分けます。LVM は物理ディスクを論理ボリュームとして扱います。KVM は物理サーバーを複数の仮想マシンに分けます。Kubernetes は複数ノード上のコンテナを、宣言的なリソースとして扱います。

抽象化が増えるほど柔軟になりますが、同時に、どの層が何を保証し、どの層が何を保証しないのかを見失いやすくなります。仮想化は便利な隠蔽ではありますが、責務境界でもあります。

層ごとに責務を分ける

Kubernetes を前提にした仮想化アーキテクチャでは、責務を層ごとに分けて考える必要があります。

層	主な責務
物理レイヤ	電源、筐体、CPU、メモリ、ディスク、NIC、配線、冷却を扱う。
仮想化レイヤ	KVM、VMware、OpenStack などで VM の配置、リソース、仮想ネットワークを扱う。
OS レイヤ	各ノードのカーネル、パッケージ、時刻同期、名前解決、証明書、ログを扱う。
Kubernetes レイヤ	Pod、Service、Ingress、CNI、CSI、Secret、Deployment などを扱う。
アプリケーションレイヤ	実際のサービス、データ、設定、リリース、監視観点を扱う。

この分離が曖昧になると、Kubernetes で解くべきではない問題を Kubernetes に押し込んだり、VM 側で解くべき問題をアプリケーション側に漏らしたりします。

Kubernetes ノードを VM にする意味

Kubernetes ノードを物理サーバーに直接構築することもできます。しかし、VM 上に Kubernetes ノードを作る構成にはいくつかの利点があります。

• ノード単位の作成、削除、再作成がしやすい
• コントロールプレーン、ワーカー、検証用ノードを分けやすい
• VM テンプレートや構成管理によって再現性を高めやすい
• 障害検証や構成変更を VM 単位で試しやすい
• 物理ホストと Kubernetes ノードの責務を分離しやすい

一方で、VM の上に Kubernetes を載せると、ネットワーク、ストレージ、性能の見通しは複雑になります。Pod の通信が、CNI、VM の仮想 NIC、仮想スイッチ、物理 NIC を経由するため、どの層で問題が起きているかを切り分ける力が必要になります。

VM 上の Kubernetes は過剰に見えることもあります。しかし、ノードを作り直す、検証する、境界を分ける、構成を再現するという観点では、かなり自然な設計になります。

ネットワークはどの層を主語に見るか

Kubernetes を前提にした仮想化アーキテクチャで難しくなりやすいのはネットワークです。物理ネットワーク、仮想スイッチ、VM の NIC、Linux bridge、OVS、OVN、Kubernetes CNI、Service、Ingress が重なります。

Pod 間通信を主語にすれば CNI の話に見えます。しかし、VM を主語にすれば仮想 NIC、仮想スイッチ、MTU、ルーティングの話になります。物理基盤を主語にすれば VLAN、L2 / L3、Firewall、経路制御の話になります。

ここで大事なのは、すべてを Kubernetes の中だけで理解しようとしないことです。Pod 間通信の問題に見えても、実際には VM の仮想 NIC、MTU、ルーティング、DNS、Firewall、ロードバランサー相当の設計が原因になることがあります。

Kubernetes は強力ですが、下位レイヤの問題を消すわけではありません。むしろ、下位レイヤを正しく設計した上で、その上にアプリケーション運用の抽象化を重ねる技術です。

ストレージは PVC だけでは終わらない

ストレージも同じです。Kubernetes では PV、PVC、StorageClass、CSI といった抽象化がありますが、その背後にはローカルディスク、NFS、Ceph、外部ストレージ、バックアップ設計があります。

アプリケーションから見ると PVC は単なる永続ボリュームに見えます。しかし、実際にはどのストレージに保存され、どの障害に耐え、どのようにバックアップされ、どこまで復元できるのかを設計しておく必要があります。

Kubernetes の抽象化を使うほど、下位レイヤの責任を意識的に言語化しないと、障害時にどこまで戻せるのかが曖昧になります。PVC は入口であって、ストレージ設計そのものではありません。

VMware、OpenStack、KVM、OpenShift Virtualization の見方

VMware は、仮想マシンを安定して運用するための完成された仮想化基盤です。OpenStack は、API を中心にクラウド基盤を作るための部品群です。KVM と libvirt は、Linux 上で仮想化基盤を構成するための土台になります。

Kubernetes を前提にする場合でも、これらの仮想化基盤は不要になるわけではありません。むしろ、Kubernetes ノードをどこに置くか、どのように作るか、障害時にどう再作成するかという点で重要になります。

OpenShift Virtualization や KubeVirt のように、Kubernetes 側から VM を管理する考え方もあります。ただし、それは VM とコンテナの境界が消えるというより、VM を Kubernetes の運用モデルに寄せる設計と見る方が自然です。

VMware 代替として見ると、VM 運用機能の比較になります。Kubernetes を主語にして見ると、VM を Pod や Service と同じ運用モデルに近づける話になります。どちらが正しいかではなく、何を主語に評価しているのかを明確にする必要があります。

自宅マイクロデータセンターでは自然なテーマになる

自宅のマイクロデータセンターのような環境では、KVM の上に Kubernetes ノードを作り、その上でアプリケーションを動かす構成はかなり自然です。

物理ホストを直接アプリケーション基盤にするのではなく、VM でノードを分け、Kubernetes でアプリケーションを運用する。さらに構成管理で OS やミドルウェアを揃え、ネットワークやストレージも明示的に設計する。

これは一般的な家庭内サーバーとしては少し過剰です。しかし、インフラの責務分離を学び、実際に運用し、障害時にどの層を見るべきかを理解するには非常に良い題材になります。

関連する記事

まとめ

Kubernetes を前提にした仮想化アーキテクチャでは、VM とコンテナを対立させて考える必要はありません。VM は OS とノードの境界を作り、Kubernetes はアプリケーション運用を抽象化します。

重要なのは、物理、仮想化、OS、Kubernetes、アプリケーションの責務を分けることです。抽象化を重ねるほど便利になりますが、同時に責任境界を明確にしなければ、障害時にどこを見るべきかが分からなくなります。

Kubernetes は下位レイヤの設計を不要にする技術ではありません。むしろ、下位レイヤを正しく設計した上で、その上にアプリケーション運用の標準化を重ねるための技術です。

そして、何を主語にしているのかによって、VM、Kubernetes、コンテナの意味は変わります。設計で大事なのは、技術名を並べることではなく、主語と責務境界を明確にすることです。