Augmenter le nombre d'adresses IP disponibles pour vos nœuds Amazon EC2 - Amazon EKS

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Augmenter le nombre d'adresses IP disponibles pour vos nœuds Amazon EC2

Chaque instance Amazon EC2 prend en charge un nombre maximum d'interfaces réseau élastiques et un nombre maximum d'adresses IP pouvant être attribuées à chaque interface réseau. Chaque nœud a besoin d'une adresse IP pour chaque interface réseau. Toutes les autres adresses IP disponibles peuvent être attribuées aux Pods. Chaque Pod a besoin de sa propre adresse IP. Par conséquent, vous pouvez avoir des nœuds qui disposent de ressources de calcul et de mémoire disponibles, mais qui ne peuvent pas accueillir d'autres Pods parce que le nœud n'a plus d'adresses IP à attribuer à Pods.

Dans cette rubrique, vous allez apprendre à augmenter de manière significative le nombre d'adresses IP que les nœuds peuvent attribuer à Pods en attribuant des préfixes IP, plutôt que d'attribuer des adresses IP secondaires individuelles à vos nœuds. Chaque préfixe inclut plusieurs adresses IP. Si vous ne configurez pas votre cluster pour l'attribution de préfixes IP, votre cluster doit effectuer davantage d'appels à l'interface de programmation d'applications (API) Amazon EC2 afin de configurer les interfaces réseau et les adresses IP nécessaires à la connectivité Pod. Au fur et à mesure que la taille des clusters augmente, la fréquence de ces appels d'API peut entraîner des temps de lancement de Pod et d'instances plus longs. Cela entraîne des retards de mise à l'échelle pour répondre à la demande d'applications volumineuses et épineuses, et ajoute des coûts et des frais généraux de gestion, car vous devez allouer des clusters et des VPC supplémentaires pour répondre aux exigences de mise à l'échelle. Pour plus d'informations, consultez la section Seuils Kubernetes d'évolutivité activés GitHub.

Considérations

  • Chaque type d'instance Amazon EC2 prend en charge un nombre maximum de Pods. Si votre groupe de nœuds gérés est composé de plusieurs types d'instance, le plus petit nombre de Pods maximum pour une instance dans le cluster est appliqué à tous les nœuds du cluster.

  • Par défaut, le nombre maximum de Pods que vous pouvez exécuter sur un nœud est de 110, mais vous pouvez modifier ce nombre. Si vous modifiez le numéro et que vous disposez d'un groupe de nœuds géré existant, la prochaine mise à jour d'AMI ou de modèle de lancement de votre groupe de nœuds entraînera la création de nouveaux nœuds avec la valeur modifiée.

  • Lorsque vous passez de l'attribution d'adresses IP à l'attribution de préfixes IP, nous vous recommandons de créer de nouveaux groupes de nœuds afin d'augmenter le nombre d'adresses IP disponibles, plutôt que de remplacer progressivement les nœuds existants. L'exécution Pods sur un nœud auquel des adresses IP et des préfixes ont été attribués peut entraîner des incohérences dans la capacité des adresses IP annoncée, ce qui a un impact sur les charges de travail futures sur le nœud. Pour connaître la méthode recommandée pour effectuer la transition, consultez Remplacer tous les nœuds lors de la migration du mode IP secondaire vers le mode Délégation de préfixe ou vice versa dans le guide des meilleures pratiques Amazon EKS.

  • Pour les clusters dotés de nœuds Linux uniquement.

    • Une fois que vous avez configuré le module complémentaire pour attribuer des préfixes aux interfaces réseau, vous ne pouvez pas rétrograder votre module complémentaire Amazon VPC CNI plugin for Kubernetes vers une version inférieure à 1.9.0 (ou 1.10.1) sans supprimer tous les nœuds de tous les groupes de nœuds de votre cluster.

    • Si vous utilisez également des groupes de sécurité pour Pods, avec POD_SECURITY_GROUP_ENFORCING_MODE = standard et AWS_VPC_K8S_CNI_EXTERNALSNAT =false, lorsque vos Pods communiquent avec des points de terminaison extérieurs à votre VPC, les groupes de sécurité du nœud sont utilisés, plutôt que les groupes de sécurité que vous avez attribués à vos Pods.

      Si vous utilisez également des groupes de sécurité pour Pods, avec POD_SECURITY_GROUP_ENFORCING_MODE =strict, lorsque vos Pods communiquent avec des points de terminaison extérieurs à votre VPC, les groupes de sécurité de Pod's sont utilisés.

