GKE on VMware-Netzwerkprobleme beheben

Version 1.28 

• Neueste Version
• Version 1.16
• Frühere Versionen (nicht unterstützt)

Auf dieser Seite wird beschrieben, wie Sie Netzwerkprobleme mit Google Distributed Cloud Virtual for VMware beheben können. Es werden allgemeine Informationen und Anleitungen zur Fehlerbehebung sowie Tools vorgeschlagen. Außerdem sind Informationen zur DNS-Fehlerbehebung und einige häufige Probleme für Calico, Seesaw und MetalLB enthalten.

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

Fehlerbehebung bei der Netzwerkverbindung

Das GKE Enterprise-Netzwerk hängt von Ihrer physischen Netzwerkinfrastruktur ab. Beispiel: Seesaw oder MetalLB verlassen sich auf Ihre Switches, die Gratuitous ARP berücksichtigen, gebündeltes Load-Balancing mit Border Gateway Protocol (BGP) basiert auf Ihren Routern und alle Knoten sollten miteinander kommunizieren können. Wenn in Ihren GKE-Clustern ein Netzwerkproblem auftritt, müssen Sie herausfinden, ob es in den GKE Enterprise-Komponenten oder in Ihrer eigenen Infrastruktur liegt.

Bestimmen 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: das Thema (von wo), das Ziel (zu dem) und die Netzwerkschicht.

Der Scope of subject kann einer der folgenden Werte sein:

• Alle Knoten (oder hostNetwork-Pods) 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 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 für Ingress (bei Istio)
• Andere Knoten aus demselben Cluster.
• Interner DNS-Name (z. B. *.svc.cluster.local).
• Externer DNS-Name (z. B. google.com).
• Entitäten außerhalb des Clusters
• Entitäten im Internet.

Die Netzwerkschicht kann eine oder mehrere der folgenden Elemente sein:

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

Wenn Sie den Umfang eines Problems verstehen, können Sie die von dem Problem betroffenen Komponenten identifizieren und ermitteln, auf welcher Ebene das Problem auftritt. Es ist wichtig, Informationen zu erfassen, wenn das Problem auftritt, da einige Probleme nur vorübergehend sind. In diesem Fall enthalten Snapshots nach der Wiederherstellung des Systems nicht genügend Informationen für eine Ursachenanalyse.

Probleme mit eingehendem Traffic

Wenn das Subjekt ein Client außerhalb des Clusters ist und keine Verbindung zu einem LoadBalancer-Dienst hergestellt werden konnte, handelt es sich um ein Nord-Süd-Verbindungsproblem. Das folgende Diagramm zeigt, dass in einem funktionierenden Beispiel der eingehende Traffic von links nach rechts durch den Stack und von rechts nach links zurück durch den Stack geleitet wird. Seesaw unterscheidet sich dadurch, dass der zurückgegebene Traffic den Load-Balancer überspringt und direkt an den Client zurückkehrt:

Wenn mit diesem Traffic-Fluss ein Problem auftritt, können Sie anhand des folgenden Flussdiagramms zur Fehlerbehebung herausfinden, wo das Problem liegt:

In diesem Flussdiagramm hilft Ihnen die folgende Anleitung zur Fehlerbehebung dabei, zu ermitteln, wo das Problem liegt:

• Verlässt das Paket den Client? Andernfalls 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? Andernfalls liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
• Verwenden Sie MetalLB? Wenn ja, kommt das Paket am LB-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 die Netzwerkadressübersetzung (Network Address Translation, NAT) korrekt ausgeführt? Andernfalls liegt wahrscheinlich ein Problem mit Kube-Proxy / Dataplane V2 vor.
• Kommt das Paket beim Worker-Knoten an? Andernfalls liegt wahrscheinlich ein Problem mit Calico / Dataplane v2 Pod-to-Pod vor.
• Kommt das Paket beim Pod an? Andernfalls 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, 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 den Router durchläuft, der in Ihrer physischen Netzwerkinfrastruktur konfiguriert ist.

1. Verwenden Sie tcpdump, um das Paket beim Verlassen des Clients an den Zieldienst zu prüfen:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Wenn du keinen Traffic siehst, ist dies die Ursache des Problems.

