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 IPVS
EKS en mode IP Virtual Server (IPVS) résout le [problème de latence réseau souvent rencontré](https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html#reliability_cprunning_large_clusters) lors de l'exécution de grands clusters avec plus de 1 000 services avec kube-proxy exécuté en mode iptables traditionnel. Ce problème de performance est le résultat du traitement séquentiel des règles de filtrage de paquets iptables pour chaque paquet. Ce problème de latence a été résolu dans nftables, le successeur d'iptables. Cependant, au moment de la rédaction de cet article, [kube-proxy est toujours en cours de développement](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-nftables) pour utiliser nftables. Pour contourner ce problème, vous pouvez configurer votre cluster pour qu'il s'exécute `kube-proxy` en mode IPVS.
## Présentation de
IPVS, qui est devenu GA depuis la [version 1.11 de Kubernetes](https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/), utilise des tables de hachage plutôt que la recherche linéaire pour traiter les paquets, ce qui améliore l'efficacité des clusters comportant des milliers de nœuds et de services. IPVS a été conçu pour l'équilibrage de charge, ce qui en fait une solution adaptée aux problèmes de performances réseau de Kubernetes.
IPVS propose plusieurs options pour répartir le trafic vers les modules principaux. Vous trouverez des informations détaillées sur chaque option dans la [documentation officielle de Kubernetes](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-ipvs), mais une liste simple est présentée ci-dessous. Round Robin et Least Connections font partie des options d'équilibrage de charge IPVS les plus populaires dans Kubernetes.
```
- rr (Round Robin)
- wrr (Weighted Round Robin)
- lc (Least Connections)
- wlc (Weighted Least Connections)
- lblc (Locality Based Least Connections)
- lblcr (Locality Based Least Connections with Replication)
- sh (Source Hashing)
- dh (Destination Hashing)
- sed (Shortest Expected Delay)
- nq (Never Queue)
```
### Mise en œuvre
Seules quelques étapes sont nécessaires pour activer IPVS dans votre cluster EKS. La première chose à faire est de vous assurer que le `ipvsadm` package d'administration du serveur virtuel Linux est installé sur les images de vos nœuds de travail EKS. Pour installer ce package sur une image basée sur Fedora, telle qu'Amazon Linux 2023, vous pouvez exécuter la commande suivante sur l'instance du nœud de travail.
```
sudo dnf install -y ipvsadm
```
Sur une image basée sur Debian, telle qu'Ubuntu, la commande d'installation ressemblerait à ceci.
```
sudo apt-get install ipvsadm
```
Ensuite, vous devez charger les modules du noyau pour les options de configuration IPVS répertoriées ci-dessus. Nous recommandons d'écrire ces modules dans un fichier situé à l'intérieur du `/etc/modules-load.d/` répertoire afin qu'ils puissent survivre au redémarrage.
```
sudo sh -c 'cat << EOF > /etc/modules-load.d/ipvs.conf
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_lc
ip_vs_wlc
ip_vs_lblc
ip_vs_lblcr
ip_vs_sh
ip_vs_dh
ip_vs_sed
ip_vs_nq
nf_conntrack
EOF'
```
Vous pouvez exécuter la commande suivante pour charger ces modules sur une machine déjà en cours d'exécution.
```
sudo modprobe ip_vs
sudo modprobe ip_vs_rr
sudo modprobe ip_vs_wrr
sudo modprobe ip_vs_lc
sudo modprobe ip_vs_wlc
sudo modprobe ip_vs_lblc
sudo modprobe ip_vs_lblcr
sudo modprobe ip_vs_sh
sudo modprobe ip_vs_dh
sudo modprobe ip_vs_sed
sudo modprobe ip_vs_nq
sudo modprobe nf_conntrack
```
**Note**
Il est vivement recommandé d'exécuter ces étapes du nœud de travail dans le cadre du processus d'amorçage de votre nœud de travail via un script de [données utilisateur ou dans tout script](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) de génération exécuté pour créer une AMI de nœud de travail personnalisée.
Ensuite, vous allez configurer votre cluster `kube-proxy` DaemonSet pour qu'il s'exécute en mode IPVS. Cela se fait en réglant le `kube-proxy` `mode` to `ipvs` et le `ipvs scheduler` to sur l'une des options d'équilibrage de charge répertoriées ci-dessus, par exemple : `rr` pour Round Robin.
**Avertissement**
Il s'agit d'un changement perturbateur qui doit être effectué en dehors des heures de bureau. Nous vous recommandons d'apporter ces modifications lors de la création initiale du cluster EKS afin de minimiser les impacts.
Vous pouvez émettre une commande AWS CLI pour activer IPVS en mettant à jour le module complémentaire `kube-proxy` EKS.
```
aws eks update-addon --cluster-name $CLUSTER_NAME --addon-name kube-proxy \
--configuration-values '{"ipvs": {"scheduler": "rr"}, "mode": "ipvs"}' \
--resolve-conflicts OVERWRITE
```
Vous pouvez également le faire en modifiant le `kube-proxy-config` ConfigMap dans votre cluster.
```
kubectl -n kube-system edit cm kube-proxy-config
```
Recherchez le `scheduler` paramètre ci-dessous `ipvs` et définissez la valeur sur l'une des options d'équilibrage de charge ipvs répertoriées ci-dessus, par exemple : `rr` pour Round Robin. Trouvez le `mode` paramètre, qui est par défaut`iptables`, et remplacez la valeur par. `ipvs` Le résultat de l'une ou l'autre option doit ressembler à la configuration ci-dessous.
```
iptables:
masqueradeAll: false
masqueradeBit: 14
minSyncPeriod: 0s
syncPeriod: 30s
ipvs:
excludeCIDRs: null
minSyncPeriod: 0s
scheduler: "rr"
syncPeriod: 30s
kind: KubeProxyConfiguration
metricsBindAddress: 0.0.0.0:10249
mode: "ipvs"
nodePortAddresses: null
oomScoreAdj: -998
portRange: ""
udpIdleTimeout: 250ms
```
Si vos nœuds de travail ont été joints à votre cluster avant d'apporter ces modifications, vous devrez redémarrer le kube-proxy DaemonSet.
```
kubectl -n kube-system rollout restart ds kube-proxy
```
### Validation
Vous pouvez vérifier que votre cluster et vos nœuds de travail s'exécutent en mode IPVS en exécutant la commande suivante sur l'un de vos nœuds de travail.
```
sudo ipvsadm -L
```
Au minimum, vous devriez voir un résultat similaire à celui ci-dessous, affichant les entrées pour le service Kubernetes API Server à et le service CoreDNS à `10.100.0.1` l'adresse. `10.100.0.10`
```
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP ip-10-100-0-1.us-east-1. rr
-> ip-192-168-113-81.us-eas Masq 1 0 0
-> ip-192-168-162-166.us-ea Masq 1 1 0
TCP ip-10-100-0-10.us-east-1 rr
-> ip-192-168-104-215.us-ea Masq 1 0 0
-> ip-192-168-123-227.us-ea Masq 1 0 0
UDP ip-10-100-0-10.us-east-1 rr
-> ip-192-168-104-215.us-ea Masq 1 0 0
-> ip-192-168-123-227.us-ea Masq 1 0 0
```
**Note**
Cet exemple de sortie provient d'un cluster EKS dont la plage d'adresses IP de service est de`10.100.0.0/16`.