アノテーションと ConfigMap を使用した NGINX Ingress の設定 - Container Service for Kubernetes

Kubernetes クラスターでは、NGINX Ingress がサービスへの外部アクセスを管理し、レイヤー 7 のロードバランシングを提供します。 NGINX Ingress を使用して、外部からアクセス可能な URL、再書き込みルール、HTTPS サービス、および段階的リリース機能を設定できます。このトピックでは、セキュアルーティングの設定、HTTPS 相互認証の設定、正規表現とワイルドカードドメイン名の使用、および無料の HTTPS 証明書のリクエスト方法について説明します。

前提条件

Nginx Ingress コントローラーをインストールしました。
kubectl クライアントがクラスターに接続されていること。詳細については、「クラスターの KubeConfig を取得し、kubectl を使用してクラスターに接続する」をご参照ください。
サービスが NGINX Ingress によって公開されていること。詳細については、「NGINX Ingress を作成してサービスを公開する」をご参照ください。

設定手順

Container Service for Kubernetes (ACK) の NGINX Ingress コントローラーの設定方法は、オープンソースコミュニティと完全に互換性があります。設定の詳細については、「NGINX Configuration」をご参照ください。

以下の 3 つの設定方法がサポートされています：

アノテーションベース：各 NGINX Ingress の YAML ファイルにアノテーションを設定できます。この設定は、その Ingress のみに有効です。詳細については、「Annotations」をご参照ください。
ConfigMap ベース：`kube-system/nginx-configuration` ConfigMap を設定できます。これは、すべての NGINX Ingress に有効なグローバル設定です。詳細については、「ConfigMaps」をご参照ください。
カスタム NGINX テンプレート：NGINX Ingress コントローラーの内部 NGINX テンプレートに特別な設定要件があり、アノテーションベースおよび ConfigMap ベースの方法ではニーズを満たせない場合に使用できます。詳細については、「カスタム NGINX テンプレート」をご参照ください。

URL リダイレクトのためのルーティングサービスの設定

NGINX Ingress コントローラーを使用する場合、NGINX は完全なリクエストパスに基づいてリクエストを転送します。たとえば、NGINX Ingress コントローラーは、/service1/api パスへのリクエストを、バックエンド Pod の /service1/api パスに直接転送します。バックエンドサービスのパスが /api の場合、パスが正しくないため、404 ステータスコードが返されます。この場合、nginx.ingress.kubernetes.io/rewrite-target アノテーションを設定して、リクエストパスを正しいディレクトリに再書き込みできます。

クラスターのバージョンに基づいて NGINX Ingress を作成します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: foo.bar.com
  namespace: default
  annotations:
    # URL リダイレクト
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
    # Ingress コントローラーのバージョンが 0.22.0 以降の場合、path フィールドで正規表現を使用してパスを定義し、rewrite-target アノテーションのキャプチャグループと組み合わせて使用する必要があります。
      - path: /svc(/|$)(.*)
        backend:
          service: 
            name: web1-service
            port: 
              number: 80
        pathType: ImplementationSpecific

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: foo.bar.com
  namespace: default
  annotations:
    # URL リダイレクト
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      # Ingress コントローラーのバージョンが 0.22.0 以降の場合、path フィールドで正規表現を使用してパスを定義し、rewrite-target アノテーションのキャプチャグループと組み合わせて使用する必要があります。
      - path: /svc(/|$)(.*)
        backend:
          serviceName: web1-service
          servicePort: 80

NGINX サービスにアクセスします。
1. 次のコマンドを実行して、ADDRESS を取得します。
```
kubectl  get  ingress
```
  想定される出力：
```
NAME           CLASS   HOSTS                ADDRESS          PORTS   AGE
foo.bar.com    nginx   foo.bar.com        172.16.XX.XX       80      46m
```
2. 次のコマンドを実行します。 ADDRESS を Ingress の IP アドレスに置き換えます。
```
curl -k -H "Host: foo.bar.com"  http://<ADDRESS>/svc/foo
```
  想定される出力：
```
web1: /foo
```

再書き込み設定

nginx.ingress.kubernetes.io/rewrite-target アノテーションを使用して、基本的な再書き込みルールを設定できます。詳細については、「URL リダイレクトのためのルーティングサービスの設定」をご参照ください。

