KubeCon EUレポート Alibabaが本番環境で使うKubeVelaとDaprのセッションを紹介

KubeCon EUからAlibabaのエンジニアが行ったKubeVelaとDaprに関するセッションを紹介する。KubeVelaはAlibabaとMicrosoftが開発をリードするオープンソースソフトウェアで、2020年にSan Joseで開催されたKubeCon NAで初めて公開された、Kubernetesをベースにしたアプリケーションのためのプラットフォームだ。

KubeVelaか登場する背景

KubeVelaは、Kubernetesがインフラストラクチャー寄り過ぎるというデベロッパー側の発想から産まれたと言えるだろう。実際Microsoftは、これまでに何度も「Kubernetesはデベロッパーに不要な苦労を強いている」と発言しているし、本セッションでも触れられているDapr（Distributed Application Run-time）をオープンソースとして公開したり、CNCFのApplication SIGでOAM（Open Application Model）を標準仕様として公開したりしている。言わばMicrosoftは「Kubernetesをもっとデベロッパーに寄りにしたい」派の中核であり、Alibabaはそれに賛同している組織と言えよう。

Daprについては以下の記事を参照されたい。

参考：Microsoftがリードするモダンな分散システム用ランタイムDaprとは？

Microsoftは、クラウドネイティブなシステムの根幹が分散することにあると思っているのだろう。OAMというスペックに従ってインフラストラクチャーであるKubernetesを抽象化し、さまざまなプログラミング言語から利用できるプラットフォームとしてのKubeVelaに注力していると言える。Daprはサイドカーとして実装されるProxy機能より多くの機能を提供するランタイムとして紹介され、その上でKubernetesに特化したプラットフォームとしてRudrを2019年に開催されたIgnite 2019で発表したが、KubeVelaはその進化版というようにも見える。

参考：分散型アプリの開発と運用を分離するOAMとDapr、そしてKubernetes上の実装であるRudrとは？

KubeCon EU 2021でのセッションは以下のリンクから視聴できる。

AlibabaによるKubeVelaとDaprのセッション：Zero Pain Microservice Development and Deployment with Dapr and KubeVela - Hongchao Deng, Alibaba

「Zero Pain Microservice Development with Dapr and KubeVela」というタイトル。

開発者に優しくないKubernetes

セッションを担当したのはAlibabaのHongchao Deng氏だ。Deng氏はAlibabaのスタッフエンジニアだが、CNCFのブログに寄稿するなどクラウドネイティブなシステムにおけるインフルエンサーとも言える存在で、同時にOAMやCrossplaneのコミッターでもある。Crossplaneは複数のクラウド上のKubernetesをオーケストレーションするソフトウェアで、OAMに準拠しているプロジェクトでもある。

Deng氏の自己紹介

Microsoftが考える「デベロッパーに優しいKubernetes上のプラットフォーム」を実現するための発想の基本は、デベロッパーはビジネスをコードに落とし込むことに専念するべきで、Kubernetesの実装はアプリケーションオペレータと呼ばれるアプリの運用担当者が行い、それを実際の仮想マシンやハードウェアに載せるのは、インフラストラクチャーオペレータがやるべきという役割分担である。それに基づいてKubeVelaもデベロッパーが設定すべき情報は最小限にして、それ以外はプラットフォームの運用担当者が管理するという発想に基づいている。ここからはDeng氏が、デベロッパーにとってのKubernetesの難しさを解説するフェーズとなった。

アプリケーションを実装するためには多くの設定が必要であることを訴求

このスライドではDeploymentとStatefulSetというKubernetesに特有の設定を挙げて、例えばWebサーバーを実装するためだけにも多くの設定が必要になり、それをすべてYAMLファイルとして表現する必要があることを解説した。

またCNCFの分科会であるApplication SIGでも、アプリケーションが必要とするべきメタデータについては議論が行われているが、現在は活動が滞っており、デベロッパーの問題を解消していないと説明した。確かにApplication SIGのGitHubページは最後のUpdateが1年以上という内容が多く、SIGとして機能していないのがわかる。

CNCFのApplication SIGも停滞中

参考：kubernetes-sigs / application

またアプリケーションにフォーカスしたソフトウェアとして、ライフサイクルマネージャーのHelmを例に挙げて、ブラックボックスでありデベロッパーが再利用できるテンプレートがないことなどを解説した。

Helmの欠点を解説

さらに多くの企業が「Kubernetesがデベロッパーに難しすぎる」問題を解決するために、Kubernetes-as-a-Serviceを自作のCRDとコントローラーで実装していることにも言及した。そしてそれを続けるためにはKubernetes自身を開発した経験が必要であり、拡張性に欠けることを指摘した。

