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.

Considérations relatives aux charges de travail dispersées ou à grande échelle

Le mode automatique EKS utilise la délégation de préfixes (/28préfixes) par défaut. Chaque nœud réserve 16 adresses IP de pod, ce qui est efficace pour les charges de travail denses qui occupent ces emplacements. Pour les charges de travail éparses (quelques modules par nœud, ce qui est courant dans les charges de travail ML ou GPU, ou les charges de travail à faible affinité) ciblant plus de quelques centaines de nœuds par zone de disponibilité, le mode IP secondaire () est une configuration plus optimisée. "32" Il alloue une adresse IP par pod au lieu d'en réserver 16 par nœud, ce qui augmente la capacité effective des sous-réseaux des /20 pods.

Pour plus d’informations, consultez Mode IP secondaire pour les pods. Pour conserver les pods dans un sous-réseau distinct des nœuds (indépendamment du mode d'allocation), consultezSous-réseaux et groupes de sécurité distincts pour les Pods.

Création d’une classe de nœuds

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

1. Créez un fichier YAML (par exemple nodeclass.yaml) contenant la configuration de votre classe de nœuds

2. Appliquez la configuration à votre cluster à l’aide de kubectl

3. Référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour plus d’informations, consultez Création d’un pool de nœuds pour le mode automatique EKS.

Vous devez avoir installé et configuré kubectl. Pour plus d’informations, consultez 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 plus d’informations, consultez 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 plus d’informations, consultez 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 plus d’informations, consultez 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 plus d’informations, consultez 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.

• Hugepages  : pour plus d'informations sur la configuration de Hugepages sur les nœuds, consultez. Configurer Hugepages sur les nœuds

• Paramètres du kubelet  : pour plus d'informations sur la modification des paramètres du kubelet, tels que la densité des pods, les seuils d'expulsion et la rotation des journaux, consultez. Configurer les paramètres de kubelet sur les nœuds

• Sysctls du noyau — Pour plus d'informations sur la configuration des fichiers sysctls du noyau sur les nœuds, consultez. Configurer les fichiers sysctls du noyau sur les nœuds

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 :

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

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

3. 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 de nœud à nœud) du trafic d'application (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 Pod 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 la liste de contrôle d'accès (ACL) réseau des sous-réseaux du pod sont correctement configurées pour la communication entre le nœud et les sous-réseaux du pod.

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

advancedNetworking.ipv4PrefixSizeaccepte deux valeurs : Auto (par défaut ; délégation de préfixe ; vitesse de création de pod plus élevée ; réserve un minimum de 16 adresses IP par nœud) et "32" (mode IP secondaire ; 1 IP par pod ; ajoute des AssignPrivateIpAddresses appels par pod ; pods par nœud plafonnés par l'ENI du type d'instance). IP-limit

En Auto mode, le mode EKS Auto attribue un /28 préfixe (16 adresses IP) à chaque nœud dès le départ et en ajoute un autre /28 lorsque la demande de pods dépasse la capacité du bloc actuel. 16 est donc un minimum par nœud plutôt qu'un plafond.

Utilisez les chiffres suivants pour la planification ; les clusters réels varient. Lorsque le sous-réseau du pod est fragmenté et qu'aucun réseau contigu n'/28est libre, le Auto mode revient à l'allocation par IP sur ce nœud. Per-node Le nombre d'adresses IP se situe alors en dessous du modèle de 16 par préfixe illustré ci-dessous.

Exemple A : 1 pod sur le nœud

• Mode IP secondaire : 1 IP du pod + 1 IP du nœud = 2 adresses IP utilisées.

• Mode préfixe : 1 IP de nœud + 16 adresses IP à partir du premier /28 préfixe (dont 1 est utilisée par le pod, 15 sont conservées pour les futurs pods) = 17 adresses IP allouées, 2 en cours d'utilisation.

Exemple B : 18 pods sur le nœud

• Mode IP secondaire : 18 adresses IP de pod + 1 IP de nœud = 19 adresses IP utilisées.

• Mode préfixe : 1 nœud IP + 2 × /28 préfixes (32 adresses IP au total, la première étant /28 complète avec 16 pods, la seconde /28 contient les pods 17 à 18 et 14 sont conservées pour les futurs pods) = 33 adresses IP allouées, 19 en cours d'utilisation.

