View a markdown version of this page

Augmentation du nombre d’adresses IP disponibles pour un nœud Amazon EKS - Amazon EKS
Conditions préalablesAttribution de préfixes d’adresses IP aux nœudsDétermination du nombre maximal de pods et du nombre d’adresses IP disponibles

Aidez à améliorer cette page

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

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.

Augmentation du nombre d’adresses IP disponibles pour un nœud Amazon EKS

Vous pouvez augmenter le nombre d’adresses IP que les nœuds peuvent attribuer aux pods en attribuant des préfixes IP, plutôt qu’en attribuant des adresses IP secondaires individuelles aux nœuds.

Conditions préalables

  • Vous devez disposer d’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 garantit que, même si certaines adresses IP de la plage réservée sont encore utilisées, elles ne seront pas réattribuées après 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 fonctionner dans le même sous-réseau lors de l’attribution de 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 disposent d’un nombre beaucoup plus faible d’adresses à attribuer aux pods que les instances basées sur Nitro.

  • 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 plug-in Amazon VPC CNI pour 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 plus d'informations, consultez les sections de mise à jour d'Assign IPs to Pods with the Amazon VPC CNI.

  • Pour les clusters avec des nœuds Windows uniquement

Attribution de préfixes d’adresses IP aux nœuds

Configurez votre cluster pour attribuer des préfixes d'adresses IP aux nœuds. Suivez la procédure correspondant au système d’exploitation de vos nœuds.

Linux

  1. Activez le paramètre pour attribuer des préfixes aux interfaces réseau pour le CNI Amazon DaemonSet VPC. Lors du déploiement d’un cluster, la version 1.10.1 ou ultérieure du module complémentaire plug-in Amazon VPC CNI est déployée avec celui-ci. 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 dispose d’adresses IP disponibles, s’il n’a pas de blocs /28 contigus disponibles, vous verrez l’erreur suivante dans les journaux du plug-in Amazon VPC CNI pour 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 déployez-y vos pods, ou utilisez une réservation CIDR de sous-réseau Amazon EC2 afin de réserver de l’espace dans un sous-réseau pour l’attribution par 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 sans AMI spécifié, et que vous utilisez une version du module complémentaire plug-in Amazon VPC CNI é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.

    Si vous déployez un groupe de nœuds autogéré 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éfinir le nombre maximum de pods pour vos nœuds. Pour plus d'informations sur la manière de déterminer la valeur appropriée, consultezComment est déterminé MaxPods.

    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 v, CPUs le nombre maximum est de 110 et pour toutes les autres instances, le nombre maximum est de 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 configuré pour IPv6, passez à l’étape suivante.

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

    Vous pouvez remplacer la commande 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 2023. Pour obtenir la liste des types d’instance Nitro, consultez Instances reposant sur le système Nitro dans le Guide de l’utilisateur Amazon EC2. Cette fonctionnalité 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.

    • Autogéré : déployez le groupe de nœuds en suivant les instructions de la section Création de nœuds Amazon Linux autogérés. Avant de créer la CloudFormation pile, ouvrez le fichier modèle et ajustez NodeLaunchTemplate le UserData dans le comme suit

      ...
            apiVersion: node.eks.aws/v1alpha1
            kind: NodeConfig
            spec:
              cluster:
                name: ${ClusterName}
                apiServerEndpoint: ${ApiServerEndpoint}
                certificateAuthority: ${CertificateAuthorityData}
                cidr: ${ServiceCidr}
              kubelet:
                config:
                  maxPods: 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é : suivez la procédure décrite dans Création d’un groupe de nœuds géré pour votre cluster. 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 un NodeConfig objet à lire par l'nodeadmoutil sur le nœud. Pour plus d'informationsnodeadm, consultez la documentation de nodeadm.

        MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"

--//
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
 cluster:
   apiServerEndpoint: [.replaceable]`my-cluster`
   certificateAuthority: [.replaceable]`LS0t...`
   cidr: [.replaceable]`10.100.0.0/16`
   name: [.replaceable]`my-cluster
 kubelet:
   config:
     maxPods: [.replaceable]`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 basée sur l’AMI optimisée Amazon EKS, vous devez alors créer la configuration manuellement.

    Note

    Si vous souhaitez également attribuer des adresses IP aux pods à partir d’un sous-réseau différent de celui de l’instance, vous devez activer cette fonctionnalité à cette étape. Pour de plus amples informations, veuillez consulter Déploiement de pods dans des sous-réseaux alternatifs avec réseau personnalisé.

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 le résultat renvoyé 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 dispose d’adresses IP disponibles, s’il n’a pas de blocs /28 contigus disponibles, vous verrez l’erreur suivante dans les journaux du plug-in Amazon VPC CNI pour 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 déployez-y vos pods, ou utilisez une réservation CIDR de sous-réseau Amazon EC2 afin de réserver de l’espace dans un sous-réseau pour l’attribution par 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 sous Windows activé GitHub.

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

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

    2. Remplacez les valeurs d'exemple par une valeur supérieure à zéro et ajoutez les entrées dont vous avez besoin dans la data section duConfigMap. 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 comprenant au moins un type d’instance Amazon EC2 basé sur Nitro. Pour obtenir la liste des types d’instance Nitro, consultez Instances reposant sur le système Nitro 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 dans le modèle de lancement. Pour de plus amples informations, veuillez consulter Personnaliser les nœuds gérés à l’aide de modèles de lancement. Pour plus d’informations sur les paramètres du script d’amorçage Windows, consultez Paramètres de configuration du script d'amorçage.

Détermination du nombre maximal de pods et du nombre d’adresses IP disponibles

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

  2. 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 c'est le nombre maximum de pods que Kubernetes déploiera sur le nœud, même si des adresses 144 IP sont disponibles.