FlaggerでBlue/Greenデプロイメントを試した

先日FlaggerでBlue/Greenデプロイメントをやる案件があり、FlaggerのインストールからBlue/Greenデプロイメントの動作を確認するところまで一通りを試したので、結果を残しておく。
今回はSlackへの通知を設定したので、更新があったりプロモーションが完了したりするとSlackに通知が来る様になっている。

Flaggerインストール及びBlue/Greenデプロイメント

Flagger インストール

基本的には以下のページを参照。Istioを有効にしてデプロイしたGKEクラスタ向けの手順もあるが、より汎用性の広い手順を試した。
https://docs.flagger.app/install/flagger-install-on-kubernetes

Flaggerのインストールは基本的にhelmを使って行う。まずはhelmのリポジトリを追加する。

helm repo add flagger https://flagger.app

次にFlaggerで使用するCanary CRDを追加する。名称はCanaryだが、カナリアデプロイのほか、Blue/green deploymentでも使用する。

kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml

Flaggerで使用するメトリクスサーバとしてprometheusを使用する。今回はistioサンプルのprometheusインストール用プロファイルを使用する(あらかじめどこかしらにistioのリリースをダウンロードしている前提。ダウンロードしていない場合、istioのリポジトリを直接指定しても可)。

Kubectl apply -f ./istio/samples/addons/prometheus.yaml

Flaggerをhelmでインストールする。flaggerはhelmインストール時の引数で機能を有効にするので、今回はメッシュプロパイダーとしてistio、メトリクスサーバとしてprometheus、通知先としてslackを登録する。あらかじめslackにアプリを登録し、webhook urlを取得しておく必要がある。また、通知先のチャネルはアプリ側のチャンネルに上書きされる。

helm upgrade -i flagger flagger/flagger \
--namespace=istio-system \
--set crd.create=false \
--set meshProvider=istio \
--set metricsServer=http://prometheus:9090 \
--set slack.url=https://hooks.slack.com/services/your/webhook/url \
--set slack.channel=general \
--set slack.user=flagger-app

Blue/green deployment

Blue/green deploymentは以下のページを参照しつつ検証した。
https://docs.flagger.app/tutorials/kubernetes-blue-green
また、使用したコードは以下のリポジトリに保存した。
https://github.com/uS-aito/argocd-and-flagger-labo

Blue/green deploymentの検証はtest namespace上で行うので、まずはtest namespaceを作成する。

kubectl create ns test

まず、各種テストで使用するPodをデプロイする。

kubectl apply -k github.com/weaveworks/flagger//kustomize/tester

次に、サンプルアプリをデプロイする。

Kubectl apply -f app -R

Podinfoコンテナを含むdeploymentリソースと、CPU使用率を参照してpod数を2-4の範囲で調整するhpaリソースがデプロイされた。
flaggerはまずprogressive deliveryで管理したいdeploymentをデプロイしておき、次にそのdeploymentをspec.targetrefで指定したcanaryリソースをデプロイする。このcanaryリソースは指定されたdeploymentを基にしたprimary deployment(リソース名は元のdeploymentに-primaryをつけたもの)をデプロイし、元のdeploymentのpod数を0にスケールする。その後、元のdeploymentに変更があるたび、canary deployment(リソース名は元のdeploymentに-canaryをつけたもの)をデプロイし、メトリクスの確認等の動作を行なった上で、トラフィックを誘導する。

Canaryリソースをデプロイする。

Kubectl apply -f canary.yaml

これ以降、元のdeploymentにpodの再生成が必要な更新が加えられるたび、canary deploymentの作成以降の動作が行われる。その様子は以下のコマンドで確認することができる。

kubectl -n test describe canary/podinfo

Slackへの通知

flaggerのインストール時にSlackのwebhook URLを指定したので、何かあるたびにSlackへ通知が来る様になっている。その通知の例は以下の通り。

更新が成功した場合

Canary alaysisとなっているが、やっていることはBlue/Green Deploymentである。

更新が失敗した場合

一度デプロイしたものの、メトリクス条件を満たさなかったのでロールバックが発生した場合の例。