Container Service for Kubernetes:Nginx Ingress の問題のトラブルシューティング

内容

背景情報

Container Service for Kubernetes (ACK) は、オープンソースバージョンに基づいて最適化された NGINX Ingress controller を提供し、完全な互換性とすべてのコミュニティ アノテーションのサポートを備えています。

Ingress が正常に機能するのは、クラスターに NGINX Ingress controller をデプロイして Ingress のルーティングルールを解析する場合のみです。NGINX Ingress controller がルーティングルールに一致するリクエストを受信すると、NGINX Ingress controller はリクエストを対応するバックエンドサービスにルーティングします。バックエンドサービスは、リクエストを Pod に転送します。Kubernetes クラスターでは、サービス、Ingress、および NGINX Ingress controller は次のプロセスで動作します:

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

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

• NGINX Ingress controller は、Ingress ルールを解析するリバースプロキシプログラムです。Ingress ルールに変更が加えられると、NGINX Ingress controller はそれに応じて Ingress ルールを更新します。NGINX Ingress controller がリクエストを受信すると、Ingress ルールに基づいてリクエストをサービス Pod にリダイレクトします。

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

診断プロセス

1. 次の手順に従って、問題が Ingress によって引き起こされているかどうかを確認し、Ingress Controller が正しく構成されていることを確認します。

   1. Controller Pod で、アクセスが期待どおりに機能することを確認します。詳細については、「Controller Pod から Ingress およびバックエンド Pod に手動でアクセスする」をご参照ください。

   2. Nginx Ingress Controller が正しく使用されていることを確認します。詳細については、「Nginx Ingress コミュニティドキュメント」をご参照ください。

2. Ingress 診断機能を使用して Ingress とコンポーネントの構成を確認し、推奨される変更を適用します。Ingress 診断機能の詳細については、「Ingress 診断機能を使用する」をご参照ください。

3. トラブルシューティングの考え方 に従って、関連する問題を特定して解決します。

4. 問題が解決しない場合は、次のチェックを実行します:

   • HTTPS 証明書の問題の場合:

     1. ドメイン名に対して透過的プロキシモードの WAF が有効になっているかどうかを確認します。

        • 有効になっている場合は、WAF または透過的プロキシモードの WAF に TLS 証明書が設定されていないことを確認します。

        • 有効になっていない場合は、次のステップに進みます。

     2. SLB インスタンスがレイヤー 7 リスナーを使用しているかどうかを確認します。

        • 使用している場合は、SLB インスタンスのレイヤー 7 リスナーに TLS 証明書が設定されていないことを確認します。

        • 使用していない場合は、次のステップに進みます。

   • HTTPS 証明書以外の問題については、Controller Pod のエラーログを確認します。詳細については、「Controller Pod のエラーログを確認する」をご参照ください。

5. 問題が解決しない場合は、Controller Pod と対応するバックエンドアプリケーション Pod でパケットをキャプチャして問題を特定します。詳細については、「パケットをキャプチャする」をご参照ください。

トラブルシューティングの考え方

一般的な検査方法

$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]

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.**.**[]

パケットをキャプチャする

問題を特定できない場合は、さらなる診断のためにパケットをキャプチャする必要があります。

1. 最初の問題の場所に基づいて、ネットワークの問題が Ingress Pod にあるか、アプリケーション Pod にあるかを判断します。情報が不十分な場合は、両方からパケットをキャプチャできます。

2. 問題のあるアプリケーション Pod または Ingress Pod があるノードにログインします。

3. ECS インスタンス (コンテナー内ではない) で、次のコマンドを実行して Ingress トラフィック情報をファイルにキャプチャします。

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

4. ログを監視します。予期されるエラーが発生したら、パケットのキャプチャを停止します。

5. アプリケーションログのエラーメッセージを使用して、エラーの正確な時刻に対応するメッセージを特定します。

   説明

   • 通常の状況では、パケットキャプチャはアプリケーションに影響を与えません。CPU 負荷とディスク書き込みがわずかに増加するだけです。

   • 上記のコマンドは、キャプチャされたパケットをローテーションします。最大 200 個の .pcap ファイルを書き込むことができ、各ファイルのサイズは 20 MB です。

クラスター内からクラスター LoadBalancer の外部アドレスにアクセスできない

