Container Service for Kubernetes:NGINX Ingress に関するよくある質問

NGINX Ingress Controller の旧バージョンにおける既知の問題

旧バージョンには以下の既知の問題があります。安定性を確保するために、最新バージョンへのアップグレードを推奨します。

• NGINX Ingress (v1.1.0) が時々クラッシュする

• ワーカーのセグメンテーション違反 (v0.44.0)

• Ingress の defaultBackend パラメーター値が NGINX Ingress Controller のグローバル設定を上書きする

  影響を受けるバージョン：1.2.1-aliyun.1 以前。

  解決策：NGINX Ingress Controller をバージョン 1.5.1-aliyun.1 以降にアップグレードします。

• nginx-cfg-xx の一時設定ファイルがクリアされず、ディスクがいっぱいになる可能性がある

  影響を受けるバージョン：1.10.2-aliyun.1 以前。

  解決策：NGINX Ingress Controller をバージョン 1.10.4-aliyun.1 以降にアップグレードします。

• 2 GB を超えるファイルのアップロード失敗

  原因：client-body-buffer-size の値が 32 ビット整数のストレージ上限を超えているためです。

  解決策：client-body-buffer-size を 200M のような小さい値に設定します。

サポートされている TLS バージョン

Ingress-nginx は TLS 1.2 と TLS 1.3 をサポートしています。1.2 より前の TLS バージョンを使用しているクライアントは、ハンドシェイクエラーが発生する可能性があります。

ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA"
ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"

リクエストヘッダーはバックエンドサーバーに渡されるか

enable-underscores-in-headers: true

HTTPS バックエンドサーバーへのリクエスト転送方法

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: xxxx
  annotations:
    # バックエンドサーバーが使用するプロトコルとして HTTPS を指定する必要があります。
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

レイヤー 7 でクライアント IP アドレスを渡す方法

デフォルトでは、ingress-nginx は X-Forward-For および X-Real-IP ヘッダーを追加してクライアント IP アドレスを渡します。ただし、クライアントが既にこれらのヘッダーを含んでいる場合、バックエンドサーバーは元のクライアント IP を取得できません。

compute-full-forwarded-for: "true"
forwarded-for-header: "X-Forwarded-For"
use-forwarded-headers: "true"

proxy-real-ip-cidr:  "0.0.0.0/0,::/0"  

HSTS の設定方法

サポートされている書き換えルール

NGINX Ingress Controller のアップグレード中に更新されるリソース

他のすべてのリソース設定はデフォルト値にリセットされます。たとえば、deployment.apps/nginx-ingress-controller リソースの replicas のデフォルト値は 2 です。NGINX Ingress Controller をアップグレードする前にこの replicas を 5 に設定した場合、アップグレード後にデフォルト値の 2 に戻ります。

レイヤー 4 リスナーからレイヤー 7 リスナーへの切り替え方法

1. 証明書を作成し、証明書 ID (cert-id) を記録します。詳細については、「Certificate Management Service の証明書を使用する」をご参照ください。

2. アノテーションを使用して、Ingress が使用する LoadBalancer リスナーをレイヤー 4 からレイヤー 7 に変更します。

   1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスター をクリックします。

   2. クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、ネットワーク > サービス を選択します。

   3. [サービス] ページの上部で、[名前空間] を kube-system に設定します。ingress-nginx-lb Service を見つけ、[アクション] 列の [YAML の編集] をクリックします。

   4. [YAML の編集] パネルで、https (ポート 443) という名前のポートの targetPort を 80 に更新します。

        - name: https
          port: 443
          protocol: TCP
          targetPort: 80 # ポート 443 の targetPort を 80 に設定します。

      annotations フィールドに以下を追加し、[OK] をクリックします。

      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80,https:443"
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}"

3. 結果を検証します。

   1. [サービス] ページで、ingress-nginx-lb サービスを探し、[タイプ] 列の アイコンをクリックします。

   2. [リスナー] タブをクリックします。[フロントエンドプロトコル/ポート] 列に HTTP:80 と HTTPS:443 の両方が表示されていれば、LoadBalancer のリスナーはレイヤー 4 からレイヤー 7 に変更されています。

