Passer au contenu

Comment utiliser plusieurs plages d’adresses CIDR avec Amazon EKS ?

Lecture de 8 minute(s)
0

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 :

  1. Ajoutez des plages CIDR supplémentaires pour étendre votre réseau de cloud privé virtuel (VPC).
  2. Créez des sous-réseaux avec une nouvelle plage d’adresses CIDR.
  3. Associez votre nouveau sous-réseau à une table de routage.
  4. 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 :

Ajouter des plages d’adresses CIDR supplémentaires pour étendre votre réseau VPC

Procédez comme suit :

  1. 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 :
    VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text)
    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.
  2. 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 :

  1. Pour répertorier toutes les zones de disponibilité de votre région, exécutez la commande describe-availability-zones suivante :
    aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName'
    Remarque : Remplacez REGION_CODE par la région dans laquelle vous avez déployé vos ressources.
  2. 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.
    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)
    Remarque : Remplacez AZ1, AZ2 et AZ3 par les zones de disponibilité de vos sous-réseaux existantes.
  3. (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 :
    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
    Remarque : Remplacez KEY par la clé de l’identification et VALUE par la valeur de l’identification.

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 :

  1. 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 2

    Si vous ne disposez pas de la version de plugin appropriée, mettez à jour le CNI Amazon VPC.

  2. 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
  3. 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
  4. 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
    EOF

    Remarque : 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.

  5. 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.

  6. 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-nodegroup

    Remarque : Remplacez CLUSTER_NAME par le nom de votre cluster et my-nodegroup par le nom de votre groupe de nœuds.

  7. 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-test

    Remarque : 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"

AWS OFFICIELA mis à jour il y a 7 mois