Problembehandlung bei Kubernetes

  • Artikel

Diese Seite führt durch mehrere häufige Probleme mit Kubernetes-Setup, Netzwerk und Bereitstellungen.

Tipp

Schlagen Sie ein FAQ-Element vor, indem Sie eine PR zu unserem Dokumentations-Repository auslösen.

Diese Seite ist in die folgenden Kategorien unterteilt:

  1. Allgemeine Fragen
  2. Häufige Netzwerkfehler
  3. Häufige Windows-Fehler
  4. Allgemeine Kubernetes-Masterfehler

Allgemeine Fragen

Gewusst wie wissen, dass Kubernetes unter Windows erfolgreich abgeschlossen wurde?

Sie sollten kubelet, kube-proxy und (wenn Sie Flannel als Netzwerklösung ausgewählt haben) flanneld Host-Agent-Prozesse sehen, die auf Ihrem Knoten ausgeführt werden. Darüber hinaus sollte Ihr Windows-Knoten in Ihrem Kubernetes-Cluster als "Bereit" aufgeführt werden.

Kann ich konfigurieren, dass alles im Hintergrund ausgeführt wird?

Ab Kubernetes Version 1.11 kann kubelet & kube-proxy als systemeigene Windows-Dienste ausgeführt werden. Sie können auch jederzeit alternative Servicemanager wie nssm.exe verwenden, um diese Prozesse (flanneld, kubelet & kube-proxy) immer im Hintergrund auszuführen.

Häufige Netzwerkfehler

Lastenausgleichsgeräte sind inkonsistent über die Clusterknoten hinweg inkonsistent

Unter Windows erstellt kube-proxy einen HNS-Lastenausgleich für jeden Kubernetes-Dienst im Cluster. In der (Standard)kube-proxy-Konfiguration können Knoten in Clustern mit vielen (normalerweise 100+) Lastenausgleichsmodulen nicht mehr verfügbaren ephemeren TCP-Ports (a.k.a. dynamischer Portbereich, der standardmäßig Ports 49152 bis 65535 abdeckt). Dies liegt an der hohen Anzahl von Ports, die für jeden Knoten (nicht dsR)-Lastenausgleich reserviert sind. Dieses Problem kann sich durch Fehler in kube-proxy manifestieren, z. B.:

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

Benutzer können dieses Problem identifizieren, indem Sie das CollectLogs.ps1-Skript ausführen und die *portrange.txt Dateien konsultieren.

Die CollectLogs.ps1 HNS-Zuordnungslogik wird auch nachahmen, um die Verfügbarkeit der Portpoolzuordnung im ephemeralen TCP-Portbereich zu testen und Erfolg/Fehler zu reservedports.txtmelden. Das Skript reserviert 10 Bereiche von 64 TCP ephemeral Ports (zum Emulieren des HNS-Verhaltens), zählt Reservierungserfolge und Fehler und gibt dann die zugeordneten Portbereiche frei. Eine Erfolgsnummer kleiner als 10 gibt an, dass der kurzlebige Pool nicht mehr freien Speicherplatz hat. Eine heuristische Zusammenfassung, wie viele 64-Block-Portreservierungen ungefähr verfügbar sind, werden auch generiert in reservedports.txt.

Um dieses Problem zu beheben, können einige Schritte ausgeführt werden:

  1. Für eine dauerhafte Lösung sollte der Kube-Proxy-Lastenausgleich auf den DSR-Modus festgelegt werden. Der DSR-Modus ist vollständig implementiert und nur für neuere Windows Server Insider Build 18945 (oder höher) verfügbar.
  2. Als Problemumgehung können Benutzer auch die standardmäßige Windows-Konfiguration von kurzlebigen Ports erhöhen, die mit einem Befehl wie z netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. B. verfügbar sind. WARNUNG: Das Überschreiben des standardmäßigen dynamischen Portbereichs kann Auswirkungen auf andere Prozesse/Dienste auf dem Host haben, die auf verfügbaren TCP-Ports aus dem nicht ephemeralen Bereich basieren, sodass dieser Bereich sorgfältig ausgewählt werden sollte.
  3. Es gibt eine Skalierbarkeitsverbesserung für Nicht-DSR-Modus-Lastenausgleichsgeräte mit intelligenten Portpoolfreigaben, die in kumulativen Update-KB4551853 (und allen neueren kumulativen Updates) enthalten sind.

HostPort-Veröffentlichung funktioniert nicht

