コンテナに入れた処理と、その処理を動かすサーバーの間には、どのような境界があるのでしょうか。利用者が持ち込むプログラムを実行する場合などは、コンテナを起動できることに加えて、何を共有し、どこから分離するかが重要になります。
Kata Containersは、コンテナを仮想マシン（VM）の中で動かし、隔離の層を増やす仕組みです。OCP Korea Tech Dayで紹介されたこの技術を、公式設計文書と制約の説明から見ていきます。特にKubernetesで使うときは、VMで分ける単位がPodであることと、従来のコンテナと同じ設定をそのまま使えるとは限らないことが、選定の出発点になります。［1、2］
簡単にまとめると？
- Kata Containersは、KubernetesのPodをVMに対応させ、その中でコンテナを動かします。同じPod内の各コンテナが、別々のVMになるわけではありません。
- VMの境界があるため、ホストのネットワークを直接使う設定や、特権コンテナに与えられる権限の範囲は、通常のLinuxコンテナと異なります。
- 導入時は必要なホスト連携を照合し、同じ仕事で起動時間やメモリー使用量も確認します。隔離を増やすことと、互換性や性能を保つことは別の確認です。
コンテナの外側に、もう一つカーネルを置く
Linuxのカーネルは、プログラムからの要求を受け、CPUやメモリー、入出力などを扱うOSの中核です。従来のLinuxコンテナは、名前空間やcgroupという仕組みで処理の見える範囲や資源の使い方を分けますが、ホスト側のカーネルを共有します。ホストとは、コンテナやVMを載せる側のシステムです。
Kata Containersでは、ホスト側のランタイムがVMを起動し、VMの内側にあるゲストLinuxカーネルでコンテナを作ります。コンテナの名前空間やcgroupによる区分は、ゲストの中にも残ります。その外側に、ハードウェア仮想化を使うVMの境界が加わる構成です。コンテナをVMへ置き換えてなくすのではなく、VMの中で引き続きコンテナとして管理します。［2、3］
公式文書の起動手順では、ホスト側のランタイムがハイパーバイザーを起動し、そのハイパーバイザーがゲストのカーネルとシステムイメージを使ってVMを立ち上げます。VM内のkata-agentがコンテナを作り、利用者の処理を実行します。このように、ホストで管理する部分と、ゲストで処理を動かす部分を分けています。［2］
同じPodの中まで、VMで分かれるわけではない
KubernetesのPodは、一つ以上のコンテナをまとめて扱う単位です。Kataの公式設計では、このPodの実行環境をVMに対応させます。一つのPodにアプリ本体と補助コンテナを置く場合、両方が同じVMに入り、ゲストカーネルを共有します。「コンテナを二つ作ったから、VMも二つ」という理解では、実際の境界とずれてしまいます。［2、3］
例えば、文書変換サービスで、サービス提供者が管理する処理と、利用者が持ち込む変換プログラムを動かす場面を考えます。二つを同じPodに置けば、コンテナが別でもVMの境界は共有します。利用者の処理を別のVMへ分けたいなら、Podの分け方から検討する必要があります。これは境界を説明する仮例で、特定サービスの導入結果ではありません。
ただし、Podを分けた後も、共有するファイルや認証情報、アクセスできる通信先は別に設計します。VMを分けることだけで、データの受け渡し方まで決まるわけではありません。どこまで同じ実行環境を共有してよいかを先に定めると、Kataを使う対象と、その対象をまとめる単位が見えてきます。
ホストに直接触れる設定は、そのまま移せない
隔離の境界を増やすと、ホストの機能を直接利用していた処理には違いが出ます。2026年10月12日に確認した公式のLimitationsは、ホストのネットワーク名前空間を使うhostNetworkを未対応としており、VMの中からホストのネットワーク設定へ直接アクセスできないことを理由に挙げています。従来のコンテナで使っていた設定を、Kataへ機械的に移す前に照合すべき点です。［4］
privileged、つまり特権付きコンテナの意味にも注意が要ります。Kataでは、コンテナが持つ高い権限はゲストの内側でのものです。通常のruncベースのコンテナにある、ホストの機器を特権コンテナへ渡す既定の挙動と同じではありません。ゲスト内で権限が高いことと、ホストの機器を操作できることを分けて考えます。［4］
| 確認する対象 | Kataでの意味 | 選定につながる確認 |
|---|---|---|
| 同じPodの複数コンテナ | 一つのVMの中で動き、ゲストカーネルを共有する | VMで分離したい処理を、同じPodへまとめていないか |
hostNetwork |
参照した公式制約文書では未対応 | ホストのネットワークへ直接入る要件があるか |
privileged |
権限が高くなるのはゲスト内。ホスト機器の自動的な受け渡しとは異なる | 必要な機器や操作を、ゲスト側で実現できるか |
この表は公式文書の説明を本稿の判断項目に整理したものです。小さい画面では横へスクロールできます。［2、3、4］
例えば、ホスト全体のネットワーク状態を直接調べるために作られた処理は、普通の業務アプリと同じ前提では移せません。どの情報や機器へ触れる必要があるかを確認し、その要件に合う実行方法を選びます。KubernetesではRuntimeClassを使ってPodのランタイムを指定できるため、すべてのPodを一度にKataへ切り替えることを前提にする必要もありません。［2］
ゲストの中と、ホスト側の資源を分けて見る
Kataの仕事は、VM内のコンテナだけで完結しません。ホスト側には、VMを動かすVMM（仮想マシンモニター）などもあります。公式文書は、資源制約を掛ける場所として、ゲストカーネル、ゲスト内のコンテナ、ホスト側のVMMを分け、目的によって複数の層へ制約を設定する場合があると説明しています。［4］
そのため、アプリの処理時間だけで導入可否を決めると、VMの起動や維持に必要な条件を見落とします。同じ入力と同じ同時実行数で、処理を始められるまでの時間、ゲスト側とホスト側のメモリー使用量、必要な入出力が動くかを比べると、どこに違いが出たか判断しやすくなります。これは本稿からの評価方法の提案であり、Kataと通常のコンテナを実測した結果ではありません。
また、公式文書は複数のハイパーバイザーを扱っていますが、対応する機器やファイル共有の仕組みは一律ではありません。「Kataに対応」という名称だけで、必要な周辺機能がそろうとは判断できません。採用するランタイム、ハイパーバイザー、版と設定をそろえ、その組合せで確認する必要があります。［3］
Kata Containersで増えるのは、コンテナとホストの間にある防御の層です。完全な安全や、従来と同じ性能を保証するものとして選ぶのではなく、分離したい処理の単位と、ホストへ触れる必要性を照らし合わせる。そのうえで資源と互換性を確かめると、VMの隔離をどの仕事へ使うべきか、具体的に判断できます。
参考資料
- Seongsoo Cho／OpenInfra Korea User Group「Open Infrastructure: Global Trends」、2026 OCP Korea Tech Day、全36頁。Kata Containersの紹介はpp.26–27。OCP公式資料一覧。
- Kata Containers contributors「Kata Containers Architecture」。Shim v2 architecture、Container creation、Mixing VM based and namespace based runtimes。
- Kata Containers contributors「Virtualization in Kata Containers」。PodとVMの対応、ゲスト内のコンテナ、ハイパーバイザーごとの機能。
- Kata Containers contributors「Limitations」。Host network、Privileged containers、The constraints challenge。
資料確認日：2026年10月12日。公式文書の公開版とリポジトリのmainを参照しています。特定の配布版を導入した検証や、速度・メモリー使用量の比較試験は行っていません。採用時は対象版の文書と実際の設定を確認する必要があります。