KubeCon + CloudNativeCon Japan 2026

KeycloakCon は、Keycloak コミュニティを一堂に集めた半日のシングルトラックカンファレンスです。このイベントは、技術的な講演、専門的な成長、ネットワーキングの機会のためのプラットフォームを提供します。参加者はKeycloakの開発者やメンテナーから洞察を得て、最新の機能やアップデートを探索し、実際のユースケースから学びます。これは、Keycloakの専門家や他のユーザーと直接関わり、理解を深め、ネットワークを拡大できる貴重な機会です。 このイベントに関するご質問は、cncfcolocatedevents@linuxfoundation.org までお問い合わせください。

ジャパン コミュニティ デイは、クラウド ネイティブ テクノロジーに関心のある専門家にとって包括的で魅力的な集まりとなる予定です。 KubeCon + CloudNativeCon Japan の参加者と、さまざまな地域のミートアップ コミュニティ、CNCJ 内のスペシャル インタレスト グループ (SIG) およびサブグループのメンバーが集まり、クラウド ネイティブ エコシステムへのコラボレーション、学習、貢献を促進します。このイベントは、複数のテーマを持つ複数のトラックを提供するように構成されており、それぞれがクラウドネイティブ開発とコミュニティへの参加のさまざまな側面を対象としています。 追記：ジャパンコミュニティデイは完売しました！ KubeCon + CloudNativeCon Japan に登録し、ジャパン コミュニティ デイの待機リストに参加してください。 ご質問がございましたら、cncj@googlegroups.com までお問い合わせください。

これは、横浜から約 1 時間離れた東京で開催される、スポンサー主催の場外イベントです。 住所：docomo R&D OPEN LAB ODAIBA |東京都港区台場2-3-2 12F Cloud Native Telecom Meetup Japan 2026 は、KubeCon + CloudNativeCon Japan のプレイベントであり、通信事業者、クラウド プロバイダー、オープンソース イノベーターが集まります。専門家の講演やディスカッションを通じて、現実世界のユースケース、5G/6G の進化、クラウドネイティブ ネットワーキングを探ります。 参加者は以下について学びます。 Kubernetes を使用した実際の通信ユースケース クラウドネイティブ ネットワーク機能 (CNF) 通信ワークロード向けのプラットフォーム エンジニアリング 通信に適用される CNCF プロジェクトの最新トレンド 詳細を確認して Cloud Native Telecom Meetup Japan 2026 に登録するには - https://cntm2026.peatix.com/view 本イベントに関するお問い合わせは、玉置信行 ntamaoki@virtualtech.jp までお願いいたします。

ArgoCon は、Argo CD、Argo Workflows、Argo Rollouts、Argo Events の 4 つのプロジェクトで構成される Argo プロジェクトに関するコラボレーション、ディスカッション、知識共有を促進するように設計されています。 このイベントに関するご質問は、cncfcolocatedevents@linuxfoundation.org までお問い合わせください。

かつて、Kubernetes を実行するということは、Kubernetes の子守りを意味していました。 AI がこの状況を変え始めています。KubeAuto Day では、エンジニアが本番環境で実際に機能しているものと、カンファレンスのスライドで単に良さそうに見えるものを比較するために集まります。 ケルシー・ハイタワーはこの作品のために来日します。あなたはおそらく彼の講演を見たことがあるでしょう。これで、コーヒーを飲みながら彼と直接議論できるようになりました。 ここでの取引は、ベンダーブースもセールストークもありません。 AI の Kubernetes への適用、構成ドリフトの排除、FinOps の作業の自動化についてエンジニアと話すエンジニア。さらに、AIOps、転倒しない AI エージェントの構築、およびゼロタッチ コントロール プレーン。 ほとんどの場合、あなたは SRE、DevOps リーダー、そしてあなたと同じ悩みを抱えているプラ​​ットフォーム担当者と同じ部屋にいるでしょう。 毎週同じ火事と戦うのに飽きたら、私たちと一緒に一日を過ごしませんか。 会場でお会いしましょう。 詳細を確認してイベントに登録するには - https://kubeauto.day/japan このイベントに関するご質問は、contact@kubeauto.day までお問い合わせください。 これは、スポンサーが主催するオフサイトの併催イベントであることに注意してください。

クラウド ネイティブは最新のソフトウェアのオペレーティング モデルになりましたが、AI が次に来るものを再定義しつつあります。組織が主権 AI プラットフォームを構築し、推論を大規模に展開し、自律エージェントを実稼働環境に導入するにつれて、クラウド ネイティブ インフラストラクチャに対する需要が急速に拡大しています。 Kubernetes やプラットフォーム エンジニアリングから可観測性、ネットワーキング、分散システムに至るまで、クラウド ネイティブ エコシステムは信頼できる AI の基盤になりつつあります。 日本はこの変革に関して独自の視点を提供しています。 100 万人近くのクラウド ネイティブ開発者と、オンプレミス システム、ハイブリッド クラウド、クラウド ネイティブ テクノロジを融合したインフラストラクチャ戦略を擁する日本の組織は、モダナイゼーションへの唯一の道がないことを実証しています。 AI の導入が加速する中、これらの強みにより、日本は次世代のインテリジェント インフラストラクチャの形成を支援できる立場にあります。 この基調講演では、Jonathan Bryce と Chris Aniszczyk が、CNCF コミュニティが AI インフラストラクチャの次の波をどのように実現しているか、オープンソースのコラボレーションがこれまで以上に重要である理由、および初めての開発者から経験豊富なメンテナまで、すべての開発者がクラウド ネイティブの推進をどのように支援できるかを探ります。

自律型エージェントの台頭により、根本的に不安定なワークロードが導入される プロファイル: インスタント GPU/CPU を必要とする、寿命が短く、高負荷のコンピューティング ポッド アクセスして消える。この基調講演では、基本的な問題を分解します。 インフラストラクチャのパラドックス: エージェントの需要は無限であるのに対し、厳密には有限である 物理的なコンピューティング、スペース、電力。単純なトレードオフ曲線を次のように使用します。 私たちの焦点は、安全に拡張するためのアーキテクチャのビジョンを提示することです 自律的な未来のために。

生成 AI とエージェント AI の出現により、Kubernetes の役割は CPU ベースのクラウド インフラストラクチャから GPU 中心のインフラストラクチャに移行しています。 爆発的に増大する計算需要、GPU 不足、電気代の高騰などの制約に直面している Kubernetes は、AI ワークロードを持続的に拡張するために利用可能なリソースの使用を最適化する必要があります。特に Agentic AI の場合、単一のリクエストによって多数の下流タスクが生成され、その結果、予測できない計算需要が発生し、従来のクラウド設計哲学だけでこれらの課題に対処することがますます困難になっています。 本プレゼンテーションでは、AI時代のクラウドネイティブインフラストラクチャが直面する新たな課題に対する富士通の視点と、コンポーザブル分散インフラストラクチャをベースとしたソリューションを紹介します。

AI テクノロジーが進歩するにつれて、多様なユーザーのワークロードをサポートするためにマルチテナント コンピューティング インフラストラクチャが不可欠になりました。 AI や ML を含むさまざまなワークロードを処理するマルチテナント プラットフォームの構築は、Kubernetes の強力な拡張性と CNCF エコシステム テクノロジーとの慎重な統合に大きく依存しています。このセッションでは、Kubernetes プラットフォームの背後にある設計哲学を共有します。プラットフォームのアーキテクチャの概要を説明し、クラウドネイティブ プロジェクトを活用して複雑なワークロードを調整する方法について説明します。 参加者は、進化するオープンソース環境に対応するインフラストラクチャを構築するための実践的な洞察を得ることができます。

スバルでは、次世代アイサイトの認識精度をさらに向上させるためのAIモデルの自社開発を進めています。 AI 開発活動が拡大するにつれて、チームは大規模な ML コンテナー イメージ、手動によるデプロイメント操作、ますます複雑化する機械学習ワークフローなど、いくつかの課題に直面しました。 これらの課題に対処するために、Subaru は、Harbor、Envoy Gateway、MetalLB、Argo CD、Helm、Argo Workflows などのクラウド ネイティブ テクノロジーを使用して、Kubernetes ベースの AI モデル開発プラットフォームを構築しました。 これらの改善により、コンテナー イメージのプル時間が約 3 時間から 3 分に短縮され、25 のアプリケーション定義の GitOps 管理が可能になり、機械学習ワークフローが自動化されました。 このセッションでは、SUBARU が Kubernetes と CNCF テクノロジーを使用して AI モデル開発の主要な課題に対処し、開発ワークフローを加速した方法を共有します。

LY Corporation は日本最大級のプライベート Kubernetes プラットフォームを運営しており、わずか 15 人のプラットフォーム エンジニアで 1,300 以上のクラスターと 40,000 以上のノードを管理しています。この 3 分間の基調講演では、LY が Kubernetes カスタム リソースとコントローラーを使用してインフラストラクチャを宣言的に定義し、OpenStack ベースのプライベート インフラストラクチャ全体でクラスターのプロビジョニング、スケーリング、アップグレード、リカバリを自動化する方法を共有します。講演では、プラットフォーム アーキテクチャ図を中心に、宣言型自動化によってプロビジョニングが数週間から数時間に短縮され、ダウンタイムゼロの運用が可能になり、Kubernetes が製品チームのセルフサービス プラットフォームにどのように変わったかを説明します。

現代自動車グループは、自社のプライベート クラウドである hCloud 上でグローバル プラットフォームを実行し、CI/CD パイプライン用のオープンソース ツールを提供しています。単一の Argo CD インスタンスは現在、世界中の 300 以上の Kubernetes クラスターにわたる 5,000 以上のアプリケーションを管理しており、毎月数百の新しいアプリケーションずつ増加しています。一方、マルチリージョンの Harbor レジストリは 5,000 以上のリポジトリにまたがる 60,000 以上のアーティファクトを保持し、データ常駐規制とパフォーマンスのバランスをとるために 3 つのリージョンに複製されています。

記載なし。

水曜日午前プロジェクト表 | 10:45 - 14:45 T-1 CoHDI T-2 繊毛 T-3 オープンコレオ T-4 コミュニティ主導のイベント + TCG T-5 ロングホーン T-6 ハミ T-7 k0s T-8 CoCC

スポンサー: データドッグ デモ: AIで進化するKubernetesモニタリング ブース番号：G7 イベントでの人脈作りやビジネス関係を促進するために、サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりすることもできます。サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりする必要はありません。ブースを訪問するとき、またはスポンサー活動に参加するとき、第三者はあなたの登録データの一部を受け取ります。このデータには、あなたの姓名、役職、会社名、住所、メールアドレス、標準的な人口統計に関する質問 (職務、業界など)、およびあなたが利用したスポンサー付きコンテンツやリソースに関する詳細が含まれます。ブースと対話したり、スポンサー付きコンテンツにアクセスしたりすることを選択した場合、サードパーティの受信者によるそのようなデータの受信と使用に明示的に同意したことになり、受信者には独自のプライバシー ポリシーが適用されます。

魔王は死んだ。クラスターは安定しています...次のカーネルアップグレードまで。 初期の頃、eBPF は、迅速かつ柔軟で、システムの深刻な問題を解決できる強力な魔法のように感じられました。しかし、eBPF ツールが実稼働環境に入ると、焦点は耐久性に移ります。呪文は、カーネルのアップグレード、プラットフォームの変更、継続的な運用にも耐える必要があります。課題は、eBPF に何ができるかではなく、それをどのように安定させるかです。 この講演では、eBPF に対する「ゲーム後」の RPG アプローチを採用し、メイン クエストの後に生じる課題について探ります。 kprobes やトレースポイントなどの古典的な呪文と、fentry/fexit や kfuncs などの新しい魔法のコントラクトを比較し、それらの長期的な安定性を分析します。 BTF と CO-RE がどのようにして古代のルーンとして機能し、継続的な書き換えを行わずにプログラムがカーネル間で適応できるようにする方法を明らかにします。最後に、ツールがあらゆる予期せぬボスとの戦いに耐えられるように、適切な抽象化を選択するための実践的なレッスンを共有します。私たちのプラットフォーム エンジニア チームは、この魔法を持続的に行使する方法を学びます。

GitOps は、「Git は真実の源である」という単純な考えから始まりました。しかし、エコシステムが成熟するにつれて、Kubernetes 構成の配布に OCI が使用されることが増えており、ギャップを無視するのは難しくなってきています。 Git では、履歴、非難、差分分析、PR ベースのレビューを無料で提供します。 OCI は、コンテンツアドレス指定可能、配布準備完了、エアギャップ互換のアーティファクトを提供します。しかし、業界は、あたかも Git の特性が基礎的なものではなく付随的なものであるかのように、あるものを別のものに置き換えています。 この講演では、OCI ファーストの世界向けに設計された実験的な構成配信ツールである Kokumi について紹介します。 Kokumi は Helm および KusTOMize と統合して、環境ごとの構成を定義し、OCI アーティファクトをレンダリングし、Argo CD 経由で配信します。この機能は、Kubernetes デプロイメントの未来を思わせる美しい UI に包まれています。 OCI-Ops の将来はどのようなものになるでしょうか?この講演ですべての答えが得られるわけではありません。しかし、それは未来を垣間見ることができ、観客の想像力を刺激し、その未来を一緒に築くことができるでしょう。

ユーザー名前空間は、コンテナーとホストの間で UID/GID を分離することにより、マルチテナント Kubernetes のセキュリティを向上させます。ただし、これらを運用環境に導入するには、ReadWriteMany (RWX) 共有ストレージの提供という大きな壁に直面します。ユーザー名前空間では、Linux の ID マップされたマウントでボリューム マウントが使用されますが、そのファイル システムのサポートは各ファイル システムの実装に依存するため、既存のリモート ファイル システムに適用できない場合があります。 当社の Kubernetes AI/ML プラットフォームにはすでに複数のストレージ システムがあり、既存のすべてのデータを別のサポートされているファイル システムに移行することは現実的な選択肢ではありませんでした。ストレージ層を置き換える代わりに、NRI を使用してコンテナーの起動時にマウント定義を調整することを選択し、既存のストレージ環境でユーザー名前空間と RWX 共有ボリュームの両方を使用できるようにしました。 このセッションでは、このアプローチの背後にある設計上の決定事項と、既存のデータ資産を使用して実稼働 Kubernetes プラットフォームにユーザー名前空間を導入するための実践的なレッスンを共有します。

