Google Distributed Cloud のネットワークの問題のトラブルシューティング

このページでは、Google Distributed Cloud のネットワークの問題を解決する方法について説明します。一般的なトラブルシューティング情報とガイダンス、および推奨されるツールを紹介します。DNS のトラブルシューティング情報と、Calico、Seesaw、MetalLB に関する一般的な問題も一部記載されています。

さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。

ネットワーク接続のトラブルシューティング

GKE Enterprise のネットワーキングは、物理的なネットワーク インフラストラクチャに依存しています。たとえば、Seesaw または MetalLB は Gratuitous ARP を使用するスイッチに依存し、Border Gateway Protocol（BGP）とのバンドル型ロード バランシングはルーターに依存し、すべてのノードが相互に通信できる必要があります。GKE クラスタでネットワークの問題がある場合は、問題が GKE Enterprise コンポーネントにあるか、独自のインフラストラクチャにあるかを特定する必要があります。

問題の範囲を判断してから、影響を受けるコンポーネントの特定を試みます。問題の範囲は、次の 3 つのカテゴリのいずれかになります。サブジェクト（開始）、ターゲット（終了）、ネットワーク レイヤ。

サブジェクトの範囲は次のいずれかになります。

  • クラスタ全体のすべてのノード（または hostNetwork Pod）。
  • クラスタ全体のすべての Pod。
  • 単一のノードまたは一連のノード上のすべての Pod。
  • 同じ Deployment または DaemonSet のすべての Pod。
  • クラスタ外のクライアント。

ターゲットの範囲は次のいずれかになります。

  • 同じクラスタの他のすべての Pod IP アドレス。
  • 同じノードの他のすべての Pod IP アドレス。
  • 同じクラスタの ClusterIP Service VIP。
  • 同じクラスタの LoadBalancer Service VIP。
  • Ingress レイヤ 7 LoadBalancer（Istio）。
  • 同じクラスタの他のノード。
  • 内部 DNS 名（*.svc.cluster.local など）。
  • 外部 DNS 名（google.com など）。
  • クラスタ外のエンティティ。
  • インターネット上のエンティティ。

ネットワーク レイヤは、次のいずれかになります。

  • ネイバー システム、ARP、NDP などのレイヤ 2 リンクレイヤの問題。
  • レイヤ 3 IP アドレスのルーティングの問題。
  • レイヤ 4 TCP または UDP エンドポイントの問題。
  • レイヤ 7 HTTP または HTTPS の問題。
  • DNS の解決に関する問題。

問題の範囲を理解すると、問題に関連するコンポーネントと問題が発生しているレイヤを特定できます。問題の一部は一時的なものであり、システム復旧後のスナップショットには根本原因の分析について十分な情報が含まれていないため、問題発生時に情報を収集することは重要です。

上り（内向き）の問題

サブジェクトがクラスタ外のクライアントで、LoadBalancer Service に接続できない場合は、North-South 接続性の問題です。次の図は、実際の例では受信トラフィックがスタックを通って左から右に向かい、戻りトラフィックがスタックを通って右から左に向かうことを示しています。Seesaw は、戻りトラフィックがロードバランサをスキップしてクライアントに直接返されるため、異なります。

上り（内向き）トラフィックは、ユーザーから物理インフラストラクチャ、ロードバランサ、anetd / kube-proxy を経由してバックエンドに送信されます。Seesaw では、下り（外向き）トラフィックはロードバランサをスキップします。

このトラフィック フローに問題がある場合は、次のトラブルシューティング フローチャートを使用して問題の発生場所を特定します。

パケットが環境を通過する際の各ステップを確認して、ネットワーク上り（内向き）の問題のトラブルシューティングを行います。途中で適切なアクションと接続が存在するかどうかを確認します。

