【レポート】KubeCon + CloudNativeCon Japan 2025に行ってきました！

はじめに

6月に開催されたKubeCon + CloudNativeCon Japan 2025に現地参加してきました。
開催から少し時間が過ぎてしまいましたが、手に入れた情報の整理も兼ねてレポート記事にまとめます。

開催概要

同様のレポート記事が他の参加者からもいくつか投稿されているため、既にお読みの方も多いと思いますが、KubeCon + CloudNativeConとは何か、今回の日本開催はどんなものかおさらいしておきましょう。

KubeCon + CloudNativeConとは

KubeCon + CloudNativeConは、CNCF (Cloud Native Computing Foundation)が主催する、Kubernetesとクラウドネイティブ技術に特化した国際的カンファレンスです。クラウドネイティブなOSSや技術に関心を持つ開発者、運用者、企業の専門家が世界中から集合します。
ヨーロッパ、北アメリカ、中国、インドなど、1年を通して世界各地で開催されています。

最初の開催は2015年のKubeCon 2015だそうで、その後2017年にクラウドネイティブ技術の関心の高まりもあって、今日まで続く併催の形となったようです。
最初の開催からもう10年経っているんですね。

KubeCon + CloudNativeCon Japan 2025とは

KubeCon + CloudNativeCon Japan 2025は、2025年に日本初開催となったKubeCon + CloudNativeConです。日本開催なだけあって、スポンサー企業も日本企業が目立っています。
2024年に開催された、KubeConより小規模なイベントであるKubeDay 2024が盛況だったことを受けて、本格的にKubeConとしての開催となったそうです。

開催概要は以下の通りです。

• 日時：2025年6月16日(月)、17日(火)
• 場所：ヒルトン東京お台場
• 参加費用：525ドル/人(企業関係者が標準的な期間に登録した場合)

早めの参加登録やバウチャーの利用で、もう少し参加費用を抑えられます。

開催規模は以下の通りです。

• 参加者：1,500人(公式発表)
• 登壇者：約130人(公式の情報から著者による独自集計)
• セッション数：約90(公式の情報から著者による独自集計)

今回、当社からは十数名が参加しました。

セッション

私が聴講したセッションと特に印象に残ったセッションをご紹介します。

聴講したセッション一覧

まずは、聴講したセッションです。1日目に8件、2日目に6件のセッションを聴講しました。
通常業務に関連のある、Observabilityに関連するセッションを積極的に聴講しました。

人気のあったセッションはアンコール講演もありました。今回は私も聴講した「No More Disruption: PlayStation Network's Approaches To Avoid Outages on Kubernetes Platform」が対象でした。

セッションの詳細ページへのリンクを貼っているので、ご活用ください。なお、Keynoteは複数登壇者で構成されて、詳細ページも登壇者ごとになっています。ここでは、冒頭の挨拶のパートを掲載しています。

セッションは基本的に英語です。一部のセッションを除いて、YouTubeでレコーディングが配信されていますので、今からでもご覧になれます。

1日目

• Keynote: Community Opening Remarks - Chris Aniszczyk, CTO, Cloud Native Computing Foundation
• Choose Your Own Adventure: The Dignified Pursuit of a Developer Platform - Whitney Lee, Datadog & Viktor Farcic, Upbound
• Safeguarding Your Applications - Achieving Zero Downtime During Kubernetes Upgrades - Kazuki Uchima & Kakeru Ishii, Google Cloud
• No More Disruption: PlayStation Network's Approaches To Avoid Outages on Kubernetes Platform - Tomoyuki Ehira & Shuhei Nagata, Sony Interactive Entertainment
• Streamlined Baremetal Deployment: A Journey of Custom Controllers Integrated With OpenStack - Mitsuhiro Tanino & Masanori Kuroha, LY Corporation
• The Grand Adventure of Production Apps: Build, Break, and Survive! ~ A Kawaii Manga Journey Through - Aoi Takahashi, Independent
• Sponsored Demo: Revolutionize DevOps with internal developer platform and multimodal AI
• 2-Node Kubernetes: A Reliable and Compatible Solution - Xin Zhang & Guang Hu, Microsoft