LLM を自己ホストする場合、高度な推論テクノロジを時期尚早に採用すると、展開の複雑さが大幅に増加します。エンジニアはこれらのツールをどのように評価し、導入する適切な時期を判断すべきでしょうか? 講演者は、実世界のケーススタディを通じて、Envoy AI Gateway と Athenz を使用して、最小限の vLLM アーキテクチャを堅牢なマルチテナント プラットフォームに進化させるまでの道のりを共有します。彼らは、認証、レート制限、重要なテナントレベルの使用統計を有効にするこの基盤を確立することが、複数のチームを安全にサポートするためにいかに重要なユースケースであるかを強調します。 この運用基盤に基づいて、実際の運用ボトルネックを使用した P/D 分解やインテリジェント ルーティングなどの高度な最適化の継続的な評価と段階的な導入について話し合います。 参加者は、各最適化によって何が改善されるか、運用上のトレードオフ、および管理可能な複雑さで最適化を導入する最適なタイミングについて学びます。

Cilium は誕生してから 10 年が経過し、事実上の標準のセキュア ネットワーキング ソリューション Kubernetes になりました。このセッションでは、Cilium の最新開発に関する最新情報を提供し、その eBPF を利用したスタックが Kubernetes 環境やその他の環境でネットワーキングとランタイム セキュリティをどのように変革および簡素化しているかを紹介します。 効率的なネットワーキング、L4 ロード バランシング、ネットワーク ポリシーのために Cilium を選択した理由についてサイボウズから聞き、それが VM からベアメタル上の Kubernetes へのサービスの移行をどのようにサポートし、本番環境でのプラットフォームの安全でスケーラブルな運用を可能にしたのかを学びます。 また、Cilium プロジェクトを中心としたコミュニティ活動について聞き、プロジェクトが 20 年目に移行する際に参加する方法についても学びます。

記載なし。

組織が Argo CD を使用して GitOps 導入を拡大するにつれて、モノリポジトリの調整速度の低下、アーティファクトの更新が必ずしもデプロイメントをトリガーするとは限らず、クラスター全体での安全なロールアウトや削除の制御が難しくなるなど、新たな課題が浮上し始めています。 20 個のアプリケーションでは機能しても、1,000 個では困難になることがよくあります。パフォーマンス、スケーラビリティ、ライフサイクル管理は、Argo CD を運用環境で実行しているプラ​​ットフォーム チームにとって現在重要な懸案事項となっています。 この講演では、シャロー クローン機能、OCI レジストリ Webhook サポートなど、Argo CD の最近のリリースで導入された 5 つの強力な機能について説明します。これらの改善により、Argo CD はより高速になり、よりイベント駆動型になり、大規模なデプロイメントでもより安全になります。Argo CD を運用環境で実行している場合、または拡張を計画している場合、これらの更新により、GitOps 操作についての考え方が大きく変わります。

ゼロフリクションの Kubernetes ディストリビューションである k0s は、最小限のフットプリントを肥大化させることなく、新しい機能とよりスマートなデフォルトをもたらしながら着実に進化してきました。 このライトニング トークでは、Windows サポートの強化、ストレージの更新、HA セットアップの最近の改善、マルチノード ブートストラップ、エアギャップ展開、クラウド ネイティブの機能強化など、k0s リリース 1.35 による k0s プロジェクトの最新の更新を取り上げます。 エッジ クラスターを実行している場合でも、開発者にとって使いやすい「きちんと動作する」K8s ディストリビューションが必要な場合でも、k0s は見直してみる価値があります。新機能、今後の予定、そしてそれがなぜ重要なのかを説明するペースの速いツアーをご覧ください。

Karmada (Kubernetes Armada) は、複数の Kubernetes クラスターおよびクラウド全体でクラウドネイティブ アプリケーションを実行できるようにする Kubernetes 管理システムです。 このプレゼンテーションでは、Karmada プロジェクトのメンテナーが次の内容を共有します。 カルマダについて簡単に紹介します。 典型的な使用例 コミュニティの概要

Kubernetes は従来、クラウド環境内の同種のサーバーにワークロードをデプロイするために最適化されてきました。しかし、AI ワークロードの急速な導入によりこの前提が根本的に変わり、Kubernetes は GPU やその他のアクセラレータを含む、ますます異種混合のハードウェア上で動作することが求められています。 限られた高価なハードウェア リソースを効率的に利用することが重要な課題となっています。この講演では、ワークロードの需要に基づいて高価値デバイスを接続および切断することで動的なハードウェア構成を探求する CNCF サンドボックス プロジェクトである CoHDI (Disaggregated Infrastructure でのコンポーザブル ハードウェア) について紹介します。 この講演では、このアプローチが、スケジューラーが必要なデバイスを宣言的に待機できるようにするバインド条件など、安全な動的ハードウェア割り当てを目的とした継続的な Kubernetes の取り組みとどのように連携するかについて概要を説明します。参加者は、動的なハードウェア構成が AI 時代の Kubernetes にとって不可欠になっている理由と、コミュニティがそれにどのように取り組んでいるのかを簡潔に理解できます。

Kairos は、パブリック クラウド、オンプレミス、エッジ環境全体でフリートを管理するためのオープンソースの不変 Linux OS です。 Ubuntu、Fedora、openSUSE などの使い慣れたディストリビューション上に構築することも、上流の調整とイメージベースの不変システムのニーズに重点を置いた最小限の Linux である Hadron で実行することもできます。 Kairos は Kubernetes の有無にかかわらず動作します。 k3s や k0s などの軽量ディストリビューションをサポートし、ライフサイクル操作は Kairos Operator によって処理されるため、Kubernetes から直接完全なノードのアップグレードが可能になります。 このセッションでは、最近のプロジェクトの更新に焦点を当て、標準の Kubernetes ワークフローを使用して Kairos ノードをプロビジョニングおよび管理するための Kubernetes Cluster API の実装である Kairos CAPI を紹介します。 Kairos は、トラステッド ブート、アトミック アップグレード、ロールバック、出荷時設定へのリセットなどの機能を備えており、分散システムを管理するための一貫したポータブルな方法を提供します。

ソフトウェアのテストに最善の努力を払っているにもかかわらず、ソフトウェアのロールアウトは依然として失敗する可能性があり、ロールバックして修正を見つけるプロセスは苦痛で複雑な場合があります。 Argo Rollouts のようなツールは、その痛みを軽減するための堅牢な基盤を提供しますが、AI を使用すると、それを中心とした開発者エクスペリエンスに革命を起こすことができます。このセッションでは、次の方法でリリース プロセスを向上させる方法を説明します。 * クラスターに接続してログとメトリクスを収集する AI エージェントを使用して、ロールアウトの失敗を分析します。 * 障害分析に基づいてコードを修正し、自動化された PR とタイムリーな通知を作成できる、インテリジェントなクラウド ベースのコーディング エージェントを採用します。 * 開発者が必要に応じて見直し、軌道修正できるようにすることで、人間による監視を採用します。 クラウド ネイティブ ツールを戦略的に組み合わせることで、平均復旧時間 (MTTR) が大幅に短縮され、より回復力のある生産的な開発者エクスペリエンスが実現します。シームレスなソフトウェア配信の未来を一緒に発見しましょう!

このセッションでは、フリート規模の Kubernetes の宣言的基盤としてのクラスター API という同じ結論に独立して到達した 2 社のケーススタディを紹介します。 1 つは、スタック全体が Kubernetes 上で実行されている 100 以上のマルチテナント クラスターを実行しています。もう 1 つは、SaaS、BYOC、および自己管理型の展開にわたって顧客ごとに分離されたクラスターをプロビジョニングします。どちらも、数日間にわたる手作業の作業を自動化されたパイプラインに置き換えました。 Kubernetes は単一クラスター用に設計されました。しかし、規模の上限、影響範囲、テナントの分離、コンプライアンス、クラウド移行により、実際のビジネスは数百ものクラスターの管理を余儀なくされています。ほとんどの企業はここから始めるべきではありません。この講演ではその理由について説明します。しかし、選択の余地がない人もいます。 出席者は次のものを持って退席します。 - マルチクラスターが必要な場合と時期尚早である場合の決定フレームワーク。 - スケールアウトを余儀なくされた原因と、2 社でそれをどのように解決したか。 - クラスター API を使用して数百の Kubernetes クラスターを管理するためのテスト済みのパターン。 - カスタム オペレーターを構築する場合と既存のツールを作成する場合。

Kubernetes 上で AI/ML ワークロードの重要性が高まるにつれ、スケジューラーを大規模に評価することは重要ですが、コストがかかります。数千のノードで数万の実際のジョブを実行するには費用がかかり、トレーニング ジョブには数日かかる場合があるため、リアルタイムの評価は現実的ではありません。既存のツールでは不十分です。scheduler_perf はマイクロベンチマークに限定されており、kwok/kind は依然としてリアルタイムで実行されます。 私たちは、次の 3 つの主要な機能を備えたオープンソース フレームワークである kube-scheduler-evaluator を開発しました。 Go ベースのシナリオ: 静的 YAML ではなく Go を使用して、大規模なワークロードをプログラムで定義します。 仮想時間: シミュレーションを実時間から切り離します。数千の GPU ジョブによる数日間にわたるクラスター トレースは数秒で完了します。 柔軟な実行: エミュレートされたコントローラーを使用して単一のバイナリとして実行するか、kwok、kind、または実際のクラスターに接続します。 参加者は、kube-scheduler-evaluator を使用してスケジューラーを評価する方法と、その結果を適用してスケジューラー開発を加速する方法を学びます。

Kubernetes のデプロイメントで地球上空 500 km のライブ衛星リンクの中断を回避する必要がある場合、標準的なロールアウト戦略では不十分です。 Synspective は、地上システムが通過中にステートフル接続を維持する SAR 観測衛星群を運用しています。誤ったタイミングで展開すると、軌道上の衛星との通信が失われる危険があります。各衛星には異なる通信ウィンドウがあり、2030 年までに衛星群が 30 以上の衛星に拡大すると、手動による調整は不可能になります。 このセッションでは、Synspective が 2 つのミッション クリティカルな地上サブシステムにわたってクラウド ネイティブの実践をどのように採用したかを説明します。まず、Argo CD が手動の CIOps を宣言型 GitOps パイプラインに置き換え、複数の環境にわたって監査可能で再現可能なデプロイメントを実現した方法について説明します。 2 つ目は、Argo Rollouts が地上局 API からのリアルタイムの衛星通過スケジュール (AOS/LOS ウィンドウ) によってゲートされたプログレッシブ配信をどのように可能にし、リリースがアクティブな通信を決して中断しないようにする方法です。

Kubernetes の講演の多くは成長をサポートするためのスケールアウトに焦点を当てていますが、大規模なプラットフォームにはスケールインするための安全な方法も必要です。これは特にオンプレミスの Kubernetes as a Service に当てはまり、未使用のノード容量がハードウェアの調達、ラック容量、および長期運用に影響を与えます。 この講演では、1,300 以上のクラスターと 40,000 以上のノードにわたって、十分に活用されていないワーカー ノードを安全に統合するためのカスタム コントローラーを構築した方法について説明します。この規模では、十分に活用されていないノードはもはや孤立した非効率性ではなく、重大な容量問題として認識されます。汎用オートスケーラーが提供できるよりも保守的なモデルが必要だったので、コントローラーは、アクションを実行する前に、観察されたノード使用状況、7 日間のピーク メトリクス、レプリカの最小保証、マシン グループ レベルの安全性チェックを使用します。 また、正常なシャットダウンの期待、DaemonSet の終了順序、ユーザーへの影響を最小限に抑えるように設計されたノード削除動作などの安全対策についても説明します。

Longhorn は、増分スナップショット、ディザスタ リカバリ、RWX サポートなど、ベンダーに依存しない軽量のクラウド ネイティブ機能をクラスターに提供します。このセッションでは、Divya Mohan が今年のプロジェクトの最新情報を調査し、ロードマップについて構造化された洞察を提供します。このセッションは、プロジェクト内での貢献の機会を強調することで、新しい貢献者にとって実行可能な道筋を概説することも目的としています。

Rook プロジェクトは、あらゆるレベルと経験の参加者に紹介されます。 Rook は、Kubernetes 用のオープンソースのクラウドネイティブ ストレージ オペレーターです。 Rook は、有名なオープンソース分散ストレージである Ceph を Kubernetes と統合します。このセッションではさまざまなシナリオを取り上げ、実稼働データに安定したブロック、共有ファイル システム、オブジェクト ストレージを提供するために Rook が Ceph をどのように構成するかを示します。 Rook は、2020 年 10 月に Cloud Native Computing Foundation の卒業プロジェクトとして承認されました。

さまざまなサイズのモデルを使用する AI 推論ジョブは、ノード上で同時に実行でき、クロスノード RDMA 通信も導入します。 RDMA 可観測性の欠如は、パフォーマンスのボトルネックが気づかれず、ハードウェアが十分に活用されていないことを意味し、ノード エクスポーターによるノード レベルの RDMA メトリクスのみの提供では、これらの要求を満たすことができません。 最近、Spiderpool は完全な RDMA 可観測性を解除しました。 SR-IOV を介した複数の RDMA デバイスが各ポッドに割り当てられ、それぞれに独自の固定 IP アドレスが割り当てられます。これにより、各ポッドの RDMA トラフィックをスイッチのリンク レベルでも表示できるようになります。さらに、Spiderpool は各ポッドとノードの RDMA メトリクスを収集し、ノード、AI ジョブ、ポッド レベルでメトリクスを集約するマルチレイヤー Grafana ダッシュボードを提供します。特にマルチテナントの AI 推論クラスターでは、これはホットなアプリケーションを特定し、通信のボトルネックを検出するのに役立ちます。この講演では、このソリューションがトラブルシューティングの効率を 60% 以上向上させる方法を実際の事例を通じて説明します。

youki は Rust ベースの OCI ランタイムであり、CNCF エコシステム内の唯一の低レベル コンテナ ランタイムです。 Kubernetes およびcontainerdによって呼び出され、OCIバンドルに基づいて分離されたLinuxプロセスを作成および管理します。 runc や crun などの確立されたランタイムが広く採用されている一方で、youki は積極的な開発と貢献を通じて進化し続けています。 このセッションでは、実際の採用のための重要な要件である runc との互換性の向上に主に焦点を当てながら、youki のアーキテクチャと 1.0.0 リリースに向けたその道筋を探ります。 これに加えて、VM ベースのコンテナ分離のための libkrun との統合や、libseccomp への依存関係を削除するための Rust への seccomp サポートのネイティブ実装など、追加の取り組みについても取り上げます。また、youki がこれらの分野で関連する CNCF プロジェクトとどのように連携しているかについても共有します。 参加者は、youki の現状、課題、参加方法を明確に理解して会場を離れることになります。

Lima は当初、ローカル コンテナー用に作成されましたが、その後、開発者向けのユニバーサル サンドボックス ツールに成長しました。今回はリマについてご紹介します！ AI コーディング アシスタントが幻覚を起こしてローカル ワークスペースを削除しようとした場合、あなたはどうしますか? AI エージェントが日常のワークフローに統合されるにつれ、AI エージェントをホスト マシン上でローカルに実行することがセキュリティ リスクになりつつあります。 また、Lima の GPU アクセラレーション、MCP サーバー、保護同期モードの新しいサポートと、AI エージェントを完全に VM 内で安全に実行する方法、またはホストから VM に接続する方法についても学習します。リマがローカルのコンテナ開発と AI 実験を迅速、簡単、安全にどのように支援しているかをご覧ください。