このフローチャートでは、次のトラブルシューティング ガイダンスが問題の発生場所の特定に役立ちます。

  • パケットはクライアントから送信されていますか？そうでない場合は、ネットワーク インフラストラクチャで問題が発生している可能性があります。
  • Seesaw ロードバランサを使用していますか？使用している場合、パケットが Seesaw ノードに到達し、ARP が正しく送信されますか？そうでない場合は、ネットワーク インフラストラクチャで問題が発生している可能性があります。
  • MetalLB を使用していますか？使用している場合、パケットが LB ノードに到達し、ARP が正しく送信されますか？そうでない場合は、ネットワーク インフラストラクチャで問題が発生している可能性があります。
  • F5 BIG-IP を使用している場合、F5 の問題を確認しましたか？
  • ネットワーク アドレス変換（NAT）が正しく行われていますか？そうでない場合は、kube-proxy / Dataplane V2 で問題が発生している可能性があります。
  • パケットはワーカーノードに到達していますか？そうでない場合は、Calico / Dataplane v2 の Pod 間で問題が発生している可能性があります。
  • パケットは Pod に到達していますか？そうでない場合は、Calico / Dataplane v2 のローカル転送で問題が発生している可能性があります。

以降のセクションでは、各ステージのトラブルシューティングを行ってトラフィックが正しく流れているかどうかを判断する手順を説明します。

パケットはクライアントから送信されていますか？

パケットがクライアントから正しく送信され、物理ネットワーク インフラストラクチャで構成されたルーターを通過しているかどうかを確認します。

  1. tcpdump を使用して、クライアントから宛先サービスに向かうパケットを確認します。

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    出て行くトラフィックが確認できない場合は、ここが問題の発生源です。

パケットは Seesaw ノードに到達していますか？

ロードバランサとして Seesaw を使用する場合は、マスターノードを見つけて、SSH を使用してノードに接続します。

  1. tcpdump を使用して、想定されるパケットが Seesaw ノードに到達したかどうかを確認します。

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    入ってくるトラフィックが確認できない場合は、ここが問題の発生源です。

パケットは LoadBalancer ノードに到達していますか？

ロードバランサとして MetalLB を使用する場合:

  1. metallb-controller ログを調べて、サービス VIP を提供するロードバランサ ノードを特定します。

    kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP

  2. SSH を使用してノードに接続します。

  3. MetalLB ノードの場合は、tcpdump を使用してトラフィックを確認します。

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    ManualLB の場合、トラフィックは任意のノードに到達する可能性があります。ロードバランサの構成に応じて、1 つまたは複数のノードを選択できます。tcpdump を使用してトラフィックを確認します。

    tcpdump -ni any host NODE_IP and port NODE_PORT

    このコマンドは、ロードバランサの種類によって異なります。MetalLB と Seesaw はパケットをノードに転送する前に NAT を行いません。

    どのノードに向かうトラフィックも確認できない場合は、ここが問題の発生源です。

F5 BIG-IP の問題がありますか？

F5 BIG-IP の問題をトラブルシューティングするには、F5 Service がトラフィックを受信しない件に関して次のいずれかのセクションをご覧ください。

ARP は正しく送信されていますか？

MetalLB または Seesaw のロードバランサ ノードは、ARP を使用してサービス VIP をアドバタイズします。ARP レスポンスが正しく送信されていても、トラフィックが到達しない場合は、物理ネットワーク インフラストラクチャに問題があることを示しています。この問題の一般的な原因は、一部の高度なデータプレーン学習機能では、ソフトウェア定義ネットワーク（SDN）ソリューションの ARP レスポンスが無視されることです。

  1. tcpdump を使用して ARP レスポンスを検出します。

    tcpdump -ni any arp

    問題が発生している VIP をアドバタイズしているメッセージを探してください。

    • Seesaw では、すべての VIP に対して Gratuitous ARP が送信されます。各 VIP の ARP メッセージが 10 秒ごとに表示されます。

    • MetalLB の場合、Gratuitous ARP は送信されません。レスポンスが確認される頻度は、トップオブラック（ToR）スイッチや仮想スイッチなどの別のデバイスが ARP リクエストを送信するタイミングによって異なります。

NAT は行われていますか？

Dataplane v2 / kube-proxy は、宛先ネットワーク アドレス変換（宛先 NAT または DNAT）を行って、宛先 VIP をバックエンド Pod の IP アドレスに変換します。ロードバランサのバックエンドのノードがわかっている場合は、SSH を使用してそのノードに接続します。

  1. tcpdump を使用して、Service VIP が正しく変換されているかどうかを確認します。

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. Dataplane v2 では、追加で anetd Pod に接続し、組み込みの Cilium デバッグツールを使用することもできます。

    cilium monitor --type=drop

詳細については、Dataplane v2 / Cilium の問題に関して次のいずれかのセクションをご覧ください。

パケットはワーカーノードに到達していますか？

