# コンテナオーケストレーション ## 定義 コンテナオーケストレーション(container orchestration)は、コンテナベースソフトウェアアプリケーションの分散クラスタを**構築し継続的に管理する**ことと定義される。マルチコンテナアプリケーションのデプロイ時にクラウド上で各コンテナの協調方法を利用者が定義できるようにし、初期デプロイだけでなくマルチコンテナをひとつのエンティティとして管理(可用性・スケーリング・ネットワーキング)する。クラウド分散環境内での協調的な構築・デプロイ・継続管理の一形態である。([[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) オーケストレーションプラン(orchestration plan)はコンポーネント・依存関係・ライフサイクルを層状に記述し、PaaS クラウドはこのプランからのワークフローをエージェント(コンテナエンジン)経由で実行する。Linux LXC ベース([[LXC]] の namespace・cgroup)を起点に [[Docker]] が事実上の標準となり、クラスタオーケストレーションは [[Kubernetes]]・Mesos・Diego・Borg などへ拡張された。([[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) ## 横断的知見 - **コンテナ単体研究は Docker、クラスタ研究は 2015 年中盤以降に集中する 2 段階のリサーチ加速がある**: Pahl ら(IEEE TCC 2019)は 46 件 SMS でコンテナ研究の年次分布を可視化し、2007 年 LXC 出現後の長い停滞を経て Docker 出現(2013)で第 1 波、Kubernetes・Mesos の普及で 2015 年中盤以降に第 2 波(クラスタ層)が立ち上がったと整理する。本論文は時点で「クラスタ層はようやく研究対象になりつつある形成期」と位置付けるが、これは [[CNCF]] の Kubernetes コアコミット集約([[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]]・[[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]] で前提化される)に至る前史を示す。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]], [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) - **デプロイ容易性が動機の主、リソース効率は副**: 46 件 SMS の動機分析(Fig. 9)は「大規模・自動的なデプロイ容易性」が「軽量リソース管理」より優先されると示す。これはコンテナの差別化要因が「軽い VM」ではなく「再現可能なパッケージング」にあることを意味し、その後のコンテナ配置最適化([[コンテナ配置最適化]])や eBPF ブラックボックス監視で「デプロイ前提を変えずに動的最適化する」アプローチが生まれた経緯と整合する。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]], [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) - **障害管理は 2017 年時点で未開拓と認識されていた**: 46 件 SMS は [S21] Borg の経験報告を引用し「根本原因特定と異常イベント対応のためのリソース監視・ログ解析の改善が必要」と将来課題に位置付ける。これは本 vault が AIOps/[[根本原因分析]]/[[Fault Localization]] で深掘りする領域の起点を示し、2026 年現在の [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] や [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]] までに 8-9 年でようやく専門サーベイが書かれた歴史的距離を示唆する。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) - **エッジ/フォグへの拡張**: 単一基板デバイス(Raspberry Pi 等)上のコンテナとそのクラスタによる分散トポロジ管理が、2016 年時点で既にエッジ/IoT コンピューティングへの適合性として認識されていた([S9][S25][S26][S43][S44])。これは Usman ら(IEEE ACCESS 2022)が定式化する「エッジ展開でのオブザーバビリティ要件」が、リサーチコミュニティで早期に予兆されていたことを意味する。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]], [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) - **オーケストレーションは IaaS と PaaS を均等に橋渡しする**: 46 件 SMS の clouds delivery model 分布(Fig. 14)は IaaS と PaaS がほぼ均等であることを示す。これは「コンテナは VM の代替(IaaS)」かつ「アプリケーションパッケージング機構(PaaS)」という二重性を持つことを定量化したものだ。ブラックボックス監視によるコンテナ配置最適化([[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]])が Kubernetes(PaaS 寄り)スケジューラを補強する形を取るのも、この二重性の延長と読める。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]], [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]) - **コンテナオーケストレーションの障害管理は、単純な再起動から状態を保持したホットリスタートとランタイム切り替えへ拡張しつつある**: CANDARW 2025 は、WebAssembly コンテナに対してランタイム中立チェックポイントを用いることで、Kubernetes の Pod 障害時にコールドスタートを回避するホットリスタートと、メモリ圧力時に高性能ランタイムからメモリ効率型ランタイムへ切り替える動的ランタイム切り替えを実現する。これは、従来の「障害が起きたら Pod を再起動する」モデルから、「状態を保持しつつ最適な実行環境へ適応する」モデルへの転換を示す。(Source: [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]]) ## 未解決の問い - 46 件 SMS は 2016 年カットオフ。サービスメッシュ(Istio・Linkerd)・GitOps(Argo CD・Flux)・eBPF ベースの動的データプレーン(Cilium)・Kubernetes Scheduling Framework など、後続発展は本論文の分類フレームワークで再分類可能か。フレームワーク自体の拡張が必要な領域はどこか。 - 本論文は「first-class なマルチジョブサービス管理メカニズムが Borg に欠如」を [S21] から引用するが、Kubernetes Operator・CRD・Custom Controllers はこのギャップをどの程度埋めたか。後続の体系的レビューはまだ存在しないように見える。 - コンテナオーケストレーション分野の数学的・理論的基礎(scheduling・consistency・workflow correctness)は 2017 年時点で皆無と本論文は指摘。その後 Kubernetes scheduler の理論的解析(approximation bounds・game theoretic placement)はどこまで進んだか。 - エッジ/フォグへの拡張は LXC・Docker 由来のセキュリティモデル(namespace 隔離)で十分か。eBPF・gVisor・Kata Containers といった代替隔離技術の選択基準は。 - 障害管理(failure management)が「2017 年時点で未開拓」とされたが、2026 年現在の Kubernetes Eventing・OpenTelemetry・Cluster Autoscaler の組み合わせは Pahl らが想定していた「コンテナ PaaS ミドルウェアのコア機能」の何割を実現しているか。([[Kubernetes]]・[[CNCF]] エコシステム) - WebAssembly コンテナのオーケストレーションでは、従来の Linux コンテナ向け Kubernetes スケジューラや CRI 実装をどう拡張すれば、ランタイム中立チェックポイントに基づくホットリスタートと動的ランタイム切り替えを統合できるか。(Source: [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]]) ## 関連 - ソース: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]] / [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] / [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]] / [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]] - 概念: [[コンテナ配置最適化]] / [[マイクロサービスアーキテクチャ]] / [[サーバーレスアーキテクチャ]] / [[プラットフォームエンジニアリング]] / [[クラウド管理モダリティ]] / [[体系的マッピング研究]] / [[WebAssembly]] / [[セルフヒーリング]] / [[ランタイム中立チェックポイント]] - エンティティ: [[Docker]] / [[LXC]] / [[Kubernetes]] / [[CNCF]] / [[Claus Pahl]] / [[Antonio Brogi]] / [[Jacopo Soldani]] / [[Pooyan Jamshidi]] / [[WasmEdge]] / [[WAMR]] - 関連 MOC: [[Cloud Container Orchestration]] / [[Platform Engineering - MOC]] / [[System Engineering - MOC]] ## 出典 - [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]（§2 Container Architectures and Their Management、§4 Classification Framework、§5 Results、§6 Conclusions） - [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]]（コンテナ配置最適化の eBPF ブラックボックス監視アプローチ） - [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]（エッジ展開コンテナのオブザーバビリティ） - [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]]（Wasm コンテナオーケストレーションにおけるランタイム中立チェックポイント、ホットリスタート、動的ランタイム切り替え）