OpenTelemetry (OTel) は、可観測性の業界標準になっています。このセッションでは、OTel が複雑なクラウドネイティブ環境と最先端のエージェント システムの処理を目的としたアーキテクチャ、プロトコル、エコシステムのアップデートにより可観測性の未来をどのように形成しているかに焦点を当てます。標準化されたセマンティック規約とインストルメンテーションによる GenAI の可観測性、Arrow と動的構成による高カーディナリティのサポート、プロファイリング信号のサポート、OTel ブループリントなど、OTel の主要な取り組みについて触れます。参加して、現在何が進行中か、そして今後何が起こるかを知りましょう!

記載なし。

主催：AWSジャパン デモ: モデルからエージェントまで - Amazon EKS 自動モードで LLM を利用した AI アプリケーションを実行する 小間番号：G8 スポンサー: マイクロソフト デモ: AKS Desktop と VS Code を使用した開発者エクスペリエンス 小間番号：G1 イベントでの人脈作りやビジネス関係を促進するために、サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりすることもできます。サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりする必要はありません。ブースを訪問するとき、またはスポンサー活動に参加するとき、第三者はあなたの登録データの一部を受け取ります。このデータには、あなたの名、姓、役職、会社、住所、電子メール、標準的な人口統計に関する質問、およびあなたがやり取りしたスポンサー付きコンテンツやリソースに関する詳細が含まれます。ブースと対話したり、スポンサー付きコンテンツにアクセスしたりすることを選択した場合、サードパーティの受信者によるそのようなデータの受信と使用に明示的に同意したことになり、受信者には独自のプライバシー ポリシーが適用されます。

主催：ティントリ デモ: Tintri VMstore 〜Kubernetesを学習して動的にマネージメントするデータプラットフォーム〜 小間番号：G2 イベントでの人脈作りやビジネス関係を促進するために、サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりすることもできます。サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりする必要はありません。ブースを訪問するとき、またはスポンサー活動に参加するとき、第三者はあなたの登録データの一部を受け取ります。このデータには、あなたの姓名、役職、会社名、住所、メールアドレス、標準的な人口統計に関する質問 (職務、業界など)、およびあなたが利用したスポンサー付きコンテンツやリソースに関する詳細が含まれます。ブースと対話したり、スポンサー付きコンテンツにアクセスしたりすることを選択した場合、サードパーティの受信者によるそのようなデータの受信と使用に明示的に同意したことになり、受信者には独自のプライバシー ポリシーが適用されます。

すべての機械が作業を開始する前に最もクリーンで最も効率的なエネルギー源を自動的に選択する都市を想像してください。その結果、システム全体がよりスマートでグリーンに稼働します。現在、Kubernetes はエネルギー使用をほとんど意識せずにワークロードをスケジュールします。ワークロードは、実行されているハードウェア、特にアクセラレータのエネルギー特性を確認することはほとんどありません。また、確認したとしても、それがユーザー側のコストや SLO にマッピングされることはほとんどありません。 動的リソース割り当て (DRA) は、このビジョンを現実に近づけます。デバイスプロバイダーは、エネルギー消費と効率を属性として公開できるため、Kubernetes はエネルギー効率の高いデバイスを優先できるようになります。 Kepler などのツールは、これらのメトリクスを使用してノードのエネルギー使用量を推定し、カーボンを考慮したマルチクラスター スケジューリングやエネルギー駆動型の自動スケーリング (KEDA など) を強化できます。 私たちは、エネルギーをスケジュール可能なリソースとして扱う際の課題を検討し、エネルギーを考慮したデバイスの選択と電力制限の概念実証をデモし、残りのエネルギー容量をスケジュールするなどのアイデアを検討します。

実装者のいない仕様書は単なる文書です。 KEP-5339 が SIG-Multicluster の Cluster Inventory API のプラグイン仕様を導入したとき、公式プラグインはゼロで、使用例も実装ガイダンスもありませんでした。 このセッションでは、私がどのようにして最初のプラグイン実装者になったかを共有します。KEP 仕様に基づいて Secret Reader プラグインを構築し、仕様を超えた kubeconfig Secret Reader プラグインを設計し、KEP 自体に改良を加え、最終的にはメンテナーシップを獲得しました。私が行った設計上の決定、避けられなかった間違い、そしてその過程で既存のメンテナーとどのように信頼を築いたかについて説明します。 ここで、Kubernetes SIG に対する信頼を獲得するための具体的なパターンと、独自の Cluster Inventory API プラグインの作成を開始するための十分な知識を学びます。また、実装者がいないプロジェクトが、コミュニティが現れたときにどのようにエコシステムに成長するかについても説明します。

GPU を多用するマルチテナント Kubernetes に適切な OS を選択することで、GPU の有効化、セキュリティ、および運用オーバーヘッドが何年にもわたって改善されます。この講演では、プラットフォーム チームに、Flatcar、Ubuntu、RHEL などに適用できる再利用可能な意思決定フレームワーク (最小限と汎用、カーネルとドライバーのサポート、パッチ適用とライフサイクル) を提供します。 Flatcar から Ubuntu への移行で説明します。GPU プロビジョニングが最大 80% 高速化され、メモリ コストが最大 15% で Ubuntu eBPF 経由でパッチ適用が最大 70% 高速になり、CAPI と Argo CD により GPU 使用率が最大 60% 向上します。私たちは、ドライバー/カーネルのテストを過小評価し、最小限の OS が大規模にシンプルなままであると仮定し、問題が発生したときにロールバックが遅すぎること、そして私たちが別の方法で行うべきことなど、間違いを共有しています。情報に基づいて OS を選択できるようにフレームワークを環境に適応させます。

多くの開発者は Kubernetes に貢献したいと考えていますが、実用的な出発点を見つけるのに苦労しています。ドキュメントの寄稿は、Kubernetes の学習を開始するためのアクセス可能な方法を提供します。 この実践的なチュートリアルでは、参加者はドキュメントとローカリゼーションを通じて最初の貢献を行う方法を学びます。ドキュメントのワークフローを紹介し、SIG Docs メンテナーとのコラボレーションについて説明し、プロセスを段階的に説明します。 参加者は、韓国と日本のローカリゼーション コミュニティの例を使用して、貢献者が単純なドキュメントの更新から上流のディスカッションやコミュニティのコラボレーションにどのように移行するかを確認します。 参加者は、ドキュメントの問題を特定し、ワークフローを理解し、貢献プロセスをナビゲートする方法を学びます。最終的には、参加者は貢献を開始する方法と、ローカリゼーションがクラウド ネイティブ コミュニティへの幅広い参加をどのようにサポートするかを理解できるようになります。

CI/CD パイプラインは攻撃者の主な標的です。 Trivy ワークフロー侵害などの最近のインシデントは、信頼できないコードを実行し、機密データを流出させるために CI がどのように悪用されるかを示しています。 Cilium プロジェクトの eBPF ベースのランタイム セキュリティ コンポーネントである Tetragon は、Kubernetes ワークロードを保護するために広く使用されています。この講演では、GitHub Actions などの CI 環境にも適用して、侵害されたジョブを検出し、データの漏洩を防ぐ方法を説明します。 Tetragon が eBPF をどのように活用するかを簡単に紹介した後、この講演では、GitHub Actions での eBPF の使用法を示し、悪意のある動作を明らかにするランタイム シグナルを提供します。プロセスとネットワーク アクティビティを監視して予期しない送信接続を検出し、侵害されたジョブをリアルタイムで特定するポリシーの具体例を示します。 参加者は、Tetragon を使用して一時的な CI 環境での悪意のある動作を検出および防止する実践的なテクニックを学びます。

研究機関は、異種ハードウェア、ステートフル サービス、そして仕事で Kubernetes を学んだ学生オペレーターという明確な課題に直面しており、蓄積されたレガシーは誰も解きほぐそうとはしません。 私たちの環境: 100GbE を超える 4 つのベアメタル クラスター (2PB Rook-Ceph レイク、22 GPU クラスター (L40S、A100 を含む 7 種類)、エッジ デバイス) は大学院生によって運営されています。統合されたマルチクラスター ターゲットを「ScaleX-POD」と呼びます。移行には、リスクのないライブ マイグレーションとテナントの分離という 2 つのハードルが必要です。 まず、外部テナントがアクティブに実行されている間に運用環境から管理クラスターを抽出します。つまり、孤立したポッドやストレージを使用せずに ArgoCD の所有権を移行し、vcluster を介してドライランニングします。何が壊れたのか、何が変わるのかを共有します。 2 番目に、Kyverno による強制分離: PSS 制限、デフォルト拒否ネットワーク ポリシー、名前空間スコープの RBAC - 移行中および移行後の爆発範囲を含みます。 参加者は失敗の教訓、移行のトレードオフ、PR ベースのワークフローを取得して、オペレーターの移行による知識の損失を軽減します。

Kubeflow は、Kubernetes 上でエンドツーエンドの機械学習を強化する包括的なエコシステムに成長しました。 このセッションでは、すべての主要な作業グループにわたる包括的な「一般教書」の最新情報を提供します。最新のモデルのライフサイクルを視聴者に説明し、統合された SDK とノートブック ワークスペースによってオーサリングがどのように簡素化されるかを示します。 次に、これらのワークロードがどのようにスケーラブルな Kubeflow Pipelines に移行し、Trainer v2 と Katib を介して分散トレーニングとハイパーパラメーター調整を受け、最終的に KServe を介してデプロイされる前にモデル レジストリにカタログされるかを追跡します。 最後に、今後のプロジェクト ロードマップの概要を示し、コア Kubeflow コンポーネントを改善する方法や、隣接する OSS AI プロジェクトへの統合ブリッジを構築する方法についての最新情報を提供します。

Deployment は ReplicaSet を作成し、それが Pod を作成し、最終的に kubelet とcontainerd がそれらを実行します。この Kubernetes ライフサイクルは基本的なものですが、理論を理解することと、実際に観察することは大きく異なります。これらのコンポーネントの相互作用を直接目撃した人はほとんどいません。 このセッションでは、参加者はログの観点から基本的なリソースとコントローラーの動作を調査します。このプレゼンテーションでは、監査ログや kube-controller-manager ログから、containerd ログに至るまで、ログを使用してこれらの動作を追跡します。デプロイメントやサービスなどの基本的なリソースに焦点を当て、ログを通じてそれらを観察することで、Kubernetes が内部でどのように動作するかについて参加者の理解を大幅に深めることができます。 講演者は、Google Kubernetes Engine をサポートしてきた長年の経験に基づいて、あらゆるプロバイダ上のクラスタのトラブルシューティングに適用できる基礎知識を共有します。参加者は、次のインシデントに備えてどこから始めればよいかを正確に把握して帰ることができます。

講演者は決して認定資格を集めようとしたわけではありません。彼は単に Kubernetes がクールだと思っただけです。 それは、同僚がワークロードをデプロイし、ノードが自動的にスケールアップするのを観察することから始まり、すべて k9s を通じてリアルタイムで確認できました。その好奇心が CKA につながりました。CKA には 2 回の試行が必要でした。しかし、合格すると次の試験がどれだけ重なっているかが明らかになったので、彼はそのまま進み続けて Kubestronaut を獲得しました。次に、「これまで触れたことのない CNCF テクノロジーについてはどうですか?」という新たな質問が生まれました。 Raspberry Pi の自宅ラボでは、なじみのないツールが真の興味に変わりました。そして、彼が気づけば、仕事で Kubernetes を一度も使用することなく、14 か月間で 15 件の認定すべてが完了しました。 このライトニング トークでは、その予期せぬ連鎖反応を追跡します。参加者は次のことを学びます: 1. 必要なのは好奇心だけです。制作経験や雇用主のサポートは必要ありません。 2. 1 つのステップが次のステップにつながります。各試験が次のステップへの扉を開きます。勢いが自然に高まる 3. 最も難しいのは最初のステップです。15 を目指す必要はありません。興味のあるものを試してみてください

OSS への貢献は、学習方法やコミュニティへの参加方法を変えることができます。しかし、多くのエンジニアにとって、新人からメンテナーになるまでの道はブラックボックスのままです。最初の号をどのように選択し、信頼を築き、役割を獲得しますか? このセッションでは、2 人のエンジニアが、Rust で書かれた OCI 準拠のコンテナ ランタイムである youki のレビュー担当者およびメンテナになった経緯を共有します。 - 消費者からクリエイターへ: 問題を主張するだけでなく、問題を作成することで、どのようにして 1 回限りの貢献が継続的な関与に変わるのか。 - ラウンドトリップを減らして PR をマージする: レビュー担当者の視点を把握し、変更を効果的に分割し、より迅速にマージに到達する方法。 - 役割の獲得: プロジェクトの明確なビジョンが、レビュー担当者やメンテナのステータスにつながる信頼をどのように構築するか。 - 影響力の拡大: アンブレラ問題がどのようにして新しい貢献者を呼び込み、プロジェクトを 1 人の人間よりもさらに前進させるか。 ここにあるものはすべて、実際の PR と youki 内のレビュー スレッドから来ています。ほとんどの投稿者がぶつかる壁を乗り越える方法を取り戻しましょう。

Kubernetes がプラットフォーム展開の基盤として確立されると、クラウド ネイティブ エコシステムは、成長するエンド ユーザー コミュニティの需要を満たすために進化し続けました。現在、この状況はコンテナを超えた転換点にあり、AI は既存のプロジェクトや新興プロジェクトに急速に不可欠な要素になりつつあります。 この講演では、AI シフトのレンズを通してエコシステムの現在の状態を検証します。クラウドネイティブ環境を安定させ、現在では成熟したオープンソース AI 環境の青写真となりつつある、確立されたパターン、ガバナンス モデル、コミュニティ構造を探ります。 このセッションでは、リバース エンジニアリングのアプローチを採用して、エコシステムがどこに向かっているのかを理解します。参加者は、オープン性、ベンダーの中立性、相互運用性、オープンなコミュニティなどの中核となる原則が、どのようにしてこの次の変革の波と AI への移行の原動力となっているのかを学びます。

