Netzwerkprobleme mit Google Distributed Cloud beheben

Auf dieser Seite erfahren Sie, wie Sie Netzwerkprobleme mit Google Distributed Cloud beheben. Es werden allgemeine Informationen und Anleitungen zur Fehlerbehebung sowie empfohlene Tools bereitgestellt. Außerdem finden Sie Informationen zur DNS-Fehlerbehebung und einige häufige Probleme mit MetalLB.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Fehlerbehebung bei Netzwerkverbindungen

Das GKE Enterprise-Netzwerk basiert auf Ihrer physischen Netzwerkinfrastruktur. Beispielsweise nutzt MetalLB Ihre Switches und berücksichtigt Gratuitous ARP, gebündeltes Load-Balancing mit Border Gateway Protocol (BGP) nutzt Ihre Router und alle Knoten sollten in der Lage sein, miteinander zu kommunizieren. Wenn Sie ein Netzwerkproblem in Ihren GKE-Clustern haben, müssen Sie feststellen, ob das Problem bei den GKE Enterprise-Komponenten oder in Ihrer eigenen Infrastruktur liegt.

Ermitteln Sie zuerst den Umfang des Problems und versuchen Sie dann, die betroffenen Komponenten zu identifizieren. Der Umfang eines Problems kann in eine von drei Kategorien eingeteilt werden: Subjekt (von wo aus) das Ziel (an welche) und Netzwerkebene “

Der Umfang des Subjekts kann eines der folgenden Dinge sein:

  • Alle Knoten (oder hostNetwork-Pod) clusterweit.
  • Alle Pods clusterweit.
  • Alle Pods auf einem einzelnen Knoten oder einer Gruppe von Knoten.
  • Alle Pods aus demselben Deployment oder DaemonSet.
  • Client von außerhalb des Clusters.

Der Zielbereich kann einer oder mehrere der folgenden Dinge sein:

  • Alle anderen Pod-IP-Adressen aus demselben Cluster
  • Alle anderen Pod-IP-Adressen von demselben Knoten.
  • ClusterIP-Dienst-VIP aus demselben Cluster.
  • LoadBalancer-Dienst-VIP aus demselben Cluster.
  • Ingress-Layer-7-LoadBalancer (Istio).
  • Andere Knoten aus demselben Cluster
  • Interner DNS-Name (z. B. *.svc.cluster.local)
  • Externer DNS-Name (z. B. google.com).
  • Entitäten von außerhalb des Clusters
  • Entitäten im Internet

Die Netzwerkebene kann eines oder mehrere der folgenden Dinge sein:

  • Probleme mit Layer-2-Link-Ebenen wie Nachbarsystem, ARP oder NDP.
  • Probleme mit dem IP‑Adress-Routing von Layer 3.
  • Probleme mit TCP- oder UDP-Endpunkten von Layer 4.
  • Layer-7-HTTP- oder -HTTPS-Probleme.
  • Probleme mit der DNS-Auflösung

Wenn Sie den Umfang eines Problems verstehen, können Sie die Komponenten identifizieren, die mit dem Problem zusammenhängen und in welchem Schicht das Problem auftritt. Es ist wichtig, Informationen zu erfassen, wenn das Problem auftritt, da einige Probleme vorübergehend sind. Snapshots nach der Systemwiederherstellung enthalten nicht genügend Informationen für die Analyse der Grundursache.

Probleme mit dem eingehenden Traffic

Wenn es sich bei dem Subjekt um einen Client von außerhalb des Clusters handelt und keine Verbindung zu einem LoadBalancer-Dienst hergestellt werden konnte, liegt ein Nord-Süd-Verbindungsproblem vor. Das folgende Diagramm zeigt, dass in einem Arbeitsbeispiel der eingehende Traffic von links nach rechts durch den Stack fließt und der Rücklauftraffic von rechts nach links durch den Stack zurückfließt.

Eingehender Traffic fließt vom Nutzer zur physischen Infrastruktur, durch einen Load Balancer zu anetd/kube-proxy und dann zum Backend.

Wenn bei diesem Traffic-Fluss ein Problem auftritt, verwenden Sie das folgende Flussdiagramm zur Fehlerbehebung, um zu ermitteln, wo das Problem liegt:

Fehlerbehebung bei Problemen mit dem eingehenden Netzwerktraffic, indem jeder Schritt überprüft wird, den ein Paket bei der Bewegung durch Ihre Umgebung ausführt. Prüfen Sie, ob die entsprechenden Aktionen und Verbindungen vorhanden sind.

In diesem Flussdiagramm helfen Ihnen die folgenden Anleitungen zur Fehlerbehebung zu ermitteln, wo das Problem liegt:

  • Verlässt das Paket den Client? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
  • Verwenden Sie MetalLB? Wenn ja, erreicht das Paket den LB-Knoten und wird ARP dann richtig gesendet? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
  • Verwenden Sie F5 BIG-IP? Falls ja, haben Sie nach F5-Problemen gesucht?
  • Wird die Network Address Translation (NAT) korrekt ausgeführt? Wenn nicht, liegt wahrscheinlich ein Problem mit kube-proxy / Dataplane V2 vor.
  • Errreicht das Paket den Worker-Knoten? Wenn nicht, liegt wahrscheinlich ein Dataplane v2-Pod-zu-Pod-Problem vor.
  • Erreicht das Paket den Pod? Wenn nicht, liegt wahrscheinlich ein lokales Weiterleitungsproblem mit Dataplane v2 vor.

