NGINX Ingressコントローラーを使用してカナリアリリースとブルーグリーンリリースを実装する - Container Service for Kubernetes

アプリケーションのバージョンを更新するときに、ローリングアップデート、段階的リリース、青緑色展開、カナリアリリースを実装できます。このトピックでは、NGINX Ingressコントローラーを使用して、Container Service for Kubernetes (ACK) クラスターにアプリケーションのカナリアリリースを実装する方法について説明します。

背景情報

カナリアリリースまたは青緑色の展開を実装して、以前のバージョンと新しいバージョンのアプリケーションを同一の運用環境に公開できます。この場合、ユーザーがリクエストを送信すると、ACKは特定のルールに基づいて一部のリクエストを新しいバージョンにルーティングします。新しいバージョンが一定期間正常に実行される場合、すべてのトラフィックを以前のバージョンから新しいバージョンに切り替えることができます。

Blue-greenデプロイメントは、カナリアリリースを実装する方法です。 blue-green展開では、一部のユーザーは以前のバージョンを使用し、他のユーザーからのリクエストは新しいバージョンに転送されます。新しいバージョンが一定期間正常に実行される場合、すべてのトラフィックを新しいバージョンに徐々に切り替えることができます。

ACKコンソールで次のいずれかの方法を使用して、カナリアリリースを実装する方法を設定できます。

canary-* annotationsを使用する: canary-* annotationsを使用して、blue-greenデプロイメントとカナリアリリースを実装する方法を設定できます。 canary-* アノテーションはKubernetesで使用されます。
service-* annotationsを使用する: service-* annotationsを使用して、blue-greenデプロイとカナリアリリースの実装方法を設定できます。 service-* アノテーションは、初期のNGINX Ingressコントローラーバージョンでカナリアリリースを実装するために使用されます。 service-matchおよびservice-weightアノテーションは維持されなくなり、まもなく廃止されます。 service-* アノテーションは引き続き使用できます。

シナリオ

リクエストに基づくトラフィック分割

たとえば、ユーザーにレイヤ7アクセスを提供するために、運用環境でサービスAを既に作成しているとします。新しい機能が利用可能になったら、新しいアプリケーションバージョンのサービスA' を作成します。外部アクセスのためにサービスAを維持したい場合は、リクエストヘッダーのfooパラメーターの値がbarと一致するリクエスト、またはCookieのfooパラメーターの値がbarと一致するリクエストをサービスA' に転送できます。新しいバージョンが一定期間安定して実行される場合、すべてのトラフィックをサービスaからサービスA' に切り替えることができます。次に、サービスAを削除できます。场景一

サービスの重みに基づくトラフィック分割

たとえば、ユーザーにレイヤ7アクセスを提供するために、運用環境でサービスBを既に作成しているとします。いくつかの問題が修正されたら、新しいアプリケーションバージョンのサービスB' を作成します。外部アクセスのためにサービスBを維持したい場合は、トラフィックの20% をサービスB' に切り替えることができます。新しいバージョンが一定期間安定して実行される場合、すべてのトラフィックをサービスBからサービスB' に切り替えることができます。次に、サービスBを削除できます。场景二

ACKのIngressコントローラーは、アプリケーションリリースの前述の要件をサポートするために、次のトラフィック分割方法を提供します。

リクエストヘッダーに基づくトラフィック分割。この方法は、カナリアリリースまたはA/Bテストが必要なシナリオに適用されます。
Cookieに基づくトラフィック分割。この方法は、カナリアリリースまたはA/Bテストが必要なシナリオに適用されます。
クエリパラメーターに基づくトラフィック分割。この方法は、カナリアリリースまたはA/Bテストが必要なシナリオに適用されます。
サービスの重みに基づくトラフィック分割。この方法は、青緑展開が必要なシナリオに適用されます。

canary-* annotationsを使用する

注釈

次の表に、NGINX Ingressコントローラーがカナリアリリースを実装するために使用するcanary-* アノテーションを示します。

