NGINX Ingressは、Kubernetesクラスター内のサービスへの外部アクセスを管理するためのレイヤー7負荷分散を提供するAPIオブジェクトです。 NGINX Ingressを使用すると、外部アクセス用のURLの設定、リクエストのURLパスの書き換え、HTTPSサービスの設定、カナリアリリースの実行を行うことができます。 このトピックでは、安全なデータ送信の設定、相互TLS認証の設定、正規表現の使用によるドメイン名の指定、ワイルドカードドメイン名の使用、無料のTLS証明書の申請、その他の関連機能のカスタマイズ方法について説明します。
前提条件
Container Service for Kubernetes (ACK) クラスターが作成されました。 詳細については、「ACK管理クラスターの作成」をご参照ください。
NGINX Ingressコントローラーがクラスターにインストールされ、期待どおりに実行されます。 詳細については、「NGINX Ingressコントローラーの管理」をご参照ください。
kubectlクライアントがクラスターに接続されています。 詳細については、「手順2: クラスター資格情報の種類の選択」をご参照ください。
配置とサービスが作成されます。 詳細については、「方法2: kubectlを使用してNGINX Ingressを作成する」をご参照ください。
NGINXの設定
ACKでNGINX Ingressコントローラーを設定するために使用されるメソッドは、オープンソースバージョンのコンポーネントと完全に互換性があります。 設定方法の詳細については、「NGINX設定」をご参照ください。
次の設定方法がサポートされています。
注釈: 各NGINX IngressのYAMLテンプレートで注釈を変更できます。 アノテーションは個々のNGINX Ingressに有効です。 詳細については、「注釈」をご参照ください。
ConfigMap: kube-system/nginx-configuration ConfigMapを変更して、すべてのNGINX Ingressを設定できます。 詳細については、「ConfigMaps」をご参照ください。
カスタムNGINXテンプレート: 上記の方法で要件を満たせない場合は、NGINX IngressコントローラーのNGINXテンプレートをカスタマイズできます。 詳細については、「カスタムNGINXテンプレート」をご参照ください。
URLリダイレクトの設定
NGINX Ingressコントローラーを設定すると、NGINX Ingressコントローラーはリクエストの完全なパスに基づいてリクエストを転送します。 たとえば、NGINX Ingressコントローラーは、/service1/api宛てのリクエストをバックエンドポッドの /service1/api/ に転送します。 バックエンドサービスのパスが /apiの場合、バックエンドサービスのパスが要求されたパスと異なるため、404ステータスコードが返されます。 この場合、nginx.ingress.kubernetes.io/rewrite-target
アノテーションを設定して、要求されたパスを使用するパスに書き換えることができます。
次のテンプレートを使用してNGINX Ingressを作成します。
Kubernetes 1.19以降を実行するクラスター
cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: foo.bar.com
namespace: default
annotations:
# URL redirection.
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- host: foo.bar.com
http:
paths:
# If the version of the Ingress controller is 0.22.0 or later, you must use regular expressions to specify paths and use the regular expressions together with capture groups in the rewrite-target annotation.
- path: /svc(/|$)(.*)
backend:
service:
name: web1-service
port:
number: 80
pathType: ImplementationSpecific
EOF
Kubernetes 1.19以前を実行するクラスター
cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: foo.bar.com
namespace: default
annotations:
# URL redirection.
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- host: foo.bar.com
http:
paths:
# If the version of the Ingress controller is 0.22.0 or later, you must use regular expressions to specify paths and use the regular expressions together with capture groups in the rewrite-target annotation.
- path: /svc(/|$)(.*)
backend:
serviceName: web1-service
servicePort: 80
EOF
NGINXサービスにアクセスします。
次のコマンドを実行して、
ADDRESS
の値を取得します。kubectl get ingress
期待される出力:
NAME CLASS HOSTS ADDRESS PORTS AGE foo.bar.com ngin x 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
: このアノテーションは、カスタム設定をサーバー設定ブロックに追加します。nginx.ingress.kubernetes.io/configuration-snippet
: このアノテーションは、カスタム設定をLocation設定ブロックに追加します。
これらの注釈は、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 /# Modify the pod name based on your business requirements
次に、nginx.confファイルの設定例を示します。
# start server foo.bar.com
server {
server_name foo.bar.com ;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
# The server-snippet configuration.
rewrite ^/v4/(.*)/card/query http://foo.bar.com/v5/#!/card/query permanent;
...
# The configuration-snippet configuration.
rewrite ^/v6/(.*)/card/query http://foo.bar.com/v7/#!/card/query permanent;
...
}
# end server foo.bar.com
さらに、スニペット
は一部のグローバル設定をサポートしています。 詳細については、「server-snippet」をご参照ください。
書き換え
ルールの使用方法の詳細については、「NGINX公式ドキュメントの書き換えルールの説明」をご参照ください。
IngressルールのTLS証明書の設定
NGINX Ingress設定を設定して、WebサイトのTLS証明書を指定できます。
証明書を準備します。
説明証明書に関連付けられているドメイン名は、指定したホストと同じである必要があります。 それ以外の場合、NGINX IngressコントローラはTLS証明書をロードできません。
次のコマンドを実行して、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"
次のコマンドを実行して、Kubernetes Secretを作成します。
証明書と秘密鍵を使用して、tls-test-ingressという名前のシークレットを作成します。 シークレットは、Ingressを作成するときに参照されます。
kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt
次のコマンドを実行してIngressを作成し、tlsフィールドを使用して前の手順で作成したSecretを参照します。
Kubernetes 1.19以降を実行するクラスター
cat <<EOF | kubectl create -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: test-test-ingress spec: # Reference the TLS certificate. tls: - hosts: - foo.bar.com # The domain name associated with the TLS certificate. secretName: tls-test-ingress rules: - host: tls-test-ingress.com http: paths: - path: /foo backend: service: name: web1-svc port: number: 80 pathType: ImplementationSpecific EOF
1.19より前のバージョンのKubernetesを実行するクラスター
cat <<EOF | kubectl create -f- apiVersion: networking.k8s.io/v1beta1 kind: Ingress メタデータ: 名前: test-test-ingress spec: # TLS証明書を参照します。 tls: - hosts: -foo.bar.com# TLS証明書に関連付けられているドメイン名。 secretName: tls-test-ingress rules: -host: tls-test-ingress.com http: paths: - path: /foo backend: serviceName: web1-svc servicePort: 80 EOF
Ingressの作成後、
ホスト
TLSを使用してデータ送信を保護する前に、ファイルを指定するか、実際のドメイン名を指定します。https://tls-test-ingress.com/foo
を使用して、web1-svc
サービスにアクセスできます。
相互TLS認証の設定
NGINX Ingressコントローラは、相互TLS認証をサポートします。 特定のシナリオで接続のセキュリティを確保するために、サーバーとクライアント間で相互TLS認証を設定することができます。
次のコマンドを実行して、自己署名認証局 (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 '/C N=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以降を実行するクラスター
cat <<-EOF | kubectl apply -f - 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 EOF
1.19より前のバージョンのKubernetesを実行するクラスター
cat <<-EOF | kubectl apply -f - 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 EOF
期待される出力:
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アドレスを取得した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><em>Thank you for using nginx.</em></p> </body> </html>
サービスからバックエンドコンテナへのHTTPSリクエストの転送
デフォルトでは、NGINX IngressコントローラはHTTPリクエストをバックエンドコンテナに転送します。 バックエンドサービスがHTTPSを使用している場合、NGINX. Ingress. kubernetes.io/backend-protocol: "HTTPS"
アノテーションを追加することで、nginx ingressコントローラーを設定してHTTPSリクエストをバックエンドコンテナに転送できます。
次のテンプレートは、NGINX Ingressの設定を示しています。
Kubernetes 1.19以降を実行するクラスター
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: backend-https
annotations:
# Note: You must set the backend protocol to 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より前のバージョンのKubernetesを実行するクラスター
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
メタデータ:
名前: backend-https
アノテーション:
# 注: バックエンドプロトコルを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
アノテーションを追加することで、ingressが正規表現をサポートできるようにすることができます。
NGINX Ingressを作成します。 次の例では、ドメイン名は正規表現
~ ^ www\.\d +\.example\.com
に設定されています。Kubernetes 1.19以降を実行するクラスター
cat <<-EOF | kubectl apply -f - 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 EOF
1.19より前のバージョンのKubernetesを実行するクラスター
cat <<-EOF | kubectl apply -f - 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 EOF
NGINX Ingressコントローラーの設定を照会します。
次のコマンドを実行して、NGINX Ingressコントローラーにプロビジョニングされているポッドを照会します。
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
次のコマンドを実行して、異なるIngressルールを使用してサービスにアクセスします。
IP_ADDRESSを前の手順で取得したIPアドレスに置き換えます。
次のコマンドを実行して、
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にワイルドカードドメイン名 * . ingress-regex.com
を指定できます。
次のテンプレートを使用してNGINX Ingressを作成します。
Kubernetes 1.19以降を実行するクラスター
cat <<-EOF | kubectl apply -f - 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 EOF
1.19より前のバージョンのKubernetesを実行するクラスター
$ cat <<-EOF | kubectl apply -f - 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 EOF
次のコマンドを実行して、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-nameを、NGINX Ingressコントローラー用にプロビジョニングされているポッドの名前に置き換えます。
期待される出力:
# 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
次のコマンドを実行して、異なるIngressルールを使用してサービスにアクセスします。
IP_ADDRESSを前の手順で取得したIPアドレスに置き換えます。
次のコマンドを実行して、
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
アノテーションを使用してカナリアリリースを実行する
Ingressにアノテーションを追加することで、カナリアリリースを実装できます。 カナリアリリースを有効にするには、nginx.ingress.kubernetes.io/canary: "true"
アノテーションを追加する必要があります。 このセクションでは、さまざまなアノテーションを使用してカナリアリリースを実装する方法について説明します。
nginx.ingress.kubernetes.io/canary-weight
: このアノテーションでは、指定されたサービスに送信されるリクエストの割合を設定できます。 0から100までの整数を入力できます。nginx.ingress.kubernetes.io/canary-by-header
: このアノテーションにより、リクエストヘッダーに基づいてトラフィックを分割できます。header
値がalways
の場合、リクエストは指定されたcanary Serviceに配信されます。header
値がnever
の場合、リクエストは指定されたcanary Serviceに配信されません。header
の値が常にでもなく、絶対でもない場合、リクエストは、優先度の高い順に、これらのカナリアサービスの一致ルールに基づいて、他のカナリアサービスに配信されます。nginx.ingress.kubernetes.io/canary-by-header-value
およびnginx.ingress.kubernetes.io/canary-by-header
: リクエストのheader
およびheader-value
の値がアノテーションで指定された値と一致する場合、リクエストは指定されたcanary Serviceに配信されます。header
値が他の値に設定されている場合、リクエストは、優先度の高い順に、これらのカナリアサービスの他の一致ルールに基づいて他のカナリアサービスに配信されます。nginx.ingress.kubernetes.io/canary-by-cookie
: この注釈は、cookieベースのトラフィック分割を有効にします。cookie
の値が常に
の場合、リクエストは新しいサービスに配信されます。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
の場合、リクエストはカナリアサービスに配信されません。 ヘッダーが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ベースのカナリアリリースは、カスタム設定をサポートしていません。 cookieの値は、
always
またはnever
。異なるルールを使用するカナリアリリースは、ヘッダーベース> クッキーベース> 重みベースの順に有効になります。
cert-managerを使用して無料のTLS証明書を申請する
cert-managerは、クラウドネイティブ証明書の管理に使用されるオープンソースツールです。 Kubernetesクラスターでcert-managerを使用してTLS証明書を申請し、証明書の自動更新を有効にすることができます。 このセクションでは、cert-managerを使用して無料の証明書を申請し、証明書の自動更新を有効にする方法について説明します。
次のコマンドを実行して、cert-managerをデプロイします。
kubectl apply -f https://raw.githubusercontent.com/AliyunContainerService/serverless-k8s-examples/master/cert-manager/ask-cert-manager.yaml
説明上記のコマンドで参照されているYAMLテンプレートは、ACKクラスターでのみcert-managerをデプロイするために使用できます。 ACKクラスターにcert-managerをデプロイする方法の詳細については、「cert-managerを使用して無料のTLS証明書を申請する」をご参照ください。
次のコマンドを実行して、cert-manager用に作成されたポッドのステータスを照会します。
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を作成します。
cat <<EOF | kubectl apply -f - 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_name@gmail.com> # Replace the value with your email address. privateKeySecretRef: name: letsencrypt-http01 solvers: - http01: ingress: class: nginx EOF
次のコマンドを実行して、作成されたClusterIssuerを照会します。
kubectl get clusterissuer
期待される出力:
NAME READY AGE letsencrypt-prod-http01 True 17s
次のコマンドを実行してNGINX Ingressを作成します。
Kubernetes 1.19以降を実行するクラスター
cat <<EOF | kubectl apply -f - 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> # Replace the value with your domain name. secretName: ingress-tls rules: - host: <your_domain_name> # Replace the value with your domain name. http: paths: - path: / backend: service: name: <your_service_name> # Replace the value with the Service name. port: number: <your_service_port> # Replace the value with the Service port. pathType: ImplementationSpecific EOF
1.19より前のバージョンのKubernetesを実行するクラスター
cat <<EOF | kubectl apply -f - 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> # Replace the value with your domain name. secretName: ingress-tls rules: - host: <your_domain_name> # Replace the value with your domain name. http: paths: - path: / backend: serviceName: <your_service_name> # Replace the value with the Service name. servicePort: <your_service_port> # Replace the value with the Service port. EOF
説明テンプレートで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
https:[website domain name]
をブラウザのアドレスバーに入力し挿入して、指定したドメイン名にアクセスします。