Slide 1

Slide 1 text

© 2025 Wantedly, Inc. KubeCon + CloudNativeCon Japan 2025 Recap KubeConの感想を肴に語らう会 Jul.16 2025 - Kazuki Obata (@donkomura_)

Slide 2

Slide 2 text

自己紹介 巨畠 和樹 (Obata Kazuki) - Wantedly 2024-09~ - Infra Squad #k8s #分散システム #ストレージ #Rust #ボルダリング󰩥

Slide 3

Slide 3 text

© 2025 Wantedly, Inc. 01 なぜ KubeCon に参加したか 02 会場の雰囲気 03 印象的だったセッション3本 04 参加して感じたこと CONTENTS

Slide 4

Slide 4 text

© 2025 Wantedly, Inc. なぜ KubeCon + CloudNativeCon Japan 2025 に参加したか - ウォンテッドリーとして - 2016年に Kubernetes を本番導⼊ - 2025年現在でも運⽤し続けている - これまでの経験や知⾒の共有、プロダクト‧組織への適⽤ - 個⼈として - 使ってはいるが、コミュニティに関われていない - 最新技術についてのキャッチアップ‧議論 - CNCF コミュニティに貢献できるところ⾒つける、実例を⾒る

Slide 5

Slide 5 text

© 2025 Wantedly, Inc. 会場の雰囲気 01

Slide 6

Slide 6 text

© 2025 Wantedly, Inc. 会場の雰囲気 - ⽇本をキーワードとしたセッションが多め - CNFNプロダクトを利⽤した⽇本企業の紹介 - 東京ガス, CAを始めとした事例紹介 キーノート

Slide 7

Slide 7 text

© 2025 Wantedly, Inc. 会場の雰囲気 - 常に⼈が多い - セッションの部屋から近いので 気軽に回れる、話やすい - セッション開始までの時間に議論 - ⽇本⼈多くて話しやすい - 海外の技術者とコネクションができる 企業ブース‧Coffee Break

Slide 8

Slide 8 text

© 2025 Wantedly, Inc. 印象的だったセッション 02

Slide 9

Slide 9 text

© 2025 Wantedly, Inc. 印象的だったセッション1 - コンテナイメージの pull にかかる時間を削減した話 - 現実的なアプローチ - イメージサイズを最⼩限にするのは⼤変そう - 特に AI/ML 分野ではライブラリやツールが⼤きくなりがちなので 効きそう - 応⽤が効きそう、⾃社で活⽤できそう - e.g. 定期的にダウンロードするバッチ処理 New Cache Hierarchy for Container Images and OCI Artifact in Kubernetes Clusters Using Container

Slide 10

Slide 10 text

© 2025 Wantedly, Inc. 印象的だったセッション1 - コンテナ起動にかかる時間を短縮したい - コンテナ起動の76%がイメージ取得 - そのほとんどはイメージ pull - Preferred Networks (PFN) は AL/ML の企業 - イメージサイズが⼤きい傾向にある - 20 GB 前後で毎回 pull するには時間がかかりそう 解決したい課題

Slide 11

Slide 11 text

© 2025 Wantedly, Inc. 印象的だったセッション1 - クラスタ内でイメージのキャッシュ管理を⾏うシステム - PFN で開発‧運⽤されている - 構成要素 - キャッシュストレージ - イメージの pull 操作をラップした実装 etc. - 導⼊後のインパクト - Pod 起動時間を20%削減 - 週当たりのデータ転送量を23TB削減 CIRC

Slide 12

Slide 12 text

© 2025 Wantedly, Inc. 印象的だったセッション1 CIRC の全体像 New Cache Hierarchy for Container Images and OCI Artifacts in Kubernetes p.12

Slide 13

Slide 13 text

© 2025 Wantedly, Inc. 印象的だったセッション1 - 透過性 - マニフェストを変更する必要がない、任意のレジストリに対応 - マルチテナンシー - クラスタ内でのキャッシュの共有、レイヤーレベルで認証 - Preheating - イメージをプッシュする際にキャッシュにもイメージを⼊れる - 初回キャッシュ時の遅延を最⼩化できる - OCIアーティファクト CIRC の特徴

Slide 14

Slide 14 text

© 2025 Wantedly, Inc. 印象的だったセッション1 → 記事 or 動画/スライドをチェック 実装と運⽤中の課題 KubeCon + CloudNativeCon Japan 2025 参加速報 - Day1 New Cache Hierarchy for Container Images and OCI Artifacts in Kubernetes

Slide 15

Slide 15 text

© 2025 Wantedly, Inc. 印象的だったセッション2 - スケジューリングに関するKEP を出して実装した話 - Community 主導で Kubernetes コアに統合される事例 - TopoLVM プロジェクトの課題 → Kubernetes (scheduler) の価値向上に寄与 - ⽇本企業で進めている KEP - ストレージの KEP を追っていないので印象深かった - 技術的なところがやや気になった - ワークロードによっては偏りそう Dynamic Provisioning and Capacity-Aware Scheduling for Local Storage

