Container Service for Kubernetes:NGINX Ingressコントローラのトラブルシューティング

目次

背景情報

Container Service for Kubernetes (ACK) は、オープンソースバージョンに基づいて最適化されたNGINX Ingressコントローラーを提供します。 ACKによって提供されるNGINX Ingressコントローラは、オープンソースバージョンと互換性があり、オープンソースバージョンによって提供されるすべての注釈をサポートします。 ACKクラスターまたはACKサーバーレスクラスターを作成するときに、NGINX Ingressコントローラーをインストールできます。 NGINX Ingressコントローラーのインストール方法の詳細については、「NGINX Ingressコントローラーの管理」をご参照ください。

Ingressは、NGINX IngressコントローラーをクラスターにデプロイしてIngressのルーティングルールを解析する場合にのみ、通常どおり機能します。 NGINX Ingressコントローラがルーティングルールに一致する要求を受信した後、NGINX Ingressコントローラは、対応するバックエンドサービスに要求をルーティングします。 その後、バックエンドサービスは要求をポッドに転送します。 Kubernetesクラスターでは、Services、Ingress、およびNGINX Ingressコントローラーは次のプロセスで動作します。

• サービスは、複製されたポッドのセットで実行されるバックエンドアプリケーションの抽象化です。

• Ingressにはリバースプロキシルールが含まれています。 HTTPまたはHTTPSリクエストがルーティングされるサービスポッドを制御します。 たとえば、リクエストは、リクエスト内のホストとURLパスに基づいて、異なるServiceポッドにルーティングされます。

• NGINX Ingressコントローラは、Ingressルールを解析するリバースプロキシプログラムです。 Ingressルールに変更が加えられた場合、NGINX Ingressコントローラはそれに応じてIngressルールを更新します。 NGINX Ingressコントローラーがリクエストを受信すると、Ingressルールに基づいてリクエストをServiceポッドにリダイレクトします。

NGINX Ingressコントローラーは、APIサーバーからIngressルールの変更を取得し、nginx.confなどの設定ファイルを動的に生成します。 これらの設定ファイルは、NGINXなどのロードバランサーで必要です。 次に、NGINX Ingressコントローラはロードバランサをリロードします。 たとえば、NGINX Ingressコントローラーはnginx -s reloadコマンドを実行してNGINXをリロードし、新しいIngressルールを生成します。

診断手順

1. 次の手順を実行して、Ingressによって問題が発生しているかどうかを確認できます。 Ingressコントローラーの設定が有効であることを確認してください。

   1. コントローラポッドから特定のポッドにアクセスできるかどうかを確認します。 詳細については、このトピックの「Ingressコントローラポッドを使用してIngressポッドとバックエンドポッドに手動でアクセスする」をご参照ください。

   2. NGINX Ingressコントローラーが正しく設定されているかどうかを確認します。 詳細については、「NGINX Ingressコントローラーのドキュメント」をご参照ください。

2. Ingress診断機能を使用して、Ingressとコンポーネントの設定を確認します。 次に、プロンプトに従って設定を変更します。 詳細については、このトピックの「Ingress診断機能の使用」をご参照ください。

3. 問題の原因を特定し、に記載されている関連ソリューションを参照してください。トラブルシューティングこのトピックのセクション。

4. 問題が解決しない場合は、次の手順を実行します。

   • TLS証明書に関連する問題:

     1. ドメイン名がCNAMEレコードモードまたは透過プロキシモードでWeb Application Firewall (WAF) に追加されているかどうかを確認します。

        • ドメイン名がWAFに追加されている場合は、ドメイン名にTLS証明書があるかどうかを確認します。

        • ドメイン名がWAFに追加されていない場合は、次の手順に進みます。

     2. Server Load Balancer (SLB) インスタンスにレイヤー7リスナーが設定されているかどうかを確認します。

        • SLBインスタンスにレイヤー7リスナーが設定されている場合は、そのリスナーにTLS証明書が関連付けられているかどうかを確認します。

        • SLBインスタンスにレイヤ7リスナーが設定されていない場合は、次の手順に進みます。

   • 問題がTLS証明書に関連していない場合は、コントローラポッドのエラーログを確認してください。 詳細については、このトピックの「NGINX Ingressコントローラポッドのエラーログの診断」をご参照ください。

5. 問題が解決しない場合は、コントローラポッドとバックエンドポッドでパケットをキャプチャして、問題の原因を特定します。 詳細については、このトピックの「パケットのキャプチャ」をご参照ください。

6. 問題が解決しない場合は、

   チケットの送信してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。

トラブルシューティング

一般的に使用される診断方法

Ingress診断機能の使用

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

2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[検査と診断] > [診断] を選択します。

3. On the診断ページをクリックします。侵入診断.

4. [Ingressの診断] ページで、[診断] をクリックします。 [Ingressの選択] パネルで、https://www.example.com などのアクセスできないURLを入力します。 [知っていると同意する] を選択し、[診断の作成] をクリックします。

   診断が完了したら、診断結果を表示して問題の修正を試みることができます。

Simple log ServiceでNGINX Ingressコントローラポッドのアクセスログを診断する

NGINX Ingressコントローラーのアクセスログ形式は、kube-system名前空間のnginx-configuration ConfigMapで確認できます。

$remote_addr - [$remote_addr] - $remote_user [$time_local]
    "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length
    $request_time [$proxy_upstream_name] $upstream_addr $upstream_response_length
    $upstream_response_time $upstream_status $req_id $host [$proxy_alternative_upstream_name]

