🥇Kubernetes での Canary デプロイ #1: Gitlab CI

Gitlab CI と手動 GitOps を使用して、Kubernetes で Canary デプロイメントを実装および使用します。

このシリーズの記事:

（この記事）
ArgoCI を使用したカナリアデプロイメント
Istio を使用したカナリアデプロイメント
Jenkins-X Istio Flagger を使用したカナリアデプロイメント

Canary デプロイメントは GitOps 経由で手動で実行し、メインの Kubernetes リソースを作成/変更します。 この記事は主に紹介を目的としています Kubernetes Canary でのデプロイメントの仕組みについては、より効果的な自動化方法があるため、次の記事で検討します。

https://www.norberteder.com/canary-deployment/

カナリアの展開

Canary 戦略では、更新は最初に一部のユーザーのみに適用されます。リリースは、すべてのユーザーにリリースされる前に、モニタリング、ログデータ、手動テスト、またはその他のフィードバックチャネルを通じてテストされます。

Kubernetes デプロイ (ローリングアップデート)

Kubernetes デプロイメントのデフォルトの戦略はローリング更新であり、一定数のポッドが新しいバージョンのイメージで起動されます。問題なく作成された場合、古いバージョンのイメージを持つポッドは終了され、新しいポッドが並行して作成されます。

GitOps

この例では次の理由から GitOps を使用します。

Git を唯一の信頼できる情報源として使用する
ビルドとデプロイメントには Git Operations を使用します (git tag/merge 以外のコマンドは必要ありません)。

例

アプリケーションコード用に XNUMX つのリポジトリ、インフラストラクチャ用に XNUMX つのリポジトリを用意するという、良い習慣を取り入れてみましょう。

アプリケーションリポジトリ

これは、応答を JSON として返す、非常に単純な Python+Flask API です。 GitlabCI 経由でパッケージをビルドし、結果を Gitlab レジストリにプッシュします。レジストリには XNUMX つの異なるリリースバージョンがあります。

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

それらの唯一の違いは、返される JSON ファイルの変更です。このアプリケーションを使用して、通信しているバージョンをできるだけ簡単に視覚化します。

インフラストラクチャリポジトリ

このカブでは、GitlabCI 経由で Kubernetes にデプロイします。 .gitlab-ci.yml 次のようになります。

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

自分で実行するにはクラスターが必要です。Gcloud を使用できます。

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

フォークする必要があります https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure そして変数を作成します KUBECONFIG GitlabCI 内。これにはアクセス用の構成が含まれます kubectl クラスターに。

クラスターの認証情報を取得する方法 (Gcloud) について読むことができます。ここで.

インフラストラクチャ Yaml

インフラストラクチャリポジトリには次のサービスがあります。

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

そして、での展開 deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

そして別の展開 deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

app-deploy にはまだレプリカが定義されていないことに注意してください。

初期展開の実行

初期デプロイメントを開始するには、master ブランチで GitlabCI パイプラインを手動で開始します。その後 kubectl 次のように出力されるはずです:

私たちは見る app デプロイメントには 10 個のレプリカがあり、app-canary には 0 個のレプリカが含まれます。ロードバランサーもあり、そこからアクセスできます。 curl 外部 IP 経由:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

テストアプリケーションが「v1」のみを返すことがわかります。

Canary デプロイメントの実行

ステップ 1: 一部のユーザー向けに新しいバージョンをリリースする

deploy-canary.yaml ファイルと新しいバージョンイメージでレプリカの数を 1 に設定します。

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

ファイル内 deploy.yaml レプリカの数を 9 に変更しました。

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

これらの変更を、(GitlabCI 経由で) デプロイメントが開始されるリポジトリにプッシュし、結果を確認します。

両方にアプリセレクターがあるため、サービスは両方のデプロイメントを指します。 Kubernetes のデフォルトのランダム化により、リクエストの最大 10% に対して異なる応答が表示されるはずです。

私たちのアプリケーション (GitOps、単一の真実の情報源としての Git から取得) の現在の状態は、アクティブなレプリカを持つ XNUMX つのデプロイメント (バージョンごとに XNUMX つ) が存在します。

約 10% のユーザーが新しいバージョンに慣れ、意図せずテストしてしまいます。ここで、ログと監視データのエラーをチェックして問題を見つけます。

ステップ 2: 新しいバージョンをすべてのユーザーにリリースする

すべてがうまくいったと判断したので、今度は新しいバージョンをすべてのユーザーに展開する必要があります。これを行うには、単に更新するだけです deploy.yaml 新しいバージョンのイメージと 10 個のレプリカをインストールします。 deploy-canary.yaml レプリカの数を 0 に戻します。デプロイ後の結果は次のようになります。

要約

私にとって、この方法でデプロイメントを手動で実行すると、k8s を使用してデプロイメントをいかに簡単に構成できるかを理解するのに役立ちます。 Kubernetes では API 経由ですべてを更新できるため、これらの手順はスクリプトを通じて自動化できます。

もう XNUMX つ実装する必要があるのは、新しいバージョンのみにアクセスできるテスターエントリポイント (LoadBalancer または Ingress 経由) です。手動での閲覧に使用できます。

今後の記事では、これまでに行ったことのほとんどを実装する他の自動化ソリューションを確認していきます。

私たちのブログの他の記事もお読みください。

出所： habr.com

Kubernetes での Canary デプロイ #1: Gitlab CI