Auto Scaling - Amazon EKS

Auto Scaling

La scalabilità automatica è una funzione che dimensiona automaticamente le risorse per soddisfare le esigenze in continua evoluzione. Questa è una delle principali funzioni Kubernetes, la cui esecuzione manuale richiederebbe altrimenti diverse risorse umane.

Amazon EKS supporta due prodotti con scalabilità automatica. Il Cluster Autoscaler Kubernetes e il progetto di scalabilità automatica open source Karpenter. Il cluster Autoscaler utilizza gruppi di dimensionamento di AWS, mentre Karpenter lavora direttamente con il parco istanze Amazon EC2.

Cluster Autoscaler

Il Cluster Autoscaler Kubernetes regola automaticamente il numero di nodi nel cluster quando i pod non riescono o vengono riprogrammati su altri nodi. Il Cluster Autoscaler viene in genere installato come implementazione nel cluster. Usa leader election per garantire la disponibilità elevata, ma la scalabilità viene eseguita da una sola replica alla volta.

Prima di implementare il Cluster Autoscaler, assicurarsi di conoscere come i concetti di Kubernetes interfacciano con le caratteristiche AWS. In questo argomento vengono utilizzati i seguenti termini:

  • Kubernetes Cluster Autoscaler – Un componente centrale del piano di controllo Kubernetes che prende decisioni di pianificazione e dimensionamento. Per ulteriori informazioni, consultare Domande frequenti sul piano di controllo di Kubernetes su GitHub.

  • AWS Implementazione del provider cloud – Un'estensione del Cluster Autoscaler Kubernetes che implementa le decisioni del Cluster Autoscaler Kubernetes comunicando con prodotti e servizi AWS come Amazon EC2. Per ulteriori informazioni consultare Cluster Autoscaler su AWS su GitHub.

  • Gruppi di nodi – Un'astrazione Kubernetes per un gruppo di nodi all'interno di un cluster. I gruppi di nodi non sono una vera risorsa Kubernetes, ma si trovano come astrazione in Cluster Autoscaler, Cluster API e altri componenti. I nodi che si trovano all'interno di un singolo gruppo di nodi possono condividere diverse proprietà comuni, ad esempio etichette e contaminazioni. Tuttavia, possono comunque consistere in più di una zona di disponibilità o tipo di istanza.

  • Gruppi Amazon EC2 Auto Scaling – Una caratteristica di AWS utilizzato da Cluster Autoscaler. I gruppi Auto Scaling sono adatti per un gran numero di casi d'uso. I gruppi Amazon EC2 Auto Scaling sono configurati per avviare istanze che si uniscono automaticamente al cluster Kubernetes. Applicano anche etichette e contaminanti alla risorsa nodo corrispondente nell'API Kubernetes.

Per riferimento, Gruppi di nodi gestiti sono gestiti utilizzando i gruppi Amazon EC2 Auto Scaling e sono compatibili con il Cluster Autoscaler.

Questo argomento illustra come implementare Cluster Autoscaler nel cluster Amazon EKS e come configurarlo per modificare i gruppi Amazon EC2 Auto Scaling.

Prerequisiti

Prima di implementare il Cluster Autoscaler, è necessario soddisfare i seguenti prerequisiti:

  • Disponibilità di un cluster Amazon EKS esistente: se non si dispone di un cluster, consultare Creazione di un cluster Amazon EKS.

  • Provider OIDC IAM esistente per il cluster. Per determinare se si dispone di uno o se è necessario crearne uno, vedere Per creare un provider di identità IAM OIDC per il cluster.

  • Gruppi di nodi con tag per gruppi Auto Scaling. Cluster Autoscaler richiede i seguenti tag nei gruppi Auto Scaling in modo che possano essere rilevati automaticamente.

    • Se hai utilizzato eksctl per creare i gruppi di nodi, questi tag vengono applicati automaticamente.

    • Se non hai utilizzato eksctl, è necessario contrassegnare manualmente i gruppi Auto Scaling con i tag riportati di seguito. Per ulteriori informazioni, consultare Assegnazione di tag alle risorse Amazon EC2 nella Guida per l'utente di Amazon EC2 per istanze Linux.

    Key (Chiave) Value (Valore)
    k8s.io/cluster-autoscaler/<my-cluster>

    owned

    k8s.io/cluster-autoscaler/enabled TRUE

Creare una policy IAM per il proprio ruolo

