KubeCon + CloudNativeCon Japan 2025に行ってきました。
だいぶ時間が空いてしまいましたが、2025年6月16, 17日の二日間、kubeCon + CloudNativeCon Japan 2025に行ってきました！
初の日本での開催とのことで、せっかくなので参加してみました。
丸二日間、たくさんのセッションを見てきましたので、ブログに残しておきたいと思います。
前提として、私は英語が得意ではありません。
日本語でのセッションは全くと言っていいほどになかったので、正しい理解ができてるか保証しかねます。もしもブログを読んで興味を持たれた場合は、ファクトチェックの意味で公開されている動画を見ることをおすすめします。
それでは、私が参加したセッションで気になったものを紹介させて頂きます。
No More Disruption: PlayStation Network's Approaches To Avoid Outages on Kubernetes Platform
まずタイトルの時点でワクワクしますw
みなさんご存知、PlayStation Networkのお話です。
やはり興味を持つ方が多かったのか、セッション参加者がとても多く、立ち見が大量に発生していました。このセッションは初日に参加しましたが、二日目にもEncore Presentationとして同じ内容のセッションが行われたようです。
99.995%
この数字は2024年で達成した可用性の値だそうです。時間にして26min17secだけダウンしていたとのこと。
これは、数十のチームが開発した数百のサービスが50以上のクラスターで動作する環境で達成された数値だというのから驚きです。
これらはどのように実現されたのかという疑問に対しての彼らの答えは
Doing the Basics Right
普通のことを普通にやる
でした。特に変わったことをしたのではなく、１つ１つの課題に丁寧に取り組み、場当たり的な対応はしないことで、達成したとのことです。
いくつか具体的な例が上げられていましたが、それらは確かにごく当たり前と言って良いでしょうが、実現できてないプロジェクトも多いのではないでしょうか。
例としては、Podの可用性として
- Podの偏り
- スケール不足
- CoreDNSの不安定性
これらの問題点に対して
- DeschedulerによるPodの再配置
- オーバープロビジョニング
- Karpenterによるノード作成の高速化
- CoreDNSの分散配置とCPU制限の撤廃
- 固定レプリカ数でのデプロイ
と言った対策を行ったそうです。
その他にもメンテナンスやアーキテクチャ、運用体制などの課題に対して、場当たり的な方法ではなく、基本に忠実に、kubernetesのベストプラクティスなどを確実に実施することで可用性99.995%を達成したとのことでした。
他のセッションではAI関連のセッションが多くありましたが、このセッションは目新しい技術スタックの話ではなかったと思います。ですが、一つ一つの課題に対して丁寧に対応することの大切さ、そしてkubernetesでは基本的な解決策が大体のケースにおいて存在し、コミュニティの活発な活動によってさらに優れた対策が存在することで、それらを当たり前に実施することで、優れた可用性を実現できるのだと学びました。
感想
Multi Cluster Magics With Argo CD and Cluster Inventory or Don't Get Lost int the Clusterverse: Navig
グーグルのDeveloper Advocateの方のセッションです。
こちらも大変盛況でした。
Sperkerのカズリンさんは、Kubernetes PodCast from GoogleのCo-Hostもしておられる方です。
内容としては、マルチクラスターについてのお話です。
まず最初に、私はマルチクラスターの必要性がいまいちピンときてません。
私が今まで携わってきたプロジェクトでは、単独のクラスターで十分目的を達成できていましたし、複数のクラスターを独立して用意してきました。
プロダクション環境とステージング環境、開発環境それぞれクラスターを組むことが多いです。
なので、マルチクラスターってのはとても大きな組織で複数のチームが使うリソースを一限で管理するような場合に使うのかと思いました。
が、考え方としては、先ほどのプロダクション環境、ステージング環境など別のクラスターを用意してそれぞれ管理するのではなく、クラスターを管理するクラスターで管理することで、それぞれ別に管理する必要がなく、同じ環境構成を一元管理することができるとのことです。
さらにマルチクラスターの利点として、物理的に距離のあるクラスター間で同じネームスペースを使うこともできるとのことでした。
これは、リージョンの異なるクラスター間で同じアプリケーションが動作し、物理的に近いクラスターをユーザーが使えるということのようです。世界規模の巨大サービスならこのメリットはとても大きいと思いました。
これら、マルチクラスターを魔法のように使うために、マルチクラスターオーケストレーター (MCO)
というオープンソースを紹介されていました。
感想
「クラスターのためのKubernetes」という概念を知ることができ、とても興味深い内容でした。
また、スピーカーの方の英語が聞き取りやすく、英語が苦手な僕でもわかりやすかったと思います。
What’s New in Open Source Kubernetes?
またもやSperkerはカズリンさんです。
こちらはkubernetesの最近の流れのような話でした。
例えば、Vender固有のコード（AWSやGCP、Azure向けにそれぞれで独自実装されたもの）が存在しましたが、それらはCustom Resource Definitions(CRDs)/Operatorsにすることができるということになり、それによって、kubernetesのソースコードは1,071,842行も削減されたそうです。
これはとても素晴らしいことだと感じました。AWSで動作させる場合に、不要なGCPやAzure向けのコードも含まれていると、無駄だし、使えるかもと思って失敗することもあるかもしれないので、こう言ったリファクタリングは自分たちのプロジェクトでも考えていくべきだと思います。
このセッションで一番記憶に残っているのが、Sidecarの話でした。
Sidecarは昔からある概念でしたが、起動順序を制御できないなどの問題点がありました。
メインアプリより先に起動しておきたいコンテナがある場合は、init containerを使うことができましたが、init containerが停止後にメインアプリのコンテナは起動します。init containerが起動し終わって、常駐したままメインアプリを動作させることはできませんでした。
それが、Kubernetes 1.28からinit containerにrestartPolicyを定義できるようになり、停止したら自動で再起動させることができるようになったので、常時起動させることができるようになったとのことです。
確かに、Podに複数コンテナを定義しても起動順序は制御できず、クラッシュループしてしまう場合がありました。今後はこれを使えばクラッシュループすることなくデプロイすることができるのではとワクワクしました。
感想
同じspeakerの方の発表でした。このセッションは特定の企業や団体の経験の発表ではなく、kubernetesの最近の流れや実装の紹介がメインでした。
セッションの最初に、「英語でも日本語でもできますがどちらがいいですか？」と会場の観客に聞いていて、個人的には日本語での発表も聞いてみたいなと思いました。
まとめ
初めての日本開催とのことで、KubeCon自体初参加でしたがとても有意義な時間を過ごせたかと思います。英語が苦手な私でも会場にあるQRコードを読み込むと、AI自動翻訳で日本語訳や、英語字幕を見ることができ、リスニングに自信がなかったり、聞き取れない時でもセッションを理解することができました。
最先端の話を生で聞くことができるので、このようなイベントには今後も参加して行きたいなと思いましたし、周りにもおすすめしていこうと思います。
