KubeCon + CloudNativeCon North America 2022参加レポート〜3年ぶりのアメリカ現地開催の様子とセッション紹介〜

OGP

こんにちは。計測システム部SREブロックの西郷です。

10月24日から10月28日にかけてKubeCon + CloudNativeCon North America 2022（以下、KubeCon）が行われました。今回弊社からはWEARやZOZOTOWNのマイクロサービス基盤、計測システムに関わるメンバー7名で参加しました。

本記事では現地の様子や弊社エンジニアが気になったセッションについてレポートしていきます。

3年ぶりにアメリカでの現地開催となったKubeCon現況

今回参加してきたKubeConはアメリカのデトロイトで現地＋オンラインのハイブリッド開催でした。この形式での開催は、今年の5月にEUで開催されたのに続き、新型コロナウイルス感染症（COVID-19、以下コロナ）のパンデミック以降2度目となっています。3年ぶりのアメリカでの現地開催ということもあり、久しぶりに対面で会う人たちとの再会を懐かしんでいる参加者が多かったように思います。

コロナが完全に収まっていないこともあり、会場内では飲食時以外マスクの着用が義務となっていました。また、以下写真のような缶バッジやシールによって積極的に話しかけて良いかや握手などの接触を許容しているかなどの意思表示ができるよう、感染対策に配慮しつつも参加者の意志を尊重できる工夫がされていました。

KubeConのスケジュールとしては、3日間にわたってキーノートやセッションを見ることができます。また、KubeCon開催前の2日間は同じ会場で共同開催となるEnvoyやKnative、eBPFなどKubernetesやクラウド周りのトピックのカンファレンスも開催されていました。

KubeConではキーノートやセッション、LTなどを通してKubernetesに関する最新のアップデートの紹介や、実際にKubernetesを採用した企業の幅広い運用ノウハウを聞くことができます。以降では参加してきた社員がそれぞれ気になったセッションについて取り上げてご紹介します。

最後に現地の様子もまとめたので、そちらもお楽しみに！

参加メンバーによるセッション紹介

Istio Today and Tomorrow: Sidecars and Beyond

SRE部ECプラットフォーム基盤SREブロックの巣立です。

Solo.ioのLin SunとGoogleのMitch ConnrsによるIstioの新しいデータプレーンモデルであるAmbient Meshについてのセッションでした。

Istio Ambient Meshは2022年9月に公開されたばかりです。これまでのIstioではアプリケーションコンテナと一緒に配置されるサイドカーモデルを採用していましたが、Ambient Meshではサイドカーを必要としません。サイドカーモデルでは、サイドカーのアップグレード時にアプリケーションの再起動が必要になったり、アプリケーションとサイドカー間の起動・終了シーケンスが複雑になったりといくつかの課題があります。

また、サイドカーではIstioの基本的な暗号から高度なL7ポリシーまで全てを実装しています。そのためL7の処理を必要としない場合でも、サイドカーコンテナを維持するため過剰なリソースが必要となります。そこでAmbient Meshでは、トラフィックのルーティングを処理するsecure overlay layerとL7 processing layerの2つのレイヤーに分割しました。レイヤーを分割したことでユーザは必要に応じてL7の処理を利用するかどうかをワークロードのニーズによって使い分けることができるようになります。

Ambient Meshを利用することで、コンピュータコストの削減や運用・アップグレードなどのオペレーションの負荷の削減など様々な恩恵を受けることができます。

（linkより引用）

また、Ambient Meshやサイドカーで実行されるワークロードは共存可能で、ユーザーはワークロードのニーズに基づいて使用することが可能になります。

（linkより引用）

こちらから実際にIstio Admbient Meshを試すことができます。

istio.io

また、会場ではLin Sun&Christian Posta執筆のIstio Ambient Explainedが配布されており自分もゲットできました！

Ambient Meshは2022年11月時点では本番環境での利用は推奨されていません。2023年の本番環境への移行に向け、現在も活発に開発が行われています。弊社もIstioを利用していますが、サイドカーのアップグレードの度にアプリケーションを再起動させるのはとても面倒に感じていました。Ambient Meshを導入できればアプリケーションの再起動も不要になり運用負荷の軽減が期待できます。今後の動向にも注目していきたいと思います。

Cloud Governance With Infrastructure As Code (IaC) With Kyverno And Crossplane - Dolis Sharma, Nirmata

SRE部ECプラットフォーム基盤SREブロックの織田です。

このセッションでは、KyvernoとCrossplaneを用いてIaCでクラウドを管理する方法が紹介されました。

