Horizontal Pod Autoscaler (HPA)

HPA (Horizontal Pod Autoscaler) ist eine Form der automatischen Skalierung, bei der die Anzahl der Pods in einem Replication Controller, Deployment, Replica Set oder Stateful Set auf der Grundlage verschiedener Metriken wie RAM- und CPU-Auslastung, Tageszeit oder Datenverkehr auf einem Load Balancer angepasst wird. Die Skalierung ist horizontal, d.h. sie betrifft die Anzahl der Instanzen und nicht die einem einzelnen Pod zugewiesenen Ressourcen.

HPA kann Skalierungsentscheidungen auf der Grundlage von benutzerdefinierten oder extern bereitgestellten Metriken (z. B. ├╝ber Prometheus) treffen und arbeitet nach der Erstkonfiguration automatisch. Sie m├╝ssen lediglich die MIN- und MAX-Anzahl der Replikate festlegen.

Nach der Konfiguration ├╝berpr├╝ft der Horizontal Pod Autoscaler Controller in regelm├Ą├čigen Abst├Ąnden die Metriken und skaliert die Pods entsprechend nach oben oder unten. Standardm├Ą├čig ├╝berpr├╝ft HPA die Metriken alle 15 Sekunden.

Zur ├ťberwachung der Metriken st├╝tzt sich HPA auf eine andere Kubernetes-Ressource, den Metrics Server. Der Metrics Server liefert standardm├Ą├čige Metriken zur Ressourcennutzung, indem er Daten von “kubernetes.summary_api” sammelt, z. B. die CPU- und Speichernutzung f├╝r Knoten und Pods. Er kann auch auf benutzerdefinierte Metriken zugreifen (die von einer externen Quelle gesammelt werden), wie z. B. die Anzahl der aktiven Sitzungen auf einem Load Balancer oder die Backend-Last.

So wird sichergestellt, dass eine Anwendung auch unter Last verf├╝gbar bleibt und ihre Funktion erf├╝llen kann. Es stellt auch sicher, dass eine Anwendung nicht mehr Replikate betreibt, als gerade ben├Âtigt werden, und optimiert so die Ressourcennutzung und die Kosten in beide Richtungen. Die Skalierung ist jedoch durch die verf├╝gbare Rechenleistung des Clusters begrenzt.

Wie funktioniert der HPA?

HPA fragt die Kubernetes-API regelm├Ą├čig nach der Ressourcennutzung eines Pods ab und passt die Anzahl der Replikate nach Bedarf an, um ein Zielniveau der Ressourcennutzung zu erreichen.

Im Einzelnen funktioniert der Prozess wie folgt:

  1. HPA ├╝berwacht die in der Konfiguration angegebenen Metriken (normalerweise alle 15 Sekunden).
  2. Auf der Grundlage der erfassten Metriken berechnet HPA die gew├╝nschte Anzahl der erforderlichen Replikate.
  3. HPA skaliert den Pod bei Bedarf auf die gew├╝nschte Anzahl von Replikaten hoch oder runter.
  4. Da HPA kontinuierlich ├╝berwacht, wiederholt sich der Prozess ab Schritt 1.

Weitere Details zum Algorithmus k├Ânnen Sie unter diesem Link nachlesen: Details zum Algorithmus.

Beschr├Ąnkungen des Horizontal Pod Autoscalers

HPA ist zwar ein leistungsf├Ąhiges Tool, aber nicht f├╝r jeden Anwendungsfall ideal und kann nicht jedes Problem im Zusammenhang mit Cluster-Ressourcen l├Âsen. Hier sind einige ├ťberlegungen:

  • HPA funktioniert nur mit zustandslosen Anwendungen, die zur Replikation f├Ąhig sind, oder mit Stateful Sets, die eine Persistenz erm├Âglichen.
  • HPA funktioniert nicht mit Daemon-Sets.
  • Wenn die Grenzwerte f├╝r Pod-Metriken nicht effizient festgelegt sind, kann es h├Ąufig zum Abbruch von Pods oder zur Verschwendung von Ressourcen kommen.
  • HPA kann nicht in Verbindung mit VPA (Vertical Pod Autoscaler) verwendet werden, das auf denselben Metriken basiert.
  • HPA kann nicht skalieren, wenn die Gesamtkapazit├Ąt des Clusters ersch├Âpft ist, bis neue Knoten zum Cluster hinzugef├╝gt werden.

Wie verwendet man HPA?

Um HPA zu verwenden, m├╝ssen Sie eine Kubernetes-Ressource des Typs HorizontalPodAutoscaler erstellen. In dieser Ressource geben Sie das zu skalierende Deployment oder den Replica Controller, die minimale und maximale Anzahl der Replikate sowie die Zielressourcenauslastung oder benutzerdefinierte Metriken an.

Hier sehen Sie eine Beispielkonfiguration f├╝r die HPA-Skalierung auf der Grundlage von Kubernetes-Metriken:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-deployment-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 80

In dieser Konfiguration ist die minimale Anzahl der Replikate auf 1 und die maximale Anzahl auf 10 festgelegt, und es wird eine CPU-Auslastung von 80 % angestrebt. HPA skaliert die Anzahl der Replikate von “my-deployment” automatisch auf der Grundlage der CPU-Auslastung der Pods.

Wenn Sie m├Âchten, dass HPA auf der Grundlage benutzerdefinierter Metriken arbeitet, muss es auf Metriken von einem Prometheus-Endpunkt zugreifen. Sie k├Ânnen Prometheus so konfigurieren, dass es Metriken von den Pods abruft, oder einen Kubernetes-Dienst verwenden, der Metriken im Prometheus-Format exportiert. Sobald die Metriken in Prometheus verf├╝gbar sind, k├Ânnen Sie einen Prometheus-Adapter verwenden, um HPA f├╝r die Verwendung dieser Metriken zu konfigurieren.

Hier ist eine Beispielkonfiguration f├╝r die HPA-Skalierung basierend auf einer benutzerdefinierten Metrik:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-deployment-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metricName: custom_metric
      targetAverageValue: 100

Testing

Es gibt mehrere M├Âglichkeiten, den Kubernetes Horizontal Pod Autoscaler (HPA) zu testen, einschlie├člich der Verwendung von Prometheus-Metriken als Grundlage.

  1. Verwendung eines Lasttest-Tools: Eine M├Âglichkeit, den HPA zu testen, besteht darin, ein Lasttest-Tool wie Apache JMeter oder Gatling zu verwenden, um die Last einer Anwendung zu erzeugen. Sie k├Ânnen beobachten, wie die HPA reagiert, indem Sie die Anzahl der Replikate basierend auf der Nutzung der Pod-Ressourcen erh├Âhen oder verringern.

  2. Verwendung des Kubernetes-Befehls “kubectl”: Sie k├Ânnen “kubectl” verwenden, um die Anzahl der Pod-Replikate manuell zu erh├Âhen oder zu verringern und die Reaktion der HPA zu beobachten. Sie k├Ânnen zum Beispiel “kubectl scale” verwenden, um die Anzahl der Replikate eines Deployments oder Replica Controllers zu erh├Âhen.

  3. Simulation von Hochlast mit Prometheus: Wenn Sie HPA mit Prometheus-Metriken verwenden, k├Ânnen Sie diese Metrik k├╝nstlich erh├Âhen. Indem Sie Prometheus selbst verwenden, um hohe Last zu simulieren, k├Ânnen Sie eine Metrik erstellen oder ├Ąndern, die schnell ansteigt oder abf├Ąllt. Anschlie├čend k├Ânnen Sie beobachten, wie die HPA auf die ├änderung reagiert.

Simultaneous Use of HPA and VPA

HPA und VPA k├Ânnen miteinander in Konflikt geraten, wenn Sie beispielsweise RAM als Basismessgr├Â├če f├╝r die Skalierung in beiden verwenden. Dies kann dazu f├╝hren, dass beide versuchen, Workloads gleichzeitig vertikal und horizontal zu skalieren, was zu unvorhersehbaren Konsequenzen f├╝hrt. Um solche Konflikte zu vermeiden, sollten sich HPA und VPA auf unterschiedliche Metriken konzentrieren.

In der Regel wird VPA so konfiguriert, dass die Skalierung auf der Grundlage von CPU oder RAM erfolgt, und f├╝r HPA werden benutzerdefinierte Metriken verwendet.

Monitoring

Sobald die HPA eingerichtet ist, k├Ânnen Sie sie ├╝ber die Kubernetes-API oder mit ├ťberwachungstools wie Prometheus, Grafana oder Kubernetes Dashboard ├╝berwachen. Sie sollten beobachten, wie die HPA auf ├änderungen der Anzahl der Replikate unter Last reagiert, Pods anpassen und sicherstellen, dass die Anzahl der Replikate innerhalb des gew├╝nschten Bereichs liegt.

Es ist wichtig zu beachten, dass die HPA einen Regelkreis verwendet, um sicherzustellen, dass die Replikate die gew├╝nschte Anzahl erreichen. Daher kann es einige Zeit dauern, bis die HPA auf Last├Ąnderungen reagiert.

Au├čerdem wird empfohlen, die HPA in einer Staging-Umgebung und nicht in einer Produktionsumgebung zu testen, da dies zu unerwartetem Verhalten f├╝hren kann, das die Verf├╝gbarkeit der Anwendung beeintr├Ąchtigen kann.

Zuletzt ge├Ąndert 22.04.2024: Changes for the final Marketing Review (f62d8c7)