Netzwerkprobleme mit Google Distributed Cloud ansprechen

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 zu einigen häufigen Problemen mit Calico, Seesaw und 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 Netzwerk-Infrastruktur. Beispielsweise nutzen Seesaw und MetalLB Ihre Switches und berücksichtigen 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:

• Clusterweit für alle Knoten (oder den hostNetwork-Pod)
• Clusterweit für alle Pods
• 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 desselben Knotens.
• 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.
• HTTP- oder HTTPS-Probleme auf Layer 7.
• 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 das Subjekt ein Client von außerhalb des Clusters ist und keine Verbindung zu einem LoadBalancer-Dienst herstellen konnte, liegt ein Problem mit der Nord-Süd-Konnektivität 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. Bei Seesaw ist das anders, da der Rücklaufverkehr den Load Balancer überspringt und direkt an den Client zurückgegeben wird:

Wenn es ein Problem mit diesem Trafficfluss gibt, können Sie anhand des folgenden Flussdiagramms zur Fehlerbehebung ermitteln, wo das Problem liegt:

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 den Seesaw-Load-Balancer? Wenn ja, erreicht das Paket den Seesaw-Knoten und wird ARP dann richtig gesendet? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
• Verwenden Sie MetalLB? Wenn ja, kommt das Paket beim LB-Knoten an 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 durchgeführt? Wenn nicht, liegt wahrscheinlich ein Problem mit kube-proxy / Dataplane V2 vor.
• Errreicht das Paket den Worker-Knoten? Wenn nicht, liegt wahrscheinlich ein Calico-/Dataplane v2-Pod-zu-Pod-Problem vor.
• Geht das Paket beim Pod ein? Wenn nicht, liegt wahrscheinlich ein Problem mit der lokalen Weiterleitung von Calico/Dataplane v2 vor.

In den folgenden Abschnitten finden Sie Schritte zur Fehlerbehebung für die verschiedenen Phasen, um festzustellen, 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. Prüfen Sie mit tcpdump das Paket, 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 Seesaw-Knoten ein?

Wenn Sie Seesaw verwenden, lesen Sie die Dokumentation zur Version 1.16, finden 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 angekommen sind:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Wenn kein Traffic eingeht, 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 über SSH eine 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 je nach Load Balancer-Typ, da MetalLB und Seesaw keine NAT ausführen, bevor das Paket an die Knoten weitergeleitet wird.

   Wenn kein Traffic zu keinem der Knoten fließt, liegt hier das Problem.

Liegt ein F5 BIG-IP-Problem vor?

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

Wird ARP korrekt gesendet?

