**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. # 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'] ```