タグ: Kubernetes

複数の工場や店舗を中央から管理するとき、拠点との回線が切れたら、現場のクラウド基盤まで使えなくなるのでしょうか。答えは、中央へ何を任せ、拠点に何を残しているかで変わります。画面に拠点を一覧できることと、その拠点が自力で制御を続けられることは、別の設計だからです。

StarlingXのDistributed Cloud（分散クラウド）は、中央管理と拠点側の自律した制御を組み合わせます。OCP Korea Tech DayのOpenInfra講演で紹介されたこの基盤について、StarlingX 12.0の公式文書から、回線断、保守のための同期停止、拠点内の機器故障を分けて見ていきます。^{［1］［2］}

中央が束ねるもの、拠点に残すもの

Distributed Cloudは、中央のCentral Cloudと、一つ以上のサブクラウドをL3ネットワークで結びます。サブクラウドは、単なる遠隔端末ではなく、コンテナ化したアプリケーションを動かすStarlingXのシステムです。中央には、自身の設備を管理するRegionOneと、サブクラウド群を管理するSystem Controllerという役割があります。^［3］

System Controllerは、サブクラウドの追加、対象となる設定の同期、稼働状態やアラームの監視、システムソフトウェアの更新管理を担います。一方、サブクラウドには自律した制御プレーンがあり、公式の概要は、中央へ向かう接続が失われても拠点内のローカルサービスが動作する構成だと説明しています。すべての制御を中央へ毎回問い合わせる構成ではありません。^{［2］［3］}

この違いを具体的に示すのが認証です。公式構成文書では、サブクラウドのサービスは、その拠点内のIdentity Providerだけで認証するとしています。StarlingXのサービスではKeystone、KubernetesではService Accountを使うため、中央との通信が途切れたことだけで、認証先まで失う作りにはしていません。ここで説明しているのは基盤サービスの認証であり、上に載せるアプリ独自のログイン先まで自動的に拠点内へ移るわけではありません。^［3］

回線断でも残る処理を、アプリの依存先までたどる

説明用の例として、工場Aと工場Bにそれぞれサブクラウドを置き、中央から管理する構成を考えます。工場Aと中央を結ぶ回線だけが切れ、工場Aの電源、機器、拠点内ネットワークは正常に動いているとします。工場Aに制御と認証を残す意味は、この場面で現れます。中央へ到達できないことと、拠点内の基盤サービスがすべて止まることを切り離せるからです。これは構成の理解を助ける仮例で、実機試験の結果ではありません。

ただし、工場Aの検査アプリが、判定のたびに中央にあるデータベースを読むなら、その処理には回線への依存が残ります。アプリのログインに外部の認証サービスを使う場合も同様です。ローカルのクラウド制御が動くことだけから、アプリの入力、処理、結果の保存まで成立すると判断することはできません。

そこで構成を選ぶときは、制御プレーンの配置に加え、アプリが使う認証先、データ、保存先を一つずつたどります。中央へ送る結果を一時的に現場へ残す設計なら、その保存容量と後から送る手順も確認対象です。これらは本稿で提案するアプリ側の確認事項であり、StarlingXが任意のデータを自動的に保管・再送するという説明ではありません。

Managed、Online、In-syncは同じ「正常」ではない

中央から見える状態も、一つの表示だけでは読み切れません。公式のdcmanager subcloud listの出力例は、management、availability、syncを別々の列にしています。その例には、managedかつonlineでも、out-of-syncのサブクラウドが載っています。接続状態と設定の同期状態は一致するとは限らないのです。^［4］

この表は公式構成説明とCLIの出力例を整理したものです。表示の更新間隔や障害の検知時間を示す表ではありません。詳細を見るdcmanager subcloud showの例では、identity、patching、platformの同期状態も別々に表示されます。再接続後の確認でも、Onlineへ戻ったことだけでなく、どの同期項目がどう表示されているかを調べる手掛かりになります。^{［3］［4］}

特にUnmanagedは、通信障害の名前ではありません。公式文書では、拠点を保守するため、中央からの同期操作を切り離す状態としています。その間に中央側で行った設定変更は中央で待たせ、Managedへ戻したときにサブクラウドへ送ります。通信できる状態なら、Unmanagedでもアラームは中央へ送られます。「同期を止める」と「監視の通信まで止める」を同じ操作として扱わないことが大切です。^［3］

反対に、回線そのものが切れている間は、その回線を使う中央への報告も届きません。拠点の処理が続いていても、中央から現在の様子を確認できない場面があります。Unmanagedの設定保留についての説明を、そのまま「あらゆる通信障害中の変更が必ず再送され、順序どおりに適用される」という保証へ広げることもできません。

中央との回線断と、拠点内の1台故障を分ける

もう一つ分けたいのが、拠点を外部から切り離せることと、拠点内の機器を冗長にすることです。StarlingXはサブクラウドにSimplex、Duplex、Standardなどの構成を使えます。12.0の構成比較表では、1ノードのAIO-SX（All-In-One Simplex）は冗長性とコントローラーサービスの高可用性が「なし」、AIO-DX（All-In-One Duplex）とStandardは「あり」とされています。^{［3］［5］}

工場AがAIO-SXなら、中央回線の故障には拠点側の自律性が役立っても、その1台が故障したときに代わりのローカルコントローラーが生まれるわけではありません。複数拠点を中央で束ねるだけでは、各拠点の電源、サーバー、保存装置といった、同じ原因で一緒に止まり得る範囲をなくせないためです。

