ARGO CDとistioによるカナリア配備

Argo CDの第2今回は、私たちがカナリア展開を扱うためにどのようにistioでそれを使うことができるかを見るつもりです.
カナリア展開は、サーバーの小さなサブセットにのみアプリケーションの新しいバージョンを展開する方法です.エラーが新しいリリースで導入されるならば、それはユーザーの小さな部分だけに影響を及ぼします.このタイプの配備は、すべてのトラフィックがそれに送られるまで、Canaryリリースにより多くのトラフィックを送る複数のステップで構成されるほとんどの時間であり、安定版になります.各ステップの間に、我々はすべてが確かであることを確認するいくつかのテストをすることができます.エラーがテストによって検出されるならば、我々は前の働くバージョンに戻ります.つまり、すべてのユーザーに影響を与えることなく新しいバージョンを検証することが可能です.
このデモでは、Argo CDが提供するアプリケーションを配備します.このアプリケーションとコードhereについての詳細情報です.
それは私たちのデモに最適です.これは、複数の投稿要求ごとに2番目のWeb UIを提供します.各ポストリクエストはバブルで表されます.この例では、アプリケーションをBlueバージョンで展開し、Canary展開を使用してオレンジバージョンで更新します.下の写真では、現在のバージョン(青)と新しいカナリアリリース(オレンジ)の間でトラフィックがどのようにルーティングされているかを確認します.

要件

Kubernetesクラスタ

デモでgkeを使います.Google Cloudアカウントをお持ちの場合は、以下のコマンドでクラスタを作成できます.クラスタが既にある場合は、次のステップに進むことができます.

gcloud beta container clusters create gke-argocd-canary \
  --release-channel regular 

イシス

Istioをistioctlでインストールできます.

istioctl install --set profile=demo
kubectl label namespace default istio-injection=enabled

アルゴCD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

アルゴCD

Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.
https://argoproj.github.io/argo-cd/

Kubernetesでは、アプリケーションを管理するための配備リソースを使用します.Argo CD Rootoutでは、展開を使用しないで、ロールアウトリソースに置き換えられます.展開のように、Argo CDはReplicasetを作成して、ポッドを特定するためにサービスにいくつかのラベルを加えるでしょう.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

準備する

まず,ゲートウェイと仮想サービスをistio資源を生成しなければならない.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-gateway
  labels:
    app: istio-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istio-vs
  labels:
    app: istio-vs
spec:
  hosts:
  - "*"
  gateways:
  - istio-gateway
  http:
    - name: primary
      route:
        - destination:
            host: demo
          weight: 100
        - destination:
            host: demo-canary
          weight: 0

今から、トラフィックの100 %がメインサービス(ここでデモと呼ばれる)に行きます.その後、ARGO CDがこれらの値を変更してカナリアサービスでいくつかのトラフィックを送信することがわかります.

ロールアウトリソースの作成

ロールアウトリソースはいくつかの新しいフィールドを持つKubernetesの展開のようです.
彼らに集中しましょう

  strategy:
    # which strategy to use (blueGreen, canary..)
    canary:
    # this part represents all the steps during an update.
      steps:
    # we send at the beginning of the new release 20% of the traffic to the canary release.
    # To do that, Argo CD will update the weight of Istio's VirtualService.
      - setWeight: 20
    # Then we wait 1min to generate some traffic on the canary release.
      - pause:
          duration: "1m"
    # After 1 min, we send 50% of the traffic to the canary release.
      - setWeight: 50
    # Then we wait again 2min
      - pause:
          duration: "2m"
    # At the end if no more step is present, 
    # Argo will send 100% of the traffic to the canary release.
      canaryService: demo-canary # represents our canary clusterIP service.
      stableService: demo # represents our main clusterIP service.
      trafficRouting:
        istio:
           virtualService: 
            name: istio-vs
            routes:
            - primary 

我々のロールアウトリソースの完全なYAMLは、clusteripサービスを備えています.

---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo
  labels:
    app: demo
spec:
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause:
          duration: "1m"
      - setWeight: 50
      - pause:
          duration: "2m"
      canaryService: demo-canary
      stableService: demo
      trafficRouting:
        istio:
           virtualService: 
            name: istio-vs
            routes:
            - primary 
  replicas: 4
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: demo
      version: blue
  template:
    metadata:
      labels:
        app: demo
        version: blue
    spec:
      containers:
      - name: demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - name: web
          containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "140m"
---
apiVersion: v1
kind: Service
metadata:
  name: demo
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: demo
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  name: demo-canary
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: demo
  type: ClusterIP

アプリケーションの配備

ARGO CDにアプリケーションを配備する2つの必須ファイルがあります.これをしましょう、あなたのArgo CDに接続して、アプリケーションを配備してください.
リトル・リマインダー

ALGO CDのパスワードを取得します.

kubectl get pods \
  -n argocd \
  -l app.kubernetes.io/name=argocd-server \
  -o "jsonpath={.items[0].metadata.name}"

その後、

でポートフォワーディングを使います.

kubectl port-forward svc/argocd-server -n argocd 8080:443