Slide 16

Slide 16 text

© 2025 Wantedly, Inc. 印象的だったセッション2 - CSI プラグイン - ノードローカルストレージを効率的に扱えるように管理 - ネットワークを経由しない分の性能を稼ぎたい - 特徴 - 動的なプロビジョニング - ボリュームのリサイズ - ノードボリュームの容量を考慮した pod のスケジューリング TopoLVM とは https://github.com/topolvm/topolvm

Slide 17

Slide 17 text

© 2025 Wantedly, Inc. 印象的だったセッション2 - topolvm-scheduler - Scheduler Extender を使ったスケジューラ拡張 - 空き容量を考慮した pod のスケジューリングを実施 - 制約が⼤きい - kube-scheduler の設定を変更できない - topolvm-scheduler は他の CSI ドライバーのために利⽤できない - 複数のユーザーがこれらの制約で困っていた KEP-4049 提出の背景

Slide 18

Slide 18 text

© 2025 Wantedly, Inc. 印象的だったセッション2 - ノードの容量を加味したスコアリング - scheduler extender なしで容量を考慮したスケジューリング - TopoLVM 以外の CSI ドライバーもストレージを考慮した スケジューリングの恩恵を受けられる Kubernetes 1.33 で alpha - StorageCapacityScoring feature gate KEP-4049 でできるようになること

Slide 19

Slide 19 text

© 2025 Wantedly, Inc. 印象的だったセッション2 - kube-scheduler に実装する - kube-scheduler は CSI ドライバーからストレージの容量の情報を取得 - 取得した空き容量の情報を使ってストレージのスコアを計算 - 線形に設定 - 空き容量が100%の場合は10 0%の場合は0といった具合 - スコアの⾼い順にスケジューリング 仕組み Dynamic Provisioning and Capacity-Aware Scheduling for Local Storage p.29

Slide 20

Slide 20 text

© 2025 Wantedly, Inc. 印象的だったセッション3 - 印象的だったポイント - Platform Engineering に特化したセッション - Platform の運⽤にフォーカスしている - Giant Swarm で得られた⼤規模なプラットフォーム運⽤の知⾒ - Platform 運⽤の難しさ - 乗り越えるための考え⽅、プラクティス Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms

Slide 21

Slide 21 text

© 2025 Wantedly, Inc. 印象的だったセッション3 - Day 1 - ゴールデンパスの整備 - 新しいプロジェクトやアプリケーションを作成するための⾃動化 - ゴールデンパスでアプリケーションの作成ができる状態 - Day 2 - Day 1 以降のすべて - SRE - Monitoring, Troubleshooting, Scaling etc. - アプリケーション開発者 - アプリケーションのリリース、設定変更 - Platform Engineer - プラットフォームプロダクトのリリース Platform Engineering Day 1? Day 2?

Slide 22

Slide 22 text

© 2025 Wantedly, Inc. 印象的だったセッション3 - ⼤きく2種類ある - アプリケーション開発者からの変更に起因する問題 - プラットフォームエンジニアからの変更に起因する問題 - 特に Platform Engineer の変更の影響が⼤きく難しい - CNI の変更 (CalicoからCiliumへ) - ネットワークポリシーの標準が異なるため中間バージョンを リリース、移⾏ - リポジトリのオーナーの変更 - Kubernetes 更新 (e.g. deprecated API 対応) - OS のアップグレード Day 2 の困難

Slide 23

Slide 23 text

© 2025 Wantedly, Inc. 印象的だったセッション3 - 始めから Day 2 を意識した設計を⾏う - バージョン管理、ユーザーとの連携を含めたプラットフォーム設計 - プラットフォームをプロダクトとして扱う - つくって終わりではなく、進化し続けるもの - ユーザー(開発者)からフィードバックを貰って改善し続ける仕組みを⼊れておく - 宣⾔的な管理を⾏う - バージョニングを徹底する - PR を少なくする‧⾃動化する - ステークホルダーと期待値を調整する - Day 2 の困難を経営層が理解する Day 2 を乗り切るための考え⽅‧プラクティス Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms p.32

Slide 24

Slide 24 text

© 2025 Wantedly, Inc. 参加して感じたこと - 現地の熱量🔥 - 前⽇から⼤盛りあがり - どこでも議論が起こっている場所 - 眠くならずに話せる - ⽇本企業の存在感🔥 - ⽇本⼈コミッターが活躍している - ⽇本企業の Kubernetes や CNCF プロダクトの本番採⽤例の紹介 - 6⽉のお台場は暑い🔥 圧倒的熱量🔥