症状

クラスター内の一部のノード上の一部の Pod が、Nginx Ingress Controller の外部アドレス (SLB インスタンスの IP アドレス) を介してバックエンド Pod にアクセスできない場合がありますが、他の Pod はアクセスできます。

原因

この問題は、Controller のサービスの externalTrafficPolicy 構成が原因です。この構成は、外部トラフィックの処理方法を決定します。local に設定すると、Controller の Pod と同じノード上のバックエンド Pod のみがリクエストを受信できます。cluster に設定すると、アクセスは成功します。外部 LoadBalancer アドレスを使用してサービスにアクセスするクラスター内のリソースからのリクエストも、外部トラフィックとして扱われます。

解決策

• (推奨) Kubernetes クラスター内のサービスに、その ClusterIP または Ingress サービス名を使用してアクセスします。Ingress サービス名は nginx-ingress-lb.kube-system です。

• kubectl edit svc nginx-ingress-lb -n kube-system コマンドを実行して Ingress サービスを変更します。LoadBalancer サービスで externalTrafficPolicy を Cluster に設定します。クラスターのコンテナーネットワークプラグインが Flannel の場合、クライアントの送信元 IP アドレスは失われます。Terway を使用する場合、送信元 IP アドレスは保持できます。

• 例:

  apiVersion: v1
  kind: Service
  metadata:
    annotations:
      service.beta.kubernetes.io/backend-type: eni   # Direct ENI access.
    labels:
      app: nginx-ingress-lb
    name: nginx-ingress-lb
    namespace: kube-system
  spec:
    externalTrafficPolicy: Cluster

  サービスアノテーションの詳細については、「アノテーションを使用して Classic Load Balancer (CLB) インスタンスを構成する」をご参照ください。

Ingress Controller 自体にアクセスできない

症状

Flannel クラスターの場合、ドメイン名、SLB IP アドレス、または ClusterIP を使用して自身の Pod 内から Ingress にアクセスすると、一部またはすべてのリクエストが失敗します。

原因

Flannel のデフォルト構成では、ループバックアクセスが許可されていません。

解決策

• (推奨) 可能であれば、クラスターを再作成し、Terway ネットワークプラグインを使用します。既存のクラスターのアプリケーションを Terway モードのクラスターに移行します。

• クラスターを再作成できない場合は、Flannel 構成を変更して hairpinMode を有効にすることで問題を解決できます。構成を変更した後、Flannel Pod を再作成して変更を有効にします。

  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 を削除し、再作成します。

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

クラスターで TLS 証明書が追加または変更されたが、アクセスにはデフォルトまたは古い証明書がまだ使用されている

症状

クラスターに Secret を追加または変更し、Ingress で secretName を指定した後、Ingress にアクセスすると、まだデフォルトの証明書 (Kubernetes Ingress Controller Fake Certificate) または古い証明書が使用されます。

原因

• 証明書がクラスター内の Ingress Controller によって返されていません。

• 証明書が無効で、Controller によって正しく読み込まれませんでした。

• Ingress Controller は、サーバ名表示 (SNI) に基づいて対応する証明書を返しますが、TLS ハンドシェイク中に SNI が含まれていなかった可能性があります。

解決策

• 次のいずれかの方法を使用して、TLS 接続の確立時に SNI フィールドが含まれていたかどうかを確認します:

  • SNI をサポートする新しいバージョンのブラウザを使用します。

  • openssl s_client コマンドを使用して証明書をテストする場合は、-servername パラメーターを含めます。

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

• WAF、透過的プロキシモードの WAF、または SLB レイヤー 7 リスナーに TLS 証明書が設定されていないことを確認します。TLS 証明書は、クラスター内の Ingress Controller によって返される必要があります。

• ACK コンソールで Ingress 診断を実行して、構成エラーとエラーログを確認します。詳細については、「Ingress 診断機能を使用する」をご参照ください。

• 次のコマンドを実行して、Ingress Pod のエラーログを手動で表示し、ログに基づいて修正を適用します。

  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"。

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

バックエンド HTTPS サービスに接続できない

症状

• Ingress を介してバックエンド HTTPS サービスにアクセスできません。

• 応答が 400 エラーで、メッセージが The plain HTTP request was sent to HTTPS port である可能性があります。

