**Aidez à améliorer cette page**
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Configurer les paramètres du mode automatique EKS
Ce chapitre décrit comment configurer certains aspects spécifiques de vos clusters du mode automatique Amazon Elastic Kubernetes Service (EKS). Bien que le mode automatique EKS gère automatiquement la plupart des composants de l’infrastructure, vous pouvez personnaliser certaines fonctionnalités pour répondre aux exigences de votre charge de travail.
À l’aide des options de configuration décrites dans cette rubrique, vous pouvez modifier les paramètres réseau, les ressources de calcul et les comportements d’équilibrage de charge tout en conservant les avantages de la gestion automatisée de l’infrastructure. Avant d’apporter des modifications à la configuration, examinez les options disponibles dans les sections suivantes afin de déterminer l’approche la mieux adaptée à vos besoins.
| Quelles fonctionnalités voulez-vous configurer ? | Option de configuration |
| --- | --- |
| **Réseau et stockage des nœuds** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md) |
| **Ressources de calcul des nœuds** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Create a Node Pool for EKS Auto Mode](create-node-pool.md) |
| **Pools de nœuds à capacité statique** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Pools de nœuds à capacité statique en mode automatique EKS](auto-static-capacity.md) |
| **Paramètres de l’Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Créez un IngressClass pour configurer un Application Load Balancer](auto-configure-alb.md) |
| **Paramètres du Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Utilisation des annotations de service pour configurer les équilibreurs de charge Network Load Balancer](auto-configure-nlb.md) |
| **Paramètres de la classe de stockage** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Création d’une classe de stockage](create-storage-class.md) |
| **Contrôle de l’utilisation de l’ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS](auto-odcr.md) |
| **Sécurité avancée des nœuds** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/settings-auto.html) | [Configuration des paramètres de sécurité avancés pour les nœuds](auto-advanced-security.md) |
# 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
1. Appliquez la configuration à votre cluster à l’aide de `kubectl`
1. Référencez la classe de nœuds dans la configuration de votre groupe de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
Vous devez avoir installé et configuré `kubectl`. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
### 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 [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## 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](access-entries.md).
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 \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-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 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 le fichier YAML de la classe de nœuds.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Pour plus d'informations sur le déploiement CloudFormation de stacks, voir [Getting started with CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## 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
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: 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 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](access-entries.md).
+ **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](choosing-instance-type.md).
+ **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](auto-learn-iam.md).
+ **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 la fonction intégrée NodePools](set-builtin-node-pools.md).
+ **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 des zones de disponibilité différentes (AZs), vous pouvez utiliser les fonctionnalités de Kubernetes telles que les [contraintes de propagation de la topologie des pods](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) et le [routage adapté à la topologie pour répartir les](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) 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](#pod-subnet-selector).
## 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é [Security Groups for Pods](security-groups-for-pods.md) (SGPP) utilisée avec le CNI VPC d'AWS pour le calcul en mode automatique hors EKS. Le SGPP n'est pas pris en charge en mode automatique EKS. Utilisez plutôt `podSecurityGroupSelectorTerms` in `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 situés sur les nœuds utilisateurs `NodeClass` partagent les mêmes groupes de sécurité de pods.
### 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é provenant de `subnetSelectorTerms` et`securityGroupSelectorTerms`. Seule l'adresse IP du nœud est attribuée à cette interface.
1. Le mode automatique EKS crée un ENIs élément secondaire dans les sous-réseaux correspondants`podSubnetSelectorTerms`, les groupes de sécurité étant `podSecurityGroupSelectorTerms` rattachés. Les adresses IP des pods sont allouées à partir de ces préfixes secondaires à ENIs l'aide des préfixes /28 par défaut, avec un retour automatique au secondaire IPs (/32) lorsqu'aucun bloc de préfixe contigu n'est disponible. Si `ipv4PrefixSize` ce paramètre est défini sur `"32"` in`advancedNetworking`, seuls IPs les éléments secondaires sont utilisés.
1. Les groupes de sécurité spécifiés dans `podSecurityGroupSelectorTerms` s'appliquent au trafic des pods 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 d'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 situé dans le`NodeClass`.
### Cas d’utilisation
À utiliser `podSubnetSelectorTerms` et `podSecurityGroupSelectorTerms` quand vous devez :
+ 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 (node-to-node communication) du trafic d'applications (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 aux sous-réseaux Pod et aux groupes de sécurité distincts
+ **Étendue du groupe** de sécurité : les groupes de sécurité provenant de `podSecurityGroupSelectorTerms` sont attachés au groupe secondaire ENIs et s'appliquent au trafic des pods au sein du VPC. Lorsque le SNAT est activé (valeur par défaut`snatPolicy: Random`), le trafic quittant le VPC est traduit vers l'adresse IP ENI principale du nœud, de sorte que les groupes de sécurité du nœud s'appliquent `securityGroupSelectorTerms` plutôt à ce trafic. Si vous le configurez`snatPolicy: 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-niveau de granularité** : les groupes de sécurité Pod s'appliquent à tous les Pods planifiés sur les nœuds utilisant le. `NodeClass` Pour appliquer différents groupes de sécurité à différentes charges de travail, créez des `NodePool` ressources `NodeClass` et utilisez des restrictions, des tolérances 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.
+ **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 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 Pod sur plusieurs AZs. Si vous utilisez un sous-réseau Pod spécifique, il doit se trouver dans le même AZ que le sous-réseau de nœuds AZ.
## Mode IP secondaire pour les pods
Le `ipv4PrefixSize` champ permet des configurations réseau avancées en n'allouant que 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 comme minimale. IPTarget
### Cas d’utilisation
Utilisez `ipv4PrefixSize` lorsque vous devez :
+ **Utilisation IP réduite** : une seule adresse IP sera réchauffée dans chaque nœud.
+ **Réduction du taux de rotation des capsules** : la vitesse de création des capsules n'est pas une préoccupation majeure.
+ **Aucune fragmentation des préfixes : la fragmentation** causée par les préfixes est une préoccupation majeure 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 réchauffée, le service IPAM a besoin de plus de temps pour le provisionner IPs lorsque d'autres pods sont créés.
## Désactivez la IPv4 sortie des IPv6 pods en IPv6 clusters.
Le `enableV4Egress` champ est défini `true` par défaut. Pour les IPv6 clusters en mode automatique, la fonctionnalité peut être désactivée afin que le mode automatique ne crée pas d' IPv4 interface de sortie uniquement pour les pods. IPv6 Ceci est important car l'interface de IPv4 sortie 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 le IPv6 cluster** : le trafic de IPv4 sortie est autorisé par défaut.
+ **Utiliser la politique réseau** : actuellement, EKS Network Policy ne prend pas en charge le double stack. La désactivation `enableV4Egress` peut empêcher le trafic du pod de sortir de façon inattendue. 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 IPv6 cluster** : les IPv6 clusters autorisent IPv4 le trafic par défaut. Le réglage `enableV4Egress: false` bloque le IPv4 trafic sortant, offrant ainsi une sécurité renforcée, en particulier lorsqu'il est utilisé avec des politiques réseau.
# Create a Node Pool for EKS Auto Mode
Les groupes de nœuds Amazon EKS offrent une méthode flexible pour gérer les ressources de calcul dans votre cluster Kubernetes. Cette rubrique explique comment créer et configurer des groupes de nœuds à l’aide de Karpenter, un outil de provisionnement de nœuds qui permet d’optimiser l’étendue du cluster et l’utilisation des ressources. Grâce à la ressource NodePool de Karpenter, vous pouvez définir des exigences précises pour vos ressources de calcul, notamment les types d’instances, les zones de disponibilité, les architectures et les types de capacité.
Les groupes de nœuds intégrés `system` et `general-purpose` ne peuvent pas être modifiés. Vous pouvez uniquement les activer ou les désactiver. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
La spécification NodePool permet un contrôle précis des ressources de cluster computing EKS à l’aide de diverses étiquettes et exigences prises en charge. Ces options incluent la définition des catégories d’instances EC2, la configuration du processeur, la sélection des zones de disponibilité, le choix de l’architecture (ARM64 ou AMD64) et le type de capacité (Spot ou à la demande). Vous pouvez également définir des limites de ressources pour l’utilisation du processeur et de la mémoire, afin que votre cluster respecte les contraintes opérationnelles requises.
Le mode automatique EKS utilise des étiquettes Kubernetes reconnues afin de proposer des méthodes uniformes et standardisées d’identification des caractéristiques des nœuds. Ces étiquettes, par exemple `topology.kubernetes.io/zone` pour les zones de disponibilité et `kubernetes.io/arch` pour l’architecture du processeur, respectent les conventions établies de Kubernetes. De plus, des étiquettes spécifiques à EKS (préfixées par `eks.amazonaws.com/`) étendent cette fonctionnalité en ajoutant des attributs spécifiques à AWS, tels que les types d’instance, les fabricants de processeurs, les capacités GPU et les spécifications réseau. Ce système d’étiquetage standardisé assure une intégration fluide avec les outils Kubernetes existants, tout en offrant une intégration approfondie à l’infrastructure AWS.
## Création d’un NodePool
Pour créer un NodePool pour votre cluster Amazon EKS, procédez comme suit :
1. Créez un fichier YAML nommé `nodepool.yaml` contenant la configuration requise de votre NodePool. Vous pouvez utiliser l’exemple de configuration ci-dessous.
1. Appliquez le NodePool à votre cluster :
```
kubectl apply -f nodepool.yaml
```
1. Vérifiez que le NodePool a été créé avec succès :
```
kubectl get nodepools
```
1. (Facultatif) Surveillez l’état du NodePool :
```
kubectl describe nodepool default
```
Assurez-vous que votre NodePool fait référence à un NodeClass valide existant dans votre cluster. La NodeClass définit les configurations spécifiques à AWS pour vos ressources de calcul. Pour de plus amples informations, consultez [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
## Exemple de NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Étiquettes prises en charge par le mode automatique EKS
Le mode automatique EKS prend en charge les étiquettes bien connues suivantes.
**Note**
Le mode automatique EKS utilise des étiquettes différentes de celles de Karpenter. Les étiquettes associées aux instances gérées EC2 commencent par `eks.amazonaws.com`.
| Étiquette | exemple | Description |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS région |
| node.kubernetes.io/instance-type | g4dn.8xlarge | Type d'instance AWS |
| kubernetes.io/arch | amd64 | Architectures définies par les [valeurs GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) sur l’instance |
| karpenter.sh/capacity-type | spot | Les types de capacité comprennent `spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Types d’instance utilisant un hyperviseur spécifique |
| eks.amazonaws.com/compute-type | auto | Identifie les nœuds gérés par le mode automatique EKS |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Types d’instance prenant en charge (ou non) le chiffrement en transit |
| eks.amazonaws.com/instance-category | g | Types d’instance de la même catégorie, généralement la chaîne précédant le numéro de génération |
| eks.amazonaws.com/instance-generation | 4 | Numéro de génération du type d’instance au sein d’une même catégorie d’instances |
| eks.amazonaws.com/instance-family | g4dn | Types d’instance présentant des propriétés similaires, mais des quantités de ressources différentes |
| eks.amazonaws.com/instance-size | 8xlarge | Types d’instance présentant des quantités de ressources similaires, mais des propriétés différentes |
| eks.amazonaws.com/instance-cpu | 32 | Nombre de processeurs sur l’instance |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Nom du fabricant du processeur |
| eks.amazonaws.com/instance-memory | 131072 | Nombre de mébioctets de mémoire sur l’instance |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | Nombre [maximal de mégabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) d’EBS disponibles sur l’instance |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | Nombre de [mégabits de base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponibles sur l’instance |
| eks.amazonaws.com/instance-gpu-name | t4 | Nom du GPU présent sur l’instance, le cas échéant |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Nom du fabricant du GPU |
| eks.amazonaws.com/instance-gpu-count | 1 | Nombre de GPU présents sur l’instance |
| eks.amazonaws.com/instance-gpu-memory | 16384 | Quantité de mémoire GPU en mébioctets sur l’instance |
| eks.amazonaws.com/instance-local-nvme | 900 | Quantité de stockage local NVMe en gibioctets sur l’instance |
**Note**
Le mode automatique EKS ne prend en charge que certains types d’instances et impose des exigences de taille minimale. Pour de plus amples informations, consultez [Référence des instances prises en charge par le mode automatique EKS](automode-learn-instances.md#auto-supported-instances).
## Étiquettes non prises en charge par le mode automatique EKS
Le mode automatique EKS ne prend pas en charge les étiquettes suivantes.
+ Le mode automatique EKS ne prend en charge que Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Désactivation des groupes de nœuds intégrés
Si vous créez des groupes de nœuds personnalisés, vous pouvez désactiver les groupes de nœuds intégrés. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
## Cluster sans groupes de nœuds intégrés
Vous pouvez créer un cluster sans groupes de nœuds intégrés. Cela est utile si votre organisation a mis en place des groupes de nœuds personnalisés.
**Note**
Lorsque vous créez un cluster sans groupes de nœuds intégrés, la NodeClass `default` n’est pas provisionnée automatiquement. Vous devrez créer une NodeClass personnalisée. Pour de plus amples informations, consultez [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
**Présentation :**
1. Créez un cluster EKS avec les valeurs `nodePools` et `nodeRoleArn` laissées vides.
+ Exemple eksctl `autoModeConfig` :
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Pour plus d’informations, consultez [Création d’un cluster du mode automatique EKS à l’aide de la CLI eksctl](automode-get-started-eksctl.md).
1. Créez une NodeClass personnalisée avec un ARN de rôle de nœud
+ Pour plus d’informations, consultez [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
1. Créez une entrée d’accès pour la classe de nœuds personnalisée
+ Pour plus d’informations, consultez [Création d’une entrée d’accès pour la classe de nœuds](create-node-class.md#auto-node-access-entry).
1. Créez un groupe de nœuds personnalisé, comme décrit ci-dessus.
## Interruption
Vous pouvez configurer le mode automatique EKS afin de gérer l’interruption des nœuds à partir de votre NodePool de plusieurs façons. Vous pouvez utiliser `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` ou `spec.template.spec.expireAfter`. Vous pouvez également limiter le taux d’interruption du mode automatique EKS à l’aide du paramètre `spec.disruption.budgets` du NodePool. Vous pouvez également contrôler les fenêtres temporelles et le nombre de nœuds interrompus simultanément. Pour obtenir des instructions sur la configuration de ce comportement, consultez la section [Interruption](https://karpenter.sh/docs/concepts/disruption/) dans la documentation de Karpenter.
Vous pouvez configurer l’interruption pour les groupes de nœuds afin de :
+ Identifier les instances sous-utilisées et consolider les charges de travail.
+ Créer un budget d’interruption pour limiter la fréquence des arrêts de nœuds liés à la dérive, au vidage ou à la consolidation.
Par défaut, le mode automatique EKS :
+ Consolide les instances sous-utilisées.
+ Met fin aux instances au bout de 336 heures.
+ Définit un budget d’interruption unique correspondant à 10 % des nœuds.
+ Permet le remplacement des nœuds en cas de dérive lors de la publication d’une nouvelle AMI du mode automatique (environ une fois par semaine).
## Délai de grâce avant terminaison
Lorsque le `terminationGracePeriod` n’est pas explicitement définie dans une NodePool EKS Auto, le système applique automatiquement un délai de grâce de 24 heures à la NodeClaim associée. Même si les utilisateurs d’EKS Auto ne verront pas un `terminationGracePeriod` défini par défaut dans leurs configurations personnalisées de NodePool, ils pourront l’observer dans la NodeClaim. La fonctionnalité demeure identique, qu’elle soit définie explicitement dans la NodePool ou appliquée par défaut dans la NodeClaim, ce qui garantit un comportement prévisible lors de la terminaison des nœuds dans le cluster.
# Pools de nœuds à capacité statique en mode automatique EKS
Le mode automatique Amazon EKS prend en charge les pools de nœuds à capacité statique qui maintiennent un nombre fixe de nœuds, quelle que soit la demande de pods. Les pools de nœuds à capacité statique sont utiles pour les charges de travail qui nécessitent une capacité prévisible, des instances réservées ou des exigences de conformité spécifiques pour lesquelles vous devez maintenir une empreinte d'infrastructure cohérente.
Contrairement aux pools de nœuds dynamiques qui évoluent en fonction des demandes de planification des pods, les pools de nœuds à capacité statique maintiennent le nombre de nœuds que vous avez configurés.
## Configuration d'un pool de nœuds à capacité statique
Pour créer un pool de nœuds à capacité statique, définissez le `replicas` champ dans votre NodePool spécification. Le `replicas` champ définit le nombre exact de nœuds que le pool de nœuds conservera. Consultez [Exemples](#static-capacity-examples) la section pour savoir comment configurer`replicas`.
## Considérations relatives au pool de nœuds à capacité statique
Les pools de nœuds à capacité statique présentent plusieurs contraintes et comportements importants :
**Contraintes de configuration :**
+ **Impossible de changer de mode** : une fois que vous avez configuré `replicas` un pool de nœuds, vous ne pouvez pas le supprimer. Le pool de nœuds ne peut pas passer du mode statique au mode dynamique.
+ **Limites de ressources limitées** : seul le `limits.nodes` champ est pris en charge dans la section des limites. Les limites de processeur et de mémoire ne sont pas applicables.
+ **Aucun champ de pondération** : le `weight` champ ne peut pas être défini sur les pools de nœuds à capacité statique car la sélection des nœuds n'est pas basée sur la priorité.
**Comportement opérationnel :**
+ **Aucune consolidation** : les nœuds des pools de capacité statiques ne sont pas pris en compte pour la consolidation.
+ Opérations de **dimensionnement : les opérations** de dimensionnement évitent les budgets liés aux interruptions de service des nœuds, tout en les respectant PodDisruptionBudgets.
+ **Remplacement** des nœuds : les nœuds sont toujours remplacés pour cause de dérive (comme les mises à jour d'AMI) et d'expiration en fonction de votre configuration.
## Bonnes pratiques
**Planification des capacités :**
+ Définissez `limits.nodes` une valeur supérieure `replicas` à pour permettre une mise à l'échelle temporaire lors des opérations de remplacement de nœuds.
+ Tenez compte de la capacité maximale requise lors de la dérive des nœuds ou des mises à jour de l'AMI lors de la définition des limites.
**Sélection de l'instance :**
+ Utilisez des types d'instances spécifiques lorsque vous avez des instances réservées ou des exigences matérielles spécifiques.
+ Évitez les exigences trop restrictives susceptibles de limiter la disponibilité des instances lors du dimensionnement.
**Gestion des perturbations :**
+ Configurez les budgets d'interruption appropriés pour équilibrer la disponibilité avec les opérations de maintenance.
+ Tenez compte de la tolérance de votre application en matière de remplacement de nœuds lors de la définition des pourcentages de budget.
**Surveillance :**
+ Surveillez régulièrement le `status.nodes` terrain pour vous assurer que la capacité souhaitée est maintenue.
+ Configurez des alertes lorsque le nombre réel de nœuds s'écarte des répliques souhaitées.
**Répartition des zones :**
+ Pour une haute disponibilité, répartissez la capacité statique sur plusieurs zones de disponibilité.
+ Lorsque vous créez un pool de nœuds à capacité statique qui couvre plusieurs zones de disponibilité, le mode automatique EKS distribue les nœuds dans les zones spécifiées, mais il n'est pas garanti que la distribution soit uniforme.
+ Pour une distribution prévisible et uniforme entre les zones de disponibilité, créez des pools de nœuds à capacité statique distincts, chacun étant épinglé à une zone de disponibilité spécifique conformément aux `topology.kubernetes.io/zone` exigences.
+ Si vous avez besoin de 12 nœuds répartis uniformément sur trois zones, créez trois pools de nœuds avec 4 répliques chacun, plutôt qu'un pool de nœuds avec 12 répliques sur trois zones.
## Dimensionner un pool de nœuds à capacité statique
Vous pouvez modifier le nombre de répliques dans un pool de nœuds à capacité statique à l'aide de la `kubectl scale` commande suivante :
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Lors de la réduction de la taille, le mode automatique d'EKS met fin aux nœuds de manière harmonieuse, en respectant PodDisruptionBudgets et en autorisant la replanification des pods en cours d'exécution vers les nœuds restants.
## Surveillez les pools de nœuds à capacité statique
Utilisez les commandes suivantes pour surveiller vos pools de nœuds à capacité statique :
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
Le `status.nodes` champ indique le nombre actuel de nœuds gérés par le pool de nœuds, qui devrait correspondre au `replicas` nombre souhaité dans des conditions normales.
## Résolution des problèmes
**Les nœuds n'atteignent pas les répliques souhaitées :**
+ Vérifiez si la `limits.nodes` valeur est suffisante
+ Vérifiez que vos exigences ne limitent pas trop la sélection d'instances
+ Vérifiez les quotas de AWS service pour les types d'instances et les régions que vous utilisez
**Le remplacement du nœud prend trop de temps :**
+ Ajustez les budgets d'interruption pour permettre un plus grand nombre de remplacements simultanés
+ Vérifiez si PodDisruptionBudgets vous empêchez la terminaison du nœud
**Arrêt inattendu du nœud :**
+ Vérifiez les `terminationGracePeriod` paramètres `expireAfter` et
+ Vérifiez la présence de terminaisons manuelles de nœuds ou AWS d'événements de maintenance
## Exemples
### Pool de nœuds à capacité statique de base
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Capacité statique avec des types d'instances spécifiques
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Pool de nœuds à capacité statique multizone
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Capacité statique avec réservation de capacité
L'exemple suivant montre comment utiliser un pool de nœuds à capacité statique avec une réservation de capacité EC2. Pour plus d'informations sur l'utilisation des réservations de capacité EC2 avec le mode automatique EKS, consultez[Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS](auto-odcr.md).
`NodeClass`définissant le `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`en faisant référence à ce qui précède `NodeClass` et en utilisant`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Créez un IngressClass pour configurer un Application Load Balancer
Le mode automatique EKS automatise les tâches courantes liées à l’équilibrage de charge, y compris l’exposition des applications du cluster à Internet.
AWS suggère d'utiliser des équilibreurs de charge d'application (ALB) pour gérer le trafic HTTP et HTTPS. Les équilibreurs de charge Application Load Balancer peuvent acheminer les requêtes en fonction de leur contenu. Pour plus d’informations sur les équilibreurs de charge Application Load Balancer, consultez [Qu’est-ce qu’un Application Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
Le mode automatique EKS crée et configure les équilibreurs de charge d'application ()ALBs. Par exemple, le mode automatique EKS crée un équilibreur de charge lorsque vous créez un objet Kubernetes `Ingress` et le configure pour acheminer le trafic vers votre charge de travail dans le cluster.
**Présentation**
1. Créez une charge de travail que vous souhaitez exposer à Internet.
1. Créez une `IngressClassParams` ressource en spécifiant AWS des valeurs de configuration spécifiques telles que le certificat à utiliser SSL/TLS et les sous-réseaux VPC.
1. Créez une ressource `IngressClass` en spécifiant que le mode automatique EKS sera le contrôleur utilisé pour cette ressource.
1. Créez une ressource `Ingress` qui associe un chemin et un port HTTP à une charge de travail du cluster.
Le mode automatique EKS créera un équilibreur de charge Application Load Balancer pointant vers la charge de travail définie dans la ressource `Ingress`, en utilisant la configuration définie dans la ressource `IngressClassParams`.
## Conditions préalables
+ Le mode automatique EKS activé sur un cluster Amazon EKS
+ Kubectl configuré pour se connecter à votre cluster
+ Vous pouvez utiliser `kubectl apply -f ` pour appliquer les exemples de fichiers YAML de configuration ci-dessous à votre cluster.
**Note**
Le mode automatique EKS nécessite l’ajout de balises sur les sous-réseaux afin d’identifier les sous-réseaux publics et privés.
Si vous avez créé votre cluster avec `eksctl`, ces balises sont déjà présentes.
Découvrez comment [Baliser les sous-réseaux pour le mode automatique EKS](tag-subnets-auto.md).
## Étape 1 : créer une charge de travail
Tout d’abord, créez une charge de travail que vous souhaitez exposer à Internet. Il peut s’agir de n’importe quelle ressource Kubernetes qui gère le trafic HTTP, telle qu’un déploiement ou un service.
Cet exemple utilise un service HTTP simple appelé `service-2048`, qui écoute sur le port `80`. Créez ce service et son déploiement en appliquant le manifeste `2048-deployment-service.yaml` suivant :
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Appliquez la configuration à votre cluster :
```
kubectl apply -f 2048-deployment-service.yaml
```
Les ressources répertoriées ci-dessus seront créées dans l’espace de noms par défaut. Vous pouvez le vérifier en exécutant la commande suivante :
```
kubectl get all -n default
```
## Étape 2 : créer IngressClassParams
Créez un `IngressClassParams` objet pour spécifier AWS des options de configuration spécifiques pour l'Application Load Balancer. Dans cet exemple, nous créons une ressource `IngressClassParams` nommée `alb` (qui sera utilisée à l’étape suivante), afin de définir le mode de fonctionnement de l’équilibreur de charge comme `internet-facing`, dans un fichier appelé `alb-ingressclassparams.yaml`.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Appliquez la configuration à votre cluster :
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Étape 3 : créer IngressClass
Créez un `IngressClass` qui fait référence aux valeurs de configuration AWS spécifiques définies dans la `IngressClassParams` ressource dans un fichier nommé`alb-ingressclass.yaml`. Notez le nom de la ressource `IngressClass`. Dans cet exemple, la ressource `IngressClass` et la ressource `IngressClassParams` portent toutes deux le nom `alb`.
Utilisez l’annotation `is-default-class` pour indiquer si les ressources `Ingress` doivent utiliser cette classe par défaut.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Pour plus d’informations sur les options de configuration, consultez [IngressClassParams Référence](#ingress-reference).
Appliquez la configuration à votre cluster :
```
kubectl apply -f alb-ingressclass.yaml
```
## Étape 4 : créer une ressource Ingress
Créez une ressource `Ingress` dans un fichier nommé `alb-ingress.yaml`. Le but de cette ressource est d’associer les chemins et les ports de l’équilibreur de charge Application Load Balancer aux charges de travail de votre cluster. Dans cet exemple, nous créons une ressource `Ingress` nommée `2048-ingress` qui achemine le trafic vers un service nommé `service-2048` sur le port 80.
Pour plus d’informations sur la configuration de cette ressource, consultez [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) dans la documentation Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Appliquez la configuration à votre cluster :
```
kubectl apply -f alb-ingress.yaml
```
## Étape 5 : vérifier l’état
Utilisez `kubectl` pour afficher l’état de la ressource `Ingress`. Il peut falloir quelques minutes pour que l’équilibreur de charge soit disponible.
Utilisez le nom de la ressource `Ingress` définie à l’étape précédente. Par exemple :
```
kubectl get ingress 2048-ingress
```
Une fois la ressource prête, extrayez le nom de domaine de l’équilibreur de charge.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Pour afficher le service dans un navigateur web, vérifiez le port et le chemin indiqués dans la résolution `Ingress`.
## Étape 6 : nettoyage
Pour nettoyer l’équilibreur de charge, utilisez la commande suivante :
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
Le mode automatique EKS supprimera automatiquement l'équilibreur de charge associé dans votre AWS compte.
## IngressClassParams Référence
Le tableau ci-dessous constitue une référence rapide des options de configuration les plus courantes.
| Champ | Description | Exemple de valeur |
| --- | --- | --- |
| `scheme` | Définit si l’ALB est interne ou orienté Internet | `internet-facing` |
| `namespaceSelector` | Limite les espaces de noms qui peuvent l'utiliser IngressClass | `environment: prod` |
| `group.name` | Regroupe plusieurs ressources Ingress pour partager un même ALB | `retail-apps` |
| `ipAddressType` | Définit le type d’adresse IP de l’ALB | `dualstack` |
| `subnets.ids` | Liste des sous-réseaux pour le déploiement IDs d'ALB | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Filtres de balises pour sélectionner les sous-réseaux destinés à l’ALB | `Environment: prod` |
| `certificateARNs` | ARNs de certificats SSL à utiliser | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Tags personnalisés pour les AWS ressources | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Attributs spécifiques à l’équilibreur de charge | `idle_timeout.timeout_seconds: 60` |
## Considérations
+ Vous ne pouvez pas utiliser les annotations sur et IngressClass pour configurer les équilibreurs de charge avec le mode automatique EKS. IngressClass la configuration doit être effectuée via IngressClassParams. Cependant, vous pouvez utiliser des annotations sur des ressources d'entrée individuelles pour configurer le comportement de l'équilibreur de charge (tel que `alb.ingress.kubernetes.io/security-group-prefix-lists` ou). `alb.ingress.kubernetes.io/conditions.*`
+ Vous ne pouvez pas effectuer de réglage [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)avec le mode automatique EKS.
+ Vous devez mettre à jour le rôle IAM du cluster pour permettre la propagation des balises depuis Kubernetes vers les ressources Load AWS Balancer. Pour de plus amples informations, veuillez consulter [AWS Balises personnalisées pour les ressources EKS Auto](auto-learn-iam.md#tag-prop).
+ Pour plus d'informations sur l'association de ressources au mode automatique EKS ou au AWS Load Balancer Controller autogéré, consultez. [Référence de migration](migrate-auto.md#migration-reference)
+ Pour plus d’informations sur la résolution des problèmes liés aux équilibreurs de charge, consultez [Résolution des problèmes avec le mode automatique EKS](auto-troubleshoot.md).
+ Pour des considérations supplémentaires concernant l’utilisation de la fonctionnalité d’équilibrage de charge du mode automatique EKS, consultez [Équilibrage de charge](auto-networking.md#auto-lb-consider).
Les tableaux suivants fournissent une comparaison détaillée des modifications IngressClassParams, des annotations d'entrée et des TargetGroupBinding configurations pour le mode automatique EKS. Ces tableaux mettent en évidence les principales différences entre la fonctionnalité d’équilibrage de charge du mode automatique EKS et le contrôleur d’équilibreur de charge open source, notamment l’évolution des versions d’API, les fonctionnalités obsolètes et les nouveaux noms de paramètres.
### IngressClassParams
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifications de version d’API |
| `spec.certificateArn` | `spec.certificateARNs` | Support pour plusieurs certificats ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Modification du schéma de correspondance des sous-réseaux |
| `spec.listeners.listenerAttributes` | Non pris en charge | Pas encore pris en charge par le mode automatique EKS |
### Annotations Ingress
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Non pris en charge | Utilisation de `spec.ingressClassName` sur les objets Ingress |
| `alb.ingress.kubernetes.io/group.name` | Non pris en charge | Spécifier les groupes dans IngressClass uniquement |
| `alb.ingress.kubernetes.io/waf-acl-id` | Non pris en charge | Utilisation de WAF v2 à la place |
| `alb.ingress.kubernetes.io/web-acl-id` | Non pris en charge | Utilisation de WAF v2 à la place |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Non pris en charge | Intégration Shield désactivée |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Non pris en charge | Type d’authentification OIDC non pris en charge actuellement |
### TargetGroupBinding
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifications de version d’API |
| `spec.targetType` facultatif | `spec.targetType` obligatoire | Spécifications explicite du type de cible |
| `spec.networking.ingress.from` | Non pris en charge | Ne prend plus en charge NLB sans groupes de sécurité |
Pour utiliser la TargetGroupBinding fonctionnalité personnalisée, vous devez étiqueter le groupe cible avec la eks-cluster-name balise eks : avec le nom du cluster afin d'accorder au contrôleur les autorisations IAM nécessaires. Sachez que le contrôleur supprimera le groupe cible lorsque la TargetGroupBinding ressource ou le cluster sera supprimé.
# Utilisation des annotations de service pour configurer les équilibreurs de charge Network Load Balancer
Découvrez comment configurer les équilibreurs de charge Network Load Balancer (NLB) dans Amazon EKS à l’aide des annotations du service Kubernetes. Cette rubrique décrit les annotations prises en charge par le mode automatique d'EKS pour personnaliser le comportement du NLB, notamment l'accessibilité à Internet, les bilans de santé, la SSL/TLS résiliation et les modes de ciblage IP.
Lorsque vous créez un service Kubernetes de type `LoadBalancer` EKS Auto Mode, EKS approvisionne et configure automatiquement un AWS Network Load Balancer en fonction des annotations que vous spécifiez. Cette approche déclarative vous permet de gérer les configurations des équilibreurs de charge directement via vos manifestes Kubernetes, conformément aux pratiques d’infrastructure en tant que code.
Le mode automatique EKS gère le provisionnement du Network Load Balancer par défaut pour tous les types LoadBalancer de services. Aucune installation ou configuration de contrôleur supplémentaire n'est requise. La spécification `loadBalancerClass: eks.amazonaws.com/nlb` est automatiquement définie comme valeur par défaut du cluster, simplifiant ainsi le déploiement et assurant la compatibilité avec les charges de travail Kubernetes existantes.
**Note**
Le mode automatique EKS nécessite l’ajout de balises sur les sous-réseaux afin d’identifier les sous-réseaux publics et privés.
Si vous avez créé votre cluster avec `eksctl`, ces balises sont déjà présentes.
Découvrez comment [Baliser les sous-réseaux pour le mode automatique EKS](tag-subnets-auto.md).
## Exemple de service
Pour plus d’informations sur la ressource Kubernetes `Service`, consultez la [documentation Kubernetes](https://kubernetes.io/docs/concepts/services-networking/service/).
Consultez l’exemple de ressource `Service` ci-dessous :
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Annotations couramment utilisées
Le tableau ci-dessous présente les annotations couramment utilisées et prises en charge par le mode automatique EKS. Notez que le mode automatique EKS ne prend pas en charge toutes les annotations existantes.
**Astuce**
Toutes les annotations suivantes doivent être préfixées par `service.beta.kubernetes.io/`
| Champ | Description | Exemple |
| --- | --- | --- |
| `aws-load-balancer-type` | Spécifie le type d’équilibreur de charge. Utilisez `external` pour les nouveaux déploiements. | `external` |
| `aws-load-balancer-nlb-target-type` | Spécifie s'il faut acheminer le trafic vers les instances de nœuds ou directement vers le pod IPs. Utilisez `instance` pour les déploiements standards ou `ip` pour un routage direct vers les pods. | `instance` |
| `aws-load-balancer-scheme` | Contrôle si l’équilibreur de charge est interne ou accessible depuis Internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protocole de surveillance de l’état pour le groupe cible. Les options courantes sont `TCP` (par défaut) ou `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Le chemin HTTP pour les contrôles de santé lors de l'utilisation HTTP/HTTPS du protocole. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Port utilisé pour la surveillance de l’état. Il peut s’agir d’un numéro de port spécifique ou du `traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Spécifie les sous-réseaux dans lesquels créer l’équilibreur de charge. Peut utiliser un sous-réseau IDs ou des noms. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN du certificat SSL fourni par Certificate Manager for HTTPS/TLS. AWS | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Spécifie les ports devant utiliser SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Plages CIDR autorisées à accéder à l’équilibreur de charge. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | AWS Balises supplémentaires à appliquer à l'équilibreur de charge et aux ressources associées. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Spécifie si l'équilibreur de charge utilise IPv4 ou double pile (IPv4 \$1 IPv6). | `ipv4` ou `dualstack` |
## Considérations
+ Vous devez mettre à jour le rôle IAM du cluster pour permettre la propagation des balises depuis Kubernetes vers les ressources Load AWS Balancer. Pour de plus amples informations, veuillez consulter [AWS Balises personnalisées pour les ressources EKS Auto](auto-learn-iam.md#tag-prop).
+ Pour plus d'informations sur l'association de ressources au mode automatique EKS ou au AWS Load Balancer Controller autogéré, consultez. [Référence de migration](migrate-auto.md#migration-reference)
+ Pour plus d’informations sur la résolution des problèmes liés aux équilibreurs de charge, consultez [Résolution des problèmes avec le mode automatique EKS](auto-troubleshoot.md).
+ Pour des considérations supplémentaires concernant l’utilisation de la fonctionnalité d’équilibrage de charge du mode automatique EKS, consultez [Équilibrage de charge](auto-networking.md#auto-lb-consider).
Lors de la migration vers le mode automatique EKS pour l’équilibrage de charge, plusieurs modifications concernant les annotations de service et la configuration des ressources sont nécessaires. Les tableaux suivants présentent les principales différences entre l’ancienne et la nouvelle mise en œuvre, incluant les options non prises en charge et les alternatives recommandées.
### Annotations de service
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Non pris en charge | Utiliser `spec.loadBalancerSourceRanges` sur le service |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Non pris en charge | Utiliser `spec.loadBalancerClass` sur le service |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Non pris en charge | Utilisation des `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` à la place |
| Divers attributs de l’équilibreur de charge | Non pris en charge | Utilisation des `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Non pris en charge | Utiliser `service.beta.kubernetes.io/aws-load-balancer-attributes` à la place |
Pour migrer à partir des annotations d’attributs d’équilibreur de charge désormais obsolètes, regroupez ces paramètres dans l’annotation `service.beta.kubernetes.io/aws-load-balancer-attributes`. Cette annotation accepte une liste de paires clé-valeur séparées par des virgules afin de définir plusieurs attributs de l’équilibreur de charge. Par exemple, pour spécifier la journalisation des accès et l'équilibrage de charge entre zones, utilisez le format suivant :
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Ce format consolidé offre une méthode plus cohérente et flexible pour configurer les attributs de l’équilibreur de charge, tout en réduisant le nombre d’annotations nécessaires. Passez en revue vos configurations de service existantes et mettez-les à jour pour utiliser ce format consolidé.
### TargetGroupBinding
| Précédent | Nouveau | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifications de version d’API |
| `spec.targetType` facultatif | `spec.targetType` obligatoire | Spécifications explicite du type de cible |
| `spec.networking.ingress.from` | Non pris en charge | Ne prend plus en charge NLB sans groupes de sécurité |
Remarque : Pour utiliser la TargetGroupBinding fonctionnalité personnalisée, vous devez étiqueter le groupe cible avec le `eks:eks-cluster-name` tag portant le nom du cluster afin d'accorder au contrôleur les autorisations IAM nécessaires. Sachez que le contrôleur supprimera le groupe cible lorsque la TargetGroupBinding ressource ou le cluster sera supprimé.
# Création d’une classe de stockage
Une `StorageClass` dans le mode automatique Amazon EKS définit la façon dont les volumes Amazon EBS sont automatiquement provisionnés lorsque les applications demandent du stockage persistant. Cette page explique comment créer et configurer une `StorageClass` compatible avec le mode automatique Amazon EKS pour le provisionnement de volumes EBS.
En configurant une `StorageClass`, vous pouvez définir les paramètres par défaut de vos volumes EBS, notamment le type de volume, le chiffrement, le nombre d’IOPS et d’autres paramètres liés au stockage. Vous pouvez également configurer le `StorageClass` pour utiliser les clés AWS KMS pour la gestion du chiffrement.
Le mode automatique EKS ne crée pas de `StorageClass` pour vous. Vous devez créer une `StorageClass` faisant référence à `ebs.csi.eks.amazonaws.com` pour utiliser les fonctionnalités de stockage du mode automatique EKS.
Tout d’abord, créez un fichier nommé `storage-class.yaml` :
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Ensuite, appliquez la classe de stockage à votre cluster.
```
kubectl apply -f storage-class.yaml
```
**Composants clés :**
+ `provisioner: ebs.csi.eks.amazonaws.com` : utilise le mode automatique EKS
+ `allowedTopologies` : en spécifiant `matchLabelExpressions` pour filtrer selon `eks.amazonaws.com/compute-type:auto`, vous vous assurez que si vos pods ont besoin qu’un volume soit automatiquement provisionné via le mode automatique, ceux-ci ne seront pas programmés sur des nœuds qui ne sont pas gérés par le mode automatique.
+ `volumeBindingMode: WaitForFirstConsumer` : retarde la création du volume jusqu’à ce qu’un pod en ait besoin
+ `type: gp3` : spécifie le type de volume EBS
+ `encrypted: "true"` : EBS chiffre tous les volumes créés avec la `StorageClass`. EBS utilisera l’alias de clé `aws/ebs` par défaut. Pour plus d’informations, consultez [Fonctionnement du chiffrement Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) dans le Guide de l’utilisateur Amazon EBS. Cette valeur est facultative, mais recommandée.
+ `storageclass.kubernetes.io/is-default-class: "true"` : Kubernetes utilisera cette classe de stockage par défaut, à moins que vous ne spécifiiez une autre classe de volume dans une demande de volume persistant. Cette valeur est facultative. Faites preuve de prudence lorsque vous définissez cette valeur si vous effectuez une migration depuis un autre contrôleur de stockage.
## Utilisation d’une clé KMS autogérée pour chiffrer les volumes EBS
Pour utiliser une clé KMS autogérée afin de chiffrer des volumes EBS automatisés par le mode automatique EKS, vous devez :
1. Créer une clé KMS autogérée.
+ Pour plus d’informations, consultez [Création d’une clé KMS de chiffrement symétrique](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) ou [Utilisation de KMS par Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html).
1. Créez une nouvelle politique permettant l’accès à la clé KMS.
+ Utilisez l’exemple de politique IAM ci-dessous comme modèle pour créer la politique. Insérez l’ARN de votre nouvelle clé KMS autogérée. Pour plus d'informations, consultez la section [Création de rôles et attachement de politiques (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) dans le guide de l'utilisateur AWS IAM.
1. Attachez la politique au rôle du cluster EKS.
+ Utilisez la AWS console pour trouver l'ARN du rôle de cluster EKS. Les informations relatives au rôle sont visibles dans la section **Présentation**. Pour de plus amples informations, veuillez consulter [Rôle IAM de cluster Amazon EKS](cluster-iam-role.md).
1. Mettez à jour la `StorageClass` pour faire référence à l’ID de la clé KMS dans le champ `parameters.kmsKeyId`.
### Exemple de politique IAM KMS autogérée
Mettez à jour les valeurs suivantes dans la politique ci-dessous :
+ ``— Votre identifiant de AWS compte, tel que `111122223333`
+ ``— La AWS région de votre cluster, telle que `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Exemple de `StorageClass` KMS autogérée
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## Référence des paramètres `StorageClass`
Pour des informations générales sur les ressources `StorageClass` de Kubernetes, consultez [Classes de stockage](https://kubernetes.io/docs/concepts/storage/storage-classes/) dans la documentation Kubernetes.
THe `parameters`section de la `StorageClass` ressource est spécifique à AWS. Utilisez le tableau ci-dessous pour consulter les options disponibles.
| Parameters | Valeurs | Par défaut | Description |
| --- | --- | --- | --- |
| « csi.storage.k8s.io/fstype » | xfs, ext2, ext3, ext4 | ext4 | Type de système de fichiers qui sera formaté lors de la création du volume. Ce paramètre n’est pas sensible à la casse \$1 |
| « type » | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | Type de volume EBS. |
| « iopsPerGB » | | | Nombre d’opérations d’E/S par seconde par Gio. Peut être spécifié pour IO1 IO2, et les GP3 volumes. |
| « Autoriser Auto IOPSPer GBIncrease » | true, false | false | Lorsque `"true"` le pilote CSI augmente le nombre d'IOPS pour un volume trop faible pour correspondre à la plage d'IOPS prise en charge par. `iopsPerGB * ` AWS Cela permet au provisionnement dynamique de réussir en tout temps, même si l’utilisateur spécifie une capacité PVC trop faible ou une valeur `iopsPerGB` insuffisante. Cependant, cette fonctionnalité peut entraîner des coûts plus élevés, car ces volumes obtiennent un niveau d’IOPS supérieur à celui demandé dans `iopsPerGB`. |
| « iops » | | | Nombre d’opérations d’E/S par seconde. Peut être spécifié pour IO1 IO2, et les GP3 volumes. |
| « throughput » | | 125 | Le débit est exprimé en Mio/s. Efficace uniquement lorsque le type de volume gp3 est spécifié. |
| « encrypted » | true, false | false | Indique si le volume doit être chiffré ou non. Les valeurs valides sont « true » ou « false ». |
| « blockExpress » | true, false | false | Permet la création de volumes io2 Block Express. |
| "kmsKeyId" | | | ARN complet de la clé à utiliser pour chiffrer le volume. Si elle n'est pas spécifiée, AWS utilisera la clé KMS par défaut pour la région dans laquelle se trouve le volume. Si elle n’a pas été modifiée, cette clé autogénérée s’appelera `/aws/ebs`. |
| « blockSize » | | | Taille des blocs utilisée lors du formatage du système de fichiers sous-jacent. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3`, `ext4` ou `xfs`. |
| « inodeSize » | | | Taille des inodes utilisée lors du formatage du système de fichiers. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3`, `ext4` ou `xfs`. |
| "bytesPerInode" | | | Nombre de `bytes-per-inode` utilisé lors du formatage du système de fichiers sous-jacent. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3` et `ext4`. |
| "numberOfInodes" | | | Nombre de `number-of-inodes` utilisé lors du formatage du système de fichiers sous-jacent. Prise en charge uniquement sur les nœuds Linux et pour les types de systèmes de fichiers `ext2`, `ext3` et `ext4`. |
| « poste 4 BigAlloc » | true, false | false | Modifie le système de fichiers `ext4` pour activer l’allocation de blocs en clusters en utilisant l’option de formatage `bigalloc`. Avertissement : `bigalloc` peut ne pas être entièrement pris en charge par le noyau Linux de vos nœuds. |
| « poste 4 ClusterSize » | | | Taille des clusters utilisée lors du formatage d’un système de fichiers `ext4` lorsque la fonctionnalité `bigalloc` est activée. Remarque : le paramètre `ext4BigAlloc` doit être défini sur true. |
Pour plus d'informations, voir le [pilote AWS EBS CSI activé](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md). GitHub
## Considérations
**Note**
Vous pouvez uniquement déployer des charges de travail en fonction du mode automatique EKS StorageClasses sur les nœuds du mode automatique EKS. Si votre cluster comporte différents types de nœuds, vous devez configurer vos charges de travail afin qu’elles s’exécutent uniquement sur les nœuds du mode automatique EKS. Pour de plus amples informations, veuillez consulter [Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS](associate-workload.md).
La capacité de stockage par blocs du mode automatique EKS est différente de celle du pilote CSI EBS.
+ Provisionnement statique
+ Si vous souhaitez utiliser des volumes EBS créés en externe avec le mode automatique EKS, vous devez ajouter manuellement une AWS balise avec la clé `eks:eks-cluster-name` et la valeur du nom du cluster.
+ Rejet de démarrage des nœuds
+ Vous ne pouvez pas utiliser la fonctionnalité de rejet de démarrage des nœuds pour empêcher la planification des pods avant que la capacité de stockage ne soit prête
+ Balises personnalisées sur les volumes provisionnés dynamiquement
+ Vous ne pouvez pas utiliser le paramètre CLI extra-tag pour configurer des balises personnalisées sur les volumes EBS provisionnés dynamiquement
+ Vous pouvez utiliser le balisage `StorageClass` pour ajouter des balises personnalisées. Le mode automatique EKS ajoutera des balises aux AWS ressources associées. Vous devrez mettre à jour le rôle IAM du cluster afin d’utiliser des balises personnalisées. Pour de plus amples informations, veuillez consulter [AWS Balises personnalisées pour les ressources EKS Auto](auto-learn-iam.md#tag-prop).
+ Métriques de performances détaillées d’EBS
+ Vous ne pouvez pas accéder aux métriques Prometheus pour les performances détaillées d’EBS
## Installation du module complémentaire CSI Snapshot Controller
Le mode automatique EKS est compatible avec le module complémentaire Amazon EKS CSI Snapshot Controller.
AWS vous suggère de configurer ce module complémentaire pour qu'il s'exécute sur le pool de `system` nœuds intégré.
Pour en savoir plus, consultez :
+ [Exécutez les modules complémentaires critiques sur des instances dédiées.](critical-workload.md)
+ [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md)
+ [Activer la fonctionnalité d’instantané pour les volumes CSI](csi-snapshot-controller.md)
### Pour installer le contrôleur d’instantané dans le groupe de nœuds système
1. Ouvrez votre cluster EKS dans la AWS console
1. Dans l’onglet **Modules complémentaires**, sélectionnez **Obtenir plus de modules complémentaires**
1. Sélectionnez le module **CSI Snapshot Controller**, puis **Suivant**
1. Sur la page **Configurer les paramètres des modules complémentaires sélectionnés**, sélectionnez **Paramètres de configuration facultatifs** pour afficher le **schéma de configuration des modules complémentaires**
1. Insérez le fichier YAML suivant pour associer le contrôleur d’instantané au groupe de nœuds `system`. Le contrôleur d’instantané inclut une tolérance pour le rejet `CriticalAddonsOnly`.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Sélectionnez **Suivant**
1. Vérifier la configuration du module complémentaire, puis sélectionnez **Créer**
# Désactivation du mode automatique EKS
Vous pouvez désactiver le mode automatique EKS sur un cluster EKS existant. Cette opération est destructrice.
+ EKS mettra fin à toutes les EC2 instances gérées par le mode automatique EKS.
+ EKS supprime tous les équilibreurs de charge gérés par le mode automatique EKS.
+ EKS **ne** supprime pas les volumes EBS provisionnés par le mode automatique EKS.
Le mode automatique EKS est conçu pour gérer entièrement les ressources qu’il crée. Toute intervention manuelle peut empêcher le mode automatique EKS de nettoyer correctement ces ressources lors de sa désactivation. Par exemple, si vous faites référence à un groupe de sécurité géré depuis des règles d’un groupe de sécurité externe et que vous oubliez de supprimer cette référence avant de désactiver le mode automatique EKS pour un cluster, le groupe de sécurité géré peut ne pas être supprimé (fuite de ressource). Les étapes ci-dessous expliquent comment supprimer un groupe de sécurité ayant fui.
## Désactiver le mode automatique EKS (AWS console)
1. Ouvrez la page de présentation de votre cluster dans la AWS Management Console.
1. Sous **Mode automatique EKS**, sélectionnez **Gérer**
1. Basculez **Mode automatique EKS** sur `off`.
Si un groupe de sécurité géré n’est pas supprimé à la fin du processus, vous pouvez le supprimer manuellement en suivant les instructions de la section [Suppression d’un groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Désactiver le mode automatique EKS (AWS CLI)
Utilisez la commande suivante pour désactiver le mode automatique EKS sur un cluster existant.
La CLI `aws` doit être installée et vous devez être connecté avec des autorisations suffisantes pour gérer les clusters EKS. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
**Note**
Les capacités de calcul, de stockage bloc et d’équilibrage de charge doivent toutes être activées ou désactivées dans la même requête.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Vous pouvez vérifier si un groupe de sécurité géré par le mode automatique EKS n’a pas été supprimé après la désactivation en procédant comme suit :
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Pour supprimer ensuite le groupe de sécurité :
```
aws ec2 delete-security-group --group-name=
```
# Mise à jour de la version Kubernetes d’un cluster du mode automatique Amazon EKS
Cette rubrique explique comment mettre à jour la version Kubernetes de votre cluster du mode automatique. Le mode automatique EKS simplifie le processus de mise à jour en gérant la coordination entre la mise à jour du plan de contrôle et le remplacement des nœuds, tout en préservant la disponibilité des charges de travail grâce aux budgets d’interruption des pods.
Lors de la mise à niveau d’un cluster du mode automatique EKS, de nombreux composants traditionnellement mis à jour manuellement sont désormais gérés automatiquement par le service. La compréhension des aspects automatisés du processus de mise à jour et de vos responsabilités permet d’assurer une transition fluide entre les versions de votre cluster.
## Informations sur les mises à jour avec le mode automatique EKS
Une fois la mise à niveau du plan de contrôle lancée, le mode automatique EKS procède à la mise à jour des nœuds de votre cluster. Au fur et à mesure que les anciens nœuds arrivent à expiration, le mode automatique EKS les remplace par de nouveaux nœuds. Les nouveaux nœuds exécutent la nouvelle version Kubernetes correspondante. Le mode automatique EKS respecte les budgets d’interruption des pods pendant le processus de mise à jour des nœuds.
De plus, il n’est plus nécessaire de mettre à jour manuellement certains composants tels que :
+ CNI Amazon VPC
+ Contrôleur de l'équilibreur de charge AWS
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ Pilote AWS EBS CSI
Le mode automatique EKS remplace ces composants par des fonctionnalités de service intégrées.
Vous restez toutefois responsable de la mise à jour des éléments suivants :
+ Applications et charges de travail déployées sur votre cluster
+ Modules complémentaires et contrôleurs autogérés
+ Modules complémentaires Amazon EKS
+ Découvrez comment… [Mettre à jour un module complémentaire Amazon EKS](updating-an-add-on.md)
Découvrez les [bonnes pratiques pour les mises à niveau des clusters](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Démarrage de la mise à jour du cluster
Pour démarrer la mise à jour d’un cluster, consultez [Mettre à jour un cluster existant vers une nouvelle version de Kubernetes](update-cluster.md).
# Activer ou désactiver la fonction intégrée NodePools
Le mode automatique EKS en possède deux intégrés NodePools. Vous pouvez les activer ou les désactiver à NodePools l'aide de la AWS console, de la CLI ou de l'API.
## NodePool Référence intégrée
+ `system`
+ Cela NodePool a une `CriticalAddonsOnly` odeur. De nombreux modules complémentaires EKS, tels que CoreDNS, tolèrent ce rejet. Utilisez ce groupe de nœuds système pour séparer les applications critiques du cluster.
+ Prend en charge les architectures `amd64` et `arm64`.
+ `general-purpose`
+ Cela NodePool permet de lancer des nœuds pour des charges de travail générales dans votre cluster.
+ Utilise uniquement l’architecture `amd64`.
Les deux sont intégrés NodePools :
+ Utiliser l'EKS par défaut NodeClass
+ Utiliser uniquement la EC2 capacité à la demande
+ Utiliser les familles d' EC2 instances C, M et R
+ Exiger des EC2 instances de génération 5 ou plus récentes
**Note**
L'activation d'au moins une fonction intégrée NodePool est requise pour qu'EKS puisse configurer la « valeur par défaut » NodeClass. Si vous désactivez toutes les NodePools fonctionnalités intégrées, vous devrez créer une personnalisation NodeClass et en configurer une NodePool pour l'utiliser. Pour plus d'informations sur NodeClasses, voir[Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
## Procédure
### Conditions préalables
+ La dernière version de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil. Pour vérifier votre version actuelle, utilisez `aws --version`. Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et [configuration rapide](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) avec aws configure dans le Guide de l'utilisateur de l'interface de ligne de AWS commande.
+ Connectez-vous à la CLI avec des autorisations IAM suffisantes pour créer des AWS ressources, notamment des politiques IAM, des rôles IAM et des clusters EKS.
### Activer avec la AWS CLI
Utilisez la commande suivante pour activer les deux fonctions intégrées NodePools :
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Vous pouvez modifier la commande pour activer de manière sélective le NodePools.
### Désactiver avec la AWS CLI
Utilisez la commande suivante pour désactiver les deux fonctions intégrées NodePools :
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS
Lors de l’exécution de charges de travail dans un cluster EKS utilisant le mode automatique EKS, il peut être nécessaire de contrôler si certaines charges de travail doivent s’exécuter sur des nœuds du mode automatique EKS ou sur d’autres types de calcul. Cette section explique comment utiliser des sélecteurs de nœuds et des règles d’affinité pour garantir que vos charges de travail soient planifiées sur l’infrastructure de calcul souhaitée.
Les exemples de cette rubrique montrent comment utiliser l’étiquette `eks.amazonaws.com/compute-type` pour imposer ou empêcher le déploiement d’une charge de travail sur les nœuds du mode automatique EKS. Cette approche est particulièrement utile dans les clusters en mode mixte, où vous utilisez à la fois le mode automatique EKS et d’autres types de calcul, tels que les fournisseurs Karpenter autogérés ou les groupes de nœuds gérés par EKS.
Les nœuds du mode automatique EKS définissent l’étiquette `eks.amazonaws.com/compute-type` sur `auto`. Vous pouvez utiliser cette étiquette pour contrôler si une charge de travail est déployée sur des nœuds gérés par le mode automatique EKS.
## Exigence de déploiement d’une charge de travail sur les nœuds du mode automatique EKS
**Note**
Cette valeur `nodeSelector` n’est pas obligatoire pour le mode automatique EKS. Cette valeur `nodeSelector` n’est pertinente que si vous exécutez un cluster en mode mixte, avec des types de nœuds non gérés par le mode automatique EKS. Par exemple, un cluster peut combiner une capacité de calcul statique fournie par les groupes de nœuds gérés par EKS et une capacité dynamique fournie par le mode automatique EKS.
Vous pouvez ajouter ce `nodeSelector` aux déploiements ou à d’autres charges de travail afin d’indiquer à Kubernetes à les planifier exclusivement sur des nœuds du mode automatique EKS.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Exigence de non-déploiement d’une charge de travail sur les nœuds du mode automatique EKS
Vous pouvez ajouter ce `nodeAffinity` aux déploiements ou à d’autres charges de travail afin d’indiquer à Kubernetes de **ne pas** les planifier sur des nœuds du mode automatique EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Exécutez les modules complémentaires critiques sur des instances dédiées.
Dans cette rubrique, vous apprendrez comment déployer une charge de travail avec une tolérance `CriticalAddonsOnly` afin que le mode automatique EKS la planifie sur le pool de nœuds `system`.
Le pool de nœuds `system` intégré au mode automatique EKS est conçu pour exécuter des modules complémentaires essentiels sur des instances dédiées. Cette séparation garantit que les composants essentiels disposent de ressources dédiées et sont isolés des charges de travail générales, ce qui améliore la stabilité et les performances globales du cluster.
Ce guide explique comment déployer des modules complémentaires dans le pool de nœuds `system` en utilisant la tolérance `CriticalAddonsOnly` et les sélecteurs de nœuds appropriés. En suivant ces étapes, vous pouvez vous assurer que vos applications critiques sont planifiées sur les nœuds `system` dédiés, en tirant parti des avantages en termes d’isolation et d’allocation des ressources offerts par la structure de pool de nœuds spécialisée du mode automatique EKS.
Le mode automatique EKS dispose de deux pools de nœuds intégrés : `general-purpose` et `system`. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
Le but du pool de nœuds `system` est de séparer les modules complémentaires critiques sur différents nœuds. Les nœuds provisionnés par le pool de nœuds `system` ont un rejet Kubernetes `CriticalAddonsOnly`. Kubernetes ne planifiera les pods sur ces nœuds que s’ils ont une tolérance correspondante. Pour plus d’informations, consultez [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation de Kubernetes.
## Prérequis
+ Le cluster du mode automatique EKS avec le groupe de nœuds `system` intégré activé. Pour plus d’informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
+ `kubectl` installé et configuré. Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).
## Procédure
Consultez l’exemple YAML ci-dessous. Notez les configurations suivantes :
+ `nodeSelector`— Cela associe la charge de travail au pool de nœuds `system` intégré. Ce pool de nœuds doit être activé avec l’API AWS. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
+ `tolerations` : cette tolérance permet de surmonter le rejet `CriticalAddonsOnly` des nœuds dans le groupe de nœuds `system`.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Pour mettre à jour une charge de travail afin qu’elle s’exécute sur le pool de nœuds `system`, vous devez :
1. Mettez à jour la charge de travail existante pour ajouter les configurations suivantes décrites ci-dessus :
+ `nodeSelector`
+ `tolerations`
1. Déployez la charge de travail mise à jour sur votre cluster avec `kubectl apply`
Une fois la charge de travail mise à jour, elle s’exécutera sur des nœuds dédiés.
# Utilisation des politiques réseau avec le mode automatique EKS
## Présentation de
À mesure que les clients adaptent leurs environnements applicatifs à l'aide d'EKS, l'isolation du trafic réseau devient de plus en plus fondamentale pour empêcher tout accès non autorisé aux ressources à l'intérieur et à l'extérieur du cluster. Cela est particulièrement important dans un environnement mutualisé dans lequel plusieurs charges de travail indépendantes s'exécutent côte à côte dans le cluster. Les politiques réseau Kubernetes vous permettent d'améliorer le niveau de sécurité du réseau pour vos charges de travail Kubernetes, ainsi que leur intégration avec les points de terminaison externes au cluster. Le mode automatique EKS prend en charge différents types de politiques réseau.
### Isolation des couches 3 et 4
Les politiques réseau standard de Kubernetes s'appliquent aux couches 3 et 4 du modèle de réseau OSI et vous permettent de contrôler le flux de trafic au niveau de l'adresse IP ou du port au sein de votre cluster Amazon EKS.
#### Cas d’utilisation
+ Segmentez le trafic réseau entre les charges de travail afin de garantir que seules les applications associées puissent communiquer entre elles.
+ Isolez les locataires au niveau de l'espace de noms à l'aide de politiques visant à appliquer la séparation des réseaux.
### Application basée sur le DNS
Les clients déploient généralement des charges de travail dans EKS qui font partie d'un environnement distribué plus large, dont certaines doivent communiquer avec des systèmes et des services extérieurs au cluster (trafic en direction du nord). Ces systèmes et services peuvent être hébergés dans le AWS cloud ou AWS totalement externes. Les politiques basées sur le système de noms de domaine (DNS) vous permettent de renforcer votre posture de sécurité en adoptant une approche plus stable et prévisible pour empêcher tout accès non autorisé des pods aux ressources ou points de terminaison externes au cluster. Ce mécanisme élimine le besoin de suivre manuellement et d'autoriser la création de listes d'adresses IP spécifiques. En sécurisant les ressources grâce à une approche basée sur le DNS, vous bénéficiez également d'une plus grande flexibilité pour mettre à jour l'infrastructure externe sans avoir à assouplir votre posture de sécurité ou à modifier les politiques réseau en cas de modifications apportées aux serveurs et hôtes en amont. Vous pouvez filtrer le trafic sortant vers des points de terminaison externes à l'aide d'un nom de domaine complet (FQDN) ou d'un modèle de correspondance pour un nom de domaine DNS. Cela vous donne la flexibilité supplémentaire d'étendre l'accès à plusieurs sous-domaines associés à un point de terminaison externe au cluster particulier.
#### Cas d’utilisation
+ Utilisez une approche basée sur le DNS pour filtrer l'accès depuis un environnement Kubernetes vers des points de terminaison externes au cluster.
+ Accès sécurisé aux AWS services dans un environnement mutualisé.
+ Gérez l'accès au réseau, des modules aux charges de travail sur site dans vos environnements de cloud hybride.
### Règles relatives à l'administration (ou à l'échelle du cluster)
Dans certains cas, tels que les scénarios multi-locataires, les clients peuvent avoir besoin d'appliquer une norme de sécurité réseau qui s'applique à l'ensemble du cluster. Au lieu de définir et de gérer de manière répétitive une politique distincte pour chaque espace de noms, vous pouvez utiliser une seule stratégie pour gérer de manière centralisée les contrôles d'accès au réseau pour les différentes charges de travail du cluster, quel que soit leur espace de noms. Ces types de politiques vous permettent d'étendre le champ d'application des règles de filtrage de votre réseau appliquées aux couches 3, 4 et lors de l'utilisation des règles DNS.
#### Cas d’utilisation
+ Gérez de manière centralisée les contrôles d'accès au réseau pour toutes les charges de travail (ou un sous-ensemble de celles-ci) de votre cluster EKS.
+ Définissez une posture de sécurité réseau par défaut sur l'ensemble du cluster.
+ Étendez les normes de sécurité organisationnelles à l'étendue du cluster de manière plus efficace sur le plan opérationnel.
## Prise en main
### Conditions préalables
+ Cluster Amazon EKS avec le mode automatique EKS activé
+ kubectl configuré pour se connecter à votre cluster
### Étape 1 : activer le contrôleur de politiques réseau
Pour utiliser les politiques réseau avec le mode automatique EKS, vous devez d'abord activer le Network Policy Controller en appliquant un ConfigMap à votre cluster.
1. Créez un fichier nommé `enable-network-policy.yaml` avec le contenu suivant:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Appliquez le ConfigMap à votre cluster :
```
kubectl apply -f enable-network-policy.yaml
```
### Étape 2 : créer et tester des politiques réseau
Votre cluster du mode automatique EKS est maintenant configuré pour prendre en charge les politiques réseau Kubernetes. Vous pouvez tester cette configuration à l’aide de [Démonstration des politiques réseau pour Amazon EKS](network-policy-stars-demo.md).
### Étape 3 : ajuster la configuration de l'agent de politique réseau dans la classe de nœuds (facultatif)
Vous pouvez éventuellement créer une nouvelle classe de nœuds pour modifier le comportement par défaut de l'agent de stratégie réseau sur les nœuds ou activer la journalisation des événements de politique réseau. Pour cela, procédez comme suit :
1. Créez ou modifiez un fichier YAML de classe de nœud (par exemple, `nodeclass-network-policy.yaml`) avec le contenu suivant :
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Appliquez la configuration de la classe de nœuds à votre cluster :
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Vérifiez que la classe de nœuds a été créée :
```
kubectl get nodeclass network-policy-config
```
1. Mettez à jour votre groupe de nœuds pour utiliser cette classe de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## Fonctionnement
### Politique réseau basée sur le DNS
![\[Illustration du flux de travail lorsqu'une politique basée sur le DNS est appliquée dans EKS Auto\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Illustration du flux de travail lorsqu'une politique basée sur le DNS est appliquée dans EKS Auto\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/apply-dns-policy-2.png)
1. L'équipe de la plateforme applique une politique basée sur le DNS au cluster EKS.
1. Le Network Policy Controller est chargé de surveiller la création de politiques au sein du cluster, puis de réconcilier les points de terminaison des politiques. Dans ce cas d'utilisation, le contrôleur de stratégie réseau demande à l'agent du nœud de filtrer les demandes DNS en fonction des domaines autorisés dans la politique créée. Les noms de domaine sont autorisés à l'aide du nom de domaine complet ou d'un nom de domaine correspondant à un modèle défini dans la configuration des ressources Kubernetes.
1. La charge de travail A tente de résoudre l'adresse IP d'un point de terminaison externe au cluster. La demande DNS passe d'abord par un proxy qui filtre ces demandes en fonction de la liste d'autorisation appliquée par le biais de la politique réseau.
1. Une fois que la demande DNS passe par la liste d'autorisation du filtre DNS, elle est transmise par proxy à CoreDNS,
1. CoreDNS envoie à son tour la demande au résolveur DNS externe (Amazon Route 53 Resolver) pour obtenir la liste des adresses IP sous-jacentes au nom de domaine.
1. Les données résolues IPs avec TTL sont renvoyées dans la réponse à la demande DNS. Ils IPs sont ensuite écrits dans une carte eBPF qui est utilisée à l'étape suivante pour l'application de la couche IP.
1. Les sondes eBPF connectées à l'interface Pod veth filtreront ensuite le trafic sortant de la charge de travail A vers le point de terminaison externe au cluster en fonction des règles en place. Cela garantit que les pods ne peuvent envoyer du trafic externe au cluster que vers les domaines autorisés IPs répertoriés. Leur validité IPs est basée sur le TTL extrait du résolveur DNS externe (Amazon Route 53 Resolver).
#### Utilisation de la politique du réseau d'applications
Il `ApplicationNetworkPolicy` combine les fonctionnalités des politiques réseau standard de Kubernetes avec le filtrage basé sur le DNS au niveau de l'espace de noms en utilisant une seule définition de ressource personnalisée (CRD). Par conséquent, `ApplicationNetworkPolicy` ils peuvent être utilisés pour :
1. Définition des restrictions au niveau des couches 3 et 4 de la pile réseau à l'aide de blocs IP et de numéros de port.
1. Définir des règles qui s'appliquent à la couche 7 de la pile réseau et vous permettre de filtrer le trafic en fonction de FQDNs.
**Important**
Les règles basées sur le DNS définies à l'aide du `ApplicationNetworkPolicy` ne s'appliquent qu'aux charges de travail exécutées dans des instances EC2 lancées en mode EKS Auto. `ApplicationNetworkPolicy`prend en charge tous les champs du Kubernetes standard`NetworkPolicy`, avec un filtre FQDN supplémentaire pour les règles de sortie.
**Avertissement**
N'utilisez pas le même nom pour un `ApplicationNetworkPolicy` et un `NetworkPolicy` dans le même espace de noms. Si les noms entrent en collision, les `PolicyEndpoints` objets obtenus risquent de ne pas refléter correctement l'une ou l'autre des politiques. Les deux ressources sont acceptées sans erreur, ce qui rend ce problème difficile à diagnostiquer.
Pour résoudre un conflit de dénomination, renommez les objets `ApplicationNetworkPolicy` ou renommez-les de `NetworkPolicy` manière à ce qu'ils soient uniques dans l'espace de noms, puis vérifiez que les `PolicyEndpoints` objets correspondants sont correctement mis à jour.
#### Exemple
Dans votre cluster EKS Auto Mode, vous avez une charge de travail qui doit communiquer avec une application sur site située derrière un équilibreur de charge portant un nom DNS. Vous pouvez y parvenir en appliquant la politique réseau suivante :
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Au niveau du réseau Kubernetes, cela permettrait de sortir de tous les pods de l'espace de noms « galaxy » étiqueté avec `role: backend` pour se connecter au nom de domaine **myapp.mydomain.com** sur le port TCP 8080. En outre, vous devez configurer la connectivité réseau pour le trafic sortant de votre VPC vers le centre de données de votre entreprise.
![\[Illustration de la charge de travail dans EKS Auto communiquant avec les applications sur site\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Politique réseau de l'administrateur (ou du cluster)
![\[illustration de l'ordre d'évaluation des politiques réseau dans EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/images/evaluation-order.png)
#### Utilisation de la politique réseau du cluster
Lorsque vous utilisez un`ClusterNetworkPolicy`, les politiques du niveau administrateur sont évaluées en premier et ne peuvent pas être remplacées. Lorsque les politiques de niveau administrateur ont été évaluées, les politiques délimitées par espace de noms standard sont utilisées pour exécuter les règles de segmentation du réseau appliquées. Cela peut être accompli en utilisant l'un `ApplicationNetworkPolicy` ou l'autre`NetworkPolicy`. Enfin, les règles du niveau de référence qui définissent les restrictions réseau par défaut pour les charges de travail des clusters seront appliquées. Ces règles du niveau de base **peuvent** être remplacées par les politiques délimitées de l'espace de noms si nécessaire.
#### Exemple
Votre cluster contient une application que vous souhaitez isoler des charges de travail des autres locataires. Vous pouvez bloquer explicitement le trafic du cluster en provenance d'autres espaces de noms pour empêcher l'accès réseau à l'espace de noms de charge de travail sensible.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Considérations
### Comprendre l'ordre d'évaluation des politiques
Les fonctionnalités de politique réseau prises en charge dans EKS sont évaluées dans un ordre spécifique afin de garantir une gestion du trafic prévisible et sécurisée. Il est donc important de comprendre le flux d'évaluation afin de concevoir une posture de sécurité réseau efficace pour votre environnement.
1. **Politiques du niveau administrateur (évaluées en premier)** : toutes les politiques du niveau administrateur ClusterNetworkPolicies sont évaluées avant les autres politiques. Au niveau administrateur, les politiques sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Le type d'action détermine ce qui se passe ensuite.
+ **Refuser l'action (priorité la plus élevée)** : lorsqu'une politique d'administration associée à une action de refus correspond au trafic, ce trafic est immédiatement bloqué, quelles que soient les autres politiques. Aucune autre ClusterNetworkPolicy NetworkPolicy règle n'est traitée. Cela garantit que les contrôles de sécurité à l'échelle de l'organisation ne peuvent pas être remplacés par des politiques au niveau de l'espace de noms.
+ **Autoriser l'action** : une fois les règles de refus évaluées, les politiques d'administration comportant des actions d'autorisation sont traitées par ordre de priorité (le numéro de priorité le plus bas en premier). Lorsqu'une action Autoriser correspond, le trafic est accepté et aucune autre évaluation de politique n'est effectuée. Ces politiques peuvent accorder l'accès à plusieurs espaces de noms en fonction de sélecteurs d'étiquettes, offrant ainsi un contrôle centralisé des charges de travail pouvant accéder à des ressources spécifiques.
+ **Action de transfert** : les actions de transfert prévues dans les politiques du niveau administrateur délèguent la prise de décision aux niveaux inférieurs. Lorsque le trafic correspond à une règle Pass, l'évaluation ignore toutes les règles de niveau administrateur restantes pour ce trafic et passe directement au NetworkPolicy niveau. Cela permet aux administrateurs de déléguer explicitement le contrôle de certains modèles de trafic aux équipes d'application. Par exemple, vous pouvez utiliser les règles Pass pour déléguer la gestion du trafic intra-espace à des administrateurs d'espaces de noms tout en maintenant des contrôles stricts sur l'accès externe.
1. **Niveau de politique réseau** : si aucune politique de niveau administrateur ne correspond à Deny ou Allow, ou si une action Pass correspond, les NetworkPolicy ressources traditionnelles ApplicationNetworkPolicy et limitées à l'espace de noms sont ensuite évaluées. Ces politiques fournissent un contrôle précis au sein des espaces de noms individuels et sont gérées par les équipes d'application. Les politiques étendues à l'espace de noms ne peuvent être que plus restrictives que les politiques d'administration. Ils ne peuvent pas annuler la décision de refus d'une politique d'administration, mais ils peuvent restreindre davantage le trafic autorisé ou approuvé par les politiques d'administration.
1. **Politiques d'administration du niveau de référence** : si aucune politique d'administration ou limitée à un espace de noms ne correspond au trafic, le niveau de référence est évalué. ClusterNetworkPolicies Ils fournissent des postures de sécurité par défaut qui peuvent être remplacées par des politiques délimitées par des espaces de noms, permettant aux administrateurs de définir des valeurs par défaut à l'échelle de l'organisation tout en donnant aux équipes la flexibilité de les personnaliser selon les besoins. Les politiques de base sont évaluées par ordre de priorité (le numéro de priorité le plus bas en premier).
1. **Refus par défaut (si aucune politique ne correspond)** : ce deny-by-default comportement garantit que seules les connexions explicitement autorisées sont autorisées, garantissant ainsi un niveau de sécurité élevé.
### Appliquer le principe du moindre privilège
+ **Commencez par des politiques restrictives et ajoutez progressivement des autorisations selon les besoins** : commencez par mettre en œuvre des deny-by-default politiques au niveau du cluster, puis ajoutez progressivement des règles d'autorisation au fur et à mesure que vous validez les exigences de connectivité légitimes. Cette approche oblige les équipes à justifier explicitement chaque connexion externe, créant ainsi un environnement plus sécurisé et plus contrôlable.
+ **Auditez régulièrement et supprimez les règles de politique non utilisées** : les politiques réseau peuvent s'accumuler au fil du temps à mesure que les applications évoluent, laissant derrière elles des règles obsolètes qui étendent inutilement votre surface d'attaque. Mettez en œuvre un processus de révision régulier pour identifier et supprimer les règles de politique qui ne sont plus nécessaires, afin de garantir que votre posture de sécurité reste stricte et maintenable.
+ **Utilisez des noms de domaine spécifiques plutôt que des modèles généraux lorsque cela est possible**. Si les modèles génériques sont pratiques, ils `*.amazonaws.com` permettent également d'accéder à un large éventail de services. Dans la mesure du possible, spécifiez des noms de domaine exacts, par exemple `s3.us-west-2.amazonaws.com` pour limiter l'accès aux seuls services spécifiques dont vos applications ont besoin, réduisant ainsi le risque de déplacement latéral si une charge de travail est compromise.
### Utilisation de politiques basées sur le DNS dans EKS
+ Les règles basées sur le DNS définies à l'aide du `ApplicationNetworkPolicy` ne s'appliquent qu'aux charges de travail exécutées dans des instances EC2 lancées en mode EKS Auto. Si vous utilisez un cluster en mode mixte (composé à la fois de nœuds de travail EKS Auto et de nœuds de travail non EKS Auto), vos règles basées sur le DNS ne sont efficaces que dans les nœuds de travail en mode automatique d'EKS (instances gérées EC2).
### Validation de vos politiques DNS
+ **Utilisez des clusters intermédiaires qui reflètent la topologie du réseau de production pour les tests** - Votre environnement intermédiaire doit reproduire l'architecture réseau, les dépendances externes et les modèles de connectivité de production afin de garantir des tests de politiques précis. Cela inclut les configurations VPC correspondantes, le comportement de résolution DNS et l'accès aux mêmes services externes dont vos charges de travail de production ont besoin.
+ **Mettez en œuvre des tests automatisés pour les chemins réseau critiques** - Créez des tests automatisés qui valident la connectivité aux services externes essentiels dans le cadre de votre CI/CD pipeline. Ces tests doivent vérifier que les flux de trafic légitimes sont autorisés tandis que les connexions non autorisées sont bloquées, afin de valider en permanence que vos politiques réseau maintiennent le bon niveau de sécurité au fur et à mesure de l'évolution de votre infrastructure.
+ **Surveillez le comportement des applications après les modifications des politiques** : après avoir déployé des politiques réseau nouvelles ou modifiées en production, surveillez de près les journaux des applications, les taux d'erreur et les indicateurs de performance pour identifier rapidement les problèmes de connectivité. Établissez des procédures d'annulation claires afin de pouvoir annuler rapidement les modifications de politique si elles entraînent un comportement inattendu des applications ou des interruptions de service.
### Interaction avec le pare-feu DNS Amazon Route 53
Les politiques d'administration et de réseau d'EKS sont d'abord évaluées au niveau du module lorsque le trafic est initié. Si une politique réseau EKS autorise la sortie vers un domaine spécifique, le pod exécute alors une requête DNS qui atteint le résolveur Route 53. À ce stade, les règles du pare-feu DNS Route 53 sont évaluées. Si le pare-feu DNS bloque la requête de domaine, la résolution DNS échoue et la connexion ne peut pas être établie, même si la politique réseau EKS l'autorise. Cela crée des couches de sécurité complémentaires : les politiques réseau basées sur le DNS d'EKS fournissent un contrôle des sorties au niveau du pod pour répondre aux exigences d'accès spécifiques aux applications et aux limites de sécurité mutualisées, tandis que le pare-feu DNS fournit une protection à l'échelle du VPC contre les domaines malveillants connus et applique des listes de blocage à l'échelle de l'organisation.
# Baliser les sous-réseaux pour le mode automatique EKS
Si vous utilisez la fonctionnalité d'équilibrage de charge du mode automatique d'EKS, vous devez ajouter des AWS balises à vos sous-réseaux VPC.
## Contexte
Ces balises identifient les sous-réseaux comme étant associés au cluster et, plus important encore, indiquent si le sous-réseau est public ou privé.
Les sous-réseaux publics ont un accès direct à Internet via une passerelle Internet. Ils sont utilisés pour les ressources qui doivent être accessibles au public, telles que les équilibreurs de charge.
Les sous-réseaux privés n’ont pas d’accès direct à Internet et utilisent des passerelles NAT pour le trafic sortant. Ils sont utilisés pour les ressources internes telles que les nœuds EKS qui n'ont pas besoin d'être publics IPs.
Pour en savoir plus sur les passerelles NAT et les passerelles Internet, consultez [Connecter votre VPC à d’autres réseaux](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) dans le Guide de l’utilisateur Amazon Virtual Private Cloud (VPC).
## Exigence
À l’heure actuelle, les sous-réseaux utilisés pour l’équilibrage de charge par le mode automatique EKS doivent être balisés avec l’une des balises suivantes.
### Sous-réseaux publics
Les sous-réseaux publics sont utilisés pour les équilibreurs de charge connectés à Internet. Ces sous-réseaux doivent comporter les balises suivantes :
| Clé | Valeur |
| --- | --- |
| `kubernetes.io/role/elb` | `1` ou `` |
### Sous-réseaux privés
Les sous-réseaux privés sont utilisés pour les équilibreurs de charge internes. Ces sous-réseaux doivent comporter les balises suivantes :
| Clé | Valeur |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` ou `` |
## Procédure
Avant de commencer, identifiez les sous-réseaux publics (avec accès à une passerelle Internet) et les sous-réseaux privés (utilisant une passerelle NAT). Vous aurez besoin d’autorisations pour modifier les ressources VPC.
### AWS Management Console
1. **Ouvrez la console Amazon VPC et accédez à Subnets.**
1. Sélectionnez le sous-réseau à étiqueter.
1. Choisissez l'onglet **Tags**, puis sélectionnez **Ajouter un tag**.
1. Ajoutez la balise appropriée :
+ Pour les sous-réseaux publics : Key=`kubernetes.io/role/elb`
+ Pour les sous-réseaux privés : Key=`kubernetes.io/role/internal-elb`
1. Définissez **la valeur** sur `1` ou laissez le champ vide.
1. Enregistrez et répétez l'opération pour les sous-réseaux restants.
### AWS CLI
Pour les sous-réseaux publics :
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Pour les sous-réseaux privés :
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Remplacez `subnet-ID` par votre ID de sous-réseau réel.
# Génération de rapports de conformité CIS à partir des nœuds Kubernetes à l’aide de kubectl debug
Cette rubrique explique comment générer des rapports de conformité CIS (Center for Internet Security) pour les nœuds Amazon EKS à l’aide de la commande `kubectl debug`. Cette commande permet de créer temporairement un conteneur de débogage sur un nœud Kubernetes et d’exécuter les vérifications CIS à l’aide de l’outil `apiclient`. L’outil `apiclient` fait partie de l’OS Bottlerocket, utilisé par les nœuds du mode automatique EKS.
## Conditions préalables
Avant de commencer, assurez-vous de disposer des éléments suivants :
+ Accès à un cluster Amazon EKS avec la commande `kubectl` configurér (la version installée doit être au minimum v1.32.0 ; tapez `kubectl version` pour vérifier).
+ Autorisations IAM appropriées pour déboguer les nœuds.
+ Profil valide autorisant les opérations de débogage (par exemple, `sysadmin`).
Pour plus d’informations sur l’utilisation de profils de débogage avec `kubectl`, consultez la section [Débogage d’un pod ou d’un nœud lors de l’application d’un profil](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) dans la documentation de Kubernetes.
## Procédure
1. Déterminez l'ID d' AWS instance du nœud sur lequel vous souhaitez exécuter le rapport. Utilisez la commande suivante pour afficher la liste des nœuds du cluster. L’ID d’instance se trouve dans la colonne du nom et commence par `i-` :
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Exécutez la commande ci-dessous en remplaçant `` par l’ID d’instance du nœud ciblé :
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Les composants de cette commande sont les suivants :
+ `kubectl debug node/` : crée une session de débogage sur l’ID d’instance EC2 spécifié.
+ `-it` : alloue un TTY (shell de ligne de commande) et maintient stdin ouvert pour une utilisation interactive.
+ `--profile=sysadmin` : utilise le profil `kubectl` spécifié avec les autorisations appropriées.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` : utilise `amazonlinux:2023` comme image de conteneur pour le débogage.
+ `bash -c "…"` : exécute les commandes suivantes dans un shell bash :
+ `yum install -q -y util-linux-core` : installe discrètement le package d’utilitaires requis.
+ `nsenter -t 1 -m` : exécute `nsenter` pour accéder à l’espace de noms du processus hôte (PID 1).
+ `apiclient report cis --level 1 --format text` : exécute le rapport de conformité CIS au niveau 1, avec un résultat au format texte.
1. Passez en revue le résultat au format texte du rapport.
## Interprétation du résultat
La commande génère un rapport au format texte indiquant l’état de conformité des différents contrôles CIS. Le résultat comprend :
+ Contrôle CIS individuel IDs
+ Description de chaque contrôle
+ État Réussite, Échec ou Ignoré pour chaque vérification
+ Détails expliquant les éventuels problèmes de conformité
Voici un exemple de résultat du rapport exécuté sur une instance de Bottlerocket :
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Pour plus d’informations sur le référentiel, consultez [Référentiel Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/) dans la documentation du Center for Internet Security (CIS).
## Ressources connexes
+ [Référence CIS Bottlerocket](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) dans la documentation du système d’exploitation Bottlerocket.
+ [Débogage des pods en cours d’exécution](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) dans la documentation de Kubernetes.
+ [Référentiel Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/) dans la documentation du Center for Internet Security (CIS)
# Activation du chiffrement des volumes EBS avec des clés KMS gérées par le client pour le mode automatique EKS
Vous pouvez chiffrer le volume racine éphémère des instances gérées par le mode automatique EKS à l’aide d’une clé KMS gérée par le client.
Le mode automatique Amazon EKS utilise des rôles liés à des services pour déléguer des autorisations à d'autres AWS services lors de la gestion de volumes EBS chiffrés pour vos clusters Kubernetes. Cette rubrique explique comment configurer la stratégie de clé requise lorsque vous spécifiez une clé gérée par le client pour le chiffrement Amazon EBS avec le mode automatique EKS.
Considérations :
+ Le mode automatique EKS n'a pas besoin d'autorisation supplémentaire pour utiliser la clé AWS gérée par défaut afin de protéger les volumes chiffrés de votre compte.
+ Cette rubrique traite du chiffrement des volumes éphémères, les volumes racines pour les instances. EC2 Pour plus d’informations sur le chiffrement des volumes de données utilisés pour les charges de travail, consultez [Création d’une classe de stockage](create-storage-class.md).
## Présentation de
Les clés AWS KMS suivantes peuvent être utilisées pour le chiffrement du volume racine Amazon EBS lorsque le mode automatique EKS lance des instances :
+ **Clé gérée par AWS ** : clé de chiffrement créée, détenue et gérée par Amazon EBS dans votre compte. Il s'agit de la clé de chiffrement par défaut d'un nouveau compte.
+ **Clé gérée par le client** : clé de chiffrement personnalisée que vous créez, détenez et gérez vous-même.
**Note**
La clé doit être symétrique. Amazon EBS ne prend pas en charge les clés asymétriques gérées par le client.
## Étape 1 : configurer la stratégie de clé
Vos clés KMS doivent inclure une stratégie de clé permettant au mode automatique EKS de lancer des instances avec des volumes Amazon EBS chiffrés à l’aide d’une clé gérée par le client.
Configurez votre stratégie de clé selon la structure suivante :
**Note**
Cette stratégie inclut uniquement les autorisations nécessaires au mode automatique EKS. La stratégie de clé peut nécessiter des autorisations supplémentaires si d’autres identités ont besoin d’utiliser la clé ou de gérer des autorisations.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Assurez-vous de le remplacer `` par votre numéro de AWS compte actuel.
Lors de la configuration de la stratégie de clé :
+ Le `ClusterServiceRole` doit disposer des autorisations IAM nécessaires pour utiliser la clé KMS lors des opérations de chiffrement
+ Cette `kms:GrantIsForAWSResource` condition garantit que les subventions ne peuvent être créées que pour AWS des services
## Étape 2 : Configuration à l' NodeClass aide de votre clé gérée par le client
Après avoir configuré la politique des clés, référencez la clé KMS dans votre NodeClass configuration du mode automatique EKS :
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
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
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Remplacez les valeurs d’exemple par vos valeurs réelles :
+ ``avec votre AWS région
+ ``avec votre identifiant AWS de compte
+ `` par l’ID de votre clé KMS
Vous pouvez spécifier la clé KMS selon l’un des formats suivants :
+ ID de clé KMS : `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN de clé KMS : ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nom d’alias de clé : `alias/eks-auto-mode-key`
+ ARN d’alias de clé : ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Appliquez la NodeClass configuration à l'aide de kubectl :
```
kubectl apply -f nodeclass.yaml
```
## Ressources connexes
+ [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md)
+ Pour plus d'informations, consultez le guide du développeur du service de gestion des AWS clés
+ [Autorisations pour les AWS services dans les politiques clés](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Modification d’une stratégie de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Subventions dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Mise à jour des contrôles d’organisation pour le mode automatique EKS
Certains contrôles organisationnels peuvent empêcher le mode automatique EKS de fonctionner correctement. Dans ce cas, vous devez mettre à jour ces contrôles afin de permettre au mode automatique EKS de disposer des autorisations nécessaires pour gérer les instances EC2 en votre nom.
Le mode automatique EKS utilise un rôle de service pour lancer les instances EC2 qui constituent les nœuds du mode automatique EKS. Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) créé dans votre compte, qu’un service peut assumer afin d’effectuer des actions en votre nom. Les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) s'appliquent toujours aux actions effectuées avec des rôles de service. Ainsi, une SCP peut bloquer certaines opérations du mode automatique EKS. L'occurrence la plus courante se produit lorsqu'un SCP est utilisé pour restreindre les Amazon Machine Images (AMIs) qui peuvent être lancées. Pour permettre au mode automatique EKS de fonctionner, modifiez le SCP afin de permettre le lancement à AMIs partir des comptes du mode automatique EKS.
Vous pouvez également utiliser la AMIs fonctionnalité [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) pour limiter la visibilité sur AMIs d'autres comptes. Si vous utilisez cette fonctionnalité, vous devez élargir les critères d’images afin d’inclure également les comptes d’AMI en mode automatique EKS dans les régions concernées.
## Exemple de SCP pour tout bloquer AMIs sauf le mode automatique EKS AMIs
L’exemple ci-dessous empêche l’appel de `ec2:RunInstances` sauf si l’AMI appartient au compte d’AMI en mode automatique EKS pour us-west-2 ou us-east-1.
**Note**
Il est important de **ne pas** utiliser la clé de contexte `ec2:Owner`. Amazon est propriétaire des comptes AMI en mode automatique EKS et la valeur de cette clé sera toujours `amazon`. La construction d'un SCP qui permet le `ec2:Owner` lancement AMIs s'il permet de lancer n'importe quelle AMI appartenant à Amazon, et pas seulement celles destinées au mode automatique d'EKS. `amazon` \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Comptes AMI en mode automatique EKS
AWS les comptes qui varient selon les régions hébergent le mode automatique EKS public AMIs.
| | |
| --- |--- |
| AWS Région | Compte |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Association d’une adresse IP publique
Lorsque l’appel `ec2:RunInstances` est effectué, la valeur du champ `AssociatePublicIpAddress` lors du lancement d’une instance est déterminée automatiquement en fonction du type de sous-réseau dans lequel l’instance est lancée. Une SCP peut être utilisée pour imposer que cette valeur soit explicitement définie sur « false », quel que soit le sous-réseau utilisé pour le lancement. Dans ce cas, le NodeClass champ `spec.advancedNetworking.associatePublicIPAddress` peut également être défini sur false pour satisfaire aux exigences du SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS
Vous pouvez contrôler le déploiement des charges de travail dans des [réserves de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). Le mode automatique EKS prend en charge les réserves de capacité à la demande (On-Demand Capacity Reservation, ODCR) EC2 ainsi que les blocs de capacité EC2 pour le ML.
**Astuce**
Par défaut, le mode automatique d'EKS peut être lancé en mode ouvert ODCRs par le biais d'une correspondance ouverte, mais il ne les priorise pas. Les instances lancées par le biais d'une correspondance ouverte sont étiquetées`karpenter.sh/capacity-type: on-demand`, non`reserved`. Pour hiérarchiser l'utilisation de l'ODCR et étiqueter les instances`karpenter.sh/capacity-type: reserved`, configurez `capacityReservationSelectorTerms` dans la NodeClass définition. Les blocs de capacité pour le ML nécessitent toujours `capacityReservationSelectorTerms` et ne sont pas utilisés automatiquement.
## Réservations de capacité à la demande EC2 () ODCRs
Les réserves de capacité à la demande (ODCR) EC2 permettent de réserver de la capacité de calcul pour vos instances Amazon EC2 dans une zone de disponibilité spécifique, pour toute durée souhaitée. Lorsque vous utilisez le mode automatique EKS, vous pouvez vouloir contrôler le déploiement de vos charges de travail Kubernetes sur ces instances réservées afin de maximiser l’utilisation de la capacité préachetée ou garantir l’accès des charges de travail critiques à des ressources dédiées.
Par défaut, le mode automatique EKS démarre automatiquement en mode ouvert ODCRs. Cependant, en configurant `capacityReservationSelectorTerms` sur un NodeClass, vous pouvez contrôler explicitement les charges de travail utilisées par ODCRs vos charges de travail. Les nœuds approvisionnés à l'aide de la configuration ODCRs auront `karpenter.sh/capacity-type: reserved` et seront priorisés par rapport à la demande et au spot. Une fois cette fonctionnalité activée, le mode automatique d'EKS n'utilisera plus automatiquement les options ouvertes. ODCRs Elles doivent être explicitement sélectionnées par un NodeClass, ce qui vous permet de contrôler précisément l'utilisation des réservations de capacité au sein de votre cluster.
**Avertissement**
Si vous effectuez une configuration `capacityReservationSelectorTerms` NodeClass dans un cluster, le mode automatique d'EKS n'utilisera plus automatiquement l'option open ODCRs pour *aucun* NodeClass élément du cluster.
### Exemple NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Cet exemple NodeClass illustre deux approches de sélection ODCRs. La première méthode fait référence directement à une ODCR spécifique à l’aide de son ID (`cr-56fac701cc1951b03`). La seconde méthode utilise la sélection basée sur les balises, le ciblage à l' ODCRs aide de la balise`Name: "targeted-odcr"`. Vous pouvez également éventuellement filtrer en fonction du AWS compte propriétaire de la réservation, ce qui est particulièrement utile dans les scénarios entre comptes ou lorsque vous travaillez avec des réservations à capacité partagée.
## Blocs de capacité EC2 pour ML
Les blocs de capacité pour ML vous permettent de réserver à l’avance des instances de calcul accéléré basées sur GPU pour exécuter des charges de travail de machine learning (ML) de courte durée. Les instances qui s'exécutent au sein d'un bloc de capacité sont automatiquement placées à proximité les unes des autres dans Amazon EC2 UltraClusters, pour une mise en réseau non bloquante à faible latence, à l'échelle du pétabit.
Pour plus d’informations sur les plateformes et les types d’instances pris en charge, consultez [Blocs de capacité ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le Guide de l’utilisateur EC2.
Vous pouvez créer un mode automatique EKS NodeClass qui utilise un bloc de capacité pour le ML, similaire à un ODCR (décrit précédemment).
Les exemples de définitions suivants créent trois ressources :
1. A NodeClass qui fait référence à votre réservation Capacity Block
1. Un NodePool qui utilise le NodeClass et applique une teinte
1. Une spécification de pod tolérant cette balise de rejet et demandant des ressources GPU
### Exemple NodeClass
Cela NodeClass fait référence à un bloc de capacité spécifique pour ML par son ID de réservation. Vous pouvez obtenir cet ID dans la console EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
### Exemple NodePool
Cela NodePool fait référence à la configuration importante `gpu` NodeClass et précise :
+ Il utilise **uniquement** la capacité réservée en définissant `karpenter.sh/capacity-type: reserved`
+ Il demande des familles d’instances GPU spécifiques adaptées aux charges de travail ML
+ Il applique une balise de rejet `nvidia.com/gpu` pour s’assurer que seules les charges de travail GPU sont planifiées sur ces nœuds
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
### Exemple de pod
Cet exemple de pod montre comment configurer une charge de travail afin qu’elle s’exécute sur vos nœuds de bloc de capacité :
+ Il utilise un **NodeSelector** pour cibler des types de GPU spécifiques (dans ce cas, le H200) GPUs
+ Il inclut une **tolérance à l'égard de** la `nvidia.com/gpu` souillure appliquée par le NodePool
+ Il **demande explicitement des ressources GPU** en utilisant le type de ressource `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Pour plus d'informations, consultez [pods](https://kubernetes.io/docs/concepts/workloads/pods/) dans la documentation Kubernetes.
### Ressources connexes
+ [Blocs de capacité pour ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le Guide de l’utilisateur Amazon EC2
+ [Trouver et acheter des blocs de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) dans le Guide de l’utilisateur Amazon EC2
+ [Gérez les ressources informatiques pour les AI/ML charges de travail sur Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Optimisation et gestion des coûts des ressources GPU](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) dans le Guide des bonnes pratiques EKS
# Déployer des nœuds EKS Auto Mode sur des Zones Locales
Le mode automatique EKS simplifie la gestion des clusters grâce au provisionnement automatique des nœuds. AWS Les zones locales étendent AWS l'infrastructure à des emplacements géographiques plus proches de vos utilisateurs finaux, réduisant ainsi le temps de latence pour les applications sensibles à la latence. Ce guide explique le processus de déploiement des nœuds EKS Auto Mode sur les Zones AWS Locales, ce qui vous permet d'exécuter des applications conteneurisées avec une latence plus faible pour les utilisateurs de zones géographiques spécifiques.
Ce guide explique également comment utiliser les contraintes et les tolérances de Kubernetes pour garantir que seules des charges de travail spécifiques s'exécutent sur les nœuds de votre zone locale, ce qui vous aide à contrôler les coûts et à optimiser l'utilisation des ressources.
## Conditions préalables
Avant de commencer à déployer des nœuds EKS Auto Mode sur des Zones Locales, assurez-vous que les conditions préalables suivantes sont réunies :
+ [Un cluster de mode automatique EKS existant](create-auto.md)
+ [Vous avez activé la zone locale dans votre compte AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Étape 1 : créer un sous-réseau de zone locale
La première étape du déploiement des nœuds du mode automatique EKS dans une zone locale consiste à créer un sous-réseau dans cette zone locale. Ce sous-réseau fournit l'infrastructure réseau pour vos nœuds et leur permet de communiquer avec le reste de votre VPC. Suivez les instructions de [création d'un sous-réseau de zone locale](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (dans le guide de l'utilisateur des zones AWS locales) pour créer un sous-réseau dans la zone locale de votre choix.
**Astuce**
Notez le nom du sous-réseau de votre zone locale.
## Étape 2 : Création NodeClass pour le sous-réseau de zone locale
Après avoir créé votre sous-réseau de zone locale, vous devez définir un NodeClass qui fait référence à ce sous-réseau. NodeClass Il s'agit d'une ressource personnalisée Kubernetes qui spécifie les attributs d'infrastructure de vos nœuds, notamment les sous-réseaux, les groupes de sécurité et les configurations de stockage à utiliser. Dans l'exemple ci-dessous, nous créons une « zone locale » qui cible un sous-réseau de zone locale en fonction de son NodeClass nom. Vous pouvez également utiliser l'ID de sous-réseau. Vous devrez adapter cette configuration pour cibler votre sous-réseau de zone locale.
Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Étape 3 : créer NodePool avec NodeClass et teindre
Une fois que vous êtes NodeClass configuré, vous devez maintenant créer un NodePool qui l'utilise NodeClass. A NodePool définit les caractéristiques de calcul de vos nœuds, y compris les types d'instances. Il NodePool utilise le NodeClass comme référence pour déterminer où lancer les instances.
Dans l'exemple ci-dessous, nous créons un NodePool qui fait référence à notre « zone locale ». NodeClass Nous ajoutons également une touche aux nœuds afin de garantir que seuls les pods présentant une tolérance correspondante puissent être planifiés sur ces nœuds de zone locale. Cela est particulièrement important pour les nœuds de zone locale, qui ont généralement des coûts plus élevés et ne doivent être utilisés que par des charges de travail bénéficiant spécifiquement de la réduction de la latence.
Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
L'odeur associée à la touche `aws.amazon.com/local-zone` et à l'effet `NoSchedule` garantit que les pods sans tolérance correspondante ne seront pas planifiés sur ces nœuds. Cela permet d'éviter que des charges de travail régulières ne s'exécutent accidentellement dans la zone locale, ce qui pourrait entraîner des coûts imprévus.
## Étape 4 : Déployer les charges de travail avec tolérance et affinité des nœuds
Pour un contrôle optimal du placement de la charge de travail sur les nœuds de zone locale, utilisez à la fois l'affinité taints/tolerations des nœuds et l'affinité des nœuds. Cette approche combinée offre les avantages suivants :
1. **Contrôle des coûts** : Cette altération garantit que seuls les pods soumis à des tolérances explicites peuvent utiliser des ressources de zone locale potentiellement coûteuses.
1. **Placement garanti** : l'affinité des nœuds garantit que vos applications sensibles à la latence s'exécutent exclusivement dans la zone locale, et non sur des nœuds de cluster ordinaires.
Voici un exemple de déploiement configuré pour s'exécuter spécifiquement sur les nœuds de zone locale :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Ce déploiement comporte deux configurations de planification clés :
1. La **tolérance** permet de planifier les capsules sur les nœuds présentant cette odeur`aws.amazon.com/local-zone`.
1. L'exigence d'**affinité des nœuds** garantit que ces pods ne s'exécuteront que sur les nœuds portant le label`node-type: local-zone`.
Ensemble, ils garantissent que votre application sensible à la latence ne s'exécute que sur les nœuds de zone locale, et que les applications ordinaires ne consomment pas les ressources de la zone locale, sauf si elles sont explicitement configurées pour le faire.
## Étape 5 : vérification à l'aide de AWS la console
Après avoir configuré vos déploiements NodeClass NodePool, et,,,,,,,,,,, vous devez vérifier que les nœuds sont approvisionnés dans votre zone locale comme prévu et que vos charges de travail s'exécutent sur eux. Vous pouvez utiliser la console AWS de gestion pour vérifier que les EC2 instances sont lancées dans le sous-réseau de zone locale approprié.
En outre, vous pouvez consulter la liste des nœuds Kubernetes en utilisant `kubectl get nodes -o wide` pour vérifier que les nœuds rejoignent votre cluster avec les étiquettes et les caractéristiques appropriées :
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Vous pouvez également vérifier que vos pods de charge de travail sont planifiés sur les nœuds de la zone locale :
```
kubectl get pods -o wide
```
Cette approche garantit que seules les charges de travail qui tolèrent spécifiquement l'empreinte de zone locale seront planifiées sur ces nœuds, ce qui vous permet de contrôler les coûts et d'utiliser au mieux les ressources de votre zone locale.
# Configuration des paramètres de sécurité avancés pour les nœuds
Cette rubrique explique comment configurer les paramètres de sécurité avancés pour les nœuds Amazon EKS Auto Mode à l'aide des `advancedSecurity` spécifications de votre classe de nœuds.
## Conditions préalables
Avant de commencer, assurez-vous de disposer des éléments suivants :
+ Un cluster du mode automatique Amazon EKS. Pour de plus amples informations, veuillez consulter [Création d’un cluster avec le mode automatique Amazon EKS](create-auto.md).
+ `kubectl` installé et configuré. Pour de plus amples informations, veuillez consulter [Configuration pour utiliser Amazon EKS](setting-up.md).
+ Compréhension de la configuration des classes de nœuds. Pour de plus amples informations, veuillez consulter [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md).
## Configuration des paramètres de sécurité avancés
Pour configurer les paramètres de sécurité avancés pour vos nœuds, définissez les `advancedSecurity` champs dans la spécification de votre classe de nœud :
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Appliquez cette configuration :
```
kubectl apply -f nodeclass.yaml
```
Référencez cette classe de nœuds dans la configuration de votre pool de nœuds. Pour de plus amples informations, veuillez consulter [Create a Node Pool for EKS Auto Mode](create-node-pool.md).
## Descriptions des champs
+ `fips`(booléen, facultatif) : lorsqu'il est défini sur`true`, approvisionne les nœuds à l'aide de modules cryptographiques validés AMIs par la norme FIPS 140-2. Ce paramètre sélectionne la conformité à la norme FIPS AMIs ; les clients sont responsables de la gestion de leurs exigences de conformité. Pour plus d'informations, consultez la section [Conformité à la AWS norme FIPS](https://aws.amazon.com/compliance/fips/). Valeur par défaut : `false`.
+ `kernelLockdown`(chaîne, facultatif) : contrôle le mode du module de sécurité du verrouillage du noyau. Valeurs acceptées :
+ `integrity`: bloque les méthodes permettant de remplacer la mémoire du noyau ou de modifier le code du noyau. Empêche le chargement de modules de noyau non signés.
+ `none`: désactive la protection contre le verrouillage du noyau.
Pour plus d'informations, consultez la [documentation sur le verrouillage du noyau Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Considérations
+ Les produits conformes à la norme FIPS AMIs sont disponibles dans les AWS régions de l'Est/Ouest des États-Unis et du AWS Canada AWS GovCloud (Centre-Ouest). Pour plus d'informations, consultez la section [Conformité à la AWS norme FIPS](https://aws.amazon.com/compliance/fips/).
+ Lors de l'utilisation`kernelLockdown: "integrity"`, assurez-vous que vos charges de travail ne nécessitent pas le chargement de modules de noyau non signés ou la modification de la mémoire du noyau.
## Ressources connexes
+ [Création d’une classe de nœuds pour Amazon EKS](create-node-class.md)- Guide complet de configuration des classes de nœuds
+ [Create a Node Pool for EKS Auto Mode](create-node-pool.md)- Configuration du pool de nœuds