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

Brève description

Avant de suivre les étapes de la section Résolution, vérifiez que vous disposez des éléments suivants :

• Un cluster Amazon EKS en cours d’exécution
• La dernière version de l’interface de la ligne de commande AWS (AWS CLI)
• Autorisations Gestion des identités et des accès AWS (AWS IAM) pour gérer un Virtual Private Cloud (VPC) Amazon
• Un kubectl disposant des autorisations nécessaires pour créer des ressources personnalisées et modifier le DaemonsSet
• Une version installée de jq sur votre système
  Remarque : pour télécharger et installer jq, consultez la section Download jq sur le site Web de jq. 
• Un système basé sur Unix avec un shell Bash
• Un VPC déjà configuré

Remarque :

• Vous pouvez associer des blocs d’adresse CIDR privés (RFC 1918) et publics (non-RFC 1918) à votre VPC avant ou après la création de votre cluster.
• Dans les cas qui utilisent une traduction d’adresses réseau (NAT) de niveau opérateur, 100.64.0.0/10 est une plage de réseau privé. La plage de réseau privé est utilisée dans l’espace d’adressage partagé pour les communications entre le fournisseur de services et ses abonnés. Pour que les pods puissent communiquer avec Internet, vous devez disposer d’une passerelle NAT configurée au niveau de la table de routage. Les clusters AWS Fargate ne prennent pas en charge les DaemonSets. Pour ajouter des plages d’adresses CIDR secondaires aux profils Fargate, utilisez les sous-réseaux des blocs d’adresse CIDR secondaires de votre VPC. Veillez ensuite à ajouter des balises à vos nouveaux sous-réseaux avant de les incorporer à votre profil Fargate.

Important : dans certains cas, Amazon EKS ne peut pas communiquer avec les nœuds que vous lancez dans des sous-réseaux à partir de blocs d’adresse CIDR ajoutés à un VPC après la création d’un cluster. Lorsque vous ajoutez des blocs d’adresse CIDR à un cluster existant, la plage mise à jour peut prendre jusqu’à 5 heures pour s’afficher.

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 page Résoudre les erreurs liées à AWS CLI. Vérifiez également que vous utilisez la version la plus récente de l’AWS CLI.

La résolution suivante nécessite que vous configuriez d’abord votre VPC. Vous devez ensuite configurer le plugin CNI pour utiliser une nouvelle plage d’adresses CIDR.

Ajout de plages d’adresses CIDR supplémentaires pour étendre votre réseau VPC

Procédez comme suit :

1. Identifiez vos VPC.
   Si vos VPC disposent d’une balise, exécutez la commande suivante pour les identifier :

   VPC_ID=$(aws ec2 describe-vpcs --filters Name=tag:Name,Values=yourVPCName | jq -r '.Vpcs[].VpcId')

   Dans le cas contraire, exécutez la commande suivante pour répertorier tous les VPC de votre région AWS :

   aws ec2 describe-vpcs --filters  | jq -r '.Vpcs[].VpcId'

2. Pour associer votre VPC à une variable VPC_ID, exécutez la commande suivante :

   export VPC_ID=vpc-xxxxxxxxxxxx

   Pour associer un autre bloc d’adresse CIDR avec la plage 100.64.0.0/16 au VPC, exécutez la commande suivante :

   aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16

Création de 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 suivante :

   aws ec2 describe-availability-zones --region us-east-1 --query 'AvailabilityZones[*].ZoneName'

   Remarque : remplacez us-east-1 par votre région.

2. Choisissez la zone de disponibilité dans laquelle vous souhaitez ajouter les sous-réseaux, puis attribuez cette zone de disponibilité à une variable. Exemple :

   export AZ1=us-east-1a
   export AZ2=us-east-1b
   export AZ3=us-east-1c

   Remarque : pour pouvoir ajouter d’autres zones de disponibilité, vous devez créer des variables supplémentaires.

3. Exécutez les commandes 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)

4. (Facultatif) Définissez une paire clé-valeur pour ajouter une balise nominative à vos sous-réseaux. Exemple :

   aws ec2 create-tags --resources $CUST_SNET1 --tags Key=Name,Value=SubnetA
   aws ec2 create-tags --resources $CUST_SNET2 --tags Key=Name,Value=SubnetB
   aws ec2 create-tags --resources $CUST_SNET3 --tags Key=Name,Value=SubnetC

Association du nouveau sous-réseau à une table de routage

Procédez comme suit :

1. Exécutez la commande suivante pour répertorier l’intégralité de la table de routage sous le VPC :

   aws ec2 describe-route-tables --filters Name=vpc-id,Values=$VPC_ID |jq -r '.RouteTables[].RouteTableId'