ack-ingress-nginx で既存の SLB インスタンスを使用する方法

1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、マーケットプレイス > マーケットプレイス を選択します。

2. [アプリカタログ] タブで、クラスターのバージョンに応じて ack-ingress-nginx または ack-ingress-nginx-v1 を選択します。

   • クラスターが Kubernetes 1.20 以前を実行している場合は、ack-ingress-nginx を選択します。

   • クラスターが Kubernetes 1.20 より後のバージョンを実行している場合は、ack-ingress-nginx-v1 を選択します。

3. Ingress Controller をデプロイします。手順については、「トラフィック分離のために複数の Ingress Controller をデプロイする」をご参照ください。

   [パラメーター] ウィザードページで、次の操作を行います。

   1. controller.service.annotations セクションのすべてのアノテーションを削除します。

      

   2. 新しいアノテーションを追加します。

      # 使用したい SLB インスタンスを指定します。
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALANCER_ID}"
      # リスナーを上書きします。
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"

      

4. [OK] をクリックして Ingress Controller をデプロイします。

5. Ingress Controller がデプロイされた後、Ingress クラスを設定します。手順については、「トラフィック分離のために複数の Ingress Controller をデプロイする」をご参照ください。

nginx-ingress-controller の TCP リスナーを有効にする方法

デフォルトでは、Ingress は外部の HTTP および HTTPS リクエストのみをクラスター内の Service に転送します。ingress-nginx を設定して、関連する ConfigMap で指定された TCP ポートで受信した外部 TCP リクエストの転送を有効にすることができます。

NGINX Ingress Controller はどのように TLS 証明書をリクエストにマッチングさせるか

Kubernetes の Ingress リソースでは、TLS 証明書は spec.tls フィールドで定義されますが、それが適用されるホスト名は spec.rules.host フィールドで指定されます。

NGINX Ingress Controller はこれらのルールを処理し、各ホスト名とそれに対応する証明書のマッピングを内部の Lua テーブルに保存します。

リクエストフロー

1. クライアントが HTTPS リクエストを開始すると、TLS ハンドシェイクのサーバー名表示 (SNI) 拡張にリクエストされたホスト名を含めます。

2. NGINX Ingress Controller はこのリクエストを受信し、certificate.call() 関数を使用して Lua マッピングテーブルで SNI ホスト名を検索します。

3. 一致する証明書が見つかった場合、それがクライアントに提示され、TLS ハンドシェイクが完了します。

4. リクエストされたホスト名に一致する証明書が見つからない場合、コントローラーはデフォルトの自己署名 fake 証明書を提示します。

このロジックを実装する関連する NGINX 設定を以下に示します。

    ## Start server _
    server {
        server_name _ ;
        listen 80 default_server reuseport backlog=65535 ;
        listen [::]:80 default_server reuseport backlog=65535 ;
        listen 443 default_server reuseport backlog=65535 ssl http2 ;
        listen [::]:443 default_server reuseport backlog=65535 ssl http2 ;
        set $proxy_upstream_name "-";
        ssl_reject_handshake off;
        ssl_certificate_by_lua_block {
            certificate.call()
        }
   ...
   }
    
    
    ## Start server www.example.com
    server {
        server_name www.example.com ;
        listen 80  ;
        listen [::]:80  ;
        listen 443  ssl http2 ;
        listen [::]:443  ssl http2 ;
        set $proxy_upstream_name "-";
        ssl_certificate_by_lua_block {
            certificate.call()
        }
    ...
    }

ingress-nginx は、証明書のステータス検証のパフォーマンスを向上させる機能である Online Certificate Status Protocol (OCSP) ステープリングをサポートしています。この機能を有効にすると、クライアントは証明書の失効ステータスを確認するために認証局 (CA) に直接問い合わせる必要がなくなります。これにより、証明書の検証時間が短縮され、初期接続の全体的な速度が向上します。詳細については、「OCSP ステープリングの設定」をご参照ください。

NGINX Ingress に一致する証明書がない場合の対処法