In den folgenden Abschnitten finden Sie Schritte zur Fehlerbehebung für jede Phase, um festzustellen, ob der Traffic korrekt fließt.

Verlässt das Paket den Client?

Prüfen Sie, ob das Paket den Client ordnungsgemäß verlässt und durch den in Ihrer physischen Netzwerkinfrastruktur konfigurierten Router geleitet wird.

  1. Verwenden Sie tcpdump, um das Paket zu prüfen, wenn es den Client verlässt und zum Zieldienst weitergeleitet wird:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Wenn kein Traffic hinausgeht, liegt hier das Problem.

Geht das Paket bei einem LoadBalancer-Knoten ein?

Wenn Sie MetalLB als Load-Balancer verwenden:

  1. Prüfen Sie anhand des Logs metallb-controller, welcher Load-Balancer-Knoten die Dienst-VIP bedient:

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

  2. Stellen Sie eine SSH-Verbindung zum Knoten her.

  3. Prüfen Sie für einen MetalLB-Knoten mit tcpdump den Traffic:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Bei der manuellen Load Balancing-Methode kann der Traffic auf einem beliebigen Knoten landen. Je nach Load Balancer-Konfiguration können Sie einen oder mehrere Knoten auswählen. Mit tcpdump können Sie den Traffic überprüfen:

    tcpdump -ni any host NODE_IP and port NODE_PORT

    Der Befehl unterscheidet sich zwischen den Load-Balancer-Typen, da MetalLB keine NAT ausführt, bevor das Paket an Knoten weitergeleitet wird.

    Wenn Sie keinen Traffic zu einem Knoten sehen, liegt hier das Problem.

Gibt es ein Problem mit F5 BIG-IP?

Informationen zur Fehlerbehebung bei F5 BIG-IP-Problemen finden Sie in den folgenden Abschnitten unter Der F5-Dienst empfängt keinen Traffic.

Wird ARP korrekt gesendet?

Der Load Balancer-Knoten für MetalLB nutzt ARP, um die VIP des Dienstes anzukündigen. Wenn die ARP-Antwort korrekt gesendet wird, aber kein Traffic eingeht, ist dies ein Hinweis auf ein Problem mit der physischen Netzwerkinfrastruktur. Eine häufige Ursache für dieses Problem ist, dass einige erweiterte Lernfeatures der Datenebene die ARP-Antwort in SDN-Lösungen (softwarebasierten Netzwerk) ignorieren.

  1. Mit tcpdump können Sie ARP-Antworten erkennen:

    tcpdump -ni any arp

    Suchen Sie nach der Nachricht, die die VIP bewirbt, bei der Sie Probleme haben.

  2. Bei MetalLB wird kein Gratuitous ARP gesendet. Wie oft Sie eine Antwort erhalten, hängt davon ab, wann ein anderes Gerät wie ein ToR-Switch (Top of Rack) eine ARP-Anfrage sendet.

Wird NAT ausgeführt?

Dataplane v2/kube-proxy führt eine Zielnetzwerkadressübersetzung (Destination Network Address Translation, DNAT) durch, um die Ziel-VIP in eine Backend-Pod-IP-Adresse umzuwandeln. Wenn Sie wissen, welcher Knoten das Backend für den Load Balancer ist, stellen Sie über SSH eine Verbindung zum Knoten her.

  1. Prüfen Sie mit tcpdump, ob die Dienst-VIP richtig übersetzt ist:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. Bei Dataplane V2 können Sie zusätzlich eine Verbindung zu den anetd-Pods herstellen und die eingebetteten Cilium-Debugging-Tools verwenden:

    cilium monitor --type=drop

Weitere Informationen finden Sie in den folgenden Abschnitten zu Problemen mit Dataplane V2/Cilium.

Erreicht das Paket einen Worker-Knoten?

Auf den Worker-Knoten kommt das Paket an der externen Schnittstelle an und wird dann an die Pods weitergeleitet.

  1. Prüfen Sie mit tcpdump, ob das Paket an der externen Schnittstelle ankommt, die in der Regel eth0 oder ens192 heißt:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
Bei Google Distributed Cloud ist das Paket in einem Tunnel gekapselt. Wenn das Paket entkapselt wird, kommt es von einer Netzwerkschnittstelle mit dem Namen cilium_geneve.

Da normale Service-Back-Ends mehrere Pods auf verschiedenen Knoten enthalten, kann es schwierig sein, zu ermitteln, welcher Knoten fehlerhaft ist. Eine gängige Problemumgehung besteht darin, das Problem entweder so lange zu erfassen, dass ein Paket ankommt, oder die Anzahl der Back-Ends auf eins zu beschränken.