2日目

• Keynote: Welcome Back + Opening Remarks
• Should Our Project Join the CNCF? - Lenka Bočincová, Red Hat
• Bridging Cultures: Kubernetes Upstream Training and Japan's Open Source Journey Ltd.; Masahiro Kitamura, LY Corporation; Junya Okabe, University of Tsukuba; Masaki Kimura, Hitachi
• Full Lifecycle API Management in Kubernetes With Envoy and WebAssembly - Brandon Kang, Akamai Technologies & Mostafa Radwan, Datadog
• Debugging OpenTelemetry: Ensuring Your Observability Signals Are Spot On - Kasper Borg Nissen, Dash0
• The Future of Prometheus Exposition Format - Arthur Sens, Grafana Labs

私が参加した限りでは、「Sponsored Demo: Revolutionize DevOps with internal developer platform and multimodal AI」のセッションは完全に日本語でした。開始後に日本語だと分かったからか退出する外国の方もいました。

全セッションのスケジュールは、こちらからご確認ください。

ピックアップ

私が聴講したセッションの中で、特に印象に残ったもの、おもしろかったもの、共有したいものを少し詳しくご紹介します。

Keynote: Community Opening Remarks

こちらは、KubeCon + CloudNativeCon Japan 2025の幕開けを記念する、CNCFのCTOであるChris Aniszczyk氏によるキーノートです。
キーノートは10分程度の発表が6件連続する形式でした。

本会場は写真のように満席で、サテライト会場も解放されました。私はサテライト会場から参加しました。

クラウドネイティブ技術の拡大

冒頭には、クラウドネイティブ技術の利用やコミュニティの規模が年々拡大していることが強調されていました。

CNCFへのコントリビューション数として日本は世界9位、Kubernetesへのコントリビューション数に限れば8位だそうです。カナダやドイツ、イギリスなどの方が日本より上位であり、人口比で考えればまだまだ日本もコントリビューション数を伸ばせる余地がありそうです。

日本の活躍

日本からKubernetesに積極的に貢献しているコントリビューターの紹介がありました。

また、日本発または日本が先導するCNCFプロジェクトの紹介がありました。ここで取り上げられたCNCFプロジェクトは、Keycloak、containerd、Lima、youkiの4プロジェクトです。

日本におけるクラウドネイティブの大きな事例として、LINEヤフー、日立製作所、Preferred Networksのケーススタディが2025年に公開されたことも取り上げられていました。今後さらに3件が公開される予定だそうです。

その他、キーノート中には、今回チケットが完売したことと、2026年も開催予定であることが発表されました。

キーノートの全容は、レコーディングもご覧ください。

Choose Your Own Adventure: The Dignified Pursuit of a Developer Platform

こちらは、Upbound社のViktor Farcic氏とDatadog社のWhitney Lee氏による、クラウドネイティブなアプリケーションを開発するために開発プラットフォームでどのツールを活用すべきかをデモを交えて紹介するセッションです。

開発者向けプラットフォーム

Kubernetesのエコシステムでは、データベース、認証、メッセージング、ポリシー管理など様々な機能を実現する多様なツールが開発・公開されています。
アプリケーションの開発時には、それらから必要な機能を選択して導入する必要がありますが、アプリケーション開発者にとって、ある機能を実現したい時にどのツールを使えばよいか判断するのは簡単なことではありません。各ツールを開発している専門家ならばそのツールを詳しく理解しているでしょうが、アプリケーション開発者にツールの詳細まで理解を求めるのは酷な話です。

これを解決するために、組織の事情や方針に合わせて各機能を実現するツールがコレクションされたプラットフォームが組織内で提供されていると、アプリケーション開発者はそこからツールを選べるようになり開発がスムーズになります。

