AP Communiicatoin 、ACS事業部の亀崎です。
KubeCon EU 2023のセッションで、「Tutorial: Deploying Cloud-Native Applications Using Kubevela and OAM」というものがありました。こちらのセッションではOAM(Open Application Model)の概要と、OAMの実装のひとつであるKubeVelaを実際にどのように使うかを紹介していました。今回はこのセッションの先にあるPlatform Engineeringとの関係について考察してみたいと思います。
OAM / KubeVelaの概要
Kubernetesの課題のひとつは、設定の複雑さです。アプリケーションを実行しようとする際に、そのアプリケーション開発チームが様々な指定をしなければなりません。このことを本セッションでは「Bottom Up」での指定と呼んでいました。
これを解決しようとするのがOAMであり、KubeVelaです。アプリケーションを実行する際に必要な設定項目をよく見ていくと、実は本当に設定しなければならない部分は少数で、多くの部分はアプリケーションの種別によって概ねパターンが決まっていることがわかると思います。OAM/KubeVelaではこうした「パターン」の部分をComponentとして規定し、それにアプリケーション固有の指定を加えることで最終的なYamlを生成しようとしています。
例えば一般なWebServiceの指定は次のようになります。
apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: website spec: components: - name: frontend type: webservice properties: image: oamdev/testapp:v1 cmd: ["node", "server.js"] ports: - port: 8080 expose: true cpu: "0.1" env: - name: FOO value: bar - name: FOO valueFrom: secretKeyRef: name: bar key: bar
アプリケーション開発者が指定するのはこれだけです。
Componentとして一般的な「webservice」という指定をし，それに対して名称や実行コマンド、環境変数などを指定するだけで、自動的にDeploymentやServiceに変換されるのです。そして、さらにオプション機能がもし使いたいということであれば Traitというものでそうしたものを追加することができます。また、ポリシーなども「標準的な」ものが用意されています。
# vela-app.yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: first-vela-app spec: components: - name: express-server type: webservice properties: image: oamdev/hello-world port: 8000 traits: - type: gateway properties: domain: testsvc.example.com http: "/": 8000
たとえば traitは上記の traits:の指定のような形式で指定します。
これにより開発者は、そのアプリケーションに必要な項目のみを指定するだけでデプロイすることができるのです。これを「Top Down」による指定と呼んでいます。
Platform Engineering / Platform Teamにおける利点
さてこのKubeVelaのComponent、Trait、Poliicyといったものは自由に定義することができます。例えば組織共通で指定しなければならない指定をComponentに追加しておくこともできますし、Platform Teamが用意したサービスの利用をTraitを通じて公開することもできます。組織的に矯正したい Policyなども指定することができます。
こうした組織横断的なものを用意することができるのがKubeVelaのポイントです。この部分がまさにPlatform EngineeringにおけるPlatform Teamが行いたい部分にマッチしているものと思います。
KubeVelaではこのことを「関心時の分離」と呼んでいます。 （アプリケーション設計における関心事の分離と同じような概念です）
組織横断的なポリシー等の検討や、デプロイ用コンフィグレーションの標準化を行いたい Platform TeamはComponent / Trait / Policyの作成（開発）に専念し、アプリケーションの実行に集中したい開発者はPlatform Teamが用意・指定した Component / Trait / Poiicyを利用すればよい。そして Platform Teamが用意した Component等に変更を行った場合でも、それを利用してるアプリケーションには自動的に更新できるようになる。
このようなことを実現したいのが Platform Engineeriing の目標の１つではないでしょうか。こうした点でKubeVelaは Platform Engineeringにマッチしているのではないかと考えています。
KubeVelaはKubernetes上で実行するツールですが、その利用は実はKubernetesだけにとどまるものではありません。最近はCrossplane のように、クラウドリソースをKubernetesから管理・プロビジョニングできるようなサービスもあります。つまりこうしたサービスと KubeVela を組み合わせることによって、クラウドリソースやアプリケーションを一括して管理する アプリケーション実行環境の「コントロールプレーン」を実現できるようになると考えています。
別のセッションで発表されていたコンプライアンスについても、こうした仕組みで実現できるのではないかと考えます。
さらに、Platform Teamで用意する Component / Trait / Poliicy などはBackstageのカタログやドキュメントとして登録公開することで開発チームがいつでも参照・利用することができるようになり、アプリケーションでの指定についてもTemplateという形で共通化できるようになるのではとも思います。 さらに、BackstageでPlatform Teamや開発チームがそれぞれの知見を公開・議論できるようにすることで、各種標準パターンの継続的な改善も組織全体で実施できるようになると考えています。
いかがでしょうか。Platform Engineerとして、こうした世界を見てみたいと思いませんか？
