Static Rulesで閾値を決定するソリューション
Flagger
Flaggerは、FluxCDでプログレッシブデリバリーを実現するための追加コンポーネントです。
Kubernetesのカスタムコントローラーとして提供されているため、Kubernetes上で動作するアプリケーションのみが対象となります。
上で説明した3つのステップ（トラフィック制御→分析→自動化されたロールバック）に従い、まずカナリアとなるPodsをデプロイします。そしてそのカナリアPodsへのトラフィックを徐々に増やしていきます。
FlaggerはトラフィックシフティングするためにサービスメッシュかIngressコントローラーのどちらかを利用します。
分析のために、Flaggerはモニタリングシステムから定期的にメトリクスを取得します。「分析のポイント（1）最適なメトリクスの選択」で紹介したようなメトリクスの決め方に応じてクエリを作成し、Flaggerに設定します。
その後、設定された静的な閾値の範囲内に収まっているかを確認します。収まっていない場合は即座に全トラフィックを現行バージョンに戻し、カナリアを削除します。
分析フェーズでカナリアのメトリクスを取得できるように、事前にモニタリングシステム側に設定を追加しておく必要があります。例えばPrometheusを使う場合は、TargetとしてカナリアのService等を追加します。
細かなトラフィック制御とシンプルな設計が特徴ですが、サービスメッシュかIngressコントローラーに頼っている点が導入障壁を高くしていることは間違いありません。
KubernetesであればPod数の割合を調整することができますが、作者のStefan Prodanはそれをサポートする予定は無いことを明言しています。
次の節で紹介するArgo Rolloutsではこの方法を採用しています。
Argo Rollouts
Kubernetesのカスタムコントローラーとして提供されているソリューションとして、Argo Rolloutsも有力な候補です。こちらはArgoCDと同じIntuit社が開発しており、Flaggerと同じようにKubernetes上で動作するアプリケーションのみが対象となります。
Argo RolloutsもFlaggerと非常に似通った仕組みで動作します。モニタリングシステムから適切なメトリクスを取得できるように設定し、静的な閾値と比較することでカナリアを分析します。
Kubernetesはkube-proxy経由でPodの数を調整することでもトラフィックスプリッティングが可能です。
前述した通りArgo Rolloutsはそれを利用することができるので、数％ごとの細かいトラフィック制御の必要がなければ十分と言えます。現時点では世界的にもサービスメッシュの導入事例がそこまで多くないため、そういった点では既存システムへの導入が容易だと考えられます。
ただArgo Rolloutsは、DeploymentをラップしたRolloutというカスタムコントローラーを使ってアプリケーションのロールアウトを行います。そのため、既にDeploymentを利用した既存プロジェクトに導入する場合は、マイグレーションのコストがかかります。十分にテストされていますが、Kubernetes標準のDeploymentと比べると信頼性の面では劣ります。
静的な閾値による分析の他にもExperimentsという機能も提供しており、後述するKayentaスタイルの分析をすることも可能です。
PipeCD
PipeCDは、Static Rulesベースの分析機能を提供するソリューションとしては後発のものになります。
これまで紹介したソリューションとは違って、Google Cloud RunやAWS Lambda、Amazon ECSなど、Kubernetes以外のアプリケーションへのプログレッシブデリバリーをサポートしている点が特徴です。また、プログレッシブデリバリーのために追加コンポーネントを導入する必要はなく、PipeCD単体ですべてのプロセスを実行できます。
PipeCDはデプロイに必要なタスクをStageという単位で提供しており、それらを組み合わせることでデプロイフローを構築していきます。分析についてはAutomated deployment analysisというステージが担当しており、分析結果に基づいて次に実行されるステージが自動で決定されます。
こちらもサービスメッシュは必須ではなく、Pod数の割合を調整することで大まかなトラフィックシフティングが可能です。PipeCDはCRDを使っていないため、標準のKubernetesリソースだけで段階的にロールアウトしていくことが可能です。
