Google Distributed Cloud-Netzwerkprobleme 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. Informationen zur DNS-Fehlerbehebung und einige häufige Probleme bei Calico, Seesaw und MetalLB sind ebenfalls enthalten.

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

Fehlerbehebung bei der Netzwerkverbindung

Das GKE Enterprise-Netzwerk basiert auf Ihrer physischen Netzwerkinfrastruktur. Beispielsweise verlassen sich Seesaw oder MetalLB darauf, dass Ihre Switches Gratuitous ARP berücksichtigen, während das gebündelte Load-Balancing mit dem Border Gateway Protocol (BGP) von Ihren Routern abhängt und alle Knoten miteinander kommunizieren können. Wenn in Ihren GKE-Clustern ein Netzwerkproblem auftritt, müssen Sie herausfinden, ob es von den GKE Enterprise-Komponenten oder Ihrer eigenen Infrastruktur verursacht wird.

Bestimmen Sie zuerst den Umfang des Problems und versuchen Sie dann, die betroffenen Komponenten zu identifizieren. Ein Problem kann in drei Kategorien eingeteilt werden: Thema (von wo aus), das Ziel (zu welchem Ziel) und Netzwerkschicht.

Der Umfang des Subjekts kann einer der folgenden sein:

• Alle Knoten (oder hostNetwork-Pod) im Cluster
• Alle Pods clusterübergreifend.
• 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 Umfang des Ziels kann eines oder mehrere der folgenden sein:

• Alle anderen Pod-IP-Adressen aus demselben Cluster.
• Alle anderen Pod-IP-Adressen vom selben Knoten.
• ClusterIP-Dienst-VIP aus demselben Cluster.
• Virtuelle IP-Adresse des LoadBalancer-Dienstes aus demselben Cluster.
• Layer-7-LoadBalancer (Istio) für eingehenden Traffic
• Andere Knoten aus demselben Cluster.
• Interner DNS-Name (z. B. *.svc.cluster.local).
• Name des externen DNS (z. B. google.com).
• Entitäten außerhalb des Clusters.
• Entitäten im Internet.

Die Netzwerkschicht kann eine oder mehrere der folgenden sein:

• Probleme der Ebene-2-Verbindungsschicht wie Nachbarsystem, ARP oder NDP.
• Probleme beim Routing von Layer-3-IP-Adressen.
• Layer-4-TCP- oder UDP-Endpunktprobleme
• Ebene-7-HTTP- oder HTTPS-Probleme.
• DNS-Auflösungsprobleme.

Wenn Sie den Umfang eines Problems verstehen, können Sie die vom Problem betroffenen Komponenten ermitteln und ermitteln, in welcher Ebene das Problem auftritt. Es ist wichtig, Informationen zu erfassen, wenn das Problem auftritt, da einige Probleme vorübergehend sind. Daher enthalten Snapshots nach der Systemwiederherstellung nicht genügend Informationen für die Ursachenanalyse.

Probleme mit eingehendem Traffic

Wenn das Subjekt ein Client außerhalb des Clusters ist und keine Verbindung zu einem LoadBalancer-Dienst herstellen konnte, liegt ein North-South-Verbindungsproblem vor. Das folgende Diagramm zeigt, dass der eingehende Traffic in einem praktischen Beispiel den Stapel von links nach rechts durchquert und der Rücktraffic von rechts nach links durch den Stack zurückgeleitet wird. Seesaw ist anders, da der Rücktraffic den Load-Balancer überspringt und direkt zum Client zurückkehrt:

Wenn bei diesem Datenverkehr ein Problem auftritt, können Sie anhand des folgenden Flussdiagramms zur Fehlerbehebung herausfinden, wo das Problem liegt:

In diesem Flussdiagramm helfen dir die folgenden Schritte zur Fehlerbehebung, herauszufinden, wo das Problem liegt:

• Verlässt das Paket den Client? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
• Verwenden Sie den Seesaw-Load-Balancer? Wenn ja, kommt das Paket beim Seesaw-Knoten an und wird ARP dann korrekt gesendet? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
• Verwenden Sie MetalLB? Wenn ja, kommt das Paket beim Load-Balancer-Knoten an und wird ARP dann korrekt gesendet? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
• Verwenden Sie F5 BIG-IP und wenn ja, haben Sie nach F5-Problemen gesucht?
• Wird Network Address Translation (NAT) korrekt ausgeführt? Wenn nicht, liegt wahrscheinlich ein Problem mit kube-proxy / Dataplane V2 vor.
• Geht das Paket beim Worker-Knoten an? Wenn nicht, liegt wahrscheinlich ein Pod-zu-Pod-Problem mit Calico / Dataplane v2 vor.
• Geht das Paket beim Pod an? Wenn nicht, liegt wahrscheinlich ein Problem mit der lokalen Weiterleitung von Calico / Dataplane v2 vor.

In den folgenden Abschnitten werden Schritte zur Fehlerbehebung in den einzelnen Phasen beschrieben, damit Sie feststellen können, ob der Traffic korrekt fließt.

Verlässt das Paket den Client?

Prüfen Sie, ob das Paket den Client korrekt verlässt und den Router durchläuft, der in Ihrer physischen Netzwerkinfrastruktur konfiguriert ist.

1. Verwenden Sie tcpdump, um das Paket zu prüfen, während es den Client für den Zieldienst verlässt:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Wenn Sie keine Zugriffe abnehmen, ist dies die Ursache des Problems.

Geht das Paket bei einem Seesaw-Knoten an?

Wenn Sie Seesaw als Load-Balancer verwenden, suchen Sie den Masterknoten und stellen Sie dann über SSH eine Verbindung zum Knoten her.

1. Prüfen Sie mit tcpdump, ob die erwarteten Pakete beim Seesaw-Knoten eingegangen sind:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Wenn keine Zugriffe eingehen, ist dies die Ursache des Problems.

Geht das Paket bei einem LoadBalancer-Knoten an?

Wenn Sie MetalLB als Load-Balancer verwenden:

1. Sehen Sie sich das Log metallb-controller an, um festzustellen, welcher Load-Balancer-Knoten die Dienst-VIP bereitstellt:

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

2. Stellen Sie über SSH eine Verbindung zum Knoten her.

3. Verwenden Sie für einen MetalLB-Knoten tcpdump, um den Traffic zu prüfen:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Bei manualLB könnte der Traffic auf einem beliebigen Knoten landen. Je nach Konfiguration des Load-Balancers können Sie einen oder mehrere Knoten auswählen. Verwenden Sie tcpdump, um den Traffic zu prüfen:

   tcpdump -ni any host NODE_IP and port NODE_PORT
   

   Der Befehl unterscheidet sich zwischen den Load-Balancer-Typen, da MetalLB und Seesaw vor der Weiterleitung des Pakets an Knoten keine NAT ausführen.

   Wenn an keinem Knoten Traffic fließt, ist dies die Ursache des Problems.

Gibt es ein F5 BIG-IP-Problem?

Informationen zur Fehlerbehebung bei F5 BIG-IP-Problemen finden Sie in einem der folgenden Abschnitte unter F5-Dienst empfängt keinen Traffic.

Wurde der ARP korrekt gesendet?

Der Load-Balancer-Knoten für MetalLB oder Seesaw nutzt ARP, um die Dienst-VIP anzubieten. Wenn die ARP-Antwort korrekt gesendet wird, aber kein Traffic eingeht, ist dies ein Hinweis auf ein Problem in Ihrer physischen Netzwerkinfrastruktur. Eine häufige Ursache für dieses Problem besteht darin, dass einige erweiterte Funktionen für das Dataplane-Lernen die ARP-Antwort in Lösungen für Softwaredefinierte Netzwerke (SDN) ignorieren.

1. Verwenden Sie tcpdump, um ARP-Antworten zu erkennen:

   tcpdump -ni any arp
   

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

   • Bei Seesaw werden Gratuitous-ARS für alle VIPs gesendet. Sie sollten die ARP-Nachrichten für jede VIP alle 10 Sekunden sehen.

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

Wird NAT ausgeführt?