Um das HostPort-Feature zu verwenden, stellen Sie sicher, dass Ihre CNI-Plug-Ins v0.8.6 version oder höher sind und dass die CNI-Konfigurationsdatei die portMappings folgenden Funktionen festgelegt hat:

"capabilities": {
    "portMappings":  true
}

Ich sehe Fehler wie "hnsCall failed in Win32: The wrong diskette is in the drive."

Dieser Fehler kann auftreten, wenn sie benutzerdefinierte Änderungen an HNS-Objekten vornehmen oder neues Windows Update installieren, das Änderungen an HNS einführt, ohne alte HNS-Objekte zu zerreißen. Es gibt an, dass ein HNS-Objekt, das zuvor vor einem Update erstellt wurde, nicht mit der aktuell installierten HNS-Version kompatibel ist.

Unter Windows Server 2019 (und früheren Versionen) können Benutzer HNS-Objekte löschen, indem sie die HNS.data-Datei löschen.

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

Benutzer sollten in der Lage sein, alle inkompatiblen HNS-Endpunkte oder Netzwerke direkt zu löschen:

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Benutzer unter Windows Server, Version 1903, können zum folgenden Registrierungsspeicherort wechseln und alle NICs löschen, beginnend mit dem Netzwerknamen (z. B. vxlan0 ):cbr0

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

Container in meiner Flannel-Host-GW-Bereitstellung in Azure können das Internet nicht erreichen

Beim Bereitstellen von Flannel im Host-GW-Modus in Azure müssen Pakete den physischen Azure-Host vSwitch durchlaufen. Benutzer sollten benutzerdefinierte Routen vom Typ "virtual Anwendung" für jedes Subnetz programmieren, das einem Knoten zugewiesen ist. Dies kann über die Azure-Portal erfolgen (siehe ein Beispiel hier) oder über az Azure CLI. Nachfolgend sehen Sie ein Beispiel für UDR mit dem Namen "MyRoute" mit az-Befehlen für einen Knoten mit IP 10.0.0.4 und dem jeweiligen Pod-Subnetz 10.244.0.0/24:

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4 

Tipp

Wenn Sie Kubernetes auf Azure- oder IaaS-VMs von anderen Cloudanbietern selbst bereitstellen, können Sie stattdessen auch verwenden overlay networking .

Meine Windows-Pods können keine externen Ressourcen pingen

Windows-Pods verfügen heute nicht über ausgehende Regeln für das ICMP-Protokoll. TCP/UDP wird jedoch unterstützt. Wenn Sie versuchen, verbindungen mit Ressourcen außerhalb des Clusters zu veranschaulichen, ersetzen ping <IP> Sie bitte die entsprechenden curl <IP> Befehle.

Wenn Weiterhin Probleme auftreten, verdient Ihre Netzwerkkonfiguration in cni.conf wahrscheinlich eine besondere Aufmerksamkeit. Sie können diese statische Datei immer bearbeiten, die Konfiguration wird auf alle neu erstellten Kubernetes-Ressourcen angewendet.

Warum? Eine der Kubernetes-Netzwerkanforderungen (siehe Kubernetes-Modell) besteht darin, dass die Clusterkommunikation ohne NAT intern erfolgen kann. Um diese Anforderung zu berücksichtigen, verfügen wir über eine ExceptionList für alle Kommunikationen, in denen keine ausgehende NAT auftreten soll. Dies bedeutet jedoch auch, dass Sie die externe IP ausschließen müssen, die Sie aus der ExceptionList abfragen möchten. Nur dann wird der Datenverkehr, der von Ihren Windows-Pods stammt, ordnungsgemäß SNAT'ed, um eine Antwort von der Außenwelt zu erhalten. In diesem Zusammenhang sollte Ihre ExceptionList cni.conf wie folgt aussehen:

"ExceptionList": [
  "10.244.0.0/16",  # Cluster subnet
  "10.96.0.0/12",   # Service subnet
  "10.127.130.0/24" # Management (host) subnet
]

Mein Windows-Knoten kann nicht auf einen NodePort-Dienst zugreifen

Der lokale NodePort-Zugriff vom Knoten selbst schlägt möglicherweise fehl. Dies ist eine bekannte Featurelücke, die mit kumulativen Update-KB4571748 (oder höher) behoben wird. Der NodePort-Zugriff funktioniert von anderen Knoten oder externen Clients.

