# Kubernetes クラウドネイティブ基盤のデファクトなコンテナオーケストレータ(K8s)。複雑な分散コントロールプレーンを持つ一方、標準化されたドキュメント群を備える。(Source: [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - [[Cloud-OpsBench]] は Kubernetes(v1.31、Huawei Cloud ECS 上の 4 インスタンス)を対象スタックに選ぶ。複雑な障害注入の余地と標準化された文書コーパスを併せ持つため、知識基盤型推論(knowledge-grounded reasoning)を厳密に検証でき、独自・難解なシステムに基づくベンチとの差別化点となる。 - 同ベンチの 40 の根本原因種別は Kubernetes 全スタックを覆う(Admission Control・Scheduling・Startup・Runtime・Service Routing・Performance・Infrastructure の 7 カテゴリ、表2)。State Snapshot はコントロールプレーン設定(マニフェスト)とデータプレーン状態(Pod 一覧)を凍結し、`kubectl` 互換のモック接面で再生する。 - [[Datadog]] は親クラスタ(コントロールプレーンを素の VM 群として稼働)と子クラスタ(実ワークロード。子クラスタのコントロールプレーンは親クラスタ上の Pod として稼働)という二層構造を運用する。2023年3月8日の大規模障害では、systemd/networkd の経路フラッシュで Pod ネットワーキングが全断し、親クラスタ→子クラスタのコントロールプレーン→実ワークロードノードの順で復旧する必要があった。(Source: [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]]) - [[Red Hat OpenShift]] は Kubernetes を拡張した企業向けディストリビューションであり、[[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] は OpenShift 上に ReAct ベースの LLM エージェントを統合し、Kubernetes API・[[Prometheus]] メトリクスへのアクセスを通じて IT オペレーション支援を行う産業経験報告を発表した。 - [[wiki/entities/AI Systems Performance Engineering|AI Systems Performance Engineering]] 第3章では、GPUワークロード向けのKubernetesチューニングとして、既定でトポロジ非対応(NUMAノード・NVLinkドメインを考慮しないGPU割り当て)である問題と、Topology Manager(`--topology-manager-policy`)・NVIDIA GPU Operator・NVIDIA デバイスプラグインによる解決策が解説される。QoS `Guaranteed`には`requests == limits`(CPU・メモリとも整数値)が必要である点、KubernetesはCPU/メモリのcgroup分離は提供するがI/O分離はネイティブでは提供しない点も指摘される。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]]) - 『詳解 システム・パフォーマンス 第2版』11章は、Kubernetesを「Podという同じ場所に配置されるコンテナのグループを単位としてコンテナをデプロイする」オーケストレーションシステムと定義し、Pod間通信をKubeプロキシとCNI(Calico=netfilter/iptables、Cilium=BPF)が仲介する構成を図解する。ノード(物理マシン)・クラスタ(同じAPIサーバーに接続されたノード群)という用語、CPU/メモリの要求と制限・ノードテイント・ラベルセレクタによるスケジューリングを説明し、現行のKubernetesがブロックI/Oを制限していない点([Xu 20])を課題として挙げている——これは[[wiki/entities/AI Systems Performance Engineering|AI Systems Performance Engineering]]第3章が指摘する「I/O分離はネイティブでは提供しない」という観察と一致する。`kubectl top nodes/pods`によるCPU/メモリ監視の実例も示す。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] §11.1.6, §11.3.1, §11.3.4.2.1) - `Observability Engineering`(2nd Edition)第20章は、Kubernetesクラスタのコスト最適化の観測手法として、各ノードでOpenTelemetry CollectorをDaemonSetとして稼働させ`kubeletstats`レシーバと`k8sattributes`プロセッサを組み合わせる構成を推奨する。ノード・Pod間のCPU/メモリ使用率・飽和度のばらつきはパーセンタイルでは見落としやすいため、ヒートマップでの可視化が有効だとする。ローリングアップデート中はPod数が一時的に倍増して見えるため、設定テンプレートハッシュ別に集計することで見かけ上の重複計上を回避する。[[Karpenter]]プラグイン(またはASG)を用いれば、フォールトトレランスとタスク自動移行というKubernetesの特性を活かし、スポット・中断可能インスタンス市場の柔軟性を利用できるが、Node Termination Handlerでノード終了前にワークロードを退避させる必要がある。ビンパッキングの観点では、32コアのマシンに20コアのPodは1つしか収まらず(2つ目は積めない)、主要ワークロードのPodサイズに合わせてマシンのコアサイズを選ぶべきだとする具体的な指針を示す。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] "Cost Optimizing Kubernetes") - [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]は、Kubernetesクラスタの共有インターネット帯域を占有するPodを特定するため、Chained CNI PluginからPodインターフェイスのTCへeBPFをアタッチする。Pod・Service・クラスタ外の3分類でIngress/Egressバイト数をMapへ集約し、DaemonSetとして稼働するTraffic-ExporterがOpenTelemetry/Prometheus形式で出力する。CPU・メモリだけでなくPod単位のネットワーク帯域を運用上の資源メトリクスとして扱う具体例である。 - `Designing Data-Intensive Applications`(2nd Edition)第11章は、Kubernetesをバッチ処理のジョブオーケストレータの代表例としてYARNと並べ、オペレーティングシステムのカーネルとの類推で説明する。kubeletがタスクエグゼキュータ(YARNのNodeManagerに相当)としてノード上でタスクを実行しハートビートで生存を通知する役割、cgroupsによるセキュリティ・性能分離、etcdがリソースマネージャとしてクラスタ状態(ノードのハードウェア・タスク状態・ネットワーク位置)を保持する役割、そしてKubernetesが「オペレータ」と呼ぶアプリケーション固有のサブスケジューラ(YARNの用語ではApplicationMaster)がクエリしきい値によるリードレプリカのオートスケーリングのような特殊要件を扱う仕組みを説明する。これは本ページの他ソースが扱う「GPUワークロード向けチューニング」「コスト最適化」といった運用面の観測とは異なり、Kubernetesのスケジューラ・リソースマネージャ・エグゼキュータという内部アーキテクチャをYARNとの対比で位置づける記述である。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] "Distributed Job Orchestration") - クラウドオーバーサブスクリプション最適化フレームワーク[[Hestia]]([[@2026__SIGCOMM__Rethinking Cloud Optimization - Volatility-Driven for Better Outcomes]], SIGCOMM 2026)はKubernetesクラスタ上に実装・評価されている。物理的なワークロード再配置では、Kubernetes v1.33で正式機能化された in-place pod resize を優先的に用い、リサイズで不足する場合のみ migration を行う設計を採る。Hestiaの本番展開先である[[Tencent]] CloudのオーバーサブスクリプションシステムCraneもKubernetes上に構築されている。(Source: [[@2026__SIGCOMM__Rethinking Cloud Optimization - Volatility-Driven for Better Outcomes]]) - [[Dynamic Resource Allocation (DRA)]]は、GPU等のアクセラレータデバイスをPodへ割り当てる仕組みを、kubeletのデバイスプラグインAPI(単一の線形量しか表現できない)から、`ResourceSlice`/`ResourceClaim`/`DeviceClass`という宣言的オブジェクトモデルへ刷新するKubernetesコアの拡張である。Kubernetes 1.30でアルファ実装され1.34でGA昇格し、ネットワーク接続デバイス・複数Pod間のデバイス共有・ベンダー定義のカスタム設定パラメータをネイティブに表現できるようになった。本ページの他ソースが扱う「NVIDIA GPU Operator・デバイスプラグインによるTopology Manager連携」([[wiki/entities/AI Systems Performance Engineering|AI Systems Performance Engineering]]第3章)は、DRAが置き換えを目指す旧世代の仕組みそのものである。(Source: [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]]) - [[Kueue]] は Kubernetes 上で動くジョブキューイング・バッチスケジューリングコントローラであり、kube-scheduler を置き換えるのではなく admission 制御層として動作する。その拡張である[[トポロジ考慮型スケジューリング]](TAS、[[@2024__KEP__KEP-2724 Topology Aware Scheduling]])は、データセンターのラック・ブロック階層をノードラベルとして表現し、AI/ML ワークロードの Pod 間通信帯域を意識した配置制約を required/preferred アノテーションで表現する。[[wiki/entities/AI Systems Performance Engineering|AI Systems Performance Engineering]]第3章が指摘する「既定でトポロジ非対応」という Kubernetes スケジューラの限界に対し、TAS は kube-scheduler 本体ではなく Kueue という admission 層で NUMA/NVLink ドメインに相当するラック・ブロック単位のトポロジ対応を実現するアプローチである。(Source: [[@2024__KEP__KEP-2724 Topology Aware Scheduling]]) - [[Kubernetes Workload・PodGroup API]]([[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]])は、kube-scheduler にギャングスケジューリング(all-or-nothing方式でのPod集合起動)のフレームワーク支援をネイティブに組み込む拡張である。`Workload`(長寿命のスケジューリングポリシーテンプレート)と `PodGroup`(スタンドアロンのランタイムスケジューリング単位)を分離したAPI設計を採り、Alpha(v1.35)の単純なバリア方式から、Beta(v1.37)でPodGroup単位の一括処理を行うWorkload Scheduling Cycleへ刷新された。Volcano.sh・Kueue・Co-scheduling pluginなどkube-scheduler外で既に複数回実装されてきた機能をコアへ吸収する点で、本ページが扱う[[Dynamic Resource Allocation (DRA)]](デバイスプラグインAPIの刷新)と同時期・同方向の設計思想を共有する。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]]) - [[@2023__arXiv__The Flux Operator]]([[Lawrence Livermore National Laboratory]] と [[Google]] の共著)は、HPC ワークロードマネージャ [[Flux Framework]] を Kubernetes の Indexed Job・headless service・ConfigMap のみを使って稼働させる Kubernetes Operator「Flux Operator」を提案する。本ページの他ソースが扱う「Kubernetes を GPU/バッチ処理基盤としてどうチューニング・観測するか」という運用面の観察とは異なり、この論文は Kubernetes を HPC 側のワークロードマネージャそのものの実行基盤として転用する「収束コンピューティング(converged computing)」を主題とする——[[Kueue]]・[[Dynamic Resource Allocation (DRA)]]・[[Kubernetes Workload・PodGroup API]]が「Kubernetesコアの外で複数回実装された機能をコアへ吸収する」方向の発展であるのに対し、Flux Operator は「Kubernetesの外で確立された既存のワークロードマネージャ(Flux)をそのままKubernetesの内側へ持ち込む」逆方向のアプローチである点で対照的である。LAMMPS を用いた実験では、SSH で協調する [[MPI Operator]](Kubeflow 発)に対し総壁時間で平均約5%高速という結果を報告した。(Source: [[@2023__arXiv__The Flux Operator]]) - [[@2020__arXiv__Serverless inferencing on Kubernetes]](ICML 2020 ワークショップ論文)は、[[Kubeflow]] エコシステムの [[KFServing]] プロジェクトを解説する。[[Knative]](さらにその基盤の [[Istio]])を拡張して機械学習推論を単一の InferenceService CRD でサーバーレスデプロイ可能にし、GPU オートスケーリングでは Knative Pod Autoscaler(KPA)のリクエストベースオートスケーリングを活用する。本ページの他ソースが 2024年以降の GPU クラスタスケジューリング・トポロジ考慮・ギャングスケジューリングという「大規模 AI/ML ワークロードの配置最適化」を扱うのに対し、本ソースは2020年時点(LLM 以前)の「個々の機械学習モデルをサーバーレスにどう推論サービングするか」という、より早期かつ異なる層の課題(スケールツーゼロ・多フレームワーク対応・canary デプロイ)を扱う。(Source: [[@2020__arXiv__Serverless inferencing on Kubernetes]]) - [[IBM Research]] の Workload Variant Autoscaler(WVA、[[@2026__arXiv__WVA - A Global Optimization Control Plane for llmd]])は、Kubernetes 標準の horizontal pod autoscaler(HPA)が LLM 推論に不十分である理由を体系的に論じる: (1) アプリケーション固有 SLO を考慮しない、(2) 全 Pod を交換可能な均質資源として扱いハードウェア異種性(A100/H100 等)のコスト意識ティアリングができない、(3) KV キャッシュフラグメンテーションやキュー長のようなエンジン内部の輻輳シグナルを捕捉できず、クラスタ全体平均利用率が低くても特定ノードが局所的に飽和した状態のままレプリカを終了させ、ステートフル推論を破壊しうる。WVA はコア HPA を fork・改変する代わりに HPA をアクチュエータとして再利用しつつ意思決定ロジックのみを上位に重ねる「拡張可能な推論認識型制御プレーン」として設計されており、CNCF の新興イニシアチブ([[llm-d]] の CNCF Sandbox 提案)を根拠に、LLM 固有ロジックをコア HPA へ埋め込むことは後方互換性を壊すと明示的に退けている。(Source: [[@2026__arXiv__WVA - A Global Optimization Control Plane for llmd]]) - Kubernetes ブログの記事「[[@2026__KubernetesBlog__Running Agents on Kubernetes with Agent Sandbox]]」は、SIG Apps が開発する [[Agent Sandbox]](`kubernetes-sigs/agent-sandbox`)を紹介する。AI エージェントは孤立・ステートフル・シングルトンという性質を持ち、短いバースト活動の合間はアイドル状態のまま永続的アイデンティティを保つ必要があるため、既存の StatefulSet・headless Service・PersistentVolumeClaim の組み合わせでは大規模運用が「運用上の悪夢」になると論じる。Sandbox CRD は [[gVisor]]・[[Kata Containers]] による強い隔離、アイドル時ゼロスケール可能なライフサイクル管理、安定したネットワークアイデンティティを提供し、SandboxWarmPool 拡張は事前起動済み Pod プールで約1秒の Pod 起動コールドスタートを解消する。本ページの他ソースが扱う「GPU ワークロードのトポロジ最適化」「オートスケーリング」が既存 Kubernetes ワークロード種別(Deployment・Job)の**性能・配置**を最適化する方向であるのに対し、Agent Sandbox は AI エージェントという**新しいワークロード形状そのもの**に対する宣言的 API を新設する点で対照的である。同じく SIG Apps 発の [[LeaderWorkerSet]](分散 LLM 推論・訓練向けの Leader/Worker 非対称レプリカ)とは、「AI 関連ワークロードの新形状ごとに専用 CRD を新設する」という設計方針を共有する。(Source: [[@2026__KubernetesBlog__Running Agents on Kubernetes with Agent Sandbox]]) - 『ネットワークシステムについて語るときに我々の語ること』第11章「ネットワーク管理は今やクールな仕事だ」§11.2は、Kubernetesを GitOps との親和性を説明する具体例として挙げる。構成そのものはYAMLファイルで宣言的に記述され GitOps のフレームワークと非常に親和性が高い一方、障害でダウンしたポッドを再起動する処理のような実行時の状態はコントローラがハンドリングし、いちいち GitOps のプルリクエストにすべきではないという区別を示す。同§11.6は、Google の Borg プロジェクトから生まれた Kubernetes の登場が、プロビジョニング・統合・デプロイ・管理ツールからなる活発なエコシステムの起爆剤となり、PlanetLabや商用エッジクラウドで自前の仕組みを捨てる決断を繰り返し促したと述べる。同§11.4は、Kubernetes の CRD(Custom Resource Definitions)を Helm Chart・Terraform Template と並ぶ宣言的な構成仕様の例として挙げ、これらのツールが「システム管理に携わるのはオペレーターである」という前提を置いている点を指摘し、マルチテナント型プラットフォームのエンドユーザーがシステム管理を行う場合には別の設計(プログラムから制御可能なAPI)が必要になるとする。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2, §11.4, §11.6) - *Building Secure and Reliable Systems* 第14章は、Kubernetes を「デプロイのチョークポイント(choke point)」——すべてのデプロイ要求が必ず通過する地点——を構築するための具体例として扱う。コントロールプレーン("master")ノードだけがワーカーノードへの直接アクセスを受け付けるよう構成すれば、コントロールプレーンが良いチョークポイントになり、Admission Controller webhook がその地点でポリシー判定(署名検証・来歴照合など)を行う差し込み点になる。GKE を利用する場合は [[Binary Authorization]] がこの admission controller をホスト型サービスとして提供する。本ページの他ソースが扱う「スケジューリング・オートスケーリング・トポロジ最適化」という性能・配置の最適化とは異なり、この観察はコントロールプレーンを**セキュリティ制御の集約点**として位置づける視点であり、GitOps 親和性(§11.2 既出)が「宣言的構成の伝達経路」としてコントロールプレーンを見るのに対し、こちらは「デプロイの正当性を強制する検問所」として見る点で対照的である。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] §Advanced Mitigation Strategies > Deployment Choke Points) ## 関連 - 本ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 14 Deploying Code]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] / [[@2026__KubernetesBlog__Running Agents on Kubernetes with Agent Sandbox]] / [[@2026__SIGCOMM__Rethinking Cloud Optimization - Volatility-Driven for Better Outcomes]] / [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] / [[@2023__SREcon23EMEA__The World Blew Up but We're All Okay - How We Managed a Massive-scale Incident at Datadog]] / [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] / [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 11 Batch Processing]] / [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]] / [[@2024__KEP__KEP-2724 Topology Aware Scheduling]] / [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]] / [[@2023__arXiv__The Flux Operator]] / [[@2020__arXiv__Serverless inferencing on Kubernetes]] / [[@2026__arXiv__WVA - A Global Optimization Control Plane for llmd]] - 利用ベンチ: [[Cloud-OpsBench]] - 関連システム: [[Online-Boutique]](K8s 上のマイクロサービスデモ) / [[ChaosMesh]] / [[Red Hat OpenShift]] / [[Karpenter]] / [[Kueue]] / [[Flux Framework]] / [[MPI Operator]] / [[KFServing]] / [[Kubeflow]] / [[Knative]] / [[llm-d]] / [[Agent Sandbox]] / [[LeaderWorkerSet]] / [[Binary Authorization]] - 関連組織: [[Datadog]] / [[Red Hat]] / [[Honeycomb.io]] / [[Lawrence Livermore National Laboratory]] / [[IBM Research]] - 関連概念: [[根本原因分析]] / [[AIOps]] / [[障害注入]] / [[インシデント管理]] / [[ReAct]] / [[パフォーマンスエンジニアリング]] / [[サーバーレスアーキテクチャ]] / [[Dynamic Resource Allocation (DRA)]] / [[トポロジ考慮型スケジューリング]] / [[Kubernetes Workload・PodGroup API]] / [[収束コンピューティング]] / [[LLMサービング管理]] / [[オートスケーリング]] / [[ソフトウェアサプライチェーンセキュリティ]]