Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Kube-Proxy im Nftables-Modus ausführen
`kube-proxy`Im Nftables-Modus kann Amazon EKS das [ Netzwerklatenzproblem lösen, das ](https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html#reliability_cprunning_large_clusters) häufig in großen Clustern mit über 1.000 Diensten auftritt, die Kube-Proxy im iptables-Modus ausführen. Der Iptables-Modus verarbeitet die Paketfilterregeln sequentiell für das erste Paket jeder Verbindung, was zu diesem Leistungsproblem führt. nftables ist der Nachfolger von iptables, und das nftables-Backend behebt dieses Latenzproblem, indem es Pakete unabhängig von der Clustergröße in nahezu konstanter Zeit `kube-proxy` verarbeitet. Um dieses Problem zu vermeiden, konfigurieren Sie Ihren Cluster so, dass er im Nftables-Modus ausgeführt wird. `kube-proxy`
## -Übersicht
Das `kube-proxy` nftables-Backend ist seit Kubernetes-Version 1.33 allgemein verfügbar (GA). [https://kubernetes.io/blog/2025/02/28/nftables-kube-proxy/](https://kubernetes.io/blog/2025/02/28/nftables-kube-proxy/) Es war in 1.29 als Alpha und in 1.31 als Beta verfügbar. Das iptables-Backend installiert eine Regel für jeden Service und wertet die Regeln sequentiell aus. Dies führt zu einer O (n) -Paketverarbeitungszeit, die mit der Anzahl der Dienste wächst. Im Gegensatz dazu verwendet nftables [ Urdict-Maps, ](https://kubernetes.io/blog/2025/02/28/nftables-kube-proxy/) um Pakete in ungefähr O (1) -Zeit zu versenden. Dadurch bleibt die Latenz pro Paket selbst in Clustern mit Zehntausenden von Diensten nahezu konstant, was für Effizienz bei Clustern mit Tausenden von Knoten und Diensten sorgt.
**Anmerkung**
Obwohl das nftables-Backend GA ist, `iptables` bleibt es aus Kompatibilitätsgründen der `kube-proxy` Standardmodus. Sie müssen sich explizit für den Nftables-Modus entscheiden.
Im Gegensatz zum [ IPVS-Backend](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-ipvs), das als Load Balancer konzipiert wurde und Planungsalgorithmen wie Round-Robin und Least Connections bereitstellt, bietet das nftables-Backend keine konfigurierbaren Planungsalgorithmen. Wenn ein Service mehrere Backing-Pods hat, wählt der nftables-Modus zufällig einen Backend-Pod aus.
### Voraussetzungen
Das `kube-proxy` nftables-Backend benötigt den ** Linux-Kernel 5.13 oder höher auf Ihren Worker-Knoten. ** Amazon Linux 2023 und aktuelle Versionen von Ubuntu erfüllen diese Mindestanforderung. Da nftables-Regeln direkt über das Netfilter-Subsystem des Kernels `kube-proxy` programmiert werden, benötigen Sie außer einem unterstützten Kernel kein zusätzliches Userspace-Paket (wie`ipvsadm`) oder das Laden von Kernelmodulen.
**Anmerkung**
Kernel 5.13 ist die Mindestanforderung, um den Nftables-Modus auszuführen. Für eine verbesserte Leistung bei der Regelsynchronisierung in großen Clustern empfehlen wir einen neueren Kernel und eine neuere Version. `kube-proxy` Weitere Informationen finden Sie unter Überlegungen zur [ Leistung](#nftables-performance).
**Wichtig**
Das nftables-Backend ist möglicherweise nicht mit allen Netzwerk-Plugins kompatibel. Konsultieren Sie die Dokumentation Ihres CNI-Anbieters, bevor Sie den Nftables-Modus aktivieren. Das Amazon VPC CNI ist ab Version 2 mit dem Nftables-Modus kompatibel. `v1.23.0`
### Implementierung
Konfigurieren Sie Ihre Cluster so, dass `kube-proxy` DaemonSet sie im Nftables-Modus ausgeführt werden, indem Sie das auf setzen. `kube-proxy` `mode` `nftables`
**Warnung**
Dies ist eine disruptive Änderung. Wir empfehlen, dies außerhalb der Geschäftszeiten oder während der ersten EKS-Clustererstellung durchzuführen, um die Auswirkungen zu minimieren.
Sie können einen AWS-Befehlszeilenschnittstellen-Befehl (AWS CLI) ausführen, um nftables zu aktivieren, indem Sie das EKS aktualisieren. `kube-proxy` Add-on Dies erfordert einen EKS-Cluster, auf dem Kubernetes 1.33 oder höher ausgeführt wird.
```
aws eks update-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy \
--configuration-values '{"mode": "nftables"}' \
--resolve-conflicts OVERWRITE
```
Oder Sie können dies tun, indem Sie das `kube-proxy-config` ConfigMap in Ihrem Cluster ändern.
```
kubectl -n kube-system edit cm kube-proxy-config
```
Suchen Sie die `mode` Einstellung, die standardmäßig auf eingestellt ist`iptables`, und ändern Sie den Wert in`nftables`. Das Ergebnis einer der beiden Optionen sollte der folgenden Konfiguration ähneln.
```
mode: "nftables"
nftables:
masqueradeAll: false
masqueradeBit: 14
minSyncPeriod: 1s
syncPeriod: 30s
kind: KubeProxyConfiguration
metricsBindAddress: 0.0.0.0:10249
nodePortAddresses: null
oomScoreAdj: -998
portRange: ""
```
Wenn Ihre Worker-Knoten mit Ihrem Cluster verbunden waren, bevor Sie diese Änderungen vorgenommen haben, starten Sie den DaemonSet Kube-Proxy neu.
```
kubectl -n kube-system rollout restart ds kube-proxy
```
### Performanceaspekte
Obwohl der Nftables-Modus in der Regel ab der Kubernetes-Version verfügbar ist, empfehlen wir`v1.33`, diesen Modus erst ab der Kubernetes-Version zu verwenden. `v1.36` In `kube-proxy` v1.36.0 hat das Kubernetes-Projekt viele Leistungsverbesserungen an der Konstruktion von Nftables-Karten und -Regeln vorgenommen. Diese Änderungen reduzieren die Anzahl der Ketten `jump` und/ `goto` -Regeln erheblich und verbessern so die Synchronisationsleistung in großem Maßstab erheblich.
Diese Verbesserungen kommen in erster Linie Clustern mit einer großen Anzahl von Endpunkten (den Pods, die Ihre Dienste unterstützen) zugute. Vor `kube-proxy` Version 1.36.0 kam es bei Clustern mit Hunderttausenden von Endpunkten zu sehr langsamen Synchronisierungszeiten der NFTables-Regeln und zu häufigen CPU-Blockups. Das passiert, weil der Linux-Kernel verifiziert, dass die generierten Ketten und Sprünge keine Schleifen enthalten. `kube-proxy`
Dieses Verhalten wird auch von der Linux-Kernelversion beeinflusst. Die zugrundeliegenden Kernel-Verbesserungen sind im Linux-Kernel enthalten `6.18` (und werden auf einige frühere stabile Kernel zurückportiert). Die Verwendung des nftables-Modus mit früheren Linux-Kernelversionen kann zu langsameren Zeiten für die Regelsynchronisierung und zu potenziellen Softlockups der CPU führen. Für die beste Leistung in großen Clustern empfehlen wir, einen aktuellen Linux-Kernel zusammen mit `kube-proxy` v1.36.0 oder höher auszuführen. Weitere Informationen finden Sie unter [ Kube-Proxy-Nftables-Leistungsproblem (kubernetes/kubernetes\#135639) auf der Website. ](https://github.com/kubernetes/kubernetes/issues/135639) GitHub