Flagger と Istio を使用した自動カナリア デプロイメント

CD はエンタープライズ ソフトウェアの実践として認識されており、確立された CI 原則の自然な進化の結果です。 ただし、おそらく管理の複雑さと、導入の失敗がシステムの可用性に影響を与える恐れがあるため、CD は依然として非常にまれです。

報告者 は、混乱を招く関係を排除することを目的としたオープンソースの Kubernetes オペレーターです。 Istio トラフィック オフセットと Prometheus メトリクスを使用してカナリア デプロイメントの推進を自動化し、管理されたロールアウト中のアプリケーションの動作を分析します。

以下は、Google Kubernetes Engine (GKE) で Flagger を設定して使用するためのステップバイステップのガイドです。

Kubernetes クラスターのセットアップ

まず、Istio アドオンを使用して GKE クラスターを作成します (GCP アカウントをお持ちでない場合は、サインアップできます) ここで - 無料のクレジットを取得します)。

Google Cloud にログインし、プロジェクトを作成し、そのプロジェクトに対する課金を有効にします。 コマンドラインユーティリティをインストールする gクラウド そしてプロジェクトをセットアップします gcloud init.

デフォルトのプロジェクト、コンピューティングエリア、およびゾーンを設定します (置き換えます) PROJECT_ID あなたのプロジェクト用):

gcloud config set project PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

GKE サービスを有効にし、HPA および Istio アドオンを含むクラスターを作成します。

gcloud services enable container.googleapis.com
K8S_VERSION=$(gcloud beta container get-server-config --format=json | jq -r '.validMasterVersions[0]')
gcloud beta container clusters create istio 
--cluster-version=${K8S_VERSION} 
--zone=us-central1-a 
--num-nodes=2 
--machine-type=n1-standard-2 
--disk-size=30 
--enable-autorepair 
--no-enable-cloud-logging 
--no-enable-cloud-monitoring 
--addons=HorizontalPodAutoscaling,Istio 
--istio-config=auth=MTLS_PERMISSIVE

上記のコマンドは、XNUMX つの VM を含むデフォルトのノード プールを作成します。 n1-standard-2 (vCPU: 2、RAM 7,5 GB、ディスク: 30 GB)。 理想的には、Istio コンポーネントをワークロードから分離する必要がありますが、専用のノード プールで Istio Pod を実行する簡単な方法はありません。 Istio マニフェストは読み取り専用とみなされ、GKE はノードへのリンクやポッドからの接続解除などの変更を元に戻します。

資格情報をセットアップする kubectl:

gcloud container clusters get-credentials istio

クラスター管理者の役割バインディングを作成します。

kubectl create clusterrolebinding "cluster-admin-$(whoami)" 
--clusterrole=cluster-admin 
--user="$(gcloud config get-value core/account)"

コマンドラインツールをインストールする ヘルメット:

brew install kubernetes-helm

Homebrew 2.0 は以下でも利用できるようになりました。 Linux.

Tiller のサービス アカウントとクラスター ロール バインディングを作成します。

kubectl -n kube-system create sa tiller && 
kubectl create clusterrolebinding tiller-cluster-rule 
--clusterrole=cluster-admin 
--serviceaccount=kube-system:tiller

名前空間で Tiller を展開します kube-system:

helm init --service-account tiller

Helm と Tiller の間で SSL の使用を検討する必要があります。 Helm インストールの保護の詳細については、次を参照してください。 docs.helm.sh

設定を確認します。

kubectl -n istio-system get svc

数秒後、GCP はサービスに外部 IP アドレスを割り当てます。 istio-ingressgateway.

Istio Ingress ゲートウェイの構成

名前を付けて静的 IP アドレスを作成する istio-gatewayIstio ゲートウェイの IP アドレスを使用します。

export GATEWAY_IP=$(kubectl -n istio-system get svc/istio-ingressgateway -ojson | jq -r .status.loadBalancer.ingress[0].ip)
gcloud compute addresses create istio-gateway --addresses ${GATEWAY_IP} --region us-central1

ここで、インターネット ドメインと DNS レジストラへのアクセスが必要になります。 XNUMX つの A レコードを追加します (置き換えます) example.com あなたのドメインに):

istio.example.com   A ${GATEWAY_IP}
*.istio.example.com A ${GATEWAY_IP}

DNS ワイルドカードが機能していることを確認します。

watch host test.istio.example.com

汎用 Istio ゲートウェイを作成して、HTTP 経由でサービス メッシュの外側にサービスを提供します。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"

上記のリソースを public-gateway.yaml として保存し、適用します。

kubectl apply -f ./public-gateway.yaml

運用システムは、SSL を使用せずにインターネット上でサービスを提供すべきではありません。 cert-manager、CloudDNS、Let's Encrypt を使用して Istio Ingress ゲートウェイを保護するには、以下をお読みください。 ドキュメンテーション フラガーG.K.E.

