Flux+Flagger+Istio+Kubernetes を使用して GitOps クラウドネイティブプログレッシブ (カナリア) 配信を実装する

[[403388]]

このガイドでは、Kubernetes と Istio を使用したプログレッシブ配信のための GitOps の使用について実践的な経験を積むことができます。

導入

デモ: https://github.com/stefanprodan/gitops-istio

GitOps とは何ですか?

GitOps は、宣言型インフラストラクチャとワークロードの信頼できるソースとして Git を使用する継続的デリバリーのアプローチです。 Kubernetes の場合、これは kubectl apply/delete または helm install/upgrade の代わりに git push を使用することを意味します。

このワークショップでは、GitHub を使用して構成リポジトリをホストし、Flux を GitOps 配信ソリューションとして使用します。

プログレッシブデリバリーとは何ですか?

プログレッシブ配信は、カナリア、機能フラグ、A/B テストなどの高度なデプロイメントパターンの総称です。プログレッシブデリバリー技術は、アプリケーション開発者と SRE チームに影響範囲を細かく制御できるようにすることで、新しいソフトウェアバージョンを本番環境に導入するリスクを軽減します。

このワークショップでは、Flagger と Prometheus を使用して、アプリケーションのカナリアリリースと A/B テストを自動化します。

準備

LoadBalancer をサポートする Kubernetes クラスター v1.16 以上が必要になります。テスト目的では、2 つの CPU と 4 GB のメモリを搭載した Minikube を使用できます。

Homebrew を使用して flux CLI をインストールします。

 brew をインストールして fluxcd/tap/flux

macOS AMD64/ARM64、Linux AMD64/ARM、Windows 用のバイナリは、flux2 リリースページからダウンロードできます。

クラスターが前提条件を満たしていることを確認します。

フラックスチェック  --前

Homebrew を使用して jq と yq をインストールします。

 brew インストール jq yq

このリポジトリをフォークしてクローンします:

 git clone https://github.com/<ユーザー名>/gitops-istio
 cd gitops-istio

クラスターブートストラップ

flux ブートストラップコマンドを使用すると、Kubernetes クラスターに Flux をインストールし、Git リポジトリから自身を管理するように構成できます。クラスターに Flux コンポーネントが存在する場合、ブートストラップコマンドは必要に応じてアップグレードを実行します。

GitHub リポジトリのフォーク URL を指定して Flux をブートストラップします。

フラックスブートストラップgit \
 --author-email=<あなたのメールアドレス> \  
 --url=ssh://[email protected]/<ユーザー名>/gitops-istio \  
 --branch=メイン\  
 --path=クラスタ/my-cluster

上記のコマンドには ssh-agent が必要です。Windows を使用している場合は、flux bootstrap github ドキュメントを参照してください。

起動時に、Flux は SSH キーを生成し、公開キーを出力します。クラスターの状態を git と同期するには、公開キーをコピーし、write を使用して GitHub リポジトリにアクセスするためのデプロイキーを作成する必要があります。 GitHub で、[設定] > [デプロイキー] に移動し、[デプロイキーの追加] をクリックして、☑️ [書き込みアクセスを許可する] をオンにし、Flux 公開キーを貼り付けて、[キーの追加] をクリックします。

Flux がリポジトリにアクセスすると、次の処理が行われます。

Istioオペレーターのインストール
Istioコントロールプレーンの準備が整うのを待っています
Flagger、Prometheus、Grafanaをインストールする
Istioパブリックゲートウェイを作成する
prod名前空間を作成する
負荷テスターのデプロイメントを作成する
フロントエンドのデプロイメントとカナリアを作成する
バックエンドのデプロイメントとカナリアを作成する

Istio を使用してクラスターをブートストラップする場合、適用順序を定義することが重要です。アプリケーションポッドが Istio サイドカーインジェクションを使用するには、アプリケーションの前に Istio コントロールプレーンが起動して実行されている必要があります。

Flux v2 では、オブジェクト間の依存関係を定義することで実行順序を指定できます。たとえば、clusters/my-cluster/apps.yaml では、アプリの調整が istio システムに依存することを Flux に伝えます。

 apiバージョン: kustomize.toolkit.fluxcd.io/v1beta1
種類: カスタマイズ
メタデータ:
名前: アプリ
  名前空間: flux-system
仕様:
  間隔: 30分0秒
  依存:
    -名前: istio-system
  ソース参照:
    種類: Gitリポジトリ
名前: フラックスシステム
  パス: ./apps

まず Flux を観察して Istio をインストールし、次にデモアプリを観察します。

ウォッチフラックスがカスタマイズを取得

次のコマンドを使用して、Flux 調整ログを tail できます。

