Création d’une classe de nœuds Création d’une entrée d’accès pour la classe de nœuds Spécification de la classe de nœuds Considérations Sous-réseaux et groupes de sécurité distincts pour les Pods Mode IP secondaire pour les pods Désactivez la sortie IPv4 depuis les pods IPv6 dans les clusters IPv6.Configuration de l'interface réseau statique

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 qui se trouve dans le volet droit de chaque page.

Création d’une classe de nœuds pour Amazon EKS

Les classes de nœuds Amazon EKS sont des modèles qui offrent un contrôle précis de la configuration de vos nœuds gérés par le mode automatique EKS. Une classe de nœuds définit les paramètres d’infrastructure appliqués à des groupes de nœuds de votre cluster EKS, notamment la configuration réseau, les paramètres de stockage et le balisage des ressources. Cette rubrique explique comment créer et configurer une classe de nœuds pour répondre à vos exigences opérationnelles spécifiques.

Lorsque vous devez personnaliser la façon dont le mode automatique EKS provisionne et configure les instances EC2 au-delà des paramètres par défaut, la création d’une classe de nœuds vous permet de contrôler précisément des paramètres d’infrastructure essentiels. Par exemple, vous pouvez spécifier le placement dans des sous-réseaux privés pour renforcer la sécurité, configurer un stockage éphémère des instances pour les charges de travail sensibles aux performances ou appliquer des étiquettes personnalisées pour l’allocation des coûts.

Création d’une classe de nœuds

Pour créer une NodeClass, procédez comme suit :

Créez un fichier YAML (par exemple nodeclass.yaml) contenant la configuration de votre classe de nœuds
Appliquez la configuration à votre cluster à l’aide de kubectl
Référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour de plus amples informations, veuillez consulter Création d’un pool de nœuds pour le mode automatique EKS.

Vous devez avoir installé et configuré kubectl. Pour de plus amples informations, veuillez consulter Configuration pour utiliser Amazon EKS.

Exemple de classe de nœuds simple

Voici un exemple de classe de nœuds :


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-compute
spec:
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
  ephemeralStorage:
    size: "160Gi"

Cela NodeClass augmente la quantité de stockage éphémère sur le nœud.

Appliquez cette configuration en utilisant :


kubectl apply -f nodeclass.yaml

Ensuite, référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour de plus amples informations, veuillez consulter Création d’un pool de nœuds pour le mode automatique EKS.

Création d’une entrée d’accès pour la classe de nœuds

Si vous créez une classe de nœuds personnalisée, vous devez créer une entrée d’accès EKS pour permettre aux nœuds de rejoindre le cluster. EKS crée automatiquement les entrées d’accès lorsque vous utilisez la classe de nœuds intégrée et les groupes de nœuds intégrés.

Pour plus d’informations sur le fonctionnement des entrées d’accès, consultez Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS.

Lorsque vous créez des entrées d’accès pour les classes de nœuds du mode automatique EKS, vous devez utiliser le type d’entrée d’accès EC2.

Création d’une entrée d’accès à l’aide de la CLI

Pour créer une entrée d’accès pour les nœuds EC2 et associer la politique de nœud automatique EKS :

Mettez à jour les commandes CLI suivantes avec le nom de votre cluster et l’ARN du rôle de nœud. L’ARN du rôle de nœud est spécifié dans le fichier YAML de la classe de nœuds.


# Create the access entry for EC2 nodes
aws eks create-access-entry \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --type EC2

# Associate the auto node policy
aws eks associate-access-policy \
  --cluster-name <cluster-name> \
  --principal-arn <node-role-arn> \
  --policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
  --access-scope type=cluster

Créez une entrée d'accès avec CloudFormation

Pour créer une entrée d’accès pour les nœuds EC2 et associer la politique de nœud automatique EKS :