次の図は、Simple log ServiceコンソールにNGINX Ingressコントローラーのアクセスログが表示されるページを示しています。 詳細については、「手順3: ログの照会と分析」をご参照ください。

kubectl logs <controller pod name> -n <namespace> | less

42.11.**.** - [42.11.**.**]--[25/Nov/2021:11:40:30 +0800]"GET / HTTP/1.1" 200 615 "_" "curl/7.64.1" 76 0.001 [default-nginx-svc-80] 172.16.254.208:80 615 0.000 200 46b79dkahflhakjhdhfkah**** 47.11.**.**[]
42.11.**.** - [42.11.**.**]--[25/Nov/2021:11:40:31 +0800]"GET / HTTP/1.1" 200 615 "_" "curl/7.64.1" 76 0.001 [default-nginx-svc-80] 172.16.254.208:80 615 0.000 200 fadgrerthflhakjhdhfkah**** 47.11.**.**[]

NGINX Ingressコントローラポッドのエラーログの診断

NGINX Ingressコントローラポッドのエラーログを診断して、トラブルシューティングの範囲を絞り込むことができます。 Ingressコントローラポッドのエラーログには、次のタイプが含まれます。

• Ingressコントローラのエラーを記録するログ。 通常、このタイプのエラーログは、無効なIngress設定が原因で生成されます。 次のコマンドを実行して、このタイプのエラーログを照会できます。

  kubectl logs <controller pod name> -n <namespace> | grep -E ^[WE]

  説明

  イングレスコントローラの初期化中に、いくつかの警告イベントが生成され得る。 たとえば、kubeconfigファイルまたはIngressClassリソースを指定しない場合、警告イベントが生成されます。 これらのイベントはIngressコントローラーには影響せず、無視できます。

• NGINXアプリケーションのエラーを記録するログ。 通常、このタイプのエラーログは、失敗した要求によって生成されます。 次のコマンドを実行して、このタイプのエラーログを照会できます。

  kubectl logs <controller pod name> -n <namespace> | grep error

Ingressコントローラポッドを使用してIngressポッドとバックエンドポッドに手動でアクセスする

1. 次のコマンドを実行して、Ingressコントローラポッドにログインします。

   kubectl exec <controller pod name> -n <namespace> -it -- bash

2. IngressコントローラポッドにはcurlとOpenSSLがプリインストールされており、ネットワーク接続のテストと証明書の検証が可能です。

   • 次のコマンドを実行して、Ingressとバックエンドポッド間のネットワーク接続をテストします。

     # Replace your.domain.com with the actual domain name of the Ingress. 
     curl -H "Host: your.domain.com" http://127.0.**.**/ # for http
     curl --resolve your.domain.com:443:127.0.0.1 https://127.0.0.1/ # for https

   • 次のコマンドを実行して証明書を確認します。

     openssl s_client -servername your.domain.com -connect 127.0.0.1:443

   • バックエンドポッドへのアクセスをテストします。

     説明

     Ingressコントローラーは、ClusterIPサービスを使用する代わりに、バックエンドポッドのIPアドレスに直接接続します。

     1. 次のkubectlコマンドを実行して、バックエンドポッドのIPアドレスを照会します。

        kubectl get pod -n <namespace> <pod name> -o wide

        想定される出力：

        NAME                      READY    STATUS    RESTARTS   AGE    IP            NODE                        NOMINATED NODE    READINESS GATES
        nginx-dp-7f5fcc7f-****    1/1      Running   0          23h    10.71.0.146   cn-beijing.192.168.**.**    <none>            <none>

        出力は、バックエンドポッドのIPアドレスが10.71.0.146であることを示しています。

     2. Ingressコントローラポッドとバックエンドポッド間のネットワーク接続をテストするには、次のコマンドを実行してIngressコントローラポッドを使用してIPアドレスに接続します。

        curl http://<your pod ip>:<port>/path

キャプチャパケット

問題を特定できない場合は、パケットをキャプチャして診断します。

1. 問題がIngressコントローラポッドに関連しているか、アプリケーションポッドに関連しているかを確認します。 問題を特定できない場合は、Ingressコントローラポッドとアプリケーションポッドの両方のパケットをキャプチャします。

2. アプリケーションポッドとIngressコントローラポッドが実行されているノードにログインします。

3. Elastic Compute Service (ECS) インスタンスで次のコマンドを実行して、Ingressによって受信されたすべての最近のパケットをキャプチャします。

   tcpdump -i any host <IP address of the application pod or Ingress controller pod> -C 20 -W 200 -w /tmp/ingress.pcap

4. ログデータにエラーが確認された場合は、パケットのキャプチャを停止します。

5. エラーが発生した期間に転送されるパケットを診断します。

   説明

   • パケットキャプチャはサービスに影響を与えず、CPU使用率とディスクI/Oのわずかな増加のみを引き起こします。

   • 上記のコマンドは、キャプチャされたパケットをローテーションし、最大200を生成できます. pcapファイルのサイズはそれぞれ20 MBです。

Kubernetesクラスター内のLoadBalancerサービスのIPアドレスにアクセスできないのはなぜですか。

問題

Kubernetesクラスターでは、LoadBalancerサービスのexternalTrafficPolicyパラメーターがLocalに設定されている場合、特定のノードのみがLoadBalancerサービスのIPアドレスにアクセスできます。