Pour passer en mode IP secondaire (1 adresse IP par espace, aucune réservation de préfixe) pour une charge de travail éparse, créez une adresse personnalisée advancedNetworking.ipv4PrefixSize: "32" et pointez une adresse personnalisée NodeClass vers celle-ci. NodePool Les pools intégrés general-purpose et de system nœuds utilisent ceux qui sont automatiquement provisionnés default NodeClass ; le remplacement ipv4PrefixSize nécessite une personnalisation NodeClass associée à une personnalisation. NodePool

Cas d’utilisation

• Meilleure utilisation des adresses IP des sous-réseaux

• Aucune fragmentation des préfixes

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

Configurer Hugepages sur les nœuds

Avec ce advancedCompute.hugepages champ, vous pouvez configurer des pages énormes sur les nœuds du. NodeClass Hugepages améliore les performances d'accès à la mémoire pour les charges de travail sensibles à la latence, telles que le calcul haute performance (HPC), les bases de données et les applications gourmandes en réseau. Vous pouvez utiliser deux configurations HugePages indépendantes séparément ou ensemble :

• Hugepages statiques  : utilisez ce pages champ pour pré-allouer un nombre fixe de 1Gi pages énormes à chaque nœud, 2Mi ou une combinaison des deux tailles. Les pages énormes statiques sont une ressource de nœud planifiable. Pour les utiliser, configurez vos Pods de manière à demander explicitement des ressources Hugepage telles hugepages-2Mi que ou. hugepages-1Gi Pour plus d'informations, consultez la section Gérer HugePages dans la documentation Kubernetes.

• Transparent hugepages (THP) — Utilisez ce transparent champ pour configurer la politique THP du noyau. Le THP est une politique à l'échelle du noyau plutôt qu'une ressource allouable. Cela n'affecte pas la planification ni la capacité des nœuds, et les pods ne le demandent pas. Pour plus d'informations, consultez Transparent Hugepage Support dans la documentation du noyau Linux.

Exemple de configuration

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

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

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

  advancedCompute:
    hugepages:
      # Static hugepage reservations: up to one entry for each size
      pages:
        - size: "2Mi"
          count: 512
        - size: "1Gi"
          count: 2
      # Transparent hugepages (THP) kernel policy
      transparent:
        enabled: always  # or madvise, never
        defrag: defer    # or always, defer+madvise, madvise, never

Paramètres de page énormes transparents

Les deux transparent paramètres sont facultatifs. Si vous omettez un paramètre, le nœud utilise la valeur par défaut du noyau (madvise).

• enabled— Permet enabled de contrôler la politique d'allocation du THP. Réglez cette option pour appliquer always le THP à l'ensemble du système. Réglez-le pour madvise appliquer le THP uniquement aux régions de mémoire avec madvise(MADV_HUGEPAGE) lesquelles l'option est activée. Réglez-le sur never pour désactiver le THP.

• defrag— Permet defrag de contrôler l'agressivité avec laquelle le noyau compacte la mémoire pour satisfaire une allocation THP. Les valeurs valides sont always, defer, defer+madvise, madvise et never.

Pour désactiver le THP, par exemple pour les charges de travail de base de données qui recommandent de le désactiver, définissez. enabled: never Quand enabled c'est never le cas, defrag laissez-le désactivé ou définissez-le sur never ; NodeClass la validation rejette toute autre combinaison.

Considérations relatives aux pages énormes

Tenez compte des points suivants lorsque vous configurez hugepages sur un : NodeClass

• Tailles de page énormes statiques  : utilisez ce pages champ pour spécifier jusqu'à une entrée pour chaque taille de page énorme (et). 2Mi 1Gi Vous pouvez réserver les deux tailles sur les mêmes nœuds.

• Réservation de mémoire  : les énormes pages statiques sont prises en compte dans la mémoire totale de l'instance. Amazon EKS marque les types d'instance comme incompatibles NodeClass lorsque la réservation combinée de pages énormes, toutes tailles de page confondues, dépasserait 80 % de la mémoire totale.

