ACK の高度な NGINX Ingress 機能とルールの設定 - ACK - Alibaba Cloud - Container Service for Kubernetes

NGINX Ingress の URL リライト、TLS、相互 TLS 認証 (mTLS)、カナリアリリース、cert-manager を設定します。

前提条件

次の項目を確認してください。

ACK マネージドクラスターが作成されます。
NGINX Ingress コントローラーがインストールされ、実行中です。
kubectlがクラスターに接続されている。
Deployment と Service はクラスターにデプロイされます。

NGINX の設定方法

ACK の NGINX Ingress コントローラーは、オープンソースのアップストリームと完全に互換性があります。次の 3 つの方法が利用可能です。

方法	スコープ	リファレンス
アノテーション	個別の Ingress — 特定の Ingress YAML を変更	アノテーション
ConfigMap	すべての Ingress — `kube-system/nginx-configuration` ConfigMap を変更	ConfigMap
カスタム NGINX テンプレート	完全な制御 — 他の方法では不十分な場合に NGINX テンプレートをカスタマイズ	カスタム NGINX テンプレート

URL リダイレクトの設定

デフォルトでは、NGINX Ingress コントローラーは完全なパスを使用してリクエストを転送します。バックエンドのパスが異なる場合は、nginx.ingress.kubernetes.io/rewrite-target アノテーションを使用してパスを書き換えます。

NGINX Ingress コントローラー 0.22.0 以降では、パスにキャプチャグループを含む正規表現を使用し、それを rewrite-target アノテーションと組み合わせて使用する必要があります。

ご利用のクラスターの Kubernetes バージョンに応じたテンプレートを適用してください。

Kubernetes 1.19 以降

cat <<-EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: foo.bar.com
  namespace: default
  annotations:
    # リクエストパスの書き換え：/svc プレフィックスを削除し、残りの部分をバックエンドに転送します。
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - 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:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /svc(/|$)(.*)
        backend:
          serviceName: web1-service
          servicePort: 80
EOF

設定の確認：

Ingress の IP アドレスを取得します。

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
```
/svc プレフィックスが削除され、バックエンドは /foo を受信します。

書き換えルールの設定

nginx.ingress.kubernetes.io/rewrite-target アノテーションは、基本的なパスの書き換えを処理します。より高度な書き換えを行うには、スニペットアノテーションを使用して、カスタムの NGINX 設定を直接挿入します。

アノテーション	対象ブロック	ユースケース
`nginx.ingress.kubernetes.io/server-snippet`	`server {}` ブロック	サーバーレベルの書き換え、リダイレクト
`nginx.ingress.kubernetes.io/configuration-snippet`	`location {}` ブロック	ロケーションレベルの書き換え、カスタムヘッダー

例：

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.conf でスニペットを確認します。

kubectl exec nginx-ingress-controller-xxxxx --namespace kube-system -- cat /etc/nginx/nginx.conf
# xxxxx を実際の Pod 名に置き換えてください。

server-snippet は server {} ブロックに、configuration-snippet は location {} ブロックに表示されます。

# 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

グローバルなスニペットは、ConfigMap の server-snippet を使用して設定します。rewrite の完全な構文については、NGINX 書き換えモジュールのドキュメントをご参照ください。

Ingress 用の TLS 証明書の設定

Ingress に TLS 証明書をアタッチして HTTPS を有効にします。

TLS 証明書のドメインは、Ingress の host の値と一致する必要があります。一致しない場合、コントローラーは証明書をロードできません。

ステップ 1：証明書と Secret の作成

自己署名証明書と秘密鍵を生成します。

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 に保存します。

kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt

ステップ 2：Secret を参照する Ingress の作成

Kubernetes 1.19 以降

cat <<-EOF | kubectl create -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  tls:
  - hosts:
    - foo.bar.com
    secretName: tls-test-ingress  # 上記で作成した Secret を参照します。
  rules:
  - host: tls-test-ingress.com
    http:
      paths:
      - path: /foo
        backend:
          service:
            name: web1-svc
            port:
              number: 80
        pathType: ImplementationSpecific
EOF

Kubernetes 1.19 以前

cat <<-EOF | kubectl create -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-test-ingress
spec:
  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
EOF

hosts ファイルまたは DNS を更新して、tls-test-ingress.com が Ingress の IP アドレスに解決されるようにします。サービスには https://tls-test-ingress.com/foo でアクセスします。

相互 TLS 認証の設定

相互 TLS 認証 (mTLS) では、TLS ハンドシェイク中にサーバーとクライアントの両方が証明書を提示する必要があります。

mTLS はホストごとに適用されます。同じホスト配下の異なるパスに別々の設定をすることはできません。

4 つのアノテーションで mTLS を制御します。

アノテーション	説明
`nginx.ingress.kubernetes.io/auth-tls-verify-client`	クライアント証明書の検証を有効にします。値：「`on`」(有効な証明書が必須。ない場合は HTTP 400)、「`optional`」(要求するが必須ではない)、「`off`」(無効)。
`nginx.ingress.kubernetes.io/auth-tls-secret`	クライアント検証用の CA 証明書を含む Secret の `namespace/secretName`。
`nginx.ingress.kubernetes.io/auth-tls-verify-depth`	クライアント証明書チェーンの最大深度。デフォルト：`1`。
`nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream`	「`true`」の場合、クライアント証明書をリクエストヘッダーに入れてバックエンドに転送します。

ステップ 1：自己署名証明局 (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'

ステップ 2：サーバー証明書の作成

証明書署名要求 (CSR) を生成します。

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

CA を使用して CSR に署名し、サーバー証明書を生成します。

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

ステップ 3：クライアント証明書の作成

クライアントの CSR を生成します。

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

CA を使用してクライアントの CSR に署名します。

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

ステップ 4：すべての証明書ファイルが存在することの確認

ls

期待される出力：

ca.crt  ca.key  client.crt  client.csr  client.key  server.crt  server.csr  server.key

ステップ 5：CA 証明書とサーバー証明書用の Secret の作成

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

ステップ 6：mTLS アノテーションを使用して 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

Kubernetes 1.19 以前

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

ステップ 7：/etc/hosts ファイルの作成または更新

Ingress の IP アドレスを取得し、/etc/hosts に追加します。

kubectl get ing

期待される出力：

NAME         HOSTS         ADDRESS        PORTS     AGE
nginx-test   foo.bar.com   39.102.XX.XX   80, 443   4h42m

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
```
期待される出力：デフォルトの nginx ウェルカムページ (Welcome to nginx!)。

