SIG Apps に注目：Kubernetes ワークロード管理の変遷

Kubernetes の普及に伴い、議論の焦点はコンテナの実行から、複雑化するアプリケーションライフサイクルの管理へと移ってきた。現代のプラットフォームは、ステートレスな Web サービス、ステートフルなデータベース、バッチ処理、AI ワークロード、プラットフォームサービスを支えながら、アップグレード、スケーリング、インフラ障害の間も信頼性を保たなければならない。

Kubernetes を使う誰もが、意識しているかどうかにかかわらず SIG Apps に依存している。Deployment、StatefulSet、DaemonSet、Job、CronJob は、Kubernetes エコシステム全体におけるアプリケーションのデプロイ、更新、スケーリング、運用の基盤だ。

SIG Apps はワークロードのレジリエンスを高め、アプリケーションライフサイクル管理を改善し、ノード障害、リリースの中断、ますます複雑化するインフラ環境でアプリケーションが抱える運用上の課題に取り組んでいる。

今回の特集では、SIG Apps の3人のチェアのうち2人——Janet Kuo と Maciej Szulik——に話を聞いた。Kubernetes のワークロード管理がどう進化してきたか、アプリケーションの信頼性と運用のシンプルさの間でどう折り合いをつけるか、そして Kubernetes で最も影響力のある Special Interest Group のひとつにおけるアプリケーションライフサイクル管理の今後について。

SIG Apps を知る

Janet Kuo：Google のシニアスタッフソフトウェアエンジニアで、2015年から Kubernetes のメンテナーを務めています。コミュニティに加わったのは、1.0 リリースに向けて全員が突き進んでいた時期でした。当初はコアな Workloads API の構築、具体的には Deployment、ReplicaSet、StatefulSet、DaemonSet といったコントローラの開発、そのロールアウト動作の定義、そして初期設計から GA までの推進が中心でした。この実際に手を動かす仕事が、私を SIG Apps に引き込みました。

それ以来、Kubernetes の技術面とコミュニティ面の両方に深く関わっています。2019年からは SIG Apps の Co-Chair と Tech Lead を務めてきました。現在は workloads API のメンテナンスに加えて、Agent Sandbox などの新しいサブプロジェクトを進め、Kubernetes が次世代の agentic ワークロードと AI ワークロードを支えられるようにしています。

Maciej Szulik：私は2014年から Kubernetes に貢献しています。以来、controller、kubectl、apimachinery と、プロジェクトのさまざまな領域で仕事をしてきて、最終的に SIG Apps の Chair 兼 Tech Lead の一人になりました。現在の重点は2つあり、ひとつは SIG Apps 配下の workload controller の信頼性、もうひとつは kubectl の安定性と使いやすさで、これは SIG CLI の Tech Lead としての役割です。さらに Steering Committee の一員として、コミュニティ全体の健全性と成長にも関心を持っています。Kubernetes の外では Defense Unicorns で Staff Platform Engineer を務め、zarf というプロジェクトを通じて Kubernetes の airgap 環境サポートを改善しています。

課題と解決

SIG Apps はコアな workload API を担っており、アプリケーションが Kubernetes 上でどう動くかはこれらの API にかかっている。Deployment や StatefulSet から Job、CronJob まで、これらの controller が workload の作成、更新、スケーリング、そして問題発生時の復旧方法を決める。

Kubernetes が扱う workload の種類が増えるにつれ——AI、バッチ処理、大規模分散アプリケーションなど——SIG Apps はこれらの API を進化させ続けながら、信頼性、後方互換性、運用のシンプルさのバランスを取っている。

NF：読者の中には SIG Apps に馴染みのない人もいるかもしれません。SIG Apps とは何で、Kubernetes エコシステム全体でどんな役割を担っているのでしょうか？

MS：SIG Apps は Kubernetes の workload API を担当する Special Interest Group です。CronJob と Job はバッチ workload の実行に使い、DaemonSet、Deployment、ReplicaSet、StatefulSet はそれ以外のほとんどのアプリケーションを支えています。もう少し広く言えば、SIG Apps が握っているのは、ほとんどの開発者が日常的に実際に触れる層です。つまり、workload の spec を、実際に動いて自己修復する pod に変える controller です。Deployment がどうローリングリリースするか、Job がどうリトライするか、DaemonSet がどうやって各ノードに1つずつ pod を配置するかは、このグループが決めています。