• Exclusion mutuelle EFA — Elastic Fabric Adapter (EFA) et static hugepages ne peuvent pas coexister en même temps. NodeClass Si vous configurez interfaceType: efa-only avecpages, NodeClass la validation échoue. Amazon EKS ne fournit pas de pods qui demandent vpc.amazonaws.com/efa à partir NodeClass de pages énormes statiques. Utilisez une unité distincte NodeClass pour les charges de travail EFA. Les pages énormes transparentes n'entrent pas en conflit avec EFA ; vous pouvez les configurer transparent sur un appareil NodeClass qui utilise des interfaces EFA.

Configurer les paramètres de kubelet sur les nœuds

Utilisez ce advancedCompute.kubelet champ pour modifier les paramètres de kubelet sur les nœuds du. NodeClass Grâce à ces modifications, vous pouvez ajuster la densité des pods, l'éviction sous pression des ressources, la rotation des journaux des conteneurs et le comportement en cas de manque de mémoire (OOM). Amazon EKS applique les paramètres de kubelet par défaut aux nœuds en mode automatique. Configurez donc ce champ uniquement lorsque vos charges de travail nécessitent un comportement différent. Pour plus d'informations sur les paramètres sous-jacents, consultez la section Configuration de Kubelet dans la documentation Kubernetes.

Les paramètres de kubelet suivants sont disponibles :

• maxPods: le nombre maximum de Pods pouvant être exécutés sur un nœud.

• podPidsLimit: le nombre maximum d'ID de processus (PID) par pod.

• idsPerPod: le nombre d'UID et de GID que kubelet attribue à l'espace de noms utilisateur de chaque Pod.

• singleProcessOOMKill: indique si le kubelet OOM tue les processus d'un conteneur individuellement plutôt qu'en groupe.

• eviction: Seuils d'expulsion stricts et souples pour les signaux de pression sur les ressources.

• logging: taille de rotation du journal des conteneurs et nombre de fichiers.

• allowedUnsafeSysctls: une liste de sysctls dangereux, ou de modèles d'espace de noms se terminant par*, que les Pods planifiés sur le nœud sont autorisés à définir.

Exemple de configuration

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

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

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

  advancedCompute:
    kubelet:
      # Range: 1-110
      maxPods: 60
      # -1 disables the limit, or specify 100 or greater
      podPidsLimit: 4096
      # Multiple of 65536, range: 65536-4294967295. Requires
      # advancedCompute.kernel.sysctl.user.max_user_namespaces > 0.
      idsPerPod: 65536
      singleProcessOOMKill: false
      eviction:
        # Valid signals: memory.available, nodefs.available, nodefs.inodesFree,
        # imagefs.available, imagefs.inodesFree, pid.available
        hard:
          memory.available: "100Mi"
          nodefs.available: "10%"
        soft:
          memory.available: "500Mi"
          nodefs.available: "15%"
        # Required when soft thresholds are set
        softGracePeriod:
          memory.available: "1m30s"
          nodefs.available: "2m"
        # 0 uses each Pod's terminationGracePeriodSeconds
        maxPodGracePeriod: 60
      logging:
        containerLogMaxSize: "10Mi"
        # Minimum: 2
        containerLogMaxFiles: 5
      # Up to 64 entries. Allowed patterns: kernel.shm*, kernel.msg*,
      # kernel.sem, fs.mqueue.*, net.*
      allowedUnsafeSysctls:
        - "net.core.somaxconn"
        - "kernel.shm*"

Considérations relatives aux paramètres de Kubelet

Tenez compte des points suivants lorsque vous configurez les paramètres de kubelet sur un : NodeClass

• Remplacement d'un nœud  : la modification des paramètres d'un kubelet sur un existant NodeClass marque les nœuds qui l'utilisent comme étant dérivés. Amazon EKS remplace ces nœuds par de nouveaux nœuds utilisant la configuration mise à jour. Amazon EKS n'applique pas les paramètres de kubelet aux nœuds en cours d'exécution sur place.

• maxPodsserrage  : la valeur que vous définissez est une limite supérieure et non une garantie. Au moment de l'exécution, Amazon EKS applique la plus faible des trois valeurs. Il s'agit de votre maxPods valeur, des adresses IP disponibles pour le type d'instance et de la limite du mode automatique de 110 pods par nœud. Pour plus d’informations, consultez Choix du type d’instance Amazon EC2 optimal pour les nœuds.

• podPidsLimitvaleurs  : indiquez -1 si vous souhaitez désactiver la limite, ou une valeur égale 100 ou supérieure. NodeClassla validation rejette les valeurs comprises entre 0 et99.