Crossplaneは、クラウドネイティブなコントロールプレーンを構築するフレームワークです。Kubernetesクラスターを拡張することで複数ベンダー（AWS,GCP,Azure）のインフラストラクチャやマネージドサービスのオーケストレーションをサポートします。

Crossplaneを使うことでKubernetes上からAWS EC2やS3などを管理できます。具体的にはDeploymentやJobのようにyamlでmanifestを作成し、applyするだけなので、容易に取り入れることができます。

手元で試したい場合は、Getting Startedで簡単に試すことができます。

Kubernetesにデプロイすることによって、Kubernetesの機能であるReconcileによりAWSのインフラストラクチャやマネージドサービスが定義された状態に維持されます。また、Kubernetesで管理することによって、容易にGitOpsにも対応できることも良い点だと思います。

次にKyvernoでCrossplaneを使って作成したリソースを制限する方法についてです。Kyvernoは、Kubernetesのためのポリシーエンジンです。アドミッションコントロールやバックグラウンドスキャンを利用して、設定のvalidate,mutate,generateを行います。

KyvernoのポリシーはKubernetesリソースであり、yamlで記述するため新しい言語の学習コストは不要です。

Kyvernoを使うことによって、Crossplaneのmanifestに対して制限をかけられます。例えば開発環境ではt2.mediumのような小さなインスタンスのみ構築できるようにする、RDSの特定バージョンより前のバージョンは利用させないようにする等ができるのではと思います。

KubeConでの多くのセッションを通じて、Crossplaneが様々な企業で使われていると感じました。

弊チームではAWSリソースのIaCツールであるCloudFormationを利用しています。そのためCrossplaneに置き換えるかは非常に悩ましいのですが、ReconcileやGitOpsが活用できると考えると乗り換えを再考しても良さそうだと思いました。

“Why Can’t Kubernetes Devs Just Add This New Feature? Seems So Easy!” - Understanding the Feature Lifecycle In Kubernetes - Ricardo Katz, VMware & Carlos Panato, Chainguard

SRE部ECプラットフォームサービスSREブロックの出川です。

こちらのセッションは、Kubernetesに新しい機能が提案されてGAになるまで（または途中でreject/rollbackされるまで）にメンテナやコントリビュータの間で何が起こっているかを、具体例をもとに示したセッションです。

機能追加は本当に大変で常に様々な議論が必要になること、また共に議論をしたり実装する人が足りていないために機能追加には時間を要することが述べられていました。

ここで紹介されていた議論の観点として以下が挙げられていました。

Questions to be answered（抜粋）：

The feature solves a wide problem or is this too niche? （解決するのは広い範囲の問題か、ニッチすぎる問題か？）
Does the feature bring (or solve) a security concern? （セキュリティ上の懸念をもたらす/解決するか？）
Does the feature bring (or solve) a performance concern? （パフォーマンスに関する懸念をもたらす／解決するか？）
Is the feature a breaking change? （破壊的変更か？）
- Breaking changes in GA are not allowed! （GAに破壊的変更が入ることは許可されていない）
Was this feature discussed before? What are the conclusions of previous discussions? （以前議論されたことがあるか？以前の議論の結論は？）

このような観点での議論が、開発フェーズのあらゆるシーンで行われます。下図のように、SIG (Special Interest Groups) との議論が行われます。そしてKEP (Kubernetes Enhancement Proposal) を書くことによるコミュニティ全体への提案が行われます。その後Alpha, Beta, GAそれぞれの前段階で度重なる議論が行われることになります。

（linkより引用）

例えばkubectlコマンドの出力に色を付けたいという素朴なfeature requestがあります。
https://github.com/kubernetes/kubectl/issues/524

「kubectlに色を付けるべきか？」を考えるだけでも、「workaroundはないか、kubecolorではダメなのか」「出力に依存するスクリプトは影響を受けるか」「任意のカラーテーマを実装できるのか」「色盲の人々のアクセスビリティは変わるか」「これを長期的にメンテナンスしていくモチベーションはあるか」など、様々な観点での議論が行われます。

2018年に立てられたこのissueは、2022年11月現在まだクローズに至っていません。

（linkより引用）

他にもNetwork Policyにフィールドを追加してport rangeを指定できるようにする、kubercファイルによる設定（PR）、Ephemeral containers（PR）における例も紹介されていました。

また、どんどん新しいアイデアを上げて欲しい、コードを書くだけがcontributeではない（どんなcontributionも歓迎する）ということも強調されていました。

