Utilisation du module complémentaire Kubernetes kube-proxy

Important

Nous recommandons d'ajouter le type Amazon EKS du module complémentaire à votre cluster au lieu d'utiliser le type autogéré du module complémentaire. Si la différence entre les types ne vous est pas familière, consultez Modules complémentaires Amazon EKS. Pour plus d'informations sur l'ajout d'un module complémentaire Amazon EKS à votre cluster, consultez Création d'un module complémentaire. Si vous ne parvenez pas à utiliser le module complémentaire Amazon EKS, nous vous encourageons à signaler les raisons pour lesquelles vous ne pouvez pas utiliser le module complémentaire Amazon EKS dans le GitHub référentiel de feuilles de route pour les conteneurs.

Le module complémentaire kube-proxy est déployé sur chaque nœud Amazon EC2 de votre cluster Amazon EKS. Il maintient les règles du réseau sur vos nœuds et permet la communication du réseau à vos Pods. Le module complémentaire n'est pas déployé sur les nœuds Fargate de votre cluster. Pour plus d'informations, consultez la section kube-proxydans la documentation Kubernetes.

Le tableau suivant répertorie la dernière version du module complémentaire Amazon EKS pour chaque version de Kubernetes.

Version de Kubernetes	1.29	1.28	1.27	1.26	1.25	1.24	1.23
	v1.29.1-eksbuild.2	v1.28.6-eksbuild.2	v1.27.10-eksbuild.2	v1.26.13-eksbuild.2	v1.25.16-eksbuild.3	v1.24.17-eksbuild.8	v1.23.17-eksbuild.9

Important

Une version antérieure de la documentation était incorrecte. kube-proxyversions v1.28.5v1.27.9, et v1.26.12 ne sont pas disponibles.

Si vous gérez vous-même ce module complémentaire, les versions répertoriées dans le tableau peuvent ne pas être les mêmes que les versions autogérées disponibles.

Il existe deux types d'images de conteneur kube-proxy disponibles pour chaque version de cluster Amazon EKS :

• Default (Par défaut) : cette image est basée sur une image Docker basée sur Debian qui est gérée par la communauté Kubernetes en amont.

• Minimal (Minimale) : cette image est basée sur une image de base minimale gérée par Amazon EKS Distro, qui contient un package minimum sans aucun Shell. Pour plus d'informations, consultez Amazon EKS Distro.

Dernière version disponible d'image de conteneur kube-proxy autogéré pour chaque version de cluster Amazon EKS
Type d’image	1.29	1.28	1.27	1.26	1.25	1.24	1.23
kube-proxy (type par défaut)	Seul le type minimal est disponible	Seul le type minimal est disponible	Seul le type minimal est disponible	Seul le type minimal est disponible	Seul le type minimal est disponible	v1.24.10-eksbuild.2	v1.23.16-eksbuild.2
kube-proxy (type minimal)	v1.29.1-minimal-eksbuild.2	v1.28.6-minimal-eksbuild.2	v1.27.10-minimal-eksbuild.2	v1.26.13-minimal-eksbuild.2	v1.25.16-minimal-eksbuild.3	v1.24.17-minimal-eksbuild.4	v1.23.17-minimal-eksbuild.5

Important

• Le type d'image par défaut n'est pas disponible pour Kubernetes version 1.25 et versions ultérieures. Vous devez utiliser le type d'image minimal.

• Lorsque vous mettez à jour un type de module complémentaire Amazon EKS, vous spécifiez une version valide du module complémentaire Amazon EKS, qui peut ne pas être répertoriée dans ce tableau. Cela est dû au fait que les versions du module complémentaire Amazon EKS ne correspondent pas toujours aux versions d'image de conteneur spécifiées lors de la mise à jour du type autogéré de ce module complémentaire. Lorsque vous mettez à jour le type autogéré de ce module complémentaire, vous spécifiez une version d'image de conteneur valide répertoriée dans ce tableau.

Prérequis

• Un cluster Amazon EKS existant. Pour en déployer un, consultez Démarrer avec Amazon EKS.

Considérations

• Kube-proxy sur un cluster Amazon EKS possède la même politique de compatibilité et d'inclinaison que Kubernetes. Découvrez comment Récupérez la compatibilité des versions de l'addon.

• Kube-proxy doit correspondre à la même version mineure que kubelet sur vos nœuds Amazon EC2.

• Kube-proxy ne peut pas être postérieur à la version mineure du plan de contrôle de votre cluster.