Wenn das Paket nie den Arbeitsknoten erreicht, weist dies auf ein Problem mit der Netzwerkinfrastruktur hin. Erkundigen Sie sich beim Team für die Netzwerkinfrastruktur, warum das Paket zwischen LoadBalancer-Knoten und Worker-Knoten verworfen wird. Zu den häufigsten Problemen gehören:

  • Prüfen Sie die Logs Ihres softwaredefinierten Netzwerks (Software-defined Network, SDN). Manchmal kann das SDN Pakete aus verschiedenen Gründen ablehnen, z. B. aufgrund von Segmentierung, falscher Prüfsumme oder Anti-Spoofing.
  • Firewallregeln, die Geneve-Pakete an UDP-Port 6081 filtern.

Wenn das Paket an der externen Schnittstelle oder Tunnelschnittstelle des Knotens ankommt, muss es an den Ziel-Pod weitergeleitet werden. Wenn der Pod ein Pod im Hostnetzwerk ist, ist dieser Schritt nicht erforderlich, da der Pod den Netzwerk-Namespace mit dem Knoten teilt. Andernfalls ist eine zusätzliche Paketweiterleitung erforderlich.

Jeder Pod hat virtuelle Ethernet-Schnittstellenpaare, die wie Pipes funktionieren. Ein Paket, das an ein Ende der Schnittstelle gesendet wird, wird vom anderen Ende der Schnittstelle empfangen. Eine der Schnittstellen wird in den Netzwerk-Namespace des Pods verschoben und in eth0 umbenannt. Die andere Schnittstelle bleibt im Host-Namespace. Verschiedene CNIs haben unterschiedliche Schemas. Bei Dataplane v2 heißt die Schnittstelle normalerweise lxcxxxx. Die Namen haben aufeinanderfolgende Schnittstellennummern, wie lxc17 und lxc18. Sie können mit tcpdump prüfen, ob das Paket am Pod ankommt. Sie können auch die Schnittstelle angeben:

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Wenn das Paket den Knoten erreicht, aber nicht den Pod, prüfen Sie die Routingtabelle so:

ip route

Normalerweise sollte jeder Pod einen Routingeintrag haben, der die Pod-IP-Adresse an die Schnittstelle lxc weiterleitet. Wenn der Eintrag fehlt, bedeutet dies in der Regel, dass der CNI-Datenpfad einen Fehler aufweist. Prüfen Sie die CNI DaemonSet-Logs, um die Ursache zu ermitteln.

Probleme mit ausgehendem Traffic

Wenn Traffic bei einem Pod eingehen kann, besteht möglicherweise ein Problem mit dem Traffic, der aus dem Pod ausgeht. Die folgenden Diagramme zeigen, dass in einem Arbeitsbeispiel der eintreffende Traffic von links nach rechts durch den Stack fließt:

Ausgehender Traffic wird vom Pod über die externe Schnittstelle des Hosts an die physische Infrastruktur und dann an den externen Dienst geleitet.

  1. Prüfen Sie den externen Dienst (Layer 4), um zu prüfen, ob das ausgehende Paket korrekt als Knoten-IP-Adresse maskiert wird.

    Die Quell-IP-Adresse des Pakets sollte von der Pod-IP-Adresse mit Quellnetzwerkadressübersetzung (SNAT) der Knoten-IP-Adresse zugeordnet werden. In Dataplane v2 wird dieser Vorgang durch ebpf erreicht, das auf einer externen Schnittstelle geladen wird.

    Prüfen Sie mit tcpdump, ob die Quell-IP-Adresse korrekt von der Pod-IP-Adresse in die Knoten-IP-Adresse übersetzt wurde:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    Wenn tcpdump anzeigt, dass Pakete korrekt maskiert sind, der Remotedienst jedoch nicht reagiert, prüfen Sie die Verbindung zum externen Dienst in Ihrer Infrastruktur.

  2. Wenn die ausgehenden Pakete korrekt als Knoten-IP-Adresse maskiert werden, prüfen Sie die Verbindung zum externen Host (Layer 3) mit tcpdump:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    Senden Sie gleichzeitig mit der Ausführung von tcpdump einen Ping-Befehl von einem der Pods:

    kubectl exec POD_NAME ping EXTERNAL_IP

    Wenn Sie keine Ping-Antworten sehen, prüfen Sie die Verbindung zum externen Dienst in Ihrer Infrastruktur.

Probleme im Cluster

Bei Problemen mit der Pod-zu-Pod-Verbindung sollten Sie versuchen, das Problem auf Knoten einzugrenzen. Oft kann eine Gruppe von Knoten nicht mit einer anderen Gruppe von Knoten kommunizieren.

  1. Prüfen Sie in Dataplane V2 die Knotenverbindung vom aktuellen Knoten zu allen anderen Knoten im selben Cluster. Prüfen Sie im Pod anetd den Systemstatus:

    cilium status --all-health

Probleme mit der Netzwerkebene

