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

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub 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 :

  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 de plus amples informations, consultez Create a Node Pool for EKS Auto Mode.

Vous devez avoir installé et configuré kubectl. Pour de plus amples 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"

Cette classe de nœuds augmente la quantité de stockage éphémère disponible 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, consultez Create a Node Pool for EKS Auto Mode.

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éation d’une entrée d’accès à l’aide de 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 le modèle CloudFormation ci-dessous 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 piles CloudFormation, consultez Mise en route avec 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: 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" # 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 # 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

  • 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 du volume : EKS utilise la clé KMS personnalisée configurée pour chiffrer le volume racine en lecture seule de l’instance ainsi que le volume de données en lecture/écriture.

  • 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, 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 de plus amples 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 de plus amples 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 les groupes de nœuds créés.

  • 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 Sélection des sous-réseaux pour les pods.

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

Les champs podSubnetSelectorTerms et podSecurityGroupSelectorTerms activent des configurations réseau avancées en permettant aux pods de s’exécuter dans des sous-réseaux différents de ceux des nœuds. Cette séparation offre un meilleur contrôle du routage du trafic réseau et des politiques de sécurité. Notez que les podSecurityGroupSelectorTerms sont requises avec les podSubnetSelectorTerms.

Cas d’utilisation

Utilisez podSubnetSelectorTerms lorsque vous devez :

  • Séparer le trafic d’infrastructure (communication entre nœuds) du trafic des applications (communication entre pods)

  • Appliquer des configurations réseau différentes aux sous-réseaux des nœuds et aux sous-réseaux des pods.

  • Mettre en œuvre des politiques de sécurité ou des règles de routage distinctes pour les nœuds et les 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 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

  • Réduction de la densité de pods : moins de pods peuvent s’exécuter sur chaque nœud lorsqu’on utilise podSubnetSelectorTerms, 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 dans le sous-réseau des pods.

  • Limites des sélecteurs de sous-réseaux : les configurations standard subnetSelectorTerms et securityGroupSelectorTerms ne s’appliquent pas à la sélection du sous-réseau des pods.

  • 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 spécifique pour les pods, celui-ci doit se trouver dans la même zone de disponibilité que le sous-réseau des nœuds.