Dataplane v2 / kube-proxy führt eine Zielnetzwerkadressübersetzung (Ziel-NAT oder DNAT) durch, um die Ziel-VIP in eine Back-End-Pod-IP-Adresse zu übersetzen. Wenn Sie wissen, welcher Knoten das Back-End 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 wurde:

   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 Debug-Tools von Cilium verwenden:

   cilium monitor --type=drop
   

Weitere Informationen finden Sie in einem der folgenden Abschnitte zu Problemen mit Dataplane v2 / Clium.

Geht das Paket bei einem Worker-Knoten an?

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

1. Prüfen Sie mit tcpdump, ob das Paket bei der externen Schnittstelle, normalerweise mit dem Namen eth0 oder ens192, ankommt:

   tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
   

Da normale Service-Back-Ends mehrere Pods auf verschiedenen Knoten enthalten, kann es schwierig sein, herauszufinden, welcher Knoten fehlerhaft ist. Eine gängige Problemumgehung besteht darin, das Problem entweder lange genug zu erfassen, sodass ein Paket letztendlich eintrifft, oder die Anzahl der Back-Ends auf eins zu begrenzen.

Wenn das Paket den Arbeitsknoten nie erreicht, weist dies auf ein Problem mit der Netzwerkinfrastruktur hin. Erkundigen Sie sich beim Team für die Netzwerkinfrastruktur, warum das Paket zwischen LoadBalancer- und Worker-Knoten verworfen wurde. Hier einige häufige Probleme:

• Prüfen Sie die Protokolle Ihres softwarebasierten Netzwerks (SDN). Manchmal verwirft das SDN aus verschiedenen Gründen Pakete, z. B. aufgrund von Segmentierung, falscher Prüfsumme oder Anti-Spoofing.
• Firewallregeln, die Pakete filtern, deren Ziel die IP-Adresse und der Port des Back-End-Pods sind

Wenn das Paket an der externen Schnittstelle oder Tunnelschnittstelle des Knotens ankommt, muss es an den Ziel-Pod weitergeleitet werden. Wenn der Pod ein Hostnetzwerk-Pod 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 an ein Ende der Schnittstelle gesendetes Paket 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 wird im Host-Namespace beibehalten. Verschiedene CNIs haben unterschiedliche Schemas. Bei Dataplane v2 heißt die Schnittstelle normalerweise lxcxxxx. Die Namen haben aufeinanderfolgende Schnittstellennummern, z. B. lxc17 und lxc18. Mit tcpdump können Sie prüfen, ob das Paket beim Pod ankommt. Alternativ können Sie auch die Schnittstelle angeben:

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Wenn das Paket beim Knoten, aber nicht beim Pod ankommt, 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 normalerweise, 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 an einen Pod eingeht, gibt es möglicherweise ein Problem mit dem Traffic, der den Pod ausgeht. Die folgenden Diagramme zeigen, dass der eingehende Traffic in einem praktischen Beispiel den Stack von links nach rechts durchläuft:

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

   Die Quell-IP-Adresse des Pakets sollte mit der Quellnetzwerkadressübersetzung (Quell-NAT oder SNAT) von der Pod-IP-Adresse der Knoten-IP-Adresse zugeordnet werden. In Dataplane v2 wird dieser Prozess mit ebpf ausgeführt, das auf einer externen Schnittstelle geladen wird. Calico verwendet iptables-Regeln.

   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 Remote-Dienst aber nicht reagiert, prüfen Sie die Verbindung zum externen Dienst in Ihrer Infrastruktur.

2. Wenn die ausgehenden Pakete korrekt als Knoten-IP-Adresse maskiert sind, prüfen Sie die Verbindung des externen Hosts (Ebene 3) mit tcpdump:

   tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp
   

   Senden Sie während der Ausführung von tcpdump einen Ping von einem der Pods aus:

   kubectl exec POD_NAME ping EXTERNAL_IP
   

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

Clusterinterne Probleme