Identifizieren, in welcher Netzwerkebene das Verbindungsproblem auftritt, ist ein wichtiger Schritt. Eine Fehlermeldung wie „Ein Verbindungsproblem von einer Quelle zu einem Ziel“ ist nicht aussagekräftig genug, um das Problem zu beheben. Es könnte sich um einen Anwendungsfehler, ein Routingproblem oder ein DNS-Problem handeln. Wenn Sie wissen, auf welcher Ebene das Problem auftritt, können Sie leichter die richtige Komponente korrigieren.

Oft geben Fehlermeldungen direkt an, auf welcher Ebene das Problem auftritt. Die folgenden Beispiele können Ihnen bei der Fehlerbehebung bei Fragen zur Netzwerkebene helfen:

  • HTTP-Fehler weisen darauf hin, dass es sich um ein Layer-7-Problem handelt.
    • HTTP-Codes 40x, 50x oder TLS-Handshake-Fehler bedeuten, dass in Layer 4 alles normal funktioniert.
  • Fehler vom Typ Verbindung wurde von einem anderen Computer zurückgesetzt weisen auf ein Problem in Layer 4 hin.
    • Häufig kann der Remote-Socket nicht mit dem aktuellen Status einer Verbindung übereinstimmen und sendet daher ein RESET-Paket. Dieses Verhalten kann auf einen Fehler beim Verbindungs-Tracking oder bei NAT zurückzuführen sein.
  • Die Fehler Keine Route zum Host und "Zeitüberschreitung der Verbindung" sind normalerweise ein Layer-3- oder Layer-2-Problem.
    • Diese Fehler weisen darauf hin, dass das Paket nicht ordnungsgemäß an das Ziel weitergeleitet werden kann.

Nützliche Tools zur Fehlerbehebung

Netzwerkbezogene DaemonSets werden auf Ihren Knoten ausgeführt und können die Ursache für Verbindungsprobleme sein. Eine fehlerhafte Konfiguration der Knoten, ToR-Switches (Top-of-Rack), Spine-Router oder Firewalls kann jedoch ebenfalls Probleme verursachen. Mit den folgenden Tools können Sie den Umfang oder die Ebene des Problems ermitteln und feststellen, ob es sich um ein Problem mit Ihren GKE Enterprise-Knoten oder Ihrer physischen Infrastruktur handelt.

Ping

Ping arbeitet auf Layer 3 (IP-Ebene) und prüft die Route zwischen einer Quelle und einem Ziel. Wenn der Ping ein Ziel nicht erreicht, liegt das Problem häufig auf Layer 3.

Allerdings können nicht alle IP-Adressen angepingt werden. Einige Load-Balancer-VIPs können beispielsweise nicht angepingt werden, wenn es sich um einen reinen Layer-4-Load-Balancer handelt. Der ClusterIP-Dienst ist ein Beispiel dafür, dass die VIP möglicherweise keine Ping-Antwort zurückgibt. Auf Layer 4 gibt dieser Dienst nur dann eine Ping-Antwort zurück, wenn Sie eine Portnummer angeben, z. B. VIP:port.

Die BGPLB- und MetalLB-Load-Balancer in Google Distributed Cloud arbeiten alle auf Layer 3. Sie können die Verbindung mit Ping prüfen. F5 ist anders, unterstützt aber auch ICMP. Sie können die Verbindung zur F5-VIP mit einem Ping-Befehl prüfen.

Arping

Arping ähnelt dem Ping, funktioniert aber auf Layer 2. Probleme mit Layer 2 und 3 haben häufig ähnliche Fehlermeldungen von Anwendungen. Mithilfe von Arping und Ping können Sie das Problem unterscheiden. Wenn sich Quelle und Ziel beispielsweise im selben Subnetz befinden, Sie aber kein Arping für das Ziel ausführen können, liegt ein Problem auf Layer 2 vor.

Ein erfolgreicher arping <ip> gibt die MAC-Adresse des Ziels zurück. Auf Layer 2 deutet diese Adresse häufig auf ein Problem mit der physischen Infrastruktur hin. Dieses Problem ist häufig ein physischer Wechsel zwischen Knoten.

Arping kann auch IP-Adresskonflikte erkennen. Ein IP-Adresskonflikt tritt auf, wenn zwei Maschinen so konfiguriert sind, dass sie dieselbe IP-Adresse im selben Subnetz verwenden, oder wenn eine VIP von einer anderen physischen Maschine verwendet wird. IP-Adresskonflikte können zu zeitweiligen Problemen führen, die schwer zu beheben sind. Wenn arping <ip> mehr als einen MAC-Adresseintrag zurückgibt, ist dies ein Hinweis darauf, dass ein IP-Adresskonflikt vorliegt.

Nachdem Sie die MAC-Adresse von Arping abgerufen haben, können Sie über https://maclookup.app/ den Hersteller der MAC-Adresse ermitteln. Jeder Hersteller hat ein MAC-Präfix. Anhand dieser Informationen können Sie feststellen, welches Gerät dieselbe IP-Adresse verwenden möchte. Beispiel: VMware besitzt den Block 00:50:56, sodass eine MAC-Adresse 00:50:56:xx:yy:zz eine VM in Ihrer vSphere-Umgebung ist.