Mein Windows-Knoten stoppt das Routing von thourgh NodePorts, nachdem ich meine Pods verkleinerte

Aufgrund einer Entwurfsbeschränkung muss mindestens ein Pod auf dem Windows-Knoten ausgeführt werden, damit die NodePort-Weiterleitung funktioniert.

Nach einiger Zeit werden vNICs und HNS-Endpunkte von Containern gelöscht.

Dieses Problem kann verursacht werden, wenn der hostname-override Parameter nicht an kube-proxy übergeben wird. Um ihn zu beheben, müssen Benutzer den Hostnamen wie folgt an kube-proxy übergeben:

C:\k\kube-proxy.exe --hostname-override=$(hostname)

Im Flannel-Modus (vxlan) treten bei meinen Pods Konnektivitätsprobleme auf, nachdem der Knoten erneut verbunden wurde.

Wenn ein zuvor gelöschter Knoten erneut an dem Cluster angefügt wird, versucht flannelD, dem Knoten ein neues Pod-Subnetz zuzuweisen. Benutzer sollten die alten Pod-Subnetzkonfigurationsdateien in den folgenden Pfaden entfernen:

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

Nach dem Start von Kubernetes bleibt Flanneld in "Warten auf die Erstellung des Netzwerks" hängen.

Dieses Problem sollte mit Flannel v0.12.0 (und höher) behoben werden. Wenn Sie eine ältere Version von Flanneld verwenden, gibt es eine bekannte Racebedingung, die auftreten kann, sodass die Verwaltungs-IP des Flannel-Netzwerks nicht festgelegt ist. Eine Problemumgehung besteht darin, FlannelD manuell neu zu starten.

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

Meine Windows-Pods können aufgrund fehlender /run/flannel/subnet.env nicht gestartet werden.

Dies weist darauf hin, dass Flannel nicht ordnungsgemäß gestartet wurde. Sie können entweder versuchen, flanneld.exe neu zu starten, oder Sie können die Dateien manuell vom /run/flannel/subnet.env Kubernetes-Master C:\run\flannel\subnet.env auf den Windows-Arbeitsknoten kopieren und die FLANNEL_SUBNET Zeile in das subnetz ändern, das zugewiesen wurde. Beispiel: Wenn knoten subnetz 10.244.4.1/24 zugewiesen wurde:

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

Häufiger als nicht, gibt es ein weiteres Problem, das diesen Fehler verursachen könnte, der zuerst untersucht werden muss. Es wird empfohlen, diese Datei für Sie zu flanneld.exe generieren.

Pod-to-Pod-Konnektivität zwischen Hosts ist auf meinem Kubernetes-Cluster unterbrochen, der auf vSphere ausgeführt wird

Da sowohl vSphere als auch Flannel Port 4789 (Standard-VXLAN-Port) für Overlaynetzwerke reserviert, können Pakete am Ende abgefangen werden. Wenn vSphere für Overlaynetzwerke verwendet wird, sollte sie so konfiguriert werden, dass ein anderer Port verwendet wird, um bis zu 4789 freizugeben.

Meine Endpunkte/IPs gehen verloren

Es gibt 2 derzeit bekannte Probleme, die dazu führen können, dass Endpunkte verloren gehen.

  1. Das erste bekannte Problem ist ein Problem in Kubernetes, Version 1.11. Vermeiden Sie die Verwendung von Kubernetes, Version 1.11.0 - 1.11.2.
  2. Das zweite bekannte Problem , das zu einem Verlust von Endpunkten führen kann, ist ein Parallelitätsproblem im Speicher von Endpunkten. Um den Fix zu erhalten, müssen Sie Docker EE 18.09 oder höher verwenden.

Meine Pods können aufgrund von "Netzwerk: Fehler beim Zuordnen von Bereichsfehlern" nicht gestartet werden.

Dies gibt an, dass der IP-Adressraum auf Ihrem Knoten verwendet wird. Um alle durchleckten Endpunkte zu sauber, migrieren Sie alle Ressourcen für betroffene Knoten und führen Sie die folgenden Befehle aus:

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

Mein Windows-Knoten kann nicht über die Dienst-IP auf meine Dienste zugreifen.

Dies ist eine bekannte Einschränkung des aktuellen Netzwerkstapels unter Windows. Windows-Pods können jedoch auf die Dienst-IP zugreifen.

Beim Starten von Kubelet wird kein Netzwerkadapter gefunden.