注釈	説明	該当するNGINX Ingressコントローラのバージョン
nginx.ingress.kubernetes.io /カナリア	このアノテーションの値を`true`に設定する必要があります。それ以外の場合、他のルールは有効になりません。有効な値： `true`: `カナリア`機能を有効にします。 `false`: `canary`機能を無効にします。	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-by-header	リクエストヘッダーに基づいてカナリアリリースを実装します。次の特殊な値がサポートされています。 `always`: すべてのトラフィックを新しいアプリケーションバージョンに転送します。 `never`: 新しいアプリケーションバージョンにトラフィックを転送しません。ヘッダーを指定しない場合、ヘッダーを含むすべてのリクエストが転送されます。	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-by-header-value	リクエストヘッダー値に基づいてカナリアリリースを実装します。このアノテーションは、`canary-by-header`アノテーションと一緒に使用する必要があります。	≥ 0.30.0
nginx.ingress.kubernetes.io/canary-by-header-pattern	リクエストヘッダー値が指定された正規表現と一致するかどうかに基づいてカナリアリリースを実装します。このアノテーションは、`canary-by-header`アノテーションと一緒に使用する必要があります。値を、リクエストヘッダー値の一致に使用する正規表現に設定します。	≥ 0.44.0
nginx.ingress.kubernetes.io/canary-by-cookie	Cookieに基づいてカナリアリリースを実装します。例: `nginx.ingress.kubernetes.io/canary-by-cookie: foo` クッキーの値: `always`: cookieに`foo=always`が指定されている場合、リクエストは新しいアプリケーションバージョンに転送されます。 `never`: cookieに`foo=never`が指定されている場合、要求は新しいアプリケーションバージョンに転送されません。 cookieが存在し、値が`常に`である場合にのみ、トラフィックが転送されます。	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-weight	重みに基づいてカナリアリリースを実装します。有効な値: 0〜合計の重み。デフォルトの総重みは100です。	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-weight-total	総重量。デフォルトの総重みは100です。	≥ 1.1.2

上記のアノテーションは、優先順位の降順で有効になります。

canary-by-header > canary-by-cookie > canary-weight

説明

Ingressルールで指定できるカナリアIngressは1つだけです。複数のカナリアIngressを指定した場合、カナリアリリースの実装に使用されるカナリアIngressは1つだけです。

手順1: アプリケーションのデプロイ

NGINXアプリケーションを作成し、NGINX Ingressコントローラーをデプロイして、ドメイン名を使用してアプリケーションへのレイヤー7アクセスを有効にします。

デプロイメントとサービスを作成します。

という名前のファイルを作成します。nginx.yaml.

クリックして詳細を表示

apiVersion: apps/v1
kind: 配置
メタデータ:
  名前: old-nginx
spec:
  レプリカ：2
  セレクタ：
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    仕様：
      containers:
      -画像: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ポート：
        - containerPort: 80
          protocol: TCP
      restartPolicy: 常に
---
apiVersion: v1
種類: サービス
メタデータ:
  名前: old-nginx
spec:
  ポート：
  - port: 80
    protocol: TCP
    targetPort: 80
  セレクタ：
    run: old-nginx
  sessionAffinity: None
  タイプ: NodePort

次のコマンドを実行して、展開とサービスを作成します。
```
kubectl apply -f nginx.yaml
```

Ingressを作成します。