Versuchen Sie bei Pod-zu-Pod-Verbindungsproblemen, das Problem auf Knoten zu beschränken. Häufig 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 Systemdiagnosestatus:

   cilium status --all-health
   

   Google Distributed Cloud verwendet den direkten Routingmodus. Sie sollten einen Routeneintrag pro Knoten im Cluster sehen, wie im folgenden Beispiel gezeigt:

   # <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
   

   Wenn eine erwartete Route für einen Knoten fehlt, wird die Verbindung zu diesem Knoten unterbrochen.

Probleme mit der Netzwerkschicht

Es ist wichtig zu ermitteln, in welcher Netzwerkschicht das Verbindungsproblem auftritt. Eine Fehlermeldung wie "A connection issue from a source to a destination" (Ein Verbindungsproblem von einer Quelle zu einem Ziel) ist nicht aussagekräftig genug, um das Problem zu beheben. Es kann sich um einen Anwendungsfehler, ein Routing- oder DNS-Problem handeln. Wenn Sie wissen, auf welcher Schicht das Problem auftritt, können Sie die richtige Komponente

Häufig geben Fehlermeldungen direkt an, auf welcher Schicht das Problem auftritt. Die folgenden Beispiele können Ihnen bei der Behebung von Fragen zur Netzwerkschicht helfen:

• HTTP-Fehler weisen darauf hin, dass es sich um ein Layer-7-Problem handelt.
  • Die HTTP-Codes 40x, 50x oder TLS-Handshake-Fehler bedeuten, dass auf Layer 4 alles normal funktioniert.
• "Verbindung durch Peer zurückgesetzt" deuten darauf hin, dass es sich um ein Layer-4-Problem handelt.
  • Häufig kann der Remote-Socket nicht mit dem aktuellen Status einer Verbindung übereinstimmen und daher ein RESET-Paket senden. Dieses Verhalten kann ein Fehler bei der Verbindungsverfolgung oder NAT sein.
• Die Fehler "No route to host" und "Connection timeout" sind normalerweise ein Problem der Ebene 3 oder 2.
  • Diese Fehler weisen darauf hin, dass das Paket nicht korrekt an das Ziel weitergeleitet werden kann.

Nützliche Tools zur Fehlerbehebung

Netzwerkbezogene DaemonSets werden auf Ihren Knoten ausgeführt und können die Ursache von Verbindungsproblemen sein. Allerdings kann auch eine fehlerhafte Konfiguration Ihrer Knoten, Top-of-Rack-Switches (ToR-Switches), Spine-Router oder Firewalls zu Problemen führen. Mit den folgenden Tools können Sie den Umfang oder die Ebene des Problems bestimmen und feststellen, ob ein Problem mit Ihren GKE Enterprise-Knoten oder Ihrer physischen Infrastruktur vorliegt.

Ping

Ping arbeitet auf Ebene 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 Ebene 3.

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

Die Load-Balancer BGP, MetalLB und Seesaw in Google Distributed Cloud arbeiten alle auf Ebene 3. Sie können die Verbindung mit dem Befehl „ping“ prüfen. F5 ist anders, unterstützt aber auch ICMP. Sie können die Verbindung zur F5-VIP mit dem Befehl „ping“ prüfen.

Arping

Das Arping ähnelt dem Ping, mit dem Unterschied, dass es auf Ebene 2 funktioniert. Probleme der Ebene 2 und 3 haben oft ähnliche Fehlermeldungen von Anwendungen. Mithilfe von Arping und Ping können Sie Probleme unterscheiden. Wenn sich die Quelle und das Ziel beispielsweise im selben Subnetz befinden, Sie das Ziel aber nicht arrangieren können, handelt es sich um ein Layer-2-Problem.

Ein erfolgreicher arping <ip> gibt die MAC-Adresse des Ziels zurück. Auf Ebene 2 weist diese Adresse häufig auf ein Problem mit der physischen Infrastruktur hin. Dieses Problem ist eine fehlerhafte Konfiguration des virtuellen Switches.

