こんにちは、ACS 事業部の谷合です。

2025 年 7 月16日、17日に開催された KubeCon & CloudNativeCon Japan 2025 にチームで参加してきました！
私は諸事情により１日目のみの参加でしたが、個人的に琴線に触れたセッションをレポートしていきます。

本ブログの他、弊社から参加したメンバーも、現在以下のブログを公開してくれていますので是非ご覧ください。
【KubeCon Japan 2025】キーノートセッションを振り返る_Day1 - APC 技術ブログ
 【KubeCon Japan 2025】キーノートセッションを振り返る_Day2 - APC 技術ブログ
 KubeCon + CloudNativeCon Japan 2025 第1日目 Platform Engineering のデファクトになりつつあるのは・・・ - APC 技術ブログ
 KubeCon + CloudNativeCon Japan 2025 第2日目プロジェクトの成功は Reconciliation loopとともに。Wa の spiritを添えて。 - APC 技術ブログ
 KubeCon & CloudNativeCon Japan 2025 参加レポート - 青木 - APC 技術ブログ
 KubeCon & CloudNativeCon Japan 2025 参加レポート - 埜下 - APC 技術ブログ

更に番外編でOpenSSF Community Day 2025レポートも公開しています。
OpenSSF Community Day 2025に参加してきました。 - APC 技術ブログ

New Cache Hierarchy for Container Images and OCI Artifact in Kubernetes Clusters Using Containerd

kccncjpn2025.sched.com 公開資料

Preferred Networksさんが開発した CIRC により、コンテナイメージの共有キャッシュを行うことでパフォーマンス向上が可能になった取り組みの発表でした。
この取り組みにより、ポッドの起動速度が約20%向上、Cache hitにより週あたり約23TBのインターネットデータ転送量を削減を実現したそうです。

これは、以下のようにECRやACRのようなレジストリと、containerdがもつローカルキャッシュとの間に CIRC を挟むことで、前述のパフォーマンス向上が図れたとのことでした。

CIRCには以下の機能もあると紹介されていました。

Transparency: Users don’t need to care
- 以下のように、containerdにレジストリ設定を組み込むことで任意のレジストリからイメージのPullが可能になり、マニフェストの変更なく、透過的に様々なレジストリを扱うことができるようなっている。

# /etc/containerd/certs.d/_default/hosts.toml
[host."http://circ.internal"]
capabilities = ["pull", "resolve"]

このとき、以下のようにリクエストを送ることで、任意のイメージ、任意のレジストリを選択することが可能となっており、ユーザ側は普段のマニフェスト変更なしでキャッシュのメリットを透過的に享受できる。

# 任意のイメージ
GET http://circ.internal /v2/NAME/blobs/DIGEST
# 任意のレジストリ
GET http://circ.internal /v2/NAME/blobs/DIGEST?ns=quay.io

Multi-tenancy: Secure cache sharing
- クラスタワイドでPod間でイメージキャッシュを共有することができる。さらに、共有の際は安全な認証を行う。
Preheating: Push images for fast first pulls
- イメージPush時にもキャッシュを行い、初回のPull時の速度を向上。
OCI artifacts: Broader use cases
- OCIアーティファクトのPodマウント
- OCIイメージ形式で保存された任意のコンテンツ

ただ、メリットだけでなく問題点も紹介されていました。

CIRCのBootstrapの問題もあり、CIRC起動よりもPodが先に起動してしまった場合にレジストリへのフォールバックに20分以上かかっていたようです。（解消済み）
同時にPullがあった場合に、一方で待ちが発生するThundering Herd Problemの紹介もありました。（Kubernetes仕様）

導入のメリットだけでなく苦労も紹介されており、非常に聞きごたえのあるセッションでした。
CIRC...いつか触ってみたいなと思います。

Kubernetes SIG Node Intro and Deep Dive

kccncjpn2025.sched.com 公開資料

はい。皆大好きSIG-Nodeですね。
1.33の最新機能や、1.34で予定されている機能の紹介がありました。
その中で私が特に気になった機能をご紹介します。

User Namespaces in pods on by default beta
DRA (Dynamic Resource Allocation)やIn-place Pod Resizeの陰に隠れて、非常に有用な機能がひっそりとBeta化されています。
以下KEP（Kubernetes Enhancement Proposal）です。 github.com

この機能は、Podがスケーリングされるノードの一部UIDとGIDを、PodのUIDとGID（0-65535）に紐づけることできる機能です。
これで何が嬉しいかというと、Nodeから見たら非Rootだがコンテナ内ではrootとして見えます。つまり、root権限が必要なコンテナ（NGINXなどのWebサーバなど）でも起動させることができますし、仮にコンテナの乗っ取りが発生し、ノードに脱出できても非rootなので重要なファイルの奪取を防ぐことができる素敵な機能となっています。

まだまだ知名度も大きくはないですが、個人的に待ち望んでいた機能なので、これからGAになっていくのを楽しみしています。

ちなみに、以前Alphaの時に、イベント登壇した際の私の資料もあるので、よかったらこちらも参照いただけるとイメージつくかと思います。 speakerdeck.com

Sidecar Containers: Graduated to GA

Sidecar ContainerをInit Containerとして起動させることができる機能です。
KEPはこちらをご覧ください。

github.com

従来のSidecar Containerは、以下のような問題がありました。

Sidecar ContainerはMain Containerと並列で起動し、一時Sidecar Containerの起動待ちが発生することがある
Main Containerは停止しているが、Sidecar Containerは起動し続ける。つまりPodが停止しない。

そこで、Sidecar ContainerをInit Containerとして起動させることで以下のソリューションが利用できるようなっています。

Sidecar ContainerはMain Containerと並列で起動し、一時Sidecar Containerの起動待ちが発生することがある
→Startup Probeにより確実に一番最初にSidecar Containerを起動
Main Containerは停止しているが、Sidecar Containerは起動し続ける、つまりPodが停止しない
→Podの完了をブロックしないため、Main Containerが停止した場合、Side Containerも停止される

他にも魅力的な機能が追加されているので、是非追ってみてください。