ワーカーノードで、パケットは外部インターフェースに到達し、Pod に配信されます。

  1. tcpdump を使用して、パケットが外部インターフェース（通常は eth0 または ens192）に到達しているかどうかを確認します。

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

通常の Service バックエンドには、さまざまなノードにわたる複数の Pod が含まれているため、問題のあるノードのトラブルシューティングが難しくなる場合があります。一般的な回避策は、一部のパケットが最終的に到達するように問題を十分に長くキャプチャするか、バックエンドの数を 1 に制限することです。

パケットがワーカーノードに到達しない場合は、ネットワーク インフラストラクチャに問題があることを示しています。LoadBalancer ノードとワーカーノードの間でパケットがドロップされる理由については、ネットワーキング インフラストラクチャ チームに確認してください。一般的な問題としては、次のようなものがあります。

  • ソフトウェア定義ネットワーク（SDN）のログを確認します。SDN は、セグメンテーション、誤ったチェックサム、なりすまし対策など、さまざまな理由でパケットをドロップすることがあります。
  • 宛先がバックエンド Pod の IP アドレスとポートであるパケットをフィルタするファイアウォール ルール。

パケットがノードの外部インターフェースまたはトンネル インターフェースに到達したら、宛先 Pod に転送する必要があります。Pod がホスト ネットワーキング Pod の場合、Pod はネットワーク名前空間をノードと共有するため、この手順は不要です。それ以外の場合は、追加のパケット転送が必要になります。

各 Pod には、パイプのように動作する仮想イーサネット インターフェース ペアがあります。インターフェースの一方の端に送信されたパケットは、インターフェースのもう一方の端から受信されます。一方のインターフェースは Pod のネットワーク名前空間に移動し、名前が eth0 に変更されます。もう一方のインターフェースはホスト名前空間に残ります。CNI が異なればスキーマも異なります。Dataplane v2 の場合、インターフェースの名前は通常、lxcxxxx です。名前には連続するインターフェース番号が付きます（lxc17 や lxc18 など）。tcpdump を使用してパケットが Pod に到達しているかどうかを確認できます。インターフェースを指定することもできます。

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

パケットがノードに到達しても Pod に到達できない場合は、次のようにルーティング テーブルを確認します。

  ip route

通常、各 Pod には、Pod IP アドレスを lxc インターフェースにルーティングするルーティング エントリが必要です。エントリがない場合、通常は CNI データパスにエラーがあります。根本原因を特定するには、CNI DaemonSet ログを確認します。

下り（外向き）の問題

トラフィックが Pod に入ることができる場合は、Pod からの下り（外向き）トラフィックで問題が発生している可能性があります。次の図は、実際の例では受信トラフィックがスタックを通って左から右に向かうことを示しています。

下り（外向き）トラフィックは、Pod からホストの外部インターフェース、物理インフラストラクチャを経由して外部サービスに送信されます。

  1. 送信パケットがノード IP アドレスとして正しくマスカレードされていることを確認するには、外部サービス（レイヤ 4）を確認します。

    パケットの送信元 IP アドレスは、送信元ネットワーク アドレス変換（送信元 NAT または SNAT）を使用して Pod IP アドレスからノード IP アドレスにマッピングする必要があります。Dataplane v2 では、このプロセスは外部インターフェースに読み込まれる ebpf で実現します。Calico は iptables ルールを使用します。

    tcpdump を使用して、送信元 IP アドレスが Pod IP アドレスからノード IP アドレスに正しく変換されているかどうかを確認します。

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    パケットが正しくマスカレードされていることを tcpdump が示していてもリモート サービスが応答しない場合は、インフラストラクチャの外部サービスへの接続を確認します。

  2. 送信パケットがノード IP アドレスとしてマスカレードされている場合は、tcpdump を使用して外部ホスト（レイヤ 3）の接続性を確認します。

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    tcpdump を実行すると同時に、いずれかの Pod から ping を実行します。

    kubectl exec POD_NAME ping EXTERNAL_IP

    ping レスポンスが表示されない場合は、インフラストラクチャの外部サービスへの接続を確認します。

クラスタ内の問題

Pod 間の接続の問題については、問題をノードにスコープしてみてください。多くの場合、ノードグループは別のノードグループと通信できません。

  1. Dataplane v2 で、現在のノードから同じクラスタ内の他のすべてのノードへのノード接続性を確認します。anetd Pod 内からヘルス ステータスを確認します。

    cilium status --all-health

    Google Distributed Cloud は直接ルーティング モードを使用します。次の例に示すように、クラスタ内のノードごとに 1 つのルートエントリが表示されます。

    # <pod-cidr> via <node-ip> dev <external-interface>