バックエンドコンテナへの HTTPS リクエストの転送

デフォルトでは、NGINX Ingress コントローラーは HTTP をバックエンドに転送します。HTTPS バックエンドの場合は、nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" アノテーションを追加します。

Kubernetes 1.19 以降

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backend-https
  annotations:
    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:
    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>

プレースホルダーを実際の値に置き換えてください。

プレースホルダー	説明
`<your-host-name>`	ご利用のドメイン名
`<your-secret-cert-name>`	TLS 証明書を含む Secret
`<your-service-name>`	ご利用のバックエンド Service 名
`<your-service-port>`	ご利用のバックエンド Service ポート

ドメイン名での正規表現の使用

デフォルトでは、Kubernetes は Ingress のホストフィールドで正規表現をサポートしていません。nginx.ingress.kubernetes.io/server-alias アノテーションを使用して、正規表現ベースのサーバーエイリアスを nginx.conf に追加します。

ステップ 1：正規表現サーバーエイリアスを持つ Ingress の作成

この例では、www.<digits>.example.com および abc.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

Kubernetes 1.19 以前

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

ステップ 2：nginx.conf でエイリアスがアクティブであることの確認

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

生成された設定を検査します。

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

期待される出力 — server_name ディレクティブにはすべてのエイリアスがリストされます：

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

ステップ 3：Ingress の IP アドレスの取得

kubectl get ing

期待される出力：

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

ステップ 4：一致するすべてのホスト名のテスト

前のステップで取得したアドレスで <IP_ADDRESS> を置き換えます。

curl -H "Host: foo.bar.com" <IP_ADDRESS>/foo        # /foo
curl -H "Host: www.123.example.com" <IP_ADDRESS>/foo # /foo
curl -H "Host: www.321.example.com" <IP_ADDRESS>/foo # /foo

ワイルドカードドメイン名の指定

NGINX Ingress は、ワイルドカードドメイン名をネイティブにサポートしています。この例では、ingress-regex.com の任意のサブドメインに一致します。

ステップ 1：ワイルドカードホストを持つ 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

Kubernetes 1.19 以前

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

ステップ 2：nginx.conf での 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> を実際の Pod 名に置き換えてください。

期待される出力 (古いコントローラーバージョンの場合)：

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

期待される出力 (最新のコントローラーバージョンの場合)：

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

ステップ 3：Ingress の IP アドレスの取得

kubectl get ing

期待される出力：

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

ステップ 4：ワイルドカードマッチングのテスト

前のステップで取得したアドレスで <IP_ADDRESS> を置き換えます。

curl -H "Host: abc.ingress-regex.com" <IP_ADDRESS>/foo   # /foo
curl -H "Host: 123.ingress-regex.com" <IP_ADDRESS>/foo   # /foo
curl -H "Host: a1b1.ingress-regex.com" <IP_ADDRESS>/foo  # /foo

アノテーションを使用したカナリアリリース

カナリアリリースは、トラフィックのサブセットを新しいサービスバージョンにルーティングします。すべてのカナリア設定では、カナリア Ingress に nginx.ingress.kubernetes.io/canary: "true" を指定する必要があります。

これらのアノテーションはトラフィック分割を制御し、ヘッダーベース → Cookie ベース → 重みベースの順で評価されます。

