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

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

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

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

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

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

マルチクラスタ管理

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

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

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>

定義中の各項目は以下のような説明です。

  • mode:実行順序の設定
  • dependsOn:ステップ間の依存関係を定義
    • 例えば、step1のデプロイを待ってから、step2は実行するような使い方ができます
  • input/output:ステップ間のデータ入出力
  • subSteps:ステップをグループ単位にまとめて制御出来る

他のパラメータや詳細については、以下が参考になります。

KubeVela – K8S API for Pipeline

まとめ

今回は、KubeVelaのWorkflowとデプロイプロセスについてまとめてみました。

様々なインフラ環境に対応している中で、マルチクラスタを扱っていく過程では、定義が複雑になりがちですが、policyでの定義と再利用をうまく活用していくことで対応が可能みたいです。

ステップについてもCUEでカスタマイズが出来るようになっているので、このあたりも掘り下げられればと思います。

本書の記載が読者のお役に立てれば幸いです。

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です