192.168.1.0/24 via 21.0.208.188 dev ens192
192.168.2.0/24 via 21.0.208.133 dev ens192

    ノードに予想されるルートがない場合、そのノードへの接続は失われます。

ネットワーク層の問題

接続性の問題が発生しているネットワーク層を特定することは、重要なステップです。「ソースから宛先への接続の問題」のようなエラー メッセージは、アプリケーション エラー、ルーティングの問題、DNS の問題など、問題の解決に十分な情報ではありません。どのレイヤで問題が発生しているかを把握することで、適切なコンポーネントを修正できます。

多くの場合、エラー メッセージは問題が発生しているレイヤを直接示します。ネットワーク レイヤに関する疑問のトラブルシューティングに役立つ例を以下に紹介します。

  • HTTP エラーは、レイヤ 7 の問題であることを示します。
    • HTTP コード 40x、50x、TLS handshake のエラーは、レイヤ 4 ですべてが正常に機能していることを意味します。
  • 「ピアによって接続がリセットされた」エラーは、レイヤ 4 問題であることを示します。
    • 多くの場合、リモート ソケットは接続の現在の状態に一致しないため、RESET パケットを送信します。このような動作は、接続トラッキングや NAT の間違いである可能性があります。
  • 「ホストへのルートがない」エラーと「接続タイムアウト」エラーは通常、レイヤ 3 またはレイヤ 2 の問題です。
    • これらのエラーは、パケットを宛先に正しくルーティングできないことを示しています。

便利なトラブルシューティング ツール

ネットワーク関連の DaemonSet はノード上で実行されるため、接続の問題の原因となる可能性があります。ただし、ノード、トップオブラック（ToR）スイッチ、スパイン ルーター、ファイアウォールの構成ミスも問題を引き起こす可能性があります。次のツールを使用して、問題の範囲またはレイヤを特定し、GKE Enterprise ノードまたは物理インフラストラクチャのどちらに問題があるのかを判断することができます。

Ping

ping はレイヤ 3（IP レイヤ）で動作し、送信元と宛先の間のルートを確認します。ping が宛先に到達できない場合、通常はレイヤ 3 に問題があります。

ただし、すべての IP アドレスが ping できるわけではありません。たとえば、一部のロードバランサの VIP は、純粋なレイヤ 4 ロードバランサである場合、ping できません。VIP が ping レスポンスを返さない可能性がある一例は、ClusterIP Service です。レイヤ 4 では、VIP:port などのポート番号が指定された場合にのみ、この Service から ping レスポンスが返されます。

Google Distributed Cloud の BGPLB、MetalLB、Seesaw ロードバランサはすべてレイヤ 3 で動作します。ping を使用して接続性を確認できます。F5 は異なりますが、ICMP もサポートしています。ping を使用して F5 VIP への接続性を確認できます。

arping

arping は ping と似ていますが、レイヤ 2 で動作する点が異なります。レイヤ 2 とレイヤ 3 の問題は多くの場合、アプリケーションからのエラー メッセージが似ています。arping と ping は問題を区別するのに役立ちます。たとえば、送信元と宛先が同じサブネット内にあり、宛先に arping できない場合、レイヤ 2 の問題です。

arping <ip> が成功すると、宛先の MAC アドレスが返されます。レイヤ 2 では多くの場合、このアドレスは物理インフラストラクチャの問題を示します。この問題は、仮想スイッチの構成ミスです。

arping は、IP アドレスの競合も検出できます。IP アドレスの競合は、2 つのマシンが同じサブネット上で同じ IP アドレスを使用するように構成されている場合、または VIP が別の物理マシンによって使用されている場合に発生します。IP アドレスの競合により、トラブルシューティングしにくい断続的な問題が発生する可能性があります。arping <ip> が複数の MAC アドレス エントリを返した場合は、IP アドレスの競合があることを示しています。

arping で MAC アドレスを取得したら、https://maclookup.app/ を使用してその MAC アドレスのメーカーを検索できます。各メーカーが MAC プレフィックスを所有しているため、この情報を使用して、同じ IP アドレスを使用しようとしているデバイスを特定できます。たとえば、VMware は 00:50:56 ブロックを所有しているため、MAC アドレス 00:50:56:xx:yy:zz は vSphere 環境の VM です。