• idsPerPodexigences  : La valeur doit être un multiple 65536 compris entre 65536 et4294967295. Le réglage idsPerPod doit advancedCompute.kernel.sysctl.user.max_user_namespaces être défini sur une valeur positive sur la même valeur NodeClass ; NodeClass l'admission rejette les configurations qui définissent idsPerPod sans également user.max_user_namespaces définir une valeur supérieure à0. Pour plus d’informations sur user.max_user_namespaces, consultez Sysctls pris en charge.

• Seuils d'expulsion souples  : un seuil souple doit être moins agressif que le seuil strict pour le même signal, c'est-à-dire qu'il se déclenche plus tôt. Si vous définissez des seuils souples, vous devez également softGracePeriod les définir pour chaque signal. Un seuil souple et un seuil strict peuvent utiliser différentes unités, telles qu'un pourcentage et une quantité absolue. Dans ce cas, Amazon EKS résout les deux valeurs pour chaque type d'instance. Amazon EKS marque ensuite les types d'instances qui ne respectent pas la comparaison comme étant incompatibles avec leNodeClass.

• singleProcessOOMKillversion requise  : ce paramètre nécessite la version 1.32 ou ultérieure de Kubernetes. Dans les versions précédentes, Amazon EKS émettait un événement d'avertissement sur le NodeClass et le paramètre n'avait aucun effet.

• allowedUnsafeSysctlsrestrictions  : vous pouvez spécifier jusqu'à 64 entrées, et chaque entrée doit correspondre à l'un des modèles autorisés : kernel.shm* kernel.msg*kernel.sem,fs.mqueue. , ounet.. Autoriser un sysctl non sécurisé sur le nœud permet uniquement aux Pods de le demander. Chaque Pod doit toujours répertorier le sysctl dans son. securityContext.sysctls Pour plus d'informations, consultez la section Utilisation de sysctls dans un cluster Kubernetes dans la documentation Kubernetes.

Configurer les fichiers sysctls du noyau sur les nœuds

Utilisez ce advancedCompute.kernel.sysctl champ pour définir les fichiers sysctls du noyau Linux sur les nœuds du. NodeClass Les Sysctls ajustent le comportement du noyau d'exécution pour les charges de travail nécessitant des limites réseau plus élevées, des politiques de gestion de la mémoire différentes ou des paramètres TCP spécifiques. Les noms des propriétés sur le sysctl champ correspondent exactement au nom sysctl du noyau sous-jacent (par exemple, vm.swappiness etnet.core.somaxconn). Amazon EKS applique les valeurs sysctl au démarrage du nœud. Si vous modifiez un sysctl sur un fichier existant NodeClass, Amazon EKS commence à remplacer les nœuds pour que les nouvelles valeurs prennent effet.

Exemple de configuration

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

  subnetSelectorTerms:
    - tags:
        Name: "private-subnet"

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

  advancedCompute:
    kernel:
      sysctl:
        vm.swappiness: 30
        net.core.somaxconn: 4096
        net.ipv4.tcp_congestion_control: "cubic"
        vm.dirty_background_ratio: 10
        vm.dirty_ratio: 20

Sysctls pris en charge

Amazon EKS prend uniquement en charge les sysctls du tableau suivant. Chaque système numérique applique le minimum et le maximum indiqués, et l' NodeClass admission rejette les valeurs situées en dehors de cette plage. Les chaînes sysctls n'acceptent que les valeurs répertoriées.

