KubeVela – Workflowとデプロイプロセス

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

こんにちは。サイオステクノロジーの塙です。

前回は、KubeVelaのアーキテクチャについて紹介しました。

今回は、KubeVelaを使用して、アプリケーションのデプロイを行うために定義内でどんな制御をすればいいか、またそのデプロイプロセスについて記載をしたいと思います。

前回までの記事については、以下が参考になります。

KubeVela とは？ – アーキテクチャのご紹介

1 マルチクラスタ管理
2 デプロイプロセス
3 pipeline(WorkflowRun)
4 まとめ

マルチクラスタ管理

まず、マルチクラスタとして管理するユースケースは数多くあります。

大規模向けに、スケーラビリティの観点として
可用性の観点として、本番環境用とバックアップ用のマルチクラスタ環境

KubeVelaがデプロイ先に指定出来るインフラ環境は、様々な環境に対応しているようで、マルチクラウド、k8sマルチクラスタ、ハイブリッドなどのサポートをしてるみたいです。

マルチクラスタ管理は、Cluster Gateway（前回を参考）を利用したり、Open Cluster Management（OCM）を有効にして構成出来ます。

OCMについては、以下が参考になります。

KubeVela – About OCM

Open Cluster Management

デフォルトでは、kubeconfigを使用して接続するようです。

後述では、KubeVelaのPolicyとWorkflowを使用してマルチクラスタアプリケーションを配信する方法を記載します。

デプロイプロセス

■ アプリケーションのデプロイ

Policyを通じてクラスタを指定することにより構成出来ます。

アプリケーションを複数のクラスタにデプロイする例を以下に示します。

spec:
  components:
    ...(snip)...
  policies:
    - name: policy-1
      type: topology
      properties:
        clusters: ["cluster-1", "cluster-2"]
    - name: policy-2
      type: topology
      properties:
        clusters: ["cluster-3"]
  workflow:
    steps:
      - type: deploy
        name: deploy-12
        properties:
          policies: ["policy-1"]
      - type: deploy
        name: deploy-3
        properties:
          policies: ["policy-2"]

topology policyを使用して、登録されているクラスタを選択します。
簡単な方法としては、workflowのステップの中で、デプロイを行うpolicyを選択します。リストで表現が可能なので、異なる環境に同時に展開することも出来ます。
場合によっては、複数のApplicationで同じパターンのデプロイを行うケースもあります。
policy別にマニフェストとして管理を行い、Application内でそれらを参照することが出来るので、再利用して活用することが出来るみたいです。

pipeline(WorkflowRun)

ApplicationのWorkflowに対して、pipeline(WorkflowRun)という機能があります。

pipelineは以下のような特徴があります。

複数の環境で、複数のApplicationの管理ができる
複数のApplicationを実行する時の大元の定義みたいなイメージ
Applicationとは依存性はなく、独立している
リソース（Deployment, Service）自体は管理しない

複数のApplicationを実行するケースがある場合に、pipelineを使用してそれらをまとめて実施・管理が出来るイメージでしょうか。

簡単にApplicationとの区別点を以下に記載します。

定義

リソース

（フィールド）

構成要素

アドオン

Application

Workflow

Components, Traits, Policy

不要

pipeline

WorkflowRun

–

vela-workflow

■ pipelineの構成

WorkflowRun リソースによって表される
ステップの構成のみがあり、Components, Traitsなどの構成はない
vela-workflowアドオンが必要

apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: <name>
  namespace: <namespace>
spec:
  mode: 
    steps: <DAG or StepByStep>
    subSteps: <DAG or StepByStep>
  context:
    <optional custom contest values>
  workflowRef: <optional external workflow template to run>
  workflowSpec: <optional workflow spec to run>
    steps:
    - name: <name>
      type: <type>
      dependsOn:
        <specify the dependency for the step>
      meta: 
        alias: <alias>
      properties:
        <parameter values>
      if: <if condition>
      timeout: <timeout>
      outputs: 
        - name: <name>
          valueFrom: <value>
      inputs: 
        - name: <name>
          parameterKey: <parameter>
      subSteps:
        <optional sub steps if the type of this step is step-group>