iproute2

iproute2 の ip CLI には、次のような便利なサブコマンドがあります。

  • ip r: ルートテーブルを出力します。
  • ip n: IP アドレスから MAC アドレスへのマッピングのネイバー テーブルを出力します。
  • ip a: マシン上のすべてのインターフェースを出力します。

ネイバー テーブルにルートがないか、エントリがないと、ノードから接続の問題が発生する可能性があります。anetd と Calico は、どちらもルートテーブルとネイバー テーブルを管理します。これらのテーブルの構成ミスで、接続の問題が発生する可能性があります。

Cilium / Hubble CLI for Dataplane v2

各 anetd Pod には、接続性の問題に役立つデバッグツールがいくつか用意されています。

  • cilium monitor --type=drop
    • anetd / Cilium によってドロップされたすべてのパケットのログを出力します。
  • hubble observe
    • anetd の ebpf スタックを経由するすべてのパケットを出力します。
  • cilium status --all-health
    • ノード間の接続ステータスを含む Cilium のステータスを出力します。各 anetd Pod は、クラスタ内の他のすべてのノードの状態をチェックします。これはノード間の接続の問題を特定するのに役立ちます。

iptables

iptables は、多くの Kubernetes コンポーネントとサブシステムで使用されています。kube-proxy は iptables を使用してサービスの解決を実装します。Calico は iptables を使用してネットワーク ポリシーを実装します。

  1. iptables レベルでネットワークの問題をトラブルシューティングするには、次のコマンドを使用します。

    iptables -L -v | grep DROP

    ドロップルールを調べて、パケット数とバイト数が時間とともに増加しているかどうかを確認します。

tcpdump

tcpdump は、大量のネットワーク トラフィック データを生成する強力なパケット キャプチャ ツールです。一般に、送信元と宛先の両方から tcpdump を実行します。パケットが送信元ノードから出るときにキャプチャされ、宛先ノードではキャプチャされない場合、その間でパケットがドロップされます。この動作は通常、物理インフラストラクチャの何かでパケットが誤ってドロップされたことを示します。

DNS のトラブルシューティング

DNS の解決の問題は、次の 2 つの主要カテゴリに分類されます。

  • クラスタ内の DNS サーバーを使用する通常の Pod。
  • クラスタ内の DNS サーバーを使用しないホスト ネットワークの Pod またはノード。

以降のセクションでは、クラスタ DNS アーキテクチャについて説明し、これらのカテゴリのいずれかのトラブルシューティングを開始する前に役立つヒントを紹介します。

クラスタ DNS アーキテクチャ

クラスタ DNS サービスは、クラスタ内の Pod の DNS リクエストを解決します。CoreDNS は、Google Distributed Cloud バージョン 1.9.0 以降にこのサービスを提供します。

各クラスタには 2 つ以上の coredns Pod と、クラスタサイズに基づいて DNS Pod の数を調整するオートスケーラーがあります。また、すべてのバックエンド coredns Pod 間でリクエストのロード バランシングを行う kube-dns というサービスもあります。

ほとんどの Pod はアップストリーム DNS が kube-dns Service IP アドレスに構成されます。Pod は DNS リクエストをいずれかの coredns Pod に送信します。DNS リクエストは、次のいずれかの宛先にグループ化できます。

  • cluster.local ドメインに対するリクエストの場合、これはクラスタ内の Service または Pod を参照するクラスタ内の DNS 名です。
    • CoreDNS は、クラスタ内のすべての Service と Pod に対して api-server を監視し、有効な cluster.local ドメインへのリクエストに応答します。
  • cluster.local ドメイン以外のリクエストの場合は、外部ドメイン用です。
    • CoreDNS は、リクエストをアップストリーム ネームサーバーに転送します。デフォルトでは、CoreDNS は稼働しているノードに構成されているアップストリーム ネームサーバーを使用します。

詳細については、DNS の仕組みと Kubernetes における構成の概要に関するページをご覧ください。

DNS のトラブルシューティングのヒント

DNS の問題のトラブルシューティングを行うには、dig ツールと nslookup ツールを使用します。これらのツールを使用すると、DNS リクエストを送信して、DNS の解決が正常に機能するかどうかをテストできます。次の例は、dig と nslookup を使用して DNS の解決の問題を確認する方法を示しています。

  • dig または nslookup を使用して google.com のリクエストを送信します。

    dig google.com