フラックスログ--all-namespaces --follow --tail=10

Istio のカスタマイズとアップグレード

istio/system/profile.yaml にある IstioOperator リソースを使用して、Istio インストールをカスタマイズできます。

 apiバージョン: install.istio.io/v1alpha1
種類: IstioOperator
メタデータ:
名前: istio-デフォルト 
  名前空間: istio-system
仕様:
  プロフィール: デモ
  コンポーネント:
    パイロット：
      k8s:
        リソース：
          リクエスト:
            CPU: 10m
            メモリ: 100Mi

Istio 設定を変更した後、変更を git にプッシュすると、Flux によってクラスターに適用されます。 Istio オペレーターは、変更に応じて Istio コントロールプレーンを再構成します。

新しい Istio バージョンが利用可能になると、update-istio GitHub Action ワークフローは、Istio Operator のアップグレードに必要なマニフェスト更新を含むプルリクエストを開きます。新しい Istio バージョンは、e2e ワークフローを通じて Kubernetes Kind でテストされます。 PR がマスターブランチにマージされると、Flux はクラスター内の Istio をアップグレードします。

アプリケーションのブートストラップ

Flux が Git リポジトリをクラスターと同期すると、フロントエンド/バックエンドのデプロイメント、HPA、およびカナリアオブジェクトが作成されます。 Flagger は、カナリア定義を使用して、Kubernetes デプロイメント、ClusterIP サービス、Istio 宛先ルール、仮想サービスなどの一連のオブジェクトを作成します。これらのオブジェクトはメッシュ上のアプリケーションを公開し、カナリア分析とプロモーションを容易にします。

 # Fluxによって適用
デプロイメント.apps/フロントエンド
水平ポッドオートスケーラー.自動スケーリング/フロントエンド
canary.flagger.app/フロントエンド
 
 #フラガーによって生成されました
デプロイメント.apps/フロントエンド -プライマリ 
水平ポッドオートスケーラー.自動スケーリング/フロントエンド-プライマリ 
サービス/フロントエンド
サービス/フロントエンドカナリア
サービス/フロントエンド -プライマリ 
 destinationrule.networking.istio.io/frontend-canary
 destinationrule.networking.istio.io/frontend-primary  
 virtualservice.networking.istio.io/frontend

Flagger がカナリアを正常に初期化したかどうかを確認します。

 kubectl -n prod カナリアを取得する
 
名前ステータス 体重
バックエンド初期化0
フロントエンド初期化0

フロントエンドプライマリデプロイメントが稼働すると、Flagger はすべてのトラフィックをプライマリポッドにルーティングし、フロントエンドデプロイメントをゼロにスケーリングします。

Istio Ingress ゲートウェイアドレスを見つけるには、次のコマンドを使用します。

 kubectl -n istio-system で svc istio-ingressgateway -ojson を取得します | jq .status.loadBalancer.ingress

ブラウザを開いてエントリアドレスに移動すると、フロントエンド UI が表示されます。

カナリアリリース

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

カナリア分析は、次のいずれかのオブジェクトが変更されるとトリガーされます。

PodSpec をデプロイする (コンテナイメージ、コマンド、ポート、環境など)

ConfigMaps と Secrets はボリュームとしてマウントされるか、環境変数にマップされます

一定のトラフィックを受信しないワークロードの場合、Flagger は、呼び出されるとターゲットワークロードの負荷テストを開始する Webhook で構成できます。カナリア設定は、apps/backend/canary.yaml にあります。

GitHub から変更をプルします:

 git プルオリジンメイン

バックエンドアプリケーションのカナリアデプロイメントをトリガーするには、コンテナイメージをアップグレードします。

 '.images[0].newTag="5.0.1"' -i ./apps/backend/kustomization.yaml を追加します

変更をコミットしてプッシュします。

 gitを追加-A && \
 git commit -m "バックエンド 5.0.1" && \
 git プッシュ origin メイン

Flux に変更をプルするように指示するか、Flux が独自に変更を検出するまで 1 分ほど待ちます。

 flux 調整ソース git flux-system

Flux を監視して、クラスターを最新のコミットと調整します。

ウォッチフラックスがカスタマイズを取得

数秒後、Flager はデプロイメントリビジョンが変更されたことを検出し、新しいロールアウトを開始します。

 $ kubectl -n prod カナリアバックエンドを記述します
 
イベント: 
 
新しいリビジョンが検出されました! backend.prod のスケールアップ
backend.prodのカナリア分析を開始します
ロールアウト前の適合性チェックテストに合格
backend.prod カナリアウェイト 5 を進める
...
 backend.prod カナリアウェイト 50 を進める