Außerdem können mit Arping Konflikte zwischen IP-Adressen erkannt werden. Ein IP-Adresskonflikt liegt vor, wenn zwei Maschinen so konfiguriert sind, dass sie dieselbe IP-Adresse im selben Subnetz verwenden, oder eine VIP von einem anderen physischen Computer verwendet wird. Konflikte mit IP-Adressen können zeitweise Probleme verursachen, die schwer zu beheben sind. Wenn arping <ip> mehr als einen MAC-Adresseintrag zurückgibt, ist dies ein Hinweis auf einen Konflikt mit einer IP-Adresse.

Nachdem Sie die MAC-Adresse aus arping erhalten haben, können Sie auf https://maclookup.app/ nach dem Hersteller der MAC-Adresse suchen. Jeder Hersteller besitzt ein MAC-Präfix. Daher können Sie anhand dieser Informationen feststellen, welches Gerät versucht, dieselbe IP-Adresse zu verwenden. VMware ist beispielsweise Inhaber des Blocks 00:50:56, sodass die MAC-Adresse 00:50:56:xx:yy:zz eine VM in Ihrer vSphere-Umgebung ist.

iproute2

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

• ip r: Routingtabelle wird ausgegeben.
• ip n: gibt die Nachbartabelle für die Zuordnung der IP-Adresse zur MAC-Adresse aus
• ip a: gibt alle Schnittstellen auf dem Computer aus.

Eine fehlende Route oder ein fehlender Eintrag in der Nachbartabelle kann zu Verbindungsproblemen des Knotens führen. Anetd und Calico verwalten beide die Routingtabelle und die Nachbartabelle. Eine fehlerhafte Konfiguration in diesen Tabellen kann zu Verbindungsproblemen führen.

Cilium / Hubble-CLI für Dataplane v2

Jeder anetd-Pod verfügt über mehrere nützliche Debugging-Tools für Verbindungsprobleme:

• cilium monitor --type=drop
  • Drucken Sie das Protokoll für jedes Paket aus, das von anetd / Cilium gelöscht wird.
• hubble observe
  • Drucken Sie alle Pakete durch den ebpf-Stack von anetd.
• cilium status --all-health
  • Gibt den Status von Cilium aus, einschließlich des Knoten-zu-Knoten-Verbindungsstatus. Jeder freigegebene Pod prüft den Status aller anderen Knoten im Cluster und kann dabei helfen, Verbindungsprobleme zwischen Knoten zu ermitteln.

IPTAL

IP-Tabellen werden in vielen Kubernetes-Komponenten und -Subsystemen verwendet. kube-proxy verwendet iptables zur Implementierung der Dienstauflösung. Calico verwendet iptables zur Implementierung der Netzwerkrichtlinie

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

   iptables -L -v | grep DROP
   

   Überprüfen Sie die Löschregeln und die Paket- und Byteanzahl, um festzustellen, ob sie im Laufe der Zeit ansteigen.

tcpdump

tcpdump ist ein leistungsstarkes Paketerfassungstool, das viele Netzwerk-Traffic-Daten generiert. Häufig wird „tcpdump“ sowohl von der Quelle als auch vom Ziel aus ausgeführt. Wenn ein Paket erfasst wird, wenn es den Quellknoten verlässt, aber niemals auf dem Zielknoten erfasst wird, bedeutet dies, dass das Paket von etwas dazwischen gelöscht wird. Dieses Verhalten weist normalerweise darauf hin, dass das Paket fälschlicherweise in Ihrer physischen Infrastruktur gelöscht wird.

DNS-Fehlerbehebung

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

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

Die folgenden Abschnitte enthalten einige Informationen zur Cluster-DNS-Architektur und 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 Google Distributed Cloud ab Version 1.9.0.

Jeder Cluster hat zwei oder mehr coredns-Pods und ein Autoscaling, das die Anzahl der DNS-Pods relativ zur Clustergröße skaliert. Außerdem gibt es einen Dienst mit dem Namen kube-dns, der das Load-Balancing der Anfragen zwischen allen coredns-Back-End-Pods ausgleicht.

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

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

Weitere Informationen finden Sie in der Übersicht darüber, wie DNS in Kubernetes funktioniert und konfiguriert wird.

Tipps zur DNS-Fehlerbehebung