という名前のファイルを作成します。ingress.yaml.

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  名前: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  名前: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```

Ingressへのアクセスをテストします。
1. 次のコマンドを実行して、IngressのパブリックIPアドレスを照会します。
```
kubectl get ingress
```
2. 次のコマンドを実行してIngressにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
  期待される出力:
```
古い
```

ステップ2: アプリケーションのカナリアリリースを実装する

新しいNGINXアプリケーションバージョンをリリースし、Ingressルールを設定します。

新しいアプリケーションバージョンの展開とサービスを作成します。

という名前のファイルを作成します。nginx1.yaml.

クリックして詳細を表示

apiVersion: apps/v1
kind: 配置
メタデータ:
  名前: new-nginx
spec:
  replicas: 1
  セレクタ：
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    仕様：
      containers:
      -画像: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ポート：
        - containerPort: 80
          protocol: TCP
      restartPolicy: 常に
---
apiVersion: v1
種類: サービス
メタデータ:
  名前: new-nginx
spec:
  ポート：
  - port: 80
    protocol: TCP
    targetPort: 80
  セレクタ：
    run: new-nginx
  sessionAffinity: None
  タイプ: NodePort

次のコマンドを実行して、新しいアプリケーションバージョンのデプロイとサービスをデプロイします。
```
kubectl apply -f nginx1.yaml
```

新しいアプリケーションバージョンのIngressルールを設定します。

ACKは、次のタイプのIngressルールを提供します。要件に基づいてIngressルールのタイプを選択します。

Ingressルールを設定して、ルールに一致するリクエストを新しいアプリケーションバージョンに転送します。次の例では、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストのみが新しいアプリケーションバージョンに転送されます。

ingress1.yamlファイルにgray-release-canaryという名前の新しいIngressを作成します。

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  名前: gray-release-canary
  アノテーション：
    # カナリアリリース機能を有効にします。 
    nginx.ingress.kubernetes.io/canary: "true"
    # リクエストヘッダーをfooに設定します。 
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # ヘッダーがfooでヘッダー値がbarのリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  名前: gray-release-canary
  アノテーション：
    # カナリアリリース機能を有効にします。 
    nginx.ingress.kubernetes.io/canary: "true"
    # リクエストヘッダーをfooに設定します。 
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # ヘッダーがfooでヘッダー値がbarのリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
    
仕様：
  rules:
  - host: www.example.com
    http:
      paths:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngress1をデプロイします。
```
kubectl apply -f ingress1.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
Ingressへのアクセスをテストします。
1. 次のコマンドを実行してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
  期待される出力:
```
古い
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
新しい
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、リクエストヘッダーのfooパラメーターの値がバーと一致するリクエストのみが新しいアプリケーションバージョンに転送されることを示しています。

リクエストがルールに一致しない場合、特定の割合のリクエストを新しいアプリケーションバージョンに転送します。次の例では、リクエストヘッダーのfooパラメーターの値がbarと一致しない50% のリクエストのみが新しいバージョンに転送されます。

次のコンテンツに基づいて、2で作成されたIngressを変更します。

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  名前: gray-release-canary
  アノテーション：
    # カナリアリリース機能を有効にします。 
    nginx.ingress.kubernetes.io/canary: "true"
    # リクエストヘッダーをfooに設定します。 
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # ヘッダーがfooでヘッダー値がbarのリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
    # 上記のルールと一致しない50% のリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  名前: gray-release-canary
  アノテーション：
    # カナリアリリース機能を有効にします。 
    nginx.ingress.kubernetes.io/canary: "true"
    # リクエストヘッダーをfooに設定します。 
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # ヘッダーがfooでヘッダー値がbarのリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
    # 上記のルールと一致しない50% のリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
Ingressへのアクセスをテストします。
1. 次のコマンドを実行してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
  期待される出力:
```
古い
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
新しい
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、リクエストヘッダーのfooパラメーター値が正規表現バーと一致する50% のリクエストのみが新しいアプリケーションバージョンに転送されることを示しています。

特定の割合のリクエストを新しいアプリケーションバージョンに転送するようにIngressルールを設定します。次の例では、50% の要求のみが新しいアプリケーションバージョンに転送されます。

