ACK の高度な NGINX Ingress 機能とルールの設定 - ACK

NGINX Ingress は、Kubernetes の API オブジェクトであり、クラスター内の Service への外部アクセスを管理するためのレイヤー 7 負荷分散を提供します。本トピックでは、NGINX Ingress の高度な構成について説明します。具体的には、URL リダイレクト、書き換えルール、TLS 終端処理、相互 TLS 認証（mTLS）、HTTPS バックエンド転送、正規表現およびワイルドカードドメイン名の使用、カナリアリリース、および cert-manager を用いた無料 TLS 証明書の取得方法です。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

ACK クラスター。「ACK マネージドクラスターの作成」を参照してください。
NGINX Ingress コントローラーはインストール済みで実行中です。詳細については、「NGINX Ingress コントローラーの管理」をご参照ください。
kubectl がクラスターに接続済みであること。詳細については、「クラスター認証情報を取得し、kubectl で接続する」をご参照ください。
クラスターにデプロイされたデプロイメントとサービスです。「kubectl を使用した NGINX Ingress の作成」を参照してください。

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 rewrite モジュールのドキュメント」をご参照ください。

Ingress への TLS 証明書の構成

Ingress に TLS 証明書をアタッチすることで、ご利用のサービスで HTTPS を有効化できます。

TLS 証明書内のドメイン名は、Ingress ルール内の host 値と一致している必要があります。不一致の場合、NGINX Ingress コントローラーは証明書を読み込めません。

ステップ 1：証明書およびシークレットの作成

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

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 シークレットに格納します。
```
kubectl create secret tls tls-test-ingress --key tls.key --cert tls.crt
```

ステップ 2：シークレットを参照する 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  # 上記で作成したシークレットを参照します。
  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

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

相互 TLS 認証の構成

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

mTLS はホスト単位で適用されます。同一ホスト内の個々のパスに対して異なる mTLS 設定を構成することはできません。

mTLS を制御する 4 つのアノテーションは以下のとおりです。

アノテーション	説明
`nginx.ingress.kubernetes.io/auth-tls-verify-client`	クライアント証明書の検証を有効化します。許容値：`"on"`（有効な証明書が必要 — 欠落時は HTTP 400 を返却）、`"optional"`（証明書を要求するが必須ではない）、または `"off"`（検証を無効化）。
`nginx.ingress.kubernetes.io/auth-tls-secret`	クライアント証明書の検証に使用される CA 証明書を含むシークレットの `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 およびサーバー証明書用のシークレットを作成

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 証明書を含むシークレット
`<your-service-name>`	バックエンド Service の名前
`<your-service-port>`	バックエンド Service がリッスンするポート

ドメイン名に対する正規表現の使用

デフォルトでは、Kubernetes は Ingress の host フィールドにおける正規表現をサポートしていません。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" アノテーションを指定する必要があります。

以下のアノテーションにより、トラフィックの分割方法を制御できます。ルールは次の順序で評価されます：ヘッダーに基づく → クッキーに基づく → 重みに基づく。

アノテーション	値	条件が満たされない場合の動作
`nginx.ingress.kubernetes.io/canary-weight`	整数（0～100、パーセンテージ）	該当なし — 最終的なフォールバックとして機能
`nginx.ingress.kubernetes.io/canary-by-header`	任意のヘッダー名	ヘッダーが存在しないか、`always` および `never` のいずれとも一致しない場合、クッキーまたは重みに基づくルールにフォールスルー
`nginx.ingress.kubernetes.io/canary-by-header-value`	カスタム文字列（`canary-by-header` と併用）	ヘッダー値が一致しない場合、優先順位に基づいて次のルールにフォールスルー
`nginx.ingress.kubernetes.io/canary-by-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"

クッキーに基づくカナリアリリース

ヘッダーのルールが一致せず、クッキー 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"

クッキー値は always または never のみをサポートします。カスタムクッキー値は非対応です。

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

cert-manager を用いた無料 TLS 証明書の申請

cert-manager は、Kubernetes におけるクラウドネイティブ証明書の管理を目的としたオープンソースツールです。Let's Encrypt からの TLS 証明書の申請および自動更新を自動的に処理します。

このセクションのデプロイ YAML は ACK クラスター向けに構成されています。一般の Kubernetes クラスターの場合は、「cert-manager の公式インストールガイド」に従ってください。

ステップ 1：cert-manager のデプロイ

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

ステップ 2：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

ステップ 3：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

ステップ 4：ClusterIssuer の準備完了確認

kubectl get clusterissuer

期待される出力：

NAME                         READY   AGE
letsencrypt-prod-http01      True    17s

ステップ 5：証明書を要求する 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:
    - <your_domain_name>
    secretName: ingress-tls
  rules:
  - host: <your_domain_name>
    http:
      paths:
      - path: /
        backend:
          serviceName: <your_service_name>
          servicePort: <your_service_port>
EOF

ステップ 6：証明書発行の監視

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

ステップ 7：証明書シークレットの検証

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:高度な Ingress 構成

前提条件

NGINX 構成方法

URL リダイレクトの構成

書き換えルールの構成

Ingress への TLS 証明書の構成

相互 TLS 認証の構成

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

ドメイン名に対する正規表現の使用

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

アノテーションを用いたカナリアリリースの実施

cert-manager を用いた無料 TLS 証明書の申請

ステップ 1：cert-manager のデプロイ

ステップ 2：cert-manager Pod の実行状態の確認

ステップ 3：ClusterIssuer の作成

ステップ 4：ClusterIssuer の準備完了確認

ステップ 5：証明書を要求する Ingress の作成

ステップ 6：証明書発行の監視

ステップ 7：証明書シークレットの検証

次のステップ