Creare una policy IAM che conceda le autorizzazioni richieste dal Cluster Autoscaler per utilizzare un ruolo IAM. Sostituire tutti i <example-values> (incluso <>) con i propri valori durante le procedure.

  1. Creare una policy IAM

    1. Salvare nel computer i seguenti contenuti in un archivio denominato cluster-autoscaler-policy.json. Se i gruppi di nodi esistenti sono stati creati con eksctl, e si è usato l'opzione --asg-access, questa policy esiste già ed è possibile passare alla fase 2.

      { "Version": "2012-10-17", "Statement": [ { "Action": [ "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeTags", "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup", "ec2:DescribeLaunchTemplateVersions" ], "Resource": "*", "Effect": "Allow" } ] }
    2. Creare la policy con il seguente comando. É possibile modificare il valore di policy-name.

      aws iam create-policy \ --policy-name AmazonEKSClusterAutoscalerPolicy \ --policy-document file://cluster-autoscaler-policy.json

      Prendere nota dell'Amazon Resource Name (ARN) restituito nell'output. Sarà utile in una fase successiva.

  2. È possibile creare un ruolo IAM e allegarvi una policy IAM tramite eksctl o il AWS Management Console. Selezionare la scheda desiderata per le seguenti istruzioni.

    eksctl
    1. Esegui il comando seguente se si è creato il proprio cluster Amazon EKS con eksctl. Se i gruppi di nodi sono stati creati utilizzando l'opzione --asg-access, sostituire <AmazonEKSClusterAutoscalerPolicy> con il nome della policy IAM che eksctl ha creato per l'utente. Il nome della policy è simile a eksctl-<my-cluster>-nodegroup-ng-<xxxxxxxx>-PolicyAutoScaling.

      eksctl create iamserviceaccount \ --cluster=<my-cluster> \ --namespace=kube-system \ --name=cluster-autoscaler \ --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/<AmazonEKSClusterAutoscalerPolicy> \ --override-existing-serviceaccounts \ --approve
    2. Se i gruppi di nodi sono stati creati utilizzando l'opzione --asg-access, è consigliabile si scollegare la policy IAM eksctl creata e collegarla al Ruolo IAM del nodo Amazon EKS che eksctl ha creato per i gruppi di nodi. Scollegare la policy dal ruolo del nodo IAM per consentire il corretto funzionamento di Cluster Autoscaler. La disconnessione della policy non fornisce ad altri pod sui nodi le autorizzazioni nella policy. Per ulteriori informazioni, consultare -Rimozione delle autorizzazioni di identità IAM nella Guida per l'utente di Amazon EC2 per le istanze Linux.

    AWS Management Console
    1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.

    2. Nel riquadro di navigazione a sinistra seleziona Ruoli. Quindi seleziona Create role (Crea ruolo).

    3. Nella sezione Trusted entity type (Tpo di identità attendibile), scegli Web identity (Identità Web).

    4. Nella sezione Web identity (Identità Web):

      1. Per Provider di identità, scegliere l'URL del cluster Amazon EKS.

      2. Per Audience (Pubblico), scegliere sts.amazonaws.com.

    5. Seleziona Next (Successivo).

    6. Nella casella Policy di filtro immettere AmazonEKSClusterAutoscalerPolicy. Seleziona quindi la casella di controllo a sinistra del nome della policy restituita dalla ricerca.

    7. Seleziona Next (Successivo).

    8. Per Nome ruolo, immettere un nome univoco per il ruolo, ad esempio AmazonEKSClusterAutoscalerRole.

    9. Per Description (Descrizione), inserisci un testo descrittivo come Amazon EKS - Cluster autoscaler role.

    10. Scegliere Create role (Crea ruolo).

    11. Dopo aver creato il ruolo, scegliere il ruolo nella console per aprirlo per la modifica.

    12. Scegli la scheda Trust relationships (Relazioni di attendibilità), quindi scegli Edit trust policy (Modifica policy di attendibilità).

    13. Cercare il risultato finale simile al seguente:

      "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"

      Modifica la riga in modo che sia simile alla riga seguente. Sostituire <EXAMPLED539D4633E53DE1B716D3041E> (incluso <>) con l'ID del provider OIDC del cluster e sostituire <region-code> con il codice della regione in cui si trova il cluster.

      "oidc.eks.<region-code>.amazonaws.com/id/<EXAMPLED539D4633E53DE1B716D3041E>:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
    14. Scegli Update policy (Aggiorna policy) per concludere.

Implementazione di Cluster Autoscaler

Completare i seguenti passaggi per implementare Cluster Autoscaler. Consigliamo di rivedere Considerazioni sull'implementazione e ottimizzare la distribuzione di Cluster Autoscaler prima di distribuirla in un cluster di produzione.