次の内容に基づいて、ステップ2で作成されたIngressを変更します。

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  名前: gray-release-canary
  アノテーション：
    # カナリアリリース機能を有効にします。 
    nginx.ingress.kubernetes.io/canary: "true"
    # 50% のリクエストのみがnew-nginxサービスに転送されます。 
    # デフォルトの総重量は100です。 
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  名前: gray-release-canary
  アノテーション：
    # カナリアリリース機能を有効にします。 
    nginx.ingress.kubernetes.io/canary: "true"
    # 50% のリクエストのみがnew-nginxサービスに転送されます。 
    # デフォルトの総重量は100です。 
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
次のコマンドを実行して、Ingressにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```

上記のコマンドを再度実行して、アクセスをテストできます。結果は、50% の要求のみが新しいアプリケーションバージョンに転送されることを示しています。

手順3: 古いアプリケーションバージョンと関連するサービスの削除

新しいアプリケーションバージョンが一定期間、期待どおりに実行される場合は、以前のアプリケーションバージョンをオフラインにして、新しいアプリケーションバージョンのみをアクセスに提供する必要があります。これを行うには、以前のバージョンのアプリケーション用に作成されたサービスを使用して、新しいバージョンのアプリケーション用に作成された展開にアクセスできるようにする必要があります。また、以前のバージョンのアプリケーション用に作成された展開と、新しいバージョンのアプリケーション用に作成されたサービスも削除する必要があります。

古いアプリケーションバージョンのnginx.yamlファイルを変更して、新しいアプリケーションバージョン用に作成された展開を選択します。

クリックして詳細を表示

apiVersion: v1
種類: サービス
メタデータ:
  名前: old-nginx
spec:
  ポート：
  - port: 80
    protocol: TCP
    targetPort: 80
  セレクタ：
    # 新しいアプリケーションバージョン用に作成された展開を選択するために使用されるセレクターを指定します。 
    run: new-nginx
  sessionAffinity: None
  タイプ: NodePort

次のコマンドを実行して、古いアプリケーションバージョンのサービスを作成します。
```
kubectl apply -f nginx.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
次のコマンドを実行してIngressにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
期待される出力:
```
新しい
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、すべての要求が新しいアプリケーションバージョンに転送されることを示しています。
次のコマンドを実行して、gray-release-canaryという名前のcanary Ingressを削除します。
```
kubectl delete ingress gray-release-canary
```
以前のバージョンのアプリケーション用に作成された展開と、新しいバージョンのアプリケーション用に作成されたサービスを削除します。
1. 次のコマンドを実行して、以前のバージョンのアプリケーション用に作成されたDeploymentを削除します。
```
kubectl delete deploy old-nginx
```
2. 次のコマンドを実行して、新しいアプリケーションバージョン用に作成されたサービスを削除します。
```
kubectl削除svc new-nginx
```

service-* annotations

注釈

次の一覧では、NGINX Ingressコントローラーがカナリアリリースを実装するために使用するservice-* アノテーションについて説明します。

nginx.ingress.kubernetes.io/service-match

このアノテーションは、新しいアプリケーションバージョン用に作成されたサービスへの要求の一致ルールを構成するために使用されます。

nginx.ingress.kubernetes.io/service-match: | 
    <service-name>: <match-rule>
# パラメータ
# service-name: サービスの名前。 match-ruleによって指定されたルールに一致するリクエストは、サービスに転送されます。 
# match-rule: リクエストの一致ルール。
#
# マッチルール:
#1. 次のタイプの一致ルールがサポートされています。# - header: リクエストヘッダーに基づいてリクエストを照合します。 正規表現と完全一致ルールがサポートされています。 
# - cookie: cookieに基づいてリクエストを照合します。 正規表現と完全一致ルールがサポートされています。 
# - query: クエリパラメーターに基づいています。 正規表現と完全一致ルールがサポートされています。 
#
#2. 次の一致メソッドがサポートされています。#-正規表現: /{正規表現} /。 正規表現は、スラッシュ (/) のペアで囲まれています。 
#-完全一致ルール: "{Exact expression}" 完全一致ルールは、引用符 (") のペアで囲まれています。

一致ルールの例:

# リクエストヘッダーのfooパラメーターの値が正規表現 ^ ba r$ と一致する場合、リクエストはnew-nginx Serviceに転送されます。 
new-nginx: ヘッダー ("foo", /^ ba r$/)
# リクエストヘッダーのfooパラメーターの値が値バーと完全に一致する場合、リクエストはnew-nginx Serviceに転送されます。 
new-nginx: ヘッダー ("foo" 、"bar")
# cookieのfooパラメーターの値が正規表現 ^ sticky-.+ $と一致する場合、リクエストはnew-nginx Serviceに転送されます。 
new-nginx: cookie("foo", /^ sticky-.+$/)
# クエリパラメーターのfooパラメーターの値が値バーと完全に一致する場合、リクエストはnew-nginx Serviceに転送されます。 
new-nginx: クエリ ("foo" 、"bar")

nginx.ingress.kubernetes.io/service-weight

このアノテーションは、古いバージョンと新しいバージョンのアプリケーションに対して作成されるサービスの重みを設定するために使用されます。

nginx.ingress.kubernetes.io/service-weight: | 
    <new-svc-name >:< new-svc-weight> 、<old-svc-name >:< old-svc-weight>
パラメータ:
new-svc-name: 新しいアプリケーションバージョン用に作成されたサービスの名前。
new-svc-weight: 新しいアプリケーションバージョン用に作成されたサービスのトラフィックの重み。
old-svc-name: 古いアプリケーションバージョン用に作成されたサービスの名前。
old-svc-weight: 古いアプリケーションバージョン用に作成されたサービスのトラフィックの重み。

サービス重み設定の例:

nginx.ingress.kubernetes.io/service-weight: | 
    new-nginx: 20, old-nginx: 60

手順1: アプリケーションのデプロイ

デプロイメントとサービスを作成します。

という名前のファイルを作成します。nginx.yaml.

クリックして詳細を表示

apiVersion: apps/v1
kind: 配置
メタデータ:
  名前: old-nginx
spec:
  レプリカ：2
  セレクタ：
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    仕様：
      containers:
      -画像: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ポート：
        - containerPort: 80
          protocol: TCP
      restartPolicy: 常に
---
apiVersion: v1
種類: サービス
メタデータ:
  名前: old-nginx
spec:
  ポート：
  - port: 80
    protocol: TCP
    targetPort: 80
  セレクタ：
    run: old-nginx
  sessionAffinity: None
  タイプ: NodePort

次のコマンドを実行して、展開とサービスを作成します。
```
kubectl apply -f nginx.yaml
```

Ingressを作成します。

という名前のファイルを作成します。ingress.yaml.

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  名前: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  名前: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```