原因

Ingress Controller からバックエンド Pod へのリクエストは、デフォルトの HTTP プロトコルを使用します。

解決策

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

Ingress Pod で送信元 IP アドレスを保持できない

症状

クライアントの実際の IP アドレスが Ingress Pod に保持されません。ノードの IP アドレス、100.XX.XX.XX の範囲のアドレス、または別のアドレスとして表示されます。

原因

• Ingress で使用されるサービスの externalTrafficPolicy が Cluster に設定されています。

• SLB インスタンスでレイヤー 7 プロキシが使用されています。

• 透過的プロキシモードの WAF が使用されています。

解決策

• externalTrafficPolicy が Cluster に設定され、フロントエンドでレイヤー 4 SLB インスタンスが使用されている場合。

  externalTrafficPolicy を Local に変更できます。ただし、これにより、クラスター内から SLB IP アドレスを使用して Ingress にアクセスしようとすると失敗する可能性があります。解決策については、「クラスター内からクラスター LoadBalancer の外部アドレスにアクセスできない」をご参照ください。

• レイヤー 7 プロキシ (レイヤー 7 SLB、WAF、または透過的プロキシモードの WAF) が使用されている場合は、次の手順に従います:

  1. レイヤー 7 プロキシが使用され、X-Forwarded-For リクエストヘッダーが有効になっていることを確認します。

  2. Ingress Controller の ConfigMap (デフォルトは kube-system 名前空間の nginx-configuration) に、enable-real-ip: "true" を追加します。

  3. ログを監視して、送信元 IP アドレスが取得できるかどうかを確認します。

• 複数の転送がある長いリンクパス (たとえば、Ingress Controller の前にリバースプロキシサービスが追加で構成されている) の場合、enable-real-ip を有効にした後、ログの remote_addr の値を監視して、実際の IP アドレスが X-Forwarded-For リクエストヘッダーを介して Ingress コンテナーに渡されているかどうかを判断できます。そうでない場合は、リクエストが Ingress Controller に到達する前に、X-Forwarded-For などの方法でクライアントの実際の IP アドレスが運ばれるようにします。

段階的リリースルールが有効にならない

症状

クラスターに段階的リリースが設定されていますが、段階的リリースルールが有効になりません。

原因

考えられる理由は 2 つあります:

• canary-* 関連のアノテーションを使用する場合、nginx.ingress.kubernetes.io/canary: "true" が設定されていません。

• 0.47.0 より前の Nginx Ingress Controller バージョンで canary-* 関連のアノテーションを使用する場合、Ingress ルールの Host フィールドにアプリケーションのドメイン名を指定する必要があります。空にすることはできません。

解決策

• 原因に基づいて、Ingress ルールの nginx.ingress.kubernetes.io/canary: "true" または Host フィールドを変更します。詳細については、「ルーティングルール」をご参照ください。

• 上記に該当しない場合は、「段階的リリースルールに基づいてトラフィックが分散されない、または他のトラフィックが段階的リリースサービスにルーティングされる」をご参照ください。

段階的リリースルールに基づいてトラフィックが分散されない、または他のトラフィックが段階的リリースサービスにルーティングされる

症状

段階的リリースルールが設定されていますが、ルールに従ってトラフィックが分散されない、または他の通常の Ingress からのトラフィックが段階的リリースサービスにルーティングされます。

原因

Nginx Ingress Controller では、段階的リリースルールは単一の Ingress に適用されるのではなく、同じサービスを使用するすべての Ingress に適用されます。

この問題の詳細については、「Ingress with canary annotation will affect all ingresses with same service」をご参照ください。

解決策

段階的リリースが必要な Ingress (service-match および canary-* 関連のアノテーションを使用するものを含む) については、元の Pod を指す個別のサービス (本番サービスと段階的リリースサービスの両方) を作成します。次に、その Ingress の段階的リリースを有効にします。詳細については、「Nginx Ingress を使用して段階的リリースとブルーグリーンデプロイメントを実装する」をご参照ください。

Ingress リソースを作成するときに「failed calling webhook」エラーが報告される

症状

Ingress リソースを追加すると、次の図に示すように、「Internal error occurred: failed calling webhook...」というメッセージが表示されます。

原因

