Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Exécution de kube-proxy en mode nftables
kube-proxyEn mode nftables, Amazon EKS peut résoudre le problème de latence réseau courant dans les grands clusters comptant plus de 1 000 services exécutant kube-proxy en mode iptables. Le mode Iptables traite les règles de filtrage de paquets de manière séquentielle pour le premier paquet de chaque connexion, ce qui entraîne ce problème de performances. nftables est le successeur d'iptables, et le kube-proxy backend nftables résout ce problème de latence en traitant les paquets dans un temps quasi constant, quelle que soit la taille du cluster. Pour éviter ce problème, configurez votre cluster pour qu'il s'exécute kube-proxy en mode nftables.
Vue d’ensemble
Le kube-proxy backend nftables est généralement disponible (GA) depuis la version 1.33 de Kubernetes.
Note
Même si le backend nftables est GA, il iptables reste le kube-proxy mode par défaut pour des raisons de compatibilité. Vous devez explicitement activer le mode nftables.
Contrairement au backend IPVS
Exigences
Le kube-proxy backend nftables nécessite le noyau Linux 5.13 ou version ultérieure sur vos nœuds de travail. Amazon Linux 2023 et les versions actuelles d'Ubuntu répondent à cette exigence minimale. Comme kube-proxy les programmes nftables règnent directement via le sous-système netfilter du noyau, vous n'avez pas besoin de package d'espace utilisateur supplémentaire (tel queipvsadm) ou de chargement de module de noyau au-delà d'un noyau pris en charge.
Note
Le noyau 5.13 est le minimum requis pour exécuter le mode nftables. Pour améliorer les performances de synchronisation des règles dans les grands clusters, nous vous recommandons d'utiliser un noyau et une kube-proxy version plus récents. Pour plus d'informations, consultez la section Considérations relatives aux performances.
Important
Le backend nftables n'est peut-être pas compatible avec tous les plugins réseau. Consultez la documentation de votre fournisseur CNI avant d'activer le mode nftables. L'Amazon VPC CNI est compatible avec le mode nftables à partir de la version. v1.23.0
Mise en œuvre
Configurez vos clusters kube-proxy DaemonSet pour qu'ils s'exécutent en mode nftables en réglant le paramètre sur kube-proxymode. nftables
Avertissement
Il s'agit d'un changement bouleversant. Nous vous recommandons de l'exécuter en dehors des heures de bureau ou lors de la création initiale du cluster EKS afin de minimiser les impacts.
Vous pouvez émettre une commande AWS Command Line Interface (AWS CLI) pour activer nftables en mettant à jour l'kube-proxyEKS Add-on. Cela nécessite un cluster EKS exécutant Kubernetes 1.33 ou version ultérieure.
aws eks update-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy \ --configuration-values '{"mode": "nftables"}' \ --resolve-conflicts OVERWRITE
Ou vous pouvez le faire en modifiant le kube-proxy-config ConfigMap dans votre cluster.
kubectl -n kube-system edit cm kube-proxy-config
Recherchez le mode paramètre, dont la valeur par défaut estiptables, et modifiez-le ennftables. Le résultat de l'une ou l'autre des options doit ressembler à la configuration suivante.
mode: "nftables" nftables: masqueradeAll: false masqueradeBit: 14 minSyncPeriod: 1s syncPeriod: 30s kind: KubeProxyConfiguration metricsBindAddress: 0.0.0.0:10249 nodePortAddresses: null oomScoreAdj: -998 portRange: ""
Si vos nœuds de travail étaient joints à votre cluster avant que vous n'apportiez ces modifications, redémarrez le kube-proxy DaemonSet.
kubectl -n kube-system rollout restart ds kube-proxy
Considérations sur les performances
Bien que le mode nftables soit généralement disponible à partir de la version de Kubernetesv1.33, nous vous recommandons de n'utiliser ce mode qu'en commençant par. v1.36 Dans la kube-proxy version 1.36.0, le projet Kubernetes a apporté de nombreuses améliorations de performances à la manière dont les cartes et les règles nftables sont construites. Ces modifications réduisent considérablement le nombre de chaînes jump et/ou de goto règles, améliorant ainsi considérablement les performances de synchronisation à grande échelle.
Ces améliorations profitent principalement aux clusters comportant un grand nombre de points de terminaison (les pods qui soutiennent vos services). Avant la kube-proxy version 1.36.0, les clusters comportant des centaines de milliers de points de terminaison pouvaient connaître des temps de synchronisation des règles nftables et des blocages logiciels du processeur très lents. Cela se produit parce que le noyau Linux vérifie que les chaînes et les sauts kube-proxy générés ne contiennent pas de boucles.
Ce comportement est également affecté par la version du noyau Linux. Les améliorations du noyau sous-jacent sont incluses dans le noyau Linux 6.18 (et sont rétroportées vers certains noyaux stables antérieurs). L'utilisation du mode nftables avec des versions antérieures du noyau Linux peut entraîner des temps de synchronisation des règles plus lents et des blocages logiciels potentiels du processeur. Pour des performances optimales dans les grands clusters, nous vous recommandons d'exécuter un noyau Linux récent avec la kube-proxy version 1.36.0 ou une version ultérieure. Pour plus d'informations, consultez le problème de performance de kube-proxy nftables (kubernetes/kubernetes#135639)