TLS 証明書とその秘密鍵が一致しない場合、または証明書のドメイン名がクライアントが使用するホスト名と一致しない場合、HTTPS アクセスエラーが発生する可能性があります。この問題をトラブルシューティングするには、次の操作を実行してください。

• 証明書と秘密鍵が一致することを確認する

  次のコマンドを実行して、Kubernetes Secret から証明書と秘密鍵を抽出し、それらの暗号化モジュラスを比較します。

  # <YOUR-SECRET-NAME> と <SECRET-NAMESPACE> を実際の値に置き換えてください
  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.crt}' | base64 -d > /tmp/tls.crt && \ # <YOUR-SECRET-NAME> を使用する Secret に置き換えてください。
  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.key}' | base64 -d > /tmp/tls.key && \
  
  # 証明書とキーのモジュラスの MD5 ハッシュを計算して比較します
  openssl x509 -noout -modulus -in /tmp/tls.crt | openssl md5 && \
  openssl rsa -noout -modulus -in /tmp/tls.key | openssl md5

  上記のコマンドは、証明書とキーを抽出してデコードし、それぞれ /tmp/tls.crt と /tmp/tls.key に保存します。その後、openssl コマンドが両方のファイルの公開モジュラスの MD5 ハッシュを計算します。

  2 つの結果のハッシュ値が同一でない場合、証明書と秘密鍵が一致していないことを意味します。これを修正するには、有効な一致するキーペアで Secret を更新する必要があります。

• 証明書がドメイン名と一致することを確認する

  次のコマンドを実行して証明書の内容を検査し、それがカバーするドメイン名を確認します。

  kubectl get secret  <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE>  -o jsonpath={.data."tls\.crt"} | base64 -d  | openssl x509  -text -noout

  コマンドからの出力を確認し、以下を検査します。

  • Subject：CN = example.com のような形式のコモンネーム (CN) フィールドを探します。

  • Subject Alternative Name (SAN)：DNS: エントリを探します。

  サービスへのアクセスに使用しているホスト名が CN または SAN エントリのいずれにもリストされていない場合、その証明書はそのドメインに対して有効ではないことを意味します。これを解決するには、正しいホスト名をカバーする新しい証明書を取得して設定する必要があります。

高トラフィック下で NGINX Pod がヘルスチェックに失敗する場合の対処法

背景

NGINX Ingress Controller のヘルスチェックは、ポート 10246 で NGINX プロセスによって公開される /healthz パスにアクセスすることで機能します。このチェックは、NGINX プロセスが正常であり、サービスが正しく実行されていることを確認します。

現象

ヘルスチェックが失敗すると、healthz エンドポイントに到達できないことを示す次のようなログエントリが表示されます。

I0412 11:01:52.581960       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:01:55 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:01:55.895683       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:02.582247       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:05 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:05.896126       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:12.582687       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:15 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:15.895719       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:22.582516       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:25 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:25.896955       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:28.983016       7 nginx.go:408] "NGINX process has stopped"
I0412 11:02:28.983033       7 sigterm.go:44] Handled quit, delaying controller exit for 10 seconds
I0412 11:02:32.582587       7 healthz.go:261] nginx-ingress-controller check failed: healthz
[-]nginx-ingress-controller failed: the ingress controller is shutting down
2024/04/12 11:02:35 Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
W0412 11:02:35.895853       7 nginx_status.go:171] unexpected error obtaining nginx status info: Get "http://127.0.0.1:10246/nginx_status": dial tcp 127.0.0.1:10246: connect: connection refused
I0412 11:02:38.986048       7 sigterm.go:47] "Exiting" code=0

原因

高トラフィック下では、NGINX ワーカープロセスが過負荷になり、CPU 使用率が非常に高くなる (時には 100% に近づく) ことがあります。システムがこのレベルのストレス下にあると、ヘルスチェックプローブにタイムリーに応答するためのリソースが不足し、失敗する可能性があります。

解決策

推奨される解決策は、NGINX Ingress Controller の Pod レプリカ数を増やすことです。これにより、トラフィック負荷が複数の Pod に分散され、単一インスタンスの CPU 負荷が軽減され、ヘルスチェックが成功するようになります。

