Debugging von Kubernetes-Netzwerkproblemen: Wesentliche Techniken

Kubernetes-Netzwerkprobleme äußern sich normalerweise als Timeouts, Connection refused, DNS-Fehler, leere Service-Endpunkte oder schlechte Ingress-Antworten. Um sie schnell zu beheben, verfolgen Sie den Pfad: Quell-Pod, Ziel-Pod, Service, DNS, NetworkPolicy und dann Ingress oder Load Balancer.

Diese Anleitung bietet Ihnen eine praktische Abfolge von Überprüfungen und die kubectl-Befehle, die aufdecken, wo der Datenverkehr stoppt.

Grundlagen des Kubernetes-Netzwerks verstehen

Bevor Sie mit dem Debuggen beginnen, ist es wichtig, die grundlegenden Netzwerkkonzepte in Kubernetes zu verstehen:

Pod-Netzwerk: Jeder Pod erhält eine eigene eindeutige IP-Adresse. Pods innerhalb desselben Knotens können direkt kommunizieren. Pods auf verschiedenen Knoten kommunizieren über ein virtuelles Netzwerk (CNI-Plugin).
Services: Services bieten eine stabile IP-Adresse und einen DNS-Namen für eine Gruppe von Pods. Sie fungieren als Abstraktionsschicht, die es anderen Pods oder externen Clients ermöglicht, auf Anwendungs-Backends zuzugreifen, ohne die einzelnen Pod-IPs kennen zu müssen.
DNS: Kubernetes DNS (normalerweise CoreDNS) löst Service-Namen in Cluster-IPs auf und ermöglicht so die Service-Erkennung.
NetworkPolicies: Diese Ressourcen steuern den Pod-Datenverkehr, wenn Ihr CNI-Plugin sie durchsetzt. Ein Cluster ohne NetworkPolicy-Unterstützung akzeptiert die Objekte, setzt die Regeln aber möglicherweise nicht durch.
Ingress: Ingress-Controller verwalten den externen Zugriff auf Dienste innerhalb des Clusters, typischerweise HTTP und HTTPS. Sie bieten Routing, Lastausgleich und SSL-Terminierung.

Häufige Netzwerkprobleme und Debugging-Strategien

1. Fehler bei der Pod-zu-Pod-Kommunikation

Wenn Pods nicht miteinander kommunizieren können, selbst innerhalb desselben Namespace, ist das ein primärer Indikator für ein Netzwerkproblem.

Symptome:

Anwendungsfehler, die auf Verbindungs-Timeouts oder -Verweigerungen hinweisen.
curl- oder ping-Befehle von einem Pod zu einem anderen schlagen fehl.

Debugging-Schritte:

Pod-IPs überprüfen: Stellen Sie sicher, dass sowohl Quell- als auch Ziel-Pod gültige IP-Adressen haben. Verwenden Sie kubectl exec <pod-name> -- ip addr.
Netzwerkkonnektivität prüfen (innerhalb des Pods): Versuchen Sie vom Quell-Pod aus, die IP-Adresse des Ziel-Pods anzupingen. Wenn dies fehlschlägt, liegt das Problem möglicherweise am CNI-Plugin oder am Knoten-Netzwerk.
```
kubectl exec <source-pod-name> -- ping <destination-pod-ip>
```
NetworkPolicies überprüfen: NetworkPolicies sind ein häufiger Übeltäter. Überprüfen Sie, ob Richtlinien den Datenverkehr zwischen den Pods versehentlich blockieren.
```
kubectl get networkpolicies -n <namespace>
```
Untersuchen Sie die podSelector- und ingress/egress-Regeln, um zu verstehen, welcher Datenverkehr erlaubt oder verboten ist. Sobald ein Pod von einer Ingress-Richtlinie ausgewählt wird, ist nur explizit erlaubter Ingress-Datenverkehr zulässig.
CNI-Plugin-Status: Stellen Sie sicher, dass Ihr Container Network Interface (CNI)-Plugin (z. B. Calico, Flannel, Cilium) auf allen Knoten korrekt ausgeführt wird. Überprüfen Sie die Logs der CNI-DaemonSet-Pods.
```
kubectl get pods -n kube-system -l k8s-app=<cni-plugin-label>
kubectl logs <cni-plugin-pod-name> -n kube-system
```

