Création d'une classe de nœuds Créer une entrée d'accès à une classe de nœud Spécification de classe de nœuds Considérations Sélection de sous-réseaux pour les pods

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.

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 en mode automatique EKS. Une classe de nœuds définit les paramètres au niveau de l'infrastructure qui s'appliquent aux 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 d'EKS approvisionne et configure les EC2 instances au-delà des paramètres par défaut, la création d'une classe de nœuds vous permet de contrôler avec précision les paramètres d'infrastructure critiques. Par exemple, vous pouvez spécifier l'emplacement des sous-réseaux privés pour améliorer la sécurité, configurer le stockage éphémère des instances pour les charges de travail sensibles aux performances ou appliquer un balisage personnalisé pour la répartition des coûts.

Création d'une classe de nœuds

Pour créer unNodeClass, procédez comme suit :

Créez un fichier YAML (par exemple,nodeclass.yaml) avec votre configuration de classe de nœud
Appliquez la configuration à votre cluster à l'aide de kubectl
Référencez la classe de nœuds dans la configuration de votre pool 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 kubectl être installé et configuré. Pour de plus amples informations, veuillez consulter Configuration pour utiliser Amazon EKS.

Exemple de classe de nœuds de base

Voici un exemple de classe de nœud :


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, faites référence à la classe de nœuds dans la configuration de votre pool de nœuds. Pour de plus amples informations, veuillez consulter Création d'un pool de nœuds pour le mode automatique EKS.

Créer une entrée d'accès à une classe de nœud

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 des entrées d'accès lorsque vous utilisez la classe de nœuds et les pools de nœuds intégrés.

Pour plus d'informations sur le fonctionnement des entrées d'accès, consultezAccorder aux utilisateurs IAM l'accès à Kubernetes avec des entrées d'accès EKS.

Lorsque vous créez des entrées d'accès pour les classes de nœuds EKS Auto Mode, vous devez utiliser le type d'entrée d'EC2accès.

Créer une entrée d'accès avec la CLI

Pour créer une entrée d'accès pour les EC2 nœuds et associer la politique EKS Auto Node :

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 la classe de nœud YAML.


# 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 EC2 nœuds et associer la politique EKS Auto Node :

Mettez à jour ce qui suit 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 la classe de nœud YAML.


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 CloudFormation de stacks, voir Getting started with CloudFormation

Spécification de classe de nœuds


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: my-node-class
spec:
  # Required fields
  role: MyNodeRole  # IAM role 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"


  # 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

  # Optional: Forward proxy, commonly requires certificateBundles as well
  #for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
  advancedNetworking:
    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

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

  # 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

Chiffrement du volume : EKS utilise la clé KMS personnalisée configurée pour chiffrer le volume racine en lecture seule de l'instance et le volume de données. read/write
Remplacer le rôle IAM du nœud : si vous modifiez le rôle IAM du nœud associé à unNodeClass, 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 politique d'accès AmazonEKSAutoNodePolicy EKS. Pour de plus amples informations, veuillez consulter Accorder aux utilisateurs IAM l'accès à Kubernetes avec des entrées d'accès EKS.
densité maximale de pods - EKS limite le nombre maximum de pods sur un nœud à 110. Cette limite est appliquée après le calcul du nombre maximum de pods existant. Pour de plus amples informations, veuillez consulter Choisissez un type d'instance de EC2 nœud Amazon optimal.
Balises - Si vous souhaitez propager des balises depuis Kubernetes vers EC2, vous devez configurer des autorisations IAM supplémentaires. Pour de plus amples informations, veuillez consulter En savoir plus sur l'identité et l'accès en mode automatique EKS.
Classe de nœud par défaut : ne nommez pas votre classe de nœud personnaliséedefault. Cela est dû au fait que le mode automatique d'EKS inclut un NodeClass appel default qui est automatiquement provisionné lorsque vous activez au moins un appel intégréNodePool. Pour plus d'informations sur l'activation de la fonction intégréeNodePools, consultezActiver ou désactiver la fonction intégrée NodePools.
subnetSelectorTermscomportement avec plusieurs sous-réseaux - S'il existe plusieurs sous-réseaux qui répondent aux subnetSelectorTerms conditions ou que vous fournissez par ID, le mode automatique EKS crée des nœuds répartis sur les sous-réseaux.
- Si les sous-réseaux se trouvent dans des zones de disponibilité (AZ) différentes, vous pouvez utiliser les fonctionnalités de 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.
- Si plusieurs sous-réseaux correspondent à la même zonesubnetSelectorTerms, le mode automatique d'EKS crée des pods sur chaque nœud répartis sur les sous-réseaux de cette zone. Le mode automatique EKS crée des interfaces réseau secondaires sur chaque nœud des autres sous-réseaux de la même zone de distribution. Il choisit en fonction du nombre d'adresses IP disponibles dans chaque sous-réseau, afin d'utiliser les sous-réseaux de manière plus efficace. Cependant, vous ne pouvez pas spécifier quel sous-réseau EKS Auto Mode utilise pour chaque pod ; si vous avez besoin de pods pour fonctionner dans des sous-réseaux spécifiques, Sélection de sous-réseaux pour les pods utilisez-le plutôt.

Sélection de sous-réseaux pour les pods

Les podSecurityGroupSelectorTerms champs podSubnetSelectorTerms et permettent des configurations réseau avancées en permettant aux pods de s'exécuter dans des sous-réseaux différents de ceux de leurs nœuds. Cette séparation permet de mieux contrôler le routage du trafic réseau et les politiques de sécurité. Notez que cela podSecurityGroupSelectorTerms est obligatoire avec lepodSubnetSelectorTerms.

Cas d’utilisation

À utiliser podSubnetSelectorTerms lorsque vous devez :

Séparez le trafic d'infrastructure (node-to-node communication) du trafic d'applications (pod-to-pod communication)
Appliquez des configurations réseau différentes aux sous-réseaux de nœuds par rapport aux sous-réseaux de pods.
Mettez en œuvre différentes politiques de sécurité ou règles de routage pour les nœuds et les pods.
Configurez les proxys inverses ou le filtrage réseau spécifiquement pour le trafic des nœuds sans affecter le trafic des pods. Utilisez advancedNetworking et certificateBundles pour définir votre proxy inverse et tout certificat auto-signé ou privé pour le proxy.

Exemple de configuration


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

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

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

  # Separate subnets for pods
  podSubnetSelectorTerms:
    - tags:
        Name: "pod-subnet"
        kubernetes.io/role/pod: "1"

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

Considérations relatives aux sélecteurs de sous-réseaux pour les pods

Densité de pods réduite : moins de pods peuvent être exécutés sur chaque nœud lors de podSubnetSelectorTerms son utilisation, car l'interface réseau principale du nœud se trouve dans le sous-réseau du nœud et ne peut pas être utilisée pour les pods du sous-réseau du pod.
Limites 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 du pod.
Planification du réseau : assurez-vous que l'espace d'adresse IP est suffisant dans les sous-réseaux de nœuds et de pods pour répondre aux exigences de votre charge de travail.
Configuration du routage : Vérifiez que la table de routage et la liste de contrôle d'accès réseau (ACL) des sous-réseaux du pod sont correctement configurées pour la communication entre le nœud et les sous-réseaux du pod.

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

Configuration

Créer un pool de nœuds