cert-manager が証明書の発行に失敗する場合の対処法

この問題は、Web Application Firewall (WAF) が有効になっている場合に発生する可能性があります。WAF は、cert-manager がドメイン所有権を検証するために使用する HTTP01 リクエストを傍受またはブロックすることがあり、これにより証明書発行プロセスが正常に完了しなくなります。

これを解決するには、一時的に WAF を無効にして、HTTP-01 チャレンジが成功するようにします。

高トラフィック下で NGINX が大量のメモリを使用する理由

NGINX Ingress Controller がアップグレード中に停止した場合の対処法

現象

NGINX Ingress Controller の段階的ロールアウト (カナリアアップグレード) 中に、プロセスが検証フェーズでスタックし、先に進めなくなります。Operation is forbidden for task in a failed state のようなエラーメッセージが表示されることがあります。

原因

この問題は通常、アドオンのアップグレードタスクが事前に定義された 4 日間の有効期限を超えたためにシステムによって自動的にクリーンアップされた場合に発生します。この場合、問題を解決するには、アドオンのデプロイメント状態を手動でリセットする必要があります。

注意：アドオンがすでにアップグレードの最終段階である「リリース済み」フェーズに達している場合は、何もする必要はありません。現在のタスクがタイムアウトして自動的に終了するのを待つだけです。

手順

Deployment をリセットしてアップグレードを続行するには、次の手順に従ってください。

1. 次のコマンドを実行して、Deployment マニフェストを編集用に開きます。

   kubectl edit deploy -n kube-system  nginx-ingress-controller

2. エディターで、spec セクションの下にある次のフィールドを見つけ、以下のようにデフォルト値に戻します。

   • spec.minReadySeconds: 0

   • spec.progressDeadlineSeconds: 600

   • spec.strategy.rollingUpdate.maxSurge: 25%

   • spec.strategy.rollingUpdate.maxUnavailable: 25%

   

3. 変更を保存してエディターを終了します。

期待される結果

変更を保存すると、アドオンのアップグレードが自動的に再開され、古い Pod が置き換えられて段階的ロールアウトが完了します。

コントローラーバージョン 1.10 以降、チャンク転送エンコーディング (Transfer-Encoding: chunked) が機能しなくなった理由

現象

アプリケーションが HTTP ヘッダー Transfer-Encoding: chunked を設定しており、コントローラーのログに重複ヘッダーに関するエラーが表示されます。

原因

これは、v1.10 以降のコントローラーで使用されている基盤となる NGINX バージョンの更新に関連しています (NGINX 更新ログをご参照ください)。新しい NGINX バージョンでは、HTTP 応答の検証がより厳格になっています。バックエンドサービスが複数の Transfer-Encoding: chunked ヘッダーを返した場合、NGINX はその応答を無効として扱います。

解決策

バックエンドサービスが単一の Transfer-Encoding: chunked ヘッダーのみを返すようにしてください。詳細については、GitHub Issue #11162 をご参照ください。

IP 許可リスト/拒否リストによるアクセス制御の設定方法

NGINX Ingress v1.2.1 の defaultBackend に関する既知の問題

現象

Ingress リソースで defaultBackend を設定すると、デフォルトサーバーの defaultBackend 設定が誤って上書きされることがあります。

解決策

