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

Karpenter

Karpenter è un progetto open source che fornisce la gestione del ciclo di vita dei nodi per i cluster Kubernetes. Automatizza il provisioning e il deprovisioning dei nodi in base alle esigenze di pianificazione dei pod, consentendo una scalabilità efficiente e l'ottimizzazione dei costi. Le sue funzioni principali sono:

Con Karpenter, puoi definire NodePools vincoli sul provisioning dei nodi come contaminazioni, etichette, requisiti (tipi di istanze, zone, ecc.) e limiti sulle risorse totali assegnate. Quando si distribuiscono carichi di lavoro, è possibile specificare i vincoli di pianificazione nelle specifiche del pod, come le affinità delle risorse, le tolleranze e i vincoli di diffusione della topologia. requests/limits, node selectors, node/pod Karpenter fornirà quindi i nodi della giusta dimensione per quei pod.

Motivi per usare Karpenter

Prima del lancio di Karpenter, gli utenti di Kubernetes si affidavano principalmente ai gruppi Amazon Auto Scaling EC2 e al Kubernetes Cluster Autoscaler () per regolare dinamicamente la capacità di elaborazione dei propri cluster. CAS Con Karpenter, non è necessario creare dozzine di gruppi di nodi per ottenere la flessibilità e la diversità offerte da Karpenter. Inoltre, Karpenter non è così strettamente associato alle versioni di Kubernetes (come lo CAS è) e non richiede di passare da una versione all'altra di Kubernetes. AWS APIs

Karpenter consolida le responsabilità di orchestrazione delle istanze all'interno di un unico sistema, che è più semplice, stabile e compatibile con i cluster. Karpenter è stato progettato per superare alcune delle sfide presentate da Cluster Autoscaler fornendo modi semplificati per:

Per informazioni e documentazione sull'uso di Karpenter, visitate il sito karpenter.sh.

Raccomandazioni

Le migliori pratiche sono suddivise in sezioni relative a Karpenter stesso e alla pianificazione dei pod NodePools.

Le migliori pratiche di Karpenter

Le seguenti best practice riguardano argomenti relativi a Karpenter stesso.

Usa Karpenter per carichi di lavoro con esigenze di capacità mutevoli

Karpenter avvicina la gestione della scalabilità a APIs quella nativa di Kubernetes rispetto ad Autoscaling Groups () e Managed Node Groups (). ASGs MNGs ASGse MNGs sono astrazioni AWS native in cui il ridimensionamento viene attivato in base a metriche di livello, come il carico. AWS EC2 CPU Cluster Autoscaler collega le astrazioni di Kubernetes in AWS astrazioni, ma per questo motivo perde una certa flessibilità, ad esempio la pianificazione per una zona di disponibilità specifica.

Karpenter rimuove un livello di astrazione per portare parte della flessibilità direttamente in Kubernetes. AWS Karpenter è ideale per cluster con carichi di lavoro che incontrano periodi di domanda elevata e impennata o hanno requisiti di elaborazione diversi. MNGse ASGs sono ideali per i cluster che eseguono carichi di lavoro che tendono ad essere più statici e coerenti. È possibile utilizzare una combinazione di nodi gestiti dinamicamente e staticamente, a seconda delle esigenze.

Prendi in considerazione altri progetti di scalabilità automatica quando...

Hai bisogno di funzionalità che sono ancora in fase di sviluppo in Karpenter. Poiché Karpenter è un progetto relativamente nuovo, per il momento prendi in considerazione altri progetti di scalabilità automatica se hai bisogno di funzionalità che non fanno ancora parte di Karpenter.

Esegui il controller Karpenter su EKS Fargate o su un nodo di lavoro che appartiene a un gruppo di nodi

Karpenter viene installato utilizzando un grafico Helm. Il grafico Helm installa il controller Karpenter e un pod webhook come implementazione che deve essere eseguita prima che il controller possa essere utilizzato per scalare il cluster. Consigliamo un minimo di un piccolo gruppo di nodi con almeno un nodo di lavoro. In alternativa, puoi eseguire questi pod su EKS Fargate creando un profilo Fargate per il namespace. karpenter In questo modo tutti i pod distribuiti in questo spazio dei nomi verranno eseguiti su Fargate. EKS Non eseguite Karpenter su un nodo gestito da Karpenter.

Karpenter non supporta modelli di avvio personalizzati

Non è disponibile il supporto per i modelli di avvio personalizzati con v1beta1 (v0.32+)APIs. È possibile utilizzare dati utente personalizzati e/o specificare direttamente la personalizzazione in. AMIs EC2NodeClass Ulteriori informazioni su come eseguire questa operazione sono disponibili all'indirizzo NodeClasses.

Escludi i tipi di istanze che non si adattano al tuo carico di lavoro

Valuta la possibilità di escludere tipi di istanze specifici con la node.kubernetes.io/instance-type chiave se non sono richiesti dai carichi di lavoro in esecuzione nel cluster.

L'esempio seguente mostra come evitare il provisioning di istanze Graviton di grandi dimensioni.

- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
  - m6g.16xlarge
  - m6gd.16xlarge
  - r6g.16xlarge
  - r6gd.16xlarge
  - c6g.16xlarge

Abilita la gestione delle interruzioni quando usi Spot

Karpenter supporta la gestione nativa delle interruzioni ed è in grado di gestire eventi di interruzione involontaria come interruzioni delle istanze Spot, eventi di manutenzione programmata, eventi di terminazione/arresto delle istanze che potrebbero interrompere i carichi di lavoro. Quando Karpenter rileva tali eventi per i nodi, contamina, prosciuga e chiude automaticamente i nodi interessati in anticipo per avviare una corretta pulizia dei carichi di lavoro prima dell'interruzione. In caso di interruzioni Spot con un preavviso di 2 minuti, Karpenter avvia rapidamente un nuovo nodo in modo che i pod possano essere spostati prima che l'istanza venga recuperata. Per abilitare la gestione delle interruzioni, configurate l'--interruption-queueCLIargomento con il nome della coda predisposta a tale scopo. SQS Non è consigliabile utilizzare la gestione delle interruzioni di Karpenter insieme a Node Termination Handler, come spiegato qui.

I pod che richiedono un checkpoint o altre forme di drenaggio graduale, che richiedono 2 minuti prima dello spegnimento, dovrebbero consentire a Karpenter di gestire le interruzioni all'interno dei propri cluster.

Cluster EKS privato Amazon senza accesso a Internet in uscita

Quando esegui il provisioning di un EKS cluster in un VPC ambiente senza accesso a Internet, devi assicurarti di aver configurato l'ambiente in base ai requisiti del cluster privato indicati nella EKS documentazione. Inoltre, devi assicurarti di aver creato un endpoint STS VPC regionale nel tuo. VPC In caso contrario, verranno visualizzati errori simili a quelli visualizzati di seguito.

{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts.<region>.amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}

Queste modifiche sono necessarie in un cluster privato perché il controller Karpenter utilizza IAM Roles for Service Accounts ()IRSA. I pod configurati con IRSA acquisiscono le credenziali chiamando il AWS Security Token Service (). AWS STS API Se non è disponibile un accesso a Internet in uscita, devi creare e utilizzare un AWSSTSVPCendpoint nel tuo. VPC

I cluster privati richiedono inoltre la creazione di un VPC endpoint per. SSM Quando Karpenter tenta di effettuare il provisioning di un nuovo nodo, interroga le configurazioni del modello Launch e un parametro. SSM Se non avete un SSM VPC endpoint nel vostro computerVPC, ciò causerà il seguente errore:

{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm.<region>.amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}

Non esiste un VPCendpoint per la richiesta del listino prezzi. API Di conseguenza, i dati sui prezzi diventeranno obsoleti nel tempo. Karpenter aggira questo problema includendo i dati sui prezzi su richiesta nel suo file binario, ma aggiorna tali dati solo quando Karpenter viene aggiornato. Le richieste non riuscite di dati sui prezzi genereranno i seguenti messaggi di errore:

{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}

Fai riferimento a questa documentazione per utilizzare Karpenter in un EKS cluster completamente privato e per sapere quali VPC endpoint creare.

Creando NodePools

Le seguenti best practice riguardano argomenti relativi alla creazione NodePools.

Creane più NodePools quando...

Quando team diversi condividono un cluster e devono eseguire i propri carichi di lavoro su nodi di lavoro diversi o hanno requisiti di sistema operativo o tipo di istanza diversi, creane diversi NodePools. Ad esempio, un team potrebbe voler usare Bottlerocket, mentre un altro potrebbe voler usare Amazon Linux. Allo stesso modo, un team potrebbe avere accesso a GPU hardware costoso che non sarebbe necessario a un altro team. L'utilizzo di più risorse NodePools assicura che le risorse più appropriate siano disponibili per ogni team.

Creazioni NodePools che si escludano a vicenda o ponderate

Si consiglia di creare creazioni NodePools che si escludano a vicenda o ponderate per fornire un comportamento di pianificazione coerente. Se non lo sono e ne NodePools vengono abbinate più di una, Karpenter sceglierà a caso quali usare, generando risultati inaspettati. Di seguito sono riportati alcuni esempi utili per la creazione di più elementi: NodePools

Creare un oggetto NodePool con GPU e consentire l'esecuzione solo di carichi di lavoro speciali su questi (costosi) nodi:

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m0s
    consolidationPolicy: WhenEmpty
    expireAfter: Never
  template:
    metadata: {}
    spec:
      nodeClassRef:
        name: default
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - p3.8xlarge
        - p3.16xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      taints:
      - effect: NoSchedule
        key: nvidia.com/gpu
        value: "true"

Distribuzione con tolleranza per la contaminazione:

# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-gpu
spec:
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"

Per una distribuzione generale per un altro team, le NodePool specifiche potrebbero includere. nodeAffinity Un Deployment potrebbe quindi essere utilizzato nodeSelectorTerms per abbinarebilling-team.

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: generalcompute
spec:
  disruption:
    expireAfter: Never
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        name: default
      requirements:
      - key: node.kubernetes.io/instance-type
        operator: In
        values:
        - m5.large
        - m5.xlarge
        - m5.2xlarge
        - c5.large
        - c5.xlarge
        - c5a.large
        - c5a.xlarge
        - r5.large
        - r5.xlarge
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand

Distribuzione utilizzandonodeAffinity:

# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
  name: workload-my-team
spec:
  replicas: 200
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                - key: "billing-team"
                  operator: "In"
                  values: ["my-team"]

Usa timers (TTL) per eliminare automaticamente i nodi dal cluster

È possibile utilizzare i timer sui nodi assegnati per impostare quando eliminare i nodi privi di pod per il carico di lavoro o che hanno raggiunto una scadenza. La scadenza dei nodi può essere utilizzata come mezzo di aggiornamento, in modo che i nodi vengano ritirati e sostituiti con versioni aggiornate. Vedi Scadenza nella documentazione di Karpenter per informazioni sull'utilizzo per configurare la scadenza dei nodi. spec.disruption.expireAfter

Evita di limitare eccessivamente i tipi di istanze che Karpenter può fornire, specialmente quando utilizzi Spot

Quando utilizza Spot, Karpenter utilizza la strategia di allocazione Price Capacity Optimized per il provisioning delle istanze. EC2 Questa strategia prevede di effettuare EC2 il provisioning delle istanze provenienti dai pool più profondi per il numero di istanze che si stanno avviando e che presentano il minor rischio di interruzione. EC2Fleet richiede quindi le istanze Spot dal prezzo più basso di questi pool. Più tipi di istanze consenti a Karpenter di utilizzare, meglio EC2 è l'ottimizzazione del runtime dell'istanza Spot. Per impostazione predefinita, Karpenter utilizzerà tutte le EC2 offerte di Instance Types nella regione e nelle zone di disponibilità in cui è distribuito il cluster. Karpenter sceglie in modo intelligente dal set di tutti i tipi di istanze in base ai pod in sospeso per assicurarsi che i pod siano programmati su istanze di dimensioni e equipaggiate in modo appropriato. Ad esempio, se il tuo pod non richiede un, Karpenter non programmerà il tuo pod su un GPU tipo di istanza che supporta a. EC2 GPU Se non sei sicuro dei tipi di istanze da utilizzare, puoi eseguire Amazon ec2-instance-selector per generare un elenco di tipi di istanze che soddisfano i tuoi requisiti di calcolo. Ad esempio, CLI prende memory vCPU, architecture e region come parametri di input e fornisce un elenco di istanze che soddisfano tali vincoli. EC2

$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium

Non dovreste imporre troppi vincoli a Karpenter quando utilizzate le istanze Spot, perché così facendo potreste influire sulla disponibilità delle vostre applicazioni. Supponiamo, ad esempio, che tutte le istanze di un particolare tipo vengano recuperate e che non siano disponibili alternative adeguate per sostituirle. I pod rimarranno in sospeso fino a quando non verrà ripristinata la capacità spot per i tipi di istanze configurati. È possibile ridurre il rischio di errori di capacità insufficiente distribuendo le istanze su diverse zone di disponibilità, poiché i pool spot sono diversi tra loro. AZs Detto questo, la best practice generale consiste nel consentire a Karpenter di utilizzare una serie diversificata di tipi di istanze quando utilizza Spot.

Scheduling Pods

Le seguenti best practice riguardano la distribuzione dei pod in un cluster utilizzando Karpenter per il provisioning dei nodi.

Segui le migliori pratiche EKS per un'elevata disponibilità

Se devi eseguire applicazioni ad alta disponibilità, segui le raccomandazioni generali sulle EKS migliori pratiche. Consultate la documentazione Topology Spread in Karpenter per i dettagli su come distribuire i pod tra nodi e zone. Usa Disruption Budgets per impostare il numero minimo di pod disponibili che devono essere mantenuti, in caso di tentativi di rimuovere o eliminare i pod.

Usa vincoli a più livelli per limitare le funzionalità di elaborazione disponibili dal tuo provider di servizi cloud

Il modello di vincoli a più livelli di Karpenter ti consente di creare un insieme complesso di vincoli di implementazione NodePool e pod per ottenere le migliori corrispondenze possibili per la pianificazione dei pod. Di seguito sono riportati alcuni esempi di vincoli che una specifica del pod può richiedere:

Crea allarmi di fatturazione per monitorare la spesa di elaborazione

Quando configuri il cluster per la scalabilità automatica, devi creare allarmi di fatturazione per avvisarti quando la spesa supera una soglia e aggiungere limiti di risorse alla configurazione di Karpenter. L'impostazione dei limiti delle risorse con Karpenter è simile all'impostazione della capacità massima di un gruppo con AWS scalabilità automatica in quanto rappresenta la quantità massima di risorse di calcolo che possono essere istanziate da un Karpenter. NodePool

Lo snippet riportato di seguito indica a Karpenter di fornire solo un massimo di 1000 CPU core e 1000 Gi di memoria. Karpenter smetterà di aggiungere capacità solo quando il limite viene raggiunto o superato. Quando viene superato un limite, il controller Karpenter memory resource usage of 1001 exceeds limit of 1000 scriverà un messaggio dall'aspetto simile nei log del controller. Se state indirizzando i log dei container verso i CloudWatch log, potete creare un filtro metrico per cercare modelli o termini specifici nei log e quindi creare un CloudWatchallarme per avvisarvi quando la soglia delle metriche configurate viene superata.

Per ulteriori informazioni sull'uso dei limiti con Karpenter, consulta Impostazione dei limiti delle risorse nella documentazione di Karpenter.

spec:
  limits:
    cpu: 1000
    memory: 1000Gi

Se non utilizzi limiti o vincoli i tipi di istanze che Karpenter può fornire, Karpenter continuerà ad aggiungere capacità di calcolo al cluster in base alle esigenze. La configurazione di Karpenter in questo modo consente al cluster di scalare liberamente, ma può anche avere implicazioni significative in termini di costi. È per questo motivo che consigliamo di configurare gli allarmi di fatturazione. Gli allarmi di fatturazione ti consentono di essere avvisato e avvisato in modo proattivo quando gli addebiti stimati calcolati sul/i tuo/i account superano una soglia definita. Per ulteriori informazioni, consulta Configurazione di un allarme di CloudWatch fatturazione Amazon per monitorare in modo proattivo gli addebiti stimati.

Potresti anche voler abilitare Cost Anomaly Detection, una funzionalità di gestione dei AWS costi che utilizza l'apprendimento automatico per monitorare continuamente costi e utilizzo al fine di rilevare spese insolite. Ulteriori informazioni sono disponibili nella guida introduttiva a AWS Cost Anomaly Detection. Se sei arrivato al punto di creare un budget in AWS Budgets, puoi anche configurare un'azione per avvisarti quando viene superata una soglia specifica. Con Budget Actions puoi inviare un'email, pubblicare un messaggio SNS su un argomento o inviare un messaggio a un chatbot come Slack. Per ulteriori informazioni, consulta Configurazione delle azioni dei budget AWS.

Usa l'do-not-disrupt annotazione karpenter.sh/ per impedire a Karpenter di eseguire il deprovisioning di un nodo

Se state eseguendo un'applicazione critica su un nodo fornito da Karpenter, ad esempio un processo batch a esecuzione prolungata o un'applicazione stateful, e il nodo è scaduto, l'applicazione verrà interrotta quando l'istanza viene terminata. TTL Aggiungendo un'karpenter.sh/do-not-disruptannotazione al pod, si ordina a Karpenter di conservare il nodo fino alla chiusura del Pod o alla rimozione dell'annotazione. karpenter.sh/do-not-disrupt Per ulteriori informazioni, consultate la documentazione di Distruption.

Se gli unici pod non daemonset rimasti su un nodo sono quelli associati ai job, Karpenter è in grado di indirizzare e terminare quei nodi a condizione che lo stato del processo sia riuscito o non riuscito.

Configura requests=limits per tutte le non risorse quando usi il consolidamento CPU

Il consolidamento e la pianificazione in generale funzionano confrontando le richieste di risorse dei pod con la quantità di risorse allocabili su un nodo. I limiti delle risorse non vengono considerati. Ad esempio, i pod con un limite di memoria superiore alla richiesta di memoria possono superare la richiesta. Se più pod sullo stesso nodo scoppiano contemporaneamente, alcuni pod possono essere chiusi a causa di una condizione di out of memory (). OOM Il consolidamento può aumentare la probabilità che ciò si verifichi, in quanto consiste nel comprimere i pod nei nodi solo tenendo conto delle loro richieste.

Viene utilizzato LimitRanges per configurare le impostazioni predefinite per le richieste e i limiti delle risorse

Poiché Kubernetes non imposta richieste o limiti predefiniti, il consumo di risorse provenienti dall'host sottostante e la memoria da parte di un container non sono associatiCPU. Lo scheduler Kubernetes esamina le richieste totali di un pod (il più alto tra le richieste totali dai contenitori del pod o il totale delle risorse dai contenitori Init del pod) per determinare su quale nodo di lavoro pianificare il pod. Analogamente, Karpenter prende in considerazione le richieste di un pod per determinare il tipo di istanza da fornire. È possibile utilizzare un intervallo limite per applicare un valore predefinito ragionevole per un namespace, nel caso in cui le richieste di risorse non siano specificate da alcuni pod.

Vedi Configurazione delle richieste e dei limiti di memoria predefiniti per un namespace

Applica richieste di risorse accurate a tutti i carichi di lavoro

Karpenter è in grado di avviare i nodi che meglio si adattano ai tuoi carichi di lavoro quando le informazioni sui requisiti dei tuoi carichi di lavoro sono accurate. Ciò è particolarmente importante se si utilizza la funzionalità di consolidamento di Karpenter.

Vedi Configurazione e dimensione delle richieste/limiti di risorse per tutti i carichi di lavoro

DNSRaccomandazioni principali

Aggiorna la configurazione di Core DNS per mantenere l'affidabilità

Quando si implementano i Core DNS pod su nodi gestiti da Karpenter, data la natura dinamica di Karpenter nel terminare/creare rapidamente nuovi nodi per soddisfare la domanda, è consigliabile attenersi alle seguenti best practice:

Durata del core lameduck DNS

Sonda di prontezza centrale DNS

Ciò garantirà che DNS le richieste non vengano indirizzate a un Core DNS Pod che non è ancora pronto o è stato terminato.

Progetti Karpenter

Poiché Karpenter adotta un approccio incentrato sulle applicazioni per fornire capacità di calcolo al piano dati di Kubernetes, ci sono scenari di carico di lavoro comuni che potresti chiederti come configurarli correttamente. Karpenter Blueprints è un repository che include un elenco di scenari di carico di lavoro comuni che seguono le migliori pratiche descritte qui. Avrai a disposizione tutte le risorse necessarie anche per creare un EKS cluster con Karpenter configurato e testare ciascuno dei blueprint inclusi nel repository. Puoi combinare diversi progetti per creare finalmente quello che ti serve per i tuoi carichi di lavoro.

Risorse aggiuntive

📝 Modifica questa pagina su GitHub