このセッションは自分にとって、単純にKubernetesとその周辺の開発でどのような議論がなされているかがよくわかり、非常に興味深いセッションでした。Kubernetesのような、既に多くのEnterpriseレベルの本番環境に採用されるほどのOSSはかくあるべきだと感じました。

KubeConはメンテナ等のKubernetesコミュニティの人々が直接会する場所であり、このようなセッションはコミュニティがどのようなことを考えているかが感じられます。KubeConのような場が初めてな自分にとってよい機会となりました。

参考：

Kubernetes SIGs https://github.com/kubernetes-sigs

Kubernetes Enhancement Proposals (KEPs) https://github.com/kubernetes/enhancements/blob/master/keps/README.md

Security In the Cloud With Falco: Overview And Project Updates - Jason Dellaluce & Luca Guerra, Sysdig

計測システム部SREブロックの西郷です。

このセッションではコンテナとKubernetes環境下における脅威検知のデファクトスタンダードであるFalcoについて、直近のアップデートや今後予定されているアップデートが紹介されていました。

今回はその中からいくつかピックアップしたいと思います。

直近のアップデートからは、2022/9/15に発表されたgVisorのサポートについてです。 gVisorはGoogleが開発している低レベルコンテナレイヤで、GKEやAppEngine等で利用されています。仕組みとしてはホストのカーネルとコンテナを切り離し、サンドボックス化したコンテナでセキュアにアプリケーションを実行します。この分離により、カーネルモジュールもしくはeBPFでイベントを収集するFalcoはgVisorのイベントを検知できないという課題がありました。今回のサポートによりそれが解消され、例えばGKE SandboxのgVisorを有効にした環境に対してもFalcoの利用が可能になりました。バージョン0.32.1から対応しているとのことなので、詳しくはFalcoの以下ドキュメントを参照ください。

falco.org

その他にもバージョン0.33からは同一インスタンス内で複数のイベントソースが処理できるようになったこと等が紹介されていました。これまでは複数のイベントソースからのイベントに対応するには、各イベントソースごとに複数のFalcoインスタンスをデプロイする必要がありました。

（linkより引用）

今回のアップデートにより、よりFalcoが使いやすくなったのではないでしょうか。

また、Upcomingなものとしては新しいeBPF Probeについての話がありました。eBPFの最先端機能を妥協することなく活用した新しいeBPF Probeの開発が進められており、いずれは従来のものと置き換えることが想定されているようです。現時点では80ほどのシステムコールに対応しており、従来のものより安全で高速化するだろうとのことでした。

計測システム部ではこれまでに静的解析の機構として、AquaSecurityによるkube-bench等の導入を進めてきました。まだFalcoは導入できていないのですが、ゆくゆくは動的解析の機構として導入したいと考えているので、今後も動向を注視していきたいと思います。

Migrating From Single-Node Kubernetes Control Plane To HA In Production - Cong Yue & David Oppenheimer, Databricks

ブランドソリューション開発本部SREブロックの和田です。

今回取り上げるのは、Databricks社によるKubernetesコントロールプレーンを、単一構成からHA構成へ移行した際のノウハウを紹介するセッションです。Databricks社は2016年にKubernetesを採用しました。当時コントロールプレーンのHA構成は一般的でありませんでした。単一構成の場合、可用性に問題があることはもちろん、Kubernetesクラスタのバージョンアップ等の運用においてロールバックが困難であり運用上の課題があります。そこで、単一のVMで稼働するコントロールプレーンのスナップショットを取ることで複数台のコントロールプレーンを構築し、ロードバランサーを介してHA構成を実現しています。

（linkより引用）

この構成により一部のコントロールプレーンに問題が生じた際に、該当のノードへのリクエストを避けることができます。移行時には増設したVMに対してetcdのデータをリストアし、Multi-nodeのetcdクラスターを設定した後にapi-serverの更新を受け付けるようにしています。従ってロードバランサーやetcdを増設するだけではなく、更新するタイミングを気にする必要があり、本セッションでは具体的な手順が紹介されていました。移行後のコントロールプレーンの操作は自動化して、問題が発生した場合はロールバックする仕組みを用いています。

一口にKubernetesと言っても導入時期やシステムの規模によって、直面する課題は様々だと実感しました。今回のようにKubernetesを初期段階で採用した企業の運用ノウハウが聞けるのもKubeConの魅力の1つです。このような運用に関するセッションは「Reliability + Operational Continuity」というカテゴリで確認できます。

When the Logs Just Don’t Cut It: Root-Causing Incidents Without Re-Deploying Prod

ブランドソリューション開発本部SREブロックの繁谷です。

