Comment puis-je 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 EKSen cours d'exécution
• Accès à une version (non antérieure à 1.16 284) de l'interface de ligne de commande AWS (AWS CLI)
• Autorisations AWS Identity and Access Management (IAM) pour gérer un Amazon VPC
• Un kubectl avec des autorisations pour créer des ressources personnalisées et modifier le DaemonsSet
• Une version installée de jq (à partir du site jq) sur votre système
• Un système Unix avec un shell Bash

Gardez à l'esprit les points suivants :

• 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 scénarios avec traduction d'adresses réseau (NAT) de niveau opérateur, 100.64.0.0/10 est une plage de réseau privé. Cette plage de réseau privé est utilisée dans l'espace d'adresses partagées pour les communications entre un fournisseur de services et ses abonnés. Vous devez avoir une passerelle NAT configurée dans la table de routage pour que les pods puissent communiquer avec Internet. Les daemonsets ne sont pas pris en charge sur les clusters AWS Fargate. Pour ajouter des plages d'adresses CIDR secondaires à des profils Fargate, utilisez des sous-réseaux à partir de blocs d'adresses CIDR secondaires de votre VPC. Ensuite, balisez vos nouveaux sous-réseaux avant de les ajouter à votre profil Fargate.

Important : dans certaines cas, Amazon EKS ne peut pas communiquer avec les nœuds lancés dans les sous-réseaux à partir de blocs d'adresses CIDR supplémentaires ajoutés à un VPC après la création d'un cluster. Une plage mise à jour provoquée par l'ajout de blocs d'adresse CIDR à un cluster existant peut prendre jusqu'à cinq heures pour apparaître.

Solution

Remarque : si vous recevez des erreurs lors de l'exécution des commandes AWS CLI, vérifiez que vous utilisez la version AWS CLI la plus récente.

Dans la résolution suivante, configurez d'abord votre VPC. Configurez ensuite le plug-in CNI pour utiliser une nouvelle plage d'adresses CIDR.

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

1.    Trouvez vos VPC.

Si vos VPC ont une balise, exécutez la commande suivante pour les trouver :

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

Si vos VPC n'ont pas de balise, 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 attacher votre VPC à une variable VPC_ID exécutez la commande suivante :

export VPC_ID=vpc-xxxxxxxxxxxx

3.    Pour associer un bloc d'adresse CIDR supplémentaire de 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éer des sous-réseaux avec une nouvelle plage d'adresses CIDR

1.    Pour répertorier toutes les zones de disponibilité de votre région AWS, exécutez la commande suivante :

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

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

2.    Choisissez la zone de disponibilité dans laquelle vous souhaitez ajouter les sous-réseaux, puis attribuez ces zones de disponibilité aux variables. Par exemple :

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

Remarque : vous pouvez ajouter d'autres zones de disponibilité en créant d'autres variables.

3.    Pour créer de nouveaux sous-réseaux sous le VPC avec la nouvelle plage d'adresses CIDR, exécutez les commandes suivantes :

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)

Baliser les nouveaux sous-réseaux

Pour les clusters exécutés sur Kubernetes 1.18 et les versions antérieures, vous devez baliser tous les sous-réseaux afin qu'Amazon EKS puisse découvrir les sous-réseaux.

Remarque : Amazon EKS prend en charge la découverte automatique de sous-réseaux sans balises kubernetes.io à partir de la version 1.19 de Kubernetes. Pour plus d'informations, consultez le journal des modifications sur le site GitHub de Kubernetes.

1.    (Facultatif) Ajoutez une balise de nom pour vos sous-réseaux en définissant une paire clé-valeur. Par 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

2.    Pour les clusters exécutés sur Kubernetes 1.18 et les versions antérieures, balisez le sous-réseau à des fins de découverte par Amazon EKS. Par exemple :

aws ec2 create-tags --resources $CUST_SNET1 --tags Key=kubernetes.io/cluster/yourClusterName,Value=shared
aws ec2 create-tags --resources $CUST_SNET2 --tags Key=kubernetes.io/cluster/yourClusterName,Value=shared
aws ec2 create-tags --resources $CUST_SNET3 --tags Key=kubernetes.io/cluster/yourClusterName,Value=shared

