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

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

しかし、実際の基盤設計では、VM と Kubernetes は単純な競合関係ではありません。

多くの環境では、物理サーバー、仮想化基盤、VM、OS、Kubernetes、コンテナ、アプリケーションが階層として重なります。

重要なのは、どちらを選ぶかではありません。

どの層を主語にして、どの責務をどこに持たせるかです。

VM と Kubernetes を対立させない

VM は、OS 単位の境界を作る技術です。

カーネル、ネットワーク設定、ディスク、セキュリティ境界、障害範囲を VM 単位で分けられます。

Kubernetes は、アプリケーションの配置、再起動、スケール、Service、ConfigMap、Secret、Ingress、Pod 間通信などを扱うための基盤です。

つまり、Kubernetes は 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 の拡張なのか、アプリケーション運用基盤なのかが混ざります。

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

仮想化とは、単に VM を動かすことではありません。

複雑な物理構造や運用対象を、扱いやすい単位に置き換える抽象化です。

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

抽象化が増えるほど柔軟になります。

同時に、どの層が何を保証し、どの層が何を保証しないのかを見失いやすくなります。

仮想化は便利な隠蔽であると同時に、責務境界でもあります。

層ごとに責務を分ける

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

層	主な責務	曖昧にした時の問題
物理レイヤ	電源、筐体、CPU、メモリ、ディスク、NIC、配線、冷却	性能や障害範囲を説明できなくなる
仮想化レイヤ	KVM、VMware、OpenStack などで VM の配置、リソース、仮想ネットワークを扱う	VM と物理ホストの責任境界が混ざる
OS レイヤ	各ノードのカーネル、パッケージ、時刻同期、名前解決、証明書、ログ	Kubernetes で解けない OS 問題を見落とす
Kubernetes レイヤ	Pod、Service、Ingress、CNI、CSI、Secret、Deployment	下位基盤の問題を Kubernetes 設定だけで直そうとする
アプリケーションレイヤ	サービス、データ、設定、リリース、監視観点	アプリの責任と基盤の責任が混ざる

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

Kubernetes ノードを VM にする意味

Kubernetes ノードを物理サーバーに直接構築することもできます。

しかし、VM 上に Kubernetes ノードを作る構成には意味があります。

利点	意味
ノードの再作成	VM 単位で作成、削除、再作成しやすい
役割分離	コントロールプレーン、ワーカー、検証用ノードを分けやすい
再現性	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、KVM、OpenShift Virtualization は、すべて同じものではありません。

VMware は、VM を安定して運用するための完成された仮想化基盤です。OpenStack は、API を中心にクラウド基盤を作るための部品群です。KVM と libvirt は、Linux 上で VM を動かすための土台です。OpenShift Virtualization は、Kubernetes / OpenShift の上で VM を扱う方向の技術です。

これらを単純に「VM が動く技術」として並べると、本質を見失います。

見るべきなのは、どこに管理面を置くのか、どの API を正とするのか、VM を主役にするのか、Kubernetes を主役にするのか、運用者がどの責任を持つのかです。

まとめ

Kubernetes を前提とした仮想化アーキテクチャでは、VM とコンテナを対立させる必要はありません。

VM は OS、ノード、障害範囲、セキュリティ境界を作る層です。Kubernetes は、その上でアプリケーションの配置、再起動、スケール、Service、Ingress、Secret などを扱う層です。

重要なのは、どちらが優れているかではありません。

物理、仮想化、OS、Kubernetes、アプリケーションの各層が、何を保証し、何を保証しないのかを分けることです。

ネットワークやストレージも、Kubernetes の抽象化だけでは完結しません。CNI、CSI、PVC、Service、Ingress の裏側には、VM、仮想スイッチ、物理 NIC、ストレージ、バックアップ、復旧順序があります。

Kubernetes を前提にするほど、下位レイヤを見なくてよくなるのではありません。むしろ、どの層に何を任せるのかを、より明確に設計する必要があります。