Kubernetes クラスターでは、NGINX Ingress はサービスへの外部アクセスを管理し、レイヤー 7 ロードバランシングを提供します。アクセス可能な URL、再書き込みルール、HTTPS サービス、段階的リリースなど、NGINX Ingress のさまざまな機能を設定できます。このトピックでは、セキュアなルーティング、HTTPS 相互認証、正規表現とワイルドカードを使用したドメイン名、および無料の HTTPS 証明書を設定する方法について説明します。
前提条件
クラスターの KubeConfig ファイルを取得し、kubectl を使用してクラスターに接続していること。詳細については、「クラスターの KubeConfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。
NGINX Ingress が作成され、サービスを公開するために使用されていること。詳細については、「NGINX Ingress を作成してサービスを公開する」をご参照ください。
設定の説明
Container Service for Kubernetes (ACK) で使用される NGINX Ingress Controller の設定方法は、コミュニティ版と完全に互換性があります。設定の完全なリストについては、「NGINX Configuration」をご参照ください。
次の 3 つの設定方法がサポートされています：
アノテーションベース：NGINX Ingress の YAML ファイルのアノテーションで設定を構成できます。この設定は、その特定の NGINX Ingress にのみ適用されます。詳細については、「Annotations」をご参照ください。
ConfigMap ベース：`kube-system/nginx-configuration` ConfigMap を使用して設定を構成できます。これは、すべての NGINX Ingress に適用されるグローバル構成です。詳細については、「ConfigMaps」をご参照ください。
カスタム NGINX テンプレート：アノテーションベースまたは ConfigMap ベースの方法では満たせない、NGINX Ingress Controller の内部 NGINX テンプレートに対する特別な設定要件がある場合、この方法を使用できます。詳細については、「Custom NGINX template」をご参照ください。
URL リダイレクトのためのルーティングサービスの設定
NGINX Ingress Controller を使用すると、NGINX は完全なパスをバックエンドに転送します。たとえば、Ingress を介した /service1/api へのリクエストは、バックエンド Pod の /service1/api パスに転送されます。バックエンドサービスのパスが /api の場合、パスの不一致が発生し、404 エラーが返されます。これを修正するには、nginx.ingress.kubernetes.io/rewrite-target アノテーションを設定して、パスを正しいディレクトリに再書き込みします。
クラスターのバージョンに基づいて NGINX Ingress を作成します。
バージョン 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 Controller バージョン 0.22.0 以降では、正規表現を使用してパスを定義し、rewrite-target でキャプチャグループと共に使用する必要があります。
- path: /svc(/|$)(.*)
backend:
service:
name: web1-service
port:
number: 80
pathType: ImplementationSpecificバージョン 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 Controller バージョン 0.22.0 以降では、正規表現を使用してパスを定義し、rewrite-target でキャプチャグループと共に使用する必要があります。
- path: /svc(/|$)(.*)
backend:
serviceName: web1-service
servicePort: 80NGINX サービスにアクセスします。
次のコマンドを実行して、
ADDRESSを取得します。kubectl get ingress想定される出力：
NAME CLASS HOSTS ADDRESS PORTS AGE foo.bar.com nginx foo.bar.com 172.16.XX.XX 80 46m次のコマンドを実行します。
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 server ブロックにカスタムコードスニペットを追加できます。これにより、さまざまなシナリオに合わせて 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 Controller コンポーネント内の 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.comsnippet 機能は、いくつかのグローバル構成もサポートしています。詳細については、「server-snippet」をご参照ください。
rewrite 命令の使用方法の詳細については、NGINX 公式ドキュメントをご参照ください。
ルーティングルールへの HTTPS 証明書の設定
Ingress のネイティブセマンティクスを使用して、Web サイトに HTTPS 証明書を設定できます。
サービス証明書を準備します。
説明ドメイン名は、設定するホストと同じである必要があります。そうでない場合、NGINX Ingress Controller は正しくロードできません。
次のコマンドを実行して、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"次のコマンドを実行して、Secret を作成します。
証明書と秘密鍵から `tls-test-ingress` という名前の Kubernetes Secret を作成します。Ingress を作成する際に、この Secret を参照する必要があります。
kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt
次のコマンドを実行してテンプレートをデプロイし、Ingress リソースを作成します。前のステップで作成した Secret を `tls` フィールドで参照する必要があります。
バージョン 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バージョン 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: 80hostsファイルを設定するか、実際のドメイン名を設定して TLS サービスにアクセスします。https://tls-test-ingress.com/fooでweb1-svcサービスにアクセスできます。
HTTPS 相互認証の設定
一部のシナリオでは、接続のセキュリティを確保するために、サーバーとクライアント間で相互 HTTPS 認証を設定する必要がある場合があります。NGINX Ingress Controller を使用すると、アノテーションを使用してこの機能を設定できます。
次のコマンドを実行して、自己署名 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 証明書の Secret を作成します。
kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt次の出力が想定されます：
secret/ca-secret created次のコマンドを実行して、サーバー証明書の Secret を作成します。
kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key想定される出力：
secret/tls-secret created次のテンプレートをデプロイして、テスト用の NGINX Ingress ユースケースを作成します。
バージョン 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バージョン 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想定される出力は次のとおりです。Ingress の IP アドレスは ADDRESS フィールドに表示されます。
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 Controller はリクエストをバックエンドアプリケーションコンテナーに HTTP 経由で転送します。アプリケーションコンテナーが HTTPS を使用している場合、nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" アノテーションを使用して、NGINX Ingress Controller がリクエストをバックエンドアプリケーションコンテナーに HTTPS 経由で転送するように設定できます。
以下は NGINX Ingress の設定例です：
バージョン 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バージョン 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を使用します。バージョン 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バージョン 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 Controller の構成を表示します。
次のコマンドを実行して、NGINX Ingress Controller サービスがデプロイされている 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 Controller の構成を表示します。`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_ADDRESS を前のステップで取得した IP アドレスに設定します。
Host: foo.bar.comを使用してサービスにアクセスするには、次のコマンドを実行します。curl -H "Host: foo.bar.com" <IP_ADDRESS>/foo想定される出力：
/fooHost: www.123.example.comを使用してサービスにアクセスするには、次のコマンドを実行します。curl -H "Host: www.123.example.com" <IP_ADDRESS>/foo想定される出力：
/fooHost: www.321.example.comを使用してサービスにアクセスするには、次のコマンドを実行します。curl -H "Host: www.321.example.com" <IP_ADDRESS>/foo想定される出力：
/foo
ドメイン名におけるワイルドカードサポートの設定
Kubernetes クラスターでは、NGINX Ingress リソースはワイルドカードドメイン名をサポートしています。たとえば、ワイルドカードドメイン名 *.ingress-regex.com を設定できます。
次のテンプレートをデプロイして、NGINX Ingress を作成します。
バージョン 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バージョン 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 Controller の構成を表示します。`server_name` フィールドで有効な構成を確認できます。
kubectl exec -n kube-system <nginx-ingress-pod-name> cat /etc/nginx/nginx.conf | grep -C3 "*.ingress-regex.com"説明nginx-ingress-pod-name を、ご利用の環境の nginx-ingress Pod の名前に置き換えてください。
想定される出力：
# start server *.ingress-regex.com server { server_name *.ingress-regex.com ; listen 80; listen [::]:80; ... } # end server *.ingress-regex.comNGINX Ingress Controller の新しいバージョンでの想定される出力：
## 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_ADDRESS を前のステップで取得した IP アドレスに設定します。
Host: abc.ingress-regex.comを使用してサービスにアクセスするには、次のコマンドを実行します。curl -H "Host: abc.ingress-regex.com" <IP_ADDRESS>/foo想定される出力：
/fooHost: 123.ingress-regex.comを使用してサービスにアクセスするには、次のコマンドを実行します。curl -H "Host: 123.ingress-regex.com" <IP_ADDRESS>/foo想定される出力：
/fooHost: 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 はこのコンポーネントを保守していません。本番環境では注意して使用してください。
次のコマンドを実行して、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_n***@gmail.com> # これをメールボックスに置き換えてください。 privateKeySecretRef: name: letsencrypt-http01 solvers: - http01: ingress: class: nginx次のコマンドを実行して、ClusterIssuer を表示します。
kubectl get clusterissuer想定される出力：
NAME READY AGE letsencrypt-prod-http01 True 17sNGINX Ingress リソースオブジェクトを作成します。
バージョン 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バージョン 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を実行して証明書の処理プロシージャを表示します。次のコマンドを実行して、Secret を表示します。
kubectl get secret ingress-tls想定される出力：
NAME TYPE DATA AGE ingress-tls kubernetes.io/tls 2 2mWeb ブラウザーで、
https://[your_domain_name]を入力して、設定したドメイン名にアクセスします。
HTTP から HTTPS へのリダイレクト
NGINX Ingress の nginx.ingress.kubernetes.io/ssl-redirect アノテーションを使用して、HTTP から HTTPS へのリダイレクトを強制できます。以下は例です：
バージョン 1.19 以降のクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true" # HTTP トラフィックを HTTPS に強制的にリダイレクトします。バージョン 1.19 以前のクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true" # HTTP トラフィックを HTTPS に強制的にリダイレクトします。