JK：Maciej の話を補足します。業界の変化に伴い、複雑で非伝統的な workload を動かす需要が急増しています。分散 AI トレーニング、バッチ計算、動的な agent 環境などです。私たちの役割も広がっています。クラシックな workload API を保守するだけでなく、積極的に進化させ、新しいパターン（たとえば Agent Sandbox）を打ち立て、Kubernetes が次世代の workload（たとえば AI）にとって最良のプラットフォームであり続けるようにする。それが私たちの仕事です。

NF：SIG Apps が担当する workload API（Deployment、StatefulSet、DaemonSet、Job、CronJob）のうち、メンテナーとコントリビューターが最も注目している領域はどこですか？

MS：長い間、私たちの重心はバッチ処理 workload を Kubernetes 上で円滑に動かすことにありました。今は関心を移し、サービス系 workload（DaemonSet、StatefulSet など）が取り残されないようにすることに注力しています。具体的には、ローリングリリースとスケーリングの性能および大規模時の挙動を改善し、ユーザーから報告された問題のバックログを整理し、ユーザーコミュニティの声が最も大きいものから優先的に対応するということです。

現在の重点

Kubernetes の workload は規模と複雑さを増し続け、workload コントローラーが直面する課題も変わりつつあります。SIG Apps の主席数名に、コントリビューターの精力が今どこに向いているのか、どのレジリエンス問題の優先度が最も高いと考えているのかを聞きました。

NF：SIG Apps が現在取り組んでいる workload レジリエンスの問題のうち、最も重要なものは何だとお考えですか？

MS：ノードライフサイクルに関する課題は、SIG Apps、SIG Node、SIG Autoscaling の議論で繰り返し出てきます。DaemonSet と Job はノードの状態と最も直接的に結びついているため、痛点が最もはっきり現れる場所です。個々の SIG の中で場当たり的に対処するのではなく、Node Lifecycle ワーキンググループを立ち上げて本腰を入れて進めることにしました。一時しのぎのパッチではなく、長期的な解決策を出したいと考えています。

JK：AI の観点から言えば、レジリエンスは決定的に重要です。数百枚の GPU にまたがる大規模な分散 LLM トレーニングジョブを動かしているとき、ノード1台の故障でパイプライン全体が止まりかねません。同じように、ログや GPU 監視を担う DaemonSet が壊れたノードでスタックすれば、クラスタ全体の健全性に影響します。

Node Lifecycle ワーキンググループがインフラ層で劣化に対処する一方、SIG Apps はオーケストレーション層でも、JobSet（分散トレーニング向け）や LeaderWorkerSet（LWS、シャード化された LLM 推論向け）といったサブプロジェクトを通じてこの問題に取り組んでいます。これらの API は「オール・オア・ナッシング」の障害処理モデルを導入します。単一の Pod や Job の失敗がグループ全体の協調再起動を引き起こし、直近のクリーンな checkpoint から復旧します。スタックした workload を不整合な状態のまま放置しません。

実際の影響

SIG Apps の活動はコントローラーの実装や API 設計にとどまりません。本番環境で Kubernetes クラスタを運用するプラットフォームチームにとって、こうした改善が実際に何を意味するのかを明らかにしたいと考えています。

NF：本番環境で Kubernetes クラスタを運用するプラットフォームチームにとって、現在議論されているノードライフサイクルと workload レジリエンスの取り組みが順調に進んだ場合、どのような実際の改善が感じられるでしょうか？

MS：私は主に傍観者の立場から見ているので、Node Lifecycle Working Group に実際に参加している人たちのほうが正確に答えられるでしょう。ただ、私が見る限りでは、彼らの仕事によって「ノード X が不安定で DaemonSet のローリングアップデートがスタックし、誰かが手動で cordon/delete/restart しないと解けない」というだけの午前3時のアラートが減ることを期待しています。

JK：Maciej に同意します。手動介入の削減に加えて、プラットフォームチームはリソースの予測可能性とコスト効率の明らかな改善も実感するはずです。たとえば GPU のアイドル時間が極めて高価な AI workload では、Kubernetes が劣化ノードを自動検出し、ジョブがクラッシュする前にトレーニングコーディネーターや agent を再スケジュールすることで、計算資源の浪費が減り、ジョブの実行が安定します。

課題とトレードオフ

数百万の workload が依存する API を進化させるには、慎重なエンジニアリングが要ります。それ以上に慎重な意思決定が要ります。SIG Apps の主席数名に、Kubernetes の中核 workload コントローラーを変更する際に、どのような技術的・運用的トレードオフを天秤にかけるのかを聞きました。