これは既知の問題です (GitHub Issue #8823 をご参照ください)。これを解決するには、NGINX Ingress Controller をバージョン 1.3 以降にアップグレードすることを推奨します。手順については、「NGINX Ingress Controller のアップグレード」をご参照ください。

curl を使用すると Connection reset by peer エラーが発生する理由

現象

curl を使用して HTTP 経由で外部の公開サービスにアクセスすると、curl: (56) Recv failure: Connection reset by peer というエラーが表示されます。

原因

これは通常、プレーンテキストの HTTP リクエストに、ネットワークの中継装置によって機密と見なされるキーワードが含まれている場合に発生し、接続がブロックまたはリセットされます。

解決策

Ingress ルートに TLS 証明書を設定し、すべての通信に HTTPS を使用してトラフィックが暗号化されるようにします。

パスマッチングの優先順位はどのように機能するか

NGINX の正規表現パスは定義された順に評価され、最初に一致したものが使用されます。より正確なパスマッチングを可能にするため、ingress-nginx はまずすべてのパスを長さの降順でソートし、それらを nginx.conf ファイルに location ブロックとして書き込みます。

詳細な説明については、公式ドキュメント「Ingress Path Matching」をご参照ください。

非べき等なリクエストがリトライされない理由

バージョン 1.9.13 以降、NGINX はエラーが発生した場合に非べき等なリクエスト (POST、LOCK、PATCH) をリトライしません。

以前の動作に戻すには、nginx-configuration ConfigMap で retry-non-idempotent: "true" を設定します。

大きなクライアントヘッダーやクッキーを持つリクエストをサポートする方法

現象

NGINX Ingress 経由でサービスにアクセスすると、400 Bad Request エラーと Request Header Or Cookie Too Large というメッセージが表示されます。

原因

このエラーは、クライアントのリクエストヘッダーまたはクッキーのサイズが Nginx で設定されたデフォルトのバッファーサイズを超えた場合に発生します。

解決策

関連するバッファーサイズを増やします。2 つの主要なパラメーターは次のとおりです。

• client-header-buffer-size：クライアントリクエストヘッダーのバッファーサイズ。デフォルトは 1k です。

• large-client-header-buffers：大きなクライアントリクエストヘッダーを読み取るためのバッファーの最大数とサイズ。デフォルトは 4 8k です。

これらのパラメーターを変更するには、nginx-configuration ConfigMap を編集します。
kubectl edit cm -n kube-system nginx-configuration

例：

client-max-body-size: "16k"
large-client-header-buffers: "4 32k" 

変更を適用した後、NGINX 設定でそれらが有効になっていることを確認します。Ingress Controller Pod の 1 つの内部にある nginx.conf ファイルを検査できます。
kubectl exec <nginx-ingress-pod> -n kube-system -- cat /etc/nginx/nginx.conf

Exact または Prefix パスがまだ正規表現として扱われる理由

特定の host に対する Ingress ルールのいずれかで use-regex または rewrite-target アノテーションが使用されている場合、その同じホスト配下のすべてのパスで、大文字と小文字を区別しない正規表現マッチングが強制的に使用されます。 これは NGINX Ingress Controller の現在の実装ロジックです。 詳細については、「コミュニティドキュメント」をご参照ください。

多数の Ingress があるクラスターで Ingress を追加する際に検証 Webhook の応答が遅い理由

これは NGINX Ingress Controller V1.12 以前の既知のパフォーマンス問題です。検証 Webhook は既存のすべての Ingress に対して完全なチェックを実行するため、大規模な環境では遅くなる可能性があります。#11115 をご参照ください。

解決策：

• オプション 1：Webhook のタイムアウトを増やす
  応答時間が長くなっても許容でき、増分検証を使用したくない場合は、検証 Webhook のタイムアウトを増やします。デフォルトは 10s です。
  

  • アクション：validatingwebhookconfigurations オブジェクトの名前が ingress-nginx-admission のものを編集し、timeoutSeconds の値を増やします (最大 30s)。

  • 注意：この値はアドオンのアップグレード中に上書きされます。

• オプション 2：増分検証を有効にする
  NGINX Ingress Controller の Deployment を変更して、--disable-full-test=true 起動引数を追加します。
  

  • 効果：このフラグを使用すると、Webhook は新しい Ingress ルールに対してのみ増分検証を実行します。これにより検証速度は大幅に向上しますが、異なる Ingress リソース間の競合は検出しません。

スニペットの使用に関する注意点

問題

複数の Ingress リソースにわたって同じドメインに対して server-snippet アノテーションを設定すると、ログに警告が表示され、最初のスニペットのみが適用されることがあります。これにより、予期しない動作が発生する可能性があります。

ログ警告の例：

W0619 14:58:49.323721       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")
W0619 14:58:49.323727       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")
W0619 14:58:49.323734       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com")

この警告は、test.example.com のスニペットがすでに定義されており、他の Ingress リソースからの後続の定義が無視されていることを示しています。

Secret で設定した TLS 証明書が機能しない理由

コントローラーのログを確認する

NGINX Ingress Controller Pod のログを調べて、証明書関連のエラーがないか確認します。

kubectl -n kube-system logs <nginx-ingress-controller-pod-name> | grep "Error getting SSL certificate"

以下のようなエラーが表示された場合、証明書 Secret の読み込みに問題があることを示しています (xxxx は Secret の名前です)。

Error getting SSL certificate "xxxx": local SSL certificate xxxx tls was not found. Using default certificate

このエラーには主に 3 つの原因が考えられます。

原因 1：Secret が存在しない

ログメッセージで指定された名前の Secret が正しい名前空間に実際に存在することを確認します。

原因 2：証明書と秘密鍵が一致しない

Secret に保存されている tls.crt (公開鍵) と tls.key (秘密鍵) は、一致するペアでなければなりません。

• kubectl create secret tls を使用して、一致しないペアで tls Secret を作成しようとすると、コマンドは次のエラーで失敗します。
  error: tls: private key does not match public key
  

• 既存の Secret の不一致を確認するには、次のスクリプトを実行します。

  export SECRET_NAME=<Your Secret Name>
  export NAME_SPACE=<Your Secret Namespace>
  diff <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -modulus | openssl md5) <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.key}' | base64 -d | openssl rsa -noout -modulus | openssl md5) && echo "Certificate and Key match" || echo "Certificate and Key do not match"

  このコマンドは、証明書とキーのモジュラスを比較します。キーと証明書が一致しない場合、出力には 2 つの異なるハッシュ値と Certificate and Key do not match というメッセージが表示されます。有効なキーペアで Secret を更新する必要があります。

  root@Aliyun ~/ssl # export SECRET_NAME=test
  root@Aliyun ~/ssl # export NAME_SPACE=default
  root@Aliyun ~/ssl # diff <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -modulus | openssl md5) <(kubectl get secret $SECRET_NAME -n $NAME_SPACE -o jsonpath='{.data.tls\.key}' | base64 -d | openssl rsa -noout -modulus | openssl md5) && echo "Certificate and Key match" || echo "Certificate and Key do not match"
  1c1
  < (stdin)= 66a309089e87e32d1b6fe361ebf8cd88
  ---
  > (stdin)= 12e15c5fe35585b6fd9920abc8e8706d
  Certificate and Key do not match

原因 3：同じドメインの別の Ingress で TLS エントリが誤って設定されている

複数の Ingress リソースにわたって同じドメインに対して tls セクションを定義している場合、そのうちの 1 つの設定にエラーがあると、証明書が正しく読み込まれなくなる可能性があります。そのドメインを参照するすべての Ingress リソースを確認し、誤った設定を修正してください。

証明書を更新した後も証明書の有効期限切れアラートが届く理由

原因

古いバージョンの NGINX Ingress Controller には、証明書が更新された後も nginx_ingress_controller_ssl_expire_time_seconds メトリクスが正しく更新またはパージされないという既知のバグがあります。これにより、監視システムが古いデータに基づいて certificate expired アラートを発し続ける可能性があります。

解決策

古いメトリクスをクリアするには、NGINX Ingress Controller Pod のローリングリスタートを実行する必要があります。

この問題は新しいバージョンで解決されているため、NGINX Ingress Controller をバージョン 1.11.4 以降にアップグレードすることを強く推奨します。

特定の NGINX Ingress Controller バージョンのデフォルト設定を見つける方法

設定パラメーターのデフォルト値は、NGINX Ingress Controller のバージョンによって異なります。たとえば、use-gzip はバージョン 0.35.0 以前ではデフォルトで有効でしたが、バージョン 1.11.4 ではデフォルトで無効になっています。

特定のバージョンの特定のパラメーターのデフォルトの動作を見つけるには、公式ドキュメントの対応するバージョンブランチにある configmap.md ファイルを参照してください。

例：controller-v1.8.0 の場合、ページの左側にあるバージョンセレクターを使用して他のバージョンに切り替えます。