フラガーのインストール

GKE Istio アドオンには、Istio テレメトリ サービスをクリーンアップする Prometheus インスタンスは含まれていません。 Flagger は Istio HTTP メトリクスを使用してカナリア分析を実行するため、公式の Istio Helm スキーマに付属するものと同様の、次の Prometheus 構成をデプロイする必要があります。

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/gke/istio-prometheus.yaml

Flagger Helm リポジトリを追加します。

helm repo add flagger [https://flagger.app](https://flagger.app/)

Flager を名前空間に展開する istio-systemSlack 通知を有効にすることで:

helm upgrade -i flagger flagger/flagger 
--namespace=istio-system 
--set metricsServer=http://prometheus.istio-system:9090 
--set slack.url=https://hooks.slack.com/services/YOUR-WEBHOOK-ID 
--set slack.channel=general 
--set slack.user=flagger

Flagger は、ポート 9090 で Istio Prometheus サービスと通信できる限り、任意の名前空間にインストールできます。

Flagger には、カナリア分析用の Grafana ダッシュボードがあります。 Grafana を名前空間にインストールする istio-system:

helm upgrade -i flagger-grafana flagger/grafana 
--namespace=istio-system 
--set url=http://prometheus.istio-system:9090 
--set user=admin 
--set password=change-me

仮想サービス (置換) を作成して、オープン ゲートウェイ経由で Grafana を公開します。 example.com あなたのドメインに):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: grafana
  namespace: istio-system
spec:
  hosts:
    - "grafana.istio.example.com"
  gateways:
    - public-gateway.istio-system.svc.cluster.local
  http:
    - route:
        - destination:
            host: flagger-grafana

上記のリソースを grafana-virtual-service.yaml として保存し、適用します。

kubectl apply -f ./grafana-virtual-service.yaml

に移動するとき http://grafana.istio.example.com ブラウザでは、Grafana のログイン ページが表示されます。

Flagger を使用した Web アプリケーションのデプロイ

Flagger は Kubernetes をデプロイし、オプションで自動的にスケールアウト (HPA) し、一連のオブジェクト (Kubernetes デプロイメント、ClusterIP サービス、および Istio 仮想サービス) を作成します。 これらのオブジェクトはアプリケーションをサービス メッシュに公開し、カナリア分析と進行状況を制御します。

Istio Sidecar インジェクションを有効にしてテスト名前空間を作成します。

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml

デプロイメントとポッド自動スケールアウト ツールを作成します。

kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml
kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml

テスト ロード サービスをデプロイして、カナリア分析中にトラフィックを生成します。

helm upgrade -i flagger-loadtester flagger/loadtester 
--namepace=test

カスタム カナリア リソースを作成します (置き換えます) example.com あなたのドメインに):

apiVersion: flagger.app/v1alpha3
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: podinfo
  service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
  canaryAnalysis:
    interval: 30s
    threshold: 10
    maxWeight: 50
    stepWeight: 5
    metrics:
    - name: istio_requests_total
      threshold: 99
      interval: 30s
    - name: istio_request_duration_seconds_bucket
      threshold: 500
      interval: 30s
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo.test:9898/"

上記のリソースを podinfo-canary.yaml として保存し、適用します。

kubectl apply -f ./podinfo-canary.yaml

上記の分析が成功した場合、XNUMX 分間実行され、XNUMX 分ごとに HTTP メトリクスがチェックされます。 次の式を使用して、カナリア デプロイメントの検証とプロモートに必要な最小時間を決定できます。 interval * (maxWeight / stepWeight)。 Canary CRD フィールドが文書化されている ここで.

数秒後、Flagger は Canary オブジェクトを作成します。

# applied 
deployment.apps/podinfo
horizontalpodautoscaler.autoscaling/podinfo
canary.flagger.app/podinfo
# generated 
deployment.apps/podinfo-primary
horizontalpodautoscaler.autoscaling/podinfo-primary
service/podinfo
service/podinfo-canary
service/podinfo-primary
virtualservice.networking.istio.io/podinfo

ブラウザを開いて、次の場所に移動します app.istio.example.com、バージョン番号が表示されるはずです デモアプリ.

自動カナリア分析とプロモーション

Flagger は、HTTP リクエストの成功率、平均リクエスト期間、ポッドの健全性などの主要なパフォーマンス メトリクスを測定しながら、トラフィックを徐々にカナリアに移動する制御ループを実装します。 KPI分析に基づいてカナリアを昇格または中断し、分析結果をSlackに公開します。

カナリア デプロイメントは、次のオブジェクトのいずれかが変更されるとトリガーされます。

• PodSpec のデプロイ (コンテナー イメージ、コマンド、ポート、環境など)
• ConfigMap はボリュームとしてマウントされるか、環境変数にマップされます
• シークレットはボリュームとしてマウントされるか、環境変数に変換されます

