Kubecon Japan 2025に参加してきました #Kubecon #CloudNativeCon #Platform Engineering #Prometheus #GCP #マルチクラウド

a-ikedaGCPKubernetesクラウドネイティブ

2025/06/16,17に日本で初めて開催されたKubeconに参加してきました。
印象に残った3セッションについてのまとめ＆感想になります。あとで資料を見返しているものの、解釈が誤っている箇所があるかもしれないです。ご容赦ください。

ご紹介する3つのセッション

  • Platform Engineering Day 2 Why Service Iterations Are the Crux of Developer Platforms(Puja Abbassi)
  • Prometheus 3.0 and the new Governance:Setting up the project for the next decade(Josh Abreu)
  • Multi Cluster Magics with Argo CD and Cluster Inventory(Kaslin Fields)

Platform Engineering Day 2 Why Service Iterations Are the Crux of Developer Platforms

Developer Platform & Golden Path

「Developer Platform」とは、開発者がアプリケーションの開発や運用を効率的に進めるために用意された共通の仕組みやツール群です。「開発者の作業効率を高めるための土台」と言えそうです。

ここで重要なコンセプトに「Golden Path」があります。Golden Pathという言葉はPlatform Engineeringでは耳なじみのある用語だと思います。これはアプリケーション開発において推奨されるベストプラクティスをあらかじめ定義し、開発者がスムーズに開発を進められるように示された道筋のことです。

ところで「Day 2」って何？

「Day 2」という用語を発表時に目にしたとき、以前の登壇の続きなのかと本気で勘違いしてしまいました。1日目に行われたセッションなのでそんな訳はなく、「Day 2」とはアプリケーションやサービスをリリースした後の運用フェーズを指しているようです。リリースが「Day 1」であるのに対し、その後の維持管理や改善などの継続的な作業が「Day 2」という事です。

Day 2におこなう作業には、大きく次のようなものがあります。

  • アプリケーション開発者の作業
    • コードの継続的な改善とリリース
    • プラットフォーム製品の設定変更
  • プラットフォームエンジニアの作業
    • プラットフォームそのもののアップデートや改善

Day 2 はなぜ難しい？

Day 2が複雑になりがちな理由は、すでに存在する環境やリソースを変更する際、多くの考慮すべきポイントがあるためです。具体的には以下のような要素が影響します。

  • Kubernetesやクラウドインフラの設定変更
  • 変更管理プロセス（PRやテストの管理）

例えば、KubernetesのバージョンアップやVMのOSアップデートといった作業はアプリケーションの影響を考慮する必要があり、慎重さが求められます。

Day 2 をうまく乗り切るためのベストプラクティス

Day 2の課題を乗り越えるためには、以下のようなポイントを押さえることが効果的です。

  • 最初からDay 2を意識した設計を行う
    後から考えると困難な変更が発生するため、最初からDay 2運用を視野に入れ設計することが重要です。
  • 宣言的な管理を導入する
    宣言的な管理を導入することで、設定変更をコードとして記録できるため、変更点をGitなどで明確に管理できます。
  • 変更は計画的に実施する
    大きな変更時は、関係者と早期にコミュニケーションを取り、綿密に計画を立てる必要があります。

感想

Giant Swarm社のPuja Abbassi氏の登壇資料をまとめさせていただきました。
“Day 2”という表現がどれほど一般的なのかは分かりませんが、その言葉が印象的で、つい耳を傾けてしまいました。

KubernetesのバージョンアップやOSのアップデートは、その上で動くアプリケーションに影響を及ぼす可能性があります。そのため、開発環境→ステージング環境→本番環境という段階的なスケジューリングや動作確認の自動化を導入し、効率を保ちつつも慎重に進めることが重要だと感じました。

また、セッションで出てきた「Day 2を意識した設計」という言葉に共感しました。プロジェクトの企画や立案の段階からDay 2における開発者の課題解決を意識し、Platform Engineeringの考え方を取り入れつつ、開発者の業務がはかどるためには何をすべきかを考える必要があると思われます。

Prometheus 3.0 and the new Governance:Setting up the project for the next decade

続いてはJosh Abreu 氏のPrmetheus3.0のアップデート情報のセッションについて纏めます。いくつかあったお話しの内、以下を注目しました。

  1. New UI & UX – Query Explainer
  2. Remote Write 2.0 – 重複削除による効率化
  3. OpenTelemetry × Prometheus – プロトコルサポートと属性管理

1. New UI & UX – Query Explainer

  • Prometheus 3.x では UI が全面刷新
    • ランディングページがモダンになり、視認性が大幅に向上したようです。
  • 「Query Explainer」
    • PromQLクエリの理解を深め、作成やトラブルシューティングを効率化する機能

prometheus3.0 UIに関してはこちらにも説明がありました。

2. Remote Write 2.0 – 重複削除で帯域コストを削減

  • Remote Write 2.0 は、複数ノードから送られる同一サンプルを内部でまとめ上げ、ネットワーク転送量を劇的に削減される

3. OpenTelemetry × Prometheus – Push 対応と属性管理の強化

Prometheus 3.x では OpenTelemetryとの相互運用 が大きく前進しています。登壇や資料では以下のポイントが紹介されていました。

  • Collector からの Push：Otel Collector → Prometheus への Push が可能に。関連リンク
  • 属性管理の自由度向上：メトリクス名にドット（.）を含められるなど命名規則が緩和。さらに PromQL では 引用符で囲む書式（Quoting in PromQL） が導入予定で、詳細は issue #14217 にて議論中。