Kommt das Paket bei einem Seesaw-Knoten an?

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

1. Verwenden Sie tcpdump, um zu prüfen, 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.

Kommt das Paket bei einem LoadBalancer-Knoten an?

Wenn Sie MetalLB als Load-Balancer verwenden:

1. Sehen Sie im Log metallb-controller nach, 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 bei einem MetalLB-Knoten tcpdump, um den Traffic zu überprüfen:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Bei manualLB kann 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 keine NAT ausführen, bevor das Paket an Knoten weitergeleitet wird.

   Wenn kein Traffic in einen Knoten 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.

Wird der ARP korrekt gesendet?

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

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

   tcpdump -ni any arp
   

   Suchen Sie die Nachricht, die für die VIP wirbt, mit der Sie Probleme haben.

   • Für Seesaw werden kostenlose ARPs an alle VIPs gesendet. Die ARP-Nachrichten sollten für jede VIP alle 10 Sekunden angezeigt werden.

   • Für MetalLB wird kein grundloser ARP gesendet. Wie oft Sie eine Antwort erhalten, hängt davon ab, wann ein anderes Gerät, z. B. ein Top-of-Rack-Switch (ToR) 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. Verwenden Sie tcpdump, um zu prüfen, 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-Fehlerbehebungstools verwenden:

   cilium monitor --type=drop
   

Weitere Informationen finden Sie in den folgenden Abschnitten zu Problemen mit Dataplane v2 und Cilium.

Kommt 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 zugestellt.

1. Prüfen Sie mit tcpdump, ob das Paket bei der externen Schnittstelle eingeht, die normalerweise eth0 oder ens192 heißt:

   tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
   

Da normale Dienst-Back-Ends mehrere Pods auf verschiedenen Knoten enthalten, kann es schwierig sein, Fehler beim Ermitteln des fehlerhaften Knotens zu finden. Eine gängige Problemumgehung besteht darin, entweder das Problem lange genug zu erfassen, sodass ein Paket schließlich eintrifft, oder die Anzahl der Back-Ends auf ein Back-End zu beschränken.

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

• Prüfen Sie Ihre SDN-Protokolle (Software-Defined Network). Manchmal kann der SDN aus verschiedenen Gründen Pakete verwerfen, z. B. wegen 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 die externe Schnittstelle oder Tunnelschnittstelle des Knotens erreicht, 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 gesendete 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 gehalten. Verschiedene CNIs haben unterschiedliche Schemas. Bei Dataplane v2 heißt die Schnittstelle normalerweise lxcxxxx. Die Namen haben fortlaufende Schnittstellennummern, z. B. lxc17 und lxc18. Sie können mit tcpdump prüfen, ob das Paket den Pod erreicht, oder die Schnittstelle angeben:

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Wenn das Paket den Knoten erreicht, 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 enthält. Prüfen Sie die Logs des CNI-DaemonSets, um die Ursache zu ermitteln.

Probleme mit ausgehendem Traffic

Wenn Traffic in einen Pod eingehen kann, liegt möglicherweise ein Problem mit dem Traffic beim ausgehenden Pod vor. Die folgenden Diagramme zeigen, dass in einem funktionierenden Beispiel der eingehende Traffic von links nach rechts durch den Stack geleitet wird:

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

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

   Verwenden Sie tcpdump, um zu prüfen, ob die Quell-IP-Adresse richtig von der Pod-IP-Adresse in die Knoten-IP-Adresse übersetzt ist:

   tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT
   

   Wenn tcpdump anzeigt, dass Pakete korrekt maskiert sind, 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 sind, prüfen Sie die Verbindung des externen Hosts (Layer 3) mit tcpdump:

   tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp
   

   Pingen Sie gleichzeitig mit dem Befehl tcpdump von einem der Pods an:

   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

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 Virtual for VMware verwendet den direkten Routingmodus. Im folgenden Beispiel sollte pro Knoten ein Routeneintrag im Cluster angezeigt werden:

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

