本セッションの登壇者
セッション動画
それでは、「KubeCon + CloudNatieCon NA 2022 帰国後即日 Recap LT」というタイトルで、本日はお話をさせていただきます。
サイバーエージェントでKubernetes as a serviceプロダクトオーナーとして勤務している青山と申します。もしかしたら「Kubernetes完全ガイド」(インプレス)を読んでいただいている方もいらっしゃるかなと思います。
ほぼコロナ前の水準に戻ったKubeCon
本日は、KubeConというKubernetes関連のカンファレンスのRecapをしたいと思います。ちょうど昨日の午後3時45分ぐらいに羽田に着陸して、24時間後くらいなので、新鮮なLTができたらと思っております。
軽くイベントの概要ですが、KubeCon + CloudNatieCon NA 2022は、10月24日から28日にかけて開催されたカンファレンスです。今回はデトロイトで開催されて、バーチャルでも見られる形になっていました。
コロナ前の最後のカンファレンスはだいたい1万2000人ぐらい参加していて、去年の実績は3500人ぐらいでした。
今回は、体感で言うと7000 - 8000人ぐらいはいたかなと思います。だいたいもとのKubeConに戻ってきた形になっています。立ち見や満員のセッションもけっこうあって、コロナ以前との違いもほとんどなく、マスクの着用とセッション会場内で飲食が禁止になった程度という印象でした。
日本からの参加者も、各企業いろいろなところから40名ほどが参加していました。
次回はアムステルダムとシカゴなので、ご興味がある方はぜひ現地参加も検討してみていただければと思います。
再起動なしにCPU/メモリを適時に動的割り当て
さっそく内容に入っていきたいんですけれども、本日は私が最近注目しているeBPFとWASMの話でおもしろかった短いお話をひとつずつと、あとkubectl bindというKubernetes APIを拡張してオペレータをうまく使っていこうという話をひとつ、合計3つを2分ぐらいずつ、軽くご紹介できればと思います。
1つ目が「Resize Your Pods In-Place With Deterministic eBPF Triggers」というタイトルのセッションです。
まず前提知識として今、In-placeのPod Resizeという機能のKubernetesへの実装が進められています。これは、コンテナのCPUやメモリの割り当てをコンテナの再起動なしで動的に変更できるようにする機能です。これが実装されると、KubernetesのPodの.specを書き換えると、コンテナのCPUとメモリのリソース割り当てを即座に変更できるようになります。そこで、eBPFを使って特定のイベントをトリガーして、そのトリガーをもとに、特定の期間や特定のタイミングだけCPUやメモリの割り当てを動的に変更しましょうというセッションでした。
ユースケースとしてこのセッションで語られていたのは、開発用のコンテナの中でmakeコマンドを実行したときだけCPU使用率がはねたりするので、そこだけCPU割り当てを変更しましょうという話です。定期的に特定の処理をする時だけリソースを多く消費するようなデーモン系のプロセスの場合にも、同じ仕組みでリソース割り当てをうまく変更できます。
たとえばこのeBPFトリガーがなく、VPAとIn-placeのPod Resizeだけで実行すると、makeコマンドなどの突発的スパイクに対してCPUやメモリを増やしたりするのが少し遅れます。
したがって、必要なときにリソースが足りなくて、不必要なときに余分に確保されてしまうといった状態になってしまうのですが、このセッションでは理想的に使われているときだけリソース割り当てをうまく増加させるのが狙いです。
makeプロセスが実行されたことをeBPFで取得して、実際にトリガーした後に、Kubernetes APIサーバのPATCH経由でコンテナのリソースの割り当てを変えていくという流れが説明されていました。
今回はさわりだけでしたが、このセッションでは「In-Place Pod Resizeに伴ってKubernetes側のどういう実装が変更されてどういうステータスが追加されたか」「eBPFトリガーの実装例」、デモなども紹介されているので、興味のある方は見てみてください。
Kubernetesのイベントドリブンでリソース伝播する仕組みはうまく作られていると思いますが、このセッションで良かったのが、Kubernetesのリソースで取れない情報をeBPFでトリガーしてKubernetesのAPIに反映させて、そこからコントローラなどのイベント駆動に乗せることができるのは興味深い話でした。今後も発展しておもしろいことができそうです。
Fluent BitがWASMプラグイン対応、DockerもWASM対応に
2つ目がFluent Bit V2の話とWASM関連の話です。
Fluent Bit V2が10月25日にリリースされました。いろいろな機能も追加されているので、詳しくは別途見ていただきたいと思います。
今回お話したいのが、プラグインサポートの追加です。今回Fluent Bitでは、WASMで実装したinputやfilterのプラグインを差し込めるようになったことが、個人的におもしろかったトピックです。
今までもEnvoyやOpenPolicyAgent(OPA)などで機能拡張したいときにWASMを利用するケースがありましたが、Fluent BitでもWASMを使って機能を拡張できるようになりました。機能拡張するときにWASMを使うパターンが今後もどんどん増えていきそうで、市民権を得ているというか、有用なパターンのひとつとして認知されてきていると考えています。我々もプロダクトを作るときには、こういうWASMプラグインの仕組みを使っていくのがいいんじゃないかなと思っています。
あともうひとつは、DockerのWASM対応です。これはDocker上でWASMの実行が可能になる仕組みです。
KubeConのブースでもDocker + WASMを押していました。runCの代わりにOCIランタイムとしてWasmEdgeという、去年の10月ぐらいにSandboxプロジェクトに入った2番目のWASM Runtimeを使っているのが特徴です。
OCIに準拠しているので、下記のようなDockerファイルを使ってイメージを作って、それを直接実行できます。純粋にWASMのバイナリを作って、それを配置してENTRYPOINTに指定しておけば、実際にWASMで実行できるという形です。WasmEdgeはWASI以外にも、HTTPやKVSなどとやりとりするインターフェースも実装されているそうなので、そういったところもおもしろいなと思いました。
OperaterをSaaS-likeに簡単に利用可能に
最後はkubectl bindの話です。
時間がないので割愛しますが、オペレータなどを今のようにKubernetesの自分のクラスタにデプロイするのではなく、プロバイダ側にデプロイされたものをbindして、実体は自分たちのクラスタで持たない仕組みを作るプロジェクトです。
このあたりの詳細については11月24日のKubernetes Meetup Tokyoでお話ししたいと思うのでぜひ見に来てください。
ご清聴ありがとうございました。