Remarque : remplacez yourClusterName par le nom de votre cluster Amazon EKS.

Si vous envisagez d'utiliser Elastic Load Balancing, pensez à ajouter des identifications supplémentaires.

Associer votre nouveau sous-réseau à une table de routage

1.    Pour répertorier la totalité de la table de routage sous le VPC, exécutez la commande suivante :

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

2.    Pour la table de routage que vous souhaitez associer à votre sous-réseau, exécutez la commande suivante pour exporter vers la variable. Remplacez ensuite rtb-xxxxxxxxx par les valeurs de l'étape 1 :

export RTASSOC_ID=rtb-xxxxxxxxx

3.    Associez la table de routage à tous les nouveaux sous-réseaux. Par 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 plus d’informations, consultez Routage.

Configurer le plug-in CNI pour utiliser la nouvelle plage d'adresses CIDR

1.    Assurez-vous que la dernière version recommandée du plugin vpc-cni est en cours d'exécution dans le cluster.
Pour vérifier la version qui s'exécute dans le cluster, exécutez la commande suivante :

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

Pour vérifier la dernière version recommandée de vpc-cni et mettre à jour le plug-in si nécessaire, consultez la section Mise à jour du module complémentaire Amazon VPC CNI pour Kubernetes.

2.    Pour activer la configuration réseau personnalisée pour le plug-in CNI, exécutez la commande suivante :

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

3.    Pour ajouter l'étiquette ENIConfig afin d'identifier vos nœuds de travail, exécutez la commande suivante :

kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=failure-domain.beta.kubernetes.io/zone

4.    Pour créer une ressource personnalisée ENIConfig pour l'ensemble des sous-réseaux et des 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:
  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 : ENIConfig doit correspondre à la zone de disponibilité de vos nœuds de travail.

5.    Lancez les nouveaux composants master.

Remarque : cette étape permet au plug-in CNI (ipamd) d'allouer des adresses IP à partir de la nouvelle plage d'adresses CIDR sur les nouveaux composants master.

Quand vous utilisez un réseau personnalisé, l'interface réseau principale n'est pas utilisée pour le placement de pod. Dans ce cas, vous devez d'abord mettre à jour max-pods à l'aide de la formule suivante :

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

• Pour un groupe de nœuds autogérés : déployez le groupe de nœuds en suivant les instructions de la section Lancement de nœuds Amazon Linux autogérés. Ne spécifiez pas les sous-réseaux que vous avez utilisés dans les ressources ENIConfig que vous avez déployées. Spécifiez plutôt le texte suivant pour le paramètre BootstrapArguments :

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

• Pour un groupe de nœuds gérés sans modèle de lancement ou avec un modèle de lancement sans ID d'AMI spécifié : les groupes de nœuds gérés calculent automatiquement la valeur maximale de pods recommandée par Amazon EKS. Suivez les étapes décrites dans la section Création d'un groupe de nœuds géré. Vous pouvez également utiliser l'interface de ligne de commande Amazon EKS pour créer le groupe de nœuds géré :

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>

Remarque : pour le champ de sous-réseau, ne spécifiez pas les sous-réseaux que vous avez définis dans les ressources ENIConfig. D'autres options peuvent être spécifiées si nécessaire.

• Si vous créez un groupe de nœuds gérés avec un modèle de lancement avec un ID d'AMI spécifié, fournissez l'argument supplémentaire **« --max-pods=

»** en tant que données utilisateur dans le modèle de lancement. Dans votre modèle de lancement, spécifiez un ID d'AMI optimisée pour Amazon EKS ou une AMI personnalisée créée à partir de l'AMI optimisée pour Amazon EKS. Déployez ensuite le groupe de nœuds à l'aide d'un modèle de lancement 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'>

6.    Après avoir créé votre groupe de nœuds, notez le groupe de sécurité du sous-réseau et appliquez le groupe de sécurité à l'ENIConfig associé.

Dans l'exemple suivant, remplacez sg-xxxxxxxxxxxx par votre groupe de sécurité.

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

7.    Résiliez les anciens composants master. Puis, testez la configuration en lançant un nouveau déploiement. Dix nouveaux pods ont été ajoutés et la nouvelle plage d'adresses CIDR est planifiée sur les nouveaux composants master :

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

---