Prérequis

  • Un cluster existant. Pour en déployer un, consultez Création d'un cluster Amazon EKS.

  • Les sous-réseaux dans lesquels se trouvent vos nœuds Amazon EKS doivent comporter suffisamment de blocs de routage inter-domaines sans classe (CIDR) contigus /28 (pour les clusters IPv4) ou /80 (pour les clusters IPv6). Vous ne pouvez avoir que des nœuds Linux dans un cluster IPv6. L'utilisation de préfixes IP peut échouer si les adresses IP sont dispersées dans le CIDR du sous-réseau. Nous vous recommandons la procédure suivante :

    • L'utilisation d'une réservation CIDR de sous-réseau afin que, même si des adresses IP comprises dans la plage réservée sont encore utilisées, elles ne soient pas réattribuées lors de leur libération. Cela permet de s'assurer que les préfixes sont disponibles pour l'allocation sans segmentation.

    • Utilisez de nouveaux sous-réseaux spécifiquement utilisés pour exécuter les charges de travail auxquelles les préfixes IP sont attribués. Les charges de travail Windows et Linux peuvent être exécutées dans le même sous-réseau lors de l'attribution des préfixes IP.

  • Pour attribuer des préfixes IP à vos nœuds, ceux-ci doivent être basés sur AWS Nitro. Les instances qui ne sont pas basées sur Nitro continuent d'allouer des adresses IP secondaires individuelles, mais ont un nombre nettement inférieur d'adresses IP à attribuer aux Pods par rapport aux instances Nitro-based.

  • Pour les clusters avec des nœuds Linux uniquement : si votre cluster est configuré pour la famille IPv4, la version 1.9.0 ou une version ultérieure du module complémentaire Amazon VPC CNI plugin for Kubernetes doit être installée. Vous pouvez vérifier votre version actuelle à l'aide de la commande suivante.

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

    Si votre cluster est configuré pour la famille IPv6, la version 1.10.1 du module complémentaire doit être installée. Si la version de votre plugin est antérieure aux versions requises, vous devez la mettre à jour. Pour en savoir plus, consultez les sections de mise à jour de Utilisation du module complémentaire Amazon VPC CNI plugin for Kubernetes Amazon EKS.

  • Pour les clusters avec des nœuds Windows uniquement

    • La version de votre cluster et de sa plateforme doit être égale ou ultérieure aux versions indiquées dans le tableau suivant. Pour mettre à jour la version de votre cluster, consultez Mettre à jour le cluster existant vers la nouvelle version de Kubernetes. Si votre cluster ne dispose pas de la version minimale de la plateforme, vous ne pouvez pas attribuer de préfixes IP à vos nœuds tant qu'Amazon EKS n'a pas mis à jour votre version de la plateforme.

      Version de Kubernetes Version de la plateforme
      1.27 eks.3
      1.26 eks.4
      1.25 eks.5

      Vous pouvez vérifier votre version actuelle de Kubernetes et de la plateforme en remplaçant my-cluster dans la commande suivante par le nom de votre cluster et en exécutant la commande modifiée : aws eks describe-cluster --name my-cluster --query 'cluster.{"Kubernetes Version": version, "Platform Version": platformVersion}'.

    • Prise en charge de Windows activée pour votre cluster. Pour plus d’informations, consultez Déployer Windows des nœuds sur des clusters EKS.