今回のセッションでは、聴講者の投票を基に採用するツールを選んでデモをしつつ、プラットフォームを組み上げていきました。

4つのシナリオ

今回はKubernetes上の開発における、以下の4シナリオを取り上げて、デモが実演されました。

1. APIと状態管理
   Kubernetesではリソースやその状態をAPIを通して管理する設計思想であるため、独自リソースなども含めてAPIを統合管理できるツールが必要
2. クラスターレベルのポリシー導入
   アプリケーションをクラスターにデプロイする時に組織のポリシーに従っているかチェックし、従っていないアプリケーションのデプロイを拒否する仕組みが必要
3. 一度きりのタスク実行管理
   Kubernetesに対応したパイプラインが必要(ここでいう「一度きりのタスク」とは、ビルド時のみに走るCI/CDパイプラインのことを指す)
4. GUIの追加
   デプロイ済みのリソースなど全体像を把握するには、リソースを視覚的に確認できるGUIが必要

それぞれのシナリオでのデモ候補と実際に選ばれたもの(太字)は以下の通りです。

1. Crossplane / KubeVela
2. Validating Admission Policy / Kyverno
3. Argo workflows / Tekton
4. Backstage / Port

デモ

デモの風景をご紹介します。

1つ目は、2番目のシナリオで選ばれたKyvernoです。
こちらのデモでは、アプリケーションをデプロイするときにspec.parameters.scaling.enabledがtrueに、spec.parameters.scaling.minが1より大きい値に設定されていなければならないというポリシーを設定しました。
この状態で、ポリシー違反のアプリケーション(＝スケーリングに対応していないアプリケーション)をデプロイしようとすると、写真のようにデプロイが拒否されました。

2つ目は、4番目のシナリオで選ばれたBackstageです。
こちらのデモでは、Backstage側にはデプロイしたリソースの情報を個別に伝えなくても、自動的にAPIから情報を取得し可視化できることが披露されました。
1番目のAPI管理も関連していますが、全てのリソースがAPIを通して管理されていることによる効果でもあります。

レコーディングはこちらです。

2-Node Kubernetes: A Reliable and Compatible Solution

こちらは、Microsoft社のGuang Hu氏とJoshua Zhang氏による、Kubernetesクラスターを2ノードで動かしても高可用性を維持するための解決策を紹介するセッションです。

2ノード構成を考える理由

通常、Kubernetesクラスターで高可用性を維持するためには、3ノード以上の構成が必要です。もし2ノードでも高可用性を維持できれば、1ノード分のハードウェアやソフトウェアライセンスの費用、運用の手間を削減することができます。
Kubernetesを2ノードで動かす場合に具体的にネックになるのは、クラスターの構成情報を管理するetcdです。通常の構成で1つのノードがダウンすると、残りの2ノードのみの投票では多数派を作れないためにリーダーを選出することができません。

「ウィットネスストレージ」の導入

そこで提案されていたのが、「ウィットネスストレージ」を用いた第3の投票者の導入です。
etcdでノード間のリーダー選出に使用されているRaftアルゴリズムを拡張し、ウィットネスストレージにメタデータを書き込む処理の追加やリーダー投票時のアルゴリズムの拡張などの修正をすることで、2ノード構成で1ノードがダウンしても新たなリーダーを選出してetcdの動作を継続することができるとのことです。
また、kube-apiserverに改変を加えることなく動作し、フェイルオーバーの性能も3ノード構成の場合と遜色ないとのことです。

その後の質疑では、ウィットネスストレージは単なる書き込み可能なストレージでよい、etcdのみコードを書き換えたが他のKubernetesコンポーネントは書き換えていない、などが話されていました。

登壇資料とレコーディングはこちらです。

Should Our Project Join the CNCF?