アノテーション	値	条件が満たされない場合の動作
`nginx.ingress.kubernetes.io/canary-weight`	整数 0–100 (パーセンテージ)	N/A — 最終的なフォールバックとして機能
`nginx.ingress.kubernetes.io/canary-by-header`	任意のヘッダー名	ヘッダーが存在しないか、`always` または `never` のいずれにも一致しない場合、Cookie ベースまたは重みベースのルールにフォールスルーします
`nginx.ingress.kubernetes.io/canary-by-header-value`	カスタム文字列 (`canary-by-header` と共に使用)	ヘッダー値が一致しない場合、優先順位に従って次のルールにフォールスルーします
`nginx.ingress.kubernetes.io/canary-by-cookie`	Cookie 名	Cookie の値は `always` または `never` である必要があります — カスタム値はサポートされていません

重みベースのカナリアリリース

トラフィックの 20% をカナリア Service にルーティングします。

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 の場合、トラフィックはカナリアにルーティングされます。never の場合、カナリアはスキップされます。その他の値は重み (50%) にフォールバックします。

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 と等しい場合、トラフィックはカナリアにルーティングされます。その他の値は重み (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"
    nginx.ingress.kubernetes.io/canary-by-header: "ack"
    nginx.ingress.kubernetes.io/canary-by-header-value: "alibaba"

Cookie ベースのカナリアリリース

ヘッダールールが一致せず、Cookie hangzhou_region が always の場合、トラフィックはカナリアにルーティングされます。その他の場合は重み (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"
    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 である必要があります。カスタム値はサポートされていません。

詳細については、「NGINX Ingress コントローラーを使用してカナリアリリースとブルーグリーンリリースを実装する」をご参照ください。

cert-manager を使用した無料 TLS 証明書の取得

cert-manager は、Kubernetes 内で Let's Encrypt を通じて TLS 証明書のプロビジョニングと更新を自動化します。

この YAML は、ASK (Serverless Kubernetes) クラスターを対象としています。ACK クラスターについては、cert-manager インストールガイドをご参照ください。

cert-manager のデプロイ

kubectl apply -f https://raw.githubusercontent.com/AliyunContainerService/serverless-k8s-examples/master/cert-manager/ask-cert-manager.yaml

cert-manager 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 の作成

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>  # ご利用のメールアドレスに置き換えてください。
    privateKeySecretRef:
      name: letsencrypt-http01
    solvers:
    - http01:
        ingress:
          class: nginx
EOF

ClusterIssuer の準備完了の確認

kubectl get clusterissuer

期待される出力：

NAME                         READY   AGE
letsencrypt-prod-http01      True    17s

証明書を要求する Ingress の作成

ドメイン名は、次の条件を満たす必要があります。

64 文字以下であること
ワイルドカードドメイン名ではないこと
HTTP 経由でパブリックにアクセス可能であること (ACME HTTP-01 チャレンジに必須)

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>       # ご利用のドメイン名に置き換えてください。
    secretName: ingress-tls
  rules:
  - host: <your_domain_name>   # ご利用のドメイン名に置き換えてください。
    http:
      paths:
      - path: /
        backend:
          service:
            name: <your_service_name>   # ご利用の Service 名に置き換えてください。
            port:
              number: <your_service_port>  # ご利用の Service ポートに置き換えてください。
        pathType: ImplementationSpecific
EOF

Kubernetes 1.19 以前

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:
    - <お使いのドメイン名>
    secretName: ingress-tls
  rules:
  - host: <お使いのドメイン名>
    http:
      paths:
      - path: /
        backend:
          serviceName: <お使いのサービス名>
          servicePort: <お使いのサービスポート>
EOF

証明書発行の監視

kubectl get cert

期待される出力 (発行には数分かかる場合があります)：

NAME          READY   SECRET        AGE
ingress-tls   True    ingress-tls   52m

READY が True でない場合は、証明書を検査して詳細を確認します。

kubectl describe cert ingress-tls

次のような Events セクションを探します。

Events:
  Type    Reason     Age    From          Message
  ----    ------     ---    ----          -------
  Normal  Requested  64s    cert-manager  Created new CertificateRequest resource "ingress-tls-xxxxx"
  Normal  Issuing    40s    cert-manager  The certificate has been successfully issued

証明書 Secret の確認

kubectl get secret ingress-tls

期待される出力：

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

https://<your_domain_name> にアクセスして、HTTPS がアクティブであることを確認します。

Container Service for Kubernetes:NGINX Ingress の高度な機能の設定

前提条件

NGINX の設定方法

URL リダイレクトの設定

書き換えルールの設定

Ingress 用の TLS 証明書の設定

相互 TLS 認証の設定

バックエンドコンテナへの HTTPS リクエストの転送

ドメイン名での正規表現の使用

ワイルドカードドメイン名の指定

アノテーションを使用したカナリアリリース

cert-manager を使用した無料 TLS 証明書の取得

cert-manager のデプロイ

cert-manager Pod の実行確認

ClusterIssuer の作成

ClusterIssuer の準備完了の確認

証明書を要求する Ingress の作成

証明書発行の監視

証明書 Secret の確認

次のステップ