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à.

Cluster Autoscaler

Panoramica di

Kubernetes Cluster Autoscaler è una popolare soluzione Cluster Autoscaling gestita da SIG Autoscaling. https://github.com/kubernetes/community/tree/master/sig-autoscaling È responsabile di garantire che il cluster abbia abbastanza nodi per pianificare i pod senza sprecare risorse. Controlla i pod che non vengono pianificati e i nodi sottoutilizzati. Quindi simula l'aggiunta o la rimozione di nodi prima di applicare la modifica al cluster. L'implementazione di AWS Cloud Provider all'interno di Cluster Autoscaler controlla il .DesiredReplicas campo dei tuoi EC2 Auto Scaling Groups.

Questa guida fornirà un modello mentale per configurare Cluster Autoscaler e scegliere il miglior set di compromessi per soddisfare i requisiti della tua organizzazione. Sebbene non esista una configurazione ottimale, esiste una serie di opzioni di configurazione che consentono di compromettere prestazioni, scalabilità, costi e disponibilità. Inoltre, questa guida fornirà suggerimenti e best practice per ottimizzare la configurazione per AWS.

Glossario

La seguente terminologia verrà utilizzata frequentemente in questo documento. Questi termini possono avere un significato ampio, ma sono limitati alle definizioni seguenti ai fini del presente documento.

La scalabilità si riferisce alle prestazioni del Cluster Autoscaler man mano che il cluster Kubernetes aumenta di numero di pod e nodi. Quando vengono raggiunti i limiti di scalabilità, le prestazioni e le funzionalità del Cluster Autoscaler peggiorano. Quando Cluster Autoscaler supera i limiti di scalabilità, potrebbe non aggiungere o rimuovere nodi nel cluster.

Le prestazioni si riferiscono alla velocità con cui Cluster Autoscaler è in grado di prendere ed eseguire decisioni di scalabilità. Un Cluster Autoscaler perfettamente funzionante prenderebbe immediatamente una decisione e innescherebbe un'azione di ridimensionamento in risposta a stimoli, ad esempio un pod che diventa non programmabile.

La disponibilità significa che i pod possono essere programmati rapidamente e senza interruzioni. Ciò include quando è necessario programmare i pod appena creati e quando un nodo ridimensionato chiude tutti i pod rimanenti programmati su di esso.

Il costo è determinato dalla decisione alla base dello scale-out e della scalabilità degli eventi. Le risorse vengono sprecate se un nodo esistente è sottoutilizzato o viene aggiunto un nuovo nodo troppo grande per i pod in arrivo. A seconda del caso d'uso, la chiusura prematura dei pod a causa di una decisione aggressiva di ridimensionamento può comportare dei costi.

I gruppi di nodi sono un concetto astratto di Kubernetes per un gruppo di nodi all'interno di un cluster. Non è una vera risorsa Kubernetes, ma esiste come astrazione nel Cluster Autoscaler, nell'API del Cluster e in altri componenti. I nodi all'interno di un gruppo di nodi condividono proprietà come etichette e taint, ma possono essere costituiti da più zone di disponibilità o tipi di istanza.

Gli EC2 Auto Scaling Groups possono essere utilizzati come implementazione dei Node Groups su EC2. I gruppi EC2 Auto Scaling sono configurati per avviare istanze che si uniscono automaticamente ai loro cluster Kubernetes e applicano etichette e taint alla risorsa Node corrispondente nell'API Kubernetes.

I gruppi di nodi gestiti EC2 sono un'altra implementazione dei gruppi di nodi su EC2. Eliminano la complessità della configurazione manuale di EC2 Autoscaling Scaling Groups e forniscono funzionalità di gestione aggiuntive come l'aggiornamento della versione del nodo e la terminazione semplificata dei nodi.

Funzionamento del Cluster Autoscaler

Il Cluster Autoscaler viene in genere installato come implementazione nel cluster. Utilizza l'elezione del leader per garantire un'elevata disponibilità, ma il lavoro viene svolto da una singola replica alla volta. Non è scalabile orizzontalmente. Per le configurazioni di base, l'impostazione predefinita dovrebbe funzionare immediatamente utilizzando le istruzioni di installazione fornite, ma ci sono alcune cose da tenere a mente.

Verifica che:

Utilizza l'accesso meno privilegiato al ruolo IAM

Quando si utilizza l'Auto Discovery, si consiglia vivamente di utilizzare l'accesso con privilegi minimi limitando le azioni autoscaling:SetDesiredCapacity e i gruppi Auto Scaling con ambito autoscaling:TerminateInstanceInAutoScalingGroup al cluster corrente.

Ciò impedirà a un Cluster Autoscaler in esecuzione in un cluster di modificare i gruppi di nodi in un cluster diverso anche se l'--node-group-auto-discoveryargomento non è stato limitato ai gruppi di nodi del cluster utilizzando i tag (ad esempio). k8s.io/cluster-autoscaler/<cluster-name>

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/my-cluster": "owned"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "ec2:DescribeImages",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:GetInstanceTypesFromInstanceRequirements",
                "eks:DescribeNodegroup"
            ],
            "Resource": "*"
        }
    ]
}

Configurazione dei gruppi di nodi

Una scalabilità automatica efficace inizia con la corretta configurazione di un set di gruppi di nodi per il cluster. La selezione del giusto set di gruppi di nodi è fondamentale per massimizzare la disponibilità e ridurre i costi per tutti i carichi di lavoro. AWS implementa i Node Groups utilizzando gli Auto Scaling Groups EC2, che sono flessibili per un gran numero di casi d'uso. Tuttavia, il Cluster Autoscaler formula alcune ipotesi sui gruppi di nodi. Mantenere le configurazioni del gruppo EC2 Auto Scaling coerenti con questi presupposti ridurrà al minimo i comportamenti indesiderati.

Verifica che:

Ottimizzazione delle prestazioni e della scalabilità

Comprendere la complessità di runtime dell'algoritmo di scalabilità automatica ti aiuterà a ottimizzare Cluster Autoscaler per continuare a funzionare senza problemi in cluster di grandi dimensioni con più di 1.000 nodi. https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/proposals/scalability_tests.md

Le manopole principali per l'ottimizzazione della scalabilità di Cluster Autoscaler sono le risorse fornite al processo, l'intervallo di scansione dell'algoritmo e il numero di gruppi di nodi nel cluster. Ci sono altri fattori coinvolti nella vera complessità di runtime di questo algoritmo, come la complessità della pianificazione del plug-in e il numero di pod. Questi sono considerati parametri non configurabili in quanto sono naturali per il carico di lavoro del cluster e non possono essere regolati facilmente.

Il Cluster Autoscaler carica in memoria lo stato dell'intero cluster, inclusi pod, nodi e gruppi di nodi. A ogni intervallo di scansione, l'algoritmo identifica i pod non programmabili e simula la pianificazione per ciascun gruppo di nodi. L'ottimizzazione di questi fattori comporta diversi compromessi che devono essere considerati attentamente in base al caso d'uso.

Scalabilità automatica verticale del Cluster Autoscaler

Il modo più semplice per scalare Cluster Autoscaler su cluster più grandi è aumentare le richieste di risorse per la sua implementazione. Sia la memoria che la CPU dovrebbero essere aumentate per i cluster di grandi dimensioni, sebbene ciò vari in modo significativo in base alle dimensioni del cluster. L'algoritmo di scalabilità automatica memorizza tutti i pod e i nodi in memoria, il che può comportare un ingombro di memoria superiore a un gigabyte in alcuni casi. L'aumento delle risorse viene in genere eseguito manualmente. Se ritieni che l'ottimizzazione costante delle risorse stia creando un onere operativo, prendi in considerazione l'utilizzo di Addon Resizer o Vertical Pod Autoscaler.

Ridurre il numero di gruppi di nodi

Ridurre al minimo il numero di gruppi di nodi è un modo per garantire che Cluster Autoscaler continui a funzionare bene su cluster di grandi dimensioni. Questo può essere difficile per alcune organizzazioni che strutturano i propri gruppi di nodi per team o per applicazione. Sebbene sia completamente supportato dall'API Kubernetes, è considerato un anti-pattern di Cluster Autoscaler con ripercussioni sulla scalabilità. Esistono molte ragioni per utilizzare più gruppi di nodi (ad esempio Spot o GPU), ma in molti casi esistono design alternativi che ottengono lo stesso effetto utilizzando un numero limitato di gruppi.

Verifica che:

Riduzione dell'intervallo di scansione

Un intervallo di scansione basso (ad esempio 10 secondi) assicurerà che Cluster Autoscaler risponda il più rapidamente possibile quando i pod diventano non programmabili. Tuttavia, ogni scansione comporta molte chiamate API all'API Kubernetes e alle API EC2 Auto Scaling Group o EKS Managed Node Group. Queste chiamate API possono comportare una limitazione della velocità o addirittura l'indisponibilità del servizio per il tuo Kubernetes Control Plane.

L'intervallo di scansione predefinito è di 10 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 l'avvio di un nodo impiega 2 minuti, cambiando l'intervallo a 1 minuto si otterrà un compromesso tra una riduzione di 6 volte le chiamate API e una scalabilità più lenta del 38%.

Sharding tra gruppi di nodi

Il Cluster Autoscaler può essere configurato per funzionare su un set specifico di gruppi di nodi. Utilizzando questa funzionalità, è possibile implementare più istanze del Cluster Autoscaler, ciascuna configurata per operare su un diverso set di gruppi di nodi. Questa strategia consente di utilizzare un numero arbitrariamente elevato di gruppi di nodi, scambiando i costi con la scalabilità. Consigliamo di utilizzarla solo come ultima risorsa per migliorare le prestazioni.

Il Cluster Autoscaler non è stato originariamente progettato per questa configurazione, quindi ci sono alcuni effetti collaterali. Poiché gli shard non comunicano, è possibile che più autoscaler tentino di pianificare un pod non programmabile. Ciò può comportare una scalabilità non necessaria di più gruppi di nodi. Questi nodi aggiuntivi verranno ridimensionati dopo ilscale-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

Verifica che:

Ottimizzazione dei costi e della disponibilità

Spot Instances

Puoi utilizzare le istanze Spot nei tuoi gruppi di nodi e risparmiare fino al 90% sul prezzo on demand, con il compromesso che le istanze Spot possono essere interrotte in qualsiasi momento quando EC2 ha bisogno di recuperare la capacità. Si verificheranno errori di capacità insufficiente quando il gruppo EC2 Auto Scaling non riesce a scalare a causa della mancanza di capacità disponibile. Massimizzare la diversità selezionando molte famiglie di istanze può aumentare le possibilità di raggiungere la scalabilità desiderata attingendo a molti pool di capacità Spot e 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. Tieni presente che se hai bisogno di risorse garantite, utilizza le On-Demand istanze anziché le istanze Spot.

È fondamentale che tutti i tipi di istanze abbiano una capacità di risorse simile quando si configurano le policy per le istanze miste. Il simulatore di pianificazione dell'autoscaler utilizza il primo in. InstanceType MixedInstancePolicy Se i tipi di istanza successivi sono più grandi, le risorse potrebbero andare sprecate dopo uno scale-up. Se sono più piccoli, i pod potrebbero non essere programmati sulle nuove istanze a causa della capacità insufficiente. Ad esempio, le istanze M4, M5, M5a e M5n hanno tutte quantità di CPU e memoria simili e sono ottime candidate per un. MixedInstancePolicy Lo strumento EC2 Instance Selector può aiutarti a identificare tipi di istanze simili.

Si consiglia di isolare On-Demand e individuare la capacità in gruppi EC2 Auto Scaling separati. Questa operazione è preferibile rispetto all'utilizzo di una strategia di capacità di base perché le proprietà di pianificazione sono fondamentalmente diverse. Poiché le istanze Spot possono essere interrotte in qualsiasi momento (quando EC2 ha bisogno di recuperare la capacità), gli utenti spesso alterano i nodi preattivabili, richiedendo un'esplicita tolleranza da parte dei pod al comportamento di prelazione. Questi difetti comportano proprietà di pianificazione diverse per i nodi, quindi dovrebbero essere separati in più gruppi EC2 Auto Scaling.

Il Cluster Autoscaler ha un concetto di espansori, che forniscono diverse strategie per selezionare il gruppo di nodi da scalare. --expander=least-wasteQuesta strategia è una buona strategia predefinita generica e, se intendete utilizzare più gruppi di nodi per la diversificazione delle istanze Spot (come descritto nell'immagine precedente), potrebbe aiutare a ottimizzare ulteriormente i costi dei gruppi di nodi scalando il gruppo che sarebbe meglio utilizzare dopo l'attività di scalabilità.

Dare priorità a un gruppo di nodi/ASG

È inoltre possibile configurare la scalabilità automatica basata sulla priorità utilizzando l'espansore Priority. --expander=priorityconsente al cluster di dare priorità a un gruppo di nodi/ASG 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, desideri utilizzare i tipi di istanza P3 perché la loro GPU offre prestazioni ottimali per il carico di lavoro, ma come seconda opzione puoi anche utilizzare i tipi di istanza P2.

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 proverà a scalare il gruppo EC2 Auto Scaling corrispondente al nome p3-node-group. Se questa operazione non riesce, tenterà di scalare un gruppo EC2 --max-node-provision-time Auto Scaling corrispondente al nome p2-node-group. Questo valore predefinito è 15 minuti e può essere ridotto per una selezione più reattiva dei gruppi di nodi, tuttavia se il valore è troppo basso, può causare inutili scalature.

Overprovisioning

Il Cluster Autoscaler riduce al minimo i costi garantendo che i nodi vengano aggiunti al cluster solo quando necessario e rimossi quando non utilizzati. Ciò ha un impatto significativo sulla latenza di implementazione perché molti pod saranno costretti ad attendere la scalabilità di un nodo prima di poter essere programmati. 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, che occupano spazio nel cluster. Quando i pod appena creati non sono programmabili e hanno una priorità più alta, ai pod temporanei verrà impedito di fare spazio. I pod temporanei diventano quindi non programmabili, attivando Cluster Autoscaler per ridimensionare i nuovi nodi con sovraprovisioning.

L'overprovisioning comporta altri vantaggi meno evidenti. Senza sovraprovisioning, uno degli effetti collaterali di un cluster altamente utilizzato è che i pod prenderanno decisioni di pianificazione meno ottimali utilizzando la regola di Pod o Node Affinity. preferredDuringSchedulingIgnoredDuringExecution Un caso d'uso comune è quello di separare i pod per un'applicazione ad alta disponibilità tra le zone di disponibilità utilizzando. AntiAffinity L'overprovisioning può aumentare significativamente la possibilità che sia disponibile un nodo della zona corretta.

La quantità di capacità sovradimensionata è una decisione aziendale attenta per l'organizzazione. Fondamentalmente, è un compromesso tra prestazioni e costi. Un modo per prendere questa decisione è determinare la frequenza media di scalabilità e dividerla per il tempo necessario per scalare un nuovo nodo. Ad esempio, se in media è necessario un nuovo nodo ogni 30 secondi e EC2 impiega 30 secondi per eseguire il provisioning di un nuovo nodo, un singolo nodo di overprovisioning garantirà la disponibilità di un nodo aggiuntivo, riducendo la latenza di pianificazione di 30 secondi al costo di una singola istanza EC2 aggiuntiva. Per migliorare le decisioni sulla pianificazione zonale, esegui un overprovisioning di un numero di nodi pari al numero di zone di disponibilità nel tuo EC2 Auto Scaling Group per garantire che lo scheduler possa selezionare la zona migliore per i pod in arrivo.

Previeni lo sfratto basato su scala ridotta

Alcuni carichi di lavoro sono costosi da espellere. L'analisi dei big data, le attività di machine learning e i test runner alla fine verranno completati, ma dovranno essere riavviati in caso di interruzione. Il Cluster Autoscaler tenterà di ridimensionare qualsiasi nodo al di sotto della soglia di riduzione dell'utilizzo, interrompendo eventuali pod rimanenti sul nodo. Ciò può essere evitato assicurando che i pod costosi da sfrattare siano protetti da un'etichetta riconosciuta dal Cluster Autoscaler.

Verifica che:

Casi d'uso avanzati

Volumi EBS

L'archiviazione persistente è fondamentale per la creazione di applicazioni con stato, come database o cache distribuite. I volumi EBS consentono questo caso d'uso su Kubernetes, ma sono limitati a una zona specifica. Queste applicazioni possono essere altamente disponibili se suddivise in più AZ utilizzando un volume EBS separato per ogni AZ. Il Cluster Autoscaler può quindi bilanciare la scalabilità dei gruppi di autoscaling EC2.

Verifica che:

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. Ciò può essere ottenuto impostando Pod Affinity per tutti i pod co-programmati o utilizzando Node Affinity. topologyKey: failure-domain.beta.kubernetes.io/zone Il Cluster Autoscaler ridimensionerà quindi una zona specifica per soddisfare le esigenze. Potresti voler allocare più gruppi EC2 Auto Scaling, uno per zona di disponibilità, per abilitare il failover per l'intero carico di lavoro co-pianificato.

Verifica che:

Acceleratori

Alcuni cluster sfruttano acceleratori hardware specializzati come la GPU. In caso di scalabilità orizzontale, il plug-in del dispositivo accelerator può impiegare diversi minuti per pubblicizzare la risorsa al cluster. Il Cluster Autoscaler ha simulato che questo nodo avrà l'acceleratore, ma finché l'acceleratore non sarà pronto e non aggiorna le risorse disponibili del nodo, non sarà possibile pianificare i pod in sospeso sul nodo. Ciò può comportare la ripetizione inutile della scalabilità orizzontale.

Inoltre, i nodi con acceleratori e un elevato utilizzo della CPU o della memoria non verranno presi in considerazione per la riduzione, anche se l'acceleratore non è utilizzato. Questo comportamento può essere costoso a causa del costo relativo degli acceleratori. Invece, Cluster Autoscaler può applicare regole speciali per considerare i nodi da scalare verso il basso se dispongono di acceleratori non occupati.

Per garantire il comportamento corretto in questi casi, puoi configurare il kubelet sui nodi dell'acceleratore per etichettare il nodo prima che si unisca al cluster. Cluster Autoscaler utilizzerà questo selettore di etichette per attivare il comportamento ottimizzato dell'acceleratore.

Verifica che:

Scalabilità da 0

Cluster Autoscaler è in grado di scalare i gruppi di nodi da e verso lo zero, il che può comportare significativi risparmi sui costi. Rileva le risorse di CPU, memoria e GPU di un Auto Scaling Group ispezionando quanto specificato nel relativo or. InstanceType LaunchConfiguration LaunchTemplate Alcuni pod richiedono risorse aggiuntive come WindowsENI o o specifiche PrivateIPv4Address NodeSelectors o Taints che non possono essere scoperte da. LaunchConfiguration Il Cluster Autoscaler può tenere conto di questi fattori scoprendoli dai tag di EC2 Auto Scaling Group. Ad esempio:

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

Parametri aggiuntivi

Ci sono molte opzioni di configurazione che possono essere utilizzate per ottimizzare il comportamento e le prestazioni di Cluster Autoscaler. Un elenco completo dei parametri è disponibile su GitHub.

Risorse aggiuntive

Questa pagina contiene un elenco di presentazioni e demo di Cluster Autoscaler. Se desideri aggiungere una presentazione o una demo qui, invia una pull request.

Riferimenti