Mettez à jour les informations suivantes CloudFormation avec le nom de votre cluster et l'ARN du rôle de nœud. L’ARN du rôle de nœud est spécifié dans le fichier YAML de la classe de nœuds.


EKSAutoNodeRoleAccessEntry:
  Type: AWS::EKS::AccessEntry
  Properties:
    ClusterName: <cluster-name>
    PrincipalArn: <node-role-arn>
    Type: "EC2"
    AccessPolicies:
      - AccessScope:
          Type: cluster
        PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
  DependsOn: [ <cluster-name> ] # previously defined in CloudFormation

Pour plus d'informations sur le déploiement de CloudFormation piles, voir Mise en route CloudFormation

Spécification de la classe de nœuds


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: my-node-class
spec:
  # Required fields

  # role and instanceProfile are mutually exclusive fields.
  role: MyNodeRole  # IAM role for EC2 instances
  # instanceProfile: eks-MyNodeInstanceProfile  # IAM instance-profile for EC2 instances

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
        kubernetes.io/role/internal-elb: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0123456789abcdef0"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"
    # Alternative approaches:
    # - id: "sg-0123456789abcdef0"
    # - name: "eks-cluster-security-group"

  # Optional: Pod subnet selector for advanced networking
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"
    # Alternative using direct subnet ID
    # - id: "subnet-0987654321fedcba0"
  # must include Pod security group selector also
  podSecurityGroupSelectorTerms:
    - tags:
        Name: "eks-pod-sg"
    # Alternative using direct security group ID
    # - id: "sg-0123456789abcdef0"

  # Optional: Selects on-demand capacity reservations and capacity blocks
  # for EKS Auto Mode to prioritize.
  capacityReservationSelectorTerms:
    - id: cr-56fac701cc1951b03
    # Alternative Approaches
    - tags:
        Name: "targeted-odcr"
      # Optional owning account ID filter
      owner: "012345678901"

  # Optional fields
  snatPolicy: Random  # or Disabled

  networkPolicy: DefaultAllow  # or DefaultDeny
  networkPolicyEventLogs: Disabled  # or Enabled

  ephemeralStorage:
    size: "80Gi"    # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
    iops: 3000      # Range: 3000-16000
    throughput: 125 # Range: 125-1000
    # Optional KMS key for encryption
    kmsKeyID: "arn:aws: kms:region:account:key/key-id"
    # Accepted formats:
    # KMS Key ID
    # KMS Key ARN
    # Key Alias Name
    # Key Alias ARN

  advancedNetworking:
    # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
    # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
    associatePublicIPAddress: false

    # Optional: Forward proxy, commonly requires certificateBundles as well
    # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
    httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
    #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
    noProxy: #Max 50 entries
        - localhost #Max 255 characters each
        - 127.0.0.1
        #- ::1 # IPv6 localhost
        #- 0:0:0:0:0:0:0:1 # IPv6 localhost
        - 169.254.169.254 # EC2 Instance Metadata Service
        #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
        # Domains to exclude, put all VPC endpoints here
        - .internal
        - .eks.amazonaws.com
    # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
    ipv4PrefixSize: Auto # or "32"

    # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
    enableV4Egress: false

    # Optional: Static network interface configuration for EFA workloads
    networkInterfaces:
      # The primary ENI (networkCardIndex 0, deviceIndex 0) must use interfaceType: interface
      # secondaryIPv4Count and secondaryIPv4PrefixCount are only supported on networkCardIndex 0
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4Count: 10
    - deviceIndex: 1
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 2 # Only one of secondaryIPv4Count or secondaryIPv4PrefixCount per ENI
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1

  advancedSecurity:
    # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
    fips: false

  # Optional: Custom certificate bundles.
  certificateBundles:
    - name: "custom-cert"
      data: "base64-encoded-cert-data"

  # Optional: EC2 Placement Group
  placementGroupSelector:
    name: "targeted-pg"
    # Alternative use direct placement group ID
    # id: "pg-02465754522cda020"

  # Optional: Additional EC2 tags (with restrictions)
  tags:
    Environment: "production"
    Team: "platform"
    # Note: Cannot use restricted tags like:
    # - kubernetes.io/cluster/*
    # - karpenter.sh/provisioner-name
    # - karpenter.sh/nodepool
    # - karpenter.sh/nodeclaim
    # - karpenter.sh/managed-by
    # - eks.amazonaws.com/nodeclass