複雑で高度な再書き込み要件には、次のアノテーションを使用できます：

nginx.ingress.kubernetes.io/server-snippet：Server セクションに設定スニペットを追加します。
nginx.ingress.kubernetes.io/configuration-snippet：Location セクションに設定を追加します。

これら 2 つのアノテーションは、Ingress コンポーネントの NGINX サーバーブロックにカスタムコードスニペットを追加します。これにより、さまざまなシナリオに合わせて NGINX 設定を柔軟に拡張およびカスタマイズできます。

設定例：

annotations:
     nginx.ingress.kubernetes.io/server-snippet: |
         rewrite ^/v4/(.*)/card/query http://foo.bar.com/v5/#!/card/query permanent;
     nginx.ingress.kubernetes.io/configuration-snippet: |
         rewrite ^/v6/(.*)/card/query http://foo.bar.com/v7/#!/card/query permanent;

次のコマンドを実行して、NGINX Ingress コントローラーコンポーネント内の NGINX 設定ファイルを表示します。

kubectl exec nginx-ingress-controller-xxxxx --namespace kube-system -- cat /etc/nginx/nginx.conf   /# ご利用の環境に基づいて Pod 名を変更してください。

この設定例では、次の nginx.conf ファイルが生成されます。

# start server foo.bar.com
    server {
        server_name foo.bar.com ;
        listen 80;
        listen [::]:80;
        set $proxy_upstream_name "-";
    # server-snippet 設定
        rewrite ^/v4/(.*)/card/query http://foo.bar.com/v5/#!/card/query permanent;
        ...
    # configuration-snippet 設定
      rewrite ^/v6/(.*)/card/query http://foo.bar.com/v7/#!/card/query permanent;
      ...
    }
    # end server foo.bar.com

snippet アノテーションは、グローバル設定もサポートしています。詳細については、「server-snippet」をご参照ください。

rewrite 命令の使用方法の詳細については、NGINX の公式ドキュメントをご参照ください。

ルーティングルールのための HTTPS 証明書の設定

Ingress のネイティブセマンティクスを使用して、Web サイトの HTTPS 証明書を設定できます。

サービス証明書を準備します。
説明
ドメイン名は、設定するホストと一致する必要があります。そうでない場合、NGINX Ingress コントローラーは証明書を正しく読み込めません。
1. 次のコマンドを実行して、tls.crt という名前の証明書ファイルと tls.key という名前の秘密鍵ファイルを生成します。
```
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=foo.bar.com/O=foo.bar.com"
```
2. 次のコマンドを実行して、シークレットを作成します。
  証明書と秘密鍵から tls-test-ingress という名前の Kubernetes シークレットを作成します。 Ingress を作成する際には、このシークレットを参照する必要があります。
```
kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt
```

次のコマンドを実行して Ingress リソースを作成し、tls フィールドを使用して前のステップで作成したシークレットを参照します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  # TLS 証明書を参照します。
  tls:
  - hosts:
    - foo.bar.com # 証明書に対応するドメイン名。 
    secretName: tls-test-ingress
  rules:
  - host: tls-test-ingress.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: web1-svc
            port:
              number: 80
        pathType: ImplementationSpecific

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  # TLS 証明書を参照します。
  tls:
  - hosts:
    - foo.bar.com # 証明書に対応するドメイン名。
    secretName: tls-test-ingress
  rules:
  - host: tls-test-ingress.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: web1-svc
          servicePort: 80

hosts ファイルを設定するか、実際のドメイン名を使用して TLS サービスにアクセスします。
https://tls-test-ingress.com/foo で web1-svc サービスにアクセスできます。

HTTPS 相互認証の設定

場合によっては、接続のセキュリティを確保するために、サーバーとクライアント間で HTTPS 相互認証を設定する必要があります。 NGINX Ingress コントローラーは、アノテーションを通じてこの機能をサポートしています。

次のコマンドを実行して、自己署名 CA 証明書を作成します。

openssl req -x509 -sha256 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 356 -nodes -subj '/CN=Fern Cert Authority'

想定される出力：

Generating a 4096 bit RSA private key
.............................................................................................................++
.....................................................................................++
writing new private key to 'ca.key'

