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

Kubernetes Cluster Autoscaler è una popolare soluzione Cluster Autoscaling gestita da Autoscaling. SIG È responsabile di garantire che il cluster disponga di nodi sufficienti per pianificare i pod senza sprecare risorse. Rileva i pod che non riescono a programmarsi e i nodi sottoutilizzati. Quindi simula l'aggiunta o la rimozione di nodi prima di applicare la modifica al cluster. L'implementazione del AWS Cloud Provider all'interno di Cluster Autoscaler controlla il .DesiredReplicas campo dei tuoi Gruppi di Auto Scaling. EC2

Questa guida fornirà un modello mentale per configurare Cluster Autoscaler e scegliere il miglior set di compromessi per soddisfare i requisiti dell'organizzazione. Sebbene non esista un'unica configurazione ottimale, esiste una serie di opzioni di configurazione che consentono di scendere a compromessi tra 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 riportate di seguito ai fini del presente documento.

La scalabilità si riferisce alle prestazioni di Cluster Autoscaler all'aumentare del numero di pod e nodi del cluster Kubernetes. Quando vengono raggiunti i limiti di scalabilità, le prestazioni e la funzionalità di Cluster Autoscaler diminuiscono. Poiché Cluster Autoscaler supera i limiti di scalabilità, non può più aggiungere o rimuovere nodi nel cluster.

Le prestazioni si riferiscono alla rapidità con cui Cluster Autoscaler è in grado di prendere ed eseguire decisioni di scalabilità. Un Cluster Autoscaler dalle prestazioni perfette prenderebbe istantaneamente una decisione e attiverebbe un'azione di scalabilità in risposta a stimoli, ad esempio se un pod diventasse non programmabile.

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

Il costo è determinato dalla decisione alla base degli eventi di scalabilità orizzontale e scalabile in base agli eventi. Le risorse vengono sprecate se un nodo esistente viene sottoutilizzato o viene aggiunto un nuovo nodo troppo grande per i pod in entrata. A seconda del caso d'uso, la chiusura anticipata dei pod può comportare dei costi dovuti a una decisione aggressiva di ridimensionamento.

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 in Cluster Autoscaler, Cluster e altri componenti. API I nodi all'interno di un gruppo di nodi condividono proprietà come etichette e caratteri, ma possono essere costituiti da più zone di disponibilità o tipi di istanze.

EC2I gruppi di Auto Scaling possono essere utilizzati come implementazione dei gruppi di nodi su. EC2 EC2I gruppi di Auto Scaling sono configurati per avviare istanze che si uniscono automaticamente ai rispettivi cluster Kubernetes e applicare etichette e contaminazioni alla risorsa Node corrispondente in Kubernetes. API

EC2I Managed Node Groups sono un'altra implementazione di Node Groups on. EC2 Riducono 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 chiusura graduale dei nodi.

Funzionamento del Cluster Autoscaler

Il Cluster Autoscaler viene in genere installato come implementazione nel cluster. Utilizza l'elezione dei 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.

Assicuratevi 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 autoscaling:TerminateInstanceInAutoScalingGroup ai gruppi di Auto Scaling che hanno come ambito il 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 dei carichi di lavoro. AWSimplementa i gruppi di nodi utilizzando i gruppi di EC2 Auto Scaling, che sono flessibili per un gran numero di casi d'uso. Tuttavia, 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.

Assicuratevi che:

Nota: consigliamo di utilizzare i gruppi di nodi EKS gestiti. I gruppi di nodi gestiti sono dotati di potenti funzionalità di gestione, tra cui funzionalità per Cluster Autoscaler come l'individuazione automatica dei gruppi di EC2 Auto Scaling e la chiusura graduale dei nodi.

Ottimizzazione per prestazioni e scalabilità

La comprensione della complessità di runtime dell'algoritmo di scalabilità automatica vi aiuterà a ottimizzare Cluster Autoscaler per continuare a funzionare senza problemi in cluster di grandi dimensioni con più di 1.000 nodi.

Le manopole principali per ottimizzare la 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. Esistono altri fattori coinvolti nella vera complessità di runtime di questo algoritmo, come la pianificazione, la complessità dei plugin 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.

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

Scalabilità automatica verticale del Cluster Autoscaler

Il modo più semplice per scalare Cluster Autoscaler su cluster più grandi consiste nell'aumentare le richieste di risorse per la sua implementazione. Per i cluster di grandi dimensioni è CPU necessario aumentare sia la memoria che la dimensione del cluster, anche se questo valore varia notevolmente a seconda delle dimensioni del cluster. L'algoritmo di scalabilità automatica archivia 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 crei 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 questo sia pienamente supportato da KubernetesAPI, è considerato un anti-pattern di Cluster Autoscaler con ripercussioni sulla scalabilità. Esistono molte ragioni per utilizzare più gruppi di nodi (ad esempio Spot oGPUs), ma in molti casi esistono design alternativi che ottengono lo stesso effetto utilizzando un numero limitato di gruppi.

Assicuratevi 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 genera molte API chiamate a Kubernetes and EC2 Auto API Scaling Group o Managed Node Group. EKS APIs Queste API chiamate possono comportare una limitazione della velocità o addirittura l'indisponibilità del servizio per Kubernetes Control Plane.

L'intervallo di scansione predefinito è di 10 secondi, ma l'avvio di un nodo richiede molto più tempo per avviare una nuova istanza. AWS Ciò significa che è possibile aumentare l'intervallo senza aumentare significativamente il tempo complessivo di scalabilità. Ad esempio, se l'avvio di un nodo richiede 2 minuti, la modifica dell'intervallo a 1 minuto comporterà un compromesso tra API chiamate ridotte di 6 volte e scalabilità più lente del 38%.

Condivisione tra gruppi di nodi

Il Cluster Autoscaler può essere configurato per funzionare su un set specifico di gruppi di nodi. Utilizzando questa funzionalità, è possibile distribuire più istanze di Cluster Autoscaler, ognuna configurata per funzionare su un diverso set di gruppi di nodi. Questa strategia consente di utilizzare un numero arbitrario 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 presenta 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

Assicurati 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 su richiesta. Con un compromesso, le istanze Spot possono essere interrotte in qualsiasi momento quando è necessario ripristinare la capacità. EC2 Si verificheranno errori di capacità insufficiente quando il gruppo EC2 Auto Scaling non può aumentare a causa della mancanza di capacità disponibile. Massimizzare la diversità selezionando più famiglie di istanze può aumentare le possibilità di ottenere 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 istanze on demand anziché le istanze Spot.

È fondamentale che tutti i tipi di istanza abbiano una capacità di risorse simile durante la configurazione delle politiche per istanze miste. Il simulatore di pianificazione di Autoscaler utilizza il primo di. InstanceType MixedInstancePolicy Se i tipi di istanza successivi sono più grandi, le risorse potrebbero essere sprecate dopo un ampliamento. Se sono più piccoli, i pod potrebbero non riuscire a programmarsi sulle nuove istanze a causa della capacità insufficiente. Ad esempio, le istanze M4, M5, M5a e M5n hanno tutte quantità simili di CPU memoria e sono ottime candidate per un. MixedInstancePolicy Lo strumento EC2Instance Selector può aiutarti a identificare tipi di istanze simili.

Si consiglia di isolare la capacità On-Demand e Spot in gruppi di Auto EC2 Scaling separati. Questa soluzione è preferibile rispetto all'utilizzo di una strategia di capacità di base, poiché le proprietà di pianificazione sono fondamentalmente diverse. Poiché le istanze Spot vengono interrotte in qualsiasi momento (quando è EC2 necessario ripristinare la capacità), gli utenti spesso alterano i nodi presvuotabili, richiedendo un'esplicita tolleranza dei pod rispetto al comportamento di prelazione. Queste macchie determinano proprietà di pianificazione diverse per i nodi, quindi devono essere separati in più gruppi di Auto EC2 Scaling.

Cluster Autoscaler si basa sul concetto di Expander, che fornisce diverse strategie per la selezione del gruppo di nodi da scalare. La strategia --expander=least-waste è una buona impostazione predefinita per uso generale e, se intendi 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 utilizzato dopo l'attività di scalabilità.

Assegnazione di 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/eASG, 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 i tipi di istanza P3 perché GPU offrono prestazioni ottimali per il carico di lavoro, ma come seconda opzione è possibile utilizzare anche 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 all'interno--max-node-provision-time, tenterà di scalare un gruppo di EC2 Auto Scaling corrispondente al nome p2-node-group. Questo valore predefinito è di 15 minuti e può essere ridotto per una selezione del gruppo di nodi più reattiva, tuttavia, se il valore è troppo basso, può causare scale-out non necessari.

Overprovisioning

Cluster Autoscaler riduce al minimo i costi garantendo che i nodi vengano aggiunti al cluster solo quando necessario e rimossi quando non vengono utilizzati. Ciò influisce in modo significativo sulla latenza di implementazione perché molti pod saranno costretti ad 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, che occupano spazio nel cluster. Quando i pod appena creati non sono programmabili e hanno una priorità più alta, i pod temporanei avranno la precedenza per liberare spazio. I pod temporanei diventano quindi non programmabili, attivando Cluster Autoscaler per ridimensionare i nuovi nodi sovradimensionati.

L'overprovisioning presenta altri vantaggi meno evidenti. Senza overprovisioning, 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 consiste nel separare i pod per un'applicazione ad alta disponibilità tra le zone di disponibilità utilizzando. AntiAffinity L'overprovisioning può aumentare in modo significativo la possibilità che sia disponibile un nodo della zona corretta.

La quantità di capacità sovradimensionata è una decisione aziendale attenta per l'organizzazione. Fondamentalmente, si tratta di 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 hai bisogno di un nuovo nodo ogni 30 secondi e EC2 impiega 30 secondi per il provisioning di un nuovo nodo, un singolo nodo di overprovisioning assicurerà che sia sempre disponibile un nodo aggiuntivo, riducendo la latenza di pianificazione di 30 secondi al costo di una singola istanza aggiuntiva. EC2 Per migliorare le decisioni di pianificazione zonale, esegui il overprovisioning di un numero di nodi pari al numero di zone di disponibilità nel tuo Gruppo EC2 Auto Scaling per assicurarti che lo scheduler possa selezionare la zona migliore per i pod in entrata.

Previeni lo sfratto da Scale Down

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 devono essere riavviati se interrotti. Cluster Autoscaler tenterà di ridimensionare qualsiasi nodo al di sotto di scale-down-utilization-threshold, interrompendo tutti i pod rimanenti sul nodo. Ciò può essere evitato assicurando che i pod costosi da rimuovere siano protetti da un'etichetta riconosciuta dal Cluster Autoscaler.

Assicuratevi che:

Casi d'uso avanzati

EBSVolumi

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

Assicuratevi che:

Pianificazione congiunta

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 Cluster Autoscaler ridimensionerà quindi una zona specifica per soddisfare le richieste. Potresti voler allocare più Gruppi di EC2 Auto Scaling, uno per zona di disponibilità, per abilitare il failover per l'intero carico di lavoro co-programmato.

Assicuratevi che:

Acceleratori

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

Inoltre, i nodi con acceleratori e un elevato CPU utilizzo 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. Al contrario, Cluster Autoscaler può applicare regole speciali per considerare i nodi da ridimensionare se hanno 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.

Assicuratevi che:

Scalabilità da 0

Cluster Autoscaler è in grado di scalare i gruppi di nodi da e verso lo zero, il che può portare a significativi risparmi sui costi. Rileva la memoria e CPU le GPU risorse di un gruppo di Auto Scaling ispezionando quanto specificato InstanceType nel suo o. LaunchConfiguration LaunchTemplate Alcuni pod richiedono risorse aggiuntive come WindowsENI o o specifiche PrivateIPv4Address NodeSelectors o Taints che non possono essere scoperte tramite. LaunchConfiguration Cluster Autoscaler può tenere conto di questi fattori scoprendoli dai tag del gruppo Auto Scaling. EC2 Per 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

Nota: tieni presente che quando si esegue la scalabilità a zero, la capacità viene ripristinata EC2 e potrebbe non essere più disponibile in futuro.

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

📝 Modifica questa pagina su GitHub