Der Windows-Netzwerkstapel benötigt einen virtuellen Adapter, damit Kubernetes-Netzwerk funktioniert. Wenn die folgenden Befehle keine Ergebnisse (in einer Administratorshell) zurückgeben, ist die Erstellung des HNS-Netzwerks – eine erforderliche Voraussetzung für die Arbeit von Kubelet – fehlgeschlagen:

Get-HnsNetwork | ? Name -ieq "cbr0"
Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

Häufig lohnt es sich, den Parameter "InterfaceName" des Skripts "start.ps1" zu ändern, in Fällen, in denen der Netzwerkadapter des Hosts nicht "Ethernet" ist. Wenden Sie sich andernfalls an die Ausgabe des Skripts, um festzustellen, ob während der start-kubelet.ps1 Erstellung des virtuellen Netzwerks Fehler auftreten.

Ich sehe immer noch Probleme. Wie sollte ich vorgehen?

Möglicherweise gibt es zusätzliche Einschränkungen in Ihrem Netzwerk oder auf Hosts, die bestimmte Arten der Kommunikation zwischen Knoten verhindern. Stellen Sie Folgendes sicher:

  • Sie haben die ausgewählte Netzwerktopologie ordnungsgemäß konfiguriert (l2bridge oder overlay)
  • Datenverkehr, der wie aus Pods stammt, ist zulässig.
  • HTTP-Datenverkehr ist zulässig, wenn Sie Webdienste bereitstellen
  • Pakete aus verschiedenen Protokollen (ie ICMP vs. TCP/UDP) werden nicht gelöscht.

Tipp

Für zusätzliche Self-Help-Ressourcen gibt es auch einen Kubernetes-Netzwerk-Handbuch zur Problembehandlung für Windows hier.

Häufige Windows-Fehler

Meine Kubernetes-Pods hängen bei "ContainerCreating"

Dieses Problem kann viele Ursachen haben, aber einer der häufigsten Ursachen ist, dass das Pausenbild falsch konfiguriert wurde. Dies ist ein hohes Symptom für das nächste Problem.

Bei der Bereitstellung werden Docker-Container weiterhin neu gestartet

Überprüfen Sie, ob Ihr Pausenimage mit Ihrer Betriebssystemversion kompatibel ist. Kubernetes geht davon aus, dass sowohl das Betriebssystem als auch die Container übereinstimmende Betriebssystemversionsnummern aufweisen. Wenn Sie einen experimentellen Build von Windows verwenden, z. B. einen Insider-Build, müssen Sie die Bilder entsprechend anpassen. Weitere Informationen finden Sie im Docker-Repository von Microsoft für Images.

Allgemeine Kubernetes-Masterfehler

Das Debuggen des Kubernetes-Masters fällt in drei Standard Kategorien (in Reihenfolge der Wahrscheinlichkeit):

  • Bei den Kubernetes-Systemcontainern ist ein Fehler aufgetreten.
  • Bei der Ausführung kubelet ist ein Fehler aufgetreten.
  • Es ist ein Fehler mit dem System aufgetreten.

Führen Sie eine Ausführung kubectl get pods -n kube-system aus, um die von Kubernetes erstellten Pods zu sehen. Dies kann einen Einblick geben, welche bestimmten Abstürzen auftreten oder nicht ordnungsgemäß gestartet werden. Führen Sie dann eine Ausführung docker ps -a aus, um alle unformatierten Container anzuzeigen, die diese Pods zurückgibt. Führen Sie docker logs [ID] schließlich die Ausführung auf den Containern aus, die vermuten, dass das Problem auftritt, um die Rohausgabe der Prozesse anzuzeigen.

Eine Verbindung mit dem API-Server kann nicht hergestellt werden unter https://[address]:[port]

Dieser Fehler weist häufiger auf Zertifikatprobleme hin. Stellen Sie sicher, dass Sie die Konfigurationsdatei ordnungsgemäß generiert haben, dass die darin enthaltenen IP-Adressen mit dem Ihres Hosts übereinstimmen und dass Sie sie in das Verzeichnis kopiert haben, das vom API-Server bereitgestellt wird.

Gute Orte für die Suche nach dieser Konfigurationsdatei sind:

  • ~/kube/kubelet/
  • $HOME/.kube/config
  • /etc/kubernetes/admin.conf

andernfalls verweisen Sie auf die Manifestdatei des API-Servers, um die Bereitstellungspunkte zu überprüfen.