次のコマンドを実行して、サーバー側証明書を作成します。

次のコマンドを実行して、サーバー側証明書のリクエストファイルを生成します。

openssl req -new -newkey rsa:4096 -keyout server.key -out server.csr -nodes -subj '/CN=foo.bar.com'

想定される出力：

Generating a 4096 bit RSA private key
................................................................................................................................++
.................................................................++
writing new private key to 'server.key'

次のコマンドを実行して、ルート証明書を使用してサーバー側のリクエストファイルに署名し、サーバー側証明書を生成します。
```
openssl x509 -req -sha256 -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
```
想定される出力：
```
Signature ok
subject=/CN=foo.bar.com
Getting CA Private Key
```

次のコマンドを実行して、クライアント側証明書を作成します。

クライアント側証明書のリクエストファイルを生成します。

openssl req -new -newkey rsa:4096 -keyout client.key -out client.csr -nodes -subj '/CN=Fern'

想定される出力：

Generating a 4096 bit RSA private key
.......................................................................................................................................................................................++
..............................................++
writing new private key to 'client.key'
-----

次のコマンドを実行して、ルート証明書を使用してクライアント側のリクエストファイルに署名し、クライアント証明書を生成します。
```
openssl x509 -req -sha256 -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt
```
想定される出力：
```
Signature ok
subject=/CN=Fern
Getting CA Private Key
```

次のコマンドを実行して、作成した証明書を確認します。
```
ls
```
想定される出力：
```
ca.crt  ca.key  client.crt  client.csr  client.key  server.crt  server.csr  server.key
```
次のコマンドを実行して、CA 証明書のシークレットを作成します。
```
kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt
```
想定される出力：
```
secret/ca-secret created
```

次のコマンドを実行して、サーバー証明書のシークレットを作成できます。

kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key

想定される出力：

secret/tls-secret created

次のテンプレートをデプロイして、テスト用の NGINX Ingress ユースケースを作成します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          service:
            name: http-svc
            port: 
              number: 80
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-secret

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-secret

想定される出力：

ingress.networking.k8s.io/nginx-test configured

次のコマンドを実行して、Ingress の IP アドレスを表示します。
```
kubectl get ing
```
ADDRESS フィールドの IP アドレスが Ingress の IP アドレスです。次の出力に示されています。
```
NAME         HOSTS                    ADDRESS         PORTS     AGE
nginx-test   foo.bar.com              39.102.XX.XX    80, 443   4h42m
```

次のコマンドを実行して、hosts ファイルを更新します。プレースホルダーの IP アドレスを実際の Ingress の IP アドレスに置き換えます。

echo "39.102.XX.XX  foo.bar.com" | sudo tee -a /etc/hosts

検証：

クライアント証明書なしでアクセス

curl --cacert ./ca.crt  https://foo.bar.com

想定される出力：

<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.19.0</center>
</body>
</html>

クライアント証明書を使用してアクセス

curl --cacert ./ca.crt --cert ./client.crt --key ./client.key https://foo.bar.com

想定される出力：

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p>Thank you for using nginx.</p>
</body>
</html>

HTTPS サービスを設定してリクエストをバックエンドコンテナーに HTTPS で転送する

デフォルトでは、NGINX Ingress コントローラーはリクエストを HTTP 経由でバックエンドアプリケーションコンテナーに転送します。アプリケーションコンテナーが HTTPS プロトコルを使用している場合、nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" アノテーションを使用して、リクエストを HTTPS 経由でバックエンドアプリケーションコンテナーに転送できます。

以下は、NGINX Ingress 設定の例です：

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    # 注：バックエンドサービスが HTTPS サービスであることを指定する必要があります。
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
  - hosts:
    - <YOUR-HOST-NAME>
    secretName: <YOUR-SECRET-CERT-NAME>
  rules:
  - host: <YOUR-HOST-NAME>
    http:
      paths:
      - path: /
        backend:
          service:
            name: <YOUR-SERVICE-NAME>
            port: 
              number: <YOUR-SERVICE-PORT>
        pathType: ImplementationSpecific

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    # 注：バックエンドサービスが HTTPS サービスであることを指定する必要があります。
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  tls:
  - hosts:
    - <YOUR-HOST-NAME>
    secretName: <YOUR-SECRET-CERT-NAME>
  rules:
  - host: <YOUR-HOST-NAME>
    http:
      paths:
      - path: /
        backend:
          serviceName: <YOUR-SERVICE-NAME>
          servicePort: <YOUR-SERVICE-PORT>

