はじめに
こんにちは！SREセクションの高木、青木です。
2025/6/16-17に、クラウドネイティブ技術に関する世界的カンファレンスであるKubeCon + CloudNativeCon Japan 2025が東京のお台場で開催されました。日本では初の開催です！
オイシックス・ラ・大地からはSREセクションの高木と青木の2名が参加しました。
この記事では気になったセッションやカンファレンスに参加した感想をご紹介します。
印象に残ったセッションの紹介
青木
Choose Your Own Adventure: The Dignified Pursuit of a Developer Platform
CNCFプロジェクトってたくさんあってどれを選んだらいいかわからなくなることがありますよね。
このセッションでは、特定のツールをデモで紹介する際に、Slidoで聴衆からの投票を募り、票が多かった方のツールのデモをするというインタラクティブな形式が非常にユニークでした。
デモが失敗したり、タイムアップで紹介できなかったりと、ライブ感のある楽しいセッションでした。
個人的に初耳なツールばかりでしたので、復習も兼ねて各ツールのご紹介をします。
Crossplane vs KubeVela
開発者が簡単にアプリケーションをデプロイするためのツールとして紹介されましたが、それぞれ役割は異なります。
CrossplaneはKubernetesのAPIを使って、Kubernetes外のリソースを管理することを目的としています。
Kubernetesのカスタムリソース (CRD) でRDSやS3を表現できちゃうということです。
これにより、Kubernetesの世界だけでインフラからアプリケーションまで完結できます。
面白い発想ですが、CRDがかなり複雑になりそうな予感もします。
一方、KubeVelaはアプリケーションのデプロイとライフサイクル管理を簡素化することを目的としています。
例えば、開発者がKubernetesのAPIやマニフェスト（Pod、Deployment、Serviceなど）を直接意識することなく、アプリケーション開発が可能になります。
CrossplaneとKubevelaを両方使えば、開発者はインフラやKubernetesを意識せずアプリケーション開発が可能になるということですね。
Kyverno vs Validating Admission Policy
さて、CrossplaneやKubeVelaにより、開発者が自分たちでインフラリソースやKubernetesリソースを構築できるようになりました 🎉 しかし、開発者は人間ですので間違えることもあります。クラスタノードを間違えて300台作ってしまうこともあります。
このようなミスをポリシーによって防げるのが、KyvernoやValidating Admission Policy(VAP) です。 いずれもポリシーエンジンですが、Kyvernoの方が機能が多いです。
デモではKyvernoのValidation（検証）の機能が紹介されていました。（例：ポリシーに違反したリソースを作成しようとすると、エラーとなり作成できない） 他にもMutation（変更）、Generation（生成）といった機能があります。
一方、VAPは文字通りValidationのみの機能となりますが、Kubernetesの組み込み機能のためインストール不要です。
Argo Workflows vs Tekton
Argo WorkflowsとTektonはどちらもKubernetesネイティブなワークフローエンジンです。
Argo Workflowsは汎用ワークフローで、CI/CDだけでなく、データ処理や、機械学習、バッチ処理などをKubernetes上で実行したい場合にも活用できます。
一方、TektonはCI/CDに特化しています。
この辺りから時間が迫ってきたため、デモの時間が取れていませんでした💦
Backstage vs Port
作成したリソースをグラフィカルに表現するツールとしてBackstageとPortが紹介されていました。
どちらも単なるGUIというよりも、開発者ポータルという位置付けのようです。
開発者ポータルは、開発者が日々の業務で必要とするすべての情報、ツール、サービスを単一の統合されたプラットフォームに集約し、開発者の生産性を向上させることを目的としています。
両者の違いとしては、Backstageはオープンソースなのに対し、PortはSaaS製品という点くらいのようです。
弊社ではAmazon EKSのクラスタが複数アカウントに存在します。 開発者にはReadOnlyのKubernetes APIを実行する権限を与えていますが、参照のためだけにクラスタがどのアカウントにあるのかを確認し、認証、アクセスするのは手間だと思います。 開発者ポータルに情報が集約されていれば、このような手間を省くことができる上、認知負荷を下げることもできるのではと思いました。
余談
“Choose Your Own Adventure” とは、1980-1990年代にアメリカで大人気だった、読者が物語の中で選択をして進める形式の子供向けゲームブックです。
日本語版もあるそうで、「きみならどうする？」というタイトルだそうです。初めて知りましたが、ピッタリなタイトルですね。
終始かわいいスライドでテンションが上がりました。
Safeguarding Your Applications - Achieving Zero Downtime During Kubernetes Upgrades
Kubernetesのアップグレード中のダウンタイムをゼロにするための方法を解説したセッションでした。
次の3つの観点で解説されていました。
- ダウンタイムの観測と分析方法
- コントロールプレーンのアップグレード時のTips
- ノードのアップグレード時のTips
その中でも特に1点目で紹介されていた、kube-apiserverの監査ログのビューアKubernetes History Inspector (KHI)が興味深かったです。KHIとは、Kubernetesの障害調査に活用できるOSSのログの可視化ツールです。
Kubernetesの監査ログを真面目に読んだことがなかったので、軽くKHIを触ってみます。
事前準備の手順や今回の検証条件については折りたたみ表示内に記載しています。
監査ログ取得準備（クリックすると展開します）
今回はサクッとminikubeを立て、Podを起動したり消したりしてみます。
なお、minikubeで監査ログを取得する場合、開始時に --extra-config オプションでAudit Policyを指定する必要があります1。
minikube stop mkdir -p ~/.minikube/files/etc/ssl/certs cat <<EOF > ~/.minikube/files/etc/ssl/certs/audit-policy.yaml # Log all requests at the Metadata level. apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata EOF minikube start \ --extra-config=apiserver.audit-policy-file=/etc/ssl/certs/audit-policy.yaml \ --extra-config=apiserver.audit-log-path=- kubectl logs kube-apiserver-minikube -n kube-system | grep audit.k8s.io/v1
それでは試しにこちらのマニフェストでDeploymentとServiceを作成します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: NodePort
selector:
app: nginx
ports:
- port: 80
targetPort: 80
作成後、Podの削除、Deploymentのスケール・ロールアウトなど、いろいろ操作した後にDeploymentとServiceを削除しました。
最後に監査ログをファイルに出力したらログの準備完了です。
kubectl logs kube-apiserver-minikube -n kube-system | grep audit.k8s.io/v1 > audit.json
KHI準備（クリックすると展開します）
KHI自体はDockerコマンド一発で起動できます。
docker run -p 127.0.0.1:8080:8080 asia.gcr.io/kubernetes-history-inspector/release:latest
http://localhost:8080 へアクセスするとこちらの画面が表示されるので、New inspectionを選択します。
今回はminikubeで出力したJSON形式の監査ログを分析するので、OSS Kubernetes Log Files を選択します。
ちなみにGKEの場合は、ログの準備は不要で、Google Cloudのプロジェクトと紐づけることで分析できるようです。
JSON形式のログファイルのアップロードが成功すると準備完了です。
監査ログ分析
KHIの分析UIは次のような画面です。リソースやnamespace毎にステータスが表示されています。
中央の青や赤のバーはタイムラインを示しており、青が正常で、（今回のケースは）リソースが削除されると赤く表示されています。
タイムラインを選択すると、ログや履歴などの詳細情報が表示されます。Historyに注目すると、UserによってPodが削除された、ということが分かります。
「Podが勝手に落ちたんです」とユーザから報告を受けたとしても、「いやいや、ユーザが意図的に削除しているよ」とバレてしまいますね。
今回、手元では超シンプルなアプリケーションを立てて、作ったり消したりの超シンプルな操作しか試していません。
KubeConのGoogle社のブースではPod Disruption Budgetの設定ミスによりPodが退避できなくなっているデモを見せていただきました。
普段は、Kubernetesの障害調査に限界を感じたらすぐにサポートへ問い合わせて調査をお願いしていますが、このような可視化ツールがあると自力での調査のハードルも下がりそうです。 EKSの場合、監査ログの出力を有効にしておく以外は特別な追加設定不要でKHIでログを調査できそうです。
The Grand Adventure of Production Apps: Build, Break, and Survive! ~ A Kawaii Manga Journey Through the Ups and Downs of Production Apps ~
Kubernetesの入門書「つくって、壊して、直して学ぶ Kubernetes入門」の著者の高橋あおいさんによる、Kubernetesの障害対応の基礎を学ぶセッションでした。
主人公のKubeKnightがkubectlという剣を入手し、エラーという名のモンスターと戦い、経験値を貯めていくお話しです。
剣（kubectl）の使い方をマスターした後はマップを入手し、トラブルシューティングの順番を学びます。ユーザから遠い下層のPodから順に調査を進めていくのがセオリーです。
新人の時に習った、「トラシューはOSI 7階層モデルの最下層の物理層からチェックすべし」というアドバイスを思い出し、プラットフォームは違えど基本は同じだ！という学びがありました。
小ボス戦では、これまでに身に付けた技術を総動員し、マップを頼りにNginxの503エラーを見事倒します。
これで一件落着、、、ではなく、ここまではチュートリアルです。本当の冒険（本番運用）はこれからが始まりです。改めて基礎の大切さを再認識しました。
かわいいキャラクターに癒されながら、モンスターを倒すたびに拍手喝采が巻き起こる、楽しいセッションでした。
高木
全体を通じての感想
日本にいながら海外のカンファレンスの雰囲気を感じ、Kubernetesに対する世界の熱量に終始圧倒されました。
セッションでは、これまで知らなかったワードもたくさん登場しました。
まだまだ勉強不足であることを痛感すると同時に、知らなかったことを新しく学ぶことで今後のサービス改善に活かせる可能性を感じました。
No More Disruption: PlayStation Network’s Approaches To Avoid Outages on Kubernetes Platform
SonyのPlayStation Network(PSN)のKubernetes基盤が99.995%の可用性をどのように達成したかについてのセッションです。
SREとしては、やはり信頼性・可用性に関するセッションが気になります。
このセッションは1日目に満席で会場に人が入りきらなかったようで、2日目にアンコールセッションが行われるほどの人気でした。
「Doing the Basics Right 普通のことを普通にやる」という言葉が強調されており、印象に残っています。
高可用性を実現するために特別なことをしているわけではなく、起きている課題に1つずつ取り組むこと、場当たり的な修正を避けること、をポイントとして挙げていました。
PSNのような世界規模のサービスでも重要なのは基本を徹底することだと分かり、私たちのサービスでもその考え方を活かせそうだと考えました。
セッション内で紹介された次の手法は弊社もすでに導入しており、基本的なことができているのだと自信を持てました。
- PDB, PTSC, Descheduelrの利用による可用性向上
- Karpenterの利用による高速なスケーリング
一方で、KyvernoというOSSが初耳でした。
Kyvernoは、Kubernetesのリソースに対するポリシーを定義できるそうです。
このセッション以外にもいくつかのセッションでKyverno, Policy as Code(PaC)というワードが登場していました。
私たちのサービスではPaCの実践がまだ行われていませんので、運用の改善や可用性の向上に活かすため学びたいと思いました。
ブース
セッションの合間やランチタイムにスポンサーブースを回りました。
スポンサーブースも多くの人で賑わっていました。
普段業務でお世話になっている企業様にご挨拶へ伺ったり、各社が提供しているSaaSやOSSの話を伺って技術トレンドを感じることができ、大変有意義でした。
ランチ
両日ランチタイムにお弁当が配布されました。
食に関わる企業の者としては、どのようなお弁当が用意されるのかも気になります。
何種類かお弁当が用意されており、高木は季節のお弁当をいただきました。
おわりに
あっという間で刺激の多い2日間でした！
来年のKubeConも日本開催ということなので、今年参加できなかった同僚たちも誘って、来年も参加したいです！
OisixではCloud Native技術の活用にも力を入れています。ご興味があればぜひカジュアル面談しましょう🙌