こちらは、Red Hat社のLenka Bočincová氏による、自分たちのプロジェクトがCNCFに参画すべきかを議論するセッションです。生成AIにより作り出された架空のプロジェクトKubeFishをベースに、CNCFに加入するまでに検討すべきこと、加入するとどんなことが起きるかが取り上げられました。

検討対象：KubeFishの紹介

架空のプロジェクトKubeFishの概要は以下の通りです。

• 名前：KubeFish
• 機能概要：クラスター内のネットワークトラフィックに対する可視性、制御、セキュリティを提供するクラウドネイティブなプラットフォーム
• カテゴリ：ネットワーキング & オブザーバビリティ
• メンテナー：1組織から3人のみ
• プロジェクトの目標：他組織への採用と他組織からのコントリビューション

CNCFに参画することの影響

まず、CNCFに参画することによる影響が3つの視点で示されました。

• メンテナー視点
  • 意思決定過程を公開する必要があり、プロジェクトを独占的にコントロールすることはできなくなる
  • コミュニティの構築や運営にも時間を費やす必要がある
• 会社視点
  • 「我々のプロジェクト」ではなく、「我々がサポートするCNCFプロジェクト」と言う必要がある
  • CNCFのイベントにも登壇など積極的に参加する必要がある
• ユーザー・コントリビューターのコミュニティ視点
  • プロジェクトコミュニティの議論に参加する必要がある

次に、CNCFに参画する上で、CNCFにフィットするプロジェクトなのか、類似した既存プロジェクトがないか、どんな付加価値をCNCFに提供できるか答えられるようにする必要があるという話がありました。
受け入れる立場の視点の考慮も必要だということですね。

成熟度による違い

CNCFプロジェクトの成熟度には、Sandbox、Incubating、Graduatedがありますが、各ステージにはCNCFから受けられるサポートの種類や量に違いがあり、成熟するほど手厚いサポートを受けられることを強調していました。また、CNCFに加わった以上はGraduatedステージに到達することをプロジェクトの目標とすべきということも述べられていました。
Sandboxステージで加わるプロジェクトが多いですが、Incubatingステージから加わるプロジェクトも一部あるそうです。

応募に向けた条件は整っているか

SandboxステージのCNCFプロジェクトとして応募する前にすべて満たすべきチェックリストがKubeFishのチェック例とともに示されました。これを見ると、KubeFishはコミュニティ運営やプロジェクト運営に課題があることが分かります。

ところで、CNCFプロジェクトだけでなく、Kubernetesのサブプロジェクトとしての道もあることが示されていました。特に今回のように名前にkubeを含む場合は、Kubernetesのみで動くものと誤解を招くため、CNCF側に参画するなら名前を変えるべきだそうです。

結論 参画すべきか

冒頭の「KubeFishがCNCFに参画すべきか」という問いに対して、「間違いなくCNCFに参画できる。ただし、コミュニティがもっと成熟して、名前を変えてからが良い」という結論でした。

最後に登壇者は「Foundation is not a magician」という言葉で締めくくり、CNCFに参画したからといって必ず成功する訳ではないことを伝えていました。

登壇資料とレコーディングはこちらです。

Debugging OpenTelemetry: Ensuring Your Observability Signals Are Spot On

こちらは、Dash0社のKasper Borg Nissen氏によるOpenTelemetryとは何か、また、使用する上での落とし穴を紹介するセッションです。

OpenTelemetryとは

まずは、CNCFプロジェクトの中で、コントリビューター数比較で2番目の規模にもなるOpenTelemetryのおさらいがありました。
業界としても利用が広まっていることもあり、ご存じの方も多いと思いますが、OpenTelemetryはデータモデル、API定義、セマンティック規約、ライブラリ実装など、システムのテレメトリを集めるために必要なもののセットです。一方で、オールインワンなツールではない、システム性能の最適化装置ではない、なども指摘されていました。
OpenTelemetryが担うのはテレメトリの生成から転送までで、蓄積と分析は他のツールの出番です。