Per implementare Cluster Autoscaler

  1. Scaricare il file YAML di Cluster Autoscaler.

    curl -o cluster-autoscaler-autodiscover.yaml https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
  2. Modificare il file YAML e sostituire <YOUR CLUSTER NAME> con il nome del cluster.

  3. Applicare il file YAML al cluster.

    kubectl apply -f cluster-autoscaler-autodiscover.yaml
  4. Annotare l'account di servizio cluster-autoscaler con l'ARN del ruolo IAM creato in precedenza. Sostituire i <valori di esempio> con i propri valori.

    kubectl annotate serviceaccount cluster-autoscaler \ -n kube-system \ eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<AmazonEKSClusterAutoscalerRole>
  5. Applicare una patch alla implementazione per aggiungere l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict ai pod Cluster Autoscaler con il comando seguente.

    kubectl patch deployment cluster-autoscaler \ -n kube-system \ -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'
  6. Modificare l'implementazione di Cluster Autoscaler mediante il comando seguente.

    kubectl -n kube-system edit deployment.apps/cluster-autoscaler

    Modificare il comando del container cluster-autoscaler e sostituire <YOUR CLUSTER NAME> (incluso <>) con il nome del cluster e aggiungere le seguenti opzioni.

    • --balance-similar-node-groups

    • --skip-nodes-with-system-pods=false

    spec: containers: - command: - ./cluster-autoscaler - --v=4 - --stderrthreshold=info - --cloud-provider=aws - --skip-nodes-with-local-storage=false - --expander=least-waste - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> - --balance-similar-node-groups - --skip-nodes-with-system-pods=false

    Salvare e chiudere il file per applicare le modifiche.

  7. Aprire la pagina delle versioni di Cluster Autoscaler da GitHub nel browser Web e trovare la versione più recente di Cluster Autoscaler corrispondente alla versione principale e secondaria di Kubernetes del cluster. Ad esempio, se la versione Kubernetes del cluster è 1.21, cercare la versione più recente di Cluster Autoscaler che inizia con 1.21. Registrare il numero di versione semantica (1.21.n) per tale versione da utilizzare nella fase successiva.

  8. Impostare il tag image di Cluster Autoscaler sulla versione registrata nella fase precedente mediante il comando seguente. Sostituire 1.21.n con il proprio valore.

    kubectl set image deployment cluster-autoscaler \ -n kube-system \ cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v<1.21.n>

Visualizzazione dei log di Cluster Autoscaler

Dopo aver implementato Cluster Autoscaler, è possibile visualizzare i log e verificare che stia monitorando il carico del cluster.

Visualizza i log di Cluster Autoscaler usando il comando seguente.

kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

L'output è il seguente:

I0926 23:15:55.165842 1 static_autoscaler.go:138] Starting main loop I0926 23:15:55.166279 1 utils.go:595] No pod using affinity / antiaffinity found in cluster, disabling affinity predicate for this loop I0926 23:15:55.166293 1 static_autoscaler.go:294] Filtering out schedulables I0926 23:15:55.166330 1 static_autoscaler.go:311] No schedulable pods I0926 23:15:55.166338 1 static_autoscaler.go:319] No unschedulable pods I0926 23:15:55.166345 1 static_autoscaler.go:366] Calculating unneeded nodes I0926 23:15:55.166357 1 utils.go:552] Skipping ip-192-168-3-111.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166365 1 utils.go:552] Skipping ip-192-168-71-83.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166373 1 utils.go:552] Skipping ip-192-168-60-191.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166435 1 static_autoscaler.go:393] Scale down status: unneededOnly=false lastScaleUpTime=2019-09-26 21:42:40.908059094 ... I0926 23:15:55.166458 1 static_autoscaler.go:403] Starting scale down I0926 23:15:55.166488 1 scale_down.go:706] No candidates for scale down

Considerazioni sull'implementazione

Esaminare le considerazioni riportate di seguito per ottimizzare l'implementazione di Cluster Autoscaler.

Considerazioni sul dimensionamento

Cluster Autoscaler può essere configurato in modo da includere tutte le funzionalità aggiuntive dei nodi. Queste funzionalità possono includere volumi Amazon EBS allegati ai nodi, tipi di nodi di istanza Amazon EC2 o acceleratori GPU.

Gruppi di nodi di ambito in più zone di disponibilità

Si consiglia di configurare più gruppi di nodi, l'ambito di ciascun gruppo in una singola zona di disponibilità e attivare la caratteristica --balance-similar-node-groups. Se si crea un solo gruppo di nodi, definire l'ambito del gruppo di nodi in modo che si estenda su più di una zona di disponibilità.

Quando si imposta --balance-similar-node-groups su vero, assicurarsi che i gruppi di nodi che si desidera bilanciare con Cluster Autoscaler abbiano etichette corrispondenti (ad eccezione delle etichette di zona aggiunte automaticamente). È possibile passare un flag di --balancing-ignore-label a nodi con etichette diverse per bilanciarli, ma è importante farlo solo in caso di necessità.

Ottimizzare i gruppi di nodi

Il Cluster Autoscaler illustra il tipo di utilizzo dei i gruppi di nodi. Ciò include i tipi di istanza utilizzati all'interno di un gruppo. Per allinearsi a questi presupposti, configurare il gruppo di nodi in base alle considerazioni e ai suggerimenti seguenti:

  • Ogni nodo di un gruppo di nodi deve avere proprietà di pianificazione identiche. Questo include etichette, contaminanti e risorse.

    • Per MixedInstancePolicies, i tipi di istanza devono avere specifiche della CPU, della memoria e della GPU compatibili.

    • Il primo tipo di istanza specificato nella policy simula la pianificazione.

    • Se la policy dispone di tipi di istanza aggiuntivi con più risorse, le risorse potrebbero essere sprecate dopo la scalabilità orizzontale.

    • Se la policy dispone di tipi di istanza aggiuntivi con meno risorse rispetto ai tipi di istanza originali, i pod potrebbero non riuscire a pianificare le istanze.

  • Configurare un numero minore di gruppi di nodi con un numero maggiore di nodi, dal momento che la configurazione opposta può influire negativamente sulla scalabilità.

  • Utilizzare le funzionalità Amazon EC2 ogni volta che entrambi i sistemi forniscono supporto (ad esempio, utilizzare Regioni e MixedInstancePolicy.)

È consigliabile, se possibile, utilizzare Gruppi di nodi gestiti. I gruppi di nodi gestiti sono dotati di potenti funzionalità di gestione. Queste includono funzionalità per Cluster Autoscaler, come il rilevamento automatico del gruppo di Amazon EC2 Auto Scaling e la terminazione aggraziata dei nodi.

Utilizzo dei volumi EBS come archiviazione persistente

L'archiviazione persistente è fondamentale per la creazione di applicazioni con stato, ad esempio database e cache distribuite. Con i volumi Amazon EBS, è possibile creare applicazioni con stato su Kubernetes. Tuttavia, la creazione è limitata solo all'interno di una singola zona di disponibilità. Per ulteriori informazioni, consultare Come faccio a utilizzare lo spazio di archiviazione persistente in Amazon EKS?. Per una soluzione migliore, considerare la creazione di applicazioni con stato suddivise in più zone di disponibilità utilizzando un volume Amazon EBS separato per ciascuna zona di disponibilità. In questo modo, l'applicazione potrà essere altamente disponibile. Inoltre, il Cluster Autoscaler può bilanciare il ridimensionamento dei gruppi di Amazon EC2 Auto Scaling. Inoltre, assicurarsi che siano soddisfatte le seguenti condizioni:

  • Il bilanciamento del gruppo di nodi è abilitato impostando balance-similar-node-groups=true.

  • I gruppi di nodi sono configurati con impostazioni identiche (a meno che non si collochino in più di una zona di disponibilità e utilizzino volumi Amazon EBS diversi).

Co-scheduling

I processi di formazione distribuiti di Machine Learning traggono vantaggio in modo significativo dalla latenza ridotta delle configurazioni dei nodi della stessa zona. Questi carichi di lavoro distribuiscono più pod in una zona specifica. È possibile ottenere questo risultato impostando l'affinità pod per tutti i pod pianificati sul nodo utilizzando topologyKey: topology.kubernetes.io/zone. Utilizzando questa configurazione, il Cluster Autoscaler ridimensiona una zona specifica per soddisfare le richieste. Allocare più gruppi Amazon EC2 Auto Scaling, uno per ogni zona di disponibilità, per abilitare il failover per l'intero carico di lavoro pianificato in collaborazione. Inoltre, assicurarsi che siano soddisfatte le seguenti condizioni:

  • Il bilanciamento del gruppo di nodi è abilitato impostando balance-similar-node-groups=true.

  • Affinità nodo, Prelazione pod, o entrambi, vengono utilizzati quando i cluster includono gruppi di nodi regionali e zonali.

    • Utilizzare Affinità nodo per forzare o incoraggiare i pod regionali ed evitare gruppi di nodi zonali.

    • Non pianificare pod zonali su gruppi di nodi regionali. Ciò provocherebbe uno squilibrio della capacità dei pod regionali.

    • Configurare Prelazione pod se i carichi di lavoro zonali sono in grado di tollerare interruzioni e spostamenti. In questo modo si applica l'opzione di priorità e la riprogrammazione in una zona meno contestata per i pod in scala regionale.

Acceleratori e GPU

Alcuni cluster utilizzano acceleratori hardware specializzati, ad esempio una GPU dedicata. Durante la scalabilità orizzontale, l'acceleratore può richiedere alcuni minuti per pubblicizzare la risorsa al cluster. Durante questo periodo, il Cluster Autoscaler simula che questo nodo abbia l'acceleratore. Tuttavia, fino a quando l'acceleratore non sarà pronto per aggiornare le risorse del nodo disponibili, i pod in sospeso non potranno essere pianificati sul nodo. Ciò può comportare la ripetizione inutile della scalabilità orizzontale.

I nodi con acceleratori e un elevato utilizzo della CPU o della memoria non vengono considerati per la scalabilità ridotta anche se l'acceleratore non è utilizzato. Tuttavia, ciò può comportare costi non necessari. Per evitare questi costi, il Cluster Autoscaler può applicare regole speciali per considerare i nodi da ridimensionare, se dispongono di acceleratori non occupati.

Per garantire il corretto comportamento per questi casi, configurare il kubelet sui nodi dell'acceleratore per etichettare il nodo prima che si unisca al cluster. Il Cluster Autoscaler utilizza questo selettore di etichette per richiamare il comportamento ottimizzato dell'acceleratore. Inoltre, assicurarsi che siano soddisfatte le seguenti condizioni:

  • La kubelet per i nodi GPU è configurato con --node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE.

  • I nodi con acceleratori aderiscono alla regola delle proprietà identiche di programmazione.

Scalabilità da zero

Cluster Autoscaler può scalare gruppi di nodi da/a zero. Ciò può comportare risparmi significativi. Il Cluster Autoscaler rileva la CPU, la memoria e le risorse GPU di un gruppo Auto Scaling attraverso l'ispezione del InstanceType che è specificato nel suo LaunchConfiguration o LaunchTemplate. Alcuni pod richiedono risorse aggiuntive come WindowsENI o PrivateIPv4Address. Oppure potrebbero richiedere specifici NodeSelectors o Taints. Questi ultimi due non possono essere scoperti dal LaunchConfiguration. Tuttavia, il Cluster Autoscaler può tenere conto di questi fattori individuandoli dai seguenti tag nel gruppo Auto Scaling.

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME Value: 5 Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY Value: $LABEL_VALUE Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY Value: NoSchedule
Nota
  • In caso di scalabilità a zero, la capacità viene restituita ad Amazon EC2 e potrebbe non essere disponibile in futuro.

  • È possibile utilizzare describeNodegroup per diagnosticare i problemi con i gruppi di nodi gestiti durante il ridimensionamento da e a zero.

Ulteriori parametri di configurazione

Ci sono molte opzioni di configurazione che possono essere utilizzate per ottimizzare il comportamento e le prestazioni di Cluster Autoscaler. Per un elenco completo dei parametri, consultare Quali sono i parametri di CA? su GitHub.

Considerazioni sulle prestazioni

Sono disponibili alcuni elementi chiave che è possibile modificare per ottimizzare le prestazioni e la scalabilità di Cluster Autoscaler. I principali sono rappresentati da tutte le risorse fornite al processo, l'intervallo di scansione dell'algoritmo e il numero di gruppi di nodi nel cluster. Tuttavia, ci sono anche molti altri fattori che sono coinvolti nella vera complessità del tempo di esecuzione di questo algoritmo. Questi includono la complessità del plug-in di pianificazione e il numero di pod. Questi parametri sono considerati non configurabili, giacché sono parte integrante del carico di lavoro del cluster e non possono essere facilmente sintonizzati.

Scalabilità fa riferimento alle prestazioni del Cluster Autoscaler man mano che aumenta il numero di pod e nodi nel cluster Kubernetes. Le prestazioni e la funzionalità di Cluster Autoscaler calano se vengono raggiunte le quote di scalabilità. Inoltre, nel momento in cui il Cluster Autoscaler supera le quote di scalabilità, non può più aggiungere o rimuovere nodi nel cluster.

Prestazioni si riferisce alla rapidità con cui il Cluster Autoscaler può prendere e implementare decisioni di scalabilità. Un Cluster Autoscaler a prestazioni perfette prende decisioni istantaneamente e richiama azioni di ridimensionamento in risposta a condizioni specifiche come, ad esempio, un pod che diventa inprogrammabile.

É necessario avere familiarità con la complessità del tempo di esecuzione dell'algoritmo di scalabilità automatica. In questo modo sarà più facile sintonizzare il Cluster Autoscaler per un corretto funzionamento in cluster di grandi dimensioni (con più di 1.000 nodi).

Il Cluster Autoscaler carica lo stato dell'intero cluster in memoria. Sono inclusi i pod, i nodi e i gruppi di nodi. In ogni intervallo di scansione, l'algoritmo identificherà i pod non programmabili e simulerà la pianificazione per ciascun gruppo di nodi. É importante sapere che la messa a punto di questi fattori in modi diversi viene fornita a fronte di diversi compromessi.

Scalabilità automatica verticale

È possibile ridimensionare il Cluster Autoscaler a cluster più grandi aumentando le richieste di risorse per la relativa implementazione. Questo è uno dei metodi più semplici per farlo. Aumentare la memoria e la CPU per i cluster di grandi dimensioni. Il limite entro cui si dovrebbe aumentare la memoria e la CPU dipende notevolmente dalla dimensione specifica del cluster. L'algoritmo di scalabilità automatica memorizza tutti i pod e i nodi in memoria. In alcuni casi, ciò può comportare un ingombro di memoria maggiore di un gigabyte in alcuni casi. Di solito è necessario aumentare le risorse manualmente. Prendere in considerazione l'utilizzo del Addon Resizer o Vertical Pod Autoscaler per automatizzare il processo, nel caso in cui sia spesso necessario aumentare manualmente le risorse.

Ridurre il numero di gruppi di nodi

È possibile ridurre il numero di gruppi di nodi per migliorare le prestazioni del Cluster Autoscaler per cluster di grandi dimensioni. Ciò potrebbe risultare difficile se si sono strutturati i gruppi di nodi in base a un singolo team o applicazione. Anche se completamente supportato dall'API Kubernetes, questo è considerato un anti-pattern di Cluster Autoscaler, che può avere ripercussioni sulla scalabilità. Esistono molti vantaggi nell'utilizzo di più gruppi di nodi che, ad esempio, utilizzano istanze Spot o GPU. In molti casi, ci sono disegni alternativi che ottengono lo stesso effetto utilizzando un piccolo numero di gruppi. Inoltre, assicurarsi che siano soddisfatte le seguenti condizioni:

  • Isolare i pod utilizzando gli spazi dei nomi anziché i gruppi di nodi.

    • In cluster multi-tenant a bassa attendibilità, potrebbe non essere possibile eseguire questa operazione.

    • Impostare pod ResourceRequests e ResourceLimits correttamente per evitare conflitti di risorse.

    • Utilizzare tipi di istanza più grandi per un bin packing ottimale e ridurre il sovraccarico del pod di sistema.

  • Evitare l'utilizzo di NodeTaints o NodeSelectors per programmare i pod. Utilizzarli solo su base limitata.

  • Definire le risorse regionali come un singolo gruppo di Amazon EC2 Auto Scaling con più di una zona di disponibilità.

Riduzione dell'intervallo di scansione

L'utilizzo di un intervallo di scansione basso, ad esempio l'impostazione predefinita di dieci secondi, permette al Cluster Autoscaler di rispondere il più rapidamente possibile quando i pod diventano non programmabili. Tuttavia, ogni scansione genera molte chiamate API all'API Kubernetes e al gruppo di Amazon EC2 Auto Scaling o alle API del gruppo di nodi gestiti da Amazon EKS. Queste chiamate API possono causare una limitazione della velocità o addirittura un'indisponibilità del servizio per il piano di controllo utente Kubernetes.

L'intervallo di scansione predefinito è di dieci secondi, ma su AWS, l'avvio di un nodo richiede molto più tempo per avviare una nuova istanza. Ciò significa che è possibile aumentare l'intervallo senza aumentare significativamente il tempo complessivo di scalabilità. Ad esempio, se occorrono due minuti per avviare un nodo, non modificare l'intervallo a un minuto perché ciò potrebbe comportare un compromesso di chiamate API ridotte di 6 volte, per il 38% di lentezza di scalabilità.

Sharding tra gruppi di nodi

Per operare su un set specifico di gruppi di nodi, è possibile configurare il Cluster Autoscaler. Utilizzando questa funzionalità, è possibile implementare più istanze di Cluster Autoscaler. Configurare ogni istanza per operare su un set diverso di gruppi di nodi. In questo modo, è possibile utilizzare un numero arbitrariamente elevato di gruppi di nodi, con costi commerciali per la scalabilità. Tuttavia, si consiglia di eseguire questa operazione solo come ultima risorsa per migliorare le prestazioni di Cluster Autoscaler.

Questa configurazione ha i suoi svantaggi. Può comportare una scalabilità non necessaria rispetto a più gruppi di nodi. I nodi aggiuntivi si ridimensionano di nuovo dopo il scale-down-delay.

metadata: name: cluster-autoscaler namespace: cluster-autoscaler-1 ... --nodes=1:10:k8s-worker-asg-1 --nodes=1:10:k8s-worker-asg-2 --- metadata: name: cluster-autoscaler namespace: cluster-autoscaler-2 ... --nodes=1:10:k8s-worker-asg-3 --nodes=1:10:k8s-worker-asg-4

Assicurarsi che le seguenti condizioni siano rispettate.

  • Ogni shard è configurato in modo da puntare a un set univoco di gruppi di Amazon EC2 Auto Scaling.

  • Ogni shard viene implementato in uno spazio dei nomi separato per evitare conflitti di leader election.

Efficienza dei costi e disponibilità

Le opzioni principali per ottimizzare l'efficienza dei costi di Cluster Autoscaler sono correlate al provisioning delle istanze Amazon EC2. Inoltre, l'efficienza dei costi deve essere bilanciata con la disponibilità. In questa sezione vengono descritte le strategie, come ad esempio l'utilizzo delle istanze Spot, per ridurre i costi e l'overprovisioning per ridurre la latenza durante la creazione di nuovi nodi.

  • Disponibilità – I pod possono essere pianificati rapidamente e senza interruzioni. Questo vale anche per nel momento in cui i pod appena creati devono essere pianificati e quando un nodo ridimensionato termina eventuali pod rimanenti pianificati su di esso.

  • Costo – Determinato dalla decisione alla base degli eventi di scaling orizzontale e verticale. Le risorse vengono sprecate se un nodo esistente è sottoutilizzato o se viene aggiunto un nuovo nodo troppo grande per i pod in ingresso. A seconda del caso d'uso specifico, ci possono essere costi associati a pod terminanti prematuramente a causa di una decisione aggressiva di ridimensionamento.

Istanze Spot

É possibile usare Istanze Spot nei gruppi di nodi per risparmiare fino al 90% sul prezzo on demand. Questo ha il compromesso delle Istanze Spot eventualmente interrotte in qualsiasi momento in cui Amazon EC2 ha nuovamente bisogno della capacità, Insufficient Capacity Errors si verificano ogni volta che il proprio gruppo Amazon EC2 Auto Scaling non può aumentare a causa della mancanza di capacità disponibile. La selezione di molte famiglie di istanze diverse comporta due vantaggi principali. Innanzitutto, può aumentare le possibilità di raggiungere il dimensionamento desiderato sfruttando molti pool di capacità Spot. In secondo luogo, può anche ridurre l'impatto delle interruzioni delle istanze Spot sulla disponibilità del cluster. Le policy di istanza miste con istanze spot sono un ottimo modo per aumentare la diversità senza aumentare il numero di gruppi di nodi. Tuttavia, è importante sapere che, nel caso siano necessarie risorse garantite, bisogna utilizzare Istanze on-demand anziché Istanze Spot.

Le istanze Spot potrebbero essere terminate quando la domanda di istanze aumenta. Per ulteriori informazioni, consultare Avvisi interruzione istanza Spot nella Guida per l'utente Amazon EC2 per le istanze Linux. Il progetto AWS Gestore di terminazione del nodo avvisa automaticamente il piano di controllo Kubernetes quando un nodo sta scendendo. Il progetto utilizza l'API Kubernetes per cordonare il nodo, in modo da garantire che nessun nuovo lavoro sia pianificato lì, quindi lo svuota e rimuove qualsiasi lavoro esistente.

È fondamentale che tutti i tipi di istanza abbiano una capacità di risorse simile durante la configurazione di Policy di istanze miste. Il simulatore di pianificazione dell'autoscaler utilizza il primo tipo di istanza nella Policy di Istanza Mista. Se i tipi di istanza successivi sono più grandi, le risorse potrebbero essere sprecate dopo una scalabilità superiore. Se le istanze sono più piccole, i pod potrebbero non riuscire a pianificare le nuove istanze a causa della capacità insufficiente. Ad esempio: tutte le istanze M4, M5, M5a, e M5n hanno quantità simili di CPU e memoria e sono ottimi candidati per una policy di istanza mista. Lo strumento di selezione delle istanze Amazon EC2 può aiutarti a identificare tipi di istanza simili o criteri critici aggiuntivi, come la dimensione. Per ulteriori informazioni, consultare Selettore di istanza Amazon EC2 su GitHub.

Consigliamo di isolare la capacità delle istanze On-demand e Spot in gruppi separati di Amazon EC2 Auto Scaling. Si consiglia questo utilizzando una strategia di capacità di base perché le proprietà di pianificazione delle istanze on-Demand e Spot sono diverse. Le istanze spot possono essere interrotte in qualsiasi momento. Quando Amazon EC2 ha bisogno nuovamente della capacità, i nodi preventivi sono spesso contaminati, richiedendo quindi una tolleranza esplicita del pod al comportamento di prelazione. Ciò si traduce in diverse proprietà di pianificazione per i nodi, quindi dovrebbero essere separati in più gruppi di Amazon EC2 Auto Scaling.

Il Cluster Autoscaler coinvolge il concetto di Espanditori. Essi forniscono collettivamente diverse strategie per la selezione del gruppo di nodi da scalare. La strategia --expander=least-waste è un buon default per scopo generico e se si intende utilizzare più gruppi di nodi per la diversificazione delle istanze Spot. Come descritto in precedenza, potrebbe aiutare ulteriormente a ottimizzare i costi dei gruppi di nodi ridimensionando il gruppo che sarebbe meglio utilizzare dopo l'attività di dimensionamento.

Assegnazione delle priorità a un gruppo di nodi o a un gruppo Auto Scaling

È inoltre possibile configurare la scalabilità automatica basata sulle priorità utilizzando il metodo di espansione Priority. --expander=priority consente al cluster di assegnare priorità a un gruppo di nodi o a un gruppo Auto Scaling e, se non è in grado di scalare per qualsiasi motivo, sceglierà il gruppo di nodi successivo nell'elenco con priorità. Ciò è utile in situazioni in cui, ad esempio, si desidera utilizzare P3 perché la loro GPU fornisce prestazioni ottimali per il carico di lavoro, ma come seconda opzione è anche possibile utilizzare tipi di istanza P2. Ad esempio:

apiVersion: v1 kind: ConfigMap metadata: name: cluster-autoscaler-priority-expander namespace: kube-system data: priorities: |- 10: - .*p2-node-group.* 50: - .*p3-node-group.*

Cluster Autoscaler tenta di aumentare il gruppo Amazon EC2 Auto Scaling corrispondente al nome p3-node-group. Se questa operazione non ha esito positivo all'interno di --max-node-provision-time, questi tenta di ridimensionare un gruppo Amazon EC2 Auto Scaling corrispondente al nome p2-node-group. Questo valore predefinito è di 15 minuti e può essere ridotto per una selezione più reattiva del gruppo di nodi. Tuttavia, se il valore è troppo basso, potrebbe verificarsi una scalatura non necessaria.

Overprovisioning

Il Cluster Autoscaler consente di ridurre al minimo i costi garantendo che i nodi vengano aggiunti al cluster solo quando sono necessari e che vengano rimossi quando non vengono utilizzati. Ciò influisce in modo significativo sulla latenza di implementazione perché molti pod devono attendere la scalabilità di un nodo prima di poter essere pianificati. I nodi possono richiedere più minuti per diventare disponibili, il che può aumentare la latenza di pianificazione del pod di un ordine di grandezza.

Questo può essere mitigato usando overprovisioning, che tratta i costi per la latenza di programmazione. L'overprovisioning viene implementato utilizzando pod temporanei con priorità negativa. Questi pod occupano spazio nel cluster. Quando i pod appena creati non sono programmabili e hanno una priorità più alta, i pod temporanei vengono annullati per fare spazio. Quindi, i pod temporanei diventano non programmabili, facendo sì che il Cluster Autoscaler ridimensioni orizzontalmente i nuovi nodi con overprovisioning.

L'overprovisioning comporta altri vantaggi. Senza overprovisioning, i pod in un cluster altamente utilizzato prendono decisioni di pianificazione meno ottimali utilizzando la regola preferredDuringSchedulingIgnoredDuringExecution. Un caso d'uso comune per questo consiste nel separare i pod per un'applicazione a disponibilità elevata nelle zone di disponibilità utilizzando AntiAffinity. L'overprovisioning può aumentare significativamente la possibilità che sia disponibile un nodo della zona desiderata.

È importante scegliere una quantità appropriata di capacità in eccesso. Un modo in cui è possibile assicurarsi di scegliere una quantità appropriata consiste nel prendere la frequenza media di scalabilità e dividerla per la durata del tempo necessario per dimensionare verso l'alto un nuovo nodo. Ad esempio, se in media si ha bisogno di un nuovo nodo ogni 30 secondi e Amazon EC2 impiega 30 secondi per effettuare il provisioning di un nuovo nodo, un singolo nodo di overprovisioning assicura che sia sempre disponibile un nodo aggiuntivo. In questo modo è possibile ridurre la latenza di programmazione di 30 secondi al costo di una singola istanza Amazon EC2 aggiuntiva. Per prendere decisioni di pianificazione zonale migliori, è anche possibile eseguire il provisioning eccessivo del numero di nodi in modo che corrisponda al numero di zone di disponibilità nel proprio gruppo di Amazon EC2 Auto Scaling. In questo modo, l'utilità di pianificazione può selezionare la zona migliore per i pod in entrata.

Prevenire l'espulsione con scala ridotta

Alcuni carichi di lavoro sono costosi da espellere. L'analisi dei Big Data, le attività di machine learning e i test runner possono richiedere molto tempo per essere completati e devono essere riavviati in caso di interruzione. Il Cluster Autoscaler aiuta a ridimensionare qualsiasi nodo sotto il scale-down-utilization-threshold. Questo interrompe tutti i pod rimanenti sul nodo. Tuttavia, è possibile evitare che ciò accada assicurando che i pod che sono costosi da espellere siano protetti da un'etichetta riconosciuta da Cluster Autoscaler. Per fare ciò, assicurarsi che i pod che sono costosi da espellere abbiano l'etichetta cluster-autoscaler.kubernetes.io/safe-to-evict=false.

Karpenter

Amazon EKS supporta il progetto di scalabilità automatica open source Karpenter. Consulta la documentazione di Karpenter per eseguire l'implementazione.

Informazioni su Karpenter

Karpenter è un Cluster Autoscaler Kubernetes flessibile e ad alte prestazioni che aiuta a migliorare la disponibilità delle applicazioni e l'efficienza del cluster. Karpenter avvia risorse di calcolo di dimensioni corrette, ad esempio le istanze di Amazon EC2, in risposta alla modifica del carico dell'applicazione in meno di un minuto. Integrando Kubernetes con AWS, Karpenter è in grado di effettuare il provisioning di risorse di calcolo just-in-time che soddisfano con precisione i requisiti del carico di lavoro. Karpenter effettua automaticamente il provisioning di nuove risorse di calcolo in base ai requisiti specifici dei carichi di lavoro del cluster. Questi includono requisiti di calcolo, archiviazione, accelerazione e pianificazione. Amazon EKS supporta i cluster che utilizzano Karpenter, anche se Karpenter funziona con qualsiasi cluster di Kubernetes conforme.

Funzionamento di Karpenter

Karpenter funziona in tandem con il pianificatore di Kubernetes osservando i pod in entrata per tutta la durata del cluster. Avvia o termina i nodi per massimizzare la disponibilità delle applicazioni e l'utilizzo del cluster. Quando c'è abbastanza capacità nel cluster, il pianificatore di Kubernetes posiziona i pod in entrata come al solito. Quando vengono avviati pod che non possono essere pianificati utilizzando la capacità esistente del cluster, Karpenter ignora il pianificatore di Kubernetes e lavora direttamente con il servizio di calcolo del provider (ad esempio, Amazon EC2), per avviare le risorse di calcolo minime necessarie adatte ai pod e associa i pod ai nodi predisposti. Man mano che i pod vengono rimossi o riprogrammati su altri nodi, Karpenter cerca opportunità per terminare i nodi sottoutilizzati. L'esecuzione di un numero inferiore di nodi più grandi nel cluster riduce il sovraccarico dei DaemonSet e dei componenti di sistema di Kubernetes e offre maggiori opportunità per un efficiente bin-packing.

Prerequisiti

Prima di implementare Karpenter, è necessario soddisfare i seguenti prerequisiti:

Se si preferisce, è possibile implementare Karpenter usando eksctl. Consulta Installazione di eksctl.