• Si vous avez récemment mis à jour votre cluster vers une nouvelle version mineure de Kubernetes, mettez alors à jour vos nœuds Amazon EC2 vers la même version mineure avant de mettre à jour kube-proxy vers la même version mineure que vos nœuds.

Mise à jour du module complémentaire autogéré kube-proxy

1. Vérifiez que le type autogéré du module complémentaire est installé sur votre cluster. Remplacez my-cluster par le nom de votre cluster.

   aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output text
   

   Si un message d'erreur est renvoyé, le type autogéré du module complémentaire est installé sur votre cluster. Les étapes restantes de cette rubrique concernent la mise à jour du type autogéré du module complémentaire. Si un numéro de version est renvoyé, le type de module complémentaire Amazon EKS est installé sur votre cluster. Pour le mettre à jour, utilisez la procédure décrite dans Mise à jour d'un module complémentaire, plutôt que celle décrite dans cette rubrique. Si les différences entre les types de modules complémentaires ne vous sont pas familières, consultez Modules complémentaires Amazon EKS.

2. Découvrez quelle version de l'image de conteneur est actuellement installée sur votre cluster.

   kubectl describe daemonset kube-proxy -n kube-system | grep Image
   

   L'exemple qui suit illustre un résultat.

   Image:    602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.25.6-minimal-eksbuild.2

   Dans l'exemple de sortie, v1.25.6-minimal-eksbuild.2 est la version installée sur le cluster.

3. Mettez à jour le module complémentaire kube-proxy en remplaçant 602401143452 et region-code par les valeurs de votre sortie à l'étape précédente. Remplacez v1.26.2-minimal-eksbuild.2 par la version de kube-proxy répertoriée dans le tableau Dernière version d'image de conteneur kube-proxy disponible pour chaque version de cluster Amazon EKS. Vous pouvez spécifier un numéro de version pour la version par défautou le type minimal d'image.

   kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.26.2-minimal-eksbuild.2
   

   L'exemple qui suit illustre un résultat.

   daemonset.apps/kube-proxy image updated

4. Vérifiez que la nouvelle version est maintenant installée sur votre cluster.

   kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3
   

   L'exemple qui suit illustre un résultat.

   v1.26.2-minimal-eksbuild.2

5. Si vous utilisez des nœuds x86 et Arm dans le même cluster et que votre cluster a été déployé avant le 17 août 2020. Ensuite, modifiez votre manifeste kube-proxy pour inclure un sélecteur de noeud pour plusieurs architectures matérielles avec la commande suivante. Il s'agit d'une opération ponctuelle. Une fois que vous avez ajouté le sélecteur à votre manifeste, vous n'avez pas besoin de l'ajouter chaque fois que vous mettez à jour le module complémentaire. Si votre cluster a été déployé à partir du 17 août 2020, kube-proxy est déjà compatible avec les architectures multiples.

   kubectl edit -n kube-system daemonset/kube-proxy
   

   Ajoutez le sélecteur de nœuds suivant au fichier dans l'éditeur, puis enregistrez le fichier. Pour obtenir un exemple d'inclusion de ce texte dans l'éditeur, consultez le fichier manifeste CNI sur GitHub. Cela permet à Kubernetes d'extraire l'image matérielle correcte en fonction de l'architecture matérielle du nœud.

   - key: "kubernetes.io/arch"
     operator: In
     values:
     - amd64
     - arm64

6. Si votre cluster a été créé à l'origine avec Kubernetes version 1.14 ou ultérieure, vous pouvez ignorer cette étape, car kube-proxy inclut déjà cette Affinity Rule. Si vous avez créé à l'origine un cluster Amazon EKS avec Kubernetes version 1.13 ou antérieure et que vous avez l'intention d'utiliser des nœuds Fargate dans votre cluster, modifiez votre manifeste kube-proxy pour y inclure une règle NodeAffinity empêchant les Pods kube-proxy de se programmer sur les nœuds Fargate. Il s'agit d'une modification unique. Une fois que vous avez ajouté Affinity Rule à votre manifeste, vous n'avez pas besoin de l'ajouter chaque fois que vous mettez à niveau votre cluster. Modifiez votre DaemonSet kube-proxy.

   kubectl edit -n kube-system daemonset/kube-proxy
   

   Ajoutez la commande Affinity Rule ci-après à la section DaemonSetspec du fichier dans l'éditeur, puis enregistrez le fichier. Pour obtenir un exemple d'inclusion de ce texte dans l'éditeur, consultez le fichier manifeste CNI sur GitHub.

   - key: eks.amazonaws.com/compute-type
     operator: NotIn
     values:
     - fargate