
Pods in einem bestimmten Knoten (nennen wir ihn Mynode) haben keinen Zugriff auf das Internet, die übrigen in anderen Knoten geplanten Pods haben jedoch Internetzugang.
Mynode hat Zugriff auf das Internet, ich kann mich per SSH damit verbinden und auch eigenständige Docker-Container starten. Diese haben tatsächlich Zugriff auf das Internet, die auf dem Knoten geplanten Pods jedoch nicht.
Das Problem betrifft Ein- und Ausgang, Kubelet läuft auf Port 10250 und ist erreichbar über:
curl https://localhost:10250 -k
gibt zurück 404 page not found
.
Kontext: Mein Cluster hat einige Knoten mit derselben Spezifikation. Gestern habe ich beschlossen, das Betriebssystem zu aktualisieren (20.04 auf 22.04). Daher habe ich den vorherigen K8S-Cluster entfernt, der einwandfrei funktionierte, das Betriebssystem auf allen Knoten aktualisiert, K8S neu installiert und den Cluster neu erstellt. Auf allen Knoten außer Mynode funktioniert alles reibungslos. Es befindet sich im ReadyState und scheint einwandfrei zu sein, ist es aber nicht.
Mein CNI ist Calico. Calico-Pods (CSI-Node-Driver und Calico-Node) auf dem Knoten befinden sich im Status „Ausführen“, keine Neustarts.
Ich habe die Debugging-Seite auf der K8s-Website befolgt. Der auf dem Pod geplante HTTP-Server kann nicht erreicht werden. Dieses Problem betrifft also beideEin- und Ausstieg.
Antwort1
Das Problem scheint nach dem Betriebssystem-Upgrade aufgetreten zu sein. Überprüfen Sie daher, ob das CNI-Plugin, die CRIs und die Container-Images der Pods auf dem neuesten Stand und mit der neueren Betriebssystemversion 22.04 kompatibel sind.
Das Problem kann aus verschiedenen Gründen auftreten, beispielsweiseNetzwerkrichtlinienBlockieren des Zugriffs, Konfiguration des Pod-Netzwerks und Calico CNI-Probleme. Befolgen Sie die folgenden Schritte, um Ihr Problem zu lösen:
Sehen Sie sich die CoreDNS-Protokolle und Pod-Protokolle an, um das Problem zu verstehen. Durch Ausführen der folgenden Befehle erhalten Sie weitere Informationen:
kubectl logs --namespace=kube-system -l k8s-app=kube-dns
kubectl loggt Podname
Überprüfen Sie alle Netzwerkrichtlinien, die den Datenverkehr zum Pod blockieren. Sie erhalten weitere Informationen, wenn Sie den folgenden Befehl ausführen:
kubectl get networkpolicy
Überprüfen der erforderlichen Portsgeöffnet sind oder nicht.
Überprüfen Sie, ob die Firewall-Regel im Pod den Datenverkehr blockieren könnte.
Match pods CIDR und Calico's Standard ist 192.168.0.0/16, sieheGitHub-Kommentarfür mehr Details.
Wenn der HTTP-Server auf DNS-Namen angewiesen ist, stellen Sie sicher, dassDNS-Auflösungist im Cluster richtig konfiguriert.
Bearbeiten1
Manchmal gibt es keine Probleme mit CoreDNS, aber aufgrund von Netzwerkproblemen von k8s wird der Datenverkehr zu ClusterIPs nicht richtig an Pods weitergeleitet. Dies kann am Kube-Proxy liegen. Siehe k8sDebug-Dienstezur Anleitung zur Fehlerbehebung.
Überprüfen Sie auch, ob sich Pod-Netzwerke mit den Host-Netzwerken überschneiden. SieheInstallieren eines Pod-Netzwerk-Add-onsfür mehr Details.
Manchmal werden netzwerkbezogene Funktionen während des Upgrades nicht geladen und wenn Sie in solche Pods gelangen, arbeiten Sie als Root-Benutzer. Versuchen Sie es also
apt-get update
und später können Sie es tunapt-get install curl.
Antwort2
Die Lösung bestand darin, den Server neu zu starten ...
Antwort3
Die Anzeige von Kubelet 404
ist erwartungsgemäß, da die URL nicht existiert. Versuchen Sie Folgendes:
curl -k https://localhost:10250/healthz
ip_forward
Ich würde mit der Überprüfung des fehlerhaften Knotens beginnen
cat /proc/sys/net/ipv4/ip_forward
Wenn das nicht der Fall ist, werde ich die von Calico durchgesetzten Richtlinien überprüfen.
kubectl get networkpolicy -A
kubectl get gnp
kubectl get cnp -A
Als nächstes würde ich überprüfen, nat
ob der IPPool aktiviert ist
kubetl get ippool -o yaml
Überprüfen Sie das Gateway.
Hinweis: Durch das Leeren von iptables wird Ihre Verbindung möglicherweise vorübergehend unterbrochen. Stellen Sie sicher, dass Sie über eine Konsolenverbindung verfügen.
Das Leeren von IP-Tabellen wäre vielleicht auch keine schlechte Idee, könnte aber eine Art Regel sein, die sich zu lange aufgehalten hat.
iptables -F