nslookup google.com

  • dig を使用して、kubernetes.default.svc.cluster.local のリクエストをサーバー 192.168.0.10 に送信します。

    dig @192.168.0.10 kubernetes.default.svc.cluster.local

  • nslookup を使用して、前の dig コマンドと同じ DNS ルックアップを行うこともできます。

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    dig コマンドまたは nslookup コマンドの出力を確認します。正しくないレスポンスが返された場合、またはレスポンスがない場合は、DNS の解決に問題があることを示しています。

通常の Pod

DNS の問題をデバッグする最初のステップは、リクエストが coredns Pod に対して行われたかどうかを判断することです。多くの場合、DNS リクエストはワークロードが送信するトラフィックの最初のタイプであるため、一般的なクラスタの接続の問題は DNS の問題として表示されます。

アプリケーションからのエラー メッセージを確認します。io timeout などのエラーは、レスポンスがなく、一般的なネットワーク接続の問題があることを示しています。

NXDOMAIN や SERVFAIL などの DNS エラーコードを含むエラー メッセージは、クラスタ内の DNS サーバーに接続していてもサーバーがドメイン名を解決できなかったことを示しています。

  • NXDOMAIN エラーは、ドメインが存在しない旨を DNS サーバーが報告していることを示しています。アプリケーションがリクエストしているドメイン名が有効であることを確認します。
  • SERVFAIL または REFUSED エラーは、DNS サーバーがレスポンスを送信したものの、ドメインを解決できなかったか、ドメインの存在を検証できなかったことを示します。詳細については、coredns Pod のログを確認してください。

次のコマンドを使用すると、kube-dns サービスの IP アドレスを確認できます。

kubectl -n kube-system get svc kube-dns

前のセクションで説明したように、DNS が機能していない Pod から、dig または nslookup を使用してこの IP アドレスに DNS リクエストを送信してみます。

  • これらのリクエストが機能しない場合は、各 coredns Pod の IP アドレスにリクエストを送信してみてください。
  • 一部の Pod が機能しても他の Pod が機能しない場合は、DNS の解決が coredns Pod と同じノードの Pod には機能するが、ノード間では機能しないなど、識別可能なパターンがあるかどうかを確認します。この動作は、クラスタ内の接続の問題を示している可能性があります。

CoreDNS が外部のドメイン名を解決できない場合は、次のセクションでホスト ネットワークの Pod のトラブルシューティングを行ってください。CoreDNS は、ホスト ネットワークの Pod のように動作し、名前解決にノードのアップストリーム DNS サーバーを使用します。

ホスト ネットワークの Pod またはノード

ホスト ネットワークの Pod とノードは、DNS の解決のためにノードに構成されたネームサーバーを使用します。クラスタ内の DNS サービスは使用しません。このネームサーバーは、OS に応じて /etc/resolv.conf または /run/systemd/resolve/resolv.conf のいずれかで構成されます。このような構成では、cluster.local ドメイン名は解決できません。

ホスト ネットワークの名前解決で問題が発生した場合は、前のセクションのトラブルシューティング手順を使用して、アップストリーム ネームサーバーで DNS が正しく機能しているかどうかをテストします。

ネットワークの一般的な問題

以降のセクションでは、ネットワークで発生する可能性のある一般的な問題について説明します。問題を解決するには、適切なトラブルシューティング ガイダンスに沿って対応してください。さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。

Calico

一般的なエラー: calico/node is not ready: BIRD is not ready: BGP not established

Kubernetes におけるこの「未準備」ステータス エラーは、通常、クラスタ内で特定のピアが到達できないことを意味します。環境で 2 つのピア間の BGP 接続が許可されていることを確認します。

このエラーは、非アクティブなノードリソースがノード間メッシュに構成されている場合にも発生することがあります。この問題を解決するには、古いノードを廃止します。

Dataplane v2 / Cilium

一般的なエラー: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

このエラーは、レート制限が原因で Pod 作成イベントが Cilium エージェントによって拒否されたことを意味します。ノードごとに、Cilium の PUT エンドポイントへの同時リクエストの上限は 4 です。1 つのノードへのリクエストがバーストした場合、この動作は想定されたものです。Cilium エージェントが遅延したリクエストに追いつく必要があります。

