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

目次

背景情報

Container Service for Kubernetes (ACK) は、オープンソースバージョンに基づいて最適化されたNGINX Ingressコントローラーを提供します。 ACKによって提供されるNGINX Ingressコントローラは、オープンソースバージョンと互換性があり、オープンソースバージョンによって提供されるすべての注釈をサポートします。 ACKクラスターの作成時に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 loadコマンドを実行して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コントローラーのアクセスログが表示されるページを示しています。 詳細については、「Simple log Serviceを使用してコンテナーからログデータを収集する」トピックの手順4: ログデータの表示セクションを参照してください。

kubectl logs <コントローラポッド名> -n <namespace> | 少ない

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 <コントローラポッド名> -n <namespace> | grep -E ^[WE]

  説明

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

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

  kubectl logs <コントローラポッド名> -n <namespace> | grepエラー

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

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

   kubectl exec <コントローラポッド名> -n <namespace> -it -- bash

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

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

     # Ingressの実際のドメイン名でe your.domain.comを再生します。 
     curl -H "ホスト: your.domain.com" http:// 127.0.**/ # for http
     curl -- resolv e your.domain.com:443:127。0.0.1 https:// 127.0.0.1/ # for https 

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

     openssl s_client -servernam e 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ノードNOMINATED NOMINATED NODE READINESS GATES
        nginx-dp-7f5fcc7f-**** 1/1実行0 23時間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任意のホスト <アプリケーションポッドまたはIngressコントローラポッドのIPアドレス> -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アドレスは、クラスター内の他のノードのポッドからアクセスできません。 LoadBalancerサービスのIPアドレスは、Kubernetesクラスターへの外部アクセスを有効にします。 ACKクラスター内のノードまたはポッドがセカンドホップを使用せずにIPアドレスにアクセスできない場合、リクエストはLoadBalancerサービスを通過しません。 その結果、LoadBalancerサービスのIPアドレスは、LoadBalancerサービスを使用するサービスの拡張IPアドレスと見なされます。 リクエストは、iptablesまたはIP仮想サーバー (IPVS) に基づくkube-proxyによって転送されます。

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

解決策

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

  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
  種類: サービス
  メタデータ:
    アノテーション：
      service.beta.kubernetes.io/backend-type: eni# バックエンドサーバーとしてeniが割り当てられているポッドを指定します。 
    ラベル：
      アプリ: nginx-ingress-lb
    名前: nginx-ingress-lb
    名前空間: kube-system
  spec:
    externalTrafficPolicy: クラスター 

  サービス注釈の詳細については、「注釈を使用してCLBインスタンスを構成する」をご参照ください。

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

問題

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

原因

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

解決策

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

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

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

     kubectl edit cm kube-フランネル-cfg -n kube-system

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

     サンプルコード：

     cni-conf.json: |
         {
           "name": "cb0" 、
           "cniVersion":"0.3.1" 、
           "type": "フランネル" 、
           "delegate": {
             "isDefaultGateway": true、
             "hairpinMode": true
           }
         }

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

     kubectl delete pod -n kube-system -l app=フランネル

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コントローラーを更新した後、システムで何が更新されますか? 「Nginx Ingress FAQ」トピックのセクション。

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

問題

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

原因

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

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

解決策

• Ingressコントローラポッドを追加し、問題が解決しないか確認します。 詳細については、「高信頼性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
   メタデータ:
     名前: tcp-services
     名前空間: ingress-nginx
   データ:
     9000: "default/example-go:8080"# ポート8080をポート9000にマップします。

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

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

   サンプルコードの表示

   apiVersion: v1
   種類: サービス
   メタデータ:
     名前: ingress-nginx
     名前空間: ingress-nginx
     ラベル：
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx
   spec:
     type: LoadBalancer
     ポート：
       - name: http
         port: 80
         targetPort: 80
         protocol: TCP
       - name: https
         port: 443
         targetPort: 443
         protocol: TCP
       -name: proxied-tcp-9000
         ポート: 9000
         targetPort: 9000
         protocol: TCP
     セレクタ：
       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がログを期待どおりに解析できない問題を修正するにはどうすればよいですか?

問題

バージョン0.20および0.30のingress-nginx-controllerコンポーネントが一般的に使用されます。 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
     データ:
       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_stream_local] "$request" $status $body_bytese_sent "$http_user_agent" $http_user_length $request_length $response_upse_proq_$ $$upserge_time] [$pro_case]
       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
     メタデータ:
       ラベル：
         app: ingress-nginx
       name: nginx-configuration
       名前空間: 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
   メタデータ:
     namespace: kube-system
     ＃あなたの設定名は、k8sクラスタ内でユニークでなければなりません
     名前: k8s-nginx-ingress
   spec:
     ＃ログをアップロードするためのログストア名
     logstore: nginx-ingress
     # product code, only for k8s nginx ingress
     productCode: k8s-nginx-ingress
     ＃logtail 設定の詳細
     logtailConfig：
       inputType：プラグイン
       ＃logtailの設定名は、[metadata.name]と同じでなければなりません
       configName: k8s-nginx-ingress
       inputDetail：
         プラグイン：
           入力：
           - type: service_docker_stdout
             詳細：
               IncludeLabel:
                 io.kubernetes.container.name: nginx-ingress-controller
               標準エラー：false
               Stdout：true
           プロセッサ:
           - type: processor_regex
             詳細：
               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 +)\d +)\s "([^"]*)"\s"([^ "]*)"\s(\S +)\s(\S +)\s(\s +)+ \S [([^]]*)]\s(\S +)\s(\S +)\s(\S +))\s(\S +)\s *(\S *)\s *\[*([^]]*)\]*.*
               SourceKey: コンテンツ 

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

発行

ユーザー「system:serviceaccount:kube-system:ingress-nginx」は、APIグループ「xxx」のリソース「xxx」をクラスタースコープ /名前空間「kube-system」に一覧表示 /取得 /更新できません

原因

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

解決策

問題

requeuing……nginx: 設定ファイルxxxテストに失敗しました (複数行)

原因

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

解決策

問題

サーバー「xxx」のSSL証明書「xxx」の予期しないエラー検証

原因

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

解決策