Profilanwendbarkeit: Stufe 1
Erlauben Sie Kubelet, iptables zu verwalten.
Kubelets können die erforderlichen Änderungen an iptables automatisch verwalten, basierend
auf den von Ihnen gewählten Netzwerkoptionen für die Pods. Es wird empfohlen, die
Verwaltung der Änderungen an iptables den Kubelets zu überlassen. Dies stellt sicher,
dass die iptables-Konfiguration mit der Netzwerk-Konfiguration der Pods synchron bleibt.
Eine manuelle Konfiguration von iptables bei dynamischen Änderungen der Pod-Netzwerkkonfiguration
könnte die Kommunikation zwischen Pods/Containern und zur Außenwelt beeinträchtigen.
Möglicherweise sind Ihre iptables-Regeln zu restriktiv oder zu offen.
![]() |
HinweisSiehe die GKE-Dokumentation für den Standardwert.
|
Auswirkung
Kubelet würde die iptables auf dem System verwalten und synchron halten. Wenn Sie
eine andere iptables-Verwaltungslösung verwenden, kann es zu Konflikten kommen.
Prüfung
Prüfmethode 1:
- SSH zu jedem Knoten und führen Sie den folgenden Befehl aus, um den laufenden Kubelet-Prozess
zu finden:
ps -ef | grep kubelet
- Wenn die Ausgabe des obigen Befehls das Argument
--make-iptables-util-chains
enthält, überprüfen Sie, ob es auf "true" gesetzt ist. - Wenn das Argument
--make-iptables-util-chains
nicht existiert und eine Kubelet-Konfigurationsdatei durch--config
angegeben ist, überprüfen Sie, dass die DateimakeIPTablesUtilChains
nicht auffalse
setzt.
Prüfmethode 2:
Wenn Sie den api configz Endpunkt verwenden, ziehen Sie in Betracht, den Status von
authentication... "makeIPTablesUtilChains.:true
zu suchen, indem Sie die Live-Konfiguration von den Knoten extrahieren, die kubelet
ausführen.Legen Sie die lokale Proxy-Portnummer und die folgenden Variablen fest und geben Sie
die Proxy-Portnummer und den Knotennamen an:
HOSTNAME_PORT="localhost-and-port-number" NODE_NAME="The-Name-Of-Node-To-Extract-Configuration"
from the output of "kubectl get nodes"
kubectl proxy --port=8001 & export HOSTNAME_PORT=localhost:8001 (example host and port number) export NODE_NAME=gke-cluster-1-pool1-5e572947-r2hg (example node name from "kubectl get nodes") curl -sSL "http://${HOSTNAME_PORT}/api/v1/nodes/${NODE_NAME}/proxy/configz"
Wiederherstellung
Sanierungsmethode 1:
Wenn Sie die Kubelet-Konfigurationsdatei ändern, bearbeiten Sie die Datei kubelet-config.json
/etc/kubernetes/kubelet-config.yaml
und setzen Sie den untenstehenden Parameter auf true:"makeIPTablesUtilChains": true
Stellen Sie sicher, dass
/etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
das Argument --make-iptables-util-chains
nicht setzt, da dies Ihre Kubelet-Konfigurationsdatei überschreiben würde.Behebungsmethode 2:
Wenn ausführbare Argumente verwendet werden, bearbeiten Sie die Kubelet-Dienstdatei
/etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
auf jedem Worker-Knoten und fügen Sie am Ende der KUBELET_ARGS
-Variablenzeichenfolge den folgenden Parameter hinzu:--make-iptables-util-chains:true
Behebungsmethode 3:
Wenn Sie den API-Configz-Endpunkt verwenden, ziehen Sie in Betracht, den Status von
"makeIPTablesUtilChains.: true
zu überprüfen, indem Sie die Live-Konfiguration von den Knoten extrahieren, die Kubelet
ausführen.Finden Sie schrittweise ConfigMap-Verfahren in der Kubernetes-Dokumentation und führen
Sie dann die Curl-Anweisung aus dem Audit-Prozess erneut aus, um Änderungen an der
Kubelet-Konfiguration zu überprüfen:
kubectl proxy --port=8001 & export HOSTNAME_PORT=localhost:8001 (example host and port number) export NODE_NAME=gke-cluster-1-pool1-5e572947-r2hg (example node name from "kubectl get nodes") curl -sSL "http://${HOSTNAME_PORT}/api/v1/nodes/${NODE_NAME}/proxy/configz"
Für alle drei Behebungsmethoden:
Basierend auf Ihrem System, starten Sie den
kubelet
-Dienst neu und überprüfen Sie den Status:systemctl daemon-reload systemctl restart kubelet.service systemctl status kubelet -l