iproute2

Die ip-Befehlszeile für iproute2 bietet viele nützliche Unterbefehle, z. B.:

  • ip r: Routentabelle drucken
  • ip n: die Nachbartabelle für die Zuordnung von IP-Adressen zu MAC-Adressen ausdrucken
  • ip a: Alle Schnittstellen auf dem Computer drucken

Eine fehlende Route oder ein fehlender Eintrag in der Nachbartabelle kann zu Verbindungsproblemen mit dem Knoten führen. Anetd verwaltet die Routingtabelle und die Nachbartabelle. Eine Fehlkonfiguration in diesen Tabellen kann zu Verbindungsproblemen führen.

Cilium-/Hubble-Befehlszeile für Dataplane v2

Jeder anetd-Pod hat mehrere nützliche Debugging-Tools für Verbindungsprobleme:

  • cilium monitor --type=drop
    • Das Log für jedes Paket ausgeben, das von anetd / Cilium verworfen wurde.
  • hubble observe
    • Alle Pakete drucken, die durch den ebpf-Stack von anetd gehen
  • cilium status --all-health
    • Den Status von Cilium drucken, einschließlich des Status der Knoten-zu-Knoten-Konnektivität. Jeder anetd-Pod prüft den Zustand aller anderen Knoten im Cluster und kann helfen, Probleme mit der Knoten-zu-Knoten-Verbindung zu ermitteln.

Iptables

Iptables wird in vielen Kubernetes-Komponenten und ‑Subsystemen verwendet. kube-proxy verwendet iptables zur Implementierung der Dienstauflösung.

  1. Verwenden Sie den folgenden Befehl, um Netzwerkprobleme auf iptables-Ebene zu beheben:

    iptables -L -v | grep DROP

    Prüfen Sie die Regeln für das Verwerfen und die Anzahl der Pakete und Bytes, um festzustellen, ob sie im Laufe der Zeit zunehmen.

Tcpdump

Tcpdump ist ein leistungsstarkes Tool zur Paketerfassung, das viele Netzwerktrafficdaten generiert. Häufig wird tcpdump sowohl an der Quelle als auch am Ziel ausgeführt. Wenn ein Paket erfasst wird, wenn es den Quellknoten verlässt, aber nie am Zielknoten erfasst wird, bedeutet das, dass das Paket irgendwo dazwischen verworfen wird. Dieses Verhalten deutet normalerweise darauf hin, dass etwas in Ihrer physischen Infrastruktur das Paket versehentlich verwirft.

DNS-Fehlerbehebung

Probleme bei der DNS-Auflösung lassen sich in zwei Hauptkategorien unterteilen:

  • Reguläre Pods, die die clusterinternen DNS-Server verwenden.
  • Hostnetzwerk-Pods oder -Knoten, die keine DNS-Server im Cluster verwenden

Die folgenden Abschnitte enthalten einige Informationen zur Cluster-DNS-Architektur sowie hilfreiche Tipps, bevor Sie mit der Fehlerbehebung für eine dieser Kategorien beginnen.

Cluster-DNS-Architektur

Ein Cluster-DNS-Dienst löst DNS-Anfragen für Pods im Cluster auf. CoreDNS bietet diesen Dienst für alle Versionen der Google Distributed Cloud.

Jeder Cluster hat zwei oder mehr coredns-Pods und einen Autoscaler, der für die Skalierung der Anzahl der DNS-Pods im Verhältnis zur Clustergröße verantwortlich ist. Es gibt auch einen Dienst namens kube-dns, der Anfragen zwischen allen Back-End-coredns-Pods verteilt.

Bei den meisten Pods ist das vorgelagerte DNS auf die IP-Adresse des kube-dns-Dienstes konfiguriert und Pods senden DNS-Anfragen an einen der coredns-Pods. DNS-Anfragen können in eines der folgenden Ziele gruppiert werden:

  • Wenn die Anfrage für eine cluster.local-Domain erfolgt, handelt es sich um einen clusterinternen DNS-Namen, der auf einen Dienst oder Pod im Cluster verweist.
    • CoreDNS überwacht die api-server für alle Dienste und Pods im Cluster und antwortet auf Anfragen für gültige cluster.local-Domains.
  • Wenn die Anfrage nicht für eine cluster.local-Domain, sondern für eine externe Domain erfolgt,
    • CoreDNS leitet die Anfrage an die Upstream-Nameserver weiter. Standardmäßig verwendet CoreDNS die vorgelagerten Nameserver, die auf dem Knoten konfiguriert sind, auf dem es ausgeführt wird.

Weitere Informationen finden Sie in der Übersicht über die Funktionsweise und Konfiguration von DNS in Kubernetes.

Tipps zur Fehlerbehebung bei DNS

