Container Service for Kubernetes:Nginx Ingress FAQ

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

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

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

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

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

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

• 内部向きのSLBインスタンスを使用するようにIngressコントローラーを設定する

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

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

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

• 複数のIngressコントローラーからアクセスログを収集する方法?

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

• NGINX Ingress用に設定された証明書の一致ロジックとは

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

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

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

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

• NGINX Ingressコントローラーのアップグレードの問題の修正

• chunked転送エンコーディングがコントローラーv1.10以降機能しなくなるのはなぜですか?

• NGINX IngressでIPアドレスのホワイトリストとブラックリストに基づいてアクセス制御を設定するにはどうすればよいですか?

• NGINX Ingress v1.2.1の既知の問題

• curlコマンドでインターネットサービスにアクセスするときに接続リセットを処理するにはどうすればよいですか?

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

Ingress-nginxは、トランスポート層セキュリティ (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:
    # You must specify HTTPS as the protocol that is used by the backend server. 
    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コントローラーを更新する前にレプリカの値を5に設定した場合、ACKコンソールの [アドオン] ページからコンポーネントを更新した後、レプリカパラメーターはデフォルト値2を使用します。

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

1. 証明書を作成し、証明書ID (cert-id) を記録します。 詳細については、「証明書管理サービスの証明書の使用」をご参照ください。

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 # Set targetPort to 80 for port 443.

      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. On theサービスページを検索し、ingress-nginx-lbサービスをクリックし、のアイコンタイプ列を作成します。

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

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

1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[Marketplace] > [Marketplace] を選択します。

2. On theアプリカタログタブを選択します。ack-ingress-nginxまたはack-ingress-nginx-v1.

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

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

3. Ingressコントローラーをデプロイします。 詳細については、「クラスターへの複数のIngressコントローラーのデプロイ」をご参照ください。

   [パラメーター] ウィザードページで、元の注釈を削除してから、新しい注釈を追加します。

   1. のすべての注釈を削除します。controller.service.annotationsセクションにアクセスします。

      

   2. 新しい注釈を追加します。

      Specify the SLB instance that you want to use.
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALANCER_ID}"
      # Overwrite the listeners of the SLB instance.
      service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"

      

4. クリックOKIngressコントローラーを展開します。

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

nginx ingressコントローラーのTCPリスナーを有効にするにはどうすればよいですか。

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

手順:

NGINX Ingressに設定された証明書の一致ロジックとは

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

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

サンプル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は、証明書のステータスを確認するために使用されるオンライン証明書ステータスプロトコル (OCSP) ステープル機能をサポートしています。 この機能を有効にすると、クライアントは認証局 (CA) で証明書のステータスを確認する必要がなくなります。 これにより、証明書の検証が高速化され、NGINXへのアクセスが高速化されます。 詳細については、「OCSPステープルの設定」をご参照ください。

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

証明書を格納するシークレットを見つけ、Base64-decoded証明書の内容を新しいファイルに保存します。 次に、opensslコマンドを実行して証明書を復号します。

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

アクセスしたドメイン名が [共通名 (CN)] フィールドに含まれているかどうかを確認します。 ドメイン名が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
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はヘルスチェックに失敗します。 この問題を解決するには、NGINXポッドをスケールアウトしてポッドを別のノードに展開することを推奨します。

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

この問題は、Web Application Firewall (WAF) が有効になっている場合に発生する可能性があります。 WAFは、証明書の発行を中断するHTTP01リクエストに干渉する可能性があります。 この問題を解決するには、WAFを無効にすることを推奨します。 WAFを無効にする前に、WAFを無効にした後の影響を評価します。

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

NGINXのピーク時にメモリ使用量の急増やメモリ不足 (OOM) エラーが発生した場合は、NGINXポッドにログインし、過剰なメモリを消費するプロセスを特定します。 ほとんどの場合、メトリック収集プロセスはメモリリークにつながります。 この問題は、NGINX Ingressコントローラー1.6.4で検出されます。 NGINX Ingressコントローラーを最新バージョンに更新し、スタートアップパラメーターに -- enable-metrics=falseを追加してメトリック収集を無効にすることを推奨します。 nginx_ingress_controller_ingress_upstream_latency_秒など、メモリ使用量が大幅に増加するメトリックの収集を無効にすることを推奨します。 詳細については、「Ingressコントローラーストレステスト」、「Prometheusメトリックコレクターメモリリーク」、および「Metrics PR」をご参照ください。

NGINX Ingressコントローラーのアップグレードの問題を修正

Nginx Ingressコントローラーカナリアアップグレードプロセス中に、プロセスが検証で停止し、「操作は失敗状態のタスクが禁止されています」というメッセージで続行できない場合、ほとんどの場合、コンポーネントのアップグレードタスクがシステムによって4日間の有効期間を超えた後にクリアされたためです。 コンポーネントのカナリアステータスを手動で調整する必要があります。

コンポーネントのアップグレードプロセスがリリースフェーズに達したら、次の手順をスキップします。 有効期間が4日を超えたために現在のタスクが自動的に停止するまで待つことができます。

手順:

パラメーターを変更すると、コンポーネントのアップグレードが自動的に再開され、古いポッドが置き換えられてカナリアのアップグレードが完了します。 ただし、ステータスは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. 設定後にファイルを保存します。

なぜchunked転送エンコーディングが機能しなくなるのですか?

コードがHTTPリクエストヘッダーTransfer-Encoding: chunkedを構成し、コントローラーログに重複ヘッダーに関連するエラーが表示された場合、NGINXの更新が原因である可能性があります。 詳細については、「NGINX更新ログ」をご参照ください。 v1.10以降、NGINXはHTTP応答の検証を強化しました。 その結果、複数のTransfer-Encoding: chunkedヘッダーを含むバックエンド応答は無効と見なされます。 バックエンドサービスがTransfer-Encoding: chunkedヘッダーを1つだけ返すようにする必要があります。 詳細については、『GitHub Issue #11162』をご参照ください。

NGINX IngressでIPアドレスのホワイトリストとブラックリストに基づいてアクセス制御を設定するにはどうすればよいですか?

NGINX Ingressのブラックリストまたはホワイトリストを設定して、特定のIPアドレスからのリクエストを拒否または許可するには、ConfigMapにキーと値のペアを追加するか、Ingressルーティングルールでアノテーションを使用します。 ConfigMapはグローバルに適用され、Ingress設定はルーティングレベルで有効になります。 Ingressルーティング設定は、グローバル設定よりも優先度が高くなります。 Ingressでアノテーションを追加する方法については、以下の表を参照してください。 詳細については、「Denylistソース範囲」および「ホワイトリストソース範囲」をご参照ください。

NGINX Ingress v1.2.1の既知の問題

IngressにdefaultBackendフィールドがある場合、NGINXのデフォルトサーバーブロックのdefaultBackend設定が上書きされることがあります。 詳細については、『GitHub Issue #8823』をご参照ください。

この問題を解決するには、NGINX Ingressコントローラーをv1.3以降に更新することを推奨します。 更新方法の詳細については、「NGINX Ingressコントローラーの更新」をご参照ください。

アクセス時に接続リセットを処理する方法インターネットサービスは、カールコマンド?

curlコマンドを使用してHTTPプロトコルを使用して中国本土以外のインターネットサービスにアクセスすると、curl: (56) Recv failure: Connection reset by peerというエラーメッセージが表示されることがあります。 通常、これは、HTTPプレーンテキスト要求に機密キーワードが含まれている可能性があり、要求がブロックされたり、応答がリセットされたりするためです。 IngressルールのTLS証明書を設定して、暗号化を使用して通信が行われるようにすることができます。 TLS証明書を設定する方法の詳細については、「高度なNGINX Ingress設定」をご参照ください。