Sysctl	Description	Valeurs autorisées
fs.aio-max-nr	Le nombre maximum de demandes asynchrones I/O .	65536–4194304
fs.inotify.max_user_instances	Le nombre maximum d'instances inotify par identifiant utilisateur réel.	8192–1048576
fs.inotify.max_user_watches	Le nombre maximum de montres inotify par identifiant utilisateur réel.	8192–1048576
fs.nr_open	Le nombre maximum de descripteurs de fichiers qu'un processus peut allouer.	1048576–2147483584
kernel.perf_event_paranoid	Contrôle l'accès non privilégié aux systèmes d'événements de performance.	-1–2
net.core.netdev_max_backlog	Le nombre maximum de paquets en file d'attente côté INPUT par processeur.	1000–3240000
net.core.rmem_max	Taille maximale de la mémoire tampon du socket de réception, en octets.	212992–134217728
net.core.somaxconn	La valeur maximale de l'argument backlog dans l'appel système d'écoute.	4096–3240000
net.core.wmem_max	Taille maximale de la mémoire tampon du socket d'envoi, en octets.	212992–134217728
net.ipv4.neigh.default.gc_thresh1	Nombre minimum d' ARP-cache entrées avant que la collecte des déchets puisse commencer.	0–262144
net.ipv4.neigh.default.gc_thresh2	Nombre maximum d' ARP-cache entrées souple.	512–524288
net.ipv4.neigh.default.gc_thresh3	Nombre maximum d' ARP-cache entrées.	1024–1048576
net.ipv4.tcp_congestion_control	Algorithme de contrôle de congestion TCP pour les nouvelles connexions.	cubic, reno
net.ipv4.tcp_fin_timeout	Durée, en secondes, pendant laquelle une connexion orpheline reste dans l'état FIN_WAIT_2 avant d'être abandonnée au niveau local.	5–120
net.ipv4.tcp_keepalive_time	Fréquence, en secondes, à laquelle TCP envoie des messages keepalive lorsque keepalive est activé.	30–432000
net.ipv4.tcp_max_syn_backlog	Le nombre maximum de demandes SYN en suspens autorisées. Les requêtes dépassant cette valeur sont supprimées par le noyau.	128–3240000
net.ipv4.tcp_tw_reuse	Activez la réutilisation des TIME-WAIT sockets pour les nouvelles connexions lorsque cela est sûr du point de vue du protocole. 0désactive, 1 active globalement, 2 active le bouclage uniquement.	0–2
user.max_user_namespaces	Le nombre maximum d'espaces de noms utilisateur pouvant être créés par un utilisateur. Une valeur de 0 désactive les espaces de noms utilisateur.	0–2147483647
vm.dirty_background_ratio	Pourcentage de mémoire disponible à partir duquel les threads de vidage du noyau commencent à réécrire les pages sales sur le disque.	1–20
vm.dirty_expire_centisecs	Des centièmes de seconde avant qu'une page sale ne soit éligible à la réécriture.	0–6000
vm.dirty_ratio	Pourcentage de mémoire disponible auquel les programmes d'écriture sont contraints de bloquer les écritures.	5–40
vm.dirty_writeback_centisecs	Centièmes de seconde entre les invocations de flusher-thread.	0–1000
vm.max_map_count	Nombre maximum de zones de carte mémoire qu'un seul processus peut avoir.	65530–2147483647
vm.swappiness	Coût d'E/S relatif de l'échange par rapport à la pagination du système de fichiers.	0–200
vm.watermark_scale_factor	Taux de filigrane de récupération de mémoire en fractions de 10 000.	10–3000

Considérations relatives aux systèmes

Tenez compte des points suivants lorsque vous configurez les fichiers sysctls du noyau sur un : NodeClass

• Sysctls pris en charge  : seuls les fichiers sysctls répertoriés dans sont pris en charge. Sysctls pris en charge Chaque champ applique un minimum et un maximum documentés, et l' NodeClass admission rejette les valeurs situées en dehors de cette plage.

• Appliqué au démarrage — Les Sysctls sont écrits dans Bottlerocket au démarrage du nœud. [settings.kernel.sysctl] Modifications d'exécution pour spec.advancedCompute.kernel.sysctl marquer les nœuds existants comme étant dérivés ; les nouvelles valeurs ne prennent effet que sur les nœuds de remplacement.

• vm.dirty_background_ratioet vm.dirty_ratio — Ces deux champs doivent tous deux être définis ou omis, et vm.dirty_background_ratio doivent être strictement inférieurs vm.dirty_ratio à. NodeClass admission rejette les configurations qui enfreignent l'une ou l'autre des règles.

• net.ipv4.neigh.default.gc_thresh1gc_thresh2, et gc_thresh3 — Les trois ARP-cache seuils doivent tous être définis ensemble ou tous omis, et leurs valeurs doivent être respectées. gc_thresh1 < gc_thresh2 < gc_thresh3 NodeClass admission rejette les configurations qui enfreignent l'une ou l'autre des règles.

• net.ipv4.tcp_congestion_control— Uniquement cubic et reno sont acceptés.