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

• NGINX Ingress コントローラーの以前のバージョンにおける既知の問題は何ですか？

• Ingress でサポートされている SSL または TLS プロトコルバージョンはどれですか？

• Ingress はデフォルトでレイヤー 7 リクエストヘッダーをバックエンドサーバーに渡しますか？

• ingress-nginx はバックエンド HTTPS サーバーにリクエストを転送できますか？

• Ingress はレイヤー 7 でクライアント IP アドレスを渡しますか？

• NGINX Ingress コントローラーは HSTS をサポートしていますか？

• ingress-nginx でサポートされている書き換えルールはどれですか？

• インターネット向けまたは内部向けの NGINX Ingress コントローラーを構成する

• ACK コンソールのアドオンページで NGINX Ingress コントローラーを更新した後、システムで何が更新されますか？

• ingress-nginx のレイヤー 4 リスナーをレイヤー 7 HTTP または HTTPS リスナーに変更するにはどうすればよいですか？

• ACK コンソールのマーケットプレイスページからデプロイされた ack-ingress-nginx に既存の SLB インスタンスを指定するにはどうすればよいですか？

• 複数の Ingress コントローラーからアクセスログを収集するにはどうすればよいですか？

• nginx-ingress-controller の TCP リスナーを有効にするにはどうすればよいですか？

• NGINX Ingress に構成された証明書の一致ロジックは何ですか？

• NGINX Ingress に一致する証明書がない場合はどうすればよいですか？

• 高負荷のシナリオで NGINX ポッドがヘルスチェックに失敗した場合はどうすればよいですか？

• cert-manager エラーが原因で証明書の発行に失敗した場合はどうすればよいですか？

• ピーク時の NGINX メモリ使用量の急増にどのように対処すればよいですか？

• NGINX Ingress コントローラーがアップグレード中の状態のままの場合はどうすればよいですか？

• NGINX Ingress コントローラー 1.10 以降を使用しているときに、チャンク転送（Transfer-Encoding: chunked）が正常に動作しない場合はどうすればよいですか？

• NGINX Ingress へのアクセスを制御するために IP ブラックリストとホワイトリストを構成するにはどうすればよいですか？

• NGINX Ingress コントローラー V1.2.1 の既知の問題は何ですか？

• curl を使用してインターネット経由で外部サービスにアクセスするときに接続リセットエラーが発生した場合はどうすればよいですか？

• パス照合の優先順位のロジックは何ですか？

• 非冪等リクエストが再試行されないのはなぜですか？

• NGINX Ingress が大きなクライアントリクエストヘッダーまたは Cookie をサポートできるようにするにはどうすればよいですか？

• Ingress の構成で特定のパスに pathType を Exact または Prefix に設定した後、代わりに正規表現が使用されるのはなぜですか？

• 多数の Ingress が既に存在するクラスターに新しい Ingress を追加すると、検証 Webhook の応答が遅いのはなぜですか？

• スニペットの問題が発生するのはなぜですか？

• Secrets に保存されている証明書が有効にならないのはなぜですか？

• 期限切れの証明書を更新した後も、証明書の期限切れに関するアラート通知が引き続き届くのはなぜですか？

• NGINX Ingress コントローラーの異なるバージョンのデフォルト構成を表示するにはどうすればよいですか？

NGINX Ingress コントローラーの以前のバージョンにおける既知の問題は何ですか？

次のリストは、NGINX Ingress コントローラーの以前のバージョンにおける問題への参照を提供します。 NGINX Ingress コントローラーを使用する際の問題を防ぐために、最新バージョンにアップグレードすることをお勧めします。 詳細については、「NGINX Ingress コントローラーをアップグレードする」をご参照ください。

• Nginx ingress(v1.1.0) がクラッシュしました

• ワーカーセグメンテーションフォールト (v0.44.0)

• Ingress の defaultBackend パラメーター値が NGINX Ingress コントローラーのグローバル構成を上書きします

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

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

• nginx-cfg-xx の一時構成ファイルがクリアされず、ディスクがいっぱいになる可能性があります（NGINX Ingress コントローラーを 1.10.4 以降にアップグレードすることをお勧めします）

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

  解決策: NGINX Ingress コントローラーを 1.10.4-aliyun.1 以降にアップグレードします。

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

  原因: client-body-buffer-size の値が 32 ビット整数のストレージ制限を超えています。

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

Ingress でサポートされている SSL または TLS プロトコルバージョンはどれですか？

Ingress-nginx は、Transport Layer Security (TLS) 1.2 および TLS 1.3 をサポートしています。 ブラウザまたはモバイルクライアントで使用される TLS プロトコルバージョンが 1.2 より前の場合、クライアントと ingress-nginx 間のハンドシェイク中にエラーが発生する可能性があります。

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"

Ingress はデフォルトでレイヤー 7 リクエストヘッダーをバックエンドサーバーに渡しますか？

enable-underscores-in-headers: true

ingress-nginx はバックエンド HTTPS サーバーにリクエストを転送できますか？

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

Ingress はレイヤー 7 でクライアント IP アドレスを渡しますか？

デフォルトでは、ingress-nginx は X-Forward-For および X-Real-IP ヘッダーフィールドを追加して、クライアント IP アドレスを渡します。 ただし、X-Forward-For および X-Real-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"  

NGINX Ingress コントローラーは HSTS をサポートしていますか？

ingress-nginx でサポートされている書き換えルールはどれですか？

ACK コンソールのアドオンページで NGINX Ingress コントローラーを更新した後、システムで何が更新されますか？

他のリソースの構成はデフォルト値にリセットされます。 たとえば、deployment.apps/nginx-ingress-controller リソースの replicas パラメーターのデフォルト値は 2 です。 NGINX Ingress コントローラーを更新する前に replicas の値を 5 に設定した場合、ACK コンソールのアドオンページからコンポーネントを更新した後、replicas パラメーターはデフォルト値の 2 を使用します。

ingress-nginx のレイヤー 4 リスナーをレイヤー 7 HTTP または HTTPS リスナーに変更するにはどうすればよいですか？

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

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

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

   2. [クラスター] ページで、管理するクラスターを見つけて、その名前をクリックします。 左側のウィンドウで、[ネットワーク] > [サービス] を選択します。

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

   4. [YAML で表示] パネルで、ports セクションのポート 443 の targetPort を 80 に設定します。

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

      次の構成を annotations パラメーターに追加し、[更新] をクリックします。

      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 が表示されている場合、SLB インスタンスのリスナーはレイヤー 4 からレイヤー 7 に変更されています。

ACK コンソールのマーケットプレイスページからデプロイされた 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 コントローラーをデプロイします。 詳細については、「クラスターに複数の Ingress コントローラーをデプロイする」をご参照ください。

   [パラメーター] ウィザードページで、元のアノテーションを削除してから、新しいアノテーションを追加します。

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

      

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

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

      

4. [OK] をクリックして、Ingress コントローラーをデプロイします。

5. Ingress コントローラーがデプロイされた後、Ingress コントローラーの Ingress クラスを構成します。 詳細については、「クラスターに複数の Ingress コントローラーをデプロイする」をご参照ください。

nginx ingress コントローラーで TCP リスナーを有効にする方法

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

NGINX Ingress 用に構成された証明書の一致ロジックとは何ですか？

Ingress は、spec.tls パラメーターを使用して TLS 構成を指定し、spec.rules.host パラメーターを使用して Ingress のドメイン名を指定します。NGINX Ingress コントローラーは、Lua テーブルを使用して、ドメイン名と証明書間のマッピングを保存します。

クライアントが NGINX に HTTPS リクエストを送信すると、リクエストには、リクエストの送信先 host を指定する Server Name Indication（SNI）フィールドが含まれます。NGINX Ingress は、certificate.call() メソッドを使用して、証明書がドメイン名に関連付けられているかどうかを確認します。証明書が見つからない場合は、fake 証明書が返されます。

NGINX 構成の例：

    ## サーバー _ の開始
    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()
        }
   ...
   }
    
    
    ## サーバー 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）で証明書のステータスを確認する必要はありません。これにより、証明書の検証が高速化され、NGINX へのアクセスが高速になります。詳細については、「OCSP ステープリングを構成する」をご参照ください。

NGINX Ingress と一致する証明書がない場合はどうすればよいですか？

この問題は、使用している証明書と秘密鍵が一致しない場合、または使用している証明書のドメイン名がアクセスされているドメイン名と異なる場合に発生します。この問題のトラブルシューティングを行うには、次の操作を実行します。

• 使用している Secret 内の証明書と秘密鍵が互いに一致するかどうかを確認します。

  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.crt}' | base64 -d > /tmp/tls.crt && \ # 使用する<YOUR-SECRET-NAME>に置き換えます。
  kubectl get secret <YOUR-SECRET-NAME>  -n <SECRET-NAMESPACE> -o jsonpath='{.data.tls\.key}' | base64 -d > /tmp/tls.key && \
  openssl x509 -noout -modulus -in /tmp/tls.crt | openssl md5 && \
  openssl rsa -noout -modulus -in /tmp/tls.key | openssl md5

  上記のコマンドを実行して kubectl を使用し、Secret から証明書の内容を抽出し、証明書をデコードして、証明書を /tmp/tls.crt ファイルに、秘密鍵を /tmp/tls.key ファイルに保存します。次に、OpenSSL MD5 関数を使用して、証明書と秘密鍵のハッシュ値を計算します。

  証明書のハッシュ値が秘密鍵のハッシュ値と異なる場合、証明書と秘密鍵は一致しません。互いに一致する証明書と秘密鍵を設定することをお勧めします。

• 証明書のドメイン名が、アクセスされているドメイン名と同じであるかどうかを確認します。

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

  上記のコマンドを実行すると、システムは出力に証明書の詳細を返します。出力の CN フィールド（Common Name を示します）で証明書のドメイン名を確認できます。例：CN = example.com。 CN フィールドの値にアクセスされているドメイン名が含まれていない場合、証明書のドメイン名はアクセスされているドメイン名と同じです。ビジネス要件に基づいてドメイン名を変更し、証明書のドメイン名がアクセスされているドメイン名と同じであることを確認します。

高負荷のシナリオで NGINX ポッドがヘルスチェックに失敗した場合はどうすればよいですか?

ヘルスチェックは、NGINX のポート 10246 を介して /healthz パスにリクエストを送信することで実行されます。

NGINX がヘルスチェックに失敗した場合、次のメッセージが返されます。

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  // ingress コントローラーがシャットダウンしています
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 // nginx ステータス情報の取得中に予期しないエラーが発生しました:
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 // ingress コントローラーがシャットダウンしています
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 // nginx ステータス情報の取得中に予期しないエラーが発生しました:
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 // ingress コントローラーがシャットダウンしています
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 // nginx ステータス情報の取得中に予期しないエラーが発生しました:
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 // ingress コントローラーがシャットダウンしています
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 // nginx ステータス情報の取得中に予期しないエラーが発生しました:
I0412 11:02:28.983016       7 nginx.go:408] "NGINX process has stopped" // "NGINX プロセスが停止しました"
I0412 11:02:28.983033       7 sigterm.go:44] Handled quit, delaying controller exit for 10 seconds // 終了を処理し、コントローラーの終了を 10 秒遅延させています
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 // ingress コントローラーがシャットダウンしています
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 // nginx ステータス情報の取得中に予期しないエラーが発生しました:
I0412 11:02:38.986048       7 sigterm.go:47] "Exiting" code=0 // "終了しています"

高負荷のシナリオでは、NGINX プロセスの CPU 使用率が急上昇し、100% に近づくことさえあります。 この場合、NGINX はヘルスチェックに失敗します。 この問題を解決するには、NGINX ポッドをスケールアウトして、ポッドを異なるノードに分散させることをお勧めします。

cert-manager エラーが原因で証明書の発行に失敗した場合はどうすればよいですか?

この問題は、Web Application Firewall（WAF）が有効になっている場合に発生する可能性があります。 WAF は HTTP01 リクエストを妨害する可能性があり、証明書の発行が中断されます。 この問題を解決するには、WAF を無効にすることをお勧めします。 WAF を無効にする前に、WAF を無効にした後の影響を評価してください。

ピーク時に NGINX のメモリ使用量が急増した場合はどうすればよいですか?

ピーク時に NGINX でメモリ使用量の急増とメモリ不足 (OOM) エラーが発生した場合は、NGINX ポッドにログインし、過剰なメモリを消費しているプロセスを特定します。 ほとんどの場合、メトリック収集プロセスがメモリリークにつながります。 これは、NGINX Ingress コントローラー V1.6.4 の既知の問題です。 この問題を解決するには、NGINX Ingress コントローラーを最新バージョンに更新し、高負荷シナリオでの NGINX Ingress コントローラーのインストールを参照して、nginx_ingress_controller_ingress_upstream_latency_seconds など、メモリ使用量を大幅に増加させるメトリックの収集を無効にすることをお勧めします。 詳細については、「Ingress controller stress test」、「Prometheus metric collector memory leak」、および「Metrics PR」をご参照ください。

NGINX Ingress コントローラーがアップグレード中の状態のままになっている場合はどうすればよいですか？

NGINX Ingress コントローラーをアップグレードするためにカナリアリリースを実装すると、アップグレード タスクが検証 ステップで停止し、システムによって Operation is forbidden for task in failed state というメッセージが表示されます。ほとんどの場合、この問題は、アップグレード タスクの期間がタイムアウト期間（デフォルトでは 4 日間）を超えたために発生します。アップグレード タスクがタイムアウトすると、システムは自動的にタスクを終了します。この問題を解決するには、カナリアリリースのステータスを手動で変更する必要があります。

アップグレード タスクがリリース ステップにある場合は、アップグレードを実行する必要はありません。アップグレード タスクの期間が 4 日を超えると、システムは自動的にタスクを終了します。

手順

変更が完了すると、システムはカナリアリリースを再開して NGINX Ingress コントローラーをアップグレードします。ただし、NGINX Ingress コントローラーは、ACK コンソールのアドオン ページで約 2 週間、アップグレード中の状態のままになる可能性があります。

1. 次のコマンドを実行して、nginx-ingress-controller デプロイメントを変更します。

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

2. 以下のパラメーターを設定します。

   • spec.minReadySeconds: 0

   • spec.progressDeadlineSeconds: 600

   • spec.strategy.rollingUpdate.maxSurge: 25%

   • spec.strategy.rollingUpdate.maxUnavailable: 25%

   

3. 変更を保存して終了します。

NGINX Ingress コントローラー 1.10 以降を使用している場合、チャンク転送（Transfer-Encoding: chunked）が正常に動作しない場合はどうすればよいですか？

コードで Transfer-Encoding: chunked HTTP ヘッダーを指定し、コントローラーログに Transfer-Encoding: chunked ヘッダーが重複して存在する場合、問題は NGINX の更新が原因である可能性があります。詳細については、「NGINX 更新ログ」をご参照ください。NGINX 1.10 以降では、HTTP 応答の検証が強化されています。その結果、バックエンド アプリケーションから複数の Transfer-Encoding: chunked ヘッダーが返されると、応答は無効と見なされます。この問題を解決するには、バックエンド アプリケーションが Transfer-Encoding: chunked ヘッダーを 1 つだけ返すように設定する必要があります。詳細については、「GitHub Issue #11162」をご参照ください。

NGINX Ingress へのアクセスを制御するために IP ブラックリストとホワイトリストを構成するにはどうすればよいですか？

NGINX Ingress コントローラー 1.2.1 の既知の問題は何ですか?

Ingress の defaultBackend パラメーターを構成すると、デフォルト サーバーの defaultBackend パラメーター値が上書きされる可能性があります。詳細については、「GitHub Issue #8823」をご参照ください。この問題を解決するには、NGINX Ingress コントローラーを V1.3 以降にアップグレードすることをお勧めします。NGINX Ingress コントローラーのアップグレード方法の詳細については、「NGINX Ingress コントローラーをアップグレードする」をご参照ください。

curl を使用してインターネット経由でパブリックサービスにアクセスするときに接続リセットエラーが発生した場合はどうすればよいですか？

HTTP 経由で中国国外のパブリックサービスに curl を使用してアクセスすると、curl: (56) Recv failure: Connection reset by peer エラーが返される場合があります。ほとんどの場合、この問題は、HTTP プレーンテキストのリクエストに禁止用語が含まれているために発生します。これにより、リクエストがブロックされたり、レスポンスがリセットされたりします。 通信を暗号化するために、Ingress ルールに TLS 証明書を設定することができます。

パス一致の優先順位のロジックとは何ですか？

NGINX では、正規表現は最初に一致したポリシーに従います。より正確なパス一致を有効にするために、ingress-nginx はまずパスの長さを降順に並べ替えてから、NGINX 構成にパスを書き込みます。詳細については、「https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/」をご参照ください。

非 idempotent リクエストがリトライされないのはなぜですか?

NGINX 1.9.13 以降では、NGINX はエラー発生時に POST、LOCK、PATCH リクエストなどの非 idempotent リクエストをリトライしません。以前の動作に戻すには、nginx-configuration ConfigMap に retry-non-idempotent=true を指定します。

NGINX Ingress で大きなクライアントリクエストヘッダーまたは Cookie をサポートするにはどうすればよいですか?

NGINX Ingress が過度に大きなクライアントリクエストヘッダーまたは Cookie を受信すると、"400 Request Header Or Cookie Too Large /Bad request" エラーが返される場合があります。この問題を解決するには、次のパラメーターを変更して、クライアントリクエストヘッダーを読み取るためのバッファーサイズを増やす必要があります。

• client-header-buffer-size: クライアントリクエストヘッダーを読み取るためのバッファーサイズ。デフォルト値: 1k。

• large-client-header-buffers: 大きなクライアントリクエストヘッダーの読み取りに使用されるバッファーの最大数とサイズ。デフォルト値: 4 8k。

kubectl edit cm -n kube-system nginx-configuration コマンドを実行して、nginx-configuration ConfigMap を変更し、ビジネス要件に基づいて上記のパラメーターを変更できます。例:

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

変更が完了したら、新しい構成が NGINX データプレーンで有効になっていることを確認します。kubectl exec <nginx-ingress-pod> -n kube-system -- cat/etc/nginx/nginx.conf | vim - コマンドを実行して、nginx.conf ファイル内の構成をクエリし、構成が nginx-configuration ConfigMap から同期されているかどうかを確認できます。

pathType を Exact または Prefix に設定した後、Ingress の構成で特定のパスに対して正規表現が使用されるのはなぜですか？

use-regex または rewrite-target アノテーションが特定のホストの Ingress に追加されている場合、大文字と小文字を区別しない正規表現が、そのホストのすべてのパスに適用されます。これは、NGINX Ingress コントローラーの実装ロジックです。詳細については、「コミュニティドキュメント」をご参照ください。

多数の Ingress が既に存在するクラスターに新しい Ingress を追加すると、検証 Webhook の応答が遅くなるのはなぜですか？

これは、NGINX Ingress コントローラー V1.12 以前における既知のパフォーマンスの問題です。詳細については、「#11115」をご参照ください。

解決策:

1. クラスターが低速の応答を許容し、検証を受け入れないと仮定します。Webhook の現在の応答がタイムアウトした場合、ingress-nginx-admission の validatingwebhookconfigurations のタイムアウト期間を延長できます。デフォルトのタイムアウト期間は 10 秒です。最大タイムアウト期間は 30 秒です。タイムアウト パラメーター値は、NGINX Ingress コントローラーのアップグレード時に上書きされることに注意してください。

2. --disable-full-test=true 設定を、NGINX Ingress コントローラー用に作成されたデプロイメントの起動パラメーターに追加します。この設定を追加すると、システムは Ingress に対して増分検証のみを実行します。これにより、検証速度が向上します。ただし、Ingress ルール間の競合は検出できません。

スニペットの問題はなぜ発生しますか？

複数のスニペットを異なる Ingress で構成すると、入力エラーが発生する可能性があります。その結果、構成が予期しないものになる可能性があります。

W0619 14:58:49.323721       7 controller.go:1314] Server snippet already configured for server "test.example.com", skipping (Ingress "default/test.example.com") // サーバースニペットはサーバー "test.example.com" に既に構成されているため、スキップします (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") // サーバースニペットはサーバー "test.example.com" に既に構成されているため、スキップします (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 "default/test.example.com")

Secret に保存されている証明書が有効にならないのはなぜですか？

kubectl -n kube-system logs <nginx-ingress-controller-pod-name> | grep "Error getting SSL certificate" コマンドを実行して、NGINX Ingress コントローラーのポッドのログを表示します。ログに次のエラーメッセージが表示された場合は、次の手順を実行してこの問題のトラブルシューティングを行うことができます。xxxx はサービス名を表します。

Error getting SSL certificate "xxxx": local SSL certificate xxxx tls was not found. Using default certificate // SSL 証明書 "xxxx" の取得中にエラーが発生しました: ローカル SSL 証明書 xxxx tls が見つかりませんでした。デフォルトの証明書を使用しています。

このエラーメッセージは、次の理由で発生する可能性があります。

1. xxxx サービスが存在しません。

2. 公開鍵（tls.crt）が秘密鍵（tls.key）と一致しません。kubectl create secret tls コマンドを実行して、公開鍵（tls.crt）が秘密鍵（tls.key）と一致しない TLS Secret を作成すると、エラーメッセージが返されます。例：

   root@Aliyun ~/ssl # kubectl create secret tls tls-test-ingress --key example.com.key --cert httpbin.example.com.crt
   error: tls: private key does not match public key // エラー: tls: 秘密鍵が公開鍵と一致しません

   既存の Secret の場合、次のコマンドを実行して、Secret にこの問題が存在するかどうかを確認できます。

   export SECRET_NAME=<Your Secret Name> // SECRET_NAME をエクスポートします
   export NAME_SPACE=<Your Secret Namespace> // NAME_SPACE をエクスポートします
   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" // 証明書と鍵が一致するかどうかを確認します

   次の出力が返された場合、この問題は 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 証明書で同じドメイン名が使用されています。ただし、1 つの TLS 証明書が正しく構成されていません。構成が正しくない TLS 証明書を見つけて、構成を修正します。

期限切れの証明書を更新した後も、証明書の有効期限に関するアラート通知が引き続き届くのはなぜですか?

特定のバグは、以前のバージョンの NGINX Ingress コントローラーに存在する可能性があります。証明書を更新した後も、metrics nginx_ingress_controller_ssl_expire_time_seconds メトリックが引き続き存在する可能性があります。この問題を解決するには、NGINX Ingress コントローラーのローリングアップデートを実行する必要があります。この問題は、NGINX Ingress コントローラー V1.11.4 以降で修正されています。NGINX Ingress コントローラーのアップグレード方法の詳細については、「NGINX Ingress コントローラーをアップグレードする」をご参照ください。

NGINX Ingress コントローラーの異なるバージョンのデフォルト構成を表示するにはどうすればよいですか？

NGINX Ingress コントローラーの複数のバージョンが繰り返しリリースされています。パラメーターのデフォルト設定は、バージョンによって異なる場合があります。たとえば、use-gzip パラメーターは、NGINX Ingress コントローラー V0.35.0 以前ではデフォルトで有効になっていますが、NGINX Ingress コントローラー V1.11.4 ではデフォルトで無効になっています。

特定のバージョンのパラメーターのデフォルト設定に関する情報を取得するには、NGINX Ingress コントローラーの Git リポジトリにある、そのバージョンのブランチ内の configmap.md ファイルを確認します。次の図は、controller-v1.8.0 バージョンのブランチにある configmap.d ファイルを示しています。ページの左側でバージョンを切り替えることができます。