Ingress リソースが追加されると、その有効性はサービス (デフォルトでは ingress-nginx-controller-admission) によって検証される必要があります。リンクに問題がある場合 (たとえば、サービスが削除されたり、Ingress controller が削除されたりした場合)、検証は失敗し、Ingress リソースは追加できません。

解決策

• Webhook リンクをチェックして、すべてのリソースが存在し、正しく機能していることを確認します。リンクは ValidatingWebhookConfiguration -> Service -> Pod です。

• Ingress Controller Pod の admission 機能が有効になっており、Pod が外部からアクセスできることを確認します。

• Ingress Controller が削除されたか、Webhook 機能が不要な場合は、ValidatingWebhookConfiguration リソースを直接削除できます。

HTTPS アクセスで SSL_ERROR_RX_RECORD_TOO_LONG エラーが報告される

症状

HTTPS 経由でアクセスすると、SSL_ERROR_RX_RECORD_TOO_LONG または routines:CONNECT_CR_SRVR_HELLO:wrong version number エラーが報告されます。

原因

HTTPS リクエストが、HTTP ポートなどの非 HTTPS ポートにアクセスしています。

解決策

必要に応じて SLB 設定またはサービス設定を変更して、HTTPS が正しいポートにアクセスできるようにします。

一般的な HTTP エラーコードが表示される

症状

リクエストは、502、503、413、499 などの 2xx または 3xx 以外のステータスコードを返します。

原因と解決策

ログをチェックして、エラーが Ingress Controller によって返されたかどうかを判断します。詳細については、「Simple Log Service (SLS) を使用して Controller Pod のアクセスログを表示する」をご参照ください。その場合は、次の解決策を参照してください:

• 413 エラー

  • 原因: リクエストデータのサイズが構成された制限を超えています。

  • 解決策: kubectl edit cm -n kube-system nginx-configuration を実行して Controller 構成を変更します。必要に応じて nginx.ingress.kubernetes.io/client-max-body-size と nginx.ingress.kubernetes.io/proxy-body-size の値を調整します。デフォルト値は 20m です。

• 499 エラー

  • 原因: サーバーが応答を送信する前にクライアントが切断しました。これは必ずしもコンポーネントやバックエンドアプリケーションの問題ではありません。

  • 解決策:

    • 少数の 499 エラーは、アプリケーションによっては正常な場合があり、無視できます。

    • 多くの 499 エラーが発生する場合は、バックエンドアプリケーションの処理時間とフロントエンドリクエストのタイムアウトが期待どおりかどうかを確認します。

• 502 エラー

  • 原因: Nginx Ingress は正しく機能していますが、Nginx Ingress Pod がターゲットのバックエンド Pod に接続できません。

  • 解決策:

    • トリガー条件:

      • バックエンドサービスと Pod の構成が正しくない可能性があります。バックエンドサービスのポート構成とコンテナー内のアプリケーションコードを確認します。

    • 断続的な問題

      • Nginx Ingress Controller の Pod の負荷が高い可能性があります。Controller の SLB インスタンスのリクエスト数と接続数を確認して負荷を評価し、必要に応じて Controller にリソースを追加できます。詳細については、「高可用性 Nginx Ingress Controller のデプロイ」をご参照ください。

      • バックエンド Pod がセッションを積極的に閉じている可能性があります。Nginx Ingress Controller はデフォルトで持続的接続を有効にします。バックエンドの持続的接続のアイドルタイムアウトが Controller のアイドルタイムアウト (デフォルトは 900 秒) より大きいことを確認します。

    • これらの方法で問題が特定できない場合は、キャプチャしたパケットを分析します。

• 503 エラー

  • 原因: Ingress Controller がリクエストをルーティングするための利用可能なバックエンド Pod を見つけられません。

  • 解決策:

    • まれなシナリオ

      • 502 エラーの解決策を参照してください。

      • バックエンドアプリケーションの準備完了ステータスを確認し、適切なヘルスチェックを構成します。

    • エラーが持続する場合:

      バックエンドサービスが正しく構成されているか、およびエンドポイントが存在するかどうかを確認します。

net::ERR_HTTP2_SERVER_REFUSED_STREAM エラーが発生する

症状

