こんにちは、ウォンテッドリーのインフラチームでエンジニアをしている加藤です。

一昨日の Japan Community Dayの記事 と昨日の KubeCon+CloudNativeCon Japan Day1の記事 に引き続き、Day2もInfra Squadの巨畠（@donkomura）、田中（@bgpat）、加藤（@kkato）の3名でお届けします。

KubeConの熱気が世間にも伝わっているのか、外の気温もなんと35度。まるで会場の熱量が気温にまで影響しているかのようです。

Day1のセッションはどれも興味深く、学びの多い一日となりました。特に PlayStation Networkのセッション は大人気で会場に入りきらないほどの盛況ぶりでした。反響の大きさから、Day2には異例の アンコール講演 が実施されました。Day2も注目のセッションが目白押しでした。

印象に残ったセッション

メインコンテンツであるセッションの中から、各自が特に印象に残ったと感じた発表について紹介します。

Dynamic Provisioning and Capacity-Aware Scheduling for Local Storage (巨畠)

TopoLVM と KEP-4049 として提案された StorageCapacityScoring を紹介します。

TopoLVM は Kubernetes でローカルストレージを有効活用するための CSI (Container Storage Interface) プラグインです。Kubernetes でストレージを利用するには様々な方法がありますが、高速な各ノードにアタッチされたローカルストレージを利用するほうがネットワークを経由しない分、ワークロードによってはNASよりも性能面で有利です。TopoLVM は以下のような機能を提供しています。

• 動的なプロビジョニング
• ボリュームのリサイズ
• ノードキャパシティを考慮した pod のスケジューリング

本発表ではスケジューリングについて提案された KEP-4049 を提出した背景とその技術的な解説が行われました。

初めは Scheduler Extender を使って topolvm-scheduler というスケジューラ拡張を作って空き容量を見た pod のスケジューリングを行っていたそうです。しかし kube-scheduler の設定を変更できなかったり、 TopoLVM 以外の他の CSI ドライバーで利用できなかったりと制約が多かったので KEP-4049 として動的プロビジョニングのためのストレージスコアリングを提案したという経緯でした。

ストレージスコアリングの仕組みはシンプルです。まず、ストレージスコアリングを有効にしている kube-scheduler は CSI ドライバーからストレージの容量の情報を取得します。取得した空き容量の情報を使ってストレージのスコアを計算します。空き容量が100%の場合は10、0%の場合は0といった具合に線形に設定します。このスコアリングポリシーは線形であることを前提にマニフェストで変更することができます。こうして計算したスコアを元に、値の大きいストレージを優先して割り当てます。

スライドより抜粋

発表では StorageCapacityScoring が解説されましたが、この割り当て方法はワークロードによっては問題になりそうです。例えば、小さい PVC が要求されると空き容量の大きい方から割り当てられます。その後、大きな PVC が要求されると小さい要求が大きな空き領域を邪魔してしまい、結果的に大きな PVC は割り当てられずに pending となることが予想されます。仮に少ない容量から割り当てても、似たような問題が発生します。この問題について発表者に質問したところ、KEPでは議論されておらず今後の導入も検討していないということでした。

周囲にいた日本の技術者の方々と議論したところ、ワークアラウンドとしてストレージプールを十分にしておくというアイディアがでました。ただ、コスト最適化の文脈で使わない容量は最小限にしたいという要求もあるので、もう少し賢いアルゴリズムを考えられそうです。今後良いアイディアを思いついたら KEP で提案したいと思います。

本セッションでは TopoLVM と KEP-4049 について解説されました。技術自体もそうですが、OSS で得られた知見を Kubernetes に還元する取り組み自体が興味深いと感じました。また、 作った本人を含めて世界中の技術者とリアルタイムに議論できるのは KubeCon ならではだと感じました。

Cloud Native Scalability for Internal Developer Platforms (加藤)

LINEヤフー社では、Kubernetesを用いて社内向けの開発者プラットフォーム (IDP: Internal Developer Platform) を提供しています。690テナント、29,000個のアプリケーション、112,000個のPodという非常に大規模なプラットフォームを運用していく中で、同社が直面したスケーラビリティに関する具体的な課題が紹介されました。

引用: https://speakerdeck.com/hhiroshell/cloud-native-scalability-for-internal-developer-platforms

Kubernetesクラスターのスケーラビリティでは、シングルクラスターかマルチクラスターの比較が行われました。リソースの効率性や運用負荷ではシングルクラスターの方が優れている一方で、ワークロードの分離性などの観点ではマルチクラスターの方が優れています。LINEヤフー社では一部のアプリケーションが多くのリソースを消費する場合があり、それらについては専用のクラスターを立てて運用したいなどの要件があり、結果的にマルチクラスターを選択したとのことでした。（KubeCon Europeでも同様のセッションがあるため、こちらも参考になりそうです。）

運用に関しては、アプリ開発者の依頼を受けてPlatform Engineerがロールの設定やGitリポジトリやNamespaceの作成をする必要がありました。しかし、徐々にCustom Controllerでロールの設定を自動化したり、GUIからGitリポジトリやNamespaceの作成をできるようにしたことで、Platform Engineerの運用負荷を下げることに成功したようです。

