Get Hands-on with Amazon EKS - Workshop Event Series
Whether you're taking your first steps with Kubernetes or you're an experienced practitioner looking to sharpen your skills, our Amazon EKS workshop series delivers practical, real-world experience that moves you forward. Learn directly from AWS solutions architects and EKS specialists through hands-on sessions designed to build your confidence with Kubernetes. Register now and start building with Amazon EKS!
Comment utiliser plusieurs plages d’adresses CIDR avec Amazon EKS ?
Je souhaite utiliser plusieurs plages d’adresses CIDR avec Amazon Elastic Kubernetes Service (Amazon EKS) pour résoudre les problèmes liés à mes pods.
Brève description
Pour utiliser plusieurs plages d’adresses CIDR dans Amazon EKS, procédez comme suit :
- Ajoutez des plages CIDR supplémentaires pour étendre votre réseau de cloud privé virtuel (VPC).
- Créez des sous-réseaux avec une nouvelle plage d’adresses CIDR.
- Associez votre nouveau sous-réseau à une table de routage.
- Configurez le plugin Amazon Container Network Interface (CNI) Virtual Private Cloud (Amazon VPC) pour utiliser une nouvelle plage d'adresses CIDR.
Remarque : Il est recommandé d'utiliser les CIDR (/16) depuis l'espace NAT (CGN) de niveau opérateur, par exemple 100.64.0.0/10 ou 198.19.0.0/16. Vous pouvez utiliser une plage VPC valide comme plage d’adresses CIDR secondaire dans les réseaux personnalisés. Cependant, ces plages sont moins susceptibles d'être utilisées dans le cadre d'une entreprise. Pour plus d'informations sur les exigences réseau personnalisées, consultez la section Considérations.
Résolution
Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'interface.
Prérequis : Vous devez disposer des configurations suivantes :
- Un cluster Amazon EKS en cours d’exécution
- Autorisations de Gestion des identités et des accès AWS (AWS IAM) pour gérer un Amazon VPC
- Un kubectl disposant des autorisations nécessaires pour créer des ressources personnalisées et modifier le DaemonSet
- Une version installée de jq sur votre système
Remarque : Pour télécharger et installer jq, consultez la page Télécharger jq sur le site Web de jq. - Un système basé sur Unix avec un shell Bash
- Un VPC configuré
Ajouter des plages d’adresses CIDR supplémentaires pour étendre votre réseau VPC
Procédez comme suit :
- Pour récupérer l'ID de votre VPC de cluster et le stocker dans une variable, exécutez la commande describe-cluster de l'AWS CLI suivante :
Remarque : Remplacez CLUSTER_NAME par le nom de votre cluster et REGION_CODE par la région AWS dans laquelle vous avez déployé le cluster.VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text) - Pour associer un autre bloc d’adresses CIDR à la plage 100.64.0.0/16 au VPC, exécutez la commande associate-vpc-cidr-block suivante :
aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16
Créer des sous-réseaux avec une nouvelle plage d’adresses CIDR
Procédez comme suit :
- Pour répertorier toutes les zones de disponibilité de votre région, exécutez la commande describe-availability-zones suivante :
Remarque : Remplacez REGION_CODE par la région dans laquelle vous avez déployé vos ressources.aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName' - Créez les sous-réseaux que vous souhaitez utiliser dans chaque zone de disponibilité dans laquelle se trouvent vos sous-réseaux existants. Exécutez les commandes create-subnet suivantes pour créer de nouveaux sous-réseaux sous le VPC avec la nouvelle plage d’adresses CIDR.
Remarque : Remplacez AZ1, AZ2 et AZ3 par les zones de disponibilité de vos sous-réseaux existantes.CUST_SNET1=$(aws ec2 create-subnet --cidr-block 100.64.0.0/19 --vpc-id $VPC_ID --availability-zone AZ1 | jq -r .Subnet.SubnetId) CUST_SNET2=$(aws ec2 create-subnet --cidr-block 100.64.32.0/19 --vpc-id $VPC_ID --availability-zone AZ2 | jq -r .Subnet.SubnetId) CUST_SNET3=$(aws ec2 create-subnet --cidr-block 100.64.64.0/19 --vpc-id $VPC_ID --availability-zone AZ3 | jq -r .Subnet.SubnetId) - (Facultatif) Pour définir une paire clé-valeur afin d'ajouter une identification de nom à vos sous-réseaux, exécutez la commande create-tags suivante :
Remarque : Remplacez KEY par la clé de l’identification et VALUE par la valeur de l’identification.aws ec2 create-tags --resources $CUST_SNET1 --tags Key=KEY,Value=VALUE aws ec2 create-tags --resources $CUST_SNET2 --tags Key=KEY,Value=VALUE aws ec2 create-tags --resources $CUST_SNET3 --tags Key=KEY,Value=VALUE
Associer votre nouveau sous-réseau à une table de routage
Par défaut, Amazon VPC associe vos nouveaux sous-réseaux à la table de routage principale de votre VPC. Cette table de routage autorise la communication uniquement entre les ressources déployées dans le VPC. Pour autoriser la communication avec des adresses IP situées en dehors des blocs d’adresses CIDR du VPC, vous devez créer votre propre table de routage pour vos sous-réseaux.
Configurer le plugin CNI pour utiliser la nouvelle plage d’adresses CIDR
Procédez comme suit :
-
Assurez-vous d'exécuter la version de plugin appropriée pour votre version de Kubernetes. Pour vérifier la version, exécutez la commande suivante :
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2Si vous ne disposez pas de la version de plugin appropriée, mettez à jour le CNI Amazon VPC.
-
Pour activer la configuration réseau personnalisée pour le plugin CNI Amazon VPC, exécutez la commande suivante :
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true -
Exécutez la commande suivante pour ajouter l’étiquette ENIConfig afin d’identifier vos composants master :
kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone -
Pour créer des ressources personnalisées ENIConfig pour l’ensemble des sous-réseaux et zones de disponibilité, exécutez les commandes suivantes :
cat <<EOF | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ1 spec: securityGroups: - cluster_security_group_id subnet: $CUST_SNET1 EOF cat <<EOF | kubectl apply -f - apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ2 spec: securityGroups: - cluster_security_group_id subnet: $CUST_SNET2 EOF cat <<EOF | kubectl apply -f - apiVersion: crd.k8s.amazonaws.com/v1alpha1 kind: ENIConfig metadata: name: $AZ3 spec: securityGroups: - cluster_security_group_id subnet: $CUST_SNET3 EOFRemarque : Remplacez cluster_security_group_id par l'ID du groupe de sécurité existant que vous souhaitez utiliser pour chaque ressource ENIConfig. Les noms des ressources ENIConfig sont les mêmes que ceux de la zone de disponibilité dans laquelle vous avez créé les nouveaux sous-réseaux.
-
Si vous utilisez un groupe de nœuds autogérés, lancez des composants master autogérés pour permettre au plugin de leur attribuer des adresses IP. Dans Sous-réseaux, utilisez les sous-réseaux d'origine que vous avez choisis lors de la création du cluster plutôt que les nouveaux sous-réseaux que vous avez utilisés dans les ressources ENIConfig. Vous pouvez également utiliser un groupe de nœuds gérés avec un modèle de lancement pour lancer des nœuds. Dans les deux cas, vous devez identifier la valeur correcte de max-pods pour votre type d'instance. Cela est dû au fait que la mise en réseau personnalisée dans Amazon EKS n'utilise pas l'interface réseau principale pour le placement des pods. Assurez-vous d'ajouter le paramètre --cni-custom-networking-enabled lorsque vous exécutez le script max-pods-calculator.sh.
Puis, exécutez la commande suivante pour spécifier la valeur de max-pods pour vos nœuds autogérés :--use-max-pods false --kubelet-extra-args '--max-pods=20'Remarque : Remplacez 20 par la valeur de max-pods que vous avez calculée.
Pour un groupe de nœuds gérés, ajoutez le script suivant aux données utilisateur :#!/bin/bash /etc/eks/bootstrap.sh my-cluster-name --use-max-pods false --kubelet-extra-args '--max-pods=20'Remarque : Remplacez my-cluster-name par le nom de votre cluster et 20 par la valeur de max-pods que vous avez calculée. Dans votre modèle de lancement, spécifiez un ID d’Amazon Machine Image (AMI) optimisée pour Amazon EKS ou une AMI personnalisée construite à partir de l'AMI optimisée pour Amazon EKS. Les AMI Amazon Linux 2023 (AL2023) utilisent le processus nodeadm. Pour plus d'informations sur la manière dont la configuration des données utilisateur s’en trouve affectée, consultez la section Mise à niveau d'Amazon Linux 2 vers Amazon Linux 2023.
Si vous utilisez un groupe de nœuds gérés sans modèle de lancement ni ID d’AMI spécifié, le groupe de nœuds gérés calcule automatiquement la valeur de max-pods. -
Une fois que les nouveaux nœuds sont prêts, videz les nœuds précédents pour arrêter correctement les pods. Pour plus d'informations, consultez la page Drainer un nœud en toute sécurité sur le site Web de Kubernetes. Si les nœuds font partie d'un groupe de nœuds gérés existant, exécutez la commande suivante pour supprimer le groupe de nœuds :
aws eks delete-nodegroup --cluster-name CLUSTER_NAME --nodegroup-name my-nodegroupRemarque : Remplacez CLUSTER_NAME par le nom de votre cluster et my-nodegroup par le nom de votre groupe de nœuds.
-
Pour lancer un nouveau déploiement afin de tester la configuration, exécutez la commande suivante :
kubectl create deployment nginx-test --image=nginx --replicas=10 kubectl get pods -o wide --selector=app=nginx-testRemarque : La commande précédente ajoute 10 nouveaux pods et les planifie sur la nouvelle plage d’adresses CIDR sur de nouveaux composants master.
Important : Un cluster peut mettre jusqu'à 5 heures pour reconnaître et autoriser un nouveau bloc d’adresses CIDR que vous associez à un VPC. Pendant cette période, le plan de contrôle Amazon EKS ne peut pas communiquer avec les pods que vous lancez dans les nouveaux sous-réseaux. Si api-server contacte les pods à l'aide d'un webhook, d'une commande kubectl logs ou d'une commande kubectl exec, le message d'erreur suivant peut s'afficher :
"failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=10s": Address is not allowed"
- Sujets
- Containers
- Langue
- Français

Contenus pertinents
- demandé il y a 2 ans
- demandé il y a 3 ans
- demandé il y a 3 ans
- demandé il y a 4 mois
AWS OFFICIELA mis à jour il y a 7 mois
AWS OFFICIELA mis à jour il y a 2 ans