正規表現をサポートするようにドメイン名を設定する

Kubernetes クラスターでは、Ingress リソースはドメイン名設定に正規表現をサポートしていません。ただし、nginx.ingress.kubernetes.io/server-alias アノテーションを使用してこの機能を有効にできます。

次のテンプレートをデプロイします。この例では、正規表現 ~^www\.\d+\.example\.com を使用します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: '~^www\.\d+\.example\.com$, abc.example.com'
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: http-svc1
            port:
              number: 80
        pathType: ImplementationSpecific

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/server-alias: '~^www\.\d+\.example\.com$, abc.example.com'
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: http-svc1
          servicePort: 80

NGINX Ingress コントローラーの設定を表示します。

次のコマンドを実行して、NGINX Ingress コントローラーの Pod を表示します。

kubectl get pods -n kube-system | grep nginx-ingress-controller

想定される出力：

nginx-ingress-controller-77cd987c4c-c****         1/1     Running   0          1h
nginx-ingress-controller-77cd987c4c-x****         1/1     Running   0          1h

次のコマンドを実行して、NGINX Ingress コントローラーの設定を表示します。出力の Server_Name フィールドに有効な設定が表示されます。

kubectl exec -n kube-system nginx-ingress-controller-77cd987c4c-c**** cat /etc/nginx/nginx.conf | grep -C3 "foo.bar.com"

想定される出力：

  # start server foo.bar.com
  server {
--
  server {
    server_name foo.bar.com abc.example.com ~^www\.\d+\.example\.com$ ;
    listen 80  ;
    listen 443  ssl http2 ;
--
--
    }
  }
  # end server foo.bar.com

次のコマンドを実行して、Ingress の IP アドレスを取得します。

kubectl get ing

想定される出力：

NAME            HOSTS         ADDRESS          PORTS     AGE
ingress-regex   foo.bar.com   101.37.XX.XX     80        11s

次のコマンドを実行して、さまざまなルールでサービスアクセスをテストします。
前のステップで取得した IP アドレスで IP_ADDRESS を置き換えます。
- 次のコマンドを実行して、Host: foo.bar.com を使用してサービスにアクセスします。
```
curl -H "Host: foo.bar.com" <IP_ADDRESS>/foo
```
  想定される出力：
```
/foo
```
- 次のコマンドを実行して、Host: www.123.example.com を使用してサービスにアクセスします。
```
curl -H "Host: www.123.example.com" <IP_ADDRESS>/foo
```
  想定される出力：
```
/foo
```
- 次のコマンドを実行して、Host: www.321.example.com を使用してサービスにアクセスします。
```
curl -H "Host: www.321.example.com" <IP_ADDRESS>/foo
```
  想定される出力：
```
/foo
```

ドメイン名の汎用化をサポートする設定

Kubernetes クラスターでは、NGINX Ingress リソースはワイルドカードドメイン名をサポートしています。たとえば、*.ingress-regex.com ワイルドカードドメイン名を設定できます。

次のテンプレートをデプロイして、NGINX Ingress を作成します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
spec:
  rules:
  - host: *.ingress-regex.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: http-svc1
            port:
              number: 80
        pathType: ImplementationSpecific

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-regex
  namespace: default
spec:
  rules:
  - host: *.ingress-regex.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: http-svc1
          servicePort: 80

次のコマンドを実行して、対応する NGINX Ingress コントローラーの設定を表示します。 server_name フィールドで有効な設定を見つけることができます。

kubectl exec -n kube-system <nginx-ingress-pod-name> cat /etc/nginx/nginx.conf | grep -C3 "*.ingress-regex.com"

説明

ご利用の環境の NGINX Ingress Pod で nginx-ingress-pod-name を置き換えます。

想定される出力：

# start server *.ingress-regex.com
  server {
    server_name *.ingress-regex.com ;
    listen 80;
    listen [::]:80;
...
  }
  # end server *.ingress-regex.com

NGINX Ingress コントローラーの新しいバージョンでは、想定される出力は次のようになります：