原因

externalTrafficPolicy: LocalはLoadBalancerサービスに設定されます。 ローカルモードでは、LoadBalancerサービスのIPアドレスには、LoadBalancerサービスを実行するローカルノードでプロビジョニングされているポッドからのみアクセスできます。 LoadBalancerサービスのIPアドレスは、クラスター内の他のノードのポッドからアクセスできません。 SLBインスタンスのIPアドレスがACKクラスターの外部にあること。 ACKクラスター内のノードまたはポッドがセカンドホップを使用せずにIPアドレスにアクセスできない場合、要求はSLBインスタンスに到達できません。 その結果、SLBインスタンスのIPアドレスは、SLBインスタンスを使用するサービスの拡張IPアドレスと見なされます。 リクエストは、iptablesまたはIP仮想サーバー (IPVS) に基づくkube-proxyによって転送されます。

このシナリオでは、要求されたポッドがローカルノードでプロビジョニングされていない場合、接続の問題が発生します。 SLBインスタンスのIPアドレスには、要求されたポッドがローカルノードでプロビジョニングされている場合にのみアクセスできます。 external-lbの詳細については、「kube-proxyがexternal-lbのIPアドレスをノードのローカルiptablesルールに追加」をご参照ください。

解決策

• ClusterIPサービスまたはIngress名を使用して、Kubernetesクラスター内からLoadBalancerのIPアドレスにアクセスすることを推奨します。

  Ingressは、kube-system名前空間でnginx-ingress-lbという名前です。

• kubectl edit svc nginx-ingress-lb -n kube-systemコマンドを実行して、Ingressを変更します。 LoadBalancerサービスのexternalTrafficPolicyパラメーターをClusterに設定します。 設定を変更した後、クライアントのIPアドレスは保持できません。

• クラスターがTerwayネットワークプラグインを使用し、クラスターに対して排他的または包括的なelastic network interface (ENI) モードが有効になっている場合、LoadBalancer ServiceのexternalTrafficPolicyパラメーターをclusterに設定し、ENIアノテーションを追加できます。 アノテーションにより、LoadBalancerサービスのバックエンドサーバーとしてENIが割り当てられたポッドが追加されます。 これにより、クライアントIPアドレスを保持し、LoadBalancerサービスのIPアドレスにクラスター内でアクセスできます。

  サンプルコード：

  apiVersion: v1
  kind: Service
  metadata:
    annotations:
      service.beta.kubernetes.io/backend-type: eni   # Specify pods that are assigned ENIs as backend servers. 
    labels:
      app: nginx-ingress-lb
    name: nginx-ingress-lb
    namespace: kube-system
  spec:
    externalTrafficPolicy: Cluster

  サービス注釈の詳細については、「CLBインスタンスを構成するためのサービスのYAMLファイルへの注釈の追加」をご参照ください。

IngressコントローラポッドがIngressコントローラへのアクセスに失敗するのはなぜですか。

問題

Flannelが使用されているクラスターでは、Ingressコントローラーポッドがドメイン名、SLB IPアドレス、またはクラスターIPアドレスを使用してIngressコントローラーにアクセスすると、Ingressコントローラーポッドから送信されたリクエストの一部またはすべてがドロップされます。

原因

デフォルトでは、Flannelはループバック要求を許可しません。

解決策

• Terwayネットワークプラグインを使用する新しいクラスターを作成し、ワークロードを新しいクラスターに移行することを推奨します。

• 新しいクラスターを作成しない場合は、Flannelの設定でhairpinModeを有効にできます。 設定を変更した後、Flannelポッドを再作成して変更を有効にします。

  1. 次のコマンドを実行して、Flannelの設定を変更します。

     kubectl edit cm kube-flannel-cfg -n kube-system

  2. 返されるcni-conf.jsonファイルで、delegateフィールドに "hairpinMode": trueを追加します。

     サンプルコード：

     cni-conf.json: |
         {
           "name": "cb0",
           "cniVersion":"0.3.1",
           "type": "flannel",
           "delegate": {
             "isDefaultGateway": true,
             "hairpinMode": true
           }
         }

  3. 次のコマンドを実行して、以前のFlannelポッドを削除し、Flannelポッドを再作成します。

     kubectl delete pod -n kube-system -l app=flannel   

TLS証明書をクラスターに追加した後、またはTLS証明書を変更した後に、デフォルトのTLS証明書または以前のTLS証明書が使用されるのはなぜですか。

問題

クラスターにシークレットを追加するか、クラスター内のシークレットを変更し、IngressのsecretNameフィールドのシークレット名を更新しました。 クラスターにアクセスすると、デフォルトの証明書 (Kubernetes Ingress Controller Fake certificate) または以前の証明書が使用されます。

原因

• 証明書は、クラスターのIngressコントローラーによって返されません。

• 証明書が無効で、Ingressコントローラは証明書をロードできません。

• 証明書は、Server Name Indication (SNI) フィールドに基づいてIngressコントローラによって返されます。 SNIフィールドは、TLSハンドシェイクの一部として送信されなくてもよい。

解決策

• 次のいずれかの方法を使用して、SNIフィールドがTLSハンドシェイクの一部として送信されているかどうかを確認します。

  • ブラウザをSNIをサポートするバージョンに更新します。

  • openssl s_clientコマンドを実行して証明書が使用中かどうかを確認するときは、-servernameパラメーターを指定します。

  • curlコマンドを実行するときは、IPアドレスとホストリクエストヘッダーを使用する代わりに、hostsを追加するか、-- resolveパラメーターを使用してドメイン名をマップします。