自作CRDとコントローラー問題を解説

そしてAlibabaが求める解決策は、デベロッパーには最小限の抽象化されたAPIだけを提供すること、リソース定義と再利用のための単一の仕組みを提供することだと解説した。このスライドで使われている「user」というのはデベロッパーのことだと解釈するべきだ。

必要な機能を解説

KubeVela

ここからKubeVelaを紹介するフェーズとなった。

KubeVelaの紹介

この中の「compose different resources」というのがポイントで、デベロッパーとインフラストラクチャー運用者がそれぞれ必要な情報を定義できることを指している。

KubeVelaのアーキテクチャー

このアーキテクチャーのイラストではDeveloper userが最初にターゲットとなる環境を選択し、その後でアプリケーションに必要となる情報を格納したテンプレートを選択、必要な値を埋め込んだ後でKubernetes上に実装する流れが示されている。ドキュメントの形をした矩形が「Workload Type」と「Trait Type」に分かれていることがわかる。これらの設定情報をデベロッパーが選択して組み合わせることで、最終的なアプリケーションを実行するための設定情報が構成されるという流れだ。

KubeVelaの設定情報の例

このスライドでは、アプリケーションの設定情報には「Component」と「Trait」が存在し、それを組み合わせて利用するのがKubeVelaの発想であるということが説明されている。アプリケーションは複数のコンポーネントから構成され、それに追加の設定情報をTraitで記述する。右側のYAMLは完成形としての設定情報となるが、TraitはManifestoにオーバーレイする形で実装されることが記述されていることから見れば、Kustomizeのように一つのテンプレートから開発、テスト、本番などのバージョンのYAMLを作るのではなく、複数の小さなYAMLを組み合わせてそれぞれの環境に必要なYAMLを作るのがKubeVelaの作法ということなのだろう。

Componentの記述例

Traitの記述例

Metricsを設定する際のTraitの例

この例ではプラットフォームチームがOperatorとしてメトリクス収集のためのTraitを定義し、それをデベロッパーがアプリケーションの中で利用するという流れが示されている。

最後にManifestoのオーバーレイの機能以外にもロールアウトの方法やマルチクラスターへのロールアウト、ヘルスポリシーの実装などがその他の機能として挙げられている。ここに出てくるCUEとはオープンソースのデータバリデーションのためのプログラミング言語で、JSONのスーパーセットとなっている。Salesforceが開発をリードしているようだ。ここではレポーティングのために使われているということが解説されている。

KubeVelaの他の機能の概略

DaprとKubeVela

次にDaprの大まかな説明を行った。Daprは分散アプリケーションのためのランタイムであり、モジュラー形式で追加削除ができること、プラグインによって拡張できること、プラットフォームを選ばないことなどを簡単におさらいした内容となった。

Daprの概略

その後でAlibabaにおけるKubeVelaとDaprの実装について説明。

AlibabaにおけるKubeVelaとDaprの概要

ここでは、AlibabaのエンジニアがKubeVelaとDaprのそれぞれにコミッターとして参加していること、10以上のプラットフォーム、1000以上のアプリケーションで実装が進んでいることを簡単に紹介した。

Alibabaの導入例。サイドカーからメトリクスを取得しOpenTelemetryに

このユースケースでは、ごく簡単にサイドカーとして実装されたDaprラインタイムからメトリクスを取得してOpenTelemetryに渡し、最終的にPrometheusで管理する流れが示されているが、詳細についてはまだ公開する段階ではないというところだろう。

KubeVelaのドキュメントには、比較対象としてHerokuなどのPaaS、サーバーレス、HashiCorpのWaypoint、Helmなどが挙げられている。PaaSが最初に比較対象となっていることからもKubernetes-as-a-Serviceを作りたかったという意図が表されているように思える。またComponentやTraitの記述にCUEだけではなく、HelmのテンプレートやTerraformのモジュールなどを利用できるということからもわかるように、ベンダーロックインしないというのがデザインポリシーとして活かされているということだろう。

ちなみにHashiCorpのWaypointについては、以下の記事を参考にして欲しい。

参考：ビルドからリリースまでを抽象化するWaypointにディープダイブ

また、より詳細な比較については以下から参照されたい。

参考：https://kubevela.io/docs/#comparisons,Introduction KubeVela

Microsoftは「Kubernetesはデベロッパーへの負担が大きいので、インフラオペレータに任せたい」と考えている。Alibabaはこれに賛同し、KubeVela＆Daprという選択肢にベットしたとも言える。これからどのように発展、もしくは変化していくのか、引き続き注目したい。

公式サイト：KubeVela