Der Load Balancer-Knoten für MetalLB oder Seesaw nutzt ARP, um die Dienst-VIP anzukündigen. Wenn die ARP-Antwort korrekt gesendet wird, aber kein Traffic eingeht, ist das ein Hinweis auf ein Problem in Ihrer physischen Netzwerkinfrastruktur. Eine häufige Ursache für dieses Problem ist, dass einige erweiterte Lernfunktionen der Dataplane ARP-Antworten in SDN-Lösungen (Software Defined Network) ignorieren.

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

   tcpdump -ni any arp
   

   Suchen Sie nach der Nachricht, die das VIP ankündigt, mit dem es Probleme gibt.

   • Bei Seesaw werden Gratuitous-ARPs für alle VIPs gesendet. Die ARP-Nachrichten für VIPs sollten alle 10 Sekunden angezeigt werden.

   • Bei MetalLB wird kein Gratuitous ARP gesendet. Wie oft eine Antwort angezeigt wird, 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 (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 zu diesem Knoten her.

1. Prüfen Sie mit tcpdump, ob die Dienst-VIP des Dienstes korrekt ü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 Cilium-Debugging-Tools verwenden:

   cilium monitor --type=drop
   

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

Geht das Paket bei einem Worker-Knoten ein?

Die Worker-Knoten erreicht das Paket über die externe Schnittstelle und wird dann an die Pods ausgeliefert.

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
   

Da normale Dienst-Backends mehrere Pods auf verschiedenen Knoten enthalten, kann es schwierig sein, den fehlerhaften Knoten zu ermitteln. Eine gängige Lösung besteht darin, das Problem entweder so lange zu erfassen, bis ein Paket ankommt, oder die Anzahl der Backends auf eins zu beschränken.

Wenn das Paket den Arbeitsknoten nie erreicht, liegt ein Problem mit der Netzwerkinfrastruktur vor. Fragen Sie beim Team für die Netzwerkinfrastruktur nach, um zu verstehen, warum das Paket zwischen LoadBalancer-Knoten und Worker-Knoten verloren geht. Zu den häufigsten Problemen zählen folgende:

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

Wenn das Paket an der externen Schnittstelle oder Tunnelschnittstelle des Knotens ankommt, muss es an den Ziel-Pod weitergeleitet werden. Wenn es sich bei dem Pod um einen Hostnetzwerk-Pod handelt, 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 arbeiten. 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. Unterschiedliche CNIs haben unterschiedliche Schemata. Bei Dataplane V2 heißt die Schnittstelle normalerweise lxcxxxx. Die Namen haben aufeinanderfolgende Schnittstellennummern, z. B. 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 lxc-Schnittstelle weiterleitet. Wenn der Eintrag fehlt, bedeutet das normalerweise, dass der CNI-Datenpfad einen Fehler hat. Prüfen Sie die CNI-DaemonSet-Logs, um die Ursache zu ermitteln.

Probleme mit ausgehendem Traffic

Wenn Traffic in einen Pod eingehen kann, liegt möglicherweise ein Problem mit dem Traffic vor, wenn er den Pod verlässt. Die folgenden Diagramme zeigen, dass in einem Arbeitsbeispiel der eingehende Traffic von links nach rechts durch den Stack fließt:

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 ein eBPF bedingt, das über eine externe Schnittstelle geladen wird. Calico verwendet iptables-Regeln.

   Verwenden Sie tcpdump, um zu prüfen, 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 getarnt werden, der Remote-Dienst aber nicht antwortet, 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
   

   Führen Sie gleichzeitig mit der Ausführung von tcpdump einen Ping von einem der Pods aus:

   kubectl exec POD_NAME ping EXTERNAL_IP
   

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

Clusterinterne Probleme

Bei Problemen mit der Pod-zu-Pod-Verbindung versuchen Sie, 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 den Status von innerhalb des anetd-Pods:

   cilium status --all-health
   

   In Google Distributed Cloud wird der Modus für direktes Routing verwendet. Sie sollten einen Routeneintrag pro Knoten im Cluster sehen, wie im folgenden Beispiel:

   # <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 für einen Knoten eine erwartete Route 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 „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 Netzwerkschicht helfen:

• HTTP-Fehler weisen auf ein Problem in Layer 7 hin.
  • 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.
  • Oft stimmt der Remote-Socket nicht mit dem aktuellen Status einer Verbindung überein und sendet daher ein RESET-Paket. Dieses Verhalten kann auf einen Fehler beim Verbindungs-Tracking oder beim 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 richtig 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 Fehlkonfiguration Ihrer Knoten, ToR-Switches (Top of Rack), Spine-Router oder Firewalls kann jedoch ebenfalls zu Problemen führen. Mit 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.

Es können jedoch nicht alle IP-Adressen gepingt werden. Einige Load Balancer-VIPs können beispielsweise nicht gepingt 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-, MetalLB- und Seesaw-Load Balancer in Google Distributed Cloud arbeiten alle auf Layer 3. Sie können die Verbindung per „ping“ prüfen. F5 ist zwar anders, unterstützt aber auch ICMP. Sie können per Ping die Verbindung zum F5-VIP 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.

Bei einem erfolgreichen arping <ip> wird die MAC-Adresse des Ziels zurückgegeben. Auf Layer 2 deutet diese Adresse häufig auf ein Problem mit der physischen Infrastruktur hin. Dieses Problem ist auf einen falsch konfigurierten virtuellen Switch zurückzuführen.

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-Adresse von einem anderen physischen Computer verwendet wird. Konflikte mit IP-Adressen können zu zeitweiligen Problemen führen, die schwer zu beheben sind. Wenn arping <ip> mehr als einen MAC-Adresseneintrag zurückgibt, liegt ein IP-Adresskonflikt vor.

Nachdem Sie die MAC-Adresse von Arping erhalten haben, können Sie unter https://maclookup.app/ den zur MAC-Adresse gehörenden Hersteller ermitteln. Jeder Hersteller hat ein MAC-Präfix. Anhand dieser Informationen können Sie ermitteln, welches Gerät versucht, dieselbe IP-Adresse zu verwenden. Beispielsweise ist VMware Inhaber des 00:50:56-Blocks. Eine MAC-Adresse 00:50:56:xx:yy:zz ist also eine VM in Ihrer vSphere-Umgebung.

iproute2

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

• ip r: die Routentabelle ausdrucken
• ip n: Die Nachbartabelle für die Zuordnung von IP-Adressen zu MAC-Adressen ausdrucken
• ip a: alle Schnittstellen des Geräts ausdrucken

Eine fehlende Route oder ein fehlender Eintrag in der Nachbartabelle kann zu Verbindungsproblemen vom Knoten aus führen. Sowohl Anetd als auch Calico verwalten 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 bietet mehrere nützliche Tools zum Beheben von Verbindungsproblemen:

• cilium monitor --type=drop
  • Das Protokoll für alle Pakete ausdrucken, die von anetd/Cilium verworfen werden.
• hubble observe
  • Alle Pakete ausdrucken, die den eBPF-Stack von anetd durchlaufen.
• cilium status --all-health
  • Den Status von Cilium ausdrucken, einschließlich des Status der Knoten-zu-Knoten-Verbindung. Jeder einzelne 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, um die Dienstauflösung zu implementieren. Calico verwendet iptables, um Netzwerkrichtlinien zu implementieren

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 Netzwerkverkehrsdaten generiert. Häufig wird tcpdump sowohl an der Quelle als auch am Ziel ausgeführt. Wenn ein Paket beim Verlassen des Quellknotens erfasst wird, aber nie am Zielknoten erfasst wird, bedeutet das, dass das Paket irgendwo dazwischen verworfen wurde. Dieses Verhalten weist in der Regel darauf hin, dass ein Gerät in Ihrer physischen Infrastruktur das Paket fälschlicherweise verwirft.

DNS-Fehlerbehebung

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

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

In den folgenden Abschnitten finden Sie einige Informationen zur Cluster-DNS-Architektur und hilfreiche Tipps, bevor Sie mit der Fehlerbehebung in einer 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-Versionen ab 1.9.0 an.

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

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

• Wenn die Anfrage für eine cluster.local-Domain erfolgt, liegt ein clusterinterner DNS-Name vor, 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 erfolgt, handelt es sich um eine externe Domain.
  • 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 zur Funktionsweise und Konfiguration von DNS in Kubernetes.

Tipps zur DNS-Fehlerbehebung

Zur Fehlerbehebung bei 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 korrekt funktioniert. In den folgenden Beispielen wird gezeigt, 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 wie mit dem vorherigen dig-Befehl ausführen:

  nslookup kubernetes.default.svc.cluster.local 192.168.0.10
  

  Sehen Sie sich die Ausgabe eines 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. Häufig treten allgemeine Clusterverbindungsprobleme als DNS-Probleme auf, da eine DNS-Anfrage die erste Art von Traffic ist, die von einer Arbeitslast gesendet wird.

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

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

• NXDOMAIN-Fehler weisen darauf hin, dass der DNS-Server die Nicht-Existenz der Domain meldet. 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 folgendem 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, wobei Sie dig oder nslookup verwenden, 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 clusterinternes Verbindungsproblem hinweisen.

Wenn CoreDNS unfähig ist, externe Domainnamen aufzulösen, lesen Sie den folgenden Abschnitt zur Fehlerbehebung bei Hostnetzwerk-Pods. CoreDNS verhält sich wie ein Hostnetzwerk-Pod und nutzt die Upstream-DNS-Server des Knotens für die Namensauflösung.

Pods oder Knoten des Hostnetzwerks

Die Pods des Hostnetzwerks und die Knoten verwenden die auf dem Knoten konfigurierten Nameserver für die DNS-Auflösung, nicht den clusterinternen DNS-Dienst. Je nach Betriebssystem ist dieser Nameserver entweder in /etc/resolv.conf oder /run/systemd/resolve/resolv.conf konfiguriert. Aufgrund dieser Konfiguration können cluster.local-Domainnamen nicht aufgelöst werden.

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 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äufiger Fehler: calico/node is not ready: BIRD is not ready: BGP not established

Dieser „unready“-Statusfehler in Kubernetes bedeutet in der Regel, dass ein bestimmter Peer im Cluster nicht erreichbar ist. Prüfen Sie, ob die BGP-Konnektivität zwischen den beiden Peers in Ihrer Umgebung erlaubt ist.

Dieser Fehler kann auch auftreten, wenn inaktive Knotenressourcen für ein Knoten-zu-Knoten-Mesh konfiguriert sind. Um dieses Problem zu beheben, nehmen Sie die veralteten Knoten außer Betrieb.

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. Cilium verwendet ein Limit von maximal vier gleichzeitigen Anfragen an den PUT-Endpunkt pro Knoten. 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 Netzwerkrichtlinien. Wenn eine Zuordnung voll ist, kann der Agent keine weiteren Einträge einfügen. Dies führt zu Abweichungen zwischen Steuerungs- und Datenebene. 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 mehrere Ereignisse ab, bevor der Knoten als Ready gekennzeichnet wird. Unter anderem prüft kubelet, ob das CNI-Plug-in (Container Network Interface) installiert ist. Das CNI-Plug-in sollte von anetd oder Calico über einen Init-Container installiert worden sein, wobei sowohl die CNI-Binärdatei als auch die CNI-Konfiguration in den erforderlichen Hostverzeichnissen installiert wurden.

Prüfen Sie zur Fehlerbehebung, warum diese Pods nicht auf dem Knoten ausgeführt werden. In der Regel ist dieser Fehler nicht auf Netzwerkprobleme zurückzuführen. Diese Pods werden im Hostnetzwerk ausgeführt, sodass keine Netzwerkabhängigkeit besteht.

1. Prüfen Sie den Status des Pods anetd oder calico-node. 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 Protokollen, warum er nicht richtig ausgeführt werden kann.
   • Wenn sich der Pod im Status Pending befindet, verwenden Sie kubectl describe und prüfen Sie die Pod-Ereignisse. Dem Pod fehlt beispielsweise möglicherweise eine Ressource, z. B. ein Volume.
   • Wenn der Pod den Status Running hat, prüfen Sie die Protokolle und die Konfiguration. Einige CNI-Implementierungen bieten Optionen zum Deaktivieren der CNI-Installation, z. B. Cilium.
   • In anetd gibt es eine Konfigurationsoption namens custom-cni-conf. Ist diese Einstellung auf true konfiguriert, installiert anetd die CNI-Binärdatei nicht.

Knoten NICHT VERFÜGBAR aufgrund veralteter ARP-Einträge

Manchmal können veraltete ARP-Einträge in Knoten der Steuerungsebene des Administratorclusters zu Abweichungen 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 Verbindungstimeouts können dazu führen, dass der Knoten mit veralteten ARP-Einträgen als NOT READY markiert wird. Knoten, die als NOT READY gekennzeichnet sind, können Clusterinstallationen und ‑upgrades verzögern.

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

So prüfen und beheben Sie das Problem:

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. Stellen Sie eine SSH-Verbindung zu einem Knoten der Steuerungsebene des Administratorclusters her.

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 unterschiedliche MAC-Adressen zurückgeben, sind Sie von diesem Problem betroffen.

5. Um das Problem zu beheben, leeren Sie den ARP-Cache auf dem Knoten der Steuerungsebene des Administratorclusters:

   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 einzelne Partition in F5 BIG-IP in einem Cluster konfiguriert ist – entweder in einem Administrator- oder einem Nutzercluster. 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 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.