• CNAMEレコードモードまたは透過プロキシモードでWebサイトをWAFに接続する場合、TLS証明書が指定されていないこと、またはTLS証明書がSLBインスタンスのレイヤー7リスナーに関連付けられていないことを確認します。 TLS証明書は、クラスターのIngressコントローラーによって返される必要があります。

• Container Intelligence Serviceコンソールに移動し、Ingressを診断します。 診断レポートで、Ingressの設定が有効かどうか、およびログデータにエラーが表示されているかどうかを確認します。 詳細については、このトピックの「Ingress診断機能の使用」をご参照ください。

• 次のコマンドを実行して、Ingressコントローラポッドのエラーログを表示し、ログデータに基づいて問題をトラブルシューティングします。

  kubectl logs <ingress pod name> -n <pod namespace> | grep -E ^[EW]

Ingressによって公開されているgRPCサービスにアクセスできないのはなぜですか?

問題

Ingressによって公開されるgRPCサービスにはアクセスできません。

原因

• バックエンドプロトコルを指定するためにIngressにアノテーションを設定しないでください。

• gRPCサービスには、トランスポート層セキュリティ (TLS) 経由でのみアクセスできます。

解決策

• Ingressに次のアノテーションを設定します。nginx.ingress.kubernetes.io/backend-protocol:"GRPC"

• クライアントがHTTPSポートを使用してリクエストを送信し、トラフィックがTLSを使用して暗号化されていることを確認します。

バックエンドHTTPSサービスにアクセスできないのはなぜですか?

問題

• Ingressに基づいてバックエンドHTTPSサービスにアクセスできません。

• 400のエラーコードが返され、次のエラーメッセージが報告されます。the plain HTTP request was sent to HTTPS port。

原因

Ingressコントローラーは、HTTPリクエストをバックエンドポッドに送信します。 デフォルト設定です。

解決策

Ingressに次のアノテーションを設定します。nginx.ingress.kubernetes.io/backend-protocol:"HTTPS"

IngressコントローラポッドがクライアントIPアドレスを保持できないのはなぜですか。

問題

Ingressコントローラポッドは、クライアントIPアドレスを保持できません。 ノードIPアドレス100.XX. XX.XXまたはその他のアドレスが表示されます。

原因

• externalTrafficPolicyパラメーターは、Ingressに関連付けられているサービスのクラスターに設定されます。

• SLBインスタンスはレイヤ7プロキシを使用します。

• WebサイトがCNAMEレコードモードまたは透過プロキシモードでWAFに接続されています。

解決策

• externalTrafficPolicyパラメーターがサービスのクラスターに設定されており、レイヤー4 SLBインスタンスが使用されている場合は、次の手順を実行します。

  externalTrafficPolicyパラメーターをLocalに設定します。 ただし、クラスター内のLoadBalancerサービスのIPアドレスにアクセスできない場合があります。 詳細については、「」をご参照ください。Kubernetesクラスター内のLoadBalancerサービスのIPアドレスにアクセスできないのはなぜですか。

• レイヤー7プロキシを使用する場合は、次の手順を実行します。 たとえば、レイヤー7 SLBインスタンスが使用されている場合、またはWebサイトがCNAMEレコードモードまたは透過プロキシモードでWAFに接続されている場合、

  1. レイヤー7プロキシでX-Forwarded-Forヘッダーが有効になっていることを確認します。

  2. IngressコントローラーのConfigMapにenable-real-ip: "true" を追加します。 デフォルトでは、ConfigMapはnginx-configurationという名前で、kube-system名前空間に属します。

  3. ログデータを分析して、クライアントIPアドレスが保存できるかどうかを確認します。

• クライアント要求がIngressコントローラポッドに到達する前にリバースプロキシを通過する必要がある場合など、クライアント要求がIngressコントローラポッドに到達する前に複数のホップを通過する場合は、enable-real-ipをtrueに設定した後、remote_addrの値を確認できます。 値がクライアントIPアドレスの場合、X-Forwarded-Forヘッダーが有効になり、クライアントIPアドレスをIngressコントローラーポッドに渡します。 X-Forwarded-Forヘッダーが無効になっている場合は、リクエストがIngressコントローラポッドに到達する前に、X-Forwarded-Forヘッダーを有効にするか、他の方法を使用してリクエストにクライアントIPアドレスを追加します。

カナリアリリースルールが有効にならないのはなぜですか?

問題

クラスターにカナリアリリースルールを設定しますが、ルールは有効になりません。

原因

考えられる原因：

• canary-* アノテーションを追加する場合、nginx.ingress.kubernetes.io/canary: "true" は設定しません。

• NGINX Ingressコントローラーのバージョンが0.47.0より前です。 canary-* アノテーションを追加するときは、Ingressルールのホストフィールドでアプリケーションのドメイン名を指定しません。

解決策

• 上記の理由で問題が発生した場合は、nginx.ingress.kubernetes.io/canary: "true" を設定するか、Ingressルールのhostフィールドでアプリケーションのドメイン名を指定します。 詳細については、「NGINX Ingressコントローラーを使用したカナリアリリースとブルーグリーンリリースの実装」をご参照ください。