こちらのセッションではbpftraceとPixieを用いて、デプロイなしでGoアプリケーションをロギングする様子が紹介されています。

本番環境などデバッガを展開できない環境でのインシデントの調査はログが頼りですが、ログに出ていない箇所のデータを取得する場合はログを出すためのデプロイが必要です。しかし、そのような環境へのデプロイは時間がかかったりリスクがあるなどの問題があり調査に時間がかかってしまいます。そこで紹介されているのが、eBPFをベースとしたbpftraceを用いたPixieによるアプリケーションのロギングです。

eBPFはいくつかの条件を満たすプログラムをカーネル上に動かす仕組みで、カーネルの機能を安全かつ効率的に拡張できます。

ebpf.io

bpftraceはkprobesやuprobesなど、カーネルやユーザ空間の様々な箇所にbpftrace Languageで書いた処理を指し込むことができます。Pixieはbpftraceを独自の言語で使いやすく拡張しつつその結果をビジュアライズしてくれるツールです。bpftraceによるデータの取得に関してGoアプリケーションのロギングもサポートしています。

実際にPixieを動かしてみました。Macの場合は下記のドキュメントに沿ってminikubeをローカルで用意し、そこにアプリケーションをapplyしてPixieへデプロイするだけです。

docs.pixielabs.ai

Goアプリケーションのロギングについて以下のデモを確認します。eの近似値を計算する computeE の引数 iterations をデプロイなしでロギングします。

docs.pixielabs.ai

github.com

デモアプリを立ち上げた状態ではPixieのテーブルに何も表示されませんが、APIを叩いた後に再度ロギングしてみると以下のように引数 iterations の値が得られます。

Pixieのアプリケーションの動的なロギングはGoのみの対応ですが下記の記事によるとC++やRustなども可能とあるので今後の展開に期待できそうです。

blog.px.dev

bpftraceのベースであるeBPFについてコミュニティも注目している様子が伺え、KubeCon + CloudNativeConの様々なセッションで取り上げられていました。

先に書かれているFalcoや超満員だったセッションの「100Gbit/S Clusters With Cilium: Building Tomorrow's Networking Data Plane」で扱っているCiliumもeBPFが使われています。

今回イベントへ参加してeBPFの学習やコミュニティへの貢献が大変有意義なものになることが実感できました。

Cloud-Native WebAssembly: Containerization On the Edge - Michael Yuan, Second State

計測システム部SREブロックの纐纈です。

今回のKubeConの前半に行われたLTの中で、WebAssembly（以下、WASM）のランタイムであるWasmEdge用のDapr SDKを使ったマイクロサービスアプリケーションが紹介されていました。それを見てWASMとクラウド周りの現状が気になったので事前に調べた上で、こちらのセッションを見に行ってきました。

このセッションでは、LinuxコンテナとWASMの比較から始まり、現在WASMが対応している言語やライブラリ、DockerやKubernetes上で実際に動くデモなどが紹介されました。

WASMはイメージサイズの小ささや立ち上がりの早さ、ネイティブ実行に近いパフォーマンス、デフォルトで高いセキュリティを持つ仕様、言語に依存しないなどの特徴があります。

今回KubeConの隣接イベントであるWASMConで、Technical PreviewとしてDocker上にWASMの実行環境が統合される、という発表がありました。

www.docker.com

これによって、AWSやGCPなど他のクラウド上のDocker実行環境でも動かせるようになりました。今までもWASMのアプリケーションはWASMの実行基盤が用意されているwasmCloudというクラウドで動かすことができたのですが、よりWASMの本番利用がしやすくなったと思われます。

またWASM用のDaprのSDKが開発されたことにより、LinuxコンテナとDaprを使用して現在運用されているサービスの中で補完的にWASMのマイクロサービスを使用できるようになりました。

現状WASMは既存のLinuxコンテナの環境を置き換えるものではなく、補完的に利用できる技術だと言えそうです。

最後に

メンバー全員初めてのKubeCon参加だったのですが、プロジェクトのメンテナから直接話が聞けたり質問できたりする機会であることを体感でき、非常に貴重な経験になりました。

カンファレンス期間中よく耳にしたフレーズですが、OSSはコミッターなしで成り立ちません。利用する技術を自分達で作ることができるのはOSSの醍醐味であり、普段使っている技術をただ使うのではなく、貢献していくことが大切であることを再認識しました。今回のKubeConで得た知識を業務に活かしつつ、還元していけたらと思います。

ZOZOでは一緒に働くエンジニアを募集していますので、興味のある方は以下リンクからぜひご応募ください。

hrmos.co