Zur Behebung von DNS-Problemen können Sie die Tools dig und nslookup verwenden. Mit diesen Tools können Sie DNS-Anfragen senden, um zu testen, ob die DNS-Auflösung richtig funktioniert. Die folgenden Beispiele zeigen, wie Sie mit dig und nslookup nach Problemen mit der DNS-Auflösung suchen.

  • Verwenden Sie dig oder nslookup, um eine Anfrage für google.com zu senden:

    dig google.com
nslookup google.com

  • Verwenden Sie dig, um eine Anfrage für kubernetes.default.svc.cluster.local an den Server 192.168.0.10 zu senden:

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

  • Mit nslookup können Sie dieselbe DNS-Suche ausführen wie mit dem vorherigen dig-Befehl:

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    Sehen Sie sich die Ausgabe der Befehle „dig“ oder „nslookup“ an. Wenn Sie eine falsche Antwort oder keine Antwort erhalten, liegt ein Problem mit der DNS-Auflösung vor.

Reguläre Pods

Der erste Schritt zur Behebung eines DNS-Problems besteht darin, zu bestimmen, ob Anfragen an die coredns-Pods gesendet werden oder nicht. Oft wird ein allgemeines Clusterverbindungsproblem als DNS-Probleme angezeigt, da eine DNS-Anfrage der erste Traffictyp ist, den eine Arbeitslast sendet.

Prüfen Sie die Fehlermeldungen Ihrer Anwendungen. Fehler wie io timeout oder ähnliche weisen darauf hin, dass keine Antwort vorliegt und es ein allgemeines Netzwerkverbindungsproblem gibt.

Fehlermeldungen, die einen DNS-Fehlercode wie NXDOMAIN oder SERVFAIL enthalten, geben an, dass eine Verbindung zum clusterinternen DNS-Server besteht, der Server konnte den Domainnamen jedoch nicht auflösen:

  • NXDOMAIN-Fehler weisen darauf hin, dass der DNS-Server meldet, dass die Domain nicht existiert. Prüfen Sie, ob der von Ihrer Anwendung angeforderte Domainname gültig ist.
  • SERVFAIL- oder REFUSED-Fehler weisen darauf hin, dass der DNS-Server eine Antwort gesendet hat, aber die Domain nicht auflösen konnte oder nicht bestätigen konnte, dass sie nicht existiert. Weitere Informationen finden Sie in den Protokollen der coredns-Pods.

Sie können die IP-Adresse des kube-dns-Dienstes mit dem folgenden Befehl ermitteln:

kubectl -n kube-system get svc kube-dns

Versuchen Sie von einem Pod, in dem DNS nicht funktioniert, eine DNS-Anfrage an diese IP-Adresse zu senden. Verwenden Sie dazu dig oder nslookup, wie in einem vorherigen Abschnitt beschrieben:

  • Wenn diese Anfragen nicht funktionieren, versuchen Sie, Anfragen an die IP-Adresse jedes coredns-Pods zu senden.
  • Wenn einige Pods funktionieren, andere aber nicht, prüfen Sie, ob es erkennbare Muster gibt, z. B. ob die DNS-Auflösung für Pods auf demselben Knoten wie dem des coredns-Pods funktioniert, aber nicht für alle Knoten. Dieses Verhalten kann auf ein Verbindungsproblem innerhalb des Clusters hinweisen.

Wenn CoreDNS keine externen Domainnamen auflösen kann, lesen Sie den folgenden Abschnitt zur Fehlerbehebung bei Hostnetzwerk-Pods. CoreDNS verhält sich wie ein Hostnetzwerk-Pod und verwendet die Upstream-DNS-Server des Knotens für die Namensauflösung.

Pods oder Knoten des Hostnetzwerks

Pods im Hostnetzwerk und die Knoten verwenden die auf dem Knoten konfigurierten Nameserver für die DNS-Auflösung, nicht den DNS-Dienst im Cluster. Je nach Betriebssystem ist dieser Nameserver entweder in /etc/resolv.conf oder /run/systemd/resolve/resolv.conf konfiguriert. Diese Konfiguration bedeutet, dass sie keine cluster.local-Domainnamen auflösen können.

Wenn Probleme mit der Namensauflösung des Hosts auftreten, können Sie mit den Schritten zur Fehlerbehebung in den vorherigen Abschnitten prüfen, ob das DNS für Ihre Upstream-Nameserver richtig funktioniert.

Prüfen Sie, ob für alle Knoten dieselben Server konfiguriert sind. Wenn Sie verschiedene Nameserver konfiguriert haben, kann es zu Inkonsistenzen bei der DNS-Auflösung auf verschiedenen Knoten kommen. Prüfen Sie, ob jeder Nameserver einzeln funktioniert, indem Sie mit dig oder nslookup eine Anfrage an jeden senden. Wenn einige Nameserver funktionieren, andere aber nicht, treten diese Fehler wegen inkonsistenter DNS-Auflösung auf.

Häufige Netzwerkprobleme

