CRDs の一種である Argo Rollouts に入門して、その良かったポイント、良くなかったポイントを書いていきます。

Argo Rollouts とは

詳細な説明は公式に譲るとして、僕の見解を述べていきます。

https://argoproj.github.io/argo-rollouts/

Argo Rollouts は、既存の Deployment Resource などの仕組みを拡張して、アプリケーションのデリバリに必要と思われる要素を追加した Custom Resource と、その Resource を利用してデリバリを行う Controller から構成されるシステムです。

Argo と付きますが、 ArgoCD とは別プロダクトであり、Argo Rollouts 単体で動作します。

既存の仕組みによるデリバリ

現在、Kubernetes におけるデリバリには Deployment リソースがもっぱら利用されます。

Deployment リソースは、ReplicaSet リソースを作成、操作する役割を持ち、単体で Rolling Update や Rollback を実行できます。

単一のバージョンのアプリケーションを上手にデリバリする、という点において Deployment リソースは非常に優れていると考えます。

Deployment リソースによるデリバリの課題

Deployment リソースにおける課題は、複数バージョンを同時に稼働させることができない、他リソースとの連携が薄いことが挙げられます。

他リソースとの連携に関しては、例えば Service リソースと連携する際には Selector による Pod への振り分けしか存在せず、この Pod にはこの Service からアクセスさせる、といった制御が単一の Deployment リソースでは実現できません。

Deployment リソースが他リソースに対して依存を持たないという設計は僕は好きですが、実世界のユースケースを鑑みるにもう少し機能があっても良さそうに感じます。

Rollout リソースによる解決

Argo Rollouts では、Rollout リソースを新たに定義することでこの課題に取り組んでいます。

具体的には、

• Strategy の拡充
  • BlueGreen, Canary Strategy を定義し、複数 ReplicaSet が共存する構成を定義可能
• Service リソースとの連携
  • Active, Preview の Service を設定し、Service リソースの書き換えによりトラフィックを制御可能

というアプローチが実装されています。

特筆する点は、Rollout リソースは ReplicaSet を直接 Owner として持つ、Deployment リソースの代替リソースであるという点です。

アプリケーションデリバリの中心を握りにいったポイントが野心的でいいなと思いました。

以下に、Rollout リソースの現段階での Example を掲載しておきます。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen: 
      activeService: rollout-bluegreen-active
      previewService: rollout-bluegreen-preview
      autoPromotionEnabled: false

ほぼ見た目が Deployment リソースと変わらない点と、 strategy.bluegreen アトリビュートが追加されている点が目に付きます。

blueGreen では、基本的なトラフィックを受ける activeService と、テスト用トラフィックを受ける previewService が用意されています。

podTemplate が更新されると、Deployment では、previous version の ReplicaSet は最終的に 0 に収束するのに対し、 Rollout では、blueGreen では、最新の ReplicaSet と同数が確保されます。

kubectl argo rollouts promote rollout-bluegreen を実行するか、 autoPromotionEnabled を true にすると、previewService の selector が activeService にコピーされ、previous version の ReplicaSet が 0 に変更されます。

このように、複数バージョンの ReplicaSet が同時に稼働すること、Service リソースの書き換えが実施されることが Rollout と Deployment の大きな差分となります。

その他のリソース

その他、Argo Rollouts には便利なリソースが存在します。

• Ephemeral ReplicaSet を追加できる Experiment リソース
• バックグラウンドで Success Rate などを監視して Strategy に適用できる Analysis リソース群

一部リクエストだけ10分間新しいバージョン通してみて、エラーが出なかったら自動で BlueGreen で切り替える、といったストラテジを、 Argo Rollouts では宣言的に管理することができます。すごいですね。

まとめ

どのくらい柔軟に制御できるか、もうちょっと検証してみようかと思います。