View a markdown version of this page

Exécution de kube-proxy en mode nftables - Amazon EKS

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. Il était disponible en version alpha en 1.29 et en version bêta en 1.31. Le backend iptables installe une règle pour chaque service et évalue les règles de manière séquentielle. Il en résulte un temps de traitement des paquets O (n) qui augmente avec le nombre de services. En revanche, nftables utilise des cartes de verdict pour envoyer les paquets dans un délai d'environ O (1). Cela permet de maintenir la latence par paquet à peu près constante, même dans les clusters contenant des dizaines de milliers de services, ce qui permet d'améliorer l'efficacité des clusters contenant des milliers de nœuds et de services.

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, qui a été conçu comme un équilibreur de charge et expose des algorithmes de planification tels que le round robin et le moindre nombre de connexions, le backend nftables ne propose pas d'algorithmes de planification configurables. Lorsqu'un service possède plusieurs pods de support, le mode nftables sélectionne un pod principal au hasard.

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) sur le site Web. GitHub