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 progettato per migliorare la gestione del ciclo di vita dei nodi all'interno dei cluster Kubernetes. Automatizza il provisioning e il deprovisioning dei nodi in base alle esigenze di pianificazione specifiche dei pod, consentendo una scalabilità efficiente e l'ottimizzazione dei costi. Le sue funzioni principali sono:

Con Karpenter, è possibile definire NodePools vincoli sul provisioning dei nodi, ad esempio limiti, etichette, requisiti (tipi di istanza, zone, ecc.) e limiti sul totale delle risorse assegnate. Quando si distribuiscono carichi di lavoro, è possibile specificare vari vincoli di pianificazione nelle specifiche del pod, come risorse, selettori di nodi requests/limits, affinità, tolleranze e vincoli di diffusione della topologia. node/pod Karpenter fornirà quindi nodi della giusta dimensione in base a queste specifiche.

Motivi per utilizzare Karpenter

Prima del lancio di Karpenter, gli utenti di Kubernetes si affidavano principalmente ai gruppi Amazon EC2 Auto Scaling e al Kubernetes Cluster Autoscaler (CAS) per regolare dinamicamente la capacità di calcolo dei loro cluster. Con Karpenter, non è necessario creare dozzine di gruppi di nodi per ottenere la flessibilità e la diversità offerte da Karpenter. A differenza di CAS, Karpenter non è così strettamente legato alle versioni di Kubernetes e non richiede di passare dalle API AWS a Kubernetes.

Karpenter consolida le responsabilità di orchestrazione delle istanze in 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, visita il sito karpenter.sh. https://karpenter.sh/

Raccomandazioni

Le migliori pratiche sono suddivise in sezioni su Karpenter stesso e sulla pianificazione dei pod NodePools.

Le migliori pratiche di Karpenter

Le seguenti best practice riguardano argomenti relativi a Karpenter stesso.

Blocca le AMI nei cluster di produzione

Ti consigliamo vivamente di aggiungere Amazon Machine Images (AMI) note utilizzate da Karpenter per i cluster di produzione. L'utilizzo amiSelector con un alias impostato su@latest, o l'utilizzo di un altro metodo che comporti la distribuzione di AMI non testate non appena vengono rilasciate, comporta il rischio di guasti del carico di lavoro e tempi di inattività nei cluster di produzione. Di conseguenza, consigliamo vivamente di aggiungere le versioni funzionanti testate delle AMI ai cluster di produzione mentre testate le versioni più recenti in cluster non di produzione. Ad esempio, puoi impostare un alias nel tuo come segue: NodeClass

amiSelectorTerms
  - alias: al2023@v20240807

Per informazioni sulla gestione e il blocco delle AMI in Karpenter, vedi Gestione delle AMI nella documentazione di Karpenter.

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

Karpenter avvicina la gestione della scalabilità alle API native di Kubernetes rispetto agli Autoscaling Groups (ASG) e ai Managed Node Groups (MNG). https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html ASG e MNG sono AWS-native astrazioni in cui la scalabilità viene attivata in base a metriche a livello AWS, come il carico della CPU EC2. Cluster Autoscaler collega le astrazioni di Kubernetes alle astrazioni AWS, ma per questo perde una certa flessibilità, ad esempio la pianificazione per una zona di disponibilità specifica.

Karpenter rimuove un livello di astrazione di AWS per portare parte della flessibilità direttamente in Kubernetes. Karpenter è ideale per i cluster con carichi di lavoro che incontrano periodi di domanda elevata e intensa o hanno requisiti di elaborazione diversi. MNG e ASG 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 diagramma Helm. https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#4-install-karpenter Il diagramma Helm installa il controller Karpenter e un pod webhook come Deployment che deve essere eseguito prima che il controller possa essere utilizzato per scalare il cluster. Consigliamo almeno 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 namespace verranno eseguiti su EKS Fargate. Non eseguire Karpenter su un nodo gestito da Karpenter.

Karpenter non supporta modelli di avvio personalizzati

Non è disponibile alcun supporto per modelli di avvio personalizzati con le API v1. È possibile utilizzare dati utente personalizzati specificando and/or direttamente le AMI personalizzate in. EC2NodeClass Ulteriori informazioni su come eseguire questa operazione sono disponibili all'indirizzo. NodeClasses

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

Valuta la possibilità di escludere tipi di istanze specifici dalla 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 istanza che potrebbero interrompere i carichi di lavoro. termination/stopping Quando Karpenter rileva tali eventi per i nodi, contamina, prosciuga e chiude automaticamente i nodi interessati in anticipo per iniziare una corretta pulizia dei carichi di lavoro prima delle interruzioni. Per le 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'argomento --interruption-queue CLI con il nome della coda SQS predisposta a tale scopo. Non è consigliabile utilizzare la gestione delle interruzioni di Karpenter insieme a Node Termination Handler, come spiegato qui. https://karpenter.sh/docs/faq/#interruption-handling

I pod che richiedono un checkpoint o altre forme di drenaggio graduale, che richiedono 2 minuti prima dello spegnimento, dovrebbero consentire a Karpenter la gestione delle interruzioni nei propri cluster.

Cluster privato Amazon EKS senza accesso a Internet in uscita

Quando esegui il provisioning di un cluster EKS in un VPC senza accesso a Internet, devi assicurarti di aver configurato il tuo ambiente in conformità ai requisiti del cluster privato indicati nella documentazione EKS. Inoltre, devi assicurarti di aver creato un endpoint regionale STS VPC nel tuo VPC. In caso contrario, vedrai 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é Karpenter Controller utilizza IAM Roles for Service Accounts (IRSA). I pod configurati con IRSA acquisiscono le credenziali chiamando l'API AWS Security Token Service (AWS STS). Se non c'è accesso a Internet in uscita, devi creare e utilizzare un endpoint AWS STS VPC nel tuo VPC.

I cluster privati richiedono anche la creazione di un endpoint VPC per SSM. Quando Karpenter tenta di eseguire il provisioning di un nuovo nodo, interroga le configurazioni del modello Launch e un parametro SSM. Se non hai un endpoint SSM VPC nel tuo VPC, 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 endpoint VPC per l'API Price List Query. https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-pelong.html Di conseguenza, i dati sui prezzi diventeranno obsoleti nel tempo. Karpenter risolve questo problema includendo i dati sui prezzi su richiesta nel suo formato binario, ma li aggiorna 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 cluster EKS completamente privato e per sapere quali endpoint VPC 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 più NodePools. Ad esempio, un team potrebbe voler utilizzare Bottlerocket, mentre un altro potrebbe voler utilizzare Amazon Linux. Allo stesso modo, un team potrebbe avere accesso a costosi hardware GPU che non sarebbero necessari 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 escludono a vicenda o sono ponderate

Si consiglia di creare NodePools che si escludano a vicenda o ponderate per fornire un comportamento di pianificazione coerente. Se non lo sono e più NodePools corrispondono, Karpenter sceglierà in modo casuale quale utilizzare, provocando risultati inaspettati. Di seguito sono riportati alcuni esempi utili per la creazione di più NodePools elementi:

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

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    metadata: {}
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      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"

Implementazione 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. Una distribuzione potrebbe quindi utilizzare il nodo corrispondente. SelectorTerms billing-team

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: generalcompute
spec:
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      expireAfter: Never
      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 tramite NodeAffinity:

# 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 i timer (TTL) per eliminare automaticamente i nodi dal cluster

È possibile utilizzare i timer sui nodi su cui è stato effettuato il provisioning per impostare quando eliminare i nodi privi di workload pod o che hanno raggiunto una data di scadenza. La scadenza dei nodi può essere utilizzata come metodo 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 del nodo. spec.template.spec

Evita di limitare eccessivamente i tipi di istanza di cui Karpenter può eseguire il provisioning, specialmente quando utilizzi Spot

Quando utilizza Spot, Karpenter utilizza la strategia di allocazione Price Capacity Optimized per il provisioning delle istanze EC2. Questa strategia indica a EC2 di effettuare il provisioning delle istanze dai pool più profondi in base al numero di istanze che stai avviando e che presentano il minor rischio di interruzione. EC2 Fleet richiede quindi le istanze Spot dal prezzo più basso di questi pool. Più tipi di istanze consenti a Karpenter di utilizzare, migliore sarà l'ottimizzazione del runtime dell'istanza spot da parte di EC2. Per impostazione predefinita, Karpenter utilizzerà tutti i tipi di istanza offerti da EC2 nella regione e nelle zone di disponibilità in cui è distribuito il cluster. Karpenter sceglie in modo intelligente dall'insieme di tutti i tipi di istanze in base ai pod in sospeso per assicurarsi che i pod siano pianificati su istanze di dimensioni e equipaggiate in modo appropriato. Ad esempio, se il pod non richiede una GPU, Karpenter non programmerà il pod su un tipo di istanza EC2 che supporti una 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, la CLI accetta memoria, vCPU, architettura e regione come parametri di input e fornisce un elenco di istanze EC2 che soddisfano tali vincoli.

$ 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 usate 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 non siano disponibili alternative adeguate per sostituirle. I tuoi pod rimarranno in sospeso fino al ripristino della capacità spot per i tipi di istanza configurati. Puoi ridurre il rischio di errori di capacità insufficiente distribuendo le istanze in diverse zone di disponibilità, poiché i pool spot sono diversi tra gli AZ. Detto questo, la best practice generale è consentire a Karpenter di utilizzare un set diversificato di tipi di istanze quando si utilizza Spot.

Pianificazione dei pod

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

Segui le best practice di EKS per l'alta disponibilità

Se hai bisogno di eseguire applicazioni ad alta disponibilità, segui le raccomandazioni generali sulle best practice di EKS. Consulta la documentazione di Topology Spread in Karpenter per 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, nel caso in cui ci siano tentativi di sfrattare o eliminare i pod.

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

Il modello di vincoli a più livelli di Karpenter consente di creare un set complesso di vincoli di distribuzione NodePool e pod per ottenere le migliori corrispondenze possibili per la pianificazione dei pod. Alcuni esempi di vincoli che una specifica del pod può richiedere sono i seguenti:

Crea allarmi di fatturazione per monitorare la tua spesa informatica

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

Lo snippet seguente indica a Karpenter di fornire solo un massimo di 1000 core CPU e 1000 Gi di memoria. Karpenter interromperà l'aggiunta di capacità solo quando il limite sarà raggiunto o superato. Quando viene superato un limite, il controller Karpenter memory resource usage of 1001 exceeds limit of 1000 scriverà un messaggio simile nei log del controller. Se stai indirizzando i log del contenitore ai CloudWatch log, puoi creare un filtro metrico per cercare modelli o termini specifici nei tuoi log e quindi creare un CloudWatch allarme per avvisarti quando la soglia delle metriche configurate viene superata.

Per ulteriori informazioni sull'utilizzo 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 istanza di cui Karpenter può eseguire il provisioning, Karpenter continuerà ad aggiungere capacità di calcolo al cluster in base alle necessità. 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 nei tuoi 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 AWS Cost Management che utilizza l'apprendimento automatico per monitorare continuamente i costi e l'utilizzo per rilevare spese insolite. Ulteriori informazioni sono disponibili nella guida introduttiva di AWS Cost Anomaly Detection. Se sei arrivato al punto di creare un budget in AWS Budgets, puoi anche configurare un'azione per notificarti quando viene superata una soglia specifica. Con le azioni relative al budget puoi inviare un'email, pubblicare un messaggio su un argomento SNS o inviare un messaggio a un chatbot come Slack. Per ulteriori informazioni, consulta Configurazione delle azioni di AWS Budgets.

Usa il karpenter. sh/do-not-disrupt annotazione per impedire a Karpenter di deprovisionare un nodo

Se si esegue un'applicazione critica su un Karpenter-provisioned nodo, ad esempio un processo batch di lunga durata o un'applicazione stateful, e il TTL del nodo è scaduto, l'applicazione verrà interrotta quando l'istanza viene terminata. Aggiungendo un'karpenter.sh/do-not-disruptannotazione al pod, si indica a Karpenter di conservare il nodo fino alla chiusura del Pod o alla rimozione dell'annotazione. karpenter.sh/do-not-disrupt Per ulteriori informazioni, consulta 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 purché lo stato del job sia riuscito o fallito.

Configura requests=limits per tutte le risorse non basate sulla CPU quando si utilizza il consolidamento

Consolidamento e pianificazione in generale del lavoro 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 si esauriscono contemporaneamente, ciò può causare la chiusura di alcuni pod a causa di una condizione di memoria insufficiente (OOM). Il consolidamento può aumentare la probabilità che ciò si verifichi, in quanto consente di impacchettare i pod nei nodi solo considerando le loro richieste.

LimitRanges Da utilizzare per configurare i valori predefiniti per le richieste e i limiti delle risorse

Poiché Kubernetes non imposta richieste o limiti predefiniti, il consumo di risorse da parte di un container dall'host, dalla CPU e dalla memoria sottostanti non è vincolato. Lo scheduler Kubernetes esamina il totale delle richieste di un pod (il valore 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 considera le richieste di un pod per determinare il tipo di istanza fornito. È 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 carichi di lavoro quando le informazioni sui requisiti dei carichi di lavoro sono accurate. Ciò è particolarmente importante se si utilizza la funzionalità di consolidamento di Karpenter.

Vedi Configurazione e dimensionamento delle risorse Requests/Limits per tutti i carichi di lavoro

Consigli CoreDNS

Aggiorna la configurazione di CoreDNS per mantenere l'affidabilità

Quando si implementano i pod CoreDNS sui nodi gestiti da Karpenter, data la natura dinamica di Karpenter nei nodi rapidamente terminating/creating nuovi per allinearsi alla domanda, è consigliabile attenersi alle seguenti best practice:

Durata del lameduck CoreDNS

Sonda di prontezza CoreDNS

Ciò garantirà che le richieste DNS non vengano indirizzate a un CoreDNS 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 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 seguendo le best practice descritte qui. Avrai a disposizione tutte le risorse necessarie anche per creare un cluster EKS con Karpenter configurato e testare ciascuno dei blueprint inclusi nel repository. Puoi combinare diversi blueprint per creare finalmente quello di cui hai bisogno per i tuoi carichi di lavoro.

Risorse aggiuntive