In den folgenden Abschnitten werden einige häufige Netzwerkprobleme beschrieben, die auftreten können. Folgen Sie der entsprechenden Anleitung zur Fehlerbehebung, um das Problem zu beheben. Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Dataplane V2/Cilium

Häufiger Fehler: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

Dieser Fehler bedeutet, dass das Pod-Erstellungsereignis vom Cilium-Agenten aufgrund einer Ratenbeschränkung abgelehnt wurde. Für jeden Knoten hat Cilium ein Limit von vier gleichzeitigen Anfragen an den PUT-Endpunkt. Wenn plötzlich viele Anfragen bei einem Knoten eingehen, ist dieses Verhalten zu erwarten. Der Cilium-Agent sollte verzögerte Anfragen abarbeiten können.

In GKE Enterprise 1.14 und höher wird die Ratenbeschränkung automatisch an die Knotenkapazität angepasst. Die Ratenbegrenzung kann sich einer angemessenen Zahl annähern, wobei für leistungsstärkere Knoten höhere Ratenbegrenzungen gelten.

Häufiger Fehler: Ebpf map size is full

Dataplane v2 speichert den Status in einer eBFP-Zuordnung. Der Status umfasst Dienst, Verbindungs-Tracking, Pod-Identität und Netzwerkrichtlinienregeln. Wenn eine Zuordnung voll ist, kann der Agent keine Einträge einfügen, was zu einer Diskrepanz zwischen der Steuerungsebene und der Datenebene führt. Die Dienstzuordnung hat beispielsweise ein Eintragslimit von 64.000.

  1. Mit bpftool können Sie eBFP-Zuordnungseinträge und ihre aktuelle Größe prüfen. Im folgenden Beispiel werden die Load Balancer-Zuordnungen geprüft:

    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. Wenn die Zuordnung das Limit von 64.000 erreicht hat, bereinigen Sie sie. Im folgenden Beispiel werden die Load Balancer-Zuordnungen bereinigt:

    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. Starten Sie anetd neu, um den Status in der eBFP-Zuordnung neu zu füllen.

Knoten nicht bereit aufgrund von NetworkPluginNotReady-Fehlern

Wenn der CNI-Pod nicht auf dem Knoten ausgeführt wird, wird möglicherweise ein ähnlicher Fehler wie der folgende angezeigt:

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

Möglicherweise befindet sich der Knoten auch in einem nicht bereiten Zustand, mit einem Fehler wie im folgenden Beispiel:

  "Network plugin not installed"

Wenn ein Knoten initialisiert wird, wartet kubelet auf mehrere Ereignisse, bevor der Knoten als Ready gekennzeichnet wird. Eines der von kubelet geprüften Ereignisse ist, dass das Plug-in "Container Network Interface (CNI)" installiert ist. Das CNI-Plug-in sollte von anetd mithilfe eines Init-Containers installiert werden, um sowohl die CNI-Binärdatei als auch die CNI-Konfiguration in den erforderlichen Hostverzeichnissen zu installieren.

Prüfen Sie zur Fehlerbehebung, warum diese Pods nicht auf dem Knoten ausgeführt werden. Normalerweise wird der Fehler nicht durch Netzwerkprobleme verursacht. Diese Pods werden im Hostnetzwerk ausgeführt, sodass keine Netzwerkabhängigkeit besteht.

  1. Prüfen Sie den Status des Pods anetd. Führen Sie die folgenden Schritte zur Fehlerbehebung aus, um die Ursache des Problems zu ermitteln:

    • Wenn der Pod den Status Crashlooping hat, prüfen Sie in den Logs, warum der Pod nicht ordnungsgemäß ausgeführt werden kann.
    • Wenn der Pod den Status Pending hat, verwenden Sie kubectl describe und prüfen Sie die Pod-Ereignisse. Im Pod fehlt beispielsweise eine Ressource wie ein Volume.
    • Wenn der Pod den Status Running hat, prüfen Sie die Protokolle und die Konfiguration. Einige CNI-Implementierungen bieten Optionen zur Deaktivierung der CNI-Installation, wie in Cilium.
    • In anetd gibt es eine Konfigurationsoption namens custom-cni-conf. Wenn diese Einstellung auf true konfiguriert ist, installiert anetd die CNI-Binärdatei nicht.

Knoten NICHT BEREIT aufgrund veralteter ARP-Einträge

Manchmal können veraltete ARP-Einträge in Knoten der Steuerungsebene des Administratorclusters zu einer Abweichung bei MAC-Adressen führen. Diese nicht übereinstimmende Adresse kann wiederum zu Zeitüberschreitungen bei den Verbindungen bei den VIPs der Steuerungsebene verwalteter Nutzercluster führen. Die Zeitüberschreitungen der Verbindung können dazu führen, dass der Knoten veraltete ARP-Einträge als NOT READY markiert. Knoten, die als NOT READY markiert sind, können Clusterinstallationen und -upgrades anhalten.

In diesem Fall enthält das Kubelet-Log des Knotens mit veralteten ARP-Einträgen einen TLS-Handshake-Zeitüberschreitungsfehler wie den folgenden:

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