OpenTelemetryのデバッグが大変な理由として、以下が挙げられていました。

• 強力なツールなだけに複雑
• 設定ミスをしやすいだけに原因の判断が難しい
• 失敗に気づかないまま、シグナルが消失する
• デバッグのスキルがあるということは、信頼できるObservabilityを持っていることと同じ(で難しい)

よくある落とし穴

続いて、OpenTelemetryを使用する上でよくハマりがちな落とし穴が紹介されました。

• プロトコルやポートなどの出力設定のミス
• サービス名(トレースに必要)の設定誤りや設定ミス
• コンテキスト伝播の問題
• トレーサーの起動遅延やエージェントの割り当てなどの初期化やシャットダウンの問題
• 誤った属性名などのセマンティック規約の不一致

単純な落とし穴もありますが、いざその場面になっても気づきにくいものです。

言語特有の問題

OpenTelemetryのライブラリを使用する上で、言語特有の設定方法やデフォルト値の違いにも落とし穴があります。
紹介されていたのはJava、Node.js、Goの3言語でしたが、この3つだけでも実装方法やプロトコル、ポート、コンテキスト伝搬の設定方法が異なります。

機能・動作	Java	Node.js	Go
実装方法	-javaagent指定で自動	--require指定で自動	手動
デフォルトプロトコル	http/protobuf	http/protobuf	grpc
デフォルトポート	4318	4318	4317
ローカルExporter	console	console	stdout
デバッグ用設定	OTEL_LOG_LEVEL=debugと OTEL_JAVAAGENT_DEBUG=true	OTEL_LOG_LEVEL=debug	OTEL_LOG_LEVEL=debug
コンテキスト伝播	エージェントが処理	SDKが処理	明示的な伝播指定

他の言語で使ったことがあるからと油断すると、設定漏れやミスが発生しそうですね。

ベストプラクティス

OpenTelemetryはアプリケーション側のクライアントから発生するテレメトリをパイプラインでつないで処理し、最終的に蓄積や分析環境まで橋渡しします。
その間に存在するOpenTelemetry Collectorは、Receiver、Processor、Exporterに分かれて、入出力先や条件に合わせてデータを処理します。

このパイプラインの動作を確認する時のチェックリストが示されていました。

• プロトコルとポートを合わせる
• サービス名を設定する
• SDKを早く初期化する
• すべてのスパンを終了させる
• デバッグとコンソールのExporterを使う
• セマンティック規約を確認する
• 常にローカルCollectorを使ってテストする

また、パイプラインの編集や可視化に役立つツールとして、OSSのOTelBinが紹介されていました。登壇者が所属するdash0社で開発されているツールです。

ここまでパイプラインの動作を中心に見てきましたが、一番肝心なのはパイプラインが正常に動いているかではなく、良いテレメトリを集められているかです。
良いテレメトリの条件として、構造的で、文脈があって、互いに関係して、信頼できて、実際に役立つことが挙げられていました。逆に、ノイズになるだけで一貫性もなく使い道のないテレメトリは悪いテレメトリです。

結論

「コンテキストのないテレメトリはただのデータである」という格言とともに、以下の忘れないでほしい5点を挙げてセッションは締めくくられました。

• 常にテレメトリを検証しよう
• よくある失敗の原因を忘れないで
• 言語ごとの特性を理解しよう
• Collectorを活用しよう
• ログから逃げずにツールを利用しよう

登壇資料とレコーディングはこちらです。

ブース

セッションの合間には、企業ブース・OSSプロジェクトブースを見て回りました。
ブースは、専用の部屋が1部屋と、通路2か所に設置されていて、計3か所に分散していました。

今回私は見ただけでしたが、OSSプロジェクトブースでは、プロジェクトの関係者と直接議論することができます。

室内のブースと通路のブースはそれぞれ次のような雰囲気です。通路のブースは、混雑が顕著でした。

印象に残ったブースを2点取り上げます。

