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.