コンテナ イメージを更新するときに Canary デプロイを実行します。

kubectl -n test set image deployment/podinfo 
podinfod=quay.io/stefanprodan/podinfo:1.4.1

Flagger は、デプロイメントのバージョンが変更されたことを検出し、解析を開始します。

kubectl -n test describe canary/podinfo

Events:

New revision detected podinfo.test
Scaling up podinfo.test
Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available
Advance podinfo.test canary weight 5
Advance podinfo.test canary weight 10
Advance podinfo.test canary weight 15
Advance podinfo.test canary weight 20
Advance podinfo.test canary weight 25
Advance podinfo.test canary weight 30
Advance podinfo.test canary weight 35
Advance podinfo.test canary weight 40
Advance podinfo.test canary weight 45
Advance podinfo.test canary weight 50
Copying podinfo.test template spec to podinfo-primary.test
Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
Promotion completed! Scaling down podinfo.test

分析中に、Grafana を使用してカナリアの結果を追跡できます。

カナリア分析中にデプロイメントに新しい変更が適用された場合、Flagger は分析フェーズを再開することに注意してください。

クラスター内のすべてのカナリアのリストを作成します。

watch kubectl get canaries --all-namespaces
NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
test        podinfo   Progressing   15       2019-01-16T14:05:07Z
prod        frontend  Succeeded     0        2019-01-15T16:15:07Z
prod        backend   Failed        0        2019-01-14T17:05:07Z

Slack 通知を有効にしている場合は、次のメッセージが表示されます。

自動ロールバック

カナリア分析中に、合成 HTTP 500 エラーと高い応答遅延を生成して、Flagger がデプロイメントを停止するかどうかを確認できます。

テスト ポッドを作成し、その中で次の操作を実行します。

kubectl -n test run tester 
--image=quay.io/stefanprodan/podinfo:1.2.1 
-- ./podinfo --port=9898
kubectl -n test exec -it tester-xx-xx sh

HTTP 500 エラーの生成:

watch curl http://podinfo-canary:9898/status/500

遅延生成:

watch curl http://podinfo-canary:9898/delay/1

失敗したチェックの数がしきい値に達すると、トラフィックはプライマリ チャネルにルーティングされ、カナリアはゼロにスケールされ、展開は失敗としてマークされます。

カナリア エラーとレイテンシのスパイクは Kubernetes イベントとして記録され、Flagger によって JSON 形式で記録されます。

kubectl -n istio-system logs deployment/flagger -f | jq .msg

Starting canary deployment for podinfo.test
Advance podinfo.test canary weight 5
Advance podinfo.test canary weight 10
Advance podinfo.test canary weight 15
Halt podinfo.test advancement success rate 69.17% < 99%
Halt podinfo.test advancement success rate 61.39% < 99%
Halt podinfo.test advancement success rate 55.06% < 99%
Halt podinfo.test advancement success rate 47.00% < 99%
Halt podinfo.test advancement success rate 37.00% < 99%
Halt podinfo.test advancement request duration 1.515s > 500ms
Halt podinfo.test advancement request duration 1.600s > 500ms
Halt podinfo.test advancement request duration 1.915s > 500ms
Halt podinfo.test advancement request duration 2.050s > 500ms
Halt podinfo.test advancement request duration 2.515s > 500ms
Rolling back podinfo.test failed checks threshold reached 10
Canary failed! Scaling down podinfo.test

Slack 通知を有効にしている場合は、期限を超過するか、分析で失敗したチェックの最大数に達すると、メッセージが届きます。

結論

Kubernetes に加えて Istio などのサービス メッシュを実行すると、自動メトリクス、ログ、プロトコルが提供されますが、ワークロードのデプロイメントは依然として外部ツールに依存します。 Flagger は、Istio 機能を追加することでこれを変えることを目指しています 漸進的な供給.

Flagger はあらゆる Kubernetes CI/CD ソリューションと互換性があり、カナリア分析は次の方法で簡単に拡張できます。 Webhook システム統合/受け入れテスト、負荷テスト、またはその他のカスタム チェックを実行します。 Flagger は宣言的であり、Kubernetes イベントに応答するため、GitOps パイプラインで次のように使用できます。 ウィーブフラックス または ジェンキンスX。 JenkinsX を使用している場合は、jx アドオンを使用して Flagger をインストールできます。

フラガーのサポート ウィーブワークス カナリア展開を提供します ウィーブクラウド。 プロジェクトは、GKE、EKS、kubeadm を使用したベアメタルでテストされています。

Flagger を改善するための提案がある場合は、GitHub で問題または PR を送信してください。 ステファンプロダン/フラガー。 貢献は大歓迎です!

感謝 レイ・ツァン.

出所： habr.com