Zu ermitteln, auf welcher Netzwerkschicht das Verbindungsproblem auftritt, ist ein wichtiger Schritt. Eine Fehlermeldung wie „Ein Verbindungsproblem von einer Quelle zu einem Ziel“ reicht nicht aus, um das Problem zu beheben. Dies kann ein Anwendungsfehler, ein Routingproblem oder ein DNS-Problem sein. Wenn Sie wissen, auf welcher Ebene das Problem auftritt, können Sie die richtige Komponente

Oftmals geben Fehlermeldungen direkt an, auf welcher Ebene 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-Handshakefehler bedeuten, dass Layer 4 normal funktioniert.
• Die Fehlermeldung „Verbindung durch Peer zurückgesetzt“ weist darauf hin, dass es sich um ein Layer-4-Problem handelt.
  • Oft kann der Remote-Socket mit dem aktuellen Status einer Verbindung nicht einverstanden sein und sendet daher ein RESET-Paket. Dieses Verhalten könnte ein Fehler beim Verbindungstracking oder NAT sein.
• Die Fehler „Keine Route zum Host“ und „Zeitüberschreitung bei der Verbindung“ sind normalerweise ein Layer-3- oder Layer-2-Problem.
  • 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 für Verbindungsprobleme sein. Eine fehlerhafte Konfiguration Ihrer Knoten, Top-of-Rack-Switches, Spine-Router oder Firewalls kann jedoch ebenfalls zu Problemen führen. 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 Ebene 3 (IP-Ebene) und prüft die Route zwischen einer Quelle und einem Ziel. Wenn mit „ping“ ein Ziel nicht erreicht wird, liegt das Problem häufig auf Ebene 3.

Allerdings können nicht alle IP-Adressen angepingt werden. Einige Load-Balancer-VIPs können beispielsweise nicht gepingt werden, wenn es sich um einen reinen Layer-4-Load-Balancer handelt. Der Dienst ClusterIP ist ein Beispiel, bei dem 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 angeben, z. B. VIP:port.

Die BGPLB-, MetalLB- und Seesaw-Load-Balancer in Google Distributed Cloud Virtual for VMware arbeiten alle auf Ebene 3. Mit „ping“ können Sie die Konnektivität prüfen. F5 ist zwar anders, unterstützt aber auch ICMP. Mit dem Ping-Befehl können Sie die Verbindung zur F5-VIP prüfen.

Arping

Arping ist dem Ping ähnlich, mit der Ausnahme, dass es auf Layer 2 funktioniert. Ebene-2- und Ebene-3-Probleme führen oft zu ähnlichen Fehlermeldungen von Anwendungen. Mit Arping und Ping lassen sich Probleme unterscheiden. Wenn sich beispielsweise die Quelle und das Ziel im selben Subnetz befinden, das Ziel jedoch nicht arrangiert werden kann, liegt ein Layer-2-Problem vor.

Eine erfolgreiche arping <ip> gibt die MAC-Adresse des Ziels zurück. Auf Ebene 2 weist diese Adresse oft auf ein Problem mit der physischen Infrastruktur hin. Dieses Problem ist eine fehlerhafte Konfiguration eines virtuellen Schalters.

Arping kann auch IP-Adresskonflikte erkennen. Ein IP-Adresskonflikt liegt vor, wenn zwei Maschinen für die Verwendung derselben IP-Adresse in demselben Subnetz konfiguriert sind oder eine VIP von einer anderen physischen Maschine verwendet wird. IP-Adressenkonflikte können zeitweise zu Problemen führen, die sich nur schwer beheben lassen. Wenn arping <ip> mehr als einen MAC-Adresseintrag zurückgibt, weist dies auf einen IP-Adresskonflikt hin.

Nachdem Sie die MAC-Adresse vom arping erhalten haben, können Sie mit https://maclookup.app/ nach dem Hersteller der MAC-Adresse suchen. Jeder Hersteller hat ein MAC-Präfix, sodass Sie anhand dieser Informationen feststellen können, 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.:

• ip r: Routentabelle ausgeben
• ip n: gibt die benachbarte Tabelle für die Zuordnung von IP-Adresse zu MAC-Adresse aus
• ip a: alle Schnittstellen auf dem Computer ausgeben

Eine fehlende Route oder ein fehlender Eintrag in der benachbarten Tabelle kann zu Verbindungsproblemen des Knotens führen. Sowohl Anetd als auch Calico verwalten 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
  • Gibt das Protokoll für jedes Paket aus, das von anetd oder Cilium verworfen wird.