## start server *.ingress-regex.com
  server {
    server_name ~^(?<subdomain>[\w-]+)\.ingress-regex\.com$ ;
    listen 80;
    listen [::]:80;
...
  }
  ## end server *.ingress-regex.com

次のコマンドを実行して、Ingress の IP アドレスを取得します。

kubectl get ing

想定される出力：

NAME            HOSTS                 ADDRESS           PORTS     AGE
ingress-regex   *.ingress-regex.com   101.37.XX.XX      80        11s

次のコマンドを実行して、さまざまなルールでサービスアクセスをテストします。
前のステップで取得した IP アドレスで IP_ADDRESS を置き換えます。
- 次のコマンドを実行して、Host: abc.ingress-regex.com を使用してサービスにアクセスします。
```
curl -H "Host: abc.ingress-regex.com" <IP_ADDRESS>/foo
```
  想定される出力：
```
/foo
```
- 次のコマンドを実行して、Host: 123.ingress-regex.com を使用してサービスにアクセスします。
```
curl -H "Host: 123.ingress-regex.com" <IP_ADDRESS>/foo
```
  想定される出力：
```
/foo
```
- 次のコマンドを実行して、Host: a1b1.ingress-regex.com を使用してサービスにアクセスします。
```
curl -H "Host: a1b1.ingress-regex.com" <IP_ADDRESS>/foo
```
  想定される出力：
```
/foo
```

アノテーションを使用した段階的リリースの実装

アノテーションを設定することで、段階的リリースを実装できます。段階的リリース機能を有効にするには、nginx.ingress.kubernetes.io/canary: "true" アノテーションを設定します。次のアノテーションを使用して、さまざまな段階的リリース戦略を実装します：

nginx.ingress.kubernetes.io/canary-weight：ターゲットサービスにルーティングされるリクエストの割合を指定します。値は 0 から 100 までの整数です。
nginx.ingress.kubernetes.io/canary-by-header：リクエストヘッダーに基づいてトラフィックをルーティングします。設定された header の値が always の場合、すべてのトラフィックが段階的リリースサービスのエンドポイントにルーティングされます。 header の値が never の場合、トラフィックは段階的リリースサービスにルーティングされません。他の header の値は無視され、トラフィックはルールの優先順位に従って他の段階的リリースサービスにルーティングされます。
nginx.ingress.kubernetes.io/canary-by-header-value と nginx.ingress.kubernetes.io/canary-by-header：リクエストの header と header-value の両方が設定値と一致する場合に、トラフィックを段階的リリースサービスのエンドポイントにルーティングします。他の header の値は無視され、トラフィックはルールの優先順位に従って他の段階的リリースサービスにルーティングされます。
nginx.ingress.kubernetes.io/canary-by-cookie：Cookie に基づいてトラフィックをルーティングします。設定された cookie の値が always の場合、すべてのトラフィックが段階的リリースサービスのエンドポイントにルーティングされます。設定された cookie の値が never の場合、トラフィックは段階的リリースサービスのエンドポイントにルーティングされません。

以下の例は、一般的なアノテーション設定を示しています。詳細については、「NGINX Ingress を使用して段階的リリースとブルーグリーンデプロイメントを実装する」をご参照ください。

重みベースの段階的リリース：段階的リリースサービスの重みを 20% に設定します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"

ヘッダーベースの段階的リリース：リクエストヘッダーが ack:always の場合、リクエストを段階的リリースサービスにルーティングします。リクエストヘッダーが ack:never の場合、リクエストを段階的リリースサービスにルーティングしません。他のヘッダーについては、重みに基づいてトラフィックを段階的リリースサービスに割り当てます。
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "50"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
```
カスタムヘッダー値を持つヘッダーベースの段階的リリース：リクエストヘッダーが ack:alibaba の場合、リクエストを段階的リリースサービスにルーティングします。他のヘッダーについては、重みに基づいてトラフィックを段階的リリースサービスに割り当てます。
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"
```

Cookie ベースの段階的リリース：リクエストヘッダーがどのルールにも一致せず、リクエスト Cookie が hangzhou_region=always の場合、リクエストを段階的リリースサービスにルーティングします。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"
    nginx.ingress.kubernetes.io/canary-by-cookie: "hangzhou_region"

