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.

YAMLコンテンツの表示

apiVersion: apps/v1
kind: Deployment
metadata:
  name: old-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: old-nginx
  sessionAffinity: None
  type: NodePort

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

Ingressを作成します。

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the old application version. 
      - 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 "Host: www.example.com"  http://<EXTERNAL_IP>
```
  期待される出力:
```
old
```

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

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

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

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

YAMLコンテンツの表示

apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: new-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: new-nginx
  sessionAffinity: None
  type: 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
metadata:
  name: gray-release-canary
  annotations:
    # Enable the canary release feature. 
    nginx.ingress.kubernetes.io/canary: "true"
    # Set the request header to foo. 
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # Only requests whose headers are foo and header values are bar are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the new application version. 
      - 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 "Host: www.example.com"  http://<EXTERNAL_IP>
```
  期待される出力:
```
old
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値がバーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
new
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、リクエストヘッダーのfooパラメーターの値がバーと一致するリクエストのみが新しいアプリケーションバージョンに転送されることを示しています。

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

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Enable the canary release feature. 
    nginx.ingress.kubernetes.io/canary: "true"
    # Set the request header to foo. 
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # Only requests whose headers are foo and header values are bar are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
    # Only 50% of the requests that do not match the preceding rule are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the new application version. 
      - 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 "Host: www.example.com"  http://<EXTERNAL_IP>
```
  期待される出力:
```
old
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値がバーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
new
```
- リクエストヘッダーのfooパラメーターの値がバーと一致するリクエスト:
  すべてのリクエストはnew-nginxサービスに転送されます。 canary-by-headerおよびcanary-by-header-valueアノテーションを使用して、一致ルールを設定できます。
- リクエストヘッダーのfooパラメーターの値がbarと一致しないリクエスト:
  50% のリクエストはnew-nginxサービスに転送されます。 canary-weightアノテーションを使用して、一致ルールを設定できます。

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

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Enable the canary release feature. 
    nginx.ingress.kubernetes.io/canary: "true"
    # Only 50% of requests are forwarded to the new-nginx Service. 
    # The default total weight is 100. 
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the new application version. 
      - 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 "Host: www.example.com" http://<EXTERNAL_IP>
```

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

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

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

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

YAMLコンテンツの表示

apiVersion: v1
kind: Service
metadata:
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    # Specify a selector that is used to select the Deployment created for the new application version. 
    run: new-nginx
  sessionAffinity: None
  type: NodePort

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

service-* annotations

注釈

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

nginx.ingress.kubernetes.io/service-match

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

nginx.ingress.kubernetes.io/service-match: | 
    <service-name>: <match-rule>
# Parameters
# service-name: the name of a Service. Requests that match the rules specified by match-rule are forwarded to the Service. 
# match-rule: the match rules for requests.
#
# Match rules:
# 1. The following types of match rules are supported:
# - header: matches requests based on the request header. Regular expressions and exact match rules are supported. 
# - cookie: matches requests based on the cookie. Regular expressions and exact match rules are supported. 
# - query: based on the query parameters. Regular expressions and exact match rules are supported. 
#
# 2. The following match methods are supported:
# - Regular expressions: /{regular expression}/. A regular expression is enclosed within a pair of forward slashes (/). 
# - Exact match rules:"{exact expression}". An exact match rule is enclosed within a pair of quotation marks (").

一致ルールの例:

# If the value of the foo parameter in the request header matches the regular expression ^bar$, the request is forwarded to the new-nginx Service. 
new-nginx: header("foo", /^bar$/)
# If the value of the foo parameter in the request header exactly matches the value bar, the request is forwarded to the new-nginx Service. 
new-nginx: header("foo", "bar")
# If the value of the foo parameter in the cookie matches the regular expression ^sticky-.+$, the request is forwarded to the new-nginx Service. 
new-nginx: cookie("foo", /^sticky-.+$/)
# If the value of the foo parameter in the query parameters exactly matches the value bar, the request is forwarded to the new-nginx Service. 
new-nginx: query("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>
Parameters in the preceding command:
new-svc-name: the name of the Service that is created for the new application version.
new-svc-weight: the traffic weight of the Service that is created for the new application version.
old-svc-name: the name of the Service that is created for the old application version.
old-svc-weight: the traffic weight of the Service that is created for the old application version.

サービス重み設定の例:

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

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

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

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

YAMLコンテンツの表示

apiVersion: apps/v1
kind: Deployment
metadata:
  name: old-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: old-nginx
  sessionAffinity: None
  type: NodePort

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

Ingressを作成します。

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the old application version. 
      - 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 "Host: www.example.com"  http://<EXTERNAL_IP>
```
  期待される出力:
```
old
```

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

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

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

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

YAMLコンテンツの表示

apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: new-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: new-nginx
  sessionAffinity: None
  type: NodePort

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

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

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

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # Only requests whose values of the foo parameters in the request headers match the regular expression bar are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/service-match: | 
      new-nginx: header("foo", /^bar$/)
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the old application version. 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Information about the Service that is created for the new application version. 
      - 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 "Host: www.example.com"  http://<EXTERNAL_IP>
```
  期待される出力:
```
old
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
new
```

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

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

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # Only requests whose values of the foo parameters in the request headers match the regular expression bar are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/service-match: |
        new-nginx: header("foo", /^bar$/)
    # Only 50% of the requests that match the preceding rule are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/service-weight: |
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the old application version. 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Information about the Service that is created for the new application version. 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80
 servicePort: 80

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # Only requests whose values of the foo parameters in the request headers match the regular expression bar are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/service-match: |
        new-nginx: header("foo", /^bar$/)
    # Only 50% of the requests that match the preceding rule are forwarded to the new-nginx Service. 
    nginx.ingress.kubernetes.io/service-weight: |
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the old application version. 
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # Information about the Service that is created for the new application version. 
      - 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 "Host: www.example.com"  http://<EXTERNAL_IP>
```
  期待される出力:
```
old
```
2. 次のコマンドを実行して、リクエストヘッダーのfooパラメーターの値が正規表現バーと一致するリクエストを使用してNGINXアプリケーションにアクセスします。
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  期待される出力:
```
new
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、リクエストヘッダーのfooパラメーター値が正規表現バーと一致する50% のリクエストのみが新しいアプリケーションバージョンに転送されることを示しています。

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
      # 50% of requests are forwarded to the new-nginx Service. 
      nginx.ingress.kubernetes.io/service-weight: |
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the old application version. 
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Information about the Service that is created for the new application version. 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
  annotations:
      # 50% of requests are forwarded to the new-nginx Service. 
      nginx.ingress.kubernetes.io/service-weight: |
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the old application version. 
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # Information about the Service that is created for the new application version. 
      - 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 "Host: www.example.com" http://<EXTERNAL_IP>
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、50% の要求のみが新しいアプリケーションバージョンに転送されることを示しています。

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

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

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

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the new application version. 
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Information about the Service that is created for the new application version. 
      - 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 "Host: www.example.com" http://<EXTERNAL_IP>
```
期待される出力:
```
new
```
上記のコマンドを再度実行して、アクセスをテストできます。結果は、すべての要求が新しいアプリケーションバージョンに転送されることを示しています。
以前のバージョンのアプリケーション用に作成されたDeployment and Serviceを削除します。
1. 次のコマンドを実行して、以前のバージョンのアプリケーション用に作成されたDeploymentを削除します。
```
kubectl delete deploy <Deployment name>
```
2. 次のコマンドを実行して、以前のバージョンのアプリケーション用に作成されたサービスを削除します。
```
kubectl delete svc <Service name>
```