クラウドネイティブの世界では、コンピューティングをストレージから分離することが長年にわたって受け入れられてきました。しかし、AI ワークロードにより、ネットワーク自体という新たなボトルネックが露呈しています。 ベンダーは、データを前処理して帯域幅を削減したり、RDMA と専用ハードウェアを統合して転送を高速化することで対応します。前者は依然として前処理中にネットワークを飽和させます。 2 つ目はオープン性と引き換えにハードウェア ロックインを実現します。 私たちは 3 番目の方法を採用しました。ユーザー定義の WebAssembly コードを、NVMe デバイスにできるだけ近いストレージ クラスタ内で直接実行します。 SQL プッシュダウンとは異なり、計算は自由形式です。コンピューティング クラスターとは異なり、データがストレージ ノードから流出することはありません。 Kubernetes 上で CSI とゲートウェイ API を使用して、これをクラウドネイティブのオープンソース機能として公開した方法を共有します。 私たちが突き当たった行き止まり、実行したベンチマーク、まだ超えていないセキュリティの境界も同様です。 このプロジェクトはオープンソースです。コミュニティから次に何が起こるのかを教えてもらいたいと考えています。

ほとんどの予知保全システムは、しきい値に基づいてアラートを送信します。センサーの読み取り値が限界を超えたときに通知し、根本原因の分析と意思決定はエンジニアに任せます。 このセッションでは、Kubernetes ベースのプラットフォーム上の製造ドメイン向けに設計された、自己進化する AI エージェント システムのアーキテクチャを紹介します。講演者は、単一のモノリシック エージェントを構築するのではなく、3 つの重要な設計上の決定事項を示します。(1) モジュラー スキル エンジンを備えた ReAct ベースのコグニティブ アーキテクチャ、(2) 相互参照合成によるマルチパースペクティブ パターンを使用した階層型マルチエージェントの深層検索アーキテクチャ、(3) エージェントがリフレクションを通じて繰り返される対話パターンを検出し、自律的に新しいスキルを登録する自己進化メカニズム。 参加者は、Kubernetes 上でクラウド ネイティブ マイクロサービスとして実行される AI エージェント システムを構築するための具体的なアーキテクチャを手に入れることになります。これは、モジュール式で監視可能で、あらゆる産業ドメインにわたって拡張できるように設計されています。

優れたプラットフォームはツールを追加することで構築されるのではなく、優れた基本要素を設計することで構築されます。しかし、ほとんどのチームは、生の Kubernetes リソースをテンプレート、スクリプト、カスタム コントローラーと組み合わせて使用しており、開発者は操作を行う必要があります。 プラットフォームが隠すべき複雑さ。 このセッションでは、プラットフォームの構築を 2 段階のプロセスとして再構成します。抽象化を構成可能なプリミティブとして定義し、残りを Kubernetes に処理させます。 参加者は、kro (Kube Resource Orchestrator) を使用して、依存関係の順序付け、動的配線、ステータスのロールアップが自動的に処理される、Kubernetes リソースを構成するセルフサービス API を作成する方法を学びます。 彼らは、プラットフォーム利用者向けの API サーフェスを設計する方法、演算子を記述するよりもグラフベースの構成をいつ選択するか、柔軟性を失わずに独自のゴールデン パスを配布する方法を学びます。 参加者は、組織に合わせて拡張できるプラットフォーム抽象化のための実践的なメンタル モデルを手にして帰ることになります。

40 を超えるリージョンと 5 を超える GPU ベンダーにわたるグローバル AI 推論には、GPU の容量以上のものが必要です。また、クラスターを管理し、コントロール プレーン アーティファクトを分散し、大規模な一貫した運用を維持するための実用的な方法も必要です。 GMI Inference Engine は、インテリジェントなルーティング、異種リソースの抽象化、GPU ページ フォールト、エントロピーを意識した配置を備えた GMI Cloud の Kubernetes ネイティブ推論プラットフォームです。この講演では、GMI が CNCF インキュベーション プロジェクトである Karmada を使用して、マルチクラスター ガバナンス、CRD 分散、フェイルオーバーの準備、およびグローバル AI サービスのプラットフォーム配信を改善する方法について説明します。 議題 1. 地域や GPU ベンダー全体でグローバルな AI 推論を実行する際のビジネス上の課題 2. Karmada が役立つ場所: マルチクラスター ガバナンス、CRD 分散、フェイルオーバー、一貫性 3. GMI 推論エンジンが役立つ場所: ルーティング、GPU 認識、弾力性、および配置 4. オープンソース Karmada が GMI の実稼働プラットフォームをどのようにサポートするか 5. コミュニティのための教訓とコラボレーションの機会

水曜日午後のプロジェクト表 | 15:15 - 19:15 T-1カイロス T-2 ヘッドランプ T-3 キークローク T-4 コミュニティ主導のイベント + TCG T-5 クベフロー T-6 オープンクラスター管理 T-7 アクリ T-8 イスティオ

プラットフォーム エンジニアリング チームは、内部プラットフォーム、自動化、セルフサービス インフラストラクチャ、より優れた開発者エクスペリエンスなど、強力なクラウド ネイティブ機能を構築しています。しかし多くの人は、なぜこの作品が投資に値するのかを説明するのに苦労している。 このセッションでは、クラウド ネイティブ ツールとプラットフォームを評価する組織の実例と、技術プラットフォームの改善を測定可能なビジネス インパクトにどのように結び付けることに成功したかを共有します。 チームが開発者の生産性、運用効率、プラットフォームの成熟度を、幹部が資金調達の決定に使用する言語にどのように変換したかを示します。チームがクラウド ネイティブ投資への賛同を得るのに役立った正確な資料、指標、枠組みがわかります。 社内プラットフォームを構築している場合でも、インフラストラクチャを最新化している場合でも、この講演では、単なる技術的なアップグレードではなく、ビジネスを実現するものとして自分の仕事を位置づける方法について実践的なガイダンスを提供します。

あなたのチームは、Ingress NGINX が廃止されたと聞きました。誰かが Gateway API に移行する必要がありますが、その誰かがあなたです。どこから始めますか? このセッションは、Gateway API に触れたことのない初心者向けです。この PoC では、17 のシナリオにわたって 7 つの実装をテストし、最初の移行のための最も単純なパスを抽出しました。 中心となるのは、分割画面での 5 分間のライブ チャレンジです。一方の側では、動作中の Ingress エンドポイントに対して継続的なカールを実行します。その後、Ingress が削除され、curl が失敗し始めます。 ingress2gateway を使用すると、構成が変換され、ゲートウェイ API リソースが同じ IP でデプロイされ、URL を変更せずに同じカールが回復されます。観客は、働く、壊れる、回復するというサイクル全体を観察します。 構成: 変更内容とその理由 (5 分)、核となる概念と 7 つのテスト済み実装からのこのパスの理由 (5 分)、5 分間のライブ移行チャレンジ (10 分)、次のステップとゲートウェイ準備スコア (5 分)、Q&A (5 分)。参加者は、自分のクラスターを試す準備ができて退席します。

現在、アプリケーションはエージェントに移行しつつあります。一方、エージェントによって取得または生成されたコードは信頼できる製品として扱うことができないため、機密データとインフラストラクチャ コントロール プレーンはエージェントが直接触れないようにする必要があります。 既存の (実証済みの) Kubernetes インフラストラクチャに基づいて、私たち (kata コンテナー開発者、ant オープンソース チーム、および日本の AI チーム) は、エージェント サンドボックス、Kata コンテナー、トンボ、および pvm カーネル仮想化ドライバーを使用してサンドボックス サービスを構築します。これにより、サービスが安全であるだけでなく、十分な安全性も確保されます。 このセッションではライブデモが表示されます。

エンタープライズ規模では、社内 AI エージェントを運用環境に展開することは、機密性、ガバナンス、レビューの品質、コストに及ぶプラットフォームの課題になります。このセッションでは、ソニー インタラクティブ エンタテインメントのエンジニアリング イネーブルメント チームが、初期の実験から 400 以上の PlayStation 内部リポジトリにわたる実稼働展開まで、コード レビュー AI エージェントをどのように行ったかを検証します。 この講演では、機密コードを保護し、セキュリティとコンプライアンスの要件を満たし、需要に合わせて Kubernetes ワークロードを拡張しながら、共有エンタープライズ プラットフォーム上で AI 支援レビューを導入することの背後にあるアーキテクチャと運用のトレードオフについて探ります。ロールアウトとガバナンスのパターン、品質評価、コスト管理、人間の判断と AI が生成するフィードバックの間の運用上の境界について説明します。 参加者は、共有エンタープライズ プラットフォーム上で AI 支援開発ワークフローを導入および運用するための実践的なパターンを学びます。

システムが拡大しても、データが消えることはほとんどなく、蓄積されるだけです。大規模なプラットフォームの場合、これは隠れた重大な問題を引き起こします。つまり、無制限のデータ増加がインフラストラクチャのコストと移行リスクの主な要因となります。 メルカリでは、プラットフォームの拡大に伴い、コアの MySQL テーブルの 1 つが数十億規模のレコードに達しました。クラウド ネイティブの分散データベース (TiDB) への移行中に、ライブ トラフィックではなく、過去の非アクティブなデータが、コストと移行の複雑さに影響を与える重要な要因となっていることがわかりました。 この講演では、完全なユーザー向け機能とデータ アクセシビリティを維持しながら、アクティブなユーザー ワークフローに寄与しなくなった休眠レコードの影響を軽減することに焦点を当てた、大規模なデータ ライフサイクル管理戦略の設計と実行に関する実際のケース スタディを紹介します。 このセッションでは、クラウド ネイティブ環境でのデータ増加を管理するための実践的なパターンに焦点を当て、データ ライフサイクル管理が後付けではなく、スケーラブルなプラットフォーム戦略の一部である必要がある理由を強調します。

AI エージェントとエージェント ワークフローはアプリケーションの構築方法に革命をもたらし、市場は急速に拡大しています。この統合の開発中の標準の 1 つが MCP です。 エージェントに提供する機能が増え、エージェントを統合するほど、エージェントのアクティビティに対する正確かつ効果的な承認が重視されるようになります。 KeycloakはMCPの認可部分をサポートします。このセッションでは、MCPのさまざまなバージョンとKeycloakの機能を紹介し、エージェントの認可サーバーとして使用するためにKeycloakを構成する方法を示します。 また、動的クライアント登録、CIMD、既存のワークロード ID の活用など、Keylcoak の他の AI 関連機能についてもまとめます。次に、今後数か月以内に Keycloak のロードマップにどのような AI 機能が含まれるかを見ていきます。

Maintainer Meetup は、CNCF Maintainer がベスト プラクティスを共有し、貢献プロセスに詳しく入り、プロジェクト全体にわたる共通の問題を解決するためのものです。

このセッションでは、Canonical エコシステムを使用してマイクロサービスを構築および運用する実践的な方法を示します。オーケストレーション、オペレーター、小規模で安全な Ubuntu ベースのコンテナー イメージの構築について説明します。また、コンテナー イメージのサイズと攻撃対象領域を削減する方法と、同じツールを Kubernetes と仮想マシン間で使用する方法についても説明します。実際のアプリケーションの配信、つまり展開、監視、拡張、保守が容易なサービスに焦点を当てています。

「当社の通信クラウドでダウンタイムなしで Ceph をアップグレードします。」これは、セキュリティ パッチ、バグ修正、ベンダーやコミュニティからの継続的なサポートを確保するために 1 ～ 2 年ごとの必須要件です。 5G コア ワークロード (AMF、UPF など) を実行するベアメタル上にデプロイされた 10 ～ 50 ノードを備えた Ceph Cluster バージョン 18.x.x があります。 この講演では、Reef → Squid の実際のアップグレードについて、実際の 3 つの失敗シナリオを交えて説明します。 - クォーラム損失の監視: 根本原因の分析、回復シーケンス、デーモンのローリング再起動中のクォーラムの低下を防ぐ方法 - リバランスによって引き起こされ、クラスターの安定性を脅かす OSD ストーム - 互換性のないクライアント バージョンがアップグレード パスをサイレントにブロックする 障害回復以外にも、プリフライト チェック、デーモン アップグレード順序 (MGR → MON → OSD → MDS/RGW) をカバーする、私たちが開発したアップグレード シーケンス戦略を共有します。 参加者は、再利用可能なアップグレード前チェックリストと、一か八かの環境におけるベアメタル Ceph のシーケンス フレームワークを手にして帰ります。

脆弱性管理は進化するトピックであり、エージェントを事前にコーディングするのは大変でしたが、現在ではセキュリティ チームや認証チームにとって負担の大きいものになる可能性があります。マルチバージョンのサポート、マルチテナント、個別の導入の波が加わると、軽減されない頭痛のレシピが完成します。 このトピックの Grafana の旅に参加して、3 年前に CVE-2023-3128 にどのように対処したか、そして現在、クラウド環境から世界中の何百万もの Grafana インスタンスまで脆弱性の分類とパッチ配布をどのように処理しているかを詳しく掘り下げていきます。 脆弱性と意図された機能を区別する方法、脆弱性パッチの展開を調整する方法、展開を危険にさらさずにユーザーのコミュニティに対して透明性を保つ方法を学びます。大量のプル リクエストや AI によって生成された脆弱性レポートによるプレッシャーの増大にメンテナーが直面している場合、セキュリティ プラクティスを改善し、進歩させることが重要な必要性になります。

このセッションでは、プラットフォーム チームが Kubernetes 上で基本的なモデル提供から運用グレードの分散推論にどのように進化できるかを探ります。 KAITO は、厳選されたプリセット、GPU ノードの自動プロビジョニング、自動スケーリング、OpenAI 互換エンドポイント、vLLM などのランタイムのサポートにより、モデルのオンボーディングとライフサイクル管理を合理化します。 llm-d は、推論対応スケジューリング、KV キャッシュ対応ルーティング、クロスノード キャッシュ調整、プリフィル/デコード分離、およびワークロード対応自動スケーリングによってこの基盤を拡張します。この講演では、デプロイメントと推論ルーティングを別個の関心事として扱うのではなく、Kubernetes 上で両方を統合する実用的なリファレンス アーキテクチャを紹介します。また、Gateway API Inference Extension が InferencePool、Endpoint Picker、Body Based Routing などの共通インターフェイスとして機能する方法と、チームが基本的なサービス提供から分散推論にいつ移行する必要があるかについても説明します。

エンジニアが「なぜこのサービスは失敗するのか?」と尋ねたとき、その答えが 1 か所で見つかることはほとんどありません。メトリクスは Prometheus に、ログは Loki に、異常シグナルは他の場所に、運用上の知識は Runbook に存在します。既存の AI アプローチ (RAG、Text-to-PromQL、シングルツール コパイロット) はそれぞれ 1 つのドメイン内ではうまく機能しますが、ドメイン全体で信号を接続するのに苦労しています。当社は、ナレッジ グラフ、メタデータ キャッシュ、クロスドメイン リレーションシップ モデリングを使用して、サービス、メトリクス、ログ、異常、ドキュメントを事前にリンクする、プラットフォームの可観測性のための AI コンテキスト ファブリックを提供します。これらはすべてモデル コンテキスト プロトコル (MCP) 経由でエージェントに公開されます。エージェントに生の断片化されたデータを強制的に結合させるのではなく、ファブリックはエージェントに、グラウンディングされたクロスドメインのコンテキストを渡します。私たちのアーキテクチャは、メタデータを瞬時に検出するためのスキーマ キャッシュ、セマンティック エッジを備えたドキュメント ナレッジ グラフ、および MCP によって統合されたメトリクス カタログを組み合わせています。その結果、根本原因の分析が迅速化され、より明確な推論が可能になり、トークン コストが大幅に削減されます。