感想

Kubernetes に限らず、オブザーバビリティは昔も今も欠かせない要素であり、SRE や Platform Engineer の領域でも必須の技術です。その中でも Prometheus は依然として高い人気と存在感を示していました。今回紹介された新機能の中で特に OpenTelemetry との連携に注目し、今後しっかりと学習を進めたいところです。

Multi Cluster Magics with Argo CD and Cluster Inventory

セッション概要

  • マルチクラスターにおける根本課題
    Kubernetes クラスターは自分自身の情報を持たず、他クラスターについてはなおさら知らない。Kubernetes には “cluster name” や “cluster ID” といった概念が存在しない。
  • 従来の対応策と限界
    • Namespaces による分割では地理的要件やセキュリティ要件など多様なニーズを満たせない。
    • Argo CD はクラスタリストを Secret で保持するが、複数アプリや組織を扱うと「リストのリスト」問題に陥りやすい。
    • マルチクラスター系 OSS やクラウド各社が独自にクラスターリストを再発明しており、利用者はツール間を繋ぐのり付け作業に追われる。

解決策:標準化へのアプローチ（SIG Multicluster）

  1. Multicluster Services (MCS) API
    • ServiceExport / ServiceImport / ClusterSet CRD により、複数クラスター間サービスを統一的に扱える。
  2. ClusterProfiles API
    • ClusterProfile CRD を使ってクラスター特性を宣言的に管理し、共通フォーマットの「Cluster Inventory」として活用できる。

解決策:Multicluster Orchestrator (MCO)


Google が 2025 年 4 月に OSS として公開したツールで、Hub クラスター上からポリシーに沿ってワークロード分散や容量最適化を実現する。

SIG MulticlusterとMCOについて後日AI使ってまとめました。
※内容において若干ニュアンスが異なるところがあるかもしれません

SIG Multicluster
  • 目的と歴史
    Kubernetes を複数クラスターで運用した際に生じる “名前がない／互いを知らない” 課題を解決するため、コミュニティが設立した Special Interest Group。ワークロード公開・メタデータ共有・クラスター間連携を Kubernetes ネイティブに行う API 群を策定・維持している。
  • 主要 API 群（2025 年6月時点）
API目的主な CRD進捗
MCS (Multi-Cluster Services) APIクラスター間で Service を公開・発見ServiceExport / ServiceImport / ClusterSetKEP-1645 に基づき Beta へ段階的移行中
ClusterProfiles APIクラスター特性を宣言的に記述し「Cluster Inventory」を形成ClusterProfileKEP-4322 提案段階。実装 PoC が進行中
About / Work APIクラスター ID 付与・マルチクラスター配置用 Workload 定義ClusterSet / Work などαリリース

Multicluster Orchestrator (MCO)
項目概要
提供元Google（OSS、GKE 向けにパブリックプレビュー公開：2025-04-02）
役割複数 GKE クラスターを “単一ユニット” として扱い、リソース不足や DR を自動解決する集中オーケストレーション層
主要機能- ワークロード自動配置：空き GPU やリージョン冗長性を考慮したスケジューリング
- ポリシーベース制御：ガードレールを定義し、開発チームは宣言的にデプロイ
- GitOps 連携：Argo CD 用プラグインを提供し、既存パイプラインと接続
想定ユースケースAI/ML 推論基盤、リージョン DR、FinOps 観点でのクラスターフリート最適化
今後の位置づけと展望
  • SIG Multicluster → “標準 API”
    クラスター ID・サービス公開・インベントリ管理といった基盤レイヤーを Kubernetes コミュニティが定義。
  • MCO → “リファレンス実装” 的オーケストレータ
    SIG が策定する ClusterProfiles や MCS API を取り込み、容量最適化・リージョン分散 を実務レベルで自動化。
  • Argo CD との相性
    Argo CD は ApplicationSet などで ClusterList を必要とするため、ClusterProfile API が標準化されることで “リストのリスト問題” を回避しつつ、MCO プラグインで GitOps ワークフローに自然に組み込める。

感想

Argo CDの話しというよりかマルチクラスタに関するセッションだったと感じました。
SIG Multicluster と MCO が今後どちらの潮流になるのか、あるいは相互に連携しながら発展していくのか、そして新しい機能が出てくるのか——非常に興味深いところです。
私自身、要件ごとに分けた複数クラスタの運用経験はあるものの、マルチクラスタ運用の経験は乏しいので、このセッションは大いに学びがありました。Kubernetes 運用の複雑さをあらためて考えさせられました。

最後に

普段オンサイトでのイベント参加の時間がなかなか取れず、今回のKubecon参加はとても有意義な2日間となりました。Kubeconの内容もさることながら、オンサイトのイベントだとオンラインでの視聴と比べて聞かざるを得ない状況になるので、私のような怠け者にはありたい場となります。今後も時間を作って他のイベントに参加していきたいです。

Kubecon主催者・関係者の皆様、イベント開催や会場のセッティングなどありがとうございました。そしてこれはホテル会場の素晴らしさだと思いますが、会場で提供されたマカロンが非常に美味しかったことをお伝えしときます。

Author

a-ikeda

    将来はいろいろな都市に住んでみたいリモート好きなエンジニア

    a-ikedaの記事一覧

    新規CTA