KEDA Helm Chart: So installieren, konfigurieren und betreiben Sie KEDA

Das KEDA Helm Chart ist der offizielle Weg, KEDA – den Kubernetes Event-Driven Autoscaler – in Ihrem Cluster zu installieren. Ein einziges helm install stellt alles bereit, was KEDA braucht, um Ihre Workloads ereignisbasiert zu skalieren: den Operator, den Metrics Server, die Admission Webhooks und die Custom Resources, mit denen Sie Ihre Skalierungsregeln definieren.

Dieser Leitfaden behandelt das Chart im Detail. Sie erfahren, was es installiert, wie Sie es einrichten und verifizieren, welche values.yaml-Parameter wichtig sind, wie Sie KEDA hochverfügbar betreiben, wie Sie es absichern und überwachen, wie Sie es per GitOps verwalten und wie Sie es aktualisieren oder deinstallieren, ohne defekte Ressourcen zurückzulassen.

Die Installation absichern

Zwei Einstellungen können die Sicherheit von KEDA in der Produktion erhöhen: eingeschränkter Zugriff auf Secrets und das Zertifikatsmanagement. Im Einzelnen:

a. Zugriff auf Secrets einschränken: Standardmäßig kann KEDA Secrets in allen überwachten Namespaces lesen. Über die permissions.operator-Einstellungen lässt sich dieser Zugriff so beschränken, dass der Operator nur Secrets in seinem eigenen Release-Namespace oder nur bestimmte, namentlich genannte Secrets lesen darf. Das reduziert die Angriffsfläche, falls der Operator kompromittiert wird.

b. Zertifikate verwalten: KEDA erzeugt eigene selbstsignierte Zertifikate, speichert sie in einem Secret namens kedaorg-certs und mountet sie in seine Komponenten. KEDA rotiert diese Zertifikate automatisch und aktualisiert die erforderlichen Kubernetes-Ressourcen, damit sie vertrauenswürdig bleiben.

c. Wenn Ihre Organisation Zertifikate einer verwalteten Zertifizierungsstelle vorschreibt, aktivieren Sie certificates.certManager.enabled, damit cert-manager die Zertifikate ausstellt und rotiert statt KEDA. Für die meisten Installationen reichen die automatisch erzeugten Zertifikate aus.

Das Chart per GitOps deployen

Wenn Sie Ihr Cluster mit Argo CD oder Flux verwalten, können Sie das KEDA Chart per GitOps deployen. Besondere Sorgfalt erfordern dabei vor allem die CRDs.

Die CRDs von KEDA sind groß, und ein normales Kubernetes-Apply kann fehlschlagen, weil die generierte Annotation zu groß wird. Konfigurieren Sie Ihr GitOps-Tool deshalb so, dass es die CRDs ersetzt, statt sie zu mergen. In Flux: Setzen Sie crds: CreateReplace im HelmRelease. In Argo CD: Verwenden Sie Replace=true oder Server-Side Apply für die CRDs, damit sie korrekt angewendet werden.

Sind die CRDs falsch konfiguriert, kann die GitOps-verwaltete KEDA-Installation fehlschlagen.

Alternativ können Sie das Chart mit helm template in reguläre Kubernetes-YAML-Dateien rendern und diese in Git committen, wenn Ihr Workflow gerenderte Manifeste einem Live-Helm-Release vorzieht.

Welchen Ansatz Sie auch wählen: Halten Sie das Label app.kubernetes.io/managed-by konsistent, damit Ihr GitOps-Tool und Helm nicht um die Ownership der Ressourcen konkurrieren.

Ihr erstes ScaledObject nach der Installation

Mit installiertem KEDA können Sie über ein ScaledObject verifizieren, dass KEDA tatsächlich einen Workload skalieren kann. Das folgende Beispiel nutzt einen Cron-Trigger und benötigt daher kein externes System. Es skaliert ein Deployment während eines geplanten Zeitfensters hoch und danach wieder herunter.

Erstellen Sie zunächst ein Deployment, das skaliert werden soll, und wenden Sie dann das ScaledObject an:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: nginx-cron
  namespace: default
spec:
  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 legt fest, wie oft KEDA den Trigger prüft (in Sekunden). minReplicaCount: 0 aktiviert Scale-to-Zero. Außerhalb des 9-bis-17-Uhr-Fensters kann das Deployment auf null Pods herunterskalieren. Während des geplanten Zeitfensters skaliert es auf fünf Replicas hoch.

Wenden Sie das ScaledObject an und prüfen Sie, was KEDA erstellt hat:

kubectl get scaledobject
kubectl get hpa

Sie sollten einen HPA namens keda-hpa-nginx-cron sehen. KEDA erstellt und verwaltet diesen HPA, der die eigentliche Skalierung übernimmt. Das bestätigt, dass KEDA mit dem Workload verbunden ist und die zeitgesteuerte Skalierung funktioniert.

Die KEDA-Installation überwachen

Sobald KEDA läuft, sollten Sie prüfen, ob es fehlerfrei arbeitet und sich wie erwartet verhält.
KEDA stellt Prometheus-Metriken für den Operator und den Metrics Server bereit. Diese Metriken zeigen Scaler-Aktivität, Fehler und die von KEDA gemeldeten Werte.

Wenn Sie den Prometheus Operator einsetzen, kann das KEDA Chart einen ServiceMonitor für den Metrics Server und einen PodMonitor für den Operator anlegen. Sie aktivieren dies über die prometheus-Einstellungen in values.yaml, damit Prometheus die Metriken automatisch erfasst.

Auch die Operator-Logs sind hilfreich, wenn ein bestimmtes ScaledObject nicht wie erwartet funktioniert. Sie zeigen, wie der Scaler seinen Trigger ausliest und welche Fehler dabei auftreten.

Die Operator-Logs sehen Sie mit:

kubectl logs -n keda deploy/keda-operator

Right-Sizing der Workloads, die KEDA skaliert

KEDA kann die Anzahl der Pods sehr gut am Bedarf ausrichten. Aber es entscheidet nicht, wie viel CPU und Arbeitsspeicher jeder Pod anfordern sollte.

Mehr Replicas beheben keine falschen Resource Requests. Wenn jeder Pod deutlich mehr CPU oder Arbeitsspeicher anfordert, als er tatsächlich nutzt, vervielfacht KEDA diese Verschwendung mit jeder zusätzlichen Replica. Fordert jeder Pod zu wenig an, werden neue Replicas bei steigendem Traffic womöglich OOMKilled oder CPU-gedrosselt.

Hier helfen Tools zur Ressourcenoptimierung. PerfectScale beobachtet, wie Workloads CPU und Arbeitsspeicher tatsächlich nutzen, und liefert automatisierte Right-Sizing-Empfehlungen, die Sie manuell oder automatisch anwenden können.

In Kombination mit KEDA erhalten Sie beide Seiten des Autoscalings: KEDA passt die Anzahl der Pods an die Nachfrage an, während PerfectScale dafür sorgt, dass jeder Pod die richtige Menge an CPU und Arbeitsspeicher erhält. So lässt sich Over-Provisioning vermeiden, ohne die Zuverlässigkeit der Workloads zu gefährden. Probieren Sie es aus oder buchen Sie eine technische Session.

Andere Tools wie der Vertical Pod Autoscaler (VPA), der Resource Requests anhand der Nutzung anpassen kann, Goldilocks, das VPA-Empfehlungen visualisiert, und Karpenter konzentrieren sich auf die Auswahl und Verwaltung der Nodes, auf denen Ihre Workloads laufen.

Das Chart aktualisieren und deinstallieren

Beim Upgrade oder der Deinstallation von KEDA gibt es einige wichtige Punkte zu beachten.

Um KEDA zu aktualisieren, aktualisieren Sie zunächst das Helm-Repository und führen dann das Upgrade auf eine gepinnte Chart-Version durch:

helm repo update
helm upgrade keda kedacore/keda --namespace keda --version <new-chart-version>

Worauf Sie beim Upgrade achten müssen, sind die CRDs. Da das Chart sie verwaltet, aktualisiert ein helm upgrade sie zusammen mit allem anderen. KEDA-Minor-Versionen ändern jedoch gelegentlich CRD-Felder oder das Scaler-Verhalten. Lesen Sie daher vor dem Upgrade eines Produktionsclusters die Release Notes und prüfen Sie, ob die neue KEDA-Version Ihre Kubernetes-Version noch unterstützt.

Auch die Deinstallation von KEDA erfordert Sorgfalt, da sonst Ressourcen zurückbleiben können.

Löschen Sie zuerst die ScaledObject- und ScaledJob-Ressourcen:

kubectl delete scaledobject --all --all-namespaces
kubectl delete scaledjob --all --all-namespaces

Deinstallieren Sie dann das Helm-Release:

helm uninstall keda --namespace keda

Wenn Sie die ScaledObject- und ScaledJob-Ressourcen zuerst löschen, kann KEDA die von ihm erstellten HPAs aufräumen. Außerdem können Workloads, die auf null skaliert wurden, wieder auf ihre normale Replica-Anzahl zurückkehren, bevor KEDA entfernt wird.

Bleibt eine Ressource wegen eines Finalizers beim Löschen hängen, können Sie den Finalizer so entfernen:

kubectl patch scaledobject <name> -p '{"metadata":{"finalizers":null}}' --type=merge

Häufige Probleme mit dem Chart beheben

Wenn KEDA nicht wie erwartet skaliert, sollten Sie zwei häufige Probleme prüfen:

a. Die External Metrics API ist nicht verfügbar oder die TLS-Verifizierung schlägt fehl: Zeigt kubectl get apiservice v1beta1.external.metrics.k8s.io nicht Available, kann der HPA keine externen Metriken abrufen – und Workloads können nicht auf deren Basis skalieren. Häufige Ursachen sind ein fehlerhafter Metrics Server, eine NetworkPolicy, die den Traffic blockiert, oder ein Proxy, der die Verbindung zwischen Kubernetes API Server und Metrics Server stört. Prüfen Sie zuerst den Metrics-Server-Pod. Wenn Sie einen Proxy verwenden, stellen Sie sicher, dass die Cluster-IP des Metrics Servers in der no_proxy-Liste des API Servers enthalten ist.

b. Ein ScaledObject wurde erstellt, aber die Replicas ändern sich nicht: Beginnen Sie mit kubectl describe scaledobject <name> und prüfen Sie Status und Events. Sehen Sie sich dann die Logs des KEDA Operators an. Ursachen können ein falsch konfigurierter Trigger, fehlende Authentifizierung für die Event-Quelle oder ein bereits vorhandener HPA sein, der denselben Workload adressiert. Der bestehende HPA kann mit dem HPA in Konflikt geraten, den KEDA erstellt und verwaltet.

Best Practices für den Betrieb des KEDA Helm Charts

Die folgenden Praktiken helfen, eine KEDA-Installation stabil und sicher zu halten:

a. Pinnen Sie die Chart-Version und ordnen Sie sie einer getesteten KEDA-App-Version zu: Installieren oder aktualisieren Sie nicht einfach auf die jeweils neueste Version. Pinnen Sie das Chart, testen Sie die KEDA-Version und rollen Sie sie kontrolliert aus – so wissen Sie immer, was läuft.

b. Betreiben Sie KEDA in einem eigenen Namespace mit eigener Resource Quota: Ein dedizierter Namespace isoliert KEDA und macht es einfacher, ResourceQuota und NetworkPolicy gezielt auf KEDA anzuwenden.

c. Setzen Sie explizite Requests und Limits für alle drei KEDA-Komponenten: Legen Sie angemessene Ressourcen für Operator, Metrics Server und Webhooks fest, damit KEDA selbst nicht gedrosselt oder verdrängt wird, wenn das Cluster unter Last steht.

d. Nutzen Sie TriggerAuthentication statt Zugangsdaten direkt im ScaledObject: Halten Sie Zugangsdaten aus Ihren ScaledObject-Manifesten heraus, indem Sie auf eine TriggerAuthentication oder ClusterTriggerAuthentication verweisen. So landen Zugangsdaten nicht in der Versionskontrolle und lassen sich zudem wiederverwenden.

e. Kombinieren Sie ein ScaledObject nicht mit einem manuell erstellten HPA auf demselben Workload: Zwei Controller, die denselben Workload skalieren wollen, können in Konflikt geraten. Überlassen Sie KEDA die Verwaltung des HPA für Workloads, die KEDA skaliert.

f. Testen Sie Upgrades in einem Nicht-Produktionscluster, bevor Sie sie ausrollen: KEDA-Minor-Versionen können CRD-Änderungen enthalten. Testen Sie das Upgrade daher zuerst in einer sicheren Umgebung. So erkennen Sie Kompatibilitätsprobleme, bevor sie Produktions-Workloads treffen.