Considérations

Si vous souhaitez vérifier le volume de stockage local d’une instance, vous pouvez décrire le nœud pour voir la ressource de stockage éphémère.
Chiffrement des volumes : EKS utilise la clé KMS personnalisée configurée pour chiffrer le volume racine en lecture seule de l'instance et le read/write volume de données.
Remplacement du rôle IAM du nœud : si vous modifiez le rôle IAM du nœud associé à une NodeClass, vous devrez créer une nouvelle entrée d’accès. EKS crée automatiquement une entrée d’accès pour le rôle IAM du nœud lors de la création du cluster. Le rôle IAM du nœud nécessite la stratégie d’accès AmazonEKSAutoNodePolicy EKS. Pour de plus amples informations, veuillez consulter Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS.
Densité maximale de pods : EKS limite le nombre maximal de pods sur un nœud à 110. Cette limite s’applique après le calcul existant du nombre maximal de pods. Pour de plus amples informations, veuillez consulter Choix du type d’instance Amazon EC2 optimal pour les nœuds.
Balises : si vous souhaitez propager des balises de Kubernetes vers EC2, vous devez configurer des autorisations IAM supplémentaires. Pour de plus amples informations, veuillez consulter Informations sur les identités et l’accès dans le mode automatique EKS.
Classe de nœuds par défaut : ne nommez pas votre classe de nœuds personnalisée default. En effet, le mode automatique EKS inclut une NodeClass appelée default, provisionnée automatiquement lorsque vous activez au moins un NodePool intégré. Pour plus d’informations sur l’activation des NodePools intégrés, consultez Activer ou désactiver Built-in NodePools.
Comportement des subnetSelectorTerms avec plusieurs sous-réseaux : si plusieurs sous-réseaux correspondent aux conditions subnetSelectorTerms ou sont fournis par ID, le mode automatique EKS crée des nœuds répartis sur l’ensemble des sous-réseaux.
- Si les sous-réseaux se trouvent dans différentes zones de disponibilité (AZ), vous pouvez utiliser des fonctionnalités Kubernetes telles que les contraintes de propagation de la topologie des pods et le routage adapté à la topologie pour répartir les pods et le trafic entre les zones, respectivement.
- S’il existe plusieurs sous-réseaux dans la même zone de disponibilité qui correspondent aux subnetSelectorTerms, le mode automatique EKS crée des pods sur chaque nœud répartis dans ces sous-réseaux de cette même zone de disponibilité. Le mode automatique EKS crée également des interfaces réseau secondaires sur chaque nœud dans les autres sous-réseaux de la même zone de disponibilité. Il choisit en fonction du nombre d’adresses IP disponibles dans chaque sous-réseau, afin d’utiliser les sous-réseaux plus efficacement. Cependant, vous ne pouvez pas spécifier quel sous-réseau le mode automatique EKS utilise pour chaque pod ; si vous avez besoin que des pods s’exécutent dans des sous-réseaux spécifiques, utilisez Sous-réseaux et groupes de sécurité distincts pour les Pods.
Restrictions relatives à la stratégie de groupe de placement : chaque stratégie de groupe de placement (cluster, partition, spread) comporte des limites spécifiques quant aux types d'instances, aux AZ et à la capacité. Pour plus de détails, consultez la section Stratégies relatives aux groupes de placement dans le guide de l'utilisateur Amazon EC2.
Groupe de placement des spreads — Limite de 7 instances — Un groupe de placement des spreads au niveau du rack autorise un maximum de 7 instances en cours d'exécution par zone de disponibilité et par groupe. Cela crée les cas limites suivants :
- Remplacement de la dérive bloqué à pleine capacité — Le mode automatique EKS lance un nœud de remplacement avant de terminer l'ancien. Lorsqu'un spread PG possède 7 instances dans une zone de zone Z, le lancement de remplacement échoue et le nœud dérivé continue de fonctionner jusqu'à ce qu'un emplacement soit libéré.
- Toutes les AZ à pleine capacité — Si chaque AZ du spread PG atteint sa limite de 7 instances, aucun remplacement ne peut être programmé. Les nœuds dérivés ou candidats à la consolidation continuent de fonctionner indéfiniment.
- Aucune solution de secours en dehors du groupe de placement : le mode automatique EKS n'essaie pas de lancer des instances de remplacement en dehors du groupe de placement.
- Solution : utilisez la politique WhenEmpty de consolidation (consolidationPolicy: WhenEmpty). Les nœuds ne sont supprimés qu'une fois que tous les pods autres que les daemonsets se sont vidés, libérant ainsi un emplacement PG sans avoir besoin d'un lancement de remplacement au préalable. Notez que Drift utilise toujours replace-then-delete, quelle que soit la politique de consolidation, de sorte que la dérive reste bloquée à pleine capacité.
Épinglage AZ du groupe de placement de clusters : une fois que la première instance est lancée dans un groupe de placement de clusters, le PG est épinglé à cet AZ. Si vous NodePool autorisez plusieurs AZ, les lancements parallèles lors de la mise à l'échelle initiale peuvent s'accélérer : l'un réussit et épingle la AZ, les autres échouent en raison d'erreurs de capacité. Épinglez l'AZ dans vos NodePool exigences pour éviter les défaillances transitoires.
Groupe de placement de partitions : les groupes de placement de partitions sont pris en charge sans aucune contrainte supplémentaire au-delà des limites EC2 standard.
La consolidation peut déplacer des pods hors d'un groupe de placement — Si un pod n'est soumis à aucune contrainte de planification de groupe de placement (telle qu'une activationeks.amazonaws.com/placement-group-id), la consolidation peut nodeSelector le déplacer vers un nœud en dehors du PG. Les candidatures qui nécessitent l'appartenance à un groupe de placement doivent l'exprimer par le biais de contraintes au niveau du module.
Groupe de placement inexistant ou supprimé : si a NodeClass fait référence à un groupe de placement qui n'existe pas ou qui a été supprimé, aucune instance n'est lancée. Le format d'identification du groupe de placement est validé lors de l'admission, mais son existence n'est vérifiée qu'au moment du lancement. Si un groupe de placement est supprimé alors que des nœuds sont en cours d'exécution, les nœuds existants sont marqués comme ayant dérivé et restent actifs indéfiniment car les lancements de remplacement par dérive sont également bloqués.

Sous-réseaux et groupes de sécurité distincts pour les Pods

Les podSecurityGroupSelectorTerms champs podSubnetSelectorTerms et permettent des configurations réseau avancées en permettant aux Pods d'utiliser des sous-réseaux et des groupes de sécurité différents de ceux de leurs nœuds. Les deux champs doivent être spécifiés ensemble. Cette séparation offre un meilleur contrôle du routage du trafic réseau et des politiques de sécurité.

Note

Cette fonctionnalité est différente de la fonctionnalité SGPP (Security Groups for Pods) utilisée avec le VPC CNI pour le calcul en mode automatique non-EKS. Le SGPP n'est pas pris en charge en mode automatique EKS. podSecurityGroupSelectorTermsUtilisez-le plutôt NodeClass pour appliquer des groupes de sécurité distincts au trafic du Pod. Les groupes de sécurité s'appliquent au NodeClass niveau, ce qui signifie que tous les Pods des nœuds qui les utilisent NodeClass partagent les mêmes groupes de sécurité.

Comment ça marche

Lorsque vous configurez podSubnetSelectorTerms et podSecurityGroupSelectorTerms :

L'ENI principal du nœud utilise les sous-réseaux et les groupes de sécurité de subnetSelectorTerms etsecurityGroupSelectorTerms. Seule la propre adresse IP du nœud est attribuée à cette interface.
Le mode automatique EKS crée des ENI secondaires dans les sous-réseaux correspondantspodSubnetSelectorTerms, avec les groupes de podSecurityGroupSelectorTerms sécurité associés. Les adresses IP des pods sont attribuées à partir de ces ENI secondaires à l'aide des préfixes /28 par défaut, avec un retour automatique aux adresses IP secondaires (/32) lorsqu'aucun bloc de préfixe contigu n'est disponible. Si cette ipv4PrefixSize option est définie sur "32" ActivéadvancedNetworking, seules les adresses IP secondaires sont utilisées.
Les groupes de sécurité spécifiés dans podSecurityGroupSelectorTerms s'appliquent au trafic du pod au sein du VPC. Pour le trafic destiné à l'extérieur du VPC, les pods utilisent l'ENI principal du nœud (et ses groupes de sécurité) car la traduction des adresses réseau source (SNAT) traduit l'adresse IP du pod en adresse IP du nœud. Vous pouvez modifier ce comportement à l'aide du snatPolicy champ duNodeClass.

Cas d’utilisation

À utiliser podSubnetSelectorTerms et podSecurityGroupSelectorTerms quand vous en avez besoin :

Appliquez différents groupes de sécurité pour contrôler le trafic des nœuds et des pods séparément.
Séparez le trafic d'infrastructure (communication nœud à nœud) du trafic applicatif (Pod-to-Pod communication).
Appliquer des configurations réseau différentes aux sous-réseaux des nœuds et aux sous-réseaux des pods.
Configurer des serveurs proxy inverses ou des filtres réseau spécifiquement pour le trafic des nœuds sans affecter le trafic des pods. Utiliser advancedNetworking et certificateBundles pour définir votre serveur proxy inverse ainsi que tout certificat autosigné ou privé pour ce serveur.

Exemple de configuration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  # Subnets and security groups for EC2 instances (nodes)
  subnetSelectorTerms:
    - tags:
        Name: "node-subnet"
        kubernetes.io/role/internal-elb: "1"

  securityGroupSelectorTerms:
    - tags:
        Name: "eks-cluster-sg"

  # Separate subnets and security groups for Pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

  podSecurityGroupSelectorTerms:
  - tags:
      Name: "eks-pod-sg"

Considérations relatives à des sous-réseaux et à des groupes de sécurité distincts pour les pods

Étendue du groupe de sécurité : les groupes de sécurité de podSecurityGroupSelectorTerms sont attachés aux ENI secondaires et s'appliquent au trafic du pod au sein du VPC. Lorsque le SNAT est activé (par défautsnatPolicy: Random), le trafic sortant du VPC est traduit vers l'adresse IP ENI principale du nœud, de sorte que les groupes de sécurité du nœud securityGroupSelectorTerms s'appliquent à ce trafic à la place. Si vous le configurezsnatPolicy: Disabled, les Pods utilisent leurs propres adresses IP pour l'ensemble du trafic, et vous devez vous assurer que les groupes de routage et de sécurité sont configurés en conséquence.
NodeClass-level granularité : les groupes de sécurité des pods s'appliquent à tous les pods planifiés sur des nœuds à l'aide duNodeClass. Pour appliquer différents groupes de sécurité à différentes charges de travail, créez des NodePool ressources NodeClass et distinctes et utilisez des teintes, des tolérations ou des sélecteurs de nœuds pour planifier les charges de travail sur les nœuds appropriés.
Densité de pods réduite : moins de pods peuvent être exécutés sur chaque nœud car l'interface réseau principale du nœud est réservée à l'adresse IP du nœud et ne peut pas être utilisée pour les pods.
Limitations du sélecteur de sous-réseau : la norme subnetSelectorTerms et les securityGroupSelectorTerms configurations ne s'appliquent pas à la sélection du sous-réseau ou du groupe de sécurité du pod.
Planification du réseau : assurez-vous de disposer d’un espace d’adresses IP suffisant dans les sous-réseaux des nœuds et des pods pour répondre aux besoins de vos charges de travail.
Configuration du routage : vérifiez que la table de routage et les listes de contrôle d’accès (ACL) réseau des sous-réseaux destinés aux pods sont correctement configurées pour permettre la communication entre les sous-réseaux des nœuds et ceux des pods.
Zones de disponibilité : vérifiez que vous avez créé des sous-réseaux pour les pods dans plusieurs zones de disponibilité. Si vous utilisez un sous-réseau Pod spécifique, celui-ci doit se trouver dans la même zone de disponibilité que le sous-réseau AZ du nœud.

Mode IP secondaire pour les pods

Le ipv4PrefixSize champ permet des configurations réseau avancées en attribuant uniquement des adresses IP secondaires aux nœuds. Cette fonctionnalité n'alloue pas de préfixes (/28) aux nœuds et ne conserve qu'une seule adresse IP secondaire en tant que MinimalIPTarget.

Cas d’utilisation

Utilisez ipv4PrefixSize lorsque vous devez :

Utilisation IP réduite : une seule adresse IP sera chauffée par nœud.
Diminution du taux de barattage des pods : la vitesse de création des pods n'est pas une préoccupation majeure.
Aucune fragmentation des préfixes : Prefix-caused la fragmentation est un problème majeur ou un obstacle à l'utilisation du mode automatique.

Exemple de configuration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    ipv4PrefixSize: "32"

Considérations relatives au mode IP secondaire

Vitesse de création de pods réduite : étant donné qu'une seule adresse IP secondaire est préchauffée, le service IPAM a besoin de plus de temps pour provisionner les adresses IP lorsque d'autres pods sont créés.

Désactivez la sortie IPv4 depuis les pods IPv6 dans les clusters IPv6.

Le enableV4Egress champ est défini true par défaut. Pour les clusters IPv6 en mode automatique, la fonctionnalité peut être désactivée afin que le mode automatique ne crée pas d'interface IPv4 de sortie uniquement pour les espaces IPv6. Ceci est important car l'interface de sortie IPv4 n'est pas soumise à l'application de la politique réseau. Les politiques réseau ne sont appliquées que sur l'interface principale du Pod (eth0).

Cas d’utilisation

Utilisez enableV4Egress lorsque vous devez :

Utiliser un cluster IPv6 : le trafic sortant IPv4 est autorisé par défaut.
Utiliser la politique réseau : Actuellement, la politique réseau EKS ne prend pas en charge la double pile. La désactivation enableV4Egress peut empêcher le trafic des pods de sortir de manière inattendue via IPv4.

Exemple de configuration


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: advanced-networking
spec:
  role: MyNodeRole

  advancedNetworking:
    enableV4Egress: false

Considérations relatives à la désactivation d'EnableV4egress

Politique réseau dans le cluster IPv6 : les clusters IPv6 autorisent le trafic IPv4 par défaut. Le paramètre enableV4Egress: false bloque le trafic sortant IPv4, offrant ainsi une sécurité accrue, en particulier lorsqu'il est utilisé avec des politiques réseau.

Configuration de l'interface réseau statique

Le networkInterfaces champ ci-dessous vous advancedNetworking permet de définir statiquement les interfaces réseau associées aux instances lors du lancement. Il est principalement utilisé pour configurer les périphériques Elastic Fabric Adapter (EFA) pour une communication inter-nœuds performante dans les charges de travail de formation et d'inférence distribuées. Cette fonctionnalité peut être associée à des pools de nœuds à capacité statique pour maintenir les nœuds préchauffés EFA-ready . Pour plus d'informations sur la gestion des appareils EFA dans EKS, consultezGérer les appareils EFA sur Amazon EKS. Pour connaître la configuration EFA recommandée pour des types d'instances spécifiques, voir Maximiser la bande passante réseau pour les types d' EFA-enabled instances dans le guide de l'utilisateur Amazon EC2.

Comment ça marche

Chaque entrée de networkInterfaces définit une interface réseau qui est attachée à l'instance lors du lancement. Chaque entrée spécifie a networkCardIndex (la carte réseau, où 0 est la principale), a deviceIndex (la position du périphérique sur cette carte) et an interfaceType (interfacepour le IP-based trafic standard ou efa-only pour les interfaces EFA dédiées au trafic RDMA sans adresse IP). L'ENI principal (networkCardIndex: 0,deviceIndex: 0) doit être utilisé interfaceType: interface pour prendre en charge la communication IP-based entre les nœuds. Les efa-only interfaces ne prennent en charge que les fonctionnalités des périphériques EFA pour le RDMA et ne peuvent pas être configurées avec des adresses IP.

Vous pouvez attribuer une capacité IP aux interfaces de la carte réseau principale (networkCardIndex: 0) en utilisant secondaryIPv4Count (chaque unité fournit une adresse IP) ou secondaryIPv4PrefixCount (chaque unité fournit un préfixe /28 avec 16 adresses IP). Un seul d'entre eux peut être utilisé par interface, et ils ne sont pris en charge que surnetworkCardIndex: 0. Ils ne peuvent pas être utilisés sur efa-only les interfaces.

Important

Lorsqu'il networkInterfaces est configuré, le mode automatique EKS n'associe pas d'adresses IP, de préfixes ou d'ENI supplémentaires après le lancement de l'instance. Seules les interfaces et les adresses IP configurées au lancement sont disponibles pour les Pods. Vous devez planifier la densité de votre pod en fonction du nombre d'adresses IP configurées.

Considérations

IPv6 n'est pas pris en charge avec les interfaces réseau définies statiquement. associatePublicIPAddressn'est pas compatible lorsque plusieurs interfaces réseau sont définies, de sorte que les nœuds utilisant plusieurs interfaces ne peuvent pas avoir d'adresses IP publiques (que ce soit dans des clusters publics ou des public/private clusters mixtes).

Lorsque vous utilisez podSubnetSelectorTerms et podSecurityGroupSelectorTerms avec des interfaces réseau statiques, configurez l'ENI principal avec 0 IP secondaires. L'ENI principal utilise le sous-réseau du nœud et les groupes de sécurité, tandis que le trafic du pod utilise la configuration du sous-réseau du pod sur les ENI secondaires.

Exemple : EFA-only interfaces pour l'entraînement des GPU

L'exemple suivant montre une NodeClass configuration avec des EFA-only interfaces pour une instance GPU utilisée dans la formation distribuée. L'interface principale possède un préfixe /28 (16 adresses IP de pod) et 4 EFA-only interfaces supplémentaires fournissent une connectivité RDMA. Cette configuration peut être associée à un pool de nœuds à capacité statique pour maintenir des nœuds préchauffés EFA-ready .


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: efa-training
spec:
  role: MyNodeRole
  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"
  securityGroupSelectorTerms:
    - tags:
        Name: "efa-security-group"
  placementGroupSelector:
    name: "ml-training-pg"
  advancedNetworking:
    networkInterfaces:
    - deviceIndex: 0
      interfaceType: interface
      networkCardIndex: 0
      secondaryIPv4PrefixCount: 1
    - deviceIndex: 1
      interfaceType: efa-only
      networkCardIndex: 0
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 1
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 2
    - deviceIndex: 0
      interfaceType: efa-only
      networkCardIndex: 3

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Configurer

Création d’un groupe de nœuds