• 上記のいずれの理由でも問題が発生しない場合は、カナリアリリースルールに基づいてトラフィックが配信されない場合、または他のIngressからのトラフィックがカナリアサービスにルーティングされる場合はどうすればよいですか? このトピックのセクション。

カナリアリリースルールに基づいてトラフィックが配信されない場合、または他のIngressからのトラフィックがカナリアサービスにルーティングされる場合はどうすればよいですか?

問題

カナリアリリースルールを設定しましたが、トラフィックはカナリアリリースルールに基づいて配信されません。または、他のIngressからのトラフィックはカナリアサービスにルーティングされます。

原因

NGINX Ingressコントローラーのカナリアリリースルールは、カナリアリリースルールが作成されたサービスに関連付けられているすべてのIngressに対して有効になります。

この問題の詳細については、「カナリアのあるIngressは、同じサービスのすべてのIngressに影響を与えます」をご参照ください。

解決策

Canary Ingressには、service-matchアノテーションまたはcanary-* アノテーションが割り当てられたIngressが含まれます。 カナリアIngressを作成する前に、カナリアリリースに使用される同じサービスを2つ作成し、アクセスするバックエンドポッドにサービスをマップします。 詳細については、「NGINX Ingressコントローラーを使用したカナリアリリースとブルーグリーンリリースの実装」をご参照ください。

Ingressを作成したときに「webhookの呼び出しに失敗しました」というエラーが発生した場合はどうすればよいですか?

問題

Ingressを作成すると、「内部エラーが発生しました: webhookの呼び出しに失敗しました... 」というエラーが発生します。

原因

Ingressリソースを作成すると、Ingressが有効かどうかを確認するためにサービスが使用されます。 デフォルトでは、ingress-nginx-controller-admissionという名前のサービスが使用されます。 サービスやIngressコントローラーが削除されるなど、webhookリンクエラーが発生した場合、Ingressは作成できません。

解決策

• 次のwebhookリンクに基づいて、リソースが存在し、期待どおりに動作するかどうかを確認します。ValidatingWebhookConfiguration > Service > Pod。

• Ingressコントローラポッドで承認機能が有効になっていること、およびクラスターの外部に外部要求を送信することでポッドにアクセスできることを確認します。

• Ingressコントローラーが削除されている場合、またはwebhook機能を使用しない場合は、ValidatingWebhookConfigurationリソースを削除できます。

HTTPSリクエストに対してエラー "SSL_ERROR_RX_RECORD_TOO_LONG" が返された場合はどうすればよいですか?

問題

HTTPSリクエストに対して次のエラーのいずれかが返されます。SSL_ERROR_RX_RECORD_TOO_LONGまたはルーチン: CONNECT_CR_SRVR_HELLO: 間違ったバージョン番号。

原因

HTTPSリクエストは、HTTPポートなどの非HTTPSポートに配信されます。

解決策

HTTPSリクエストが適切なポートに配信されるように、SLBインスタンスまたはサービスの設定を変更します。

共通のHTTPステータスコードが返された場合はどうすればよいですか?

問題

2xx、3xx以外のHTTPステータスコード (502、503、413、499など) が返されます。

原因と解決策

ログを表示し、Ingressコントローラーからエラーが返されたかどうかを確認します。 詳細については、このトピックの「Simple log ServiceのNGINX Ingressコントローラポッドのアクセスログの診断」をご参照ください。 Ingressコントローラーからエラーが返された場合は、次のソリューションを使用します。

• 413エラー

  • 原因: リクエストサイズが上限を超えています。

  • 解決策: IngressコントローラーのConfigMapでproxy-body-sizeの値を大きくします。 proxy-body-sizeのデフォルト値は、オープンソースKubernetesのNGINX Ingressコントローラーの場合1 MBであり、proxy-body-sizeのデフォルト値は、ACKのNGINX Ingressコントローラーの場合20 MBです。

• 499エラー

  • 原因: クライアントは事前に接続を終了します。 このエラーは、Ingressコントローラーまたはバックエンドサービスが原因ではない可能性があります。

  • 解決策：

    • 499エラーが頻繁に発生せず、ワークロードに影響がない場合は、エラーを無視できます。

    • 499エラーが頻繁に発生する場合は、バックエンドポッドがリクエストを処理するのにかかる時間が、クライアントで設定されているリクエストタイムアウト期間を超えているかどうかを確認する必要があります。

• 502エラー

  • 原因: Ingressコントローラーがバックエンドポッドに接続できません。

  • 解決策：

    • 問題は時々発生します:

      • バックエンドポッドが期待どおりに機能するかどうかを確認します。 バックエンドポッドがオーバーロードされている場合は、バックエンドポッドを追加します。

      • デフォルトでは、IngressコントローラーはHTTP永続接続を使用してHTTP/1.1リクエストをバックエンドサービスに送信します。 バックエンドポッドに設定されたアイドル永続接続のタイムアウト期間が、Ingressコントローラーに設定されたタイムアウト期間よりも長いことを確認します。 デフォルトでは、タイムアウト時間は900秒に設定されています。

    • 問題は毎回発生します。

      サービスポートが有効かどうか、およびIngressコントローラポッドからサービスにアクセスできるかどうかを確認します。

    • 問題が解決しない場合は、パケットをキャプチャして分析し、

      チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。

