Inhaltsverzeichnis
20.12.2024
Optimierte Ressourcennutzung und Kostenkontrolle.Effiziente Betriebszeiten mit KEDA: Dynamisches Autoscaling fĂŒr Kubernetes-Cluster
Kubernetes ist leistungsstark, doch ohne optimierte Betriebszeiten können unnötige Ressourcen und Kosten entstehen. KEDA (Kubernetes Event - Driven Autoscaling) ermöglicht es, Workloads dynamisch zu skalieren und z.B. auĂerhalb definierter Betriebszeiten zu pausieren. In diesem Blogpost zeigen wir, wie du mit KEDA deinen Cluster an Arbeitszeiten anpasst â fĂŒr mehr Effizienz und reduzierte Hosting-Kosten.
EinfĂŒhrung in Kubernetes Autoscaling
Kubernetes bringt bereits viel Automatismus und Möglichkeiten zur Effizienzoptimierung mit sich. Sei es das Zuweisen von Workloads zu den Nodes, Readiness- und Liveness - Probes, um hĂ€ngende Container neu zu starten, oder ein dynamisches HinzufĂŒgen oder Entfernen von Nodes mittels Cluster Autoscaler. Auch ein dynamisches Skalieren einzelner Workloads anhand der Ressourcen-Auslastung ist mittels Horizontal Pod Autoscaling möglich. Doch damit lassen sich nicht alle Anforderungen abdecken. Was ist z.B. mit einem Cluster, der nur werktags zu den Arbeitszeiten benötigt wird? In diesem Blogpost betrachten wir, wie du Kubernetes Workloads mittels KEDA anhand eines zeitbasierten Schedules skalieren kannst.
Erfahre mehr, wie wir dir mit Docker und Kubernetes behilflich sein könnenWas ist KEDA?
KEDA greift den Gedanken des Pod Autoscaling auf und erweitert ihn um die Möglichkeit, nicht nur anhand der Ressourcenauslastung zu skalieren, sondern auch anhand allgemeinerer Events. Die Events können z.B. auf Datenbank-Queries basieren, auf Metriken eines Message-Brokers, auf einem Cron-Schedule und vielem mehr.
Derzeit unterstĂŒtzt KEDA 71 sogenannte Scaler, die du als Basis fĂŒr das eventbasierte Autoscaling verwenden kannst. Du musst dazu lediglich ein ScaledObject anlegen, eine CustomResourceDefinition von KEDA. Der keda-operator, der im Cluster deployt ist, erzeugt daraufhin dynamisch eine entsprechende HorizontalPodAutoscaler Ressource, um deine selektierten Workloads anhand der spezifizierten Events zu skalieren.
Cron-Scaler um Betriebszeiten zu definieren
Um die Workloads eines Clusters auĂerhalb der Betriebszeiten auf 0 zu skalieren, nutzen wir den Cron-Scaler. Dieser ermöglicht es, ein Cron-Schedule mit Start- und Endzeit zu definieren, innerhalb dessen die Workloads auf eine gewĂŒnschte Anzahl an Replicas skaliert werden. AuĂerhalb des Schedules werden die Workloads auf die spezifizierte Mindestanzahl skaliert.
Anhand eines exemplarischen ScaledObjects zum beschriebenen Szenario wirst du sehen, wie einfach die Konfiguration fĂŒr unseren Anwendungsfall ist:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: cron-scaledobject
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-deployment
minReplicaCount: 0
maxReplicaCount: 3
cooldownPeriod: 60
triggers:
- type: cron
metadata:
timezone: Europe/Berlin
start: 0 6 * * 1-5
end: 0 20 * * 1-5
desiredReplicas: '3'
Was passiert hier?
Das selektierte Deployment ist my-deployment, im default-Namespace. Der minReplicaCount ist 0, damit es auĂerhalb der Betriebszeiten auf 0 skaliert wird. Start und Ende der Betriebszeit sind mit den Cron-Schedules 0 6 * * 1-5, bzw. 0 20 * * 1-5 spezifiziert. D.h. montags bis freitags zwischen 6:00 und 20:00 wird das Deployment auf die 3 Replicas skaliert, was durch den Parameter desiredReplicas angegeben ist. Dies sorgt fĂŒr einen effizienteren Ressourcenverbrauch.
Wir können auch Deine Apps dynamisch an den Bedarf anpassen.
Wie hoch ist die Kostenersparnis?
Die wirklich spannende Frage ist: Wie groà ist der Effizienzgewinn und somit die Kostenersparnis durch die Umsetzung von Betriebszeiten? Das hÀngt ganz stark von deinem Setup ab.
Voraussetzung
Der Cluster Autoscaler muss aktiv sein, damit ungenutzte Nodes entfernt werden können. Die Höhe der Einsparungen hĂ€ngt dann davon ab, wie viele Workloads auĂerhalb der Betriebszeiten pausiert werden können.
Beispiel
- Wenn in deinem Cluster 10 Anwendungen laufen und nur eine auĂerhalb der Betriebszeiten skaliert wird, bleibt der Effekt gering.
- Kannst du hingegen 9 Workloads pausieren, reduziert sich der Bedarf an Nodes erheblich â das spart spĂŒrbare Kosten.
Fazit
KEDA macht es sehr einfach, Kubernetes-Workloads anhand zeitbasierter Events dynamisch zu skalieren. Die Installation und die Spezifikation der ScaledObjects sind unkompliziert und nehmen wenig Zeit in Anspruch.
Auch wenn die genaue Kostenersparnis nicht pauschal prognostiziert werden kann, lohnt sich der Einsatz von KEDA langfristig, wenn deine Workloads eine zeitbasierte Charakteristik aufweisen.
HĂ€ufige Fragen
1. Was ist KEDA und wie unterscheidet es sich vom Kubernetes Horizontal Pod Autoscaler (HPA)?
KEDA (Kubernetes Event-Driven Autoscaling) erweitert das klassische Horizontal Pod Autoscaling (HPA) in Kubernetes. WĂ€hrend HPA Workloads basierend auf Ressourcen wie CPU- oder Speicherauslastung skaliert, ermöglicht KEDA das Autoscaling basierend auf externen Ereignissen. Dazu gehören Datenbank-Abfragen, Message-Broker-Metriken oder zeitgesteuerte Trigger. KEDA arbeitet ergĂ€nzend zum HPA, indem es externe Metriken ĂŒbermittelt und so flexiblere Skalierungsmöglichkeiten schafft.
2. Welche Vorteile bietet KEDA fĂŒr das dynamische Autoscaling von Kubernetes-Workloads?
KEDA bietet folgende Vorteile:
- FlexibilitÀt: Skalierung basierend auf externen Ereignissen (z. B. Kafka, Prometheus oder Azure Event Hubs).
- Zero Scaling: Workloads können auf 0 Pods reduziert werden, wenn keine Ressourcen benötigt werden.
- Einfache Integration: KEDA arbeitet nahtlos mit HPA zusammen und nutzt bestehende Kubernetes-Mechanismen.
- Kostenersparnis: Durch bedarfsgerechte Skalierung können unnötige Ressourcen vermieden werden.
- Breite UnterstĂŒtzung: Mit ĂŒber 70 Scalers ist KEDA vielseitig einsetzbar.
3. Wie funktioniert der Cron-Scaler von KEDA fĂŒr zeitbasiertes Autoscaling?
Der Cron-Scaler in KEDA ermöglicht die zeitgesteuerte Skalierung von Workloads. Du definierst ein Cron-Schedule mit Start- und Endzeit sowie der gewĂŒnschten Anzahl an Replicas. AuĂerhalb dieses Zeitfensters werden Workloads auf die spezifizierte Mindestanzahl (z. B. 0 Pods) skaliert.
Beispiel: Ein Deployment kann von Montag bis Freitag zwischen 6:00 und 20:00 auf 3 Pods hochskaliert und auĂerhalb dieser Zeiten auf 0 reduziert werden.
4. Welche Ereignisquellen (Scaler) unterstĂŒtzt KEDA fĂŒr das Autoscaling?
KEDA unterstĂŒtzt ĂŒber 70 Scalers, darunter:
- Message-Broker: Kafka, RabbitMQ, Azure Event Hubs.
- Datenbanken: MySQL, PostgreSQL, MongoDB.
- Metrikquellen: Prometheus, AWS CloudWatch, Azure Monitor.
- Zeitbasierte Trigger: Cron-Schedules.
- Weitere: Redis, GitHub Actions, AWS SQS, und mehr.
KEDA lÀsst sich zudem durch benutzerdefinierte Scaler erweitern, um nahezu jede Ereignisquelle zu integrieren.
5. Was bedeutet Zero Scaling und wie hilft KEDA dabei?
Zero Scaling bedeutet, dass Workloads vollstÀndig deaktiviert werden, indem ihre Anzahl an Pods auf 0 gesetzt wird. KEDA ermöglicht dies durch die Nutzung von Ereignisquellen, die bei Bedarf Pods aktivieren. Dies reduziert die Ressourcennutzung drastisch, wenn keine Ereignisse vorliegen, und hilft, Kosten zu sparen, wÀhrend die Cluster-Effizienz maximiert wird.
6. Ist KEDA fĂŒr alle Kubernetes-Anwendungen geeignet oder gibt es EinschrĂ€nkungen?
KEDA ist fĂŒr viele Anwendungen geeignet, insbesondere fĂŒr:
- Event-getriebene Anwendungen (z. B. Message-Broker, Datenbankoperationen).
- Workloads mit zeitbasierten Anforderungen (z. B. GeschÀftszeiten).
- Metrikbasierte Anwendungen, die auf externe Signale reagieren.
EinschrÀnkungen:
- KEDA ist auf Anwendungen ausgelegt, die skalierbare Architekturen verwenden (z. B. Deployments, Jobs).
- Workloads, die dauerhaft laufen mĂŒssen, profitieren weniger von KEDA, da Zero Scaling hier nicht möglich ist.
- Dein Cluster benötigt einen aktiven Cluster Autoscaler, um Nodes bei Zero Scaling zu entfernen.
Tipp: FĂŒr Anwendungen mit festen Ressourcenanforderungen oder kontinuierlicher VerfĂŒgbarkeit ist HPA allein möglicherweise ausreichend.
Hast du noch Fragen oder eine Meinung? Mit deinem GitHub Account kannst Du es uns wissen lassen...
Was unsere Kunden ĂŒber uns sagen
- Ofa Bamberg GmbHB2B Online-Shop | B2C Website | Hosting | Betreuung | Security© Ofa Bamberg GmbH
- Ludwig-Maximilians-UniversitĂ€t MĂŒnchenPlattformentwicklung | Hosting | Betreuung | APIs | Website
Blueshoe hat unsere Forschungsdatenplattform Munich Media Monitoring (M3) entwickelt und uns hervorragend dabei beraten. Das Team hat unsere Anforderungen genau verstanden und sich aktiv in die Ausgestaltung der Software und der Betriebsumgebung eingebracht. Wir sind froh, dass auch Wartung und weiterfĂŒhrender Support in Blueshoes HĂ€nden liegen.
- Deutsches MuseumDigitalisierung | Beratung | Datenbank-Optimierung | GraphQL | CMSFoto: Anne Göttlicher
Im Rahmen eines komplexen Digitalisierungsprojekts fĂŒr unsere Exponate-Datenbank war Blueshoe ein Ă€uĂerst verlĂ€sslicher Partner. Sie haben uns nicht nur wĂ€hrend des gesamten Projekts hervorragend beraten, sondern unsere Anforderungen perfekt umgesetzt. Dank ihrer Arbeit ist unsere Datenbank nun ein bedeutender Mehrwert fĂŒr die weltweite wissenschaftliche Forschung.
- Fonds Finanz Maklerservice GmbHPlattformentwicklung | Prozess-Systeme | Hosting | Betreuung | Zertifikate | Website© Fonds Finanz Maklerservice GmbH
Blueshoe ist unsere verlĂ€ngerte Werkbank fĂŒr Entwicklung, Wartung und Support unserer Weiterbildungs- und Zertifizierungsplattformen. Das Team hat sich grĂŒndlich in unsere AblĂ€ufe eingearbeitet, und wir freuen uns, Blueshoe als zuverlĂ€ssigen Partner an unserer Seite zu haben.
- Technische UniversitÀt HamburgPlattformentwicklung | Beratung | Prozess-Systeme | Hosting | Website
Seit 2019 unterstĂŒtzt uns die Blueshoe GmbH tatkrĂ€ftig bei der Entwicklung und Weiterentwicklung des "Digital Learning Lab" und der "Digital Learning Tools". Dank ihrer Beratung konnten wir von Anfang an auf eine zukunftssichere, moderne technische Struktur setzen. Die Zusammenarbeit ist reibungslos, und wir fĂŒhlen uns rundum gut betreut. Und davon profitieren dann auch die LehrkrĂ€fte in Hamburg.

