NF：中核 workload コントローラーを進化させる際、SIG Apps が直面する最も難しい技術的・運用的トレードオフは何ですか？

MS：正直に言えば、いくつかの矛盾が繰り返し現れます。コントローラーはスタックした Pod をどこまで積極的に手放すべきか、正しい判断を下すにはどのシグナルが必要なのか。同時に、後方互換性は常に考慮しなければなりません。Deployment、DaemonSet、Job の挙動は10年にわたり[Kubernetes のユーザー、ツールチェーン、自動化、より上位のコントローラーに]依存されてきたので、明らかに「より正しい」変更であっても、人々が古い挙動を前提に組んだ自動化を意図せず壊すことがあります。

JK：最も難しいトレードオフの一つは、設計を「エレガント」にするために後方互換性を壊したい衝動をぐっとこらえることです。代わりにオプトイン機能として設計し、レガシー workload に押し付けるのではなく、ユーザー自身が新しい挙動を採用するか決められるようにしなければなりません。まったく新しいパラダイムを支える必要があるときは、中核 API を肥大化させるより、まず CRD として導入するほうを選びます。Agent Sandbox、JobSet、LWS はそうやって生まれました。

今後の展望

SIG Apps の仕事の多くは既存のワークロード API の安定性を維持することだが、このグループは新しい Enhancement Proposal を通じて Kubernetes の未来も形作っている。最後に、最近再び動き出した提案と、それがワークロード管理の将来にとって何を意味するのかを聞いた。

NF：SIG は最近 KEP-4443 の再開を議論し、Kubernetes 1.38 をターゲットにしています。この提案はどのような機会や課題を解決しようとしているのでしょうか。また、なぜ今が再検討の適切なタイミングなのでしょうか。

KEP-4443 が扱っているのは、Job API にある小さくとも実在する穴だ。PodFailurePolicy は JobFailed 条件に条件付きの理由を追加するよう設定できるが、コンテナの終了コードごとに異なる Pod 失敗ポリシールールを用意しても、生成される理由はどれも同じ汎用的なものになる。提案はシンプルで、各 PodFailurePolicyRule にオプションの Name フィールドを追加し、それを JobFailed 条件の理由に付加する。これにより JobSet のような上位ツールが、ようやくどのルールで失敗が起きたかに応じて異なる対応を取れるようになる。

タイミングについては、オープンソースの世界ではいつも通りの単純な答えになる。これを推進していた元のコントリビューターが離脱したのだ。今は引き継ぐ意欲のある新しい人がいるので、次のリリースをターゲットに定めた。

参加するには

NF：SIG Apps に貢献したい人、特にまだ Kubernetes のメンテナーではない人には、どこから始めることを勧めますか。

MS：最良の出発点は #sig-apps Slack チャンネルと、定期的な SIG Apps ミーティングだ。私たちもそこから始めた。怖そうに感じたり、すぐに返信が来なかったりしても、それはまったく普通のこと。みんな忙しいだけで、あなたを避けているわけではない。

JK：Maciej の答えに加えて、比較的新しいサブプロジェクトやイニシアチブを見てみることを勧める。Deployment や StatefulSet のような安定した API への貢献は敷居が高く感じられるかもしれない。後方互換性の要件が変更のハードルを大きく引き上げるし、取りかかりやすい作業はずっと少ない。

コミュニティに加わったばかりなら、Agent Sandbox のようなプロジェクトは絶好の入口だ。急速に進化していて、メンテナーチームは親切で、まったく新しい開発の余地が大きく、すぐに意味のある貢献ができる。

まとめ

プロジェクトのごく初期から、SIG Apps は Kubernetes アプリケーションのデプロイと運用のあり方を形作ってきた。ユーザーは Deployment、StatefulSet、Job、DaemonSet を日常的に使うとき、その背後にあるコントローラーまで意識することはほとんどない。それでも SIG Apps の仕事は、Kubernetes エコシステム全体におけるワークロードの信頼性とスケーラビリティに影響を与え続けている。

ワークロードのレジリエンス向上やノードライフサイクル動作の改善から、AI や分散コンピューティングの新しいパターンの開拓まで、この SIG は Kubernetes の進化を推し進めながら、プロジェクトの核心原則を守り続けている。それはユーザーが依存する安定性と後方互換性を維持することだ。コアなワークロード API に関心がある人も、Agent Sandbox のような新しいプロジェクトに関心がある人も、あるいは各地の Kubernetes ユーザーの運用体験を改善したい人も、SIG Apps には参加の機会がたくさんある。