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 バージョンを使用しているクライアントは、ハンドシェイクエラーが発生する可能性があります。

server-tokens: "false"
ssl-ciphers: '@SECLEVEL=0:ECDHE-ECDSA-AES128-GCM-SHA256:E...
ssl-protocols: TLSv1 TLSv1.1 TLSv1.2 TLSv1.3
ssl-redirect: "false"

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-Forwarded-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 の設定方法

General
  Request URL: http://xxx.bizprodmng xxx .com/crmhome/pageListQuery.json?pageNum=1&pageName=&pageSize=20&platform=
  Request Method: GET
  Status Code: 307 Internal Redirect
Response Headers
  Access-Control-Allow-Credentials: true
  Access-Control-Allow-Origin: http://zhbyak xxx net:3001
  Location: https://bizprodmng xxx .com/crmhome/pageListQuery.json?pageNum=1&pageName=&pageSize=20&platform=
  Non-Authoritative-Reason: HSTS
Request Headers
  Provisional headers are shown
  Referer: http://zhbyak xxx .net:3001/searchPage
  User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Saf...
Query String Parameters
  pageNum: 1
  pageName:

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

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 サービスを見つけ、[アクション] 列の [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 に変更されています。

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

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

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 セクションのすべてのアノテーションを削除します。

      # 追加の内部 SLB を有効にする
      internal:
        enabled: false
        annotations:
          service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
          service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s1.small"

   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 リクエストのみを転送します。ingress-nginx を構成して、関連する ConfigMap で指定されたポートで外部 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 ハッシュを計算します。

  ハッシュ値が同一でない場合、証明書と秘密鍵は一致していません。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 のような形式の Common Name (CN) フィールドを探します。

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

  ホスト名が CN または SAN エントリにリストされていない場合、その証明書はそのドメインに対して無効です。正しいホスト名をカバーする新しい証明書を取得してください。

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

背景

NGINX Ingress Controller のヘルスチェックは、ポート 10246 の /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 日間の有効期限を超えた後、システムによってクリーンアップされた場合に発生します。これを解決するには、アドオンのデプロイメント状態を手動でリセットします。

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

手順

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%

   spec:
     minReadySeconds:0
     progressDeadlineSeconds: 600
     replicas: 2
     revisionHistoryLimit: 10
     selector:
       matchLabels:
         app: ingress-nginx
     strategy:
       rollingUpdate:
         maxSurge: 25%
         maxUnavailable: 25%

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

期待される結果

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

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

症状

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

原因

v1.10 以降、基盤となる 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 のアップグレード」をご参照ください。

なぜ Connection reset by peer というエラーが curl を使用すると表示されるのですか？

症状

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

原因

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

解決策

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

パスマッチングの優先順位の仕組み

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

詳細については、「Ingress パスマッチング」をご参照ください。

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

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

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

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

症状

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

原因

このエラーは、クライアントのリクエストヘッダーまたは Cookie のサイズが 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-header-buffer-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 アノテーションが使用されている場合、その host 配下のすべてのパスは、大文字と小文字を区別しない正規表現マッチングを使用するように強制されます。これは NGINX Ingress Controller の現在の実装ロジックです。詳細については、「コミュニティドキュメント」をご参照ください。

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

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

解決策：

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

  • アクション： ingress-nginx-admission という名前の validatingwebhookconfigurations オブジェクトを編集し、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_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 の場合、ページの左側にあるバージョンセレクターを使用して他のバージョンに切り替えます。