KubeCon + CloudNativeCon Japan 2025 参加レポ 2日目を担当する SRE の sho と言います。freee では EKS の運用や新しい EKS プラットフォームの設計・構築を担当しています。
自分からは以下2つのセッションを紹介させてもらいます。
- What's New in Open Source Kubernetes? - Kaslin Fields, Google
- Access AI Models Anywhere: Scaling AI Traffic With Envoy AI Gateway - Dan Sun, Bloomberg & Takeshi Yoneda, Tetrate.io
What's New in Open Source Kubernetes? - Kaslin Fields, Google
概要
ここ3年のメジャーなアップデート（機能追加）を解説するセッションでした。 スライドの構成や話し方がとても分かりやすく、内容もさることながらセッションのやり方としてもとても勉強になりました。
自分が登壇する際も参考になる点が多くあり、アーカイブあればもう一度見たいセッションです。
項目としては以下でした。
- Kubernetes（移行k8sと表記） のバージョンについて
- out-of-tree
- DRA（概要だけ）
- Gateway API
- In-Place Pod Resize
- registory.k8s.io
- Sidecars
個人的に面白かった内容について書いていこうと思います。
k8s のバージョンについて
- alpha より後ろ（beta/stable）ではどちらもデフォルトで有効化される
- beta と stable の違いはその機能が継続的にサポートされるかが異なる
- current major version の間サポートされる
基本的なことですが、beta と stable の違いをあまり認識できてなかったので理解する良い機会になりました。
In-Place Pod Resize
In-Place Pod Resize は待っていた人多かったのではないかと思います。freee 社内でも出た時ちょっと話題になりました。
- Pod の Resource（Request/Limit）を Resize する機能
- 今までも VPA があったが VPA は Pod 再起動 が発生するため使いづらいケースもあった
- AI ワークロードで特にユースケースが多いらしい（他と勘違いしてるかも）
Pod 再起動を伴わずに Resource を増減できるのは便利な一方、 Pod の再スケジューリングもされないため増分によってはノードに乗り切らないため、Resize が空振りするので注意が必要ですね。
ちなみに手元の Kind クラスタで試したところ、ノード・リソース以上に resize しようとすると以下のような status になりました。
status:
conditions:
- lastProbeTime: "2025-07-11T08:04:45Z"
lastTransitionTime: "2025-07-11T08:04:45Z"
message: 'Node didn''t have enough capacity: memory, requested: 107374182400,
capacity: 16734478336'
reason: Infeasible
status: "True"
type: PodResizePending
Sidecars
Sidecar も待ち望んでいた人はとても多かったと思います。自分も数年前に k8s には何故 Sidecars の概念無いんだ...と悶絶した経験があります。
- よくあるユースケース
- app pod の横に web server pod 置くパターン
- k8s における Sidecar とは？
- 同一 pod 上で動いている
- main container よりも前に起動する
- main container が終了するまで動き続けている
- つまり initContainer に restartPolicy 足すだけで Sidecar が実現できる
「initContainer + restartPolicy ＝ Sidecarは概念として分かりづらいですよね？」
「そこら辺はマーケティング頑張っていくしかないですね〜」
みたいな Q&A が最後にありました。
Access AI Models Anywhere: Scaling AI Traffic With Envoy AI Gateway - Dan Sun, Bloomberg & Takeshi Yoneda, Tetrate.io
概要
Envoy AI Gateway の紹介セッションで、名前の通り生成 AI をアプリケーション利用する際の問題解決に焦点を当てた OSS でした。Envoy Gateway を前提にしたアーキテクチャのため EKS や GKE を運用している環境では利用は難しいかなと思いつつ、内容は面白く参考になりました。
Envoy API Gateway が生まれた経緯・歴史
- 生成 AI 固有のケースにあわせた Gateway 層でのハンドリングが求められるようになってきた
- メッセージ生成の時間はぶれがおおきい
- 生成 AI 特有のセキュリティ
- レートリミット …などなど
- 当初は Envoy Filter を使うことを検討していたが結局拡張した独立したコンポーネントとして Envoy AI Gateway を作ることになった
主な機能
- AI アプリや AI エージェントが利用することを想定
- Unified API (Request/ Response Transformers)
- OpenAI API format に対応してない AI Provider があるので
- トークンベースのレートリミット
- LLM リクエストオブザーバビリティ
- Cross-Region / Cross-Provider fallbacks
アーキテクチャ
- Envoy Gateway と協調動作
- EKS では Envoy Gateway ではなく AWS 謹製のコントローラを使ってるので利用不可
- CRD を提供
- Control Plane
- CRD を Envoy Gateway/Gateway API リソースに変換
- Envoy Pods に AI Gateway ExtProc をサイドカーとして挿入
- Data Plane
- AI Gateway ExtProc
より詳細に知りたい方は Docs 参照してください https://aigateway.envoyproxy.io/docs/concepts/architecture/
Demo
Envoy AI Gateway を使ったフォールバックのデモです。
Jupyter Notebook 使ってる影響で文字が多いですが何をやってるかは雰囲気は伝わるかと思います。
最後に
自分は初めて KubeCon に参加したのですが、どのセッションも専門性が高く、普段の業務や日常的なキャッチアップの中ではなかなか得られない学びが多かったです（難しくて理解が追いつかない時もありましたが）。
特に印象的だったのは Envoy AI Gateway のように生成 AI に関連したセッションが多かった点です。これからの k8s は AI に寄り添った基盤としての成長が重要テーマになる、というスタンスが鮮明になった場でもあったと思います。今後も k8s がどのように進化していくのかますます楽しみになった時間でした。