Ingressへのアクセスをテストします。
1. 次のコマンドを実行して、IngressのパブリックIPアドレスを照会します。
```
kubectl get ingress
```
2. 次のコマンドを実行してIngressにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
  期待される出力:
```
古い
```

ステップ2: アプリケーションのカナリアリリースを実装する

新しいNGINXアプリケーションバージョンをリリースし、Ingressルールを設定します。

新しいアプリケーションバージョンの展開とサービスを作成します。

という名前のファイルを作成します。nginx1.yaml.

クリックして詳細を表示

apiVersion: apps/v1
kind: 配置
メタデータ:
  名前: new-nginx
spec:
  replicas: 1
  セレクタ：
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    仕様：
      containers:
      -画像: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ポート：
        - containerPort: 80
          protocol: TCP
      restartPolicy: 常に
---
apiVersion: v1
種類: サービス
メタデータ:
  名前: new-nginx
spec:
  ポート：
  - port: 80
    protocol: TCP
    targetPort: 80
  セレクタ：
    run: new-nginx
  sessionAffinity: None
  タイプ: NodePort

新しいアプリケーションバージョンの展開とサービスを作成します。
```
kubectl apply -f nginx1.yaml
```

新しいアプリケーションバージョンのIngressルールを設定します。

ACKは、次のタイプのIngressルールを提供します。要件に基づいてIngressルールのタイプを選択します。

次の内容に基づいて、ステップ2で作成されたIngressを変更します。

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  name: gray-release
  アノテーション：
    # リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストのみがnew-nginx Serviceに転送されます。 
    nginx.ingress.kubernetes.io/service-match: | 
      new-nginx: ヘッダー ("foo", /^ ba r$/)
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  name: gray-release
  アノテーション：
    # リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストのみがnew-nginx Serviceに転送されます。 
    nginx.ingress.kubernetes.io/service-match: | 
      new-nginx: ヘッダー ("foo", /^ ba r$/)
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
Ingressへのアクセスをテストします。
1. 次のコマンドを実行してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
  期待される出力:
```
古い
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
新しい
```

上記のコマンドを再度実行して、アクセスをテストできます。結果は、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストのみが新しいアプリケーションバージョンに転送されることを示しています。

Ingressルールを設定して、ルールに一致するリクエストの特定の割合を新しいアプリケーションバージョンに転送します。次の例では、リクエストヘッダーのfooパラメーター値が正規表現バーと一致する50% のリクエストのみが新しいバージョンに転送されます。

次の内容に基づいて、ステップ2で作成されたIngressを変更します。

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  name: gray-release
  アノテーション：
    # リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストのみがnew-nginx Serviceに転送されます。 
    nginx.ingress.kubernetes.io/service-match: |
        new-nginx: header("foo", /^bar$/)
    # 前述のルールに一致する50% のリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/service-weight: |
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80
 servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  name: gray-release
  アノテーション：
    # リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストのみがnew-nginx Serviceに転送されます。 
    nginx.ingress.kubernetes.io/service-match: |
        new-nginx: header("foo", /^bar$/)
    # 前述のルールに一致する50% のリクエストのみがnew-nginxサービスに転送されます。 
    nginx.ingress.kubernetes.io/service-weight: |
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
Ingressへのアクセスをテストします。
1. 次のコマンドを実行してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
  期待される出力:
```
古い
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "ホスト: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
新しい
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、リクエストヘッダーのfooパラメーター値が正規表現バーと一致する50% のリクエストのみが新しいアプリケーションバージョンに転送されることを示しています。

次の内容に基づいて、ステップ2で作成されたIngressを変更します。

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  name: gray-release
  アノテーション：
      # 50% のリクエストがnew-nginxサービスに転送されます。 
      nginx.ingress.kubernetes.io/service-weight: |
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  name: gray-release
  アノテーション：
      # 50% のリクエストがnew-nginxサービスに転送されます。 
      nginx.ingress.kubernetes.io/service-weight: |
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # 旧バージョンのアプリケーション用に作成されたサービスに関する情報。 
      - path: /
        backend:
          サービス: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
次のコマンドを実行して、Ingressにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、50% の要求のみが新しいアプリケーションバージョンに転送されることを示しています。

手順3: 古いアプリケーションバージョンと関連するサービスの削除

新しいアプリケーションバージョンが一定期間、期待どおりに実行される場合は、以前のアプリケーションバージョンをオフラインにして、新しいアプリケーションバージョンのみをアクセスに提供する必要があります。

次の内容に基づいて、手順2で作成されたIngressを変更します。

1.19より前のバージョンのKubernetesを実行するクラスター

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
  名前: gray-release
spec:
  rules:
  -host: www.example.com
    http:
      パス:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kubernetes 1.19以降を実行するクラスター

apiVersion: networking.k8s.io/v1
kind: Ingress
メタデータ:
  名前: gray-release
spec:
  rules:
  -host: www.example.com
    http:
      paths:
      # 新しいアプリケーションバージョン用に作成されたサービスに関する情報。 
      -パス: /
        backend:
          service: 
            name: new-nginx
            port:
              番号: 80
        pathType: ImplementationSpecific

次のコマンドを実行してIngressを作成します。
```
kubectl apply -f ingress.yaml
```
次のコマンドを実行して、外部アクセスのためにIngressのIPアドレスを照会します。
```
kubectl get ingress
```
次のコマンドを実行してIngressにアクセスします。
```
curl -H "ホスト: www.example.com" http://<EXTERNAL_IP>
```
期待される出力:
```
新しい
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、すべての要求が新しいアプリケーションバージョンに転送されることを示しています。
以前のバージョンのアプリケーション用に作成されたDeployment and Serviceを削除します。
1. 次のコマンドを実行して、以前のバージョンのアプリケーション用に作成されたDeploymentを削除します。
```
kubectl delete deploy <デプロイ名>
```
2. 次のコマンドを実行して、以前のバージョンのアプリケーション用に作成されたサービスを削除します。
```
kubectl delete svc <サービス名>
```