Argo CDでアプリケーションを作成するときに追加する情報



展開されると、アプリケーションにアクセスできます.istioで使用されるロードバランサIPが必要です.

kubectl -n istio-system get services istio-ingressgateway \
  -o "jsonpath={.status.loadBalancer.ingress[0].ip}"

ブラウザからこのIPアドレスにアクセスしてください.

覚えて、各バブルは、ポストバランサーIPに行わポストリクエストを表します.
前進する前に、新しいKubectlコマンドを見ましょう.kubectl argo rollouts get rollout demoはあなたのロールアウトの状態を見るのに便利です.カナリア展開中に、すべての手順が表示されます.

新しいリリースを展開します。

OK、青い泡は素晴らしいですが、我々はオレンジ色のものを試してみたい.つのオプションは、私たちのロールアウトのイメージを変更するには、最初の1つの更新をコミットされ、2番目は、Kubectl CLIを使用しています.2番目のオプションを使います.kubectl set imageのようにロールアウトと等価です.

kubectl argo rollouts set image demo "*=argoproj/rollouts-demo:orange"

次のようにしてください.

Canary展開の進捗状況と現在のステップを見ることができます.

ブラウザからアプリケーションに戻ると、次のようになります.

数分後、トラフィックの50 %は、2つのバージョン間で分割されます.
それが完了したら、再度表示をあなたのロールアウトの状態を得ることができます.ロールアウトは健康であり、安定したオレンジタグを持っている必要があります.

ロールアウト概要:

ロールアウトリソースは、アルゴCD

のプラグインです

ロールアウトリソースだけでなく、展開

を作成します

カナリーやブルーグリーンの戦略

を使用できます

あなたはサポートされた侵入を必要とします.

ARGO CD自体はISIVER仮想サービス

のサービスの重みを更新する

検証

新しいバージョンで問題がないことを保証するためにカナリア展開中にいくつかのテストを追加できます.プロメテウスの問い合わせのような複雑なコマンドやコマンドを実行するような簡単なテストである.それが我々のやりようだ.
私たちのYAMLファイルに戻ってください.

---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    successCondition: result[0] >= 0.95
    interval: 30s
    failureLimit: 1
    provider:
      prometheus:
        address: http://prometheus.istio-system.svc.cluster.local:9090
        query: |
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[1m]
          )) / 
          sum(irate(
            istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[1m]
          ))

このテストでは,istioによってインストールされたprometheusを問い合わせる.
我々は、最後の分でエラーのHTTP要求の割合をチェックするためにカナリア展開中に30秒ごとにPromeTheusを問い合わせたい.結果が5 %(結果[ 0 ]>= 0.95以上)の場合、テストは失敗したとみなされます.
それで、5分の配備のために、複数のテストは動きます.失敗した場合は、配置を停止し、以前の健康バージョンにロールバックします.
私たちのテストは準備ができて、我々のワークフローに追加する必要があります.ロールアウトYAMLでは、新しいものを見ましょう.

---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo
  labels:
    app: demo
spec:
  strategy:
    canary:
      # New part
      analysis:
        templates:
        # name of AnalysisTemplate
        - templateName: success-rate
        # When it begins (after the 1-minute pause)
        startingStep: 2
        args:
        - name: service-name
          # name of the canary service (used in prometheus to find the correct metrics)
          value: demo-canary.default.svc.cluster.local
      steps:
      - setWeight: 20
      - pause:
          duration: "1m"
      - setWeight: 50
      - pause:
          duration: "2m"
      canaryService: demo-canary
      stableService: demo
      [....]

テストは1分の一時停止後30秒ごとに実行されます.我々は、いくつかのトラフィックを生成する必要があるので、一時停止後に起動します.
試してみましょう!私たちはイメージの新しいタグを展開する必要があります.悪いトラフィックを生成する2つの可能性.我々は直接アプリケーションを展開して使用することができますし、バーとエラーの数を選択するだけで“悪い”バージョンを展開.
悪いバージョンを展開します.

kubectl argo rollouts set image demo "*=argoproj/rollouts-demo:bad-green"

二つの新しいタイプの泡が見えます.

Green =はHTTPリクエスト

を継承しました
黒い円=エラーHTTP要求による

緑
ロールアウトについて説明してみましょう.

テストは2回失敗し、ロールアウトの状態は悪化します.Argo CDは以前の健康版にロールバックしましたが、劣化した状態を保ちます.健康状態で戻るには、手動で正しいイメージにバージョンを変更する必要があります.
失敗したテストの詳細については、次のように実行します.

$ kubectl get analysisrun
NAME                STATUS
demo-588d8b6cb4-9   Failed

成功したHTTPリクエストの77 %、87 %しかなかった.それは十分ではなかった、少なくとも95 %が欲しかった.
妥当性検査の概要

分析テンプレートは

のテストに使用されます

は、分析テンプレートを複数のロールアウトにリンクできます

では、複数の解析テンプレートをロールアウト

で別のステップから開始することができます
ここの完全なコード:https://github.com/pabardina/argocd-canary