backend.prod テンプレート仕様をbackend- primary .prodにコピーしています
プロモーション完了！ backend.prod のスケールダウン

分析中、Grafana はカナリアの進行状況を監視できます。ポート転送を介してダッシュボードにアクセスできます。

 kubectl -n istio-system port- forward svc/flagger-grafana 3000:80

IstioダッシュボードのURLはhttp://localhost:3000/d/flagger-istio/istio-canary?refresh=10s&orgId=1&var-namespace=prod&var-primary=backend-primary&var-canary=backendです。

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

A/Bテスト

重み付けルーティングに加えて、Flagger は HTTP 一致条件に基づいてトラフィックをカナリアにルーティングするように構成することもできます。 A/B テストのシナリオでは、HTTP ヘッダーまたは Cookie を使用して、ユーザーの特定のセグメントをターゲットにします。これは、セッションアフィニティを必要とするフロントエンドアプリケーションに特に役立ちます。

HTTP 一致条件と反復回数を指定して、A/B テストを有効にすることができます。

分析：
  # スケジュール間隔 (デフォルト60 秒)
  間隔: 10秒
  #ロールバック前の失敗したメトリックチェックの最大数 
  閾値: 10
  #反復回数の合計
  繰り返し回数: 12
  # カナリアマッチ条件
  マッチ：
    - ヘッダー:
ユーザーエージェント:
          正規表現: 「.*Firefox.*」  
    - ヘッダー:
        クッキー:
          正規表現: "^(.*?;)?(type=insider)(;.*)?$"

上記の設定では、Firefox ユーザーと内部 Cookie を持つユーザーに対して 2 分間の分析が実行されます。フロントエンドの構成は、apps/frontend/canary.yaml にあります。

フロントエンドコンテナイメージを更新してデプロイをトリガーします。

 '.images[0].newTag="5.0.1"' -i ./apps/frontend/kustomization.yaml を追加します
 
 gitを追加-A && \
 gitコミット-m "フロントエンド 5.0.1" && \
 git プッシュ origin メイン
 
 flux 調整ソース git flux-system

Flagger はデプロイメントリビジョンが変更されたことを検出し、A/B テストを開始します。

 $ kubectl -n istio-system logsdeploy/flagger -f | jq .msg 
 
新しいリビジョンが検出されました! frontend.prod のスケールアップ
frontend.prod のロールアウトが完了するのを待機しています:更新されたレプリカ 1 個のうち0 個が利用可能です
ロールアウト前の適合性チェックテストに合格
frontend.prod カナリア反復を進める 1/10
 ...
高度な frontend.prod カナリア反復 10/10
 frontend.prod テンプレート仕様をfrontend- primary .prodにコピーしています
フロントエンド -プライマリ.prod ロールアウトの完了を待機中:更新されたレプリカ 2 個のうち1 個が利用可能です
プロモーション完了！ frontend.prod のスケールダウン

すべてのカナリアを次の方法で監視できます。

 $ kubectl get canaries --all-namespacesを監視します  
 
名前空間名ステータス 重み
prod フロントエンド 進捗状況 100
 prodバックエンド成功0

Istio メトリックに基づくロールバック

Flagger は、Istio テレメトリによって提供されるメトリックを使用して、カナリアワークロードを検証します。フロントエンドアプリケーション分析では、次の 2 つのインジケーターチェックが定義されます。

メトリクス:
   -名前: エラー率
     テンプレート参照:
名前: エラー率
       名前空間: istio-system
     しきい値範囲:
最大: 1
     間隔: 30秒
   -名前: レイテンシー
     テンプレート参照:
名前: レイテンシー
       名前空間: istio-system
     しきい値範囲:
最大: 500
     間隔: 30秒

エラー率とレイテンシをチェックするための Prometheus クエリは flagger-metrics.yaml にあります。

カナリア分析中に、HTTP 500 エラーと高レイテンシを生成して、Flagger ロールバックをテストできます。

HTTP 500 エラーを生成します:

 curl -b 'type=insider' http://<INGRESS-IP>/status/500 を確認します。

遅延を生成:

 curl -b 'type=insider' http://<INGRESS-IP>/delay/1 を確認します。

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

 $ kubectl -n istio-system logsdeploy/flagger -f | jq .msg 
 
新しいリビジョンが検出されました! frontend.prod のスケールアップ
ロールアウト前の適合性チェックテストに合格
frontend.prod カナリア反復を進める 1/10
 frontend.prod の進捗を停止 エラー率 31 > 1
 frontend.prod の進行遅延 2000 > 500 を停止
...
 frontend.prod のロールバック失敗チェックしきい値が 10 に達しました
カナリアは失敗しました！ frontend.prod のスケールダウン