クラウド ネイティブ エコシステムの積極的な貢献者にとって、最大の課題は多くの場合コードではなく、より広い視野、つまり影響力を活用してプロジェクトをより健全で持続可能なコミュニティに導く方法への移行です。真のオープンソースのリーダーシップとは、決して権力を掌握したりタイトルを獲得したりすることではありません。それは、コンセンサスを促進し、多様なマルチベンダーのエコシステム全体で共通のビジョンを構築することに根ざしています。 このパネルでは、4 人の CNCF TOC メンバーがマクロレベルの視点と実践的なガバナンスの経験を組み合わせて、コンセンサスを促進することで技術的な影響力を自然に確立する方法を解体します。 取り上げる主なトピック: - マインドセットの変化: 戦術的な「問題解決者」から戦略的なコミュニティ管理者への進化。 - 共有ビジョン: 企業の利益を超えて、真のベンダー中立的なコンセンサスを実現します。 - 対立の回避: プロジェクトを前進させるために技術的な意見の相違を解決します。 - 持続可能性: 他者に力を与え、健全な指導パイプラインを構築します。

「過去 1 年間、SIG Scheduling は、Kubernetes のスケジューリングへのアプローチを再定義し、Pod 中心のモデルから全体的なワークロードを意識したアーキテクチャに移行しました。この変化は、スケジューラーの内部だけでなく、新しい API セットを介して kube-scheduler と対話または統合する多くの外部コンポーネントにも影響を与えます。 このセッションでは、最近のリリースで導入された主なスケジューリング機能強化について説明し、それらがより広範なワークロード認識スケジューリング イニシアチブにどのように適合するかについて説明します。また、Kueue や Descheduler など、関連するサブプロジェクトからの更新情報も共有します。 最後に、今後のリリースの予定を提示し、コミュニティの貢献を要約し、Kubernetes スケジューリングの将来の形成に役立つ機会を概説します。」

「AI統合が成熟するにつれて、認証はアーキテクチャ上の重要な懸案事項となっています。最新のMCP認証仕様（2025-11-25バージョン）は、動的環境でクライアントIDがどのように処理されるかを再定義しており、Keycloakはこれらの要件をサポートするようになりました。」 このセッションでは、最新の MCP 認可モデルの背後にある中心的な考え方と、それが認可サーバーに要求するものについて説明します。クライアントを識別する方法としてのクライアント ID メタデータ ドキュメント (CIMD) の使用に焦点を当てており、動的に提供されるクライアント メタデータが認可の決定と運用上の責任にどのように影響するかを強調しています。 このセッションには、Keycloakが最新のMCP認可モデルを実際にどのようにサポートするかを示すライブデモンストレーションが含まれています。参加者は、KeycloakがCIMDベースのクライアント情報を処理し、認可決定を強制する方法を確認し、標準のKeycloak機能を使用してMCP認可フローを実装する方法を説明します。」

Fluent Bit は、リソースに制約のある環境でログ、メトリクス、トレースを処理するためのベンダー中立のテレメトリ エージェントです。 5 年間にわたって、軽量のログ フォワーダーから、グローバルな可観測性パイプラインのコア コンポーネントに成長しました。 運用環境では、非 UTF-8 入力 (GBK、Shift-JIS など) は、エッジ ケースではなくベースライン要件になりました。このセッションでは、CNCF プロジェクトとして Fluent Bit を維持することから得た教訓、つまりマルチ テレメトリのサポート、エッジ パフォーマンスの制約、文字エンコーディングの曖昧さについて共有します。システム上の課題として、主要な設計上のトレードオフ、非 UTF-8 ログのアーキテクチャへの影響、UTF-16→UTF-8 などの境界変換について説明します。 また、既存の仕様に照らして決定論的なエンコード変換ルールを検証し、見つけにくいエッジ ケースを明らかにするための実用的なオフライン ワークフローも示します。

エンタープライズ開発者はどうすれば 165 日ではなく 30 分でコーディングを開始できるのでしょうか?プラットフォーム エンジニアリングは多くの場合、グリーンフィールド環境で理想化されますが、大企業はレガシー プロセスの迷宮に直面しています。 JAL デジタルでは、500 のシステムをサポートする 4,000 人のエンジニアがサイロ化されており、環境セットアップには 15 の部門と 40 以上のフォームが必要で、165 日という驚異的なリードタイムに達していました。 私たちは、「私たち対彼ら」の対立を終わらせるための混合チーム、情熱を燃やすバックステージなどの独自のテクノロジーをチームに選択させることによる燃料としての自律性、そして信頼を獲得するために最初に摩擦の高いボトルネックをターゲットにすることによる小さな勝利の3つの柱に焦点を当てた、真の文化的変化を通じてこの硬直した組織を変革するという私たちの旅を共有します。 従来の承認を「ワンクリック」エクスペリエンスに自動化するアーキテクチャをデモンストレーションします。この物語は、官僚制度に囚われているすべてのエンジニア、特に次世代に向けたものです。開発者が実際に使用したいプラットフォームを構築するための実践的で人間中心の手順を学びます。

クラウドネイティブ システムが拡大するにつれて、予測可能な低遅延および高スループットのネットワーキングを実現することが重要な課題となっています。従来のネットワーキング スタックによって生じるオーバーヘッドにより、遅延の影響を受けやすいワークロードのパフォーマンスがますます制限されます。 このセッションはカーネル バイパス テクノロジの入門ガイドとして機能し、基礎から最新の研究に至るまでのトピックを理解するための構造化された道筋を提供します。中心的な概念から始まり、カーネル バイパスがパフォーマンスを大幅に向上できる理由を説明します。次に講演では、講演者自身の研究を含むユーザー空間の TCP/IP スタックの進歩を紹介し、重要な設計の選択、トレードオフ、およびほぼハードウェア レベルのパフォーマンスに近づく実験結果について議論します。 最後に、このセッションでは、Kubernetes 指向の導入モデルと統合の課題の概要を説明することで、これらのアイデアを実践に結びつけ、参加者が高性能クラウドネイティブ ネットワーキングの現在の機能と将来の方向性を理解できるようにします。

GPU の需要が予測不能になったとき、私たちの ML プラットフォーム チームは壁にぶつかりました。高価なオンプレミス GPU が他のジョブでアイドル状態になっている間、微調整ジョブは忙しい日には何時間もキューに入れられていました。クラウド GPU クラスターを追加すると容量は解決されましたが、ワークフローが分断され、開発者は複数の kubeconfig をやりくりし、Kueue はクラスター間のキューを認識できず、「マルチクラスター」は実際には共有ダッシュボードを備えた単に分離されたクラスターであったため、ワークロードはフェイルオーバーできませんでした。 この講演では、Liqo の仮想ノード パターンを使用して 5 つの異種クラスターを統合し、オンプレミスの A100/H100 ノードとクラウド プロバイダーのクラウド スポット GPU インスタンスを混合して、単一のスケジュール可能なトポロジに統合する方法について説明します。標準的な Kubernetes スケジューラーが標準のノード セレクターとアフィニティを使用して配置を処理する方法、Cilium のクラスター メッシュがクラスター間ポッド トラフィック用の Liqo の WireGuard ベースのネットワーク ファブリックとどのように比較されるか、仮想クラスター全体で統合ジョブ キューイングを行うために Kueue を統合する方法について共有します。

Kubernetes を学び、オープンソースに貢献したいと考えている人々にとって、実際のインフラストラクチャへのアクセスは最大の障壁の 1 つです。この障壁を下げるために、Cloud Native 台湾ユーザー グループは、台湾の学生、開発者、オープンソース コミュニティに無料のインフラストラクチャ リソースを提供する、コミュニティがサポートするプラットフォームである Infra Labs を作成しました。 この講演では、地域コミュニティが学習とコラボレーションをサポートする共有インフラストラクチャをどのように構築したか、もう 1 つは ChengHao Yang が Infra Labs を使用して 2023 年に Kubernetes の学習を開始し、30 件の記事を執筆し、2024 年に Kubespray に寄稿し、レビュー担当者となり、その後 2025 年に Kubespray メンテナになった経緯についての 2 つの関連するストーリーを共有します。このセッションでは、コミュニティが構築したインフラストラクチャがどのように障壁を軽減し、機会を創出し、次世代のオープンソース コントリビュータの成長に役立つかを示します。

Longhorn は、Kubernetes およびコンテナーや仮想マシンなどのさまざまなワークロード向けに構築されたクラウドネイティブの分散ブロック ストレージ ソリューションです。他のソフトウェア プラットフォームのインフラストラクチャ コンポーネントとして広く統合されており、さまざまな環境で採用され、動的システムと不変システムの両方で動作し、世界中で何十万もの導入が行われています。現在、CNCF が後援しており、卒業に向けて取り組んでいる育成プロジェクトです。このプレゼンテーションでは、最近のメジャー リリース、将来の計画、コミュニティ、ユーザー導入ストーリー、プロジェクト間のコラボレーションについて最新情報をお伝えします。さらに、Longhorn のアーキテクチャと設計の概要と、最近の Longhorn 1.12 リリースにおける V2 データ エンジンの主要な成熟度マイルストーンについて詳しく説明します。

クラウド ネイティブ コミュニティは単なるオープンソース プロジェクトではなく、個人が新しいスキルを学び、プロフェッショナル ネットワークを構築し、キャリアを加速するための場所です。最初のステップが認定資格の取得であれ、ローカル コミュニティへの参加であれ、ドキュメントの修正であれ、コードの貢献であれ、新しい参加者は皆、クラウド ネイティブを推進し続けるための新鮮なアイデアとエネルギーをもたらします。この基調講演では、Jeffrey Sica が参加するための実践的な方法を共有し、クラウド ネイティブの取り組みを構築することがキャリアとグローバル コミュニティの将来の両方を形作るのにどのように役立つかを示します。

それは、同僚がワークロードをデプロイし、ノードが自動的にスケールアップするのを観察することから始まり、すべて k9s を通じてリアルタイムで確認できました。その好奇心が CKA につながりました。CKA には 2 回の試行が必要でした。しかし、合格すると次の試験がどれだけ重なっているかが明らかになったので、彼はそのまま進み続けて Kubestronaut を獲得しました。次に、「これまで触れたことのない CNCF テクノロジーについてはどうですか?」という新たな質問が生まれました。 Raspberry Pi の自宅ラボでは、なじみのないツールが真の興味に変わり、気が付けば 15 件の認定すべてが 14 か月で完了しました。このライトニング トークでは、その予期せぬ連鎖反応を追跡します。参加者は次のことを学びます: 1. 必要なのは好奇心だけです - 経験は必要ありません 2. 1 つのステップが次のステップにつながります - それぞれの試験が次の試験への扉を開きます。勢いが自然に高まる 3. 最も難しいのは最初のステップです。15 を目指す必要はありません。興味のあるものを試してみてください

Cloud Native Community Japan (CNCJ) は、地域のミートアップ、トピックに焦点を当てたコミュニティ、関連組織とのコラボレーション、新規参入者が上流への貢献を模索するのに役立つプログラムを通じて、日本中の人々を結びつけます。このセッションでは、クラウド ネイティブ コミュニティへの最初の一歩から、エクスペリエンスを共有し、より広範な CNCF エコシステムに貢献するまで、参加するためのさまざまな方法を紹介します。また、CNCJ の最新の活動と、地域と世界の両方でつながり、協力し、影響を与える新たな機会にも焦点を当てています。

OpenTracing と OpenCensus の統合から 7 年後、OpenTelemetry は CNCF の卒業を祝い、本番環境のセキュリティとスケールを克服し、セマンティック規約を安定させ、4 つのコア データ信号すべてを単一の相互運用可能なファブリックに統合することに成功しました。 OpenTelemetry が次のフロンティアに入る中、Agentic AI、高効率の OTel-Arrow トランスポート、継続的プロファイリング、およびスマートなエンティティ駆動型サンプリングのネイティブ サポートを推進する、インテリジェントな可観測性の新時代を明らかにできることを嬉しく思います。 ぜひ祝って、次世代のオープンソースの可観測性の構築に参加してください。

PowerX は日本全国で 200 台以上の EV 充電器を運用しており、それらを確実に稼働し続けることが当社のサービスにとって最も重要な課題です。信頼性を維持しながら多数のエッジ デバイスにわたるソフトウェアを管理することは、当社の SRE チームにとって常に大きな負担でした。特に、リソースが限られているデバイスが混在する環境で一貫した動作を実現することは特に困難であることが判明しました。 この基調講演では、これらの課題に対処するために私たちが実践したソリューション、つまり Kubernetes 上に大規模なエッジ管理システムを構築することについて要約します。 利用可能な多くのオプションの中から Kubernetes を選択したのはなぜですか。また、特に k0s を採用したのはなぜですか? クラウド（GKE）とエッジを接続するハイブリッド クラスタをどのように設計したのでしょうか? リソースに制約のあるデバイスからメトリクスを効率的に収集するにはどうすればよいでしょうか。また、可観測性を確保するために OpenTelemetry のプッシュベースとプルベースのアプローチをどのように切り替えるのでしょうか?

AI ネイティブ システムが主流になるにつれ、MCP のようなエージェント AI エコシステムのガバナンスをサポートするために、アイデンティティに関する標準の数が増えています。標準の小さな誤用でも、重大なインシデントにつながる可能性があります。 基調講演では、複雑な情勢を乗り切るのに役立つ、日本での強力な活動を伴う 2 つの主要な CNCF イニシアチブを紹介します。まず、IAM ホワイト ペーパー。AI プラットフォームを含むクラウド ネイティブ システムの安全な ID 基盤を構築するための実践的なガイダンスを提供します。 2 つ目は、Agentic AI の最新標準を積極的に実装している主要なオープンソース IAM ソリューションである Keycloak です。 クラウド ネイティブ コミュニティが AI ネイティブ時代に向けて信頼、セキュリティ、相互運用性をどのように構築しているかを一緒に探ってみましょう。

グリッドは分散システムになりつつある エネルギー システムは、地政学的な衝撃、電化、異常気象、デジタル インフラストラクチャによる圧力に直面しています。グリッドには新世代以上のものが必要です。柔軟性が必要です。 日本はこの課題を具体化しています。エネルギー自給率は約15％で、発電量の約7割を化石燃料に依存しています。しかし、データセンター、半導体製造、電化による需要の増加に伴い、日本は2040年度までに再生可能電力を40～50％にすることを目標としている。 太陽光発電、バッテリー、EV、ヒートポンプの普及に伴い、貴重な送電網リソースが家庭や都市に流入しつつあります。仮想発電所は、これらのデバイスを 1 つのソフトウェア定義のエネルギー資産として調整し、需要を変化させ、再生可能エネルギーを貯蔵し、回復力を向上させます。 この基調講演では、グリッドが分散システムのように動作する理由と、クラウドネイティブ パターンがグリッドの運用にどのように役立つかを探ります。 次の発電所は、ソフトウェアによって調整された 100 万戸の住宅、バッテリー、EV になる可能性があります。

AI のコンピューティングへの欲求が高まり続けるにつれ、都市部の 1 つのデータセンターは、ラックではなく電力と土地という硬い物理的な壁にぶつかります。 1 つのサイトをいくら拡張しても問題は解決しません。これは全世界が共有する課題であり、土地に乏しい日本では特に深刻な課題である。 そこで、NTT ドコモ ビジネスは 1 つのサイトを拡張するのではなく、日本全国に GPU を分散させました。 IOWN APN（オールフォトニクスネットワーク）技術で構築された広域L2ネットワーク上で、札幌から福岡まで2,000km以上に及ぶ8つのデータセンターを単一のKubernetesクラスターとして運用しています。しかし、高速なネットワークだけでは十分ではありません。本当の課題は、分散されたキャパシティを 1 つとして使用できるようにすることです。複数のテナントが安全に分離され、既存のワークロードが単一サイトのような感覚でそのまま実行されます。私たちはそれをクラウド ネイティブ テクノロジー、とりわけ KubeVirt で実現しました。 最も重要なのは、誰がそれを構築したかです。オープンソースによって集められた日本と韓国のエンジニアです。 Kubernetes と KubeVirt によって共通言語が得られたため、NTT DOCOMO BUSINESS と SK Telecom は国境を越えて対等に設計することができました。私たちの教訓: 世界全体が共有する課題は、企業と国が共同でソリューションを構築する CNCF という共通の基盤で対処できます。これは日本と韓国のエンジニアによって構築されました。私たちはここ日本から、この分散型アーキテクチャを同じ壁に直面している世界に持ち込んでいきたいと考えています。

記載なし。

木曜午前プロジェクト表 | 10:45～13:00 T-1 CoHDI T-2 繊毛 T-3 リマ T-4 コミュニティ主導のイベント + TCG T-5 ロングホーン T-6 OVN-Kubernetes T-8 オープンエベレスト

スポンサー: レッドハット デモ: ACM での動的スコアリングのデモ 小間番号：G4 イベントでの人脈作りやビジネス関係を促進するために、サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりすることもできます。サードパーティのブースを訪問したり、スポンサー付きコンテンツにアクセスしたりする必要はありません。ブースを訪問するとき、またはスポンサー活動に参加するとき、第三者はあなたの登録データの一部を受け取ります。このデータには、あなたの姓名、役職、会社名、住所、メールアドレス、標準的な人口統計に関する質問 (職務、業界など)、およびあなたが利用したスポンサー付きコンテンツやリソースに関する詳細が含まれます。ブースと対話したり、スポンサー付きコンテンツにアクセスしたりすることを選択した場合、サードパーティの受信者によるそのようなデータの受信と使用に明示的に同意したことになり、受信者には独自のプライバシー ポリシーが適用されます。

私たちの 500 GPU プラットフォームはめちゃくちゃでした。65% のアイドル時間、8 時間のデバッグ マラソン、そして年間 600 万ドルの出費で、「なぜこのジョブが失敗したのか?」に対する答えはゼロでした。 そこで私たちは何か違うものを作りました。 OpenTelemetry とカスタム GPU インストルメンテーション、NVIDIA DCGM、eBPF ベースの NCCL トレース、および Kueue と統合された ML 対応の異常検出を組み合わせた AI ネイティブの可観測性スタック。 サイレントな CUDA メモリ リーク、謎の NCCL タイムアウト、トレーニングの相違など、実際の障害を共有します。これらは、数日ではなく数分で検出できるようになりました。 12ヶ月後？ GPU アイドル時間は 65% から 19% に減少しました。トレーニングの成功率は 94% に達しました。私たちは年間 420 万ドルを節約し、ついにエンジニアは消火活動をやめました。 完全なアーキテクチャ、構成、ダッシュボード、および「10 GPU Golden Signals」ガイドはすべてオープンソースです。

この講演では、gRPC に追加されたサービス拡張機能である ExtAuthz と ExtProc について紹介します。 gRPC は、インターセプトを外部プロキシに依存するのではなく、xDS 経由で外部サービスへのサイド チャネル コールアウトのサポートを追加しました。 ExtAuthz: ピア ID とメタデータを外部サービスに送信することで、リアルタイム認証を実行します。これにより、RPC が処理される前に動的な「許可/拒否」の決定が可能になります。 ExtProc: 特殊な「GRPC」処理モードを使用して、ヘッダーと gRPC メッセージ本文のディープ パケット インターセプトを提供します。これにより、高度なペイロード変換、PII マスキング、メッセージ レベルのフィルタリングが可能になります。 これにより、複雑なロジックをアプリケーションから切り離し、それをプラグ可能な xDS マネージド サービスに集中化することで、「Security as a Service」モデルが可能になります。 このセッションは、カスタム セキュリティ、ロギング、ビジネス ロジックを gRPC データ プレーンに直接導入しようとしている開発者向けの技術ロードマップです。

「可観測性」が産業用「IoT」と出会うと何が起こるのでしょうか? このセッションでは、IIoT 環境で OpenTelemetry を使用できる場所について詳しく説明します。また、OTel の柔軟なアーキテクチャを使用して産業機器を観察し、予防保守を通知し、品質管理 (QC) を確保する方法についても説明します。 標準の OTLP (OpenTelemetry Protocol) とともに産業用プロトコル (MQTT、OPC-UA など) を処理し、「製造現場」のデータをクラウドネイティブの「最上階」のパイプラインにブリッジするように OpenTelemetry Collector を構成する方法について学びましょう。また、予防保守とリアルタイムの QC アラートのために OpenTelemetry メトリクスとトレースを活用する方法を学びます。

ソフトウェア部品表 (SBOM) の採用は、規制上の義務と注目を集めるサプライ チェーンの事件によって加速しています。ただし、SBOM が不正確になる可能性があるという、重大かつ過小評価されている問題が依然として残ります。従来の SBOM 生成ツールは、静的分析またはパッケージ マニフェストに依存しており、動的にダウンロードされる依存関係、ビルド時のアーティファクト、ネットワークでフェッチされたコンポーネントを日常的に見逃してしまうアプローチです。 この講演では、ビルド時に取得した完全な証明書から SBOM を生成することで精度の問題を解決するサプライ チェーン セキュリティ フレームワークである、OpenSSF プロジェクトである SBOMit について紹介します。 SBOMit は、何が使用されたかを推測するのではなく、それを観察して記録し、監視ツールを活用して、実際のビルド中のファイルシステムの読み取りと書き込み、プロセスの実行、送信ネットワーク接続を追跡します。ビルド中に発生したすべての依存関係がキャプチャされ、暗号的に認証されます。結果の SBOM は最良の推測ではありません。それは構築されたものの検証された記録です。

ポーカー プラットフォームで OpenSearch を実行すると、エラーの余地はありません。不正行為の検出は待っていられません。プレーヤー統計 API には遅れがありません。また、クラスターはトラフィックの急増を気にしません。 当社は、ハンド履歴やゲームプレイ イベントからの大量の書き込み、集約の多い不正クエリ、ライブ プレイヤー統計を提供するレイテンシに敏感な読み取りなど、混合ワークロードの下で OpenSearch を運用しています。標準的な導入アドバイスは、この組み合わせには耐えられません。 この話は純粋に運用上の話です。書き込みプレッシャー下での JVM ヒープのサイジング、一括取り込みと検索分離のためのスレッドプールの調整、シャードのサイジング、ロールオーバー戦略、不均一なトラフィックのキャパシティ プランニングについて、キューの飽和、GC の一時停止、運用環境でのホット シャードに達した後に適用した特定の緩和策とともに取り上げます。 また、インデックスのライフサイクル管理、保持のトレードオフ、OpenSearch がリクエスト パスに存在する場合に重要なシグナルの監視についても説明します。 基本的な導入パターンをはるかに超える具体的な運用ガイダンスを提供します。

Kubernetes は世界を動かしていますが、その「英語ファースト」の性質が大きな障壁となる可能性があります。 SIG Docs はローカリゼーションを通じてこのギャップを埋めますが、これらの取り組みを持続可能にするにはどうすればよいでしょうか?このセッションでは、プロジェクトで最も活発なローカリゼーション コミュニティの 1 つを育成する日本チームの歩みを探ります。無味乾燥な歴史の教訓は忘れてください。私たちは、新しい貢献者向けに実践的なロードマップと例を提供しています。 SIG Docs リポジトリをナビゲートして最初の PR を実行する方法を正確に理解して立ち上がることができます。 また、容赦ない上流速度の管理、大規模な技術的精度の確保、将来のワークフローを形成する正直な議論など、現実世界の苦闘についても「カーテンを引き戻す」つもりです。ドキュメント作成のベテランであっても、初めて貢献する人であっても、世界中のユーザーに力を与えるローカライズされたエコシステムを日本でどのように構築したかを学ぶことができます。

AI コーディング アシスタントによって作成された 37,000 件の依存関係のアップグレードに関する推奨事項のデータ セットを調査し、200,000 件のアクティブでダウンロード可能な悪意のある OSS パッケージをレビューした結果、明らかなギャップと機会が特定されました。つまり、古い防御戦略の機能が低下し、新しい攻撃パターンの機能が強化されています。この講演では、これらの発見を調査し、Linux Foundation エコシステムからのいくつかの新しいツールとガイダンスを通じて、成功への明確な道筋をリスナーに提供します。

OpenTelemetry は、可観測性の業界標準となっています。これは、CNCF によってサポートされるメトリクス、トレース、ログ用のベンダー中立の単一フレームワークです。ただし、すでにレガシーがあるものの安定している場合は、それを採用するのは別の話になります。 収集からパイプライン処理、ストレージまで「機能」する可観測性プラットフォーム。 アトラシアンでは、Observability チームが特注のメトリクス パイプラインとして statsd を長年実行してきました。これは、14 リージョンにわたる約 10 万台のホストからメトリクスを収集および集計する高性能 statsd サーバーです。それはチームにとっては役に立ちましたが、亀裂が見えてきました。UDP のみの取り込み、トレースやログのサポートなし、エコシステムの目指す方向からどんどん外れていく標準などです。 この講演では、チームが OpenTelemetry Collector ベースのパイプラインに移行し、ダウンタイムやデータ損失なしにすべてをメトリクス バックエンドに配置した理由について説明します。ここでは、それらがどのように大規模に実行されたか、OTLP ネイティブを完全に導入するための戦略、および統合された可観測性のために何が可能になるかについて説明します。

大規模な AI プラットフォームが複数のクラスターにわたって拡張されるにつれ、静的配置ポリシーは限界に達しつつあります。決定には、固定ルールだけではなく、GPU 使用率、電力効率、その他の運用指標などの実際の状況を反映する必要があります。 この講演では、マルチクラスターの配置とポリシーの決定にリアルタイムのテレメトリをもたらす、オープン クラスター管理の新しいアドオンである Dynamic Sc​​oring Framework について紹介します。軽量エージェントは、Prometheus などのソースからメトリクスを収集し、モジュラー スコアリング API を通じて評価し、結果を中央ハブにフィードします。このハイブリッド設計は、分散スコアリングと集中管理のバランスをとり、スケーラブルで柔軟な意思決定を実現します。 アーキテクチャの詳細とフレームワークによるリソース最適化のデモを通じて、スコアベースの意思決定が AI インフラストラクチャのリソース効率をどのように向上させるかを示します。参加者は、スコアベースの管理パターンと、それを AI ワークロードを超えて適用する方法を学びます。

生成 AI と LLM の導入が加速するにつれて、クラウドベースのプラットフォームは、継続的な RAG コスト、データ転送オーバーヘッドの増加、機密データに関するセキュリティ上の懸念などの課題に直面しています。ワークロードをオンプレミスに移行することが検討されていますが、これにより、GPU の選択、OSS の統合、アプリケーションとモデルのライフサイクル管理などの新たな複雑さが生じます。 これらの課題に対処するために、私たちはエッジ GPU を活用したハイブリッド AI プラットフォームを設計しました。 このセッションでは、k3s を実行するエッジ GPU サーバー上に構築された実装と、クラスターおよび GPU ワークロード管理用の Rancher を使用した実装を紹介します。 AI 開発プラットフォームとして dify をオンプレミスにデプロイし、ローカル RAG とオンプレミスおよびクラウド LLM を組み合わせたハイブリッド AI エージェント アーキテクチャを構築しました。自然言語クエリから開始して、エージェントは意図を解釈し、必要に応じてビジネス API と対話して応答を生成します。私たちは全体的なアーキテクチャと開発からの重要な洞察を共有します。

Kubernetes のマルチネットワークのサポートは長年の課題であり、ネイティブのマルチネットワーク機能への道のりは複雑で時間がかかりました。しかし、なぜ？このパネルには、さまざまな分野の専門家が集まり、AI/ML、通信、クラウド ゲーム用の RDMA などの高度な機能を備えた高性能ネットワーキング、セキュリティ、コンプライアンス、マルチテナンシーのためのネットワーク分離、VM 接続、およびデータセンター VLAN や EVPN ファブリックなどのオンプレミス インフラストラクチャへの接続などのシナリオについて議論します。彼らは一緒に、複数のネットワークを Kubernetes に統合する際のアーキテクチャ上の課題、DRA 機能などの最近のアップストリーム開発、SIG ネットワークや WG デバイス管理などのコミュニティがエコシステム全体の進歩をどのように推進しているかを調査します。このインタラクティブなセッションに参加して、マルチネットワーク サポートの現状と今後の方向性を学び、上流の貢献者やメンテナーと直接交流して質問や実際の使用例を共有してください。

kubectl と kusTOMize の機能強化がどのように設計され、構築されているか疑問に思ったことはありますか?お気に入りの機能リクエストがなぜ受け入れられなかったのか知りたいですか? このセッションでは、SIG CLI のメンテナがまず kubectl および kusTOMize コマンドの開発について説明します。使いやすさ、一貫性、テスト容易性に焦点を当てた規則とパターンについて説明します。次に、kubectl を詳しく見て、既存のコマンド構造を詳しく見てコマンドの内部をカスタマイズします。 client-go (Kubernetes API サーバーとの通信を強化するライブラリ) や、汎用性の高いコマンドを構築するためのその他の重要なライブラリの効果的な使用法について説明します。また、SIG CLI コミュニティとの最良の関わり方、質問先、および 1 回限りの貢献をプロジェクトでの継続的な役割に変える方法に関するヒントも共有します。 最初のプル リクエストを開いて Kubernetes コミュニティのアクティブな一員になるために、このセッションをそのままにしておいてください。

木曜日午後のプロジェクト表 | 13:30～15:50 T-1カイロス T-2 ヘッドランプ T-3 キークローク T-4 コミュニティ主導のイベント + TCG T-5 クベフロー T-8 オープンエベレスト

2017 年の GitOps は、アプリケーション配信のシンプルなモデルとして、4 つの核となる原則に基づいて構築されました。現在では、チームが多数のクラスターと共有プラットフォーム サービスを運用するプラットフォーム エンジニアリングの中心部分に進化しました。 この講演では、GitOps が時間の経過とともにどのように進化してきたか、初期のアプローチが大規模に機能しなくなった理由、そして、Everything as Code が自動化を可能にし、同時に構成の無秩序な拡大をどのように実現したかについて説明します。 Argo CD、Helm、KusTOMize などのツールによりスケーリングが可能になりましたが、多くの場合、システムの実際の状態が隠蔽されてしまいます。 状態ストアとしての Git の限界と、ファイルベースのプル駆動型の調整が適切に拡張できない理由について見ていきます。これは、OCI ベースの配信、Gitless GitOps、および実際の運用可能な状態ストアの提供を目的とした新しいアプローチにつながりました。 プラットフォーム チームには可視性が必要であり、サイバー レジリエンス法のような規制には明確なインフラストラクチャ サプライ チェーンが必要であり、AI 主導の運用は最終的な実際のマニフェストへのアクセスに依存します。

SNOW Corp. は、1,000 台を超える A100 GPU を運用し、トップランクの 3 つの GenAI アプリケーション (Snow、Epik、B612) で 2 億ユーザーにサービスを提供し、バイラル AI トレンドによる極端なトラフィック変動の影響を受ける 1,200 以上の AI ワークフローを処理しています。 中心的なボトルネックは、GPU をアトミック リソースとして扱う Kubernetes のネイティブ GPU スケジューリングでした。これにより、実際の G​​PU の飽和を確実に把握できない状態で、Train-to-Inference パイプラインに 2 倍のオーバープロビジョニング ペナルティが課せられます。 この講演では、vGPU 仮想化のための HAMi の統合と、プロアクティブな自動スケーリングのためのカスタム Consumer Saturation メトリクスを使用した KEDA の拡張について説明し、トラフィックが到着する前にスケーリングすることでウォームアップ レイテンシーを隠します。 スケジューラー構成、Prometheus メトリクス、Helm GitOps を介したマルチリージョン スケーリングなどの実装について詳しく説明します。結果: GPU の無駄が 50% 以上削減され、サージ時の回復が 91% 速くなりました。効率的な共有 GPU プラットフォームの実稼働ブループリントを入手できます。

Envoy は、Istio、Cilium Proxy、Envoy Gateway、および数千の運用環境を強化します。しかし、今日ではそれを延長するのは困難です。 C++ フィルターはフォークを維持することを意味します。 WASM は、サンドボックスのオーバーヘッド、限られた拡張ポイント、およびエコシステムの停滞をもたらしました。 私たちはこれを修正するために動的モジュールを構築し、現在 Databricks と Netflix で使用しています。これらを使用すると、Envoy 拡張機能を Go、Rust、または C ABI を備えた任意の言語で共有ライブラリとして作成できます。ネイティブに近いパフォーマンス、サンドボックスや再構築は不要です。両社は、C++ フォークと Wasm をネイティブ Rust に置き換え、テール レイテンシーとメモリ使用量を削減しながら、機能をより迅速に提供しています。 私たちは Envoy のメンテナおよび共同作成者として、ネットワーク フィルター、LB ポリシー、カスタム クラスターを含む 12 以上の拡張ポイントにわたって Go/Rust SDK がどのように機能するかを取り上げます。現在の BoringSSL では不可能なカーネル TLS (kTLS) を有効にする Rust TLS Transport Socket のライブ デモと、これが C++ や WASM を使用せずに拡張性を必要とする Istio、Cilium、および Envoy Gateway ユーザーにとって何を意味するかを説明します。

最新の Kubernetes ワークロードでは、実行時に実際に何が起こっているのかを理解することがますます困難になっています。従来の可観測性ツールは、特にプロセス実行全体にわたる重要な低レベルの動作を見逃すことがよくあります。 この講演では、Linux カーネルから直接高忠実度のランタイム信号をキャプチャする Sauron eBPF を活用したカーネル レベルの可観測性アプローチを紹介します。プロセスのライフサイクル イベントを追跡することにより、システムはワークロードの動作の統合されたリアルタイム ビューを構築します。 このテレメトリに加えて、Graph-AI 分析レイヤーを導入します。AI エンジンにデータが供給され、意味的に意味のあるノードの埋め込みを学習し、プロセス ツリーを時間グラフとしてモデル化します。これにより、システムはノードレベルの動作とノード間の時間的関係の両方をキャプチャできるようになり、従来のアプローチでは通常見逃していた異常の検出が可能になります。

大規模なアプリケーションは監視システムに過負荷を与えます。 Kubernetes では、作成されたすべてのポッドには、メトリクスに新しいシリーズが追加されるという副作用があります。単純なロールアウトとロールバックでもカーディナリティが 3 倍になります。 Prometheus と OTel には記録ルール、ストリーム集約、シャーディングなどのソリューションがありますが、それらのすべてにはトレードオフが伴います。 Reddit では、別の角度から問題を検討することにするまで、これらのオプションでは不十分であることがわかりました。私たちはメトリクスを収集するためのステートレス アルゴリズムを設計しました。これは、精度やパフォーマンスを犠牲にせず、ポッドの出入りに応じてカーディナリティが急増することもありません。運用環境では、コンピューティング コストが 90% 削減されました。 この講演では、アルゴリズム、課題、実験について直観的かつ視覚的に説明します。現在のオプションでは機能しないのになぜそれが機能するのかを学び、時系列データベースにそれを実装する方法をしっかりと理解して終了します。

GPU での推論は、間違った画像やアーティファクト、不一致の CUDA やランタイム、過小な GPU メモリ、不正なリソース要求、またはオフライン チェックには合格するが実際のトラフィックの下では後退するモデルなど、繰り返し失敗します。共有 k8s GPU プラットフォームでは、これらの間違いはマルチテナント インシデント (ノイジー ネイバー、OOMKill、SLO 違反、アクセラレータ時間を無駄にするロールバック) になります。 この講演では、あるチームが推論ワークロード、運用トラフィックの前に適用されるチェック、コンテナーとモデルのアーティファクト、GPU の容量と可視性の契約、健全性と準備のセマンティクス、および最小限の可観測性 (使用されているメトリクス/トレース) の適合性をどのように構築したかについて説明します。 出席者は、再利用できる実用的なチェックリストを手にして帰ります。 - 「ビルド」と「サービス」の適合性を区別する方法、 - リグレッションを早期に発見する方法と - GPU のスケジューリングとクォータを推論 SLO に合わせる方法。 何がうまくいき、何がうまくいかなかったのか、チームが反対したこと、そしてプラットフォームとアプリの所有者向けの短いチェックリストを共有します。

2026 年 3 月、CNCF TAG セキュリティとコンプライアンスは、CNCF ID およびアクセス管理 (IAM) ホワイトペーパーを発行し、クラウド ネイティブ システムで認証と認可を設計および実装する方法に関する実践的なガイダンスを提供しました。 ホワイトペーパーの著者が発表するこのセッションでは、ドキュメントの背後にある意図、範囲、アーキテクチャ上の決定について説明します。この講演では、IAM 製品や実装の詳細を紹介するのではなく、TAG が認証と認可の要件を 2 つの再利用可能な参照パターン (Basic と Advanced) にどのように構造化したか、そして各パターンがその信頼境界と施行責任をどのように定義するかに焦点を当てます。 このセッションは、これらの設計選択の背後にある理由を共有することで、アーキテクトと開発者がクラウド ネイティブ システムでの認証および認可メカニズムを設計、レビュー、進化させる際に、共有アーキテクチャ ベースラインとして IAM ホワイトペーパーを適用できるように支援することを目的としています。

AI エージェントの採用が増えるにつれて、LLM の使用量とその実行コストも増加します。セルフホスト型 LLM 推論プラットフォームは、企業がコスト、セキュリティ、ガバナンスの制御を取り戻すために模索しているアプローチの 1 つです。しかし、これには大きな課題が伴います。チームにはさまざまなユースケース、アクセス パターン、セキュリティ要件があるからです。 API エンドポイントのみが必要な場合もあれば、完全な管理制御が必要な場合もあります。従来の名前空間の分離では、両方を満たすことができません。同時に、トークンあたりのコストを低く抑えるには、GPU 使用率を高めることが重要です。共有されているにもかかわらず、大規模に孤立している - この矛盾をどのように解決しますか? この講演では、Kubernetes 上で LLM 推論プラットフォームを構築することから得た実践的な洞察を共有します。これには、テナントの分離、動的で詳細な GPU 割り当て、およびそれらの間のトレードオフが含まれます。この矛盾をどのように解決したかを、実践的なパターンとともに示します。

仮想発電所 (VPP) は、何千もの分散型 IoT デバイス (太陽光発電システム、バッテリー、EV 充電器) を 1 つの調整されたクラウドネイティブ資産に変えることで、エネルギーグリッドを再構築しています。 Enpal では、ヨーロッパ最大級の住宅用太陽光発電システムを運用しており、それを調整するための次世代 VPP プラットフォームを構築しています。 この講演では、ソフトウェアで発電所を構築することが実際に何を意味するのか、そしてなぜ IoT 向けの開発が一般的なクラウド アプリ開発とまったく似ていないのかを探ります。 次のことを学びます: 1. 送電網の仕組み (例付き!) 2. 仮想発電所の仕組み - 家庭用太陽光発電から市場入札まで 3. Enpal の IoT とクラウド システムがどのように連携してエネルギーの使用と収益をリアルタイムで最適化するか 4. 100,000 戸以上の住宅を分散クラスターのように扱うことができる設計パターン (Kubernetes、KubeEdge、Dapr、イベント ストリーミング) 5. VPP が収益を得る方法 - 柔軟性市場、負荷シフト、価格裁定取引を通じて

頻繁に再起動する Kubernetes 上のアプリケーションにとって、起動の信頼性は非常に重要です。キャッシュの初期化と JIT コンパイルからのコールド スタートはパフォーマンスを低下させ、起動エラーを引き起こす可能性があり、ロールアウト中に深刻なダウンタイムを引き起こし、ポッドの水平自動スケーリングの有効性を低下させます。 最近の Kubernetes 機能のインプレース ポッド サイズ変更により、CPU バーストが可能になり、インフラストラクチャ レベルのスケーリングを通じて起動の信頼性が向上します。ただし、アプリケーション層の未準備状態には対処できず、ノイジーネイバーの問題や予期しない実行時の動作などのリスクが発生する可能性があります。 このセッションでは、打ち上げの信頼性を向上させるための最近の傾向と実践方法を調査し、実際のインプレース ポッド サイズ変更について検討します。さらに、これらのリスクを軽減し、包括的な対応を確保するために設計された専用のオープンソース コントローラーを使用した戦略を提案します。このセッションでは、Kubernetes 上で信頼性の高い運用グレードの起動を実現するための実用的な洞察を得ることができます。

誰がその GPU を要求したのか、なぜそれを持っているのか、いつ返してくれるのか? DRA を実行しているほとんどのクラスターでは、誰も知りません。基本的な RBAC を持つユーザーは誰でも、本人確認、正当化、有効期限なしで GPU を要求できます。 この話はそれを解決します。講演者は、DRA ResourceClaim の作成をインターセプトし、Dex による人間の認証、グループベースのデバイスクラス認可、必須の正当性、チーム予算の強制、および時間ベースの制約などの ID 認識ポリシーを強制する、オープンソースの検証アドミッション Webhook をデモします。 SPIRE はワークロード SVID を発行して、人間から GPU デバイスへの暗号化 ID チェーンを作成します。 TTL コントローラーは、セッションが期限切れになると自動的に GPU を再利用します。 ライブ デモでは、CNCF に準拠したツールのみを使用して、5 つの拒否シナリオと、承認からクリーンアップまでの完全なライフサイクルを説明します。参加者は、展開可能なアーキテクチャとオープンソース リポジトリを手にして帰ります。

新しいシステムが古いシステムと一致することを証明することは、レガシー移行の最も難しい部分です。等価性テストを最初から作成するのは時間がかかり、コストもかかります。 この修正は、ライブ システムがすでに出力しているものを再利用することです。要求/応答のペアを OTel トレース スパンとしてキャプチャし、置き換えをテストするためのグラウンド トゥルースとして扱います。 Java から Go への移行に関する PoC により、これが機能することが確認されました。 4 つの CRUD エンドポイントが装備されました。スパンは 4 つすべてをカバーする E2E テストを推進しました。 OTel の標準規則では HTTP 応答本文がキャプチャされないため、可観測性トレースは自動的にはテストに役立ちません。カスタム属性は必須です。 PoC では、コードを変更せずにトレースする OBI (opentelemetry-ebpf-instrumentation) もテストしました。基本的なカバレッジは機能します。ただし、eBPF 経由でカスタム属性を追加するのは現実的ではないため、OBI だけではテスト品質のトレースには十分ではありません。 OTel トレースが移行テストに十分な場合とそうでない場合、および OBI がギャップを埋めるかどうかを知ることができます。

組織を越えたデータコラボレーションが現代のコンピューティングの中心となるにつれ、共同処理中に機密データと独自のコードを保護することがますます課題となっています。 Confidential Computing (CC) は、ハードウェア強制の信頼できる実行環境 (TEE) に基づいており、データを公開することなく安全に処理できます。このセッションでは、複数のデータ プロバイダーとアプリケーション所有者が、データとアプリケーションの両方を相互に機密にしながら、共有コンピューティングに資産を提供する概念である「マルチパーティ コンフィデンシャル コンピューティング (MPCC)」について紹介します。このモデルは、アクセス制御や相互信頼に依存するのではなく、TEE とファイル暗号化を使用して、当事者間のランタイム分離を強制します。講演者は、複数の TEE にわたる認証の調整、実行後の監査可能性、基盤となるクラウドからの分離といった主要なメカニズムが、Kata コンテナや機密コンテナなどのオープンソース テクノロジを使用してどのように実現できるかを示します。

このセッションでは、AI トレーニングと推論ワークロードの需要の高まりに応えるように設計された Kubernetes エコシステムの最近の開発について説明します。 まず、エコシステム プロジェクトの状況を調査し、JobSet の最新の更新とともに、これらの取り組みの基礎となる構成要素であるコア Kubernetes Job API の最近の機能強化に焦点を当てます。 次に、堅牢な AI/ML プラットフォームとしての Kueue の機能を実証し、マルチクラスター ディスパッチング、フェア シェアリング、トポロジ認識スケジューリングなどの機能がどのようにテナント全体でのハードウェア使用率を最大化するかを示します。 最後に、バッチ セマンティクスをコア スケジューラに深く統合することを目的とした「ワークロード認識スケジューリング」に関する SIG Scheduling とのコラボレーションについて詳しく説明します。

組織が基本的な LLM 統合を超えて自律的なエージェント ワークフローに移行するにつれて、これらのシステムをサポートするために必要なインフラストラクチャはますます複雑になります。運用環境でマルチエージェント アーキテクチャを実行すると、ツールの検出、安全なアクセス、トラフィック ルーティングに関して特有の課題が生じます。 このセッションでは、Kubernetes とクラウドネイティブの抽象化を活用して AI エージェントを大規模に開発、テスト、デプロイする方法について説明します。 Kagenti プロジェクトを活用したリファレンス アーキテクチャを使用して、安全でスケーラブルなエージェント環境を構築する方法を示します。この講演では、MCP ゲートウェイを介したツール アクセスの統合、SPIFFE/SPIRE によるゼロトラスト ワークロード ID の強制、エージェント間通信の標準化について説明します。 これらの概念を説明するために、実際の金融ユースケースを見ていきます。自律エージェントは市場データに安全にアクセスし、MCP 上の金融ツールを使用してシミュレートされたトランザクションを実行し、エンドツーエンドのクラウドネイティブ展開を示します。

CoHDI (Composable Hardware in Disaggregated Infrastructure) プロジェクトにより、Kubernetes ベースのクラウド ネイティブ環境で GPU などのハードウェア リソースの動的な接続と取り外しが可能になります。最近 CNCF サンドボックス プロジェクトとして承認された CoHDI は、柔軟で効率的なインフラストラクチャ オーケストレーションへの重要な一歩を示しています。このセッションでは、CoHDI によって確立されたパラダイムと、リソース利用率の向上やベンダー間の相互運用性などのその中核となる価値について紹介します。 CoHDI の内部アーキテクチャの概要を、コンポーザブル DRA ドライバー、ダイナミック デバイス スケーラー、コンポーザブル リソース オペレーターの 3 つのコンポーネントに焦点を当てて説明します。この講演では、Kubernetes の統合と、CoHDI がマルチベンダーのコンポーザブル インフラストラクチャをコンテナ化されたプラットフォームに接続する方法について説明します。オンデマンドの GPU スケーリング、動的なデバイスの再利用、マルチテナント環境でのリソース共有などの実際のユースケースを通じて、CoHDI がどのように運用効率を向上させるかを示し、将来の方向性について結論付けています。

可観測性を実現する AI アシスタントの構築を開始したとき、難しい部分はそれをスマートにすることだと考えていました。私たちは間違っていました。難しいのは、いつそれを信頼すべきかを知ることでした。 AI エージェントは幻覚を起こし、文脈を忘れ、自信を持って間違った答えを返します。従来のテストでは、これらの障害を検出できません。必要なのは、体系的な疑念に基づいた評価です。 この講演では、AI エージェントを運用環境に移行する際の教訓を共有します。つまり、正しく取得する必要があるユースケースのゴールデン データセットを構築する方法、グラウンド トゥルースがない場合に LLM を判断として使用する方法、OpenTelemetry トレースを使用して評価の失敗をデバッグする方法です。また、マルチエージェントのハンドオフを評価し、ユーザーの質問と評価でカバーされる内容の間のフィードバック ループを閉じるなど、まだ解決されていないことについても説明します。 京都学派の哲学者、西谷啓治はこれを「大疑」と呼びました。生き残るものだけが真実になるまで、あらゆる仮定を疑うということです。 AI エージェントにとって、それは哲学ではありません。それが仕事だ。

OpenTelemetry Collector は柔軟でベンダー中立のテレメトリ パイプラインですが、拡張性は依然として運用上のコストが必要以上に高くなります。 contrib ディストリビューションは多くのコミュニティ コンポーネントを提供しますが、含まれる機能とセキュリティ体制をより厳密に制御する必要があるため、完全なバイナリをそのまま採用できないチームもあります。必要なコンポーネントのみを備えた小規模なコレクターを構築することは可能ですが、実際には、比較的小さな拡張機能をサポートするためだけにカスタム ビルド パイプラインを維持することを意味することがよくあります。この講演では、WebAssembly を使用して OpenTelemetry Collector を動的にカスタマイズするための代替モデルについて説明します。変更のたびにコレクター バイナリ全体を再構築して再配布する代わりに、カスタム レシーバー、プロセッサ、エクスポーター ロジックをより分離された方法で導入できます。このセッションでは、このモデルで何が可能になるのか、どこに適合するのか、どこが不十分なのか、安全性、移植性、パフォーマンス、運用に関してどのようなトレードオフが生じるのかを検討します。

昨年、68% の組織が災害によるデータ損失を経験し、1 件あたり平均 450 万ドルのコストがかかりました。しかし、2026 年の DR 調査では、Kubernetes DR に関する質問にはほとんど回答がなかったことが判明しており、ほとんどのチームが復旧計画でコンテナのワークロードがどのようにカバーされているかを理解していないことが示唆されています。このセッションでは、講演者が Kubernetes DR の現在の立場を率直に語ります。 講演では、Velero、Longhorn、ストレージ レベルのレプリケーション オプションなどのツールについて説明し、アクティブ/パッシブから GitOps ベースのリカバリまでのアーキテクチャ パターンについて説明します。しかし、このセッションの中核は、壊れたままであるということです。データベースのアトミックなマルチ PV スナップショットはなく、ネイティブのクラスタ間フェイルオーバーもなく、アプリケーション ユニットの DR の標準もなく、DR をエンドツーエンドでテストする人はほとんどいません。 セッションは未解決の質問で終わります。「バックアップを DR として扱うのか?」実際に Kubernetes DR を所有しているのは誰ですか? DR 標準のための CNCF ワーキング グループを設立すべきでしょうか?参加者は自分自身のギャップをより明確に把握して帰ってきます。

コンテナが侵害されました。しかし、Kubernetes は設計上一時的です。ポッドは 30 秒以内に再起動され、再起動すると、メモリ、プロセス、および一時的なファイルシステムが失われます。もう存在しないものをどうやって調べるのでしょうか？ クラウド ネイティブのエコシステムは、予防と検出においては優れていますが、一度アラートが発せられると、何が起こったのかを実際に把握するのにはまだ時間がかかります。 このセッションでは、シミュレートされた攻撃のライブ デモを使用して、オープン ソース ツールから構築したフォレンジック パイプラインについて説明します。 Falco は不審なアクティビティを検出し、Falco Talon はシステムコールとネットワーク トラフィックを自動的にキャプチャし、システム コール用の Wireshark スタイル ツールである StratoShark で証拠を分析します。また、Kubernetes Checkpoint API がオフライン検査のためにコンテナーのランタイム状態をフリーズする方法についても説明します。 参加者は、Falco Talon を使用して自動証拠キャプチャを設定し、StratoShark でキャプチャを分析し、クラスター内でフォレンジック チェックポイントをトリガーする方法を理解して終了します。

1.36 および 1.37 での SIG API Machinery の進歩と、AI / ML が SIG と Kubernetes コントロール プレーンの将来とロードマップにどのような影響を与えるかについてお話します。

Airbnb は、150 以上の Kubernetes クラスターにわたって AWS VPC CNI から Cilium に移行し、kube プロキシの置き換えやクラスター全体のネットワーク ポリシーなどの eBPF ベースの機能を利用可能にしました。この講演では、その旅から得た教訓を共有します。このパターンと教訓は Airbnb の経験に基づいていますが、Kubernetes を大規模に運用するチームに広く適用されます。 AWS VPC CNI を参照として使用して、大規模なポッド ライフサイクル パフォーマンス テストについて説明します。 IPAM 設定、EC2 API インタラクション、ワークロード ID の割り当ての違いが、特に高チャーン データやバッチ ワークロード (Spark など) の下で、どのようにスケーラビリティのボトルネックを引き起こすかについて詳しく説明します。 また、クラスター、ノード、ポッド レベルにわたるロールアウト戦略についても説明し、それぞれのトレードオフを検討します。最後に、デュアルスタック環境やブートストラップ中の循環依存関係などの課題に対する実用的な解決策について説明します。参加者は、Cilium を大規模に導入するための安全で段階的なロールアウト アプローチを携えて終了します。

Prometheus エクスポーターは通常、スクレイピング ターゲットとして使用されます。しかし、OpenTelemetry Collector Builder (OCB) で構築されたカスタム OpenTelemetry Collector ディストリビューションに直接埋め込むことができるようになると、何が変わるのでしょうか? このセッションでは、その変化が今日 Prometheus エクスポータに依存しているオブザーバビリティ チーム、プラットフォーム エンジニア、およびユーザーのための新しい運用モデルをどのように作成するかを探ります。チームはエクスポータを外部エンドポイントとしてのみ扱うのではなく、コレクタ コンポーネントとして実行し、テレメトリ パイプラインに直接統合できます。 この講演では、このモデルが焦点を当てる重要なエコシステムの問題、つまり、Prometheus エクスポータからセマンティック規約に準拠したテレメトリを公開する方法についても検討します。 参加者は、このアプローチによって何が可能になるのか、Prometheus エクスポータと Collector レシーバが重複する部分、およびこれが 2 つのコミュニティ間の相互運用性の将来にとって何を意味するのかをより明確に理解して帰ることになります。

ベアメタル上での Kubernetes の運用は、従来、PXE ワークフロー、カスタム スクリプト、および手動介入に依存しており、ドリフト、一貫性のないプロビジョニング、および大規模な運用オーバーヘッドの増加につながりました。この講演では、完全に宣言型の Kubernetes ネイティブのベアメタル ライフサイクル管理を可能にするために、Metal3.io、Cluster API、および Ironic を採用した運用ケース スタディを紹介します。 BareMetalHost API を介してサーバーを Kubernetes リソースとしてモデル化し、イメージベースのプロビジョニングを使用することで、確定的なノード ライフサイクル操作を実現し、構成のドリフトを排除し、検証された状態への収束を保証します。プロビジョニング時間が最大 40% 短縮され、クラスターの起動時間が数時間から 30 分未満に短縮されました。障害の回復とハードウェアの交換は、kubernetes ネイティブの調整を通じて処理されるようになり、手動プロセスがなくなりました。 このアプローチは、ベアメタルの運用をクラウドネイティブのパターンに合わせて調整し、Kubernetes が環境全体でインフラストラクチャ管理をどのように統合できるかを示しています。

AI エージェントが API やインフラストラクチャへの幅広いアクセスを獲得するにつれて、「承認」がセキュリティとガバナンスの両方の中心になりつつあります。 Agentic AI システムは、クラウド ネイティブ プラットフォームによってより広範に共有される、きめ細かいリアルタイム認証の課題を浮き彫りにします。 認可は、ベンダー固有の設計と実装に依存するインターフェイスによって長い間細分化されてきました。 2026 年 1 月、OpenID Foundation は AuthZEN Authorization API 1.0 を完成させ、認証対話のための標準インターフェイスを定義しました。この仕様は強い関心を集めており、現在、オープンソース IAM プロジェクトである Keycloak を含む複数のプロジェクトが AuthZEN のサポートに向けて取り組んでいます。 このセッションでは、田畑義之が AuthZEN の核となる概念を紹介し、Keycloak を使用したエンドツーエンドのデモを紹介します。このデモでは、シンプルなエージェント主導のシナリオを使用して、トークンの発行、認可評価、ポリシー決定の適用を段階的に説明し、AuthZEN がクラウド ネイティブ エコシステムにどのように適用できるかを示します。

クラウドネイティブの AI インフラストラクチャは、電力と土地の制限という「物理的な壁」に直面しています。これを解決するために、NTTとSKTは「全国GPUファブリック」を構築し、1,000kmを超える高速L2ネットワーク（IOWN APN）とKubernetesおよびKubeVirtを融合し、分散DC（札幌から福岡）を単一のクラスターとして運用しました。 単一の DC を超えた GPU オーケストレーションのアーキテクチャ、パフォーマンス、将来について詳しく掘り下げます。 - 分散型 DC と従来型 DC: 札幌から福岡までの 1,000km 以上のファブリック全体で達成可能なワークロードとトレードオフ。 - ファブリック対応トポロジー調整: 当社のソリューションが長距離 IOWN APN 制約を KubeVirt VM にマッピングし、単一の仮想化クラスターとして 1,000km にわたる高性能 GPU ピア通信 (NCCL) を維持する方法を示します。 - DRA 機能: KubeVirt の静的制限と動的オーケストレーションに対する DRA の可能性を共有します。 参加者は、単一 DC の「壁」を打ち破るための具体的な青写真を手に立ち去ります。これは、世界的な都市 AI インフラストラクチャの課題に対する拡張可能なソリューションです。

Kubernetes ネイティブのワークロード オーケストレーターである Kueue は、マルチテナント クォータ管理と高度なスケジューリングを使用して AI ワークロードを大規模に実行するのに役立ちます。 このセッションでは、Meta Superintelligence Lab のケース スタディを通じて、Kueue が複雑で異種の GPU トポロジにわたる大規模な AI トレーニングと推論に適切なクォータとスケジューリング レイヤーを提供し、社内プラットフォームから Kubernetes 上のオープンソース スタックへの移行を可能にした方法を示します。 次に、階層型ネットワーク ファブリックを備えた最新のクラスター向けの Kueue のマルチレイヤー Topology-Aware Scheduling (TAS) について詳しく説明します。階層型 TAS の背後にある主な概念とアルゴリズムを取り上げ、なぜこの移行に多層 TAS が重要であるかを示します。 最後に、Workload-Aware Scheduler の統合、柔軟なワークロード、MultiKueue を使用したマルチクラスター ジョブ スケジューリングなど、その他の最先端の Kueue 機能について説明します。

Envoy の動的モジュールは、HTTP 処理を拡張する高性能な方法を提供しますが、その機能をゲートウェイ機能に変えると、安全性、API 設計、および操作性に関する重要な疑問が生じます。この講演では、Envoy Gateway が Kubernetes ネイティブ API を使用して動的モジュールをサポートし、インフラストラクチャの登録をゲートウェイおよびルート上のポリシーベースの添付ファイルから分離する方法を説明します。これが Envoy の `dynamic_modules` HTTP フィルターにどのようにマッピングされるかを説明し、フィルターの順序付け、無効な参照、ライフサイクル動作、パッケージ化など、運用環境で拡張性をサポートできるようにする実際的な問題について説明します。ケーススタディとして実際のモジュール構成アプローチを使用して、バンドルされた共有ライブラリとランタイムロードされたプラグインを比較し、ゲートウェイとプラットフォームのメンテナーのトレードオフを強調します。