• 503エラー

  • 原因: Ingressコントローラーがバックエンドポッドを検出できないか、Ingressコントローラーがすべてのバックエンドポッドにアクセスできません。

  • 解決策：

    • 問題は時々発生します:

      • 502エラーを解決するためのソリューションを参照してください。

      • バックエンドポッドのステータスを確認し、ヘルスチェックを設定します。

    • 問題は毎回発生します。

      サービス設定が有効かどうか、およびエンドポイントが存在するかどうかを確認します。

    • 上記の方法を使用して原因を特定できない場合は、

      チケットを起票してサポートセンターにお問い合わせくださいしてサポートセンターにお問い合わせください。

"net::ERR_HTTP2_SERVER_REFUSED_STREAM" というエラーが発生した場合はどうすればよいですか?

問題

Webサイトにアクセスすると、一部のリソースをロードできず、コンソールに次のエラーのいずれかが報告されます。net::ERR_HTTP2_SERVER_REFUSED_STREAMおよびnet::ERR_FAILED。

原因

リソースへの同時HTTP/2ストリームの数が上限に達しました。

解決策

• ConfigMapのhttp2-max-concurrentストリームの値をより大きな値に変更することを推奨します。 デフォルト値は 128 です。 詳細は、「http2-max-concurrentストリーム」をご参照ください。

• ConfigMapでuse-http2をfalseに設定して、HTTP/2を無効にします。 詳細は、「use-http2」をご参照ください。

エラー "The param of ServerGroupName is illegal" が発生した場合、Idは何をしますか?

原因

ServerGroupNameは、namespace + svcName + portの形式で生成されます。 サーバーグループ名は2 ~ 128文字で、英数字、ピリオド (.) 、アンダースコア (_) 、ハイフン (-) を使用できます。 先頭は英字とする必要があります。

解決策

サーバーグループ名を必要な形式で変更します。

Ingressの作成時に "certificate signed by unknown authority" エラーが発生した場合はどうすればよいですか?

原因

複数のIngressがクラスターにデプロイされ、IngressがSecrets、Services、webhook設定などの同じリソースを使用している場合、webhookがトリガーされたときにバックエンドサーバーとの通信に異なるSSL証明書が使用されるため、上記のエラーが発生します。

解決策

2つのIngressをデプロイし、Ingressが異なるリソースを使用するようにします。 Ingressで使用されるリソースの詳細については、ACKコンソールの [アドオン] ページでNGINX Ingressコントローラーを更新した後、システムで何が更新されますか?

ヘルスチェックに失敗した後、Ingressコントローラポッドが再起動するのはなぜですか?

問題

Ingressコントローラポッドは、ヘルスチェックに失敗すると再起動します。

原因

• Ingressコントローラポッドまたはポッドがデプロイされているノードがオーバーロードされています。 その結果、ポッドはヘルスチェックに合格しませんでした。

• tcp_tw_reuseやtcp_tw_timestampなどのカーネルパラメーターは、Ingressコントローラポッドがデプロイされているクラスターノードに設定できます。 これにより、ヘルスチェックが失敗する可能性があります。

解決策

• Ingressコントローラポッドを追加し、問題が解決しないか確認します。 詳細については、「高信頼性NGINX Ingressコントローラーのデプロイ」をご参照ください。

• tcp_tw_reuseを無効にするか、パラメーターの値を2に設定し、tcp_tw_timestampsを無効にして、問題が解決するかどうかを確認します。

TCPまたはUDPを使用するサービスを追加する方法?

1. tcp-servicesおよびudp-services ConfigMapsに特定のエントリを追加します。 デフォルトでは、ConfigMapsはkube-system名前空間に属します。

   次のサンプルコードでは、既定の名前空間のexample-goのポート8080をポート9000にマップする方法の例を示します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: tcp-services
     namespace: ingress-nginx
   data:
     9000: "default/example-go:8080"  # Map port 8080 to port 9000.

2. NGINX Ingressコントローラーの展開にポート9000を追加します。 デフォルトでは、Deploymentはnginx-ingress-controllerという名前で、kube-system名前空間に属します。

3. Ingressに関連付けられているサービスにポート9000を追加します。

   サンプルコードの表示

   apiVersion: v1
   kind: Service
   metadata:
     name: ingress-nginx
     namespace: ingress-nginx
     labels:
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx
   spec:
     type: LoadBalancer
     ports:
       - name: http
         port: 80
         targetPort: 80
         protocol: TCP
       - name: https
         port: 443
         targetPort: 443
         protocol: TCP
       - name: proxied-tcp-9000
         port: 9000
         targetPort: 9000
         protocol: TCP
     selector:
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx

   TCPまたはUDPを使用するサービスを追加する方法の詳細については、「TCPまたはUDPサービスの公開」をご参照ください。

Ingressルールが有効にならないのはなぜですか?

問題

Ingressルールを追加または変更した後、ルールは有効になりません。

原因

• Ingressの設定にエラーが含まれています。 その結果、IngressはIngressルールをロードできませんでした。

• Ingressリソースの設定にエラーが含まれています。

• Ingressコントローラーに必要な権限がありません。 その結果、IngressコントローラーはIngressリソースに加えられた変更を監視できません。

• 以前のIngressは、server-aliasフィールドで指定されたドメイン名を使用します。 ドメイン名が新しいIngressのドメイン名と競合しています。 その結果、Ingressルールは無視されます。

リクエストがルートディレクトリにリダイレクトされたときに、一部のwebページリソースの読み込みに失敗したり、空白の白い画面が返されたりするのはなぜですか。

問題