• hubble observe
  • Drucken Sie alle Pakete, die über den Ebpf-Stack von Anetd geleitet werden.
• cilium status --all-health
  • Den Status von Cilium ausgeben, einschließlich des Knoten-zu-Knoten-Verbindungsstatus. Jeder Anetd-Pod prüft den Status aller anderen Knoten im Cluster und kann dabei helfen, etwaige Verbindungsprobleme zwischen Knoten zu ermitteln.

IP-Tabellen

IP-Tabellen werden in vielen Komponenten und Subsystemen von Kubernetes 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
   

   Prüfen Sie die Löschregeln sowie die Paket- und Bytezahl, um festzustellen, ob sie im Laufe der Zeit ansteigen.

tcpdump

tcpdump ist ein leistungsstarkes Paketerfassungstool, das eine große Menge an Netzwerkverkehrsdaten generiert. Eine gängige Praxis besteht darin, „tcpdump“ sowohl von der Quelle als auch vom Ziel aus auszuführen. Wenn ein Paket beim Verlassen des Quellknotens erfasst, aber auf dem Zielknoten nie erfasst wird, bedeutet dies, dass etwas dazwischen das Paket verworfen wird. Dieses Verhalten deutet in der Regel darauf hin, dass etwas in Ihrer physischen Infrastruktur das Paket fälschlicherweise löscht.

DNS-Fehlerbehebung

Probleme bei der DNS-Auflösung fallen in zwei Hauptkategorien:

• Reguläre Pods, die die clusterinternen DNS-Server verwenden
• Host-Netzwerk-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 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 Virtual für VMware ab Version 1.9.0 an.

Jeder Cluster hat zwei oder mehr coredns-Pods und ein Autoscaling, das für die Skalierung der Anzahl der DNS-Pods im Verhältnis zur Clustergröße verantwortlich ist. Außerdem gibt es einen Dienst mit dem Namen kube-dns, der Anfragen durch Load-Balancing auf allen coredns-Back-End-Pods verteilt.

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

• Wenn sich die Anfrage an eine cluster.local-Domain richtet, ist es ein clusterinterner DNS-Name, 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 die Anfrage nicht für eine cluster.local-Domain bestimmt ist, richtet sie sich an 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 dazu, wie DNS funktioniert und in Kubernetes konfiguriert wird.

Tipps zur Fehlerbehebung bei DNS

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

• Senden Sie mit dig eine Anfrage für kubernetes.default.svc.cluster.local an den Server 192.168.0.10:

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

• Sie können auch nslookup verwenden, um denselben DNS-Lookup wie mit dem vorherigen dig-Befehl auszuführen:

  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 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, festzustellen, ob Anfragen an die coredns-Pods gesendet werden oder nicht. Ein allgemeines Problem mit der Clusterverbindung wird häufig als DNS-Probleme angezeigt, da eine DNS-Anfrage die erste Art von Traffic ist, die eine Arbeitslast sendet.

Sehen Sie sich die Fehlermeldungen Ihrer Anwendungen an. Fehler wie io timeout oder ähnliche deuten darauf hin, dass es keine Antwort gibt und ein allgemeines Problem mit der Netzwerkverbindung vorliegt.

Fehlermeldungen, die einen DNS-Fehlercode wie NXDOMAIN oder SERVFAIL enthalten, weisen auf eine Verbindung zum clusterinternen DNS-Server hin, der Server konnte den Domainnamen jedoch nicht auflösen:

• NXDOMAIN-Fehler zeigen an, dass der DNS-Server meldet, dass die Domain nicht existiert. Prüfen Sie, ob der Domainname Ihrer Anwendungsanfragen gültig ist.
• SERVFAIL- oder REFUSED-Fehler weisen darauf hin, dass der DNS-Server zwar eine Antwort zurückgesendet hat, die Domain jedoch nicht auflösen konnte, oder validieren, dass sie nicht existiert. Weitere Informationen finden Sie in den Logs der coredns-Pods.

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

kubectl -n kube-system get svc kube-dns

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

