L'Helm chart di KEDA è il metodo ufficiale per installare KEDA, il Kubernetes Event-Driven Autoscaler, nel tuo cluster. Un singolo helm install distribuisce tutto ciò di cui KEDA ha bisogno per scalare i tuoi workloads in base agli eventi: l'operator, il metrics server, gli admission webhook e le custom resource con cui definisci le regole di scaling.
Questa guida analizza il chart in profondità. Scoprirai cosa distribuisce, come installarlo e verificarlo, i parametri chiave di values.yaml, come eseguire KEDA in alta disponibilità, come effettuarne l'hardening e monitorarlo, come gestirlo tramite GitOps e come aggiornarlo o disinstallarlo senza lasciare risorse orfane.
Che cos'è l'Helm chart di KEDA?
KEDA scala i tuoi pod in base agli eventi, come la lunghezza di una coda, il lag su un topic Kafka, il numero di richieste HTTP o una pianificazione cron. L'Horizontal Pod Autoscaler (HPA) integrato può scalare solo in base a CPU e memoria. KEDA aggiunge tutte queste sorgenti di eventi e può anche ridurre un workload fino a zero pod quando non c'è nulla da fare.
KEDA non sostituisce l'HPA. Legge la sorgente di eventi e crea un HPA che esegue lo scaling vero e proprio, alimentandolo con metriche esterne. Descrivi cosa scalare in una custom resource chiamata ScaledObject.
L'Helm chart installa KEDA e i suoi componenti di supporto in un unico passaggio, ed è per questo che è il metodo di deployment consigliato.
Cosa distribuisce il chart nel cluster?
Quando installi l'Helm chart di KEDA nel cluster, vengono installati i seguenti componenti:
a. KEDA operator: il controller principale di KEDA. Osserva le risorse ScaledObject e ScaledJob e gestisce l'HPA che si occupa dello scaling. È il cuore di KEDA.
b. Metrics API server: rende le metriche basate su eventi disponibili a Kubernetes tramite l'API external.metrics.k8s.io. Ciò consente all'HPA di scalare in base a valori come la lunghezza di una coda, invece che solo a CPU o memoria.
c. Admission webhook: convalidano le risorse KEDA al momento della creazione. Intercettano subito gli errori di configurazione, ad esempio due risorse ScaledObject che tentano di scalare lo stesso workload.
Infine, il chart installa le CRD, che aggiungono i tipi di risorsa KEDA con cui lavori: ScaledObject, ScaledJob, TriggerAuthentication e ClusterTriggerAuthentication. Installa inoltre le autorizzazioni RBAC necessarie a questi componenti.
Prerequisiti e compatibilità delle versioni
Prima di installare KEDA, verifica i seguenti prerequisiti e requisiti di versione:
a. KEDA 2.20 richiede Kubernetes 1.30 o versioni successive, quindi controlla prima la versione del cluster con kubectl version. Serve anche Helm 3, perché il chart di KEDA supporta solo Helm 3.
b. Assicurati che il cluster disponga di risorse sufficienti per eseguire i componenti di KEDA. Il chart scarica inoltre le immagini dei container da ghcr.io, quindi i nodi devono avere accesso di rete al registry delle immagini.
c. Il metrics server di KEDA crea anche un'APIService a livello di cluster, quindi eventuali network policy nel namespace keda devono consentire il traffico necessario a KEDA. Se il cluster è isolato o air-gapped, assicurati che l'accesso di rete e le immagini richieste siano disponibili prima dell'installazione.
Installare l'Helm chart di KEDA
Per prima cosa, aggiungi il repository ufficiale di KEDA e aggiornalo:
helm repo add kedacore https://kedacore.github.io/chartshelm repo updateInstalla in un namespace dedicato e fissa la versione del chart invece di prendere l'ultima disponibile:
helm install keda kedacore/keda \ --namespace keda \ --create-namespace \ --version <chart-version>Fissare la versione è importante perché la versione del chart corrisponde a una specifica versione dell'app KEDA, e vuoi usare la versione che hai testato. Puoi vedere le versioni disponibili con helm search repo kedacore/keda --versions.
Dopo l'installazione, verifica i tre elementi che devono risultare integri. Controlla che i pod siano in esecuzione:
kubectl get pods -n kedaPoi conferma che le CRD siano presenti e che l'APIService delle metriche esterne sia registrata e disponibile:
kubectl get crd | grep keda.shkubectl get apiservice v1beta1.external.metrics.k8s.ioSe i pod sono in esecuzione e l'APIService mostra True alla voce Available, KEDA è installato correttamente.
Altri modi per distribuire KEDA
L'Helm chart è il metodo consigliato per installare KEDA, ma non è l'unica opzione. La scelta giusta dipende da come gestisci il cluster. Ecco le altre modalità:
a. OpenShift: puoi installare KEDA tramite OperatorHub e l'Operator Lifecycle Manager (OLM). OLM gestisce l'operator di KEDA e i suoi aggiornamenti al posto di Helm.
b. Manifesti YAML raw: se non puoi usare Helm, KEDA fornisce per ogni release dei manifesti YAML applicabili con kubectl apply. Con questo approccio, gestisci tu stesso le CRD e gli aggiornamenti.
c. MicroK8s: KEDA è disponibile come add-on integrato che puoi abilitare con un solo comando.
Qualunque metodo tu scelga, i componenti principali di KEDA e le CRD sono gli stessi. La differenza principale è il modo in cui KEDA viene pacchettizzato e gestito.
Parametri chiave in values.yaml
Ecco i parametri principali da conoscere in values.yaml:
a. Registry, repository e tag delle immagini: ogni componente di KEDA (image.keda, image.metricsApiServer e image.webhooks) ha il proprio registry, repository e tag. Se lasci il tag vuoto, il chart usa la versione dell'app KEDA. In ambienti con restrizioni, puoi impostare questi valori per usare il tuo registry o un mirror.
b. crds.install e ownership delle CRD: per impostazione predefinita, il chart installa e gestisce le CRD. Se un altro strumento, ad esempio uno strumento GitOps, le gestisce già, imposta crds.install: false in modo che i due sistemi non cerchino di gestire le stesse CRD.
c. watchNamespace e ambito del namespace: per impostazione predefinita, KEDA osserva tutti i namespace. Impostando watchNamespace limiti KEDA a un namespace specifico. Può essere utile in un cluster condiviso quando vuoi limitare l'ambito in cui KEDA opera.
d. Requests e limits delle risorse: puoi impostare le risorse separatamente per operator, metrics server e webhook usando resources.operator, resources.metricServer e resources.webhooks. Imposta requests e limits adeguati in modo che KEDA abbia risorse sufficienti per funzionare in modo affidabile anche quando il cluster è sotto pressione.
Configurare KEDA in alta disponibilità
In produzione non vuoi che KEDA smetta di funzionare quando un nodo si guasta. Esegui i suoi componenti con più repliche distribuendole su nodi diversi.
L'operator supporta più repliche tramite operator.replicaCount. Usa la leader election, quindi una sola istanza dell'operator è attiva alla volta, mentre le altre sono pronte a subentrare se necessario.
Anche il metrics API server può eseguire più repliche tramite metricsServer.replicaCount. Questo aiuta a mantenere disponibili le metriche esterne se una replica si guasta.
Dovresti inoltre usare la pod anti-affinity per distribuire le repliche su nodi diversi e un PodDisruptionBudget (PDB) per assicurarti che il drain di un nodo non elimini tutte le repliche contemporaneamente.
Un values.yaml di produzione può avere questo aspetto:
operator: replicaCount: 2metricsServer: replicaCount: 2podDisruptionBudget: operator: minAvailable: 1 metricServer: minAvailable: 1affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: kubernetes.io/hostname labelSelector: matchLabels: app: keda-operatorRegolare le impostazioni HTTP e TLS degli scaler
Molti scaler di KEDA si connettono a sistemi esterni via HTTP. In un ambiente con restrizioni potresti dover controllare il funzionamento di queste connessioni. KEDA offre impostazioni per configurare le connessioni HTTP, TLS e proxy:
a. Timeout HTTP: KEDA_HTTP_DEFAULT_TIMEOUT imposta il timeout predefinito per gli scaler che usano il client HTTP integrato di KEDA. Il valore è espresso in millisecondi. Alcuni scaler usano gli SDK dei rispettivi vendor, quindi per questi scaler l'impostazione non ha effetto.
b. Versione TLS minima: KEDA_HTTP_MIN_TLS_VERSION imposta la versione TLS minima per le connessioni HTTP in uscita di KEDA. KEDA_SERVICE_MIN_TLS_VERSION imposta la versione TLS minima per i servizi TLS di KEDA stesso, come il webhook e i servizi gRPC. Il valore predefinito è TLS 1.3.
c. Elenco dei cipher TLS: KEDA_HTTP_TLS_CIPHER_LIST consente di limitare i cipher TLS utilizzabili da KEDA. Tuttavia, questa impostazione non influisce su TLS 1.3, perché la libreria TLS di Go non permette di configurare i cipher per TLS 1.3.
d. Proxy HTTP e HTTPS: se KEDA deve connettersi a sistemi esterni tramite un proxy aziendale, configura le variabili d'ambiente standard HTTP_PROXY, HTTPS_PROXY e NO_PROXY sull'operator di KEDA.
Hardening dell'installazione
Ci sono due impostazioni che possono migliorare la sicurezza di KEDA in produzione: limitare l'accesso ai secret e gestire i certificati. Vediamole:
a. Limitare l'accesso ai secret: per impostazione predefinita, KEDA può leggere i secret in tutti i namespace che osserva. Le impostazioni permissions.operator consentono di limitare questo accesso, in modo che l'operator possa leggere i secret solo nel proprio namespace di release o solo secret specifici indicati per nome. Questo riduce ciò a cui un operator compromesso potrebbe accedere.
b. Gestire i certificati: KEDA genera i propri certificati self-signed, li archivia in un secret chiamato kedaorg-certs e li monta nei suoi componenti. KEDA ruota inoltre questi certificati automaticamente e aggiorna le risorse Kubernetes necessarie affinché risultino attendibili.
c. Se la tua organizzazione richiede certificati emessi da una certificate authority gestita, abilita certificates.certManager.enabled in modo che sia cert-manager, e non KEDA, a emettere e ruotare i certificati. Per la maggior parte delle installazioni, i certificati generati automaticamente sono sufficienti.
Distribuire il chart tramite GitOps
Se gestisci il cluster con Argo CD o Flux, puoi distribuire il chart di KEDA tramite GitOps. L'aspetto principale da gestire con attenzione sono le CRD.
Le CRD di KEDA sono di grandi dimensioni e un normale apply di Kubernetes può fallire perché l'annotazione generata diventa troppo grande. Per evitarlo, configura lo strumento GitOps in modo che sostituisca le CRD invece di eseguirne il merge. In Flux: imposta crds: CreateReplace nella HelmRelease; in Argo CD: usa Replace=true o il server-side apply per le CRD, così vengono applicate correttamente.
Se le CRD non sono configurate correttamente, l'installazione di KEDA gestita via GitOps può fallire.
Puoi anche usare helm template per generare dal chart normali file YAML di Kubernetes e committare quei file in Git, se il tuo workflow prevede la gestione di manifesti renderizzati invece di una release Helm attiva.
Qualunque approccio tu scelga, mantieni coerente la label app.kubernetes.io/managed-by, in modo che lo strumento GitOps e Helm non entrino in conflitto sulla ownership delle risorse.
Creare il primo ScaledObject dopo l'installazione
Con KEDA installato, uno ScaledObject ti consente di verificare che KEDA riesca effettivamente a scalare un workload. L'esempio seguente usa un trigger cron, quindi non richiede un sistema esterno. Aumenta le repliche di un Deployment durante una fascia oraria pianificata e le riduce al termine della pianificazione.
Per prima cosa, crea un Deployment da scalare, poi applica lo ScaledObject:
apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: nginx-cron namespace: defaultspec: scaleTargetRef: name: nginx pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 5 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 9 * * * end: 0 17 * * * desiredReplicas: "5"pollingInterval indica a KEDA con quale frequenza, in secondi, controllare il trigger. minReplicaCount: 0 abilita lo scale-to-zero. Al di fuori della fascia oraria 9-17, il Deployment può ridursi fino a zero pod. Durante la finestra pianificata, scala fino a cinque repliche.
Applica lo ScaledObject e controlla cosa ha creato KEDA:
kubectl get scaledobjectkubectl get hpaDovresti vedere un HPA chiamato keda-hpa-nginx-cron. KEDA crea e gestisce questo HPA per eseguire lo scaling vero e proprio. Questo conferma che KEDA è collegato al workload e che la configurazione dello scaling pianificato funziona.
Monitorare l'installazione di KEDA
Una volta che KEDA è in esecuzione, dovresti verificare che sia integro e funzioni come previsto.
KEDA espone metriche Prometheus sia per l'operator sia per il metrics server. Queste metriche mostrano l'attività degli scaler, gli errori e i valori riportati da KEDA.
Se usi il Prometheus Operator, il chart di KEDA può creare un ServiceMonitor per il metrics server e un PodMonitor per l'operator. Puoi abilitarli tramite le impostazioni prometheus in values.yaml, così Prometheus può raccogliere le metriche automaticamente.
Anche i log dell'operator sono utili quando uno specifico ScaledObject non funziona come previsto. Mostrano come lo scaler sta leggendo il trigger ed eventuali errori riscontrati.
Puoi visualizzare i log dell'operator con:
kubectl logs -n keda deploy/keda-operatorIl right-sizing dei workloads scalati da KEDA
KEDA è ottimo nello scalare il numero di pod in base alla domanda. Ma non decide quanta CPU e memoria ogni pod dovrebbe richiedere.
Aggiungere più repliche non corregge richieste di risorse errate. Se ogni pod richiede molta più CPU o memoria di quanta ne usi realmente, KEDA può moltiplicare quello spreco man mano che aggiunge repliche. Se ogni pod richiede troppo poco, le nuove repliche possono subire OOMKill o throttling della CPU all'aumentare del traffico.
È qui che gli strumenti di ottimizzazione delle risorse possono aiutare. PerfectScale monitora come i workloads usano effettivamente CPU e memoria e fornisce raccomandazioni automatizzate di right-sizing che puoi applicare manualmente o in modo automatico.
In combinazione con KEDA, ottieni entrambi i lati dell'autoscaling: KEDA regola il numero di pod in base alla domanda, mentre PerfectScale contribuisce a garantire che ogni pod abbia la giusta quantità di CPU e memoria. Questo può aiutare a prevenire l'over-provisioning mantenendo i workloads affidabili. Puoi provarlo subito o prenotare una sessione tecnica.
Altri strumenti come il Vertical Pod Autoscaler (VPA), che può regolare le richieste di risorse in base all'utilizzo, Goldilocks, che aiuta a visualizzare le raccomandazioni del VPA, e Karpenter si concentrano sulla scelta e sulla gestione dei nodi che eseguono i tuoi workloads.
Aggiornare e disinstallare il chart
Ci sono alcuni aspetti importanti da verificare quando si aggiorna o si disinstalla KEDA.
Per aggiornare KEDA, aggiorna prima il repository Helm e poi esegui l'upgrade a una versione fissata del chart:
helm repo updatehelm upgrade keda kedacore/keda --namespace keda --version <new-chart-version>L'aspetto da tenere d'occhio durante un upgrade sono le CRD. Poiché il chart le gestisce, un helm upgrade le aggiorna insieme a tutto il resto, ma le versioni minor di KEDA a volte modificano campi delle CRD o il comportamento degli scaler: leggi quindi le note di rilascio prima di aggiornare un cluster di produzione e verifica che la nuova versione di KEDA supporti ancora la tua versione di Kubernetes.
Anche la disinstallazione di KEDA richiede attenzione, perché la rimozione può lasciare risorse orfane.
Per prima cosa, elimina le risorse ScaledObject e ScaledJob:
kubectl delete scaledobject --all --all-namespaceskubectl delete scaledjob --all --all-namespacesPoi disinstalla la release Helm:
helm uninstall keda --namespace kedaEliminare prima le risorse ScaledObject e ScaledJob consente a KEDA di ripulire gli HPA che ha creato. Dà inoltre ai workloads scalati a zero la possibilità di tornare al normale numero di repliche prima che KEDA venga rimosso.
Se una risorsa si blocca durante l'eliminazione a causa di un finalizer, puoi rimuovere il finalizer con:
kubectl patch scaledobject <name> -p '{"metadata":{"finalizers":null}}' --type=mergeRisolvere i problemi comuni del chart
Ci sono due problemi comuni da verificare quando KEDA non scala come previsto:
a. L'API delle metriche esterne non è disponibile o la verifica TLS fallisce: se kubectl get apiservice v1beta1.external.metrics.k8s.io non mostra Available, l'HPA non può ottenere le metriche esterne e quindi i workloads non possono scalare in base a esse. Le cause comuni includono un metrics server non integro, una NetworkPolicy che blocca il traffico o un proxy che interferisce con la connessione tra l'API server di Kubernetes e il metrics server. Controlla prima il pod del metrics server. Se usi un proxy, assicurati che il cluster IP del metrics server sia incluso nella lista no_proxy dell'API server.
b. Uno ScaledObject viene creato ma le repliche non cambiano: inizia con kubectl describe scaledobject <name> e controllane stato ed eventi. Poi controlla i log dell'operator di KEDA. Le cause possono essere un trigger configurato male, un'autenticazione mancante per la sorgente di eventi o un HPA esistente che punta già allo stesso workload. L'HPA esistente può entrare in conflitto con l'HPA creato e gestito da KEDA.
Best practice per eseguire l'Helm chart di KEDA
Le seguenti pratiche possono aiutare a mantenere un'installazione di KEDA stabile e sicura:
a. Fissa la versione del chart e abbinala a una versione dell'app KEDA testata: non installare né passare semplicemente all'ultima versione disponibile. Fissa il chart, testa quella versione di KEDA e distribuiscila con attenzione, così sai sempre cosa è in esecuzione.
b. Mantieni KEDA in un namespace dedicato con una propria resource quota: un namespace dedicato tiene KEDA isolato e semplifica l'applicazione di ResourceQuota e NetworkPolicy specifiche per KEDA.
c. Imposta requests e limits espliciti su tutti e tre i componenti di KEDA: devi definire risorse adeguate per operator, metrics server e webhook, così KEDA stesso non subisce throttling o eviction quando il cluster è sotto pressione.
d. Usa TriggerAuthentication invece di inserire le credenziali direttamente nello ScaledObject: mantieni le credenziali fuori dai manifesti ScaledObject facendo riferimento a una TriggerAuthentication o ClusterTriggerAuthentication. Questo aiuta a tenere le credenziali fuori dal version control e ne consente il riutilizzo.
e. Evita di abbinare uno ScaledObject a un HPA creato manualmente sullo stesso workload: due controller che tentano di scalare lo stesso workload possono entrare in conflitto tra loro. Lascia che sia KEDA a gestire l'HPA per i workloads che scala.
f. Testa gli upgrade in un cluster non di produzione prima del rollout: le versioni minor di KEDA possono includere modifiche alle CRD, quindi testa prima l'upgrade in un ambiente sicuro. Questo aiuta a individuare i problemi di compatibilità prima che colpiscano i workloads di produzione.