Auf dieser Seite erfahren Sie, wie Sie Netzwerkprobleme mit Google Distributed Cloud beheben. Es werden allgemeine Informationen und Anleitungen zur Fehlerbehebung sowie empfohlene Tools bereitgestellt. Außerdem finden Sie Informationen zur DNS-Fehlerbehebung und einige häufige Probleme mit MetalLB.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Fehlerbehebung bei Netzwerkverbindungen
Das GKE Enterprise-Netzwerk basiert auf Ihrer physischen Netzwerkinfrastruktur. Beispielsweise nutzt MetalLB Ihre Switches und berücksichtigt Gratuitous ARP, gebündeltes Load-Balancing mit Border Gateway Protocol (BGP) nutzt Ihre Router und alle Knoten sollten in der Lage sein, miteinander zu kommunizieren. Wenn Sie ein Netzwerkproblem in Ihren GKE-Clustern haben, müssen Sie feststellen, ob das Problem bei den GKE Enterprise-Komponenten oder in Ihrer eigenen Infrastruktur liegt.
Ermitteln Sie zuerst den Umfang des Problems und versuchen Sie dann, die betroffenen Komponenten zu identifizieren. Der Umfang eines Problems kann in eine von drei Kategorien eingeteilt werden: Subjekt (von wo aus) das Ziel (an welche) und Netzwerkebene “
Der Umfang des Subjekts kann eines der folgenden Dinge sein:
- Alle Knoten (oder hostNetwork-Pod) clusterweit.
- Alle Pods clusterweit.
- Alle Pods auf einem einzelnen Knoten oder einer Gruppe von Knoten.
- Alle Pods aus demselben Deployment oder DaemonSet.
- Client von außerhalb des Clusters.
Der Zielbereich kann einer oder mehrere der folgenden Dinge sein:
- Alle anderen Pod-IP-Adressen aus demselben Cluster
- Alle anderen Pod-IP-Adressen von demselben Knoten.
- ClusterIP-Dienst-VIP aus demselben Cluster.
- LoadBalancer-Dienst-VIP aus demselben Cluster.
- Ingress-Layer-7-LoadBalancer (Istio).
- Andere Knoten aus demselben Cluster
- Interner DNS-Name (z. B.
*.svc.cluster.local
) - Externer DNS-Name (z. B.
google.com
). - Entitäten von außerhalb des Clusters
- Entitäten im Internet
Die Netzwerkebene kann eines oder mehrere der folgenden Dinge sein:
- Probleme mit Layer-2-Link-Ebenen wie Nachbarsystem, ARP oder NDP.
- Probleme mit dem IP‑Adress-Routing von Layer 3.
- Probleme mit TCP- oder UDP-Endpunkten von Layer 4.
- Layer-7-HTTP- oder -HTTPS-Probleme.
- Probleme mit der DNS-Auflösung
Wenn Sie den Umfang eines Problems verstehen, können Sie die Komponenten identifizieren, die mit dem Problem zusammenhängen und in welchem Schicht das Problem auftritt. Es ist wichtig, Informationen zu erfassen, wenn das Problem auftritt, da einige Probleme vorübergehend sind. Snapshots nach der Systemwiederherstellung enthalten nicht genügend Informationen für die Analyse der Grundursache.
Probleme mit dem eingehenden Traffic
Wenn es sich bei dem Subjekt um einen Client von außerhalb des Clusters handelt und keine Verbindung zu einem LoadBalancer-Dienst hergestellt werden konnte, liegt ein Nord-Süd-Verbindungsproblem vor. Das folgende Diagramm zeigt, dass in einem Arbeitsbeispiel der eingehende Traffic von links nach rechts durch den Stack fließt und der Rücklauftraffic von rechts nach links durch den Stack zurückfließt.
Wenn bei diesem Traffic-Fluss ein Problem auftritt, verwenden Sie das folgende Flussdiagramm zur Fehlerbehebung, um zu 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 MetalLB? Wenn ja, erreicht das Paket den LB-Knoten und wird ARP dann richtig gesendet? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
- Verwenden Sie F5 BIG-IP? Falls ja, haben Sie nach F5-Problemen gesucht?
- Wird die Network Address Translation (NAT) korrekt ausgeführt? Wenn nicht, liegt wahrscheinlich ein Problem mit kube-proxy / Dataplane V2 vor.
- Errreicht das Paket den Worker-Knoten? Wenn nicht, liegt wahrscheinlich ein Dataplane v2-Pod-zu-Pod-Problem vor.
- Erreicht das Paket den Pod? Wenn nicht, liegt wahrscheinlich ein lokales Weiterleitungsproblem mit Dataplane v2 vor.
In den folgenden Abschnitten finden Sie Schritte zur Fehlerbehebung für jede Phase, um festzustellen, ob der Traffic korrekt fließt.
Verlässt das Paket den Client?
Prüfen Sie, ob das Paket den Client ordnungsgemäß verlässt und durch den in Ihrer physischen Netzwerkinfrastruktur konfigurierten Router geleitet wird.
Verwenden Sie
tcpdump
, um das Paket zu prüfen, wenn es den Client verlässt und zum Zieldienst weitergeleitet wird:tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
Wenn kein Traffic hinausgeht, liegt hier das Problem.
Geht das Paket bei einem LoadBalancer-Knoten ein?
Wenn Sie MetalLB als Load-Balancer verwenden:
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
Stellen Sie eine SSH-Verbindung zum Knoten her.
Prüfen Sie für einen MetalLB-Knoten mit
tcpdump
den Traffic:tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
Bei der manuellen Load Balancing-Methode kann der Traffic auf einem beliebigen Knoten landen. Je nach Load Balancer-Konfiguration können Sie einen oder mehrere Knoten auswählen. Mit
tcpdump
können Sie den Traffic überprüfen:tcpdump -ni any host NODE_IP and port NODE_PORT
Der Befehl unterscheidet sich zwischen den Load-Balancer-Typen, da MetalLB keine NAT ausführt, bevor das Paket an Knoten weitergeleitet wird.
Wenn Sie keinen Traffic zu einem Knoten sehen, liegt hier das Problem.
Gibt es ein Problem mit F5 BIG-IP?
Informationen zur Fehlerbehebung bei F5 BIG-IP-Problemen finden Sie in den folgenden Abschnitten unter Der F5-Dienst empfängt keinen Traffic.
Wird ARP korrekt gesendet?
Der Load Balancer-Knoten für MetalLB nutzt ARP, um die VIP des Dienstes anzukündigen. Wenn die ARP-Antwort korrekt gesendet wird, aber kein Traffic eingeht, ist dies ein Hinweis auf ein Problem mit der physischen Netzwerkinfrastruktur. Eine häufige Ursache für dieses Problem ist, dass einige erweiterte Lernfeatures der Datenebene die ARP-Antwort in SDN-Lösungen (softwarebasierten Netzwerk) ignorieren.
Mit
tcpdump
können Sie ARP-Antworten erkennen:tcpdump -ni any arp
Suchen Sie nach der Nachricht, die die VIP bewirbt, bei der Sie Probleme haben.
Bei MetalLB wird kein Gratuitous ARP gesendet. Wie oft Sie eine Antwort erhalten, hängt davon ab, wann ein anderes Gerät wie ein ToR-Switch (Top of Rack) eine ARP-Anfrage sendet.
Wird NAT ausgeführt?
Dataplane v2/kube-proxy führt eine Zielnetzwerkadressübersetzung (Destination Network Address Translation, DNAT) durch, um die Ziel-VIP in eine Backend-Pod-IP-Adresse umzuwandeln. Wenn Sie wissen, welcher Knoten das Backend für den Load Balancer ist, stellen Sie über SSH eine Verbindung zum Knoten her.
Prüfen Sie mit
tcpdump
, ob die Dienst-VIP richtig übersetzt ist:tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
Bei Dataplane V2 können Sie zusätzlich eine Verbindung zu den
anetd
-Pods herstellen und die eingebetteten Cilium-Debugging-Tools verwenden:cilium monitor --type=drop
Weitere Informationen finden Sie in den folgenden Abschnitten zu Problemen mit Dataplane V2/Cilium.
Erreicht das Paket einen Worker-Knoten?
Auf den Worker-Knoten kommt das Paket an der externen Schnittstelle an und wird dann an die Pods weitergeleitet.
Prüfen Sie mit
tcpdump
, ob das Paket an der externen Schnittstelle ankommt, die in der Regeleth0
oderens192
heißt:tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
cilium_geneve
.
Da normale Service-Back-Ends mehrere Pods auf verschiedenen Knoten enthalten, kann es schwierig sein, zu ermitteln, welcher Knoten fehlerhaft ist. Eine gängige Problemumgehung besteht darin, das Problem entweder so lange zu erfassen, dass ein Paket ankommt, oder die Anzahl der Back-Ends auf eins zu beschränken.
Wenn das Paket nie den Arbeitsknoten erreicht, weist dies auf ein Problem mit der Netzwerkinfrastruktur hin. Erkundigen Sie sich beim Team für die Netzwerkinfrastruktur, warum das Paket zwischen LoadBalancer-Knoten und Worker-Knoten verworfen wird. Zu den häufigsten Problemen gehören:
- Prüfen Sie die Logs Ihres softwaredefinierten Netzwerks (Software-defined Network, SDN). Manchmal kann das SDN Pakete aus verschiedenen Gründen ablehnen, z. B. aufgrund von Segmentierung, falscher Prüfsumme oder Anti-Spoofing.
- Firewallregeln, die Geneve-Pakete an UDP-Port 6081 filtern.
Wenn das Paket an der externen Schnittstelle oder Tunnelschnittstelle des Knotens ankommt, muss es an den Ziel-Pod weitergeleitet werden. Wenn der Pod ein Pod im Hostnetzwerk ist, ist dieser Schritt nicht erforderlich, da der Pod den Netzwerk-Namespace mit dem Knoten teilt. Andernfalls ist eine zusätzliche Paketweiterleitung erforderlich.
Jeder Pod hat virtuelle Ethernet-Schnittstellenpaare, die wie Pipes funktionieren. Ein Paket, das an ein Ende der Schnittstelle gesendet wird, wird vom anderen Ende der Schnittstelle empfangen. Eine der Schnittstellen wird in den Netzwerk-Namespace des Pods verschoben und in eth0
umbenannt. Die andere Schnittstelle bleibt im Host-Namespace. Verschiedene CNIs haben unterschiedliche Schemas. Bei Dataplane v2 heißt die Schnittstelle normalerweise lxcxxxx
. Die Namen haben aufeinanderfolgende Schnittstellennummern, wie lxc17
und lxc18
. Sie können mit tcpdump
prüfen, ob das Paket am Pod ankommt. Sie können auch die Schnittstelle angeben:
tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT
Wenn das Paket den Knoten erreicht, aber nicht den Pod, prüfen Sie die Routingtabelle so:
ip route
Normalerweise sollte jeder Pod einen Routingeintrag haben, der die Pod-IP-Adresse an die Schnittstelle lxc
weiterleitet. Wenn der Eintrag fehlt, bedeutet dies in der Regel, dass der CNI-Datenpfad einen Fehler aufweist. Prüfen Sie die CNI DaemonSet-Logs, um die Ursache zu ermitteln.
Probleme mit ausgehendem Traffic
Wenn Traffic bei einem Pod eingehen kann, besteht möglicherweise ein Problem mit dem Traffic, der aus dem Pod ausgeht. Die folgenden Diagramme zeigen, dass in einem Arbeitsbeispiel der eintreffende Traffic von links nach rechts durch den Stack fließt:
Prüfen Sie den externen Dienst (Layer 4), um zu prüfen, ob das ausgehende Paket korrekt als Knoten-IP-Adresse maskiert wird.
Die Quell-IP-Adresse des Pakets sollte von der Pod-IP-Adresse mit Quellnetzwerkadressübersetzung (SNAT) der Knoten-IP-Adresse zugeordnet werden. In Dataplane v2 wird dieser Vorgang durch ebpf erreicht, das auf einer externen Schnittstelle geladen wird.
Prüfen Sie mit
tcpdump
, ob die Quell-IP-Adresse korrekt von der Pod-IP-Adresse in die Knoten-IP-Adresse übersetzt wurde:tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT
Wenn
tcpdump
anzeigt, dass Pakete korrekt maskiert sind, der Remotedienst jedoch nicht reagiert, prüfen Sie die Verbindung zum externen Dienst in Ihrer Infrastruktur.Wenn die ausgehenden Pakete korrekt als Knoten-IP-Adresse maskiert werden, prüfen Sie die Verbindung zum externen Host (Layer 3) mit
tcpdump
:tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp
Senden Sie gleichzeitig mit der Ausführung von
tcpdump
einen Ping-Befehl von einem der Pods:kubectl exec POD_NAME ping EXTERNAL_IP
Wenn Sie keine Ping-Antworten sehen, prüfen Sie die Verbindung zum externen Dienst in Ihrer Infrastruktur.
Probleme im Cluster
Bei Problemen mit der Pod-zu-Pod-Verbindung sollten Sie versuchen, das Problem auf Knoten einzugrenzen. Oft kann eine Gruppe von Knoten nicht mit einer anderen Gruppe von Knoten kommunizieren.
Prüfen Sie in Dataplane V2 die Knotenverbindung vom aktuellen Knoten zu allen anderen Knoten im selben Cluster. Prüfen Sie im Pod
anetd
den Systemstatus:cilium status --all-health
Probleme mit der Netzwerkebene
Identifizieren, in welcher Netzwerkebene das Verbindungsproblem auftritt, ist ein wichtiger Schritt. Eine Fehlermeldung wie „Ein Verbindungsproblem von einer Quelle zu einem Ziel“ ist nicht aussagekräftig genug, um das Problem zu beheben. Es könnte sich um einen Anwendungsfehler, ein Routingproblem oder ein DNS-Problem handeln. Wenn Sie wissen, auf welcher Ebene das Problem auftritt, können Sie leichter die richtige Komponente korrigieren.
Oft geben Fehlermeldungen direkt an, auf welcher Ebene das Problem auftritt. Die folgenden Beispiele können Ihnen bei der Fehlerbehebung bei Fragen zur Netzwerkebene helfen:
- HTTP-Fehler weisen darauf hin, dass es sich um ein Layer-7-Problem handelt.
- HTTP-Codes
40x
,50x
oder TLS-Handshake-Fehler bedeuten, dass in Layer 4 alles normal funktioniert.
- HTTP-Codes
- Fehler vom Typ Verbindung wurde von einem anderen Computer zurückgesetzt weisen auf ein Problem in Layer 4 hin.
- Häufig kann der Remote-Socket nicht mit dem aktuellen Status einer Verbindung übereinstimmen und sendet daher ein
RESET
-Paket. Dieses Verhalten kann auf einen Fehler beim Verbindungs-Tracking oder bei NAT zurückzuführen sein.
- Häufig kann der Remote-Socket nicht mit dem aktuellen Status einer Verbindung übereinstimmen und sendet daher ein
- Die Fehler Keine Route zum Host und "Zeitüberschreitung der Verbindung" sind normalerweise ein Layer-3- oder Layer-2-Problem.
- Diese Fehler weisen darauf hin, dass das Paket nicht ordnungsgemäß an das Ziel weitergeleitet werden kann.
Nützliche Tools zur Fehlerbehebung
Netzwerkbezogene DaemonSets werden auf Ihren Knoten ausgeführt und können die Ursache für Verbindungsprobleme sein. Eine fehlerhafte Konfiguration der Knoten, ToR-Switches (Top-of-Rack), Spine-Router oder Firewalls kann jedoch ebenfalls Probleme verursachen. Mit den folgenden Tools können Sie den Umfang oder die Ebene des Problems ermitteln und feststellen, ob es sich um ein Problem mit Ihren GKE Enterprise-Knoten oder Ihrer physischen Infrastruktur handelt.
Ping
Ping arbeitet auf Layer 3 (IP-Ebene) und prüft die Route zwischen einer Quelle und einem Ziel. Wenn der Ping ein Ziel nicht erreicht, liegt das Problem häufig auf Layer 3.
Allerdings können nicht alle IP-Adressen angepingt werden. Einige Load-Balancer-VIPs können beispielsweise nicht angepingt werden, wenn es sich um einen reinen Layer-4-Load-Balancer handelt. Der ClusterIP
-Dienst ist ein Beispiel dafür, dass die VIP möglicherweise keine Ping-Antwort zurückgibt. Auf Layer 4 gibt dieser Dienst nur dann eine Ping-Antwort zurück, wenn Sie eine Portnummer angeben, z. B. VIP:port
.
Die BGPLB- und MetalLB-Load-Balancer in Google Distributed Cloud arbeiten alle auf Layer 3. Sie können die Verbindung mit Ping prüfen. F5 ist anders, unterstützt aber auch ICMP. Sie können die Verbindung zur F5-VIP mit einem Ping-Befehl prüfen.
Arping
Arping ähnelt dem Ping, funktioniert aber auf Layer 2. Probleme mit Layer 2 und 3 haben häufig ähnliche Fehlermeldungen von Anwendungen. Mithilfe von Arping und Ping können Sie das Problem unterscheiden. Wenn sich Quelle und Ziel beispielsweise im selben Subnetz befinden, Sie aber kein Arping für das Ziel ausführen können, liegt ein Problem auf Layer 2 vor.
Ein erfolgreicher arping <ip>
gibt die MAC-Adresse des Ziels zurück. Auf Layer 2 deutet diese Adresse häufig auf ein Problem mit der physischen Infrastruktur hin.
Dieses Problem ist häufig ein physischer Wechsel zwischen Knoten.
Arping kann auch IP-Adresskonflikte erkennen. Ein IP-Adresskonflikt tritt auf, wenn zwei Maschinen so konfiguriert sind, dass sie dieselbe IP-Adresse im selben Subnetz verwenden, oder wenn eine VIP von einer anderen physischen Maschine verwendet wird. IP-Adresskonflikte können zu zeitweiligen Problemen führen, die schwer zu beheben sind. Wenn arping <ip>
mehr als einen MAC-Adresseintrag zurückgibt, ist dies ein Hinweis darauf, dass ein IP-Adresskonflikt vorliegt.
Nachdem Sie die MAC-Adresse von Arping abgerufen haben, können Sie über https://maclookup.app/ den Hersteller der MAC-Adresse ermitteln. Jeder Hersteller hat ein MAC-Präfix. Anhand dieser Informationen können Sie feststellen, welches Gerät dieselbe IP-Adresse verwenden möchte. Beispiel: VMware besitzt den Block 00:50:56
, sodass eine MAC-Adresse 00:50:56:xx:yy:zz
eine VM in Ihrer vSphere-Umgebung ist.
iproute2
Die ip
-Befehlszeile für iproute2
bietet viele nützliche Unterbefehle, z. B.:
ip r
: Routentabelle druckenip n
: die Nachbartabelle für die Zuordnung von IP-Adressen zu MAC-Adressen ausdruckenip a
: Alle Schnittstellen auf dem Computer drucken
Eine fehlende Route oder ein fehlender Eintrag in der Nachbartabelle kann zu Verbindungsproblemen mit dem Knoten führen. Anetd verwaltet die Routingtabelle und die Nachbartabelle. Eine Fehlkonfiguration in diesen Tabellen kann zu Verbindungsproblemen führen.
Cilium-/Hubble-Befehlszeile für Dataplane v2
Jeder anetd
-Pod hat mehrere nützliche Debugging-Tools für Verbindungsprobleme:
cilium monitor --type=drop
- Das Log für jedes Paket ausgeben, das von anetd / Cilium verworfen wurde.
hubble observe
- Alle Pakete drucken, die durch den ebpf-Stack von anetd gehen
cilium status --all-health
- Den Status von Cilium drucken, einschließlich des Status der Knoten-zu-Knoten-Konnektivität. Jeder anetd-Pod prüft den Zustand aller anderen Knoten im Cluster und kann helfen, Probleme mit der Knoten-zu-Knoten-Verbindung zu ermitteln.
Iptables
Iptables wird in vielen Kubernetes-Komponenten und ‑Subsystemen verwendet. kube-proxy
verwendet iptables zur Implementierung der Dienstauflösung.
Verwenden Sie den folgenden Befehl, um Netzwerkprobleme auf iptables-Ebene zu beheben:
iptables -L -v | grep DROP
Prüfen Sie die Regeln für das Verwerfen und die Anzahl der Pakete und Bytes, um festzustellen, ob sie im Laufe der Zeit zunehmen.
Tcpdump
Tcpdump ist ein leistungsstarkes Tool zur Paketerfassung, das viele Netzwerktrafficdaten generiert. Häufig wird tcpdump sowohl an der Quelle als auch am Ziel ausgeführt. Wenn ein Paket erfasst wird, wenn es den Quellknoten verlässt, aber nie am Zielknoten erfasst wird, bedeutet das, dass das Paket irgendwo dazwischen verworfen wird. Dieses Verhalten deutet normalerweise darauf hin, dass etwas in Ihrer physischen Infrastruktur das Paket versehentlich verwirft.
DNS-Fehlerbehebung
Probleme bei der DNS-Auflösung lassen sich in zwei Hauptkategorien unterteilen:
- Reguläre Pods, die die clusterinternen DNS-Server verwenden.
- Hostnetzwerk-Pods oder -Knoten, die keine DNS-Server im Cluster verwenden
Die folgenden Abschnitte enthalten einige Informationen zur Cluster-DNS-Architektur sowie hilfreiche Tipps, bevor Sie mit der Fehlerbehebung für eine dieser Kategorien beginnen.
Cluster-DNS-Architektur
Ein Cluster-DNS-Dienst löst DNS-Anfragen für Pods im Cluster auf. CoreDNS bietet diesen Dienst für alle Versionen der Google Distributed Cloud.
Jeder Cluster hat zwei oder mehr coredns
-Pods und einen Autoscaler, der für die Skalierung der Anzahl der DNS-Pods im Verhältnis zur Clustergröße verantwortlich ist.
Es gibt auch einen Dienst namens kube-dns
, der Anfragen zwischen allen Back-End-coredns
-Pods verteilt.
Bei den meisten Pods ist das vorgelagerte DNS auf die IP-Adresse des kube-dns
-Dienstes konfiguriert und Pods senden DNS-Anfragen an einen der coredns
-Pods. DNS-Anfragen können in eines der folgenden Ziele gruppiert werden:
- Wenn die Anfrage für eine
cluster.local
-Domain erfolgt, handelt es sich um einen clusterinternen DNS-Namen, der auf einen Dienst oder Pod im Cluster verweist.- CoreDNS überwacht die
api-server
für alle Dienste und Pods im Cluster und antwortet auf Anfragen für gültigecluster.local
-Domains.
- CoreDNS überwacht die
- Wenn die Anfrage nicht für eine
cluster.local
-Domain, sondern für eine externe Domain erfolgt,- CoreDNS leitet die Anfrage an die Upstream-Nameserver weiter. Standardmäßig verwendet CoreDNS die vorgelagerten Nameserver, die auf dem Knoten konfiguriert sind, auf dem es ausgeführt wird.
Weitere Informationen finden Sie in der Übersicht über die Funktionsweise und Konfiguration von DNS in Kubernetes.
Tipps zur Fehlerbehebung bei DNS
Zur Behebung von DNS-Problemen können Sie die Tools dig
und nslookup
verwenden. Mit diesen Tools können Sie DNS-Anfragen senden, um zu testen, ob die DNS-Auflösung richtig funktioniert. Die folgenden Beispiele zeigen, wie Sie mit dig
und nslookup
nach Problemen mit der DNS-Auflösung suchen.
Verwenden Sie
dig
odernslookup
, um eine Anfrage fürgoogle.com
zu senden:dig google.com nslookup google.com
Verwenden Sie
dig
, um eine Anfrage fürkubernetes.default.svc.cluster.local
an den Server192.168.0.10
zu senden:dig @192.168.0.10 kubernetes.default.svc.cluster.local
Mit
nslookup
können Sie dieselbe DNS-Suche ausführen wie mit dem vorherigendig
-Befehl:nslookup kubernetes.default.svc.cluster.local 192.168.0.10
Sehen Sie sich die Ausgabe der Befehle „dig“ oder „nslookup“ an. Wenn Sie eine falsche Antwort oder keine Antwort erhalten, liegt ein Problem mit der DNS-Auflösung vor.
Reguläre Pods
Der erste Schritt zur Behebung eines DNS-Problems besteht darin, zu bestimmen, ob Anfragen an die coredns
-Pods gesendet werden oder nicht. Oft wird ein allgemeines Clusterverbindungsproblem als DNS-Probleme angezeigt, da eine DNS-Anfrage der erste Traffictyp ist, den eine Arbeitslast sendet.
Prüfen Sie die Fehlermeldungen Ihrer Anwendungen. Fehler wie io timeout
oder ähnliche weisen darauf hin, dass keine Antwort vorliegt und es ein allgemeines Netzwerkverbindungsproblem gibt.
Fehlermeldungen, die einen DNS-Fehlercode wie NXDOMAIN
oder SERVFAIL
enthalten, geben an, dass eine Verbindung zum clusterinternen DNS-Server besteht, der Server konnte den Domainnamen jedoch nicht auflösen:
NXDOMAIN
-Fehler weisen darauf hin, dass der DNS-Server meldet, dass die Domain nicht existiert. Prüfen Sie, ob der von Ihrer Anwendung angeforderte Domainname gültig ist.SERVFAIL
- oderREFUSED
-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 dercoredns
-Pods.
Sie können die IP-Adresse des kube-dns
-Dienstes mit dem folgenden Befehl ermitteln:
kubectl -n kube-system get svc kube-dns
Versuchen Sie von einem Pod, in dem DNS nicht funktioniert, eine DNS-Anfrage an diese IP-Adresse zu senden. Verwenden Sie dazu dig
oder nslookup
, wie in einem vorherigen Abschnitt beschrieben:
- Wenn diese Anfragen nicht funktionieren, versuchen Sie, Anfragen an die IP-Adresse jedes
coredns
-Pods zu senden. - Wenn einige Pods funktionieren, andere aber nicht, prüfen Sie, ob es erkennbare Muster gibt, z. B. ob die DNS-Auflösung für Pods auf demselben Knoten wie dem des
coredns
-Pods funktioniert, aber nicht für alle Knoten. Dieses Verhalten kann auf ein Verbindungsproblem innerhalb des Clusters hinweisen.
Wenn CoreDNS keine externen Domainnamen auflösen kann, lesen Sie den folgenden Abschnitt zur Fehlerbehebung bei Hostnetzwerk-Pods. CoreDNS verhält sich wie ein Hostnetzwerk-Pod und verwendet die Upstream-DNS-Server des Knotens für die Namensauflösung.
Pods oder Knoten des Hostnetzwerks
Pods im Hostnetzwerk und die Knoten verwenden die auf dem Knoten konfigurierten Nameserver für die DNS-Auflösung, nicht den DNS-Dienst im Cluster. Je nach Betriebssystem ist dieser Nameserver entweder in /etc/resolv.conf
oder /run/systemd/resolve/resolv.conf
konfiguriert. Diese Konfiguration bedeutet, dass sie keine cluster.local
-Domainnamen auflösen können.
Wenn Probleme mit der Namensauflösung des Hosts auftreten, können Sie mit den Schritten zur Fehlerbehebung in den vorherigen Abschnitten prüfen, ob das DNS für Ihre Upstream-Nameserver richtig funktioniert.
Prüfen Sie, ob für alle Knoten dieselben Server konfiguriert sind. Wenn Sie verschiedene Nameserver konfiguriert haben, kann es zu Inkonsistenzen bei der DNS-Auflösung auf verschiedenen Knoten kommen. Prüfen Sie, ob jeder Nameserver einzeln funktioniert, indem Sie mitdig
oder nslookup
eine Anfrage an jeden senden. Wenn einige Nameserver funktionieren, andere aber nicht, treten diese Fehler wegen inkonsistenter DNS-Auflösung auf.
Häufige Netzwerkprobleme
In den folgenden Abschnitten werden einige häufige Netzwerkprobleme beschrieben, die auftreten können. Folgen Sie der entsprechenden Anleitung zur Fehlerbehebung, um das Problem zu beheben. Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.
Dataplane V2/Cilium
Häufiger Fehler: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests
Dieser Fehler bedeutet, dass das Pod-Erstellungsereignis vom Cilium-Agenten aufgrund einer Ratenbeschränkung abgelehnt wurde. Für jeden Knoten hat Cilium ein Limit von vier gleichzeitigen Anfragen an den PUT-Endpunkt. Wenn plötzlich viele Anfragen bei einem Knoten eingehen, ist dieses Verhalten zu erwarten. Der Cilium-Agent sollte verzögerte Anfragen abarbeiten können.
In GKE Enterprise 1.14 und höher wird die Ratenbeschränkung automatisch an die Knotenkapazität angepasst. Die Ratenbegrenzung kann sich einer angemessenen Zahl annähern, wobei für leistungsstärkere Knoten höhere Ratenbegrenzungen gelten.
Häufiger Fehler: Ebpf map size is full
Dataplane v2 speichert den Status in einer eBFP-Zuordnung. Der Status umfasst Dienst, Verbindungs-Tracking, Pod-Identität und Netzwerkrichtlinienregeln. Wenn eine Zuordnung voll ist, kann der Agent keine Einträge einfügen, was zu einer Diskrepanz zwischen der Steuerungsebene und der Datenebene führt. Die Dienstzuordnung hat beispielsweise ein Eintragslimit von 64.000.
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
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
Starten Sie
anetd
neu, um den Status in der eBFP-Zuordnung neu zu füllen.
Knoten nicht bereit aufgrund von NetworkPluginNotReady-Fehlern
Wenn der CNI-Pod nicht auf dem Knoten ausgeführt wird, wird möglicherweise ein ähnlicher Fehler wie der folgende angezeigt:
"Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized
Möglicherweise befindet sich der Knoten auch in einem nicht bereiten Zustand, mit einem Fehler wie im folgenden Beispiel:
"Network plugin not installed"
Wenn ein Knoten initialisiert wird, wartet kubelet
auf mehrere Ereignisse, bevor der Knoten als Ready
gekennzeichnet wird. Eines der von kubelet
geprüften Ereignisse ist, dass das Plug-in "Container Network Interface (CNI)" installiert ist. Das CNI-Plug-in sollte von anetd mithilfe eines Init-Containers installiert werden, um sowohl die CNI-Binärdatei als auch die CNI-Konfiguration in den erforderlichen Hostverzeichnissen zu installieren.
Prüfen Sie zur Fehlerbehebung, warum diese Pods nicht auf dem Knoten ausgeführt werden. Normalerweise wird der Fehler nicht durch Netzwerkprobleme verursacht. Diese Pods werden im Hostnetzwerk ausgeführt, sodass keine Netzwerkabhängigkeit besteht.
Prüfen Sie den Status des Pods
anetd
. Führen Sie die folgenden Schritte zur Fehlerbehebung aus, um die Ursache des Problems zu ermitteln:- Wenn der Pod den Status
Crashlooping
hat, prüfen Sie in den Logs, warum der Pod nicht ordnungsgemäß ausgeführt werden kann. - Wenn der Pod den Status
Pending
hat, verwenden Siekubectl describe
und prüfen Sie die Pod-Ereignisse. Im Pod fehlt beispielsweise eine Ressource wie ein Volume. - Wenn der Pod den Status
Running
hat, prüfen Sie die Protokolle und die Konfiguration. Einige CNI-Implementierungen bieten Optionen zur Deaktivierung der CNI-Installation, wie in Cilium. - In anetd gibt es eine Konfigurationsoption namens
custom-cni-conf
. Wenn diese Einstellung auftrue
konfiguriert ist, installiert anetd die CNI-Binärdatei nicht.
- Wenn der Pod den Status
Knoten NICHT BEREIT aufgrund veralteter ARP-Einträge
Manchmal können veraltete ARP-Einträge in Knoten der Steuerungsebene des Administratorclusters zu einer Abweichung bei MAC-Adressen führen. Diese nicht übereinstimmende Adresse kann wiederum zu Zeitüberschreitungen bei den Verbindungen bei den VIPs der Steuerungsebene verwalteter Nutzercluster führen. Die Zeitüberschreitungen der Verbindung können dazu führen, dass der Knoten veraltete ARP-Einträge als NOT
READY
markiert. Knoten, die als NOT READY
markiert sind, können Clusterinstallationen und -upgrades anhalten.
In diesem Fall enthält das Kubelet-Log des Knotens mit veralteten ARP-Einträgen einen TLS-Handshake-Zeitüberschreitungsfehler wie den folgenden:
failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout
Führen Sie die folgenden Schritte aus, um das Problem zu überprüfen und zu beheben:
Verwenden Sie SSH, um eine Verbindung zum Knoten der Steuerungsebene des Nutzerclusters herzustellen.
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.Verwenden Sie SSH, um eine Verbindung zu einem Knoten der Steuerungsebene des Administratorclusters herzustellen.
Prüfen Sie den ARP-Cache auf der Steuerungsebene des Administratorclusters auf die VIP-Adresse der Steuerungsebene des Nutzerclusters:
ip n | grep VIP_ADDRESS
Ersetzen Sie
VIP_ADDRESS
durch die IP-Adresse der VIP der Steuerungsebene des Nutzerclusters (controlPlaneVIP
).Wenn die beiden
ip
-Befehle eine andere macOS-Adresse zurückgeben, sind Sie von diesem Problem betroffen.Leeren Sie den ARP-Cache auf dem Knoten der Administratorcluster-Steuerungsebene, um das Problem zu beheben:
ip n flush all
F5-Dienst empfängt keinen Traffic
Wenn kein Traffic an den F5-Dienst weitergeleitet wird, führen Sie die folgenden Schritte zur Fehlerbehebung aus:
Prüfen Sie, ob jede Partition in F5 BIG-IP in einem Cluster konfiguriert ist, entweder in Administrator- oder Nutzerclustern. Wenn eine Partition von mehreren verschiedenen Clustern gemeinsam genutzt wird, kommt es zu sporadischen Verbindungsunterbrechungen. Dieses Verhalten ist darauf zurückzuführen, dass zwei Cluster versuchen, die Kontrolle über dieselbe Partition zu übernehmen und Dienste aus anderen Clustern zu löschen.
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 vombigip
-Controller verwendet.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
Prüfen Sie die Logs und Messwerte Ihrer BIG-IP-Instanz. Wenn die ConfigMap richtig konfiguriert ist, die BIG-IP-Instanz die Konfiguration jedoch nicht berücksichtigt, kann dies ein F5-Problem sein. Bei Problemen innerhalb der BIG-IP-Instanz wenden Sie sich an den F5-Support, um die Probleme zu diagnostizieren und zu beheben.
NAT-Fehler mit zu vielen parallelen Verbindungen
Für einen bestimmten Knoten in Ihrem Cluster bietet die Knoten-IP-Adresse Network Address Translation (NAT) für Pakete, die an eine Adresse außerhalb des Clusters weitergeleitet werden.
Wenn eingehende Pakete in einen Load-Balancing-Knoten gelangen, der für die Verwendung des gebündelten Load-Balancings (spec.loadBalancer.mode: bundled
) konfiguriert ist, leitet die Quellnetzwerkadressübersetzung (SNAT) die Pakete an die Knoten-IP-Adresse weiter, bevor sie werden an einen Backend-Pod weitergeleitet.
Der von Google Distributed Cloud verwendete Portbereich für NAT ist 32768-65535
. Dieser Bereich begrenzt die Anzahl paralleler Verbindungen auf 32.767 pro Protokoll auf diesem Knoten. Jede Verbindung benötigt einen Eintrag in der Conntrack-Tabelle. Wenn Sie zu viele kurzlebige Verbindungen haben, braucht die Conntrack-Tabelle die Ports für NAT auf. Eine Speicherbereinigung bereinigt die veralteten Einträge, die Bereinigung erfolgt jedoch nicht sofort.
Wenn sich die Anzahl der Verbindungen auf dem Knoten 32.767 nähert, werden Sie Paketverluste für Verbindungen feststellen, die NAT benötigen.
So ermitteln Sie, ob Sie von diesem Problem betroffen sind:
Führen Sie den folgenden Befehl auf dem Pod
anetd
auf dem problematischen Knoten aus:kubectl -n kube-system anetd-XXX -- hubble observe \ --from-ip $IP --to-ip $IP -f
Es sollten Fehler in folgender Form angezeigt werden:
No mapping for NAT masquerade DROPPED
Als Behelfslösung für dieses Problem können Sie den Traffic auf andere Knoten verteilen.