Web ページにアクセスすると、一部のリソースが正しく読み込まれず、コンソールに net::ERR_HTTP2_SERVER_REFUSED_STREAM または net::ERR_FAILED エラーが表示されます。

原因

並列リソースリクエストの数が多く、HTTP/2 の最大同時ストリーム制限に達しています。

解決策

• (推奨) ConfigMap で、必要に応じて http2-max-concurrent-streams の値を増やします。デフォルトは 128 です。詳細については、「http2-max-concurrent-streams」をご参照ください。

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

「The param of ServerGroupName is illegal」エラーが発生する

原因

ServerGroupName を生成するためのフォーマットは namespace+svcName+port です。サーバーグループ名は 2〜128 文字の長さで、文字または漢字で始まり、数字、ピリオド (.)、アンダースコア (_)、およびハイフン (-) を含めることができます。

解決策

サーバーグループの命名要件に準拠するように名前を変更します。

Ingress を作成するときに「certificate signed by unknown authority」エラーが報告される

原因

Ingress を作成すると、前の図に示されているエラーが発生します。これは、複数の Ingress controller がデプロイされ、それらが同じリソース (Secret、サービス、Webhook 構成などを含む場合があります) を使用しているためです。これにより、Webhook の実行中に使用される SSL 証明書がバックエンドサービスと一致しなくなり、エラーが発生します。

解決策

2 つの Ingress controller を再デプロイし、それらのリソースが重複しないようにします。Ingress に含まれるリソースの詳細については、「ACK コンポーネント管理で Nginx Ingress Controller コンポーネントをアップグレードすると、システムにどのような更新が行われますか？」をご参照ください。

ヘルスチェックに失敗したため Ingress Pod が再起動する

症状

Controller Pod がヘルスチェックに失敗し、再起動します。

原因

• Ingress Pod またはそのノードの負荷が高く、ヘルスチェックが失敗します。

• クラスターノードで tcp_tw_reuse または tcp_timestamps カーネルパラメーターが設定されているため、ヘルスチェックが失敗する可能性があります。

解決策

• Ingress Pod をスケールアウトし、問題が解決するかどうかを監視します。詳細については、「Nginx Ingress Controller の高可用性デプロイメント」をご参照ください。

• tcp_tw_reuse を無効にするか、2 に設定し、tcp_timestamps も無効にします。その後、問題が解決するかどうかを監視します。

TCP および UDP サービスを追加する

1. 対応する ConfigMap (デフォルトでは、kube-system 名前空間の tcp-services と udp-services) に、対応するエントリを追加します。

   たとえば、デフォルト名前空間の example-go のポート 8080 をポート 9000 にマッピングするには、次の例を参照してください。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: tcp-services
     namespace: ingress-nginx
   data:
     9000: "default/example-go:8080"  # ポート 8080 をポート 9000 にマッピングします。

2. Ingress デプロイメント (デフォルトでは、kube-system 名前空間の nginx-ingress-controller) に、マッピングされたポートを追加します。

3. Ingress に対応するサービスに、マッピングされたポートを追加します。

   クリックしてサンプルコードを表示

   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 Controller に権限の問題があり、Ingress リソースの変更を正しく監視できません。

• 古い Ingress が、新しい Ingress と競合するドメイン名に server-alias 構成を使用しているため、ルールが無視されます。

ルートディレクトリへの書き換え後に一部のリソースの読み込みに失敗するか、空白の画面が表示される

症状

Ingress rewrite-target アノテーションを使用してアクセスを書き換えた後、一部のページリソースの読み込みに失敗するか、空白の画面が表示されます。

原因

• rewrite-target が正規表現で構成されていない可能性があります。

• アプリケーションのリソースリクエストパスがルートディレクトリにハードコーディングされています。

解決策

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

• フロントエンドリクエストが正しいパスにアクセスしているかどうかを確認します。

アップグレード後に SLS での異常なログ解析を修正する方法

症状

ingress-nginx-controller コンポーネントには現在、0.20 と 0.30 の 2 つの主要なバージョンがあります。コンソールの [コンポーネント] ページからバージョン 0.20 から 0.30 にアップグレードした後、Ingress の段階的リリースまたはブルーグリーンデプロイメント機能を使用すると、Ingress ダッシュボードが実際のバックエンドサービスのアクセスステータスを正しく表示しない場合があります。

