Kubernetes での Canary デプロイ #3: Istio

Istio+Kiali を使用して Canary デプロイメントを起動および視覚化する

このシリーズの記事

1. Kubernetes での Canary デプロイ #1: Gitlab CI
2. Kubernetes での Canary デプロイメント #2: Argo ロールアウト
3. （この記事）
4. Jenkins-X Istio Flagger を使用したカナリア デプロイメント

カナリアの展開

ぜひお読みください 最初の部分ここでは、Canary デプロイメントとは何かを簡単に説明し、標準の Kubernetes リソースを使用してカナリア デプロイメントを実装する方法を示しました。

イスティオ

この記事を読んでいるということは、Istio が何であるかをすでに理解していることを前提としています。 そうでない場合は、それについて読むことができます ここで.

試験のお申込み

各ポッドには、アプリケーションと istio-proxy の XNUMX つのコンテナーが含まれています。

フロントエンド nginx ポッドとバックエンド Python ポッドを備えた単純なテスト アプリケーションを使用します。 nginx ポッドは、各リクエストをバックエンド ポッドにリダイレクトするだけで、プロキシとして機能します。 詳細は次の yaml で確認できます。

• フロントエンド.yaml
• バックエンド.yaml
• istio.yaml

テスト アプリケーションを自分で実行する

私の例に従ってこのテスト アプリケーションを自分で使用したい場合は、次を参照してください。 プロジェクトのReadme.

初期展開

最初のデプロイメントを起動すると、アプリケーションのポッドには 2 つのコンテナーしかないことがわかります。つまり、Istio サイドカーが実装されたばかりです。

また、名前空間には Istio Gateway Loadbalancer も表示されます。 istio-system:

トラフィックの生成

次の IP を使用して、フロントエンド ポッドによって受信され、バックエンド ポッドに転送されるトラフィックを生成します。

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

も追加させていただきます frontend.istio-test ホストファイルに。

Kiali 経由でメッシュを表示

テスト アプリケーションと Istio を、Tracing、Grafana、Prometheus、Kiali とともにインストールしました (詳細は以下を参照)。 プロジェクトのReadme）。 したがって、次の方法で Kiali を使用できます。

istioctl dashboard kiali # admin:admin

Kiali はメッシュを通じて現在のトラフィックを視覚化します

ご覧のとおり、トラフィックの 100% がフロントエンド サービスに送られ、次にラベル v1 のフロントエンド ポッドに送られます。これは、リクエストをバックエンド サービスにリダイレクトする単純な nginx プロキシを使用しているためです。バックエンド サービスはリクエストをバックエンド ポッドにリダイレクトします。ラベル v1 付き。

Kiali は Istio とうまく連携し、ボックス化されたメッシュ レンダリング ソリューションを提供します。 ただ素晴らしい。

カナリアの展開

私たちのバックエンドにはすでに 8 つの k1s デプロイメントがあり、2 つは v2 用、もう XNUMX つは vXNUMX 用です。 ここで必要なのは、リクエストの一定の割合を vXNUMX に転送するように Istio に指示することだけです。

ステップ 1: 10%

そして、私たちがしなければならないのは、VirtualService の重みを調整することだけです。 istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

リクエストの 10% が v2 にリダイレクトされていることがわかります。

ステップ 2: 50%

そして今はそれを 50% に増やすだけで十分です。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

ステップ 3: 100%

これで、カナリア デプロイメントが完了したと見なされ、すべてのトラフィックが v2 にリダイレクトされます。

Canary を手動でテストする

すべてのリクエストの 2% を v10 バックエンドに送信するとします。 v2 を手動でテストして、すべてが期待どおりに動作することを確認したい場合はどうすればよいでしょうか?

HTTP ヘッダーに基づいて特別な一致ルールを追加できます。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

ここで、curl を使用して、ヘッダーを送信することで v2 リクエストを強制できます。

ヘッダーのないリクエストは、引き続き 1/10 の比率によって駆動されます。

XNUMX つの依存バージョンのカナリア

次に、フロントエンドとバックエンドの両方にバージョン v2 があるオプションを検討します。 どちらの場合も、トラフィックの 10% が v2 に送信されるように指定しました。

フロントエンド v1 と v2 は両方とも、バックエンド v1 と v10 に対して 1/2 の比率でトラフィックを転送していることがわかります。

v2 と互換性がないため、frontend-v2 からのトラフィックを backend-v1 にのみ転送する必要がある場合はどうすればよいでしょうか? これを行うには、フロントエンドに 1/10 の比率を設定し、ネゴシエーションを使用してバックエンド v2 に送信されるトラフィックを制御します。 sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

その結果、必要なものが得られます。

手動の Canary アプローチとの違い

В 最初の部分 また、8 つの kXNUMXs デプロイメントを使用して、Canary デプロイメントを手動で実行しました。 そこでは、レプリカの数を変更することでリクエストの比率を制御しました。 このアプローチは機能しますが、重大な欠点があります。

Istio を使用すると、レプリカの数に関係なくリクエストの割合を決定できます。 これは、たとえば、HPA (水平ポッド オートスケーラー) を使用でき、カナリア デプロイメントの現在の状態に従って構成する必要がないことを意味します。

合計

Istio は非常にうまく機能し、Kiali と併用すると非常に強力な組み合わせになります。 私の興味リストの次は、Spinnaker と Istio を組み合わせて自動化とカナリア分析を行うことです。

出所： habr.com