2. Probleme bei der Service-Erkennung

Wenn Pods andere Dienste nicht über ihre DNS-Namen oder Cluster-IPs erreichen können, deutet dies auf ein Problem mit Kubernetes DNS oder der Service-Objektkonfiguration hin.

Symptome:

Anwendungsfehler wie Name or service not known.
nslookup- oder dig-Befehle innerhalb eines Pods schlagen fehl, wenn sie Service-Namen auflösen.

Debugging-Schritte:

DNS-Auflösung überprüfen: Testen Sie von einem Pod aus die DNS-Auflösung für einen bekannten Service.

kubectl exec <pod-name> -- nslookup <service-name>.<namespace>.svc.cluster.local

Wenn dies fehlschlägt, überprüfen Sie die CoreDNS-Pods auf Fehler.

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs <coredns-pod-name> -n kube-system

Service-Objekt überprüfen: Stellen Sie sicher, dass das Service-Objekt korrekt konfiguriert ist und Endpunkte hat, die auf gesunde Pods verweisen.
```
kubectl get service <service-name> -n <namespace> -o yaml
kubectl get endpoints <service-name> -n <namespace>
```
Die endpoints-Ausgabe sollte die IP-Adressen der Pods auflisten, die den Service unterstützen.
Pod-Readiness-Probes: Wenn Pods ihre Readiness-Probes nicht bestehen, werden sie nicht zu den Endpunkten des Service hinzugefügt. Überprüfen Sie die Konfiguration der Readiness-Probes und die Pod-Logs auf Probleme.

3. Ingress-Controller-Probleme

Der externe Zugriff auf Ihre Dienste wird von Ingress-Ressourcen und Ingress-Controllern verwaltet. Probleme hier können Ihre Anwendung von außerhalb des Clusters unzugänglich machen.

Symptome:

502 Bad Gateway-, 404 Not Found- oder 503 Service Unavailable-Fehler beim Zugriff auf Anwendungen über ihre externe URL.
Ingress-Controller-Logs zeigen Fehler im Zusammenhang mit Backend-Diensten.

Debugging-Schritte:

Ingress-Controller-Pods überprüfen: Stellen Sie sicher, dass die Ingress-Controller-Pods (z. B. Nginx Ingress, Traefik) ausgeführt werden und gesund sind.

kubectl get pods -l app.kubernetes.io/component=controller # Label basierend auf Ihrem Ingress-Controller anpassen
kubectl logs <ingress-controller-pod-name> -n <ingress-namespace>

Ingress-Ressource überprüfen: Überprüfen Sie die Konfiguration Ihrer Ingress-Ressource.
```
kubectl get ingress <ingress-name> -n <namespace> -o yaml
```
Stellen Sie sicher, dass der rules-Abschnitt Hostnamen und Pfade korrekt auf die entsprechenden service.name und service.port abbildet.
Service und Endpunkte überprüfen: Stellen Sie wie bei der Service-Erkennung sicher, dass der Backend-Dienst, auf den der Ingress verweist, korrekt konfiguriert ist und gesunde Endpunkte hat.
```
kubectl get service <backend-service-name> -n <namespace>
kubectl get endpoints <backend-service-name> -n <namespace>
```
Firewall und Load Balancer: Wenn Sie von außerhalb des Clusters zugreifen, stellen Sie sicher, dass externe Firewalls oder Cloud-Provider-Load-Balancer korrekt konfiguriert sind, um Datenverkehr an den Service des Ingress-Controllers (oft ein LoadBalancer-Service) weiterzuleiten.