Pour augmenter le nombre d'adresses IP disponibles pour vos nœuds Amazon EC2

  1. Configurez votre cluster pour attribuer des préfixes d'adresses IP aux nœuds. Effectuez la procédure dans l'onglet correspondant au système d'exploitation de votre nœud.

    Linux

    1. Activez le paramètre pour affecter des préfixes aux interfaces réseau pour le processus CNI Amazon VPC DaemonSet. Lorsque vous déployez un cluster de version 1.21 ou ultérieure, la version 1.10.1 ou ultérieure du module complémentaire Amazon VPC CNI plugin for Kubernetes est déployée avec lui. Si vous avez créé le cluster avec la famille IPv6, ce paramètre a été réglé sur true par défaut. Si vous avez créé le cluster avec la famille IPv4, ce paramètre a été réglé sur false par défaut.

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

      Même si votre sous-réseau a des adresses IP disponibles, si le sous-réseau n'a pas de blocs contigus /28 disponibles, vous verrez le message d'erreur suivant dans les journaux Amazon VPC CNI plugin for Kubernetes.

      InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

      Cela peut se produire en raison de la fragmentation des adresses IP secondaires existantes réparties sur un sous-réseau. Pour résoudre cette erreur, créez un nouveau sous-réseau et lancez des Pods là-bas, ou utilisez une réservation CIDR de sous-réseau Amazon EC2 pour réserver de l'espace dans un sous-réseau à utiliser avec l'affectation de préfixe. Pour plus d'informations, consultez la section Réservations CIDR de sous-réseau dans le Guide de l'utilisateur Amazon VPC.

    2. Si vous prévoyez de déployer un groupe de nœuds gérés sans modèle de lancement ou avec un modèle de lancement dans lequel vous n'avez pas spécifié d'ID AMI, et si vous utilisez une version du Amazon VPC CNI plugin for Kubernetes égale ou supérieure aux versions répertoriées dans les prérequis, passez à l'étape suivante. Les groupes de nœuds gérés calculent automatiquement le nombre maximal de Pods pour vous.

      Si vous déployez un groupe de nœuds autogérés ou un groupe de nœuds gérés avec un modèle de lancement dans lequel vous avez spécifié un ID d'AMI, vous devez déterminer le nombre maximal de Pods recommandés par Amazon EKS pour vos nœuds. Suivez les instructions de la section Nombre maximal de Pods recommandé par Amazon EKS pour chaque type d'instance Amazon EC2, en ajoutant --cni-prefix-delegation-enabled à l'étape 3. Notez la sortie pour une utilisation ultérieure.

      Important

      Les groupes de nœuds gérés appliquent un nombre maximal sur la valeur de maxPods. Pour les instances avec moins de 30 vCPUs, le nombre maximum est 110 et pour toutes les autres instances, le nombre maximum est 250. Ce nombre maximal est appliqué que la délégation du préfixe soit activée ou non.

    3. Si vous utilisez un cluster 1.21 ou version ultérieure configuré pour IPv6, passez directement à l'étape suivante.

      Spécifiez les paramètres dans l'une des options suivantes. Pour déterminer l'option qui vous convient le mieux et la valeur à fournir, consultez WARM_PREFIX_TARGET, WARM_IP_TARGET et MINIMUM_IP_TARGET sur GitHub.

      Vous pouvez remplacer les example values par une valeur supérieure à zéro.

      • WARM_PREFIX_TARGET 

        kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1

      • WARM_IP_TARGET ou MINIMUM_IP_TARGET : si l'une ou l'autre des valeurs est définie, elle remplace toute valeur définie pour WARM_PREFIX_TARGET.

        kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5

        kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2

    4. Créez l'un des types de groupes de nœuds suivants avec au moins un type d'instance Amazon EC2 Nitro Amazon Linux 2. Pour obtenir la liste des types d'instances Nitro, consultez la section Instances créées sur le système Nitro dans le guide de l'utilisateur Amazon EC2. Cette capacité n'est pas prise en charge sur Windows. Pour les options qui incluent 110, remplacez-le par la valeur de l'étape 3 (recommandée) ou par votre propre valeur.

      • Gestion automatique : déploie le groupe de nœuds à l'aide des instructions de Lancement de nœuds Amazon Linux autogérés. Spécifiez le texte suivant pour le BootstrapArgumentsparamètre.

        --use-max-pods false --kubelet-extra-args '--max-pods=110'

        Si vous utilisez eksctl pour créer le groupe de nœuds, vous pouvez utiliser la commande suivante.

        eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110

      • Géré : déployez votre groupe de nœuds à l'aide de l'une des options suivantes :

        • Sans modèle de lancement ou avec un modèle de lancement sans ID d'AMI spécifié : exécutez la procédure dans Création d'un groupe de nœuds gérés. Les groupes de nœuds gérés calculent automatiquement pour vous la valeur max-pods recommandée par Amazon EKS.

        • Avec un modèle de lancement avec un ID d'AMI spécifié : dans votre modèle de lancement, spécifiez un ID d'AMI optimisé pour Amazon EKS ou une AMI personnalisée créée à partir de l'AMI optimisée pour Amazon EKS, puis Déployez le groupe de nœuds avec un modèle de lancement et fournissez les données utilisateur suivantes dans le modèle de lancement. Ces données utilisateur transmettent des arguments dans le fichier bootstrap.sh. Pour plus d'informations sur le fichier d'amorçage, consultez bootstrap.sh sur GitHub.

          /etc/eks/bootstrap.sh my-cluster \
  --use-max-pods false \
  --kubelet-extra-args '--max-pods=110'

          Si vous utilisez eksctl pour créer le groupe de nœuds, vous pouvez utiliser la commande suivante.

          eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110

          Si vous avez créé une AMI personnalisée qui n'est pas créée à partir de l'AMI optimisée pour Amazon EKS, vous devez créer vous-même la configuration.

        Note

        Si vous souhaitez également affecter des adresses IP à des Pods à partir d'un sous-réseau différent de celui de l'instance, vous devez activer cette fonctionnalité dans cette étape. Pour plus d’informations, consultez Mise en réseau personnalisée pour les pods.

    Windows

    1. Activez l'attribution de préfixes IP.

      1. Ouvrez le amazon-vpc-cni ConfigMap pour le modifier.

        kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml

      2. Ajoutez les lignes suivantes à la section data.

          enable-windows-prefix-delegation: "true"

      3. Enregistrez le fichier et fermez l'éditeur.

      4. Confirmez que la ligne a été ajoutée à la ConfigMap.

        kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"

        Si la sortie renvoyée n'est pas true, il se peut qu'il y ait eu une erreur. Essayez à nouveau d'effectuer l'étape.

        Important

        Même si votre sous-réseau a des adresses IP disponibles, si le sous-réseau n'a pas de blocs contigus /28 disponibles, vous verrez le message d'erreur suivant dans les événements du nœud. 

        "failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request"

        Cela peut se produire en raison de la fragmentation des adresses IP secondaires existantes réparties sur un sous-réseau. Pour résoudre cette erreur, créez un nouveau sous-réseau et lancez des Pods là-bas, ou utilisez une réservation CIDR de sous-réseau Amazon EC2 pour réserver de l'espace dans un sous-réseau à utiliser avec l'affectation de préfixe. Pour plus d'informations, consultez la section Réservations CIDR de sous-réseau dans le Guide de l'utilisateur Amazon VPC.

    2. (Facultatif) Spécifiez une configuration supplémentaire pour contrôler le comportement de pré-échelonnement et d'échelonnement dynamique de votre cluster. Pour plus d'informations, consultez la section Options de configuration avec le mode de délégation de préfixes activé Windows. GitHub

      1. Ouvrez le amazon-vpc-cni ConfigMap pour le modifier. 

        kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml

      2. Remplacez le example values par une valeur supérieure à zéro et ajoutez les entrées dont vous avez besoin dans la section data du ConfigMap. Si vous définissez une valeur pour warm-ip-target ou minimum-ip-target, la valeur remplace toute valeur définie pour warm-prefix-target.

          warm-prefix-target: "1" 
  warm-ip-target: "5"
  minimum-ip-target: "2"

      3. Enregistrez le fichier et fermez l'éditeur.

    3. Créez des groupes de nœuds Windows avec au moins un type d'instance Amazon EC2 Nitro. Pour obtenir la Nitro liste des types d'instances, consultez la section Instances créées sur le Nitro système dans le guide de l'utilisateur Amazon EC2. Par défaut, le nombre maximum de Pods que vous pouvez déployer sur un nœud est de 110. Si vous souhaitez augmenter ou diminuer ce nombre, indiquez ce qui suit dans les données utilisateur de la configuration d'amorçage. Remplacez max-pods-quantity par votre valeur maximale de pods.

      -KubeletExtraArgs '--max-pods=max-pods-quantity'

      Si vous déployez des groupes de nœuds gérés, cette configuration doit être ajoutée au modèle de lancement. Pour plus d’informations, consultez Personnalisation des nœuds gérés avec des modèles de lancement. Pour plus d'informations sur les paramètres de configuration du script d'amorçage de Windows veuillez consulter Paramètres de configuration du script d'amorçage.

  2. Une fois que vos nœuds sont déployés, affichez les nœuds de votre cluster.

    kubectl get nodes

    L'exemple qui suit illustre un résultat.

    NAME                                             STATUS     ROLES    AGE   VERSION
ip-192-168-22-103.region-code.compute.internal   Ready      <none>   19m   v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal    Ready      <none>   19m   v1.XX.X-eks-6b7464

  3. Décrivez l'un des nœuds pour déterminer la valeur de max-pods pour le nœud et le nombre d'adresses IP disponibles. Remplacez 192.168.30.193 par l'adresse IPv4 dans le nom de l'un de vos nœuds renvoyés dans la sortie précédente. 

    kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'

    L'exemple qui suit illustre un résultat.

    pods:                                  110
vpc.amazonaws.com/PrivateIPv4Address:  144

    Dans la sortie précédente, 110 est le nombre maximum de Pods que Kubernetes déploiera sur le nœud, même si 144 adresses IP sont disponibles.