Netzwerkprobleme mit Google Distributed Cloud ansprechen

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

Fehlerbehebung bei der Netzwerkverbindung

Das GKE Enterprise-Netzwerk basiert auf Ihrer physischen Netzwerk-Infrastruktur. 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 ermitteln, ob das Problem 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: 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)
  • 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 vom selben 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.
  • Probleme mit HTTP oder HTTPS 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. Momentaufnahmen nach der Wiederherstellung des Systems enthalten daher nicht genügend Informationen für die Analyse der Ursache.

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.

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

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

Beheben Sie Probleme mit eingehendem Netzwerk-Traffic, indem Sie alle Schritte prüfen, den ein Paket durchläuft, während es sich durch Ihre Umgebung bewegt. Prüfe, ob die entsprechenden Aktionen und Verbindungen verfügbar sind.

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

  • Verlässt das Paket den Client? Wenn nicht, liegt wahrscheinlich ein Problem mit der Netzwerkinfrastruktur vor.
  • Verwenden Sie MetalLB? Wenn ja, 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? Wenn ja, haben Sie nach F5-Problemen gesucht?
  • Wird die Netzwerkadressübersetzung (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.
  • Kommt das Paket im Pod an? Wenn nicht, liegt wahrscheinlich ein Problem mit der lokalen Weiterleitung von 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. Verwenden Sie tcpdump, um das Paket zu prüfen, wenn es den Client für den Zieldienst verlässt:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Wenn kein Traffic hinausgeht, liegt hier das Problem.

Geht das Paket bei einem LoadBalancer-Knoten ein?

Wenn Sie MetalLB als Load-Balancer verwenden:

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

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

  2. Stellen Sie ü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 ManualLB 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 kein NAT durchführt, bevor das Paket an 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 einem der folgenden Abschnitte unter 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, deutet dies auf ein Problem in Ihrer physischen Netzwerkinfrastruktur hin. Eine häufige Ursache für dieses Problem ist, dass einige erweiterte Datenebenen-Lernfunktionen ARP-Antworten in softwarebasierten Netzwerklösungen (Software-Defined Networking, SDN) 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.

  2. Bei MetalLB wird kein Gratuitous ARP gesendet. Die Häufigkeit, mit der Sie eine Antwort sehen, 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 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-Debug-Tools verwenden:

    cilium monitor --type=drop

Weitere Informationen finden Sie in einem der folgenden Abschnitte unter Dataplane v2 / Cilium-Probleme.

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 normalerweise eth0 oder ens192 heißt:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
Bei Google Distributed Cloud wird das Paket in einem Tunnel gekapselt. Wenn das Paket entkapselt wird, kommt es über eine Netzwerkschnittstelle namens cilium_geneve heraus.

Da normale Dienst-Backends mehrere Pods auf verschiedenen Knoten enthalten, kann es schwierig sein, den fehlerhaften Knoten zu ermitteln. Eine gängige Problemumgehung besteht darin, das Problem so lange aufzuzeichnen, bis ein Paket eintrifft, oder die Anzahl der Back-Ends auf eins zu beschränken.

Wenn das Paket nie am Worker-Knoten ankommt, deutet dies auf ein Problem mit der Netzwerkinfrastruktur hin. 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 softwarebasierten Netzwerks (SDN). Manchmal werden Pakete vom SDN aus verschiedenen Gründen verworfen, 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 mit 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 arbeiten. Ein Paket, das an ein Ende der Schnittstelle gesendet wird, wird am anderen Ende der Schnittstelle empfangen. Eine der Schnittstellen wird in den Netzwerk-Namespace des Pods verschoben und in eth0 umbenannt. Die andere Schnittstelle verbleibt im Host-Namespace. 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 im Pod ankommt. Alternativ können Sie auch die Schnittstelle angeben:

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Wenn das Paket am Knoten, aber nicht am Pod ankommt, 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 aufweist. 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. Das folgende Diagramm zeigt, dass in einem Arbeitsbeispiel der eingehende Traffic von links nach rechts durch den Stack fließt:

Ausgehender Traffic fließt vom Pod über die externe Schnittstelle des Hosts zur physischen Infrastruktur und dann zum externen Dienst.

  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.

    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 zeigt, dass Pakete korrekt maskiert werden, der Remotedienst aber nicht reagiert, prüfen Sie die Verbindung zum externen Dienst in Ihrer Infrastruktur.

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

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    Pingen Sie gleichzeitig mit der Ausführung von tcpdump 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.

Clusterinterne Probleme

Bei Problemen mit der Pod-zu-Pod-Konnektivität sollten Sie das Problem auf Knoten eingrenzen. 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 den Status von innerhalb des anetd-Pods:

    cilium status --all-health

Probleme mit der Netzwerkschicht

Es ist wichtig, die Netzwerkschicht zu identifizieren, in der das Verbindungsproblem auftritt. Eine Fehlermeldung wie „Verbindungsproblem zwischen Quelle und Ziel“ ist nicht informativ 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 Behebung von Problemen mit der 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 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. Probleme können jedoch auch durch eine Fehlkonfiguration Ihrer Knoten, ToR-Switches (Top of Rack), Spine-Router oder Firewalls verursacht werden. 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 VIPs von Load-Balancern 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 per „ping“ prüfen. Obwohl F5 anders ist, wird auch ICMP unterstützt. 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.

Ein erfolgreicher arping <ip>-Befehl 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 oft ein physischer Schalter zwischen Knoten.

Mit Arping können auch IP-Adresskonflikte erkannt werden. Ein IP-Adressenkonflikt tritt auf, wenn zwei Maschinen für die Verwendung derselben IP-Adresse im selben Subnetz konfiguriert sind oder eine VIP von einer anderen physischen Maschine 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 Routingtabelle ausgeben
  • ip n: Gibt die Nachbartabelle für die Zuordnung von IP-Adressen zu MAC-Adressen aus.
  • ip a: Alle Schnittstellen auf dem Computer ausgeben

Eine fehlende Route oder ein fehlender Eintrag in der Nachbartabelle kann zu Verbindungsproblemen des Knotens 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 enthält mehrere nützliche Debugging-Tools für Verbindungsprobleme:

  • 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 werden in vielen Kubernetes-Komponenten und ‑Subsystemen verwendet. kube-proxy verwendet iptables, um die Dienstauflösung zu implementieren.

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

    iptables -L -v | grep DROP

    Sehen Sie sich die Drop-Regeln an und prüfen Sie, ob die Anzahl der Pakete und Bytes im Laufe der Zeit zunimmt.

Tcpdump

Tcpdump ist ein leistungsstarkes Tool zur Paketerfassung, das viele Netzwerkverkehrsdaten generiert. Häufig wird tcpdump sowohl auf der Quelle als auch auf dem 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 deutet in der Regel darauf hin, dass das Paket aufgrund eines Fehlers in Ihrer physischen Infrastruktur verworfen wird.

Messwerte

Google Distributed Cloud enthält mehrere Messwerte, mit denen Sie das Verhalten Ihres Netzwerks nachvollziehen können. Die folgenden Messwerte sind ein guter Ausgangspunkt:

Kategorie Messwert Beschreibung
Verworfene Pakete cilium_drop_bytes_total Gesamtzahl der gelöschten Bytes, getaggt nach Grund für das Löschen und Richtung (eingehend/ausgehend). Dieser Messwert ist ein guter Ausgangspunkt für die Untersuchung von Byte-Level-Rückgängen.
cilium_drop_count_total Gesamtzahl der verworfenen Pakete, getaggt nach Grund für das Verwerfen und Richtung (eingehend/ausgehend).
container_network_receive_packets_dropped_total Kumulative Anzahl der Pakete, die während des Empfangs verworfen wurden. Die Stichprobenerhebung erfolgt alle 60 Sekunden.
container_network_transmit_packets_dropped_total Kumulative Anzahl der Pakete, die während der Übertragung verworfen wurden. Die Stichprobenerhebung erfolgt alle 60 Sekunden.
Weitergeleitete Pakete cilium_forward_bytes_total Gesamtzahl der weitergeleiteten Byte, getaggt nach Ein- und Ausgangsrichtung. Alle 60 Sekunden wird eine Stichprobe erstellt. Dieser Messwert enthält Weiterleitungsinformationen auf Byte-Ebene.
cilium_forward_count_total Gesamtzahl der weitergeleiteten Pakete, die nach Ein- und Ausgangsrichtung getaggt sind. Alle 60 Sekunden wird eine Stichprobe erstellt. Dieser Messwert gibt die Anzahl der Pakete für weitergeleiteten Traffic an.
cilium_policy_l7_forwarded_total Weitergeleitete L7-Anfragen insgesamt.
Empfangene Pakete cilium_policy_l7_received_total Anzahl der insgesamt empfangenen L7-Anfragen/Antworten. Die Stichprobenerhebung erfolgt alle 60 Sekunden.
container_network_receive_bytes_total Kumulative Anzahl der empfangenen Byte. Alle 60 Sekunden wird eine Stichprobe erstellt.
container_network_receive_packets_total Kumulative Anzahl der empfangenen Pakete. Alle 60 Sekunden wird eine Stichprobe erstellt.
container_network_receive_errors_total Kumulative Anzahl der Fehler, die beim Empfang aufgetreten sind. Die Stichprobenerhebung erfolgt alle 60 Sekunden.
cilium_kubernetes_events_received_total Anzahl der empfangenen Kubernetes-Ereignisse, aufgeschlüsselt nach Bereich, Aktion, gültigen Daten und Gleichheit. Alle 60 Sekunden wird eine Stichprobe erstellt.
BPF cilium_bpf_maps_virtual_memory_max_bytes BPF-Maps für die maximale Arbeitsspeichernutzung des Kernels in Byte.
cilium_bpf_progs_virtual_memory_max_bytes Maximale Arbeitsspeichernutzung des Kernels durch BPF-Programme in Byte.
Conntrack node_nf_conntrack_entries Anzahl der aktuell zugewiesenen Flow-Einträge für die Verbindungsüberwachung. Alle 60 Sekunden wird eine Stichprobe erstellt.
node_nf_conntrack_entries_limit Maximale Größe der Verbindungstrackingtabelle. Alle 60 Sekunden wird eine Stichprobe erstellt.
Verbindung cilium_node_connectivity_latency_seconds Die zuletzt beobachtete Latenz zwischen dem aktuellen Cilium-Agent und anderen Cilium-Knoten in Sekunden. Alle 60 Sekunden wird eine Stichprobe erstellt.
cilium_node_connectivity_status Der zuletzt beobachtete Status der ICMP- und HTTP-Verbindung zwischen dem aktuellen Cilium-Agent und anderen Cilium-Knoten. Alle 60 Sekunden wird eine Stichprobe erstellt.
Cilium-Operatoren cilium_operator_process_cpu_seconds_total Insgesamt verbrauchte Nutzer- und System-CPU-Zeit in Sekunden. Die Stichprobenerhebung erfolgt alle 60 Sekunden.
cilium_operator_process_max_fds Maximale Anzahl geöffneter Dateideskriptoren. Alle 60 Sekunden wird eine Stichprobe erstellt.
cilium_operator_process_open_fds Anzahl der geöffneten Dateideskriptoren. Alle 60 Sekunden wird eine Stichprobe erstellt.
cilium_operator_process_resident_memory_bytes Größe des residenten Speichers in Byte. Alle 60 Sekunden wird eine Stichprobe erstellt.
cilium_operator_process_start_time_seconds Startzeit des Prozesses seit der Unix-Epoche in Sekunden. Die Stichprobenerhebung erfolgt alle 60 Sekunden.
cilium_operator_process_virtual_memory_bytes Größe des virtuellen Speichers in Byte. Alle 60 Sekunden wird eine Stichprobe erstellt.
cilium_operator_process_virtual_memory_max_bytes Die maximale Menge an verfügbarem virtuellen Arbeitsspeicher in Byte. Die Stichprobenerhebung erfolgt alle 60 Sekunden.
cilium_operator_identity_gc_entries Die Anzahl der aktiven und gelöschten Identitäten am Ende eines Garbage Collector-Laufs. Alle 60 Sekunden wird eine Stichprobe erstellt.
cilium_operator_identity_gc_runs Die Anzahl der Ausführungen der Speicherbereinigung für Identitäten. Die Stichprobenerhebung erfolgt alle 60 Sekunden.

Wenn Sie Benachrichtigungen erhalten möchten, wenn einer dieser Messwerte einen bestimmten Schwellenwert über- oder unterschreitet, erstellen Sie Benachrichtigungsrichtlinien. Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien erstellen.

Weitere Informationen zu diesen Messwerten und die vollständige Liste der Messwerte finden Sie unter Google Distributed Cloud-Messwerte.

DNS-Fehlerbehebung

Probleme mit 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 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 alle Versionen von Google Distributed Cloud 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 eine der folgenden Kategorien eingeteilt 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 reagiert auf Anfragen für gültige cluster.local-Domains.
  • Wenn die Anfrage nicht für eine cluster.local-Domain bestimmt ist, handelt es sich um eine externe Domain.
    • CoreDNS leitet die Anfrage an die vorgelagerten 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 über die Funktionsweise und Konfiguration von DNS in Kubernetes.

Tipps zur DNS-Fehlerbehebung

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 korrekt funktioniert. Die folgenden Beispiele zeigen, wie Sie dig und nslookup verwenden, um nach Problemen bei der DNS-Auflösung zu 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 oder keine Antwort erhalten, deutet dies auf ein Problem mit der DNS-Auflösung hin.

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 Probleme mit der Clusterverbindung als DNS-Probleme auf, da eine DNS-Anfrage die erste Art von Traffic ist, die von einer Arbeitslast gesendet wird.

Sehen Sie sich Fehlermeldungen Ihrer Anwendungen an. 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 Logs 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 mit Hostnetzwerk

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. Das bedeutet, dass sie cluster.local-Domainnamen nicht 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 korrekt funktioniert.

Prüfen Sie, ob auf allen Knoten dieselben Server konfiguriert sind. Wenn Sie verschiedene Nameserver konfiguriert haben, kann es zu Inkonsistenzen bei der DNS-Auflösung auf verschiedenen Knoten kommen. Prüfen Sie, ob jeder Nameserver einzeln funktioniert, indem Sie mit dig oder nslookup eine Anfrage an jeden Nameserver 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. Führen Sie die entsprechenden Schritte zur Fehlerbehebung aus, 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 Ereignis zur Pod-Erstellung vom Cilium-Agent aufgrund eines Ratenlimits 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 das Ratenlimit 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

In Dataplane v2 wird der Status in einer eBFP-Zuordnung gespeichert. Der Status umfasst Dienst-, Verbindungs-Tracking-, Pod-Identitäts- und Network Policy-Regeln. 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-Maps 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-Maps 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 ist aufgrund von NetworkPluginNotReady-Fehlern nicht bereit

Wenn der CNI-Pod nicht auf dem Knoten ausgeführt wird, wird möglicherweise ein 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 ü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 dieses Problems, 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 anetd-Pods. Führen Sie die folgenden Schritte zur Fehlerbehebung aus, um die Ursache des Problems zu ermitteln:

    • Wenn sich der Pod im Status Crashlooping befindet, prüfen Sie in den Logs, warum der Pod 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 sich der Pod im Status Running befindet, prüfen Sie die Logs und die Konfiguration. Einige CNI-Implementierungen bieten Optionen zum Deaktivieren der CNI-Installation, z. B. in Cilium.
    • In anetd gibt es eine Konfigurationsoption namens custom-cni-conf. Ist diese Einstellung auf true konfiguriert, installiert anetd die CNI-Binärdatei nicht.

Knoten NICHT BEREIT aufgrund veralteter ARP-Einträge

Manchmal können veraltete ARP-Einträge in Knoten der Steuerungsebene des Administratorclusters zu 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 Zeitüberschreitungen der Verbindung 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 auf dem Knoten 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 können Sie das Problem überprüfen und beheben:

  1. Stellen Sie eine SSH-Verbindung zum Knoten der Steuerungsebene des Nutzerclusters her.

  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 Knoten der Steuerungsebene.

  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 eine unterschiedliche MAC-Adresse 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, kann es zu zeitweiligen Verbindungsunterbrechungen kommen. Dieses Verhalten tritt auf, weil 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

    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 für jeden Port jedes Dienstes eine ConfigMap vorhanden ist. Beispiel:

    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 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, liegt möglicherweise ein Problem mit F5 vor. Bei Problemen, die in der BIG-IP-Instanz auftreten, 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 Portbereich für NAT, der von Google Distributed Cloud verwendet wird, 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 stellen Sie fest, ob Sie von diesem Problem betroffen sind:

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

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

    Es sollten Fehler in folgender Form angezeigt werden:

    No mapping for NAT masquerade DROPPED

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

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care. Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören:

  • Anforderungen für das Eröffnen eines Supportfalls.
  • Tools zur Fehlerbehebung, z. B. Ihre Umgebungskonfiguration, Logs und Messwerte.
  • Unterstützte Komponenten.