Vertical Pod Autoscaler (VPA)

Der vertikale Pod-Autoscaler (VPA) ist eine Erweiterung der Kubernetes-API, die eine vertikale Skalierung für Kubernetes-Controller wie Deployments und ihre Pods ermöglicht. Seine Funktionsweise ist komplexer als die des horizontalen Pod-Autoscalers (HPA), da er die Ressourcenanforderungsparameter von Pods auf der Grundlage von Metriken optimiert, die von Arbeitslasten gesammelt wurden. “Anforderungen” sind deklarative Angaben zu den minimal erforderlichen Ressourcen für einen oder mehrere Container innerhalb eines Pods. Höhere Werte gewähren dem geplanten Pod mehr Zugriff auf CPU oder RAM. Wenn festgestellt wird, dass eine Arbeitslast mehr Ressourcen verbraucht als in ihrer Spezifikation angegeben, berechnet der VPA einen neuen Satz geeigneter Werte innerhalb seiner vorgegebenen Grenzen.

Der VPA lässt zwei verschiedene Arten von Ressourcen zu, die für jeden Container innerhalb eines Pods angegeben werden können: Anforderungen und Grenzwerte.

Requests / Limits:

• Anforderungen definieren die Mindestressourcen, die Container benötigen. Eine Anwendung kann beispielsweise mehr als 256 MB Arbeitsspeicher benötigen, aber Kubernetes garantiert ein Minimum von 256 MB, wenn die Anforderung des Containers 256 MB beträgt.
• Limits definieren die maximale Menge an Ressourcen, die einem bestimmten Container zugewiesen werden kann. Die Anwendung benötigt vielleicht mindestens 256 MB Arbeitsspeicher, möchte aber sicherstellen, dass sie unter hoher Last nicht mehr als 512 MB RAM verbraucht.

Wie funktioniert der VPA?

Der VPA fragt die Kubernetes-API regelmäßig nach der Ressourcennutzung eines Pods ab und passt die Anzahl der Replikate nach Bedarf an, um einen Zielwert für die Ressourcenauslastung zu erreichen. Im Einzelnen:

1. Der VPA Recommender liest die VPA-Konfiguration und die Metriken zur Ressourcennutzung vom Metrics-Server.
2. VPA Recommender gibt Empfehlungen für Pod-Ressourcen an den VPA.
3. VPA Updater empfängt die Empfehlungen für Pod-Ressourcen.
4. VPA Updater leitet die Beendigung des Pods ein.
5. Die Bereitstellung stellt fest, dass der Pod beendet wurde und erstellt einen neuen Pod, der seinem gewünschten Zustand entspricht.
6. Während sich der Pod im Wiederherstellungsprozess befindet, empfängt der VPA Admission Controller die Ressourcenempfehlungen für den Pod. Da Kubernetes keine dynamische Änderung der Ressourcengrenzen eines laufenden Pods unterstützt, kann VPA bestehende Pods nicht mit neuen Grenzen aktualisieren. Er beendet Pods mit veralteten Grenzwerten. Wenn der Pod-Controller beim Kubernetes-API-Dienst eine Ersetzung anfordert, fügt der VPA Admission Controller die aktualisierten Ressourcenanforderungen und Grenzwerte in die Spezifikation des neuen Pods ein.
7. Schließlich setzt der VPA Admission Controller die Empfehlungen für den Pod außer Kraft.

UpdateMode: Je nachdem, wie der VPA konfiguriert ist, kann er die folgenden Modi haben:

• Empfehlungen direkt durch Aktualisierung/Erstellung von Pods anwenden (updateMode = auto).
• Speichern der empfohlenen Werte als Referenz (updateMode = off).
• Anwendung der empfohlenen Werte nur auf neu erstellte Pods (updateMode = initial).

Wie verwendet man VPA?

Hier ist ein Beispiel für die Verwendung von VPA in einer YAML-Konfiguration:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-deployment-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-deployment
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        controlledResources:
          - cpu
          - memory
        maxAllowed:
          cpu: 1
          memory: 500Mi
        minAllowed:
          cpu: 100m
          memory: 50Mi
  updatePolicy:
    updateMode: "Auto"

Beschränkungen von VPA

Wie HPA ist auch VPA ein leistungsstarkes Werkzeug, das jedoch einige Einschränkungen aufweist und nicht für jeden Anwendungsfall ideal ist. Es kann nicht jedes Problem mit Cluster-Ressourcen lösen, und einige Überlegungen umfassen:

• Wenn die Ressourcengrenzen für Pod-Metriken nicht effizient festgelegt sind, kann VPA Pods häufig beenden oder Ressourcen verschwenden.
• VPA kann nicht parallel zu HPA auf der Grundlage derselben Metriken verwendet werden.
• VPA kann nicht skalieren, wenn die Gesamtkapazität des Clusters erschöpft ist, bis neue Knoten hinzugefügt werden.
• VPA kann mehr Ressourcen empfehlen, als im Cluster verfügbar sind, was dazu führt, dass Pods aufgrund unzureichender Ressourcen nicht den Knoten zugewiesen werden. Um diese Einschränkung zu umgehen, empfiehlt es sich, LimitRange auf die maximal verfügbaren Ressourcen zu setzen, um sicherzustellen, dass Pods nicht mehr Ressourcen anfordern, als in LimitRange definiert sind.

Testing

Es gibt mehrere Möglichkeiten, den Kubernetes Vertical Pod Autoscaler (VPA) zu testen:

1. Verwendung eines Lasttest-Tools: Eine Möglichkeit, VPA zu testen, besteht darin, ein Lasttest-Tool wie Apache JMeter oder Gatling zu verwenden, um eine Anwendung zu belasten. Sie können beobachten, wie VPA reagiert, indem Sie die Anzahl der Replikate basierend auf dem Ressourcenverbrauch des Pods erhöhen oder verringern.

2. Verwenden Sie den Befehl “kubectl”: Sie können die Anzahl der Pod-Replikate manuell mit “kubectl” erhöhen oder verringern und beobachten, wie VPA reagiert. Zum Beispiel kann “kubectl scale” verwendet werden, um die Anzahl der Replikate eines Deployments oder RCs anzupassen.

Gleichzeitige Verwendung von VPA und HPA

VPA und HPA können zu Konflikten führen, insbesondere wenn beide für die Skalierung auf der Grundlage derselben Ressource (z. B. RAM) konfiguriert sind. Dies kann dazu führen, dass beide versuchen, Workloads gleichzeitig vertikal und horizontal zu skalieren, was zu unvorhersehbaren Ergebnissen führt. Um solche Konflikte zu vermeiden, ist es am besten, HPA auf andere Metriken als VPA auszurichten, z. B. durch die Verwendung benutzerdefinierter Metriken für HPA, während VPA auf der Grundlage von CPU oder RAM skaliert.

Monitoring

Sobald VPA eingerichtet ist, können Sie es über die Kubernetes-API oder mit Überwachungstools wie Prometheus, Grafana oder Kubernetes Dashboard überwachen.