Ingressでrewrite-targetアノテーションを設定してリクエストを書き換えると、一部のwebページリソースを読み込むことができないか、バックエンドサービスにアクセスすると空白の白い画面が表示されます。

原因

• 正規表現ではrewrite-targetを設定しません。

• リクエストされたリソースのパスは、ルートディレクトリに設定されます。

解決策

• rewrite-targetが正規表現で使用されているかどうか、およびキャプチャグループが使用されているかどうかを確認します。 詳細については、「書き換え」をご参照ください。

• リクエストが期待されるパスにリダイレクトされるかどうかを確認します。

ingress-nginx-controllerの更新後にSimple Log Serviceがログを期待どおりに解析できない問題を修正するにはどうすればよいですか?

問題

ingress-nginx-controllerコンポーネントには、0.20と0.30の2つの一般的なバージョンがあります。 ACKコンソールの [アドオン] ページでingress-nginx-controllerを0.20から0.30に更新した後、Ingressを使用してカナリアリリースまたは青緑色リリースを実行すると、Ingressダッシュボードにはバックエンドサーバーへのリクエストの実際の統計が表示されません。

原因

ingress-nginx-controller 0.20のデフォルトのログ形式は、ingress-nginx-controller 0.30のそれとは異なります。 したがって、ingress-nginx-controllerを0.20から0.30に更新した後、Ingressダッシュボードには、Ingressを使用してカナリアリリースまたは青緑色リリースを実行すると、バックエンドサーバーへのリクエストの実際の統計が表示されない場合があります。

解決策

この問題を修正するには、次の手順を実行してnginx-configuration ConfigMapとk8s-nginx-ingressの設定を更新します。

1. nginx-configuration ConfigMapを更新します。

   • nginx-configuration ConfigMapを変更していない場合は、次の内容をnginx-configuration.yamlという名前のファイルにコピーし、kubectl apply -f nginx-configuration.yamlコマンドを実行してファイルをデプロイします。

     apiVersion: v1
     kind: ConfigMap
     data:
       allow-backend-server-header: "true"
       enable-underscores-in-headers: "true"
       generate-request-id: "true"
       ignore-invalid-headers: "true"
       log-format-upstream: $remote_addr - [$remote_addr] - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $request_time [$proxy_upstream_name] $upstream_addr $upstream_response_length $upstream_response_time $upstream_status $req_id $host [$proxy_alternative_upstream_name]
       max-worker-connections: "65536"
       proxy-body-size: 20m
       proxy-connect-timeout: "10"
       reuse-port: "true"
       server-tokens: "false"
       ssl-redirect: "false"
       upstream-keepalive-timeout: "900"
       worker-cpu-affinity: auto
     metadata:
       labels:
         app: ingress-nginx
       name: nginx-configuration
       namespace: kube-system

   • nginx-configuration ConfigMapを変更した場合は、次のコマンドを実行して設定を更新します。 これにより、以前の変更は上書きされません。

     kubectl edit configmap nginx-configuration -n kube-system

   log-format-upstreamフィールドに [$proxy_alternative_upstream_name] を追加し、変更を保存して終了します。

2. 変更します。Modify thek8s-nginx-ingress設定します。

   次のコンテンツをk8s-nginx-ingress.yamlという名前のファイルにコピーし、kubectl apply -f k8s-nginx-ingress.yamlコマンドを実行して、ingress-nginx-controllerコンポーネントをデプロイします。

   YAMLファイルの内容の表示

   apiVersion: log.alibabacloud.com/v1alpha1
   kind: AliyunLogConfig
   metadata:
     namespace: kube-system
     # your config name, must be unique in you k8s cluster
     name: k8s-nginx-ingress
   spec:
     # logstore name to upload log
     logstore: nginx-ingress
     # product code, only for k8s nginx ingress
     productCode: k8s-nginx-ingress
     # logtail config detail
     logtailConfig:
       inputType: plugin
       # logtail config name, should be same with [metadata.name]
       configName: k8s-nginx-ingress
       inputDetail:
         plugin:
           inputs:
           - type: service_docker_stdout
             detail:
               IncludeLabel:
                 io.kubernetes.container.name: nginx-ingress-controller
               Stderr: false
               Stdout: true
           processors:
           - type: processor_regex
             detail:
               KeepSource: false
               Keys:
               - client_ip
               - x_forward_for
               - remote_user
               - time
               - method
               - url
               - version
               - status
               - body_bytes_sent
               - http_referer
               - http_user_agent
               - request_length
               - request_time
               - proxy_upstream_name
               - upstream_addr
               - upstream_response_length
               - upstream_response_time
               - upstream_status
               - req_id
               - host
               - proxy_alternative_upstream_name
               NoKeyError: true
               NoMatchError: true
               Regex: ^(\S+)\s-\s\[([^]]+)]\s-\s(\S+)\s\[(\S+)\s\S+\s"(\w+)\s(\S+)\s([^"]+)"\s(\d+)\s(\d+)\s"([^"]*)"\s"([^"]*)"\s(\S+)\s(\S+)+\s\[([^]]*)]\s(\S+)\s(\S+)\s(\S+)\s(\S+)\s(\S+)\s*(\S*)\s*\[*([^]]*)\]*.*
               SourceKey: content

NGINX Ingressコントローラの一般的なエラーが発生した場合はどうすればよいですか?

発行

User "system:serviceaccount:kube-system:ingress-nginx" cannot list/get/update resource "xxx" in API group "xxx" at the cluster scope/ in the namespace "kube-system"