2. Exécutez la commande suivante pour exporter la table de routage vers la variable :

   export RTASSOC_ID=rtb-abcabcabc

   Remarque : remplacez rtb-abcabcabc par les valeurs de l’étape précédente.

3. Associez la table de routage à tous les nouveaux sous-réseaux. Exemple :

   aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET1
   aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET2
   aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET3

   Pour en savoir plus, reportez-vous à la section Routage de la page Exemple : VPC avec des serveurs dans des sous-réseaux privés et NAT.

Configuration du plugin CNI pour utiliser la nouvelle plage d’adresses CIDR

Procédez comme suit :

1. Ajoutez la dernière version du plugin vpc-cni au cluster. Exécutez la commande suivante pour vérifier la version présente dans le cluster :

   kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

   Exécutez la commande suivante pour activer la configuration réseau personnalisée pour le plug-in CNI :

   kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

2. 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=failure-domain.beta.kubernetes.io/zone

3. Exécutez les commandes suivantes pour créer une ressource personnalisée ENIConfig pour l’ensemble des sous-réseaux et zones de disponibilité :

   cat <<EOF  | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ1
   spec:
     subnet: $CUST_SNET1
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ2
   spec:
     subnet: $CUST_SNET2
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ3
   spec:
     subnet: $CUST_SNET3
   EOF

   Remarque : la ressource ENIConfig doit correspondre à la zone de disponibilité de vos composants master.

4. Lancez les composants master afin que le plug-in CNI (ipamd) puisse attribuer les adresses IP de la nouvelle plage d’adresses CIDR aux nouveaux composants master.
   Si vous utilisez un réseau personnalisé, l’interface réseau principale ne sera pas utilisée pour le placement des pods. Dans ce cas, vous devez commencer par mettre à jour le paramètre max-pods à l’aide de la formule suivante :

   maxPods = (number of interfaces - 1) \* (max IPv4 addresses per interface - 1) + 2

   Si vous utilisez un groupe de nœuds autogérés, suivez les étapes de la page Lancement de nœuds Amazon Linux autogérés. Il ne faut pas spécifier les sous-réseaux utilisés dans les ressources ENIConfig. Utilisez à la place les spécifications suivantes pour le paramètre BootstrapArguments :

   --use-max-pods false --kubelet-extra-args '--max-pods=<20>'

   Si vous utilisez un groupe de nœuds gérés sans modèle de lancement ni ID d’Amazon Machine Image (AMI) spécifié, les groupes de nœuds gérés calculeront automatiquement la valeur maximale des pods. Suivez les étapes de la page Création d’un groupe de nœuds gérés. Vous pouvez également utiliser l’interface de ligne de commande Amazon EKS pour créer le groupe de nœuds gérés :

   aws eks create-nodegroup --cluster-name <sample-cluster-name> --nodegroup-name <sample-nodegroup-name> --subnets <subnet-123 subnet-456> --node-role <arn:aws:iam::123456789012:role/SampleNodeRole>

   Si vous utilisez un modèle de lancement de groupe de nœuds gérés avec un ID d’AMI spécifié, vous devez spécifier un ID d’AMI optimisée pour Amazon EKS dans votre modèle de lancement. Vous pouvez également utiliser une AMI personnalisée basée sur l’AMI optimisée pour Amazon EKS. Utilisez ensuite un modèle de lancement pour déployer le groupe de nœuds et fournissez les données utilisateur suivantes dans le modèle de lancement :

   #!/bin/bash
   /etc/eks/bootstrap.sh <my-cluster-name> --kubelet-extra-args <'--max-pods=20'>

5. Notez le groupe de sécurité du sous-réseau et appliquez-le à la ressource ENIConfig associée :

   cat <<EOF  | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ1
   spec:
     securityGroups:
       - sg-xxxxxxxxxxxx
     subnet: $CUST_SNET1
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ2
   spec:
     securityGroups:
       - sg-xxxxxxxxxxxx
     subnet: $CUST_SNET2
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ3
   spec:
     securityGroups:
       - sg-xxxxxxxxxxxx
     subnet: $CUST_SNET3
   EOF

   Remarque : remplacez sg-xxxxxxxxxxxx par votre groupe de sécurité.

6. Résiliez les anciens composants master.

7. Lancez un nouveau déploiement pour tester la configuration :

   kubectl create deployment nginx-test --image=nginx --replicas=10   
   kubectl get pods -o wide --selector=app=nginx-test

   Remarque : dix nouveaux pods sont ajoutés lors du déploiement test présenté ci-dessus et la nouvelle plage de CIDR est planifiée sur de nouveaux composants master.