DNS-Probleme lassen sich mit den Tools dig und nslookup beheben. Mit diesen Tools können Sie DNS-Anfragen senden, um zu testen, ob die DNS-Auflösung korrekt funktioniert. Die folgenden Beispiele zeigen, wie Sie mit dig und nslookup nach Problemen bei 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
  

• Sie können auch mit nslookup den gleichen DNS-Lookup wie mit dem vorherigen dig-Befehl ausführen:

  nslookup kubernetes.default.svc.cluster.local 192.168.0.10
  

  Überprüfen Sie die Ausgabe der Befehle dig oder nslookup. Wenn Sie eine falsche oder keine Antwort erhalten, weist dies auf ein Problem mit der DNS-Auflösung hin.

Reguläre Pods

Der erste Schritt zur Fehlerbehebung eines DNS-Problems besteht darin, zu ermitteln, ob Anfragen an die coredns-Pods gesendet werden oder nicht. Häufig treten allgemeine Probleme mit der Clusterverbindung als DNS-Probleme auf, da eine DNS-Anfrage der erste Traffictyp ist, den eine Arbeitslast sendet.

Überprüfen Sie die Fehlermeldungen Ihrer Anwendungen. Fehler wie io timeout oder Ähnliches zeigen an, dass es keine Antwort gibt und dass ein allgemeines Problem mit der Netzwerkverbindung besteht.

Fehlermeldungen mit einem DNS-Fehlercode wie NXDOMAIN oder SERVFAIL weisen darauf hin, dass eine Verbindung zum DNS-Server im Cluster besteht, der Server den Domainnamen jedoch nicht auflösen konnte:

• NXDOMAIN-Fehler zeigen an, dass der DNS-Server meldet, dass die Domain nicht existiert. Prüfen Sie, ob der Domainname, den Ihre Anwendung anfordert, gültig ist.
• Die Fehler SERVFAIL oder REFUSED weisen darauf hin, dass der DNS-Server eine Antwort gesendet hat, die Domain jedoch nicht auflösen oder bestätigen konnte, dass sie nicht existiert. Weitere Informationen finden Sie in den Logs 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, mit dig oder nslookup eine DNS-Anfrage an diese IP-Adresse zu senden, 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 jedoch nicht, prüfen Sie, ob erkennbare Muster vorhanden sind. Beispielsweise funktioniert die DNS-Auflösung für Pods auf demselben Knoten wie der Pod coredns, jedoch nicht knotenübergreifend. Dieses Verhalten kann auf ein Verbindungsproblem im Cluster hindeuten.

Wenn CoreDNS externe Domainnamen nicht auflösen kann, finden Sie im folgenden Abschnitt Informationen zur Fehlerbehebung bei den Hostnetzwerk-Pods. CoreDNS verhält sich wie ein Hostnetzwerk-Pod und verwendet die vorgelagerten DNS-Server des Knotens zur Namensauflösung.

Hostnetzwerk-Pods oder -Knoten

Hostnetzwerk-Pods und die Knoten verwenden die Nameserver, die auf dem Knoten für die DNS-Auflösung konfiguriert sind, und 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 cluster.local-Domainnamen nicht auflösen können.

Wenn Sie Probleme mit der Auflösung von Hostnamen-Netzwerknamen haben, führen Sie die Schritte zur Fehlerbehebung in den vorherigen Abschnitten aus, um zu testen, ob DNS für Ihre Upstream-Nameserver korrekt funktioniert.

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.

Calico

Häufige Fehler: calico/node is not ready: BIRD is not ready: BGP not established

Dieser Statusfehler „Nicht bereit“ in Kubernetes bedeutet in der Regel, dass ein bestimmter Peer im Cluster nicht erreichbar ist. Prüfen Sie, ob die BGP-Verbindung zwischen den beiden Peers in Ihrer Umgebung zulässig ist.

Dieser Fehler kann auch auftreten, wenn inaktive Knotenressourcen für ein Knoten-zu-Knoten-Mesh konfiguriert sind. Deaktivieren Sie die veralteten Knoten, um dieses Problem zu beheben.