• Wenn diese Anfragen nicht funktionieren, versuchen Sie, sie an die IP-Adresse jedes coredns-Pods zu senden.
• Wenn einige Pods funktionieren, andere aber nicht, prüfen Sie, ob erkennbare Muster vorhanden sind, z. B. die DNS-Auflösung für Pods auf demselben Knoten wie der Pod coredns, aber nicht knotenübergreifend. Dies kann auf ein Problem mit der Clusterverbindung hinweisen.

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

Host-Netzwerk-Pods oder -Knoten

Hostnetzwerk-Pods 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 wird 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, testen Sie anhand der Schritte zur Fehlerbehebung in den vorherigen Abschnitten, ob das DNS für Ihre Upstream-Nameserver ordnungsgemäß funktioniert.

Häufige Netzwerkprobleme

In den folgenden Abschnitten werden einige häufig auftretende Netzwerkprobleme beschrieben. 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 Statusfehler „Nicht bereit“ in Kubernetes bedeutet in der Regel, dass ein bestimmter Peer im Cluster nicht erreichbar ist. Prüfen Sie, ob BGP-Verbindungen zwischen den beiden Peers in Ihrer Umgebung zulässig sind.

Dieser Fehler kann auch auftreten, wenn inaktive Knotenressourcen für Knoten-zu-Knoten-Mesh-Netzwerke konfiguriert sind. Außerbetriebnahme der veralteten Knoten, um dieses Problem zu beheben.

Dataplane v2 / Clium

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

Dieser Fehler bedeutet, dass das Pod-Erstellungsereignis vom Cilium-Agent aufgrund einer Ratenbegrenzung abgelehnt wurde. Cilium hat für jeden Knoten ein Limit von vier gleichzeitigen Anfragen an den PUT-Endpunkt. Dieses Verhalten ist zu erwarten, wenn viele 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 in eine sinnvollere Zahl konvergieren, wobei für leistungsstärkere Knoten höhere Ratenlimits gelten.

Häufiger Fehler: Ebpf map size is full

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

1. Verwenden Sie bpftool, um eBFP-Karteneinträ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 64k-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. Starte anetd neu, um den Status wieder in die eBFP-Karte einzufügen.

Knoten aufgrund von NetworkPluginNotReady-Fehlern ungelesen

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 sich auch in einem ungelesenen Zustand mit einem Fehler wie im folgenden Beispiel befinden:

  "Network plugin not installed"

Wenn ein Knoten initialisiert wird, wartet kubelet, bis mehrere Ereignisse eintreten, bevor der Knoten als Ready markiert wird. Eines der Ereignisse, das kubelet prüft, ist, dass das Container Network Interface (CNI)-Plug-in installiert ist. Das CNI-Plug-in sollte von anetd oder Calico 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, warum diese Pods nicht auf dem Knoten ausgeführt werden, um dieses Problem zu beheben. Normalerweise wird der Fehler nicht durch Netzwerkprobleme verursacht. Diese Pods werden im Hostnetzwerk ausgeführt, es besteht also 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 er nicht korrekt 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 möglicherweise eine Ressource wie ein Volume.
   • 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, wie in Cilium.
   • In der Datei gibt es die Konfigurationsoption custom-cni-conf. Wenn diese Einstellung als true konfiguriert ist, installiert anetd seine CNI-Binärdatei nicht.

Der F5-Dienst empfängt keinen Traffic

Wenn kein Traffic an den F5-Dienst weitergeleitet wird, gehen Sie die folgenden Schritte zur Fehlerbehebung durch:

1. Prüfen Sie, ob jede Partition in F5 BIG-IP in einem Cluster konfiguriert ist, entweder Administrator- oder Nutzercluster. Wenn eine Partition von mehreren Clustern gemeinsam genutzt wird, kommt es zu zeitweiligen Verbindungsunterbrechungen. 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 von 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. Zum 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 Abschnitt „data“ in der ConfigMap sollte die virtuelle IP-Adresse und den Port für das Frontend haben, 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 akzeptiert, könnte ein F5-Problem vorliegen. Bei Problemen innerhalb der BIG-IP-Instanz wenden Sie sich an den F5-Support, um sie zu diagnostizieren und zu beheben.

Nächste Schritte

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