説明

Cookie ベースの段階的リリースは、always と never の値のみをサポートします。
段階的リリースのルール優先順位は、高いものから順に、ヘッダーベース、Cookie ベース、重みベースです。

cert-manager を使用して無料の HTTPS 証明書を申請する

cert-manager は、クラスター内で HTTPS 証明書をプロビジョニングし、自動的に更新するオープンソースの証明書管理ツールです。次の例は、cert-manager を使用して無料の証明書をリクエストし、自動更新を有効にする方法を示しています。

重要

cert-manager はオープンソースコンポーネントです。 ACK はこのコンポーネントを保守しません。本番環境では注意して使用してください。バージョンをアップグレードするには、「Upgrading cert-manager」をご参照ください。

次のコマンドを実行して、cert-manager をデプロイします。

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

次のコマンドを実行して、Pod のステータスを表示します。

kubectl get pods -n cert-manager

想定される出力：

NAME                     READY   STATUS    RESTARTS   AGE
cert-manager-1           1/1     Running   0          2m11s
cert-manager-cainjector  1/1     Running   0          2m11s
cert-manager-webhook     1/1     Running   0          2m10s

次のテンプレートを使用して、ClusterIssuer を作成します。

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-http01
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your_email@example.com>  # これをメールアドレスに置き換えてください。
    privateKeySecretRef:
      name: letsencrypt-http01
    solvers:
    - http01: 
        ingress:
          class: nginx

次のコマンドを実行して、ClusterIssuer を表示します。

kubectl get clusterissuer

想定される出力：

NAME                         READY   AGE
letsencrypt-prod-http01      True    17s

NGINX Ingress リソースオブジェクトを作成します。

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-tls
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod-http01"
spec:
  tls:
  - hosts:
    - <YOUR_DOMAIN_NAME>        # これをドメイン名に置き換えてください。
    secretName: ingress-tls   
  rules:
  - host: <YOUR_DOMAIN_NAME>    # これをドメイン名に置き換えてください。
    http:
      paths:
      - path: /
        backend:
          service:
            name: <YOUR_SERVICE_NAME>  # これをバックエンドサービス名に置き換えてください。
            port: 
              number: <YOUR_SERVICE_PORT>  # これをサービスポートに置き換えてください。
        pathType: ImplementationSpecific

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

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tls
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod-http01"
spec:
  tls:
  - hosts:
    - <YOUR_DOMAIN_NAME>        # これをドメイン名に置き換えてください。
    secretName: ingress-tls   
  rules:
  - host: <YOUR_DOMAIN_NAME>    # これをドメイン名に置き換えてください。
    http:
      paths:
      - path: /
        backend:
          serviceName: <YOUR_SERVICE_NAME>  # これをバックエンドサービス名に置き換えてください。
          servicePort: <YOUR_SERVICE_PORT>  # これをサービスポートに置き換えてください。

説明

your_domain_name を置き換えるために使用するドメイン名は、次の条件を満たす必要があります：

ドメイン名は 64 文字を超えることはできません。
ワイルドカードドメイン名はサポートされていません。
パブリックネットワークを介して HTTP プロトコルを使用してアクセスできます。

次のコマンドを実行して、証明書を表示します。
```
kubectl get cert
```
想定される出力：
```
NAME          READY   SECRET        AGE
ingress-tls   True    ingress-tls   52m
```
説明
READY ステータスが True でない場合は、kubectl describe cert ingress-tls を実行して証明書処理プロシージャを表示できます。

次のコマンドを実行して、シークレットを表示します。

kubectl get secret  ingress-tls

想定される出力：

NAME          TYPE                DATA   AGE
ingress-tls   kubernetes.io/tls   2      2m

Web ブラウザーで、https://[your_website_domain] を入力して、設定したドメイン名にアクセスします。

HTTP から HTTPS へのリダイレクトの設定

NGINX Ingress の nginx.ingress.kubernetes.io/ssl-redirect アノテーションは、HTTP トラフィックを強制的に HTTPS にリダイレクトできます。次の例は、この設定を示しています：

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true" # HTTP トラフィックを強制的に HTTPS にリダイレクトします。

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true" # HTTP トラフィックを強制的に HTTPS にリダイレクトします。