原因

バージョン 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. k8s-nginx-ingress 構成を更新します。

   次の内容を k8s-nginx-ingress.yaml ファイルとして保存し、kubectl apply -f k8s-nginx-ingress.yaml コマンドを実行してデプロイします。

   クリックして 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

「cannot list/get/update resource」エラーが発生する

症状

Controller Pod のエラーログを確認する で説明されている方法を使用して、Pod 内の Controller エラーログを見つけることができます。ログは次のようになります:

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 Controller には、関連するリソースを更新するために必要な権限がありません。

解決策

• ログに基づいて、問題が ClusterRole または Role によって引き起こされているかどうかを判断します。

  • ログに at the cluster scope が含まれている場合、問題は ClusterRole (ingress-nginx) にあります。

  • ログに in the namespace "kube-system" が含まれている場合、問題は Role (kube-system/ingress-nginx) にあります。

• 対応する権限と権限バインディングが完全であることを確認します。

  • ClusterRole の場合:

    • ClusterRole ingress-nginx と ClusterRoleBinding ingress-nginx が存在することを確認します。存在しない場合は、作成、復元、またはコンポーネントのアンインストールと再インストールができます。

    • ClusterRole ingress-nginx にログに対応する権限 (この例では、networking.k8s.io/ingresses の List 権限) が含まれていることを確認します。権限が存在しない場合は、手動で ClusterRole に追加できます。

  • Role の場合:

    • Role kube-system/ingress-nginx と RoleBinding kube-system/ingress-nginx が存在することを確認します。存在しない場合は、作成、復元、またはコンポーネントのアンインストールと再インストールができます。

    • Role ingress-nginx にログに対応する権限 (この例では、ConfigMap ingress-controller-leader-nginx の Update 権限) が含まれていることを確認します。権限が存在しない場合は、手動で Role に追加できます。

「configuration file failed」エラーが発生する

症状

Controller Pod のエラーログを確認する で説明されている方法を使用して、Pod 内の Controller エラーログを見つけることができます。ログは次のようになります:

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

原因

構成エラーにより、Nginx 構成の再読み込みが失敗しました。これは通常、Ingress ルールまたは ConfigMap に挿入されたスニペットの構文エラーが原因です。

解決策

• ログのエラーメッセージを確認して (警告レベルのメッセージは無視できます)、問題をおおよそ特定します。エラーメッセージが明確でない場合は、エラーメッセージのファイル行番号を使用して、Pod 内の対応するファイルを表示できます。次の例では、ファイルは /tmp/nginx/nginx-cfg2825306115 で、行は 449 です。

  次のコマンドを実行して、対応する行の近くの構成にエラーがないか確認します。

  # Pod でコマンドを実行します。
  kubectl exec -n <namespace> <controller pod name> -it -- bash
  # エラーファイルを番号付きで表示し、対応する行の近くの構成にエラーがないか確認します。
  cat -n /tmp/nginx/nginx-cfg2825306115

• エラーメッセージと構成ファイルに基づいて、エラーの原因を特定し、実際の構成に従って修正します。

「Unexpected error validating SSL certificate」エラーが発生する

症状

Controller Pod のエラーログを確認する で説明されている方法を使用して、Pod 内の Controller エラーログを見つけることができます。ログは次のようになります:

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

原因

証明書の構成が正しくありません。一般的な理由は、証明書に含まれるドメイン名が Ingress で構成されたドメイン名と一致しないことです。証明書に SAN 拡張がないなど、一部の警告レベルのログは、証明書の通常の使用に影響を与えません。実際状況に基づいて問題があるかどうかを判断します。

解決策

エラーメッセージに基づいて、クラスター内の証明書の問題を確認します。

• 証明書の cert と key のフォーマットと内容は正しいですか？

• 証明書に含まれるドメイン名は、Ingress で構成されたドメイン名と一致しますか？

• 証明書は期限切れですか？

多くの構成ファイルが Controller からクリアされない

Controller のアップグレード後に Pod が Pending 状態のままになる問題のトラブルシューティング

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

kubectl -n kube-system get events

高同時実行性の Flannel CNI および IPVS クラスターで Nginx Ingress に複数の CLB インスタンスを使用すると TCP ストリームの混乱が発生する