4. Durchsetzung von NetworkPolicies

NetworkPolicies können leistungsstark sein, aber auch eine Quelle von Konnektivitätsproblemen, wenn sie falsch konfiguriert sind. Sie arbeiten nach dem Prinzip der geringsten Privilegien; wenn eine Richtlinie Datenverkehr nicht explizit erlaubt, wird er verweigert.

Debugging-Schritte:

Angewandte Richtlinien identifizieren: Bestimmen Sie, welche NetworkPolicies die betreffenden Pods betreffen.
```
kubectl get networkpolicy -n <namespace>
```
Richtlinien-Selektoren überprüfen: Untersuchen Sie sorgfältig den podSelector in jeder relevanten NetworkPolicy. Dieser Selektor bestimmt, auf welche Pods die Richtlinie angewendet wird. Wenn ein Pod von mehreren Richtlinien ausgewählt wird, ist der erlaubte Datenverkehr die Vereinigung dieser Richtlinienregeln, nicht die restriktivste einzelne Regel.
Ingress/Egress-Regeln überprüfen: Analysieren Sie die Abschnitte ingress und egress der NetworkPolicy. Wenn Sie versuchen, eine Verbindung von Pod A zu Pod B herzustellen, müssen Sie Folgendes sicherstellen:
- Eine auf Pod B angewandte NetworkPolicy erlaubt Ingress-Datenverkehr von Pod A (oder einem breiteren Label-Selektor, der Pod A einschließt).
- Eine auf Pod A angewandte NetworkPolicy erlaubt Egress-Datenverkehr zu Pod B (oder einem breiteren Label-Selektor, der Pod B einschließt).
Test mit einer weit geöffneten Richtlinie: Als vorübergehenden Fehlerbehebungsschritt können Sie eine NetworkPolicy erstellen, die den gesamten Datenverkehr zu und von bestimmten Pods oder Namespaces zulässt, um zu sehen, ob die Konnektivität wiederhergestellt wird. Dies hilft zu isolieren, ob das Problem tatsächlich bei den NetworkPolicies liegt.
```
# Beispiel: Erlaube gesamten Ingress- und Egress-Datenverkehr für Pods mit Label app=my-app
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-for-my-app
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
    - {}
  egress:
    - {}
```
Warnung: Diese allow-all-Richtlinie sollte nur zur vorübergehenden Fehlerbehebung verwendet werden. Entfernen Sie sie, sobald Sie den Test abgeschlossen haben.

Wesentliche Werkzeuge und Befehle

kubectl exec: Befehle innerhalb eines Pods ausführen (z. B. ping, curl, nslookup).
kubectl logs: Logs von Pods anzeigen, insbesondere von Steuerungsebenenkomponenten und Netzwerk-Plugins.
kubectl describe: Detaillierte Informationen über Pods, Services, Ingress und NetworkPolicies erhalten, die oft Status und Ereignisse offenbaren.
kubectl get: Ressourcen und ihren grundlegenden Status auflisten.
tcpdump: Ein leistungsstarker Befehlszeilen-Paketanalysator. Sie können es innerhalb eines Pods oder auf einem Knoten ausführen, um Netzwerkverkehr zu erfassen.
```
# Beispiel: Datenverkehr auf der eth0-Schnittstelle innerhalb eines Pods erfassen
kubectl exec <pod-name> -- tcpdump -i eth0 -nn port 80
```

Fazit

Debuggen Sie Kubernetes-Netzwerke von innen nach außen. Beweisen Sie zuerst die Pod-IP-Konnektivität, dann Service-Endpunkte, dann DNS, dann NetworkPolicy und schließlich das Ingress- oder externe Load-Balancer-Verhalten. Diese Reihenfolge verhindert, dass Sie einem Ingress-Symptom nachjagen, wenn der Service keine bereiten Endpunkte hat.