Container Service for Kubernetes:ALB イングレスを用いた ACK クラスター内でのカナリアリリースの実行

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

• 異なるゾーンにある 2 つの vSwitch を、ACK クラスターと同じ仮想プライベートクラウド (VPC) にデプロイします。詳細については、「vSwitch の作成と管理」をご参照ください。

• クラスターにインストールされている ALB イングレスコントローラーです。詳細については、「ALB イングレスコントローラーの管理」をご参照ください。

  ACK 専用クラスターで ALB イングレスを使用するには、まずクラスターに必要な権限を付与します。詳細については、「ACK 専用クラスターに ALB イングレスコントローラへのアクセスを許可する」をご参照ください。

• AlbConfig が作成されました。詳細については、「AlbConfig の作成」をご参照ください。

• kubectl を ACK クラスターに接続しておきます。詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。

カナリアアノテーション

すべてのカナリア Ingress には、alb.ingress.kubernetes.io/canary: "true" アノテーションが必要です。このアノテーションがない場合、カナリア Ingress は本番 Ingress と競合し、並列してルーティングされません。

以下のアノテーションにより、トラフィックの分割方法を制御できます。

ルールの優先順位：複数のカナリアルールが有効な場合、評価順序は以下のとおりです：ヘッダーに基づくルール ＞ Cookie に基づくルール ＞ 重みに基づくルール。

注意事項

• 同一の Ingress で、ヘッダーおよび Cookie に基づくルールと重みに基づくルールを併用することはできません。それぞれを別々の Ingress で構成するか、より複雑な条件を実現する場合は、「カスタムルーティングルール」をご利用ください。

• カナリア Ingress の host は、本番 Ingress の host と完全に一致させる必要があります。

• alb.ingress.kubernetes.io/order を使用して、複数のカナリー Ingress が同じホストを共有する場合に明示的な優先度を設定します。これは、辞書式順序付けに依存する代わりの方法です。

ステップ 1：本番サービスのデプロイ

本番バージョン向けに Deployment、Service、および Ingress をデプロイします。

1. 以下の内容で tea-deploy.yaml を作成し、適用します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: tea
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: tea
     template:
       metadata:
         labels:
           app: tea
       spec:
         containers:
         - name: tea
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx:latest
           ports:
           - containerPort: 80

   kubectl apply -f tea-deploy.yaml

2. 以下の内容で tea-svc.yaml を作成し、適用します。

   apiVersion: v1
   kind: Service
   metadata:
     name: tea-svc
   spec:
     ports:
     - port: 80
       targetPort: 80
       protocol: TCP
     selector:
       app: tea
     type: NodePort

   kubectl apply -f tea-svc.yaml

3. 以下の内容で tea-ingress.yaml を作成し、適用します。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tea-ingress
   spec:
     ingressClassName: alb
     rules:
      - host: demo.domain.ingress.top  # ロードバランサーの IP アドレスに解決される、ご自身のドメイン名に置き換えてください。
        http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: tea-svc
               port:
                 number: 80

   kubectl apply -f tea-ingress.yaml

ステップ 2：カナリアサービスおよびルーティングルールのデプロイ

新しいサービスバージョンをデプロイし、同時に 2 つのカナリア Ingress をデプロイします。1 つは特定のヘッダーを持つリクエストをカナリアにルーティングし、もう 1 つは残りのトラフィックを重みで分割します。

カナリア Ingress を適用する前に、以下の要件を確認してください。

• すべてのカナリア Ingress に alb.ingress.kubernetes.io/canary: "true" を設定してください。このアノテーションがない場合、カナリア Ingress は本番 Ingress と競合します。

• host フィールドは、本番 Ingress のホストと完全に一致させる必要があります（本例では demo.domain.ingress.top）。

• ヘッダーに基づくルールと重みに基づくルールは、別々の Ingress に設定する必要があります。

1. 以下の内容で canary-deploy.yaml を作成し、適用します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: canary
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: canary
     template:
       metadata:
         labels:
           app: canary
       spec:
         containers:
         - name: canary
           image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx:latest
           ports:
           - containerPort: 80

   kubectl apply -f canary-deploy.yaml