Führen Sie die folgenden Schritte aus, um das Problem zu überprüfen und zu beheben:

  1. Verwenden Sie SSH, um eine Verbindung zum Knoten der Steuerungsebene des Nutzerclusters herzustellen.

  2. Prüfen Sie die MAC-Adresse der Schnittstelle, an die die VIP-Adresse gebunden ist:

    ip a | grep DEVICE_NAME: -A 6

    Ersetzen Sie DEVICE_NAME durch den Namen des Netzwerkgeräts für den Steuerungsebenenknoten.

  3. Verwenden Sie SSH, um eine Verbindung zu einem Knoten der Steuerungsebene des Administratorclusters herzustellen.

  4. Prüfen Sie den ARP-Cache auf der Steuerungsebene des Administratorclusters auf die VIP-Adresse der Steuerungsebene des Nutzerclusters:

    ip n | grep VIP_ADDRESS

    Ersetzen Sie VIP_ADDRESS durch die IP-Adresse der VIP der Steuerungsebene des Nutzerclusters (controlPlaneVIP).

    Wenn die beiden ip-Befehle eine andere macOS-Adresse zurückgeben, sind Sie von diesem Problem betroffen.

  5. Leeren Sie den ARP-Cache auf dem Knoten der Administratorcluster-Steuerungsebene, um das Problem zu beheben:

    ip n flush all

F5-Dienst empfängt keinen Traffic

Wenn kein Traffic an den F5-Dienst weitergeleitet wird, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

  1. Prüfen Sie, ob jede Partition in F5 BIG-IP in einem Cluster konfiguriert ist, entweder in Administrator- oder Nutzerclustern. Wenn eine Partition von mehreren verschiedenen Clustern gemeinsam genutzt wird, kommt es zu sporadischen Verbindungsunterbrechungen. Dieses Verhalten ist darauf zurückzuführen, dass zwei Cluster versuchen, die Kontrolle über dieselbe Partition zu übernehmen und Dienste aus anderen Clustern zu löschen.

  2. Prüfen Sie, ob die folgenden beiden Pods ausgeführt werden. Nicht laufende Pods weisen auf einen Fehler hin:

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

    Die Load-balancer-f5 gehört zu GKE Enterprise und erstellt ConfigMaps für jeden Dienst vom Typ „LoadBalancer“. Die ConfigMap wird schließlich vom bigip-Controller verwendet.

  3. Achten Sie darauf, dass die ConfigMap für jeden Port jedes Dienstes vorhanden ist. Beispielsweise mit den folgenden Ports:

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

    Sollte der kube-server-Dienst in etwa wie das folgende Beispiel aussehen:

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

    Der Datenabschnitt in der ConfigMap sollte die VIP-Adresse und den Port des Frontends enthalten, wie im folgenden Beispiel gezeigt:

    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. Prüfen Sie die Logs und Messwerte Ihrer BIG-IP-Instanz. Wenn die ConfigMap richtig konfiguriert ist, die BIG-IP-Instanz die Konfiguration jedoch nicht berücksichtigt, kann dies ein F5-Problem sein. Bei Problemen innerhalb der BIG-IP-Instanz wenden Sie sich an den F5-Support, um die Probleme zu diagnostizieren und zu beheben.

NAT-Fehler mit zu vielen parallelen Verbindungen

Für einen bestimmten Knoten in Ihrem Cluster bietet die Knoten-IP-Adresse Network Address Translation (NAT) für Pakete, die an eine Adresse außerhalb des Clusters weitergeleitet werden. Wenn eingehende Pakete in einen Load-Balancing-Knoten gelangen, der für die Verwendung des gebündelten Load-Balancings (spec.loadBalancer.mode: bundled) konfiguriert ist, leitet die Quellnetzwerkadressübersetzung (SNAT) die Pakete an die Knoten-IP-Adresse weiter, bevor sie werden an einen Backend-Pod weitergeleitet.

Der von Google Distributed Cloud verwendete Portbereich für NAT ist 32768-65535. Dieser Bereich begrenzt die Anzahl paralleler Verbindungen auf 32.767 pro Protokoll auf diesem Knoten. Jede Verbindung benötigt einen Eintrag in der Conntrack-Tabelle. Wenn Sie zu viele kurzlebige Verbindungen haben, braucht die Conntrack-Tabelle die Ports für NAT auf. Eine Speicherbereinigung bereinigt die veralteten Einträge, die Bereinigung erfolgt jedoch nicht sofort.

Wenn sich die Anzahl der Verbindungen auf dem Knoten 32.767 nähert, werden Sie Paketverluste für Verbindungen feststellen, die NAT benötigen.

So ermitteln Sie, ob Sie von diesem Problem betroffen sind:

  1. Führen Sie den folgenden Befehl auf dem Pod anetd auf dem problematischen Knoten aus:

    kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

    Es sollten Fehler in folgender Form angezeigt werden:

    No mapping for NAT masquerade DROPPED

Als Behelfslösung für dieses Problem können Sie den Traffic auf andere Knoten verteilen.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.