GKE Enterprise 1.14 以降では、レート上限はノード容量に合わせて自動的に調整されます。レート制限機能はより合理的な数に収束し、より強力なノードに対するレート制限が高くなります。

一般的なエラー: Ebpf map size is full

Dataplane v2 は eBFP マップに状態を保存します。状態には、Service、接続トラッキング、Pod の ID、ネットワーク ポリシーのルールが含まれます。マップがいっぱいの場合、エージェントはエントリを挿入できません。これにより、コントロール プレーンとデータプレーンの間に不一致が生じます。たとえば、Service マップのエントリ数の上限は 64k です。

  1. eBFP マップエントリとその現在のサイズを確認するには、bpftool を使用します。次の例では、ロードバランサのマップを確認しています。

    bpftool map dump pinned \
/sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1

bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1

  2. マップが 64k の上限に近づいている場合は、マップをクリーンアップします。次の例では、ロードバランサ マップをクリーンアップしています。

    bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key

  3. 状態を eBFP マップに補充するには、anetd を再起動してください。

NetworkPluginNotReady エラーが原因でノードが未準備になる

CNI Pod がノードで実行されていない場合、次のようなエラーが表示されることがあります。

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

ノードが未準備状態になり、次の例のようなエラーが発生することがあります。

  "Network plugin not installed"

ノードが初期化されると、kubelet はノードが Ready とマークされる前に、複数のイベントが発生するのを待ちます。kubelet が確認するイベントとしては、Container Network Interface（CNI）プラグインがインストールされていることが挙げられます。CNI プラグインは、CNI バイナリと CNI 構成の両方を必要なホスト ディレクトリにインストールするために、init コンテナを使用し、anetd または Calico によってインストールする必要があります。

この問題のトラブルシューティングを行うには、こうした Pod がノードで実行されていない理由を確認します。通常、このエラーはネットワークの問題によるものではありません。これらの Pod はホスト ネットワークで実行されるため、ネットワークの依存関係はありません。

  1. anetd または calico-node Pod の状態を確認します。次のトラブルシューティング手順を確認すると、問題の原因の特定に役立ちます。

    • Pod が Crashlooping 状態の場合は、ログを調べて、Pod が正しく動作しない理由を確認します。
    • Pod が Pending 状態の場合は、kubectl describe を使用して Pod イベントを確認します。たとえば、Pod に Volume などのリソースがない場合があります。
    • Pod が Running 状態の場合は、ログと構成を確認します。Cilium など、一部の CNI 実装には CNI のインストールを無効にするオプションが用意されています。
    • anetd には custom-cni-conf という構成オプションがあります。この設定が true として構成されている場合、anetd は CNI バイナリをインストールしません。

F5 Service がトラフィックを受信しない

F5 Service にトラフィックが届かない場合は、次のトラブルシューティング手順を確認してください。

  1. F5 BIG-IP のすべてのパーティションが、管理クラスタまたはユーザー クラスタの 1 つのクラスタに構成されていることを確認します。1 つのパーティションが複数のクラスタで共有されている場合、接続が断続的に中断します。これは、2 つのクラスタが同じパーティションに対する制御を占め、他のクラスタから Service を削除しようとするためです。

  2. 次の 2 つの Pod が実行されていることを確認します。動作していない Pod は、エラーを示しています。

    Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj

    GKE Enterprise が所有する Load-balancer-f5 は、LoadBalancer タイプの Service ごとに ConfigMap を作成します。ConfigMap は、最終的に bigip コントローラによって使用されます。

  3. 各 Service の各ポートに ConfigMap が存在することを確認します。たとえば、次のポートがあるとします。

    Kube-server-443-tcp     2   31h
Kube-server-8132-tcp        2   31h

    kube-server　Service は次の例のようになります。

    Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h

    次の例に示すように、ConfigMap のデータ セクションには、フロントエンド VIP とポートが必要です。

    data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
  schema: f5schemadb://bigip-virtual-server_v0.1.7.json

  4. BIG-IP インスタンスのログと指標を確認します。ConfigMap が正しく構成されていても BIG-IP インスタンスが構成を適用できない場合は、F5 の問題である可能性があります。BIG-IP インスタンス内で発生する問題については、F5 のサポートに連絡して、問題の診断とトラブルシューティングを行います。

次のステップ

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。