Dataplane v2 / Clium

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

Dieser Fehler bedeutet, dass das Pod-Erstellungsereignis vom Cilium-Agent aufgrund einer Ratenbegrenzung abgelehnt wurde. Für jeden Knoten hat Cilium ein Limit von vier gleichzeitigen Anfragen an den PUT-Endpunkt. Dieses Verhalten ist zu erwarten, wenn mehrere Anfragen an einen Knoten gesendet werden. Der Cilium-Agent sollte verzögerte Anfragen nachholen.

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

Häufige Fehler: Ebpf map size is full

Dataplane v2 speichert den Status in einer eBFP-Karte. Der Status umfasst Regeln für Dienste, Verbindungs-Tracking, Pod-Identität und Netzwerkrichtlinien. Wenn eine Karte voll ist, kann der Agent keine Einträge einfügen, wodurch eine Diskrepanz zwischen der Steuerungsebene und der Datenebene entsteht. Für die Dienstkarte gilt beispielsweise ein Eintragslimit von 64.000.

1. Verwenden Sie bpftool, um eBFP-Zuordnungseinträge und ihre aktuelle Größe zu 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 Karte die 64.000-Grenze fast erreicht hat, bereinigen Sie die Karten. 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. Wenn Sie den Status wieder in die eBFP-Zuordnung einfügen möchten, starten Sie anetd neu.

Knoten ungelesen aufgrund von NetworkPluginNotReady-Fehlern

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

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

Der Knoten kann auch einen ungelesenen Status haben, wobei ein Fehler wie im folgenden Beispiel auftritt:

  "Network plugin not installed"

Wenn ein Knoten initialisiert wird, wartet kubelet auf das Eintreten mehrerer Ereignisse, bevor der Knoten als Ready gekennzeichnet wird. kubelet prüft unter anderem, ob das CNI-Plug-in (Container Network Interface) installiert ist. Das CNI-Plug-in sollte von anetd oder Calico mit einem Init-Container installiert werden, um sowohl die CNI-Binärdatei als auch die CNI-Konfiguration in den erforderlichen Hostverzeichnissen zu installieren.

Prüfen Sie zur Behebung dieses Problems, warum diese Pods nicht auf dem Knoten ausgeführt werden. Normalerweise ist der Fehler nicht auf Netzwerkprobleme zurückzuführen. Da diese Pods im Hostnetzwerk ausgeführt werden, besteht keine Netzwerkabhängigkeit.

1. Prüfen Sie den Status des Pods anetd oder calico-node. Gehen Sie die folgenden Schritte zur Fehlerbehebung durch, um die Ursache des Problems zu ermitteln:

   • Wenn der Pod den Status Crashlooping hat, sehen Sie in den Logs nach, 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 könnte beispielsweise eine Ressource wie ein Volume fehlen.
   • Wenn der Pod den Status Running hat, prüfen Sie die Logs und die Konfiguration. Einige CNI-Implementierungen bieten Optionen zum Deaktivieren der CNI-Installation, z. B. in Cilium.
   • In anetd gibt es die Konfigurationsoption custom-cni-conf. Wenn diese Einstellung als true konfiguriert ist, installiert anetd nicht sein CNI-Binärprogramm.

F5-Dienst empfängt keinen Traffic

Wenn kein Traffic an den F5-Dienst weitergeleitet wird, überprüfen Sie die folgenden Schritte zur Fehlerbehebung:

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, treten zeitweise Verbindungsunterbrechungen auf. Dies liegt daran, 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. Alle nicht ausgeführten 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 genutzt.

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

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

   Der kube-server-Dienst sollte in etwa so 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 Frontend-VIP und den Port 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 der BIG-IP-Instanz. Wenn die ConfigMap korrekt konfiguriert ist, die BIG-IP-Instanz die Konfiguration jedoch nicht berücksichtigt, kann es sich um ein F5-Problem handeln. Bei Problemen innerhalb der BIG-IP-Instanz wenden Sie sich an den F5-Support, um die Probleme zu diagnostizieren und zu beheben.

Nächste Schritte

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