2. 以下の内容で canary-svc.yaml を作成し、適用します。

   apiVersion: v1
   kind: Service
   metadata:
     name: canary-svc
   spec:
     ports:
     - port: 80
       targetPort: 80
       protocol: TCP
     selector:
       app: canary
     type: NodePort

   kubectl apply -f canary-svc.yaml

3. ヘッダーに基づくカナリア Ingress を作成します。すべての location: hz を含むリクエストは canary-svc にルーティングされます。他のヘッダーを含むリクエストは、次のマッチングルールに継承されます。以下の内容で canary-header-ingress.yaml を作成し、適用します。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/canary: "true"
       alb.ingress.kubernetes.io/canary-weight: "50"
     name: canary-weight-ingress
     namespace: default
   spec:
     ingressClassName: alb
     rules:
       - host: demo.domain.ingress.top  # 本番 Ingress のホストと完全に一致させる必要があります。
         http:
           paths:
             - backend:
                 service:
                   name: canary-svc
                   port:
                     number: 80
               path: /
               pathType: Prefix

   kubectl apply -f canary-header-ingress.yaml

4. 重みに基づくカナリア Ingress を作成します。ヘッダールールに一致しないリクエストは、本番サービスとカナリアサービスの間で 50:50 で分割されます。以下の内容で canary-weight-ingress.yaml を作成し、適用します。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/canary: "true"
       alb.ingress.kubernetes.io/canary-weight: "50"
     name: canary-weight-ingress
     namespace: default
   spec:
     ingressClassName: alb
     rules:
       - host: demo.domain.ingress.top  # 本番 Ingress のホストと完全に一致させる必要があります。
         http:
           paths:
             - backend:
                 service:
                   name: canary-svc
                   port:
                     number: 80
               path: /
               pathType: Prefix

   kubectl apply -f canary-weight-ingress.yaml

カナリアリリースの検証

1. ALB インスタンスのアドレスを取得します。

   kubectl get ing

   期待される出力：

   NAME                    CLASS   HOSTS                     ADDRESS                                              PORTS   AGE
   canary-header-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m23s
   canary-weight-ingress   alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      8m16s
   tea-ingress             alb     demo.domain.ingress.top   alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com   80      7m5s

2. location: hz を含むリクエストが常にカナリアに到達することを検証します。

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" -H "location:hz" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   すべての 10 回の応答で new が返されます。ヘッダールールは最も高い優先度を持ち、一致するリクエストを 100 % カナリアにルーティングします。

3. ヘッダーに一致しないリクエストが約 50:50 で分割されることを検証します。

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   応答は new（カナリア）と old（本番）を交互に返し、おおよそ半分ずつになります。一致しないヘッダー（例：location: bj）を含むリクエストも、同様の重みベースの分割に従います。

ステップ 3: 新しいバージョンをプロモートする

カナリア運用が安定した後、すべての本番トラフィックを新しいサービスに切り替え、カナリア Ingress をクリーンアップします。

1. tea-ingress.yaml を更新し、canary-svc を指すようにします。

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: tea-ingress
   spec:
     ingressClassName: alb
     rules:
      - host: demo.domain.ingress.top
        http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: canary-svc  # tea-svc から変更。
               port:
                 number: 80

   kubectl apply -f tea-ingress.yaml

2. カナリア Ingress を削除します。

   kubectl delete ing canary-weight-ingress canary-header-ingress

3. すべてのトラフィックが新バージョンに到達することを検証します。

   for i in $(seq 1 10); do curl -s -H "Host:demo.domain.ingress.top" http://alb-ny3ute4r8yevni****.cn-chengdu.alb.aliyuncs.com; done

   すべての 10 回の応答で new が返されます。旧サービスバージョンは完全に非推奨となります。

次のステップ

• HTTP から HTTPS へのリダイレクトやカスタムルーティングルールなど、高度な ALB イングレス構成については、「高度な ALB イングレス構成」をご参照ください。

• トラブルシューティングに関するガイダンスについては、「Ingress よくある質問」をご参照ください。