# コンテナオーケストレーション ## 定義 コンテナオーケストレーション(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 年現在の [[Anomaly detection and root-cause identification in microservices]] や [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] までに 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]]) - **サービスメッシュはクラスタオーケストレーションの下位区分ではなく、通信/オブザーバビリティに特化した別軸として発展した**: 本 concept が引く Pahl ら(IEEE TCC 2019, 2016年カットオフ)の46件SMSは「サービスメッシュは後続発展として本フレームワークで再分類可能か」を未解決の問いとして残していた(下記)。SREの探求26章([[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]]、2018年執筆)の時点で、すでに Istio(Envoyベース)・SmartStack(HAProxyベース)が「完全管理のソリューション」として並列に語られており、サービスメッシュはコンテナのスケジューリング・配置(クラスタオーケストレーション)とは独立に、ネットワーキングとオブザーバビリティの一貫性を解く別レイヤーとして立ち上がったことが分かる。したがって Pahl 2019 の分類フレームワークを単純に拡張してサービスメッシュを組み込むのではなく、「通信/オブザーバビリティ層」という新しいカテゴリ軸を追加する必要がある。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]] ch.26 §26.4, [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) - **リソース要求の表現力不足という別軸のギャップは、コンテナオーケストレーション自体の理論・障害管理の未成熟とは独立に、Kubernetesコアが約10年かけて段階的に埋めた**: 46 件 SMS(Pahl 2019)が指摘した「first-class なマルチジョブサービス管理メカニズムの欠如」や障害管理の未開拓とは別に、単一の線形量でしかリソースを表現できないというデバイスプラグインAPIの制約は、GPU・FPGA等の新世代アクセラレータの普及とともに顕在化した独立のギャップだった。[[Dynamic Resource Allocation (DRA)]](KEP-4381)はこれを`ResourceSlice`/`ResourceClaim`/`DeviceClass`という宣言的オブジェクトモデルで解き、Kubernetes 1.30(アルファ)から1.34(GA)まで4年越しで段階昇格させた。オーケストレーションの「配置・スケジューリング」機能と「リソース表現力」機能は別々のペースで成熟してきたことを示す一事例である。(Source: [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]], [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) - **「エコシステムに既存実装が複数ある機能をコアへ吸収する」という設計判断のパターンが、リソース表現力とスケジューリング単位の両軸で反復している**: [[Dynamic Resource Allocation (DRA)]]はデバイスプラグインAPIの4限界をコアが置き換えた事例であり、[[Kubernetes Workload・PodGroup API]]([[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]])はVolcano.sh・Co-scheduling plugin・Preferred Networks Plugin・Kueueという「kube-scheduler外で少なくとも4回実装されてきた」ギャングスケジューリングをコアへ吸収する事例である。両者ともKEPのDrawbacksセクションで「既存実装で十分ではないか」という反論に対し「レース・デッドロック等への対処の不完全さ」「AI時代の基盤性」を理由に反論しており、46件SMS(Pahl 2019)が2016年時点で「デプロイ容易性が主目的でリソース管理は副次的」と整理した状況から、2025年前後にはリソース管理・スケジューリングの表現力そのものがコアの主戦場へ移ったことを示す。ただしKEP-4671は複数ワークロードキュー・公平性の実装は明示的にスコープ外としKueue・Volcano.shへ委ね続けており、DRAほど完全な吸収ではない非対称な関係にある。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]], [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]], [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) - **GenAI 推論オーケストレーションでは、単一の統合ソリューションではなく「バッチスケジューリング」「アクセラレータスライシング」「分散推論ルーティング」の 3 層それぞれに特化したコンポーネントを組み合わせる分業型アーキテクチャが実用化されている**: Red Hat + Illinois Institute of Technology の産業論文は、[[Kueue]](ジョブキューイング・admission 制御)・Dynamic Accelerator Slicer(GPU MIG スライシング)・Gateway API Inference Extension(分散 LLM 推論ルーティング)という互いに独立したプロジェクトを OpenShift 上で組み合わせ、Whisper 音声認識バッチ推論と LLM 要約オンライン推論からなるマルチステージパイプラインで、それぞれメイクスパン最大 15%、平均ジョブ完了時間 36%、テール TTFT 最大 90% の改善を独立に達成した。これは、46 件 SMS(Pahl 2019)が2016年時点で観測した「first-class なマルチジョブサービス管理メカニズムの欠如」というギャップが、2026年時点では単一の汎用オーケストレーション機能ではなく、ワークロード種別ごとに特化したコンポーネント群の疎結合な組み合わせという形で埋められつつあることを示す。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]]) - **決定論的スケジューリングは、ベストケースのメイクスパンを犠牲にしてでも運用上の予測可能性を優先する設計判断として選好される**: 同論文は、Kueue 未使用の素の Kubernetes Job スケジューリングが(非決定的な機会主義的順序により)Kueue の BestEffortFIFO よりも短いメイクスパンを達成した事例を報告しつつ、それでもなお Kueue の決定的な admission 順序を「多テナント・本番環境で不可欠な公平性・予測可能性・再現性」として位置づける。これは、46 件 SMS が「障害管理は 2017 年時点で未開拓」と指摘した文脈の延長線上で、単なる性能最適化ではなく運用上の説明可能性・SLA 遵守能力がオーケストレーション設計の一級市民になったことを示唆する。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]]) - **ネットワーク機器の組み込みOSは、複数コンテナを使いながらもクラスタオーケストレーションを一切必要としない事例であり、「コンテナ化=クラスタオーケストレーションを要する」という暗黙の前提の反例になる**: 本 concept が集約する文献群(TCC 2019 の 46 件 SMS を含む)は、Kubernetes・Mesos・Borg のような**複数ホストにまたがるクラスタ**でのコンテナ協調管理を前提に議論を組み立てる。これに対し[[SONiC]]([[@2025__Gihyo__実践SONiC入門 - Chapter 7 SONiCの内部構造：アーキテクチャとサブシステム]])は、単一のネットワークスイッチ(1ホスト)上でdatabase・swss・syncd・bgp等、10個前後のコンテナを常時動作させるが、これらの起動順序・依存関係の制御はコンテナ内プロセスの管理ツールであるsupervisord(`dependent_startup`/`dependent_startup_wait_for`)に閉じており、Kubernetesのようなスケジューラ・レプリカ管理・ヘルスチェックに基づく自己修復は介在しない。コンテナ群の起動制御自体はビルド時にJinjaテンプレート(`supervisord.conf.j2`)からプラットフォーム構成(switch_type)に応じて生成される静的な設定であり、オーケストレーションプランのような動的な協調記述とは性質が異なる。「マルチコンテナ構成には協調のためのオーケストレーション層が要る」という本 concept の定義(§定義、[[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]])は、単一ホスト・固定台数のコンテナ構成には当てはまらないことを示す一事例である。(Source: [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]], [[@2025__Gihyo__実践SONiC入門 - Chapter 7 SONiCの内部構造：アーキテクチャとサブシステム]] ch.7 §7.3.2) - **AIプラットフォームでは、コンテナオーケストレーションがGPU利用者向けの資源境界とデータ処理基盤を同時に提供する**: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]]のACPは、マルチテナントKubernetes上でCPU/GPU選択、ワークフロー、ETL、可視化、機械学習API、テナント管理、通信セキュリティをまとめる。DRAやギャングスケジューリングがGPU資源の表現力・投入単位を拡張するのに対し、ACPはそれらを利用者向けプラットフォーム機能へ束ねる運用実例である。(Source: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]], [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]], [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]]) ## 未解決の問い - SONiCのような単一ホスト・固定台数のコンテナ構成(supervisordによるプロセス内制御のみ)と、Kubernetes等のクラスタオーケストレーションの間には、「コンテナ台数が増減する」「複数ホストにまたがる」といった条件のどこかに、オーケストレーション層が必要になる閾値があるはずである。この閾値を定量的・体系的に論じた文献は本 wiki にまだない。 - 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]]) - Kueue と Dynamic Accelerator Slicer の統合(GPU メモリを拡張リソースとして公開し、Kueue がクォータ・admission 制御を、DAS が MIG スライス割当を担う)は 2026 年時点で開発中である。統合完了後、長時間実行ワークロード(Pod・Deployment・StatefulSet)向けの推論・サービング用途でメイクスパン改善とスライス割当効率がどう変化するかは未検証。(Source: [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]]) - ACPのようなマルチテナントKubernetes環境で、CPU/GPU選択、ETL、可視化、機械学習API、テナント通信セキュリティを一つの運用指標体系でどう評価するか。GPU利用率だけではプラットフォームの価値を測れない。(Source: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]]) ## 関連 - ソース: [[@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]] / [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]] / [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]] / [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]] / [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 7 SONiCの内部構造：アーキテクチャとサブシステム]] - 概念: [[コンテナ配置最適化]] / [[マイクロサービスアーキテクチャ]] / [[サーバーレスアーキテクチャ]] / [[プラットフォームエンジニアリング]] / [[クラウド管理モダリティ]] / [[体系的マッピング研究]] / [[WebAssembly]] / [[セルフヒーリング]] / [[ランタイム中立チェックポイント]] / [[サービスメッシュ]] / [[Dynamic Resource Allocation (DRA)]] / [[Kubernetes Workload・PodGroup API]] / [[GPUクラスタスケジューリング]] / [[SONiCのモジュール責務分離]] - エンティティ: [[Docker]] / [[LXC]] / [[Kubernetes]] / [[CNCF]] / [[Claus Pahl]] / [[Antonio Brogi]] / [[Jacopo Soldani]] / [[Pooyan Jamshidi]] / [[WasmEdge]] / [[WAMR]] / [[Kueue]] / [[Dynamic Accelerator Slicer]] / [[Red Hat]] / [[SONiC]] - 関連 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 コンテナオーケストレーションにおけるランタイム中立チェックポイント、ホットリスタート、動的ランタイム切り替え） - [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]]（サービスメッシュがクラスタオーケストレーションと独立な軸として発展した経緯。ch.26 §26.4） - [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]]（Kubernetes の Dynamic Resource Allocation によるリソース要求モデルの刷新） - [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]]（Kubernetes ネイティブのギャングスケジューリング。Workload/PodGroup分離設計によるスケジューリング単位の刷新） - [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]]（ACPのマルチテナントKubernetes、CPU/GPU選択、ETL、可視化、機械学習API） - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第7章 §7.3.2.