続いてメトリクスパイプラインについても話がありました。以前はメトリクスにテナント情報を含めることができず、各テナント毎に保存していたメトリクスに他のテナントのメトリクスが混ざってしまいリソースと運用の効率性が損なわれていました。しかし、メトリクスにテナント情報を動的に含められるようにしたことで、効率的にリソースを使うことができるようになり、より簡単にメトリクスを扱うことができるようになったとのことでした。

Custom Controllerのスケーラビリティについては、Controllerの性質上Podを1つだけデプロイするという制限があるため、スケールアウトではなく、スケールアップで対応しているとのことでした。

また、最後にその他の未解決の課題として、kube-apiserverのメモリ消費量、etcdに格納できるデータ量の上限、Custom Controllerのスケールアウトの3つが挙げられていました。LINEヤフー社では非常に大規模なプラットフォームを扱っており、かなり先進的な課題に取り組んでいる印象を受けました。

Containerd: Project Update and Deep Dive - Akihiro Suda & Kohei Tokunaga, NTT; Kirtana Ashok, Microsoft; Akhil Mohan, VMware by Broadcom (田中)

田中からはイベント最後スケジュールに行われた、 containerd メンテナ4名によるセッションについて紹介します。containerd はウォンテッドリーでも EKS のコンテナランタイムとして日々活用しており、運用に役立つ情報が得られることを期待して参加しました。

セッション内容は、直近のアップデートに関する情報、コミュニティ運営やリリースの方針に関する共有、目玉機能の解説、そして最後はメンテナ4名によるパネルディスカッションという形式で進行しました。

セッションでは、2025年5月にリリースされた v2.1 の新機能としては、EROFS (Enhanced Read-Only File System) やイメージボリュームのような機能拡張について触れられました 。これにより、設定ファイルや機械学習モデルなどのデータをコードから分離して共有できるようになったのは大きな進化だと感じました。また、直近の大きな変更として Snapshotter と Node Resource Interface について詳しい解説がありました。

containerd Snapshotter は展開されたイメージレイヤーであるスナップショットを管理する機能です。例として Stargz Snapshotter を使うと必要なときにデータをダウンロードする lazy pulling が可能になり、コールドスタートパフォーマンスを大幅に向上できます。実装についてはパネルディスカッションの中でさらに詳しい解説があり、従来イメージ配布の処理は containerd のクライアント側で行う必要がありましたが、新しく transfer service を導入することでこの課題を解決したそうです。lazy pulling については2021年頃から言及されており、個人的に楽しみにしていた機能だったので、もうすぐ利用できるようになると思うと期待が高まります。

NRI (Node Resource Interface) は、コンテナのライフサイクルイベント時に動作をカスタマイズできる機能です。例としてメモリのロック状態やファイルディスクリプタの状態を監視し ulimit の値を調整する ulimit adjuster 等が紹介されました。NRI に限らずですが、containerd の新機能開発はプラグインや拡張性が重視されているように感じました。個人的には NRI がどのような課題を解決するのか現時点ではまだ具体的なイメージはできていませんが、新しく拡張できる部分が増えるのはエンドユーザーとしてもハックしがいがあり楽しみです。

そして、個人的に今回のセッションのメインコンテンツだと考えるパネルディスカッションでは、各メンテナの containerd への熱い思いを聞くことができました。特に先に紹介した Snapshotter と transfer service との関係性について聞けたことや、安全に生成 AI を活用するために containerd が活用できるはずという視点は非常に興味深い内容でした。コミュニティ運営の苦労話や、メンテナの方々が containerd にどのように関わったか、何に情熱を感じているかといった話も聞くことができ、非常に刺激を受けました。

今回のセッションでは今後の技術選定や運用改善に役立つ知見を得られただけでなく、メンテナの方々の熱意に触れ「自分にも何かできるかもしれない」と思わせてくれたことが大きな収穫になりました。今後も containerd の進化に注目し、コミュニティに貢献できるよう取り組みたいと思います。

イベント全体を通して

KubeCon + CloudNativeCon Japan 2025 最初のKeynoteセッションでは、CNCF CTOのChris Aniszczyk氏から、日本のOSSコントリビューション数がCNCF全体で9位、Kubernetesでは8位にランクインしているという紹介がありました。さらに、Keycloak、Containerd、Lima、Youkiといった日本人が主導しているプロジェクトにも触れられ、日本出身の開発者の貢献が世界でも評価されていることを実感しました。

引用元: KubeCon Japan 2025 - CRA

また、イベント全体を通して「コミュニティに貢献しよう」というメッセージが繰り返し伝えられていたのが印象的でした。

引用元: KubeCon Japan 2025 - CRA

ウォンテッドリーでも、日々の開発や運用の中で多くのCNCFプロジェクトのOSSを活用しています。
今回のKubeConをきっかけに、積極的にコミュニティと関わり、少しでも還元していきたいと思いました。

まとめ

KubeConでは最新の技術トピックに触れられるのはもちろんですが、実際にCNCFのプロジェクトに関わっているコントリビューターや、コミュニティを運営している方々と直接交流できるのも、大きな魅力だと感じました。普段なかなか会えない方々と直接話すことで、多くの刺激と学びを得ることができました。

このような素晴らしいイベントを企画・運営してくださった関係者、そして登壇者の皆様ありがとうございました。また、KubeConへの参加を会社がサポートしてくれたことにもとても感謝しています。

そしてうれしいことに、2026年も日本で KubeCon + CloudNativeCon が開催されることが発表されました！来年の開催が今から楽しみです。

引用元: KubeCon Japan 2025 - CRA