**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Pool di nodi a capacità statica in modalità EKS Auto La modalità automatica di Amazon EKS supporta pool di nodi a capacità statica che mantengono un numero fisso di nodi indipendentemente dalla domanda del pod. I pool di nodi con capacità statica sono utili per carichi di lavoro che richiedono capacità prevedibile, istanze riservate o requisiti di conformità specifici in cui è necessario mantenere un ingombro dell'infrastruttura coerente. A differenza dei pool di nodi dinamici che si ridimensionano in base alle richieste di pianificazione dei pod, i pool di nodi con capacità statica mantengono il numero di nodi configurati. ## Configurare un pool di nodi con capacità statica Per creare un pool di nodi con capacità statica, imposta il `replicas` campo nelle tue NodePool specifiche. Il `replicas` campo definisce il numero esatto di nodi che il pool di nodi manterrà. Scopri [Esempi](#static-capacity-examples) come configurare`replicas`. ## Considerazioni sulla capacità statica del pool di nodi I pool di nodi con capacità statica presentano diversi vincoli e comportamenti importanti: **Vincoli di configurazione:** + **Impossibile cambiare modalità**: una volta impostato `replicas` un pool di nodi, non è possibile rimuoverlo. Il pool di nodi non può passare dalla modalità statica a quella dinamica. + **Limiti di risorse limitati**: nella sezione dei limiti è supportato solo il `limits.nodes` campo. I limiti di CPU e memoria non sono applicabili. + **Nessun campo di peso**: il `weight` campo non può essere impostato su pool di nodi con capacità statica poiché la selezione dei nodi non si basa sulla priorità. **Comportamento operativo:** + **Nessun consolidamento**: i nodi nei pool di capacità statici non vengono presi in considerazione per il consolidamento. + **Operazioni di scalabilità: le operazioni di scalabilità** evitano i budget relativi alle interruzioni dei nodi, ma rispettano comunque i requisiti. PodDisruptionBudgets + **Sostituzione** dei nodi: i nodi vengono comunque sostituiti per eventuali variazioni (come gli aggiornamenti AMI) e per scadenza in base alla configurazione. ## Best practice **Pianificazione della capacità:** + Impostato su un `limits.nodes` valore superiore `replicas` a per consentire il ridimensionamento temporaneo durante le operazioni di sostituzione dei nodi. + Quando imposti i limiti, considera la capacità massima necessaria durante la deriva dei nodi o gli aggiornamenti AMI. **Selezione dell'istanza:** + Utilizza tipi di istanze specifici quando hai istanze riservate o requisiti hardware specifici. + Evita requisiti eccessivamente restrittivi che potrebbero limitare la disponibilità delle istanze durante la scalabilità. **Gestione delle interruzioni:** + Configura i budget appropriati per le interruzioni per bilanciare la disponibilità con le operazioni di manutenzione. + Considerate la tolleranza della vostra applicazione per la sostituzione dei nodi quando impostate le percentuali di budget. **Monitoraggio:** + Monitora regolarmente il `status.nodes` campo per garantire il mantenimento della capacità desiderata. + Imposta avvisi per quando il numero effettivo di nodi si discosta dalle repliche desiderate. **Distribuzione delle zone:** + Per un'elevata disponibilità, distribuisci la capacità statica su più zone di disponibilità. + Quando si crea un pool di nodi con capacità statica che si estende su più zone di disponibilità, EKS Auto Mode distribuisce i nodi tra le zone specificate, ma non è garantito che la distribuzione sia uniforme. + Per una distribuzione prevedibile e uniforme tra le zone di disponibilità, crea pool di nodi con capacità statica separati, ciascuno collegato a una zona di disponibilità specifica utilizzando il requisito. `topology.kubernetes.io/zone` + Se hai bisogno di 12 nodi distribuiti uniformemente su tre zone, crea tre pool di nodi con 4 repliche ciascuno, anziché un pool di nodi con 12 repliche su tre zone. ## Scalabilità di un pool di nodi con capacità statica È possibile modificare il numero di repliche in un pool di nodi con capacità statica utilizzando il `kubectl scale` comando: ``` # Scale down to 5 nodes kubectl scale nodepool static-nodepool --replicas=5 ``` In caso di ridimensionamento, EKS Auto Mode terminerà i nodi in modo corretto, rispettando PodDisruptionBudgets e consentendo la riprogrammazione dei pod in esecuzione sui nodi rimanenti. ## Monitora i pool di nodi con capacità statica Utilizzate i seguenti comandi per monitorare i pool di nodi con capacità statica: ``` # 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}' ``` Il `status.nodes` campo mostra il numero attuale di nodi gestiti dal pool di nodi, che dovrebbe corrispondere al `replicas` numero desiderato in condizioni normali. ## Risoluzione dei problemi **I nodi non raggiungono le repliche desiderate:** + Controlla se il `limits.nodes` valore è sufficiente + Verifica che i requisiti non limitino eccessivamente la selezione delle istanze + Controlla le quote AWS di servizio per i tipi di istanze e le regioni che stai utilizzando **La sostituzione dei nodi richiede troppo tempo:** + Modifica i budget per le interruzioni per consentire più sostituzioni simultanee + Controlla se PodDisruptionBudgets stanno impedendo la chiusura del nodo **Chiusura imprevista del nodo:** + Rivedi le impostazioni `expireAfter` e `terminationGracePeriod` + Verifica la presenza di interruzioni manuali dei nodi o di eventi AWS di manutenzione ## Esempi ### Pool di nodi con capacità statica di 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à statica con tipi di istanze specifici ``` 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 di nodi con capacità statica multizona ``` 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à statica con riserva di capacità L'esempio seguente mostra come utilizzare un pool di nodi di capacità statica con una prenotazione di capacità EC2. Per ulteriori informazioni sull'utilizzo di EC2 Capacity Reservations con EKS Auto Mode, consulta. [Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS](auto-odcr.md) `NodeClass`definizione del `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`facendo riferimento a quanto sopra `NodeClass` e utilizzando`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'] ```