AIO-DXなどを検討する場合も、「冗長性あり」は全アプリの無停止を意味しません。アプリを何台へ配置するか、保存先をどう構成するか、障害時にどれだけの処理能力が残るかは別の条件です。小さな拠点を1台で構成する判断と、拠点内の機器故障も受け止める判断を、中央管理の有無と分けて行う必要があります。

試すなら、切る場所と観測する場所を対応させる

導入を判断するための確認では、まず「中央との回線だけが失われる場合」と「拠点内の機器が故障する場合」を別の試験にします。前者では、現場からの基盤へのアクセス、アプリが必要な入力と保存先、中央側の状態表示を分けて観測します。接続を戻した後は、設定の同期状態とアプリの実際の動作も照合します。後者では、選んだ拠点構成で代替できる制御と、代替できない処理・保存先を確かめます。

ここで挙げたのは、公式の構成から導く確認の考え方です。本稿は障害試験を実施したものではなく、復旧時間、データ損失の有無、可用性の数値を示すものでもありません。StarlingXを選ぶ際に見るべきなのは、「分散しているから止まらない」という一語ではなく、中央から切り離しても成立させたい現場の処理と、その処理が依存するものが、同じ拠点のどこまで揃っているかです。

参考資料

1. Seongsoo Cho／OpenInfra Korea User Group「Open Infrastructure: Global Trends」、2026 OCP Korea Tech Day、全36頁。StarlingXの紹介はpp.19–22。OCP公式資料一覧。
2. StarlingX 12.0「Overview of Distributed Cloud」。中央管理、サブクラウドの自律した制御プレーン。
3. StarlingX 12.0「Distributed Cloud Architecture」。System Controller、拠点内の認証、Managed／Unmanagedとネットワークの役割。
4. StarlingX 12.0「Manage Subclouds Using the CLI」。一覧と詳細表示、管理状態の切り替え。
5. StarlingX 12.0「Deployment Model Comparison Matrix」。AIO-SX／AIO-DX／Standardの冗長性とコントローラーサービス。

資料確認日：2026年10月12日。構成と操作表示はStarlingX 12.0の公式文書に揃えています。講演にある個別企業の導入規模や効果を、この構成の性能保証として用いていません。

コンテナに入れた処理と、その処理を動かすサーバーの間には、どのような境界があるのでしょうか。利用者が持ち込むプログラムを実行する場合などは、コンテナを起動できることに加えて、何を共有し、どこから分離するかが重要になります。

Kata Containersは、コンテナを仮想マシン（VM）の中で動かし、隔離の層を増やす仕組みです。OCP Korea Tech Dayで紹介されたこの技術を、公式設計文書と制約の説明から見ていきます。特にKubernetesで使うときは、VMで分ける単位がPodであることと、従来のコンテナと同じ設定をそのまま使えるとは限らないことが、選定の出発点になります。^［1、2］

コンテナの外側に、もう一つカーネルを置く

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］

この表は公式文書の説明を本稿の判断項目に整理したものです。小さい画面では横へスクロールできます。^{［2、3、4］}

例えば、ホスト全体のネットワーク状態を直接調べるために作られた処理は、普通の業務アプリと同じ前提では移せません。どの情報や機器へ触れる必要があるかを確認し、その要件に合う実行方法を選びます。KubernetesではRuntimeClassを使ってPodのランタイムを指定できるため、すべてのPodを一度にKataへ切り替えることを前提にする必要もありません。^［2］

ゲストの中と、ホスト側の資源を分けて見る

Kataの仕事は、VM内のコンテナだけで完結しません。ホスト側には、VMを動かすVMM（仮想マシンモニター）などもあります。公式文書は、資源制約を掛ける場所として、ゲストカーネル、ゲスト内のコンテナ、ホスト側のVMMを分け、目的によって複数の層へ制約を設定する場合があると説明しています。^［4］

そのため、アプリの処理時間だけで導入可否を決めると、VMの起動や維持に必要な条件を見落とします。同じ入力と同じ同時実行数で、処理を始められるまでの時間、ゲスト側とホスト側のメモリー使用量、必要な入出力が動くかを比べると、どこに違いが出たか判断しやすくなります。これは本稿からの評価方法の提案であり、Kataと通常のコンテナを実測した結果ではありません。

また、公式文書は複数のハイパーバイザーを扱っていますが、対応する機器やファイル共有の仕組みは一律ではありません。「Kataに対応」という名称だけで、必要な周辺機能がそろうとは判断できません。採用するランタイム、ハイパーバイザー、版と設定をそろえ、その組合せで確認する必要があります。^［3］

Kata Containersで増えるのは、コンテナとホストの間にある防御の層です。完全な安全や、従来と同じ性能を保証するものとして選ぶのではなく、分離したい処理の単位と、ホストへ触れる必要性を照らし合わせる。そのうえで資源と互換性を確かめると、VMの隔離をどの仕事へ使うべきか、具体的に判断できます。

参考資料

1. Seongsoo Cho／OpenInfra Korea User Group「Open Infrastructure: Global Trends」、2026 OCP Korea Tech Day、全36頁。Kata Containersの紹介はpp.26–27。OCP公式資料一覧。
2. Kata Containers contributors「Kata Containers Architecture」。Shim v2 architecture、Container creation、Mixing VM based and namespace based runtimes。
3. Kata Containers contributors「Virtualization in Kata Containers」。PodとVMの対応、ゲスト内のコンテナ、ハイパーバイザーごとの機能。
4. Kata Containers contributors「Limitations」。Host network、Privileged containers、The constraints challenge。

資料確認日：2026年10月12日。公式文書の公開版とリポジトリのmainを参照しています。特定の配布版を導入した検証や、速度・メモリー使用量の比較試験は行っていません。採用時は対象版の文書と実際の設定を確認する必要があります。