印象に残ったブース①：トヨタ自動車

トヨタ自動車のブースでは、研究開発部門で機械学習実行基盤をKubernetesを使用して構築した事例が紹介されていました。
コストの面から、クラウドとオンプレのハイブリッドなノードの構成でクラスターを組み、Kueueを使って学習ジョブを管理しているそうです。

印象に残ったブース②：LINEヤフー

LINEヤフーのブースでは、社内クラウドプラットフォームのFlavaと自社開発OSSのAthenz、Valdが紹介されていました。

Flavaは、最新技術を取り込んだKubernetes開発環境の社内提供を実現しているそうです。
AthenzとValdについては、自社サービス構築時に既存のOSSでは必要な機能が不足していたため、独自に開発してOSS化したという話を伺いました。もともと積極的にOSSを公開していく方針だったわけでもないものの、結果として公開につながったそうです。

感想

今回初めてKubeCon + CloudNativeConに参加した感想を書き記しておきます。

セッション内容について

Kubernetes自体は触ったことはありますが、今まで知らなかったツールも多く、エコシステムの幅広さや関連プロジェクトの多さには改めて驚きました。

日本開催が実現しただけあって、国内でも、先進的な企業ではKubernetesやクラウドネイティブ技術の採用が進んでいること、そのような企業が増えていること、さらには、コントリビューションにも積極的な企業があることも実感しました。

また、デモを見ていて、登壇者が使っているツールがクールで便利そうだと思った場面もありました。例えば、k9sです。

会場について

初回ということもあったと思いますが、人数に対して会場が狭めで、特に通路での行き違いがしづらい印象でした。今後より盛況になって、より広い会場で開催されるとよいですね。

また、会場の部屋名が星の名前になっていたり、ホテルの部屋の配置の構造が少し特殊だったりと、会場に慣れるまでどこに向かえばよいかわかりづらい点もありました。

Tips

来年行かれる方に向けて、いくつかTipsも残しておきます。

朝は早めに行こう

参加者のバッジは印刷されているものが用意されていますが、思ったより探すのに時間がかかっていて、受け取り窓口では大行列でした。

1日目は9時ごろにホテルに到着し、9時20分ごろにバッジを受け取れましたが、キーノートの会場は席が埋まっていて、隣のサテライト会場に通されました。
2日目は9時15分ごろにホテルに到着し、バッジ受け取りがない上に少し空いていたこともあって、メイン会場に着席できました。

セッションは早い者勝ち

セッション聴講は、予約の仕組みがないので早い者勝ちです。ただ、実際には席が空いていることも多く、混んでいても立ち見で何とかなりました。

セッションのリストは、主催者側でSchedというサービスに公開しているので、自分が聴講したいセッションもこちらで管理します。

お昼は早く受け取ろう

会場ではお昼のお弁当が提供されましたが、配布の列は大行列でした。
また、出遅れるとヴィーガンの方向けのお弁当しか残っていないこともありました(1日目はこちらを受け取りました)。

ちなみに、お昼と午前午後のコーヒーブレイクの時間帯はセッションがないので、企業ブースを見て回るか休息(や貯まっている仕事の処理)に充てるとよいと思います。思ったよりも休憩時間は長いです。

おわりに

本記事では、KubeCon + CloudNativeCon Japan 2025に参加した内容をレポートしました。

正直なところ、セッション聴講が主目的なら1回現地参加しておけばよいようにも思いますが、登壇者やOSSプロジェクト関係者との議論、ネットワーキングなど現地でしか体験できない内容もあります。
世界的なカンファレンスがせっかく行きやすい国内で開催されるので、皆さんもぜひ1度は行かれてみてはいかがでしょうか。来年2026年も日本で開催予定です。

最後に、ベンダー主催のカンファレンスとは違い、KubeCon + CloudNativeConはスポンサー企業の皆様のご尽力により成り立っています。初めての日本開催を円滑に運営いただきありがとうございました。