エッジコンピューティングのオーケストレーション

中央集権オーケストレーションが前提にしていること

Kubernetes の標準的なオーケストレーションモデルは、kube-scheduler や各種コントローラが API サーバーへ常時到達でき、etcd の合意形成に十分な帯域と低遅延が確保されていることを暗黙の前提にしています（/devops/kube-scheduler-internals/）。コントローラは「望ましい状態」と「観測された状態」の差分を検知し、差分がなくなるまで調整アクションを繰り返す reconciliation loop で動きますが、このループが機能するのは observe（現状取得）のたびに API サーバーへ問い合わせられることが前提だからです（/devops/reconciliation-control-loop/）。

エッジコンピューティングでは、この前提の両方が崩れます。

• 断続的な接続性: 工場・店舗・車両・基地局側の機器は、衛星回線・4G/5G・省電力無線などで中央のクラウドと繋がりますが、数十秒〜数時間単位で切断されるのが異常事態ではなく通常運用です。
• リソース制約: エッジデバイスは ARM の小型ボードや産業用ゲートウェイであることが多く、CPU・メモリ・ストレージが数百MB〜数GB規模に収まらないと動きません。フル機能の etcd や複数レプリカの API サーバーを各拠点で走らせる余裕は基本的にありません。

中央集権ループが壊れる具体的なメカニズム

なぜ「たまに繋がらない」だけで設計を変える必要があるのか、reconciliation loop の内部動作に立ち返って考えます。ループは典型的に次の3段階です。

1. Observe: 現在の状態を読む（例: このノードのPod一覧、ヘルスチェック結果）
2. Diff   : 望ましい状態（宣言的マニフェスト）との差分を計算
3. Act    : 差分を埋めるAPI呼び出しを発行し、結果を再度Observeで確認

中央の API サーバーに毎回問い合わせる設計だと、回線切断中は Observe が失敗し続け、ループそのものが停止します。ここで問題なのは単に「更新が遅れる」ことではありません。切断中にエッジ側で起きた現実の変化（プロセスクラッシュ、センサー異常、ローカルでの手動復旧など）を中央が一切把握できないまま、繋がった瞬間に古い意思決定に基づく指令が大量に飛んでくることです。これは分散システムでいう「状態の乖離（スキュー）」に近い現象で、再接続時に中央側の状態と現地の状態が大きく乖離しているほど、収束に要する調整コストと誤動作リスクが跳ね上がります。

階層化オーケストレーション：自律ループを末端に置く

この制約に対する解は、調整ループそのものを中央から末端へ引き下ろすことです。具体的には次の三層構造を取ります。

[中央] 意図(Desired State)の発行・集約ダッシュボード・長期ポリシー
   │  非同期・結果整合な同期（切断を前提とした設計）
   ▼
[拠点/エッジゲートウェイ] ローカルな宣言的ストア + 調整ループ
   │  拠点内は低遅延・高信頼な想定
   ▼
[末端デバイス] エージェント・軽量ランタイム

中央は「何を実現したいか」という意図（Desired State）を配布するだけで、実際に Observe → Diff → Act のループを回すのは各拠点に置かれたローカルな制御ループです。拠点内は工場内LANのように低遅延・高信頼が見込めるため、通常の reconciliation が機能します。中央との同期は、拠点側が持つローカルなソースオブトゥルース（宣言的マニフェストのキャッシュとバージョン）を軸に、Git 由来の宣言状態を pull し続ける GitOps 的な非同期モデルと相性が良く、拠点は繋がった時にだけ最新の意図を取り込み、それ以外は最後に取得した意図に基づいて自律運転します（/devops/gitops-reconciliation/）。

リソース制約が変えるランタイムとID管理の設計

拠点・末端デバイスのリソース制約は、単に「軽量なコンテナランタイムを使う」以上の設計判断を強制します。フル機能の仮想化やハイパーバイザ型分離はメモリ・起動時間のオーバーヘッドがエッジの制約に合わず、軽量コンテナやユニカーネル的な最小ランタイムが選ばれる傾向があります（/devops/container-vs-vm/）。また、拠点あたりのノード数が数台〜十数台と少ないため、中央クラスタで前提にされる「ノードはいくらでも入れ替え可能な使い捨て資源」という発想は弱まり、個々のデバイスのアイデンティティと状態をより長く維持する運用に寄ります。

デバイスの認証も中央集権とは異なる要求を持ちます。断続的な接続下では、中央の認証局や鍵配布サーバーに毎回問い合わせるmTLSモデルをそのまま適用すると、切断中に証明書更新ができず失効してしまうリスクがあります。エッジではデバイス単位で長めの証明書寿命とローカルな検証キャッシュを持たせ、再接続時にまとめてローテーションする設計が必要です（/devops/workload-identity-mtls/）。カスタムリソースでハードウェア固有の状態（センサー校正値、ファームウェアバージョンなど）を宣言的に表現し、拠点側のオペレータがそれを調整する構成も広く使われます（/devops/operator-pattern-crd/）。

なぜマルチクラスタフェデレーションの延長では解けないのか

クラウド上のマルチクラスタフェデレーションは、複数の Kubernetes クラスタを束ねて一つの論理的な管理単位として扱う仕組みで、地理冗長性やブラスト半径の分割が主目的です。この文脈での「分散」は水平方向、つまり同格のクラスタを地理的に横に並べる発想であり、各クラスタの API サーバーには高帯域・低遅延で到達できることが前提になっています。クラスタ間の連携もリソースの複製や比較的短い遅延での状態伝播を扱うことが多く、切断そのものを常態として設計に織り込んではいません。

エッジはこれと構造が異なります。分散は垂直方向——中央、拠点ゲートウェイ、末端デバイスという非対称な階層——に伸び、末端に行くほど信頼性もリソースも細っていきます。フェデレーションの技術（マニフェストの配布、クラスタ間の状態同期）はエッジの階層下位（拠点間の水平連携）には転用できますが、「常時到達できる制御プレーン」という前提そのものを外さない限り、末端デバイス層の断続接続・リソース枯渇には対応できません。エッジ特有の設計要求は、この前提を外すこと自体にあります。

まとめ

• エッジは断続的な接続性とリソース制約が常態であり、中央のAPIサーバーに常時到達できる前提のKubernetes標準の reconciliation loop はそのまま機能しない。
• 解決策は調整ループを拠点へ引き下ろす階層化。中央は意図（Desired State）を配布するだけにとどめ、拠点はローカルな宣言的ストアを軸に自律運転し、中央との同期は非同期・結果整合にする。
• Push よりPullが安全側に倒れる。再接続時は状態乖離とサンダリングハードのリスクがあり、ジッタ付きバックオフや再接続の時間分散が必須。
• リソース制約は軽量ランタイムの選択だけでなく、デバイスIDの長寿命化やカスタムリソースでのハードウェア状態管理にも波及する。
• マルチクラスタフェデレーションは水平（同格クラスタの地理分散、常時到達前提）、エッジオーケストレーションは垂直（中央→拠点→末端の非対称階層、断続接続前提）という構造の違いが、両者を混同できない理由。