原因

NGINX Ingressコントローラーには、リソースを更新する権限がありません。

解決策

問題

requeuing……nginx: configuration file xxx test failed (multiple lines)

原因

IngressルールまたはConfigMapの構文エラーにより、NGINX設定のリロードに失敗しました。

解決策

問題

Unexpected error validating SSL certificate "xxx" for server "xxx"

原因

証明書に関連付けられているドメイン名がIngressで指定されているドメイン名と異なるため、証明書構成エラーが発生します。 警告レベルでいくつかの証明書エラーが発生した場合、期待どおりに証明書を使用し続けることができます。 たとえば、証明書にSAN属性がないことをシステムが要求した場合でも、証明書を引き続き使用できます。

解決策

NGINX Ingressコントローラーに未クリーニングの構成ファイルが多数存在する場合はどうすればよいですか?

問題

1.10より前のバージョンのNginx Ingressコントローラーに既知のバグが存在します。通常の状況では、生成されたnginx-cfgファイルは時間内にクリーンアップされます。 Ingressが正しく構成されておらず、nginx.confファイルに問題が発生した場合、正しくない構成ファイルを期待どおりにクリアすることはできません。 その結果、nginx-cfgxxxファイルは徐々に蓄積され、大量のディスク容量を消費します。

原因

問題の原因は、クリーンアップロジックの欠陥です。 正しく生成された構成ファイルはクリーンアップされますが、無効な構成ファイルが生成されるシナリオではクリーンアップメカニズムは機能しません。 詳細については、「clean nginx temp configs function does not work #11568」をご参照ください。

解決策

この問題を解決するには、次のソリューションを使用します。

• Nginx Ingressコントローラーの更新: Nginx Ingressコントローラーのバージョンを1.10以降に更新することを推奨します。 詳細については、「NGINX Ingressコントローラーの更新」をご参照ください。

• 古いファイルを手動でクリーンアップする: クリーンアップされていないnginx-cfgxxxファイルを定期的に手動で削除できます。 手動操作の負担を軽減するために、プロセスを自動化するスクリプトを作成できます。

• 構成エラーの確認: 新しいIngress構成を適用する前に、無効な構成ファイルが生成されないように、構成の正確性を慎重に確認してください。

NGINX Ingressコントローラーの更新後にポッドが継続保留状態になった場合はどうすればよいですか。

問題

Nginx Ingressコントローラーを更新すると、ポッドがスケジュールされない場合があります。 ポッドは長期間保留状態のままです。

原因

Nginx Ingressコントローラーを更新すると、ノードのアフィニティとポッドのアンチアフィニティのルールがデフォルトで設定されます。 その結果、新しいバージョンのポッドがスケジュールされない場合があります。 クラスターに十分なリソースがあることを確認してください。

次のコマンドを実行して、特定の原因を表示できます。

kubectl -n kube-system describe pod <pending-pod-name>

kubectl -n kube-system get events

解決策

この問題を解決するには、次のソリューションを使用できます。

• クラスターリソースのスケールアウト: アフィニティルールの要件を満たす新しいノードを追加します。 詳細については、「ノードプールの手動スケーリング」をご参照ください。

• アフィニティの調整: リソースが厳しい場合は、kubectl edit deploy nginx-ingress-controller -n kube-systemコマンドを実行して、ポッドを同じノードにスケジュールできるように、アフィニティ対策要件を調整できます。 この方法は、コンポーネントの高可用性を低下させ得る。

  サンプルコードの表示

        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:   ## Replace with preferredDuringSchedulingIgnoredDuringExecution. 
              - labelSelector:
                  matchExpressions:
                  - key: app
                    operator: In
                    values:
                    - ingress-nginx
                topologyKey: "kubernetes.io/hostname"
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                # virtual nodes have this label
                - key: type
                  operator: NotIn
                  values:
                  - virtual-kubelet
            preferredDuringSchedulingIgnoredDuringExecution:
            - preference:
                matchExpressions:
                # autoscaled nodes have this label
                - key: k8s.aliyun.com
                  operator: NotIn
                  values:
                  - "true"
              weight: 100

FlannelとIPVSで構築されたクラスターで使用されるNGINX Ingressコントローラーが、複数のCLBインスタンス間でTCPトラフィックの問題を引き起こす場合はどうすればよいですか。

問題

FlannelとIPVSを使用するACKクラスターでは、Nginx Ingressコントローラーが複数のClassic Load Balancer (CLB) インスタンスにバインドされている場合、同時実行時にTCPトラフィックの問題が発生する可能性があります。 以下の異常は、パケットキャプチャによって観察することができる。

• パケットの再送信

• 異常なTCP接続リセット

原因

Flannelを使用するACKクラスターでは、CLBはNginx Ingressコントローラーが存在するノードのNodePortにトラフィックを転送します。 ただし、複数のサービスが異なるNodePortsを使用する場合、IPVSセッションは高同時性シナリオで競合する可能性があります。

解決策

• 単一Server Load Balancerポリシー: Load Balancerサービス用にNginx Ingressコントローラーを1つだけ作成します。 競合の可能性を減らすために、他のCLBインスタンスをノードのNodePortに手動でバインドします。

• 複数のNodePortsが同時に有効になるのを防ぐ: IPVSセッションの競合のリスクを減らすために、同じノードで複数のNodePortsが同時に有効になるのを防ぐようにしてください。