Eine häufige Situation: Sie haben mehrere Anwendungen, von denen eine tagsüber eine Spitzenlast aufweist und zu anderen Zeiten niemand darauf zugreift (oder auf die nur selten zugegriffen wird). Andere Anwendungen können nachts Cluster-Strom verbrauchen. Als Beispiel für solche Anwendungen können wir Webdienste, einige Datenhandler, anführen.

Wie üblich reichen Clusterressourcen überhaupt nicht aus. Sie müssen sich etwas einfallen lassen, um die Ressourcennutzung zu optimieren, und Kubernetes ist dafür großartig. Es verfügt über einen horizontalen Pod-Autoscaler , mit dem Sie Anwendungen basierend auf Metriken skalieren können.



Metriken werden normalerweise vom Metrikserver bereitgestellt . Als Nächstes werde ich über das Ersetzen des Metrikservers durch Prometheus sprechen (da Prometheus die vom Metrikserver bereitgestellten Daten implementiert und wir einen zusätzlichen Link entfernen) und darüber, wie unsere Anwendungen in Kubernetes basierend auf Metriken von Prometheus skaliert werden.

Installieren Sie zunächst den Prometheus-Operator . Persönlich verwende ich vorgefertigte Manifeste . Sie können das Diagramm für Helm verwenden (aber ich habe die Leistung nicht überprüft). Entfernen Sie auch den Metrikserver, falls vorhanden. Überprüfen Sie danach, ob alles ordnungsgemäß funktioniert.

# kubectl get --raw "/apis/metrics.k8s.io/v1beta1/" | jq { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "metrics.k8s.io/v1beta1", "resources": [ { "name": "nodes", "singularName": "", "namespaced": false, "kind": "NodeMetrics", "verbs": [ "get", "list" ] }, { "name": "pods", "singularName": "", "namespaced": true, "kind": "PodMetrics", "verbs": [ "get", "list" ] } ] } 

Wenden Sie dann Manifeste aus diesem Verzeichnis an . Dadurch wird der Prometheus-Adapter installiert. Ich habe ein Diagramm gefunden , das diese Manifeste enthält, es aber nicht überprüft. Danach sollten Sie den Befehl korrekt ausführen:

 kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq 

(Es wird eine sehr große Liste geben, daher werde ich sie hier nicht auflisten.)

Um zu verstehen, was die URLsmetrics.k8s.io und custom.metrics.k8s.io bedeuten, kann Ihnen die Dokumentation helfen.

Wenn etwas nicht funktioniert, schauen Sie wie gewohnt in die Protokolle. Sie können auch nach einer Lösung für Probleme suchen.

Richten Sie jetzt die automatische Skalierung ein.

Ich habe eine Anwendung, die viele Prozessorressourcen verbraucht und die Warteschlange bedient. Sobald die Warteschlangengröße einen bestimmten Schwellenwert überschreitet, möchte ich die Anzahl der Herde im Replikatsatz erhöhen, um die Warteschlange schneller zu verarbeiten. Sobald die Größe unter dem Schwellenwert liegt, sollten Clusterressourcen freigegeben werden.

Um zu verstehen, wie Regeln für den Prometheus-Adapter geschrieben werden, müssen Sie dieses Dokument und die zugehörigen Seiten sorgfältig lesen. So sieht es bei mir aus.

Bitte an Prometheus

 wqueue_tube_total_size{tube="dmload-legacy"} 

es gibt zurück:

 wqueue_tube_total_size{endpoint="pprof-port",instance="10.116.2.237:8542",job="wqueue-pprof",namespace="default",pod="wqueue-b9fdd9455-66mwm",service="wqueue-pprof",tube="dmload-legacy"} 32 

Und ich schreibe die folgende Regel für Prometheus-Adapter:

 - seriesQuery: wqueue_tube_total_size{tube="dmload-legacy"} resources: overrides: namespace: resource: namespace tube: resource: service name: {as: "wqueue_tube_total_size_dmload_legacy"} metricsQuery: wqueue_tube_total_size{tube="dmload-legacy"} 

Es sollte beachtet werden, dass ich den Röhrenparameter im Betrieb abbilden muss, um dann hpa in der Beschreibung zu verwenden.

Hpa-Konfiguration:

 --- kind: HorizontalPodAutoscaler apiVersion: autoscaling/v2beta1 metadata: name: dmload-v3-legacy namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: dmload-v3-legacy minReplicas: 2 maxReplicas: 20 metrics: - type: Object object: metricName: wqueue_tube_total_size_dmload_legacy target: apiVersion: v1 kind: Service name: dmload-legacy targetValue: 30 

Hier wqueue_tube_total_size_dmload_legacy ich darauf hin, dass sobald die Anzahl der Jobs in der Warteschlange wqueue_tube_total_size_dmload_legacy 30 überschreitet, Pods hinzugefügt werden, bis es 20 gibt, und wenn targetValue unter 30 fällt, dann auf 2 reduzieren.

Wir bewerben uns und sehen, was passiert. Mein System arbeitet mehrere Tage und reduziert im Moment nur die Anzahl der Herde:

 # kubectl describe hpa dmload-v3-legacy Name: dmload-v3-legacy Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling/v2beta1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"dmload-v3-legacy","namespace":"d... CreationTimestamp: Thu, 24 Jan 2019 16:16:43 +0300 Reference: Deployment/dmload-v3-legacy Metrics: ( current / target ) "wqueue_tube_total_size_dmload_legacy" on Service/dmload-legacy: 14 / 30 Min replicas: 2 Max replicas: 20 Deployment pods: 15 current / 14 desired Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 14 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from Service metric wqueue_tube_total_size_dmload_legacy ScalingLimited False DesiredWithinRange the desired count is within the acceptable range Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 59m (x14 over 40h) horizontal-pod-autoscaler New size: 13; reason: All metrics below target Normal SuccessfulRescale 59m (x13 over 40h) horizontal-pod-autoscaler New size: 12; reason: All metrics below target Normal SuccessfulRescale 57m (x14 over 40h) horizontal-pod-autoscaler New size: 11; reason: All metrics below target Normal SuccessfulRescale 56m (x14 over 40h) horizontal-pod-autoscaler New size: 10; reason: All metrics below target Normal SuccessfulRescale 56m (x11 over 38h) horizontal-pod-autoscaler New size: 8; reason: All metrics below target Normal SuccessfulRescale 55m (x6 over 36h) horizontal-pod-autoscaler New size: 7; reason: All metrics below target Normal SuccessfulRescale 47m (x103 over 40h) horizontal-pod-autoscaler (combined from similar events): New size: 20; reason: Service metric wqueue_tube_total_size_dmload_legacy above target Normal SuccessfulRescale 3m38s (x19 over 41h) horizontal-pod-autoscaler New size: 17; reason: All metrics below target Normal SuccessfulRescale 2m8s (x23 over 41h) horizontal-pod-autoscaler New size: 16; reason: All metrics below target Normal SuccessfulRescale 98s (x20 over 40h) horizontal-pod-autoscaler New size: 15; reason: All metrics below target Normal SuccessfulRescale 7s (x18 over 40h) horizontal-pod-autoscaler New size: 14; reason: All metrics below target 

Alles, was beschrieben wurde, wurde auf Kubernetes 1.13.2 ausgeführt.

Fazit

In diesem kurzen Artikel habe ich gezeigt, wie Anwendungen in einem Kubernetes-Cluster mithilfe von Metriken von Prometheus automatisch skaliert werden.

Die Prometheus-Operator-Komponenten wurden konfiguriert und die erforderlichen Manifeste erstellt.

Basierend auf der Metrik von Prometheus zur Größe der Warteschlange stellte sich heraus, dass die Anzahl der Pods, die diese Warteschlange verarbeiten, erhöht oder verringert wurde.


(Die Grafik zeigt, wie sich die Anzahl der Herde in Abhängigkeit von der Größe der Warteschlange ändert.)

Vielen Dank für Ihre Aufmerksamkeit!