Watermarkpodautoscaler
0.7.0
Haftungsausschluss : Dieses Projekt befindet sich in der Betaphase. Die API kann sich ändern.
Der Watermark Pod Autoscaler (WPA) Controller ist ein benutzerdefinierter Controller, der den Horizontal Pod Autoscaler (HPA) erweitert.
Der Watermark Pod Autoscaler Controller ist ein alternativer Controller zum vorgeschalteten Horizontal Pod Autoscaler Controller.
Wenn Sie einige Ihrer Anwendungen automatisch skalieren möchten, aber:
z.B
apiVersion : datadoghq.com/v1alpha1
kind : WatermarkPodAutoscaler
[...]
spec :
algorithm : absolute
[...]Es gibt zwei Möglichkeiten, die gewünschte Anzahl an Replikaten zu berechnen:
average Der Controller verwendet den value from the external metrics provider zur current number of replicas und vergleicht ihn mit den Wasserzeichen. Die empfohlene Anzahl an Replikaten ist value from the external metrics provider / watermark (niedrig oder hoch, je nach aktuellem Wert).
Der average Algorithmus eignet sich gut, wenn Sie eine Metrik verwenden, die nicht von der Anzahl der Replikate abhängt. Typischerweise kann die Anzahl der von einem ELB empfangenen Anfragen Aufschluss darüber geben, wie viele Webserver wir haben möchten, vorausgesetzt, wir wissen, dass ein einzelner Webserver n RQ/s verarbeiten sollte. Durch das Hinzufügen eines Replikats wird die Anzahl der vom Load Balancer empfangenen Anforderungen weder erhöht noch verringert.
absolute Der Standardwert ist absolute . Es sollte eine durchschnittliche Metrik verwendet werden. Die empfohlene Anzahl von Replikaten wird als current number of replicas * value from the external metrics provider / watermark berechnet.
Der absolute Algorithmus ist der Standardwert, da er den häufigsten Anwendungsfall darstellt. Wenn Sie beispielsweise möchten, dass Ihre Anwendung zwischen 60 % und 80 % der CPU ausgeführt wird und avg:cpu.usage bei 85 % liegt, müssen Sie eine Skalierung durchführen. Die Metrik muss mit der Anzahl der Replikate korreliert werden.
Hinweis : Im Upstream-Controller wird nur die Funktion math.Ceil verwendet, um die empfohlene Anzahl von Replikaten aufzurunden.
Das heißt, wenn Sie einen Schwellenwert von 10 haben, müssen Sie eine Auslastung von 8,999 erreichen … vom externen Metrikanbieter, um eine Herunterskalierung um ein Replikat vorzunehmen. Eine Auslastung von 10.001 führt jedoch zu einer Skalierung um ein Replikat.
Der WPA-Controller verwendet math.Floor , wenn der Wert unter dem unteren Wasserzeichen liegt. Dadurch ist ein symmetrisches Verhalten gewährleistet. In Kombination mit anderen Skalierungsoptionen ermöglicht dies eine genauere Kontrolle darüber, wann herunterskaliert werden soll.
Um den Watermark Pod Autoscaler zu verwenden, stellen Sie ihn in Ihrem Kubernetes-Cluster bereit:
Laden Sie die ZIP-Datei des Watermark Pod Autoscaler-Projekts herunter. Den Quellcode finden Sie unter DataDog/watermarkpodautoscaler .
Entpacken Sie das Projekt und gehen Sie in den Ordner ./watermarkpodautoscaler .
Definieren Sie Ihren Namespace und den Watermark Pod Autoscaler-Controller:
DD_NAMESPACE= " datadog "
DD_NAMEWPA= " wpacontroller "Erstellen Sie den Namensraum:
kubectl create ns $DD_NAMESPACEInstallieren Sie den Watermark Pod Autoscaler-Controller mit Helm:
helm install $DD_NAMEWPA -n $DD_NAMESPACE ./chart/watermarkpodautoscalerDer WatermarkPodAutoscaler Controler wird mit einem kubectl-Plugin geliefert, das eine Reihe von Hilfsprogrammen bereitstellt. Weitere Informationen finden Sie auf der speziellen Dokumentationsseite: docs/kubectl-plugin.md
Erstellen Sie Ihr WPA im selben Namespace wie Ihre Zielbereitstellung.
Der Datadog Cluster Agent übernimmt das Erstellungs-/Aktualisierungs-/Löschereignis. Es analysiert die WPA-Spezifikation, um die Metrik und den Umfang zu extrahieren, die von Datadog abgerufen werden sollen.
In diesem Beispiel verwenden wir die folgende Spezifikationskonfiguration:
apiVersion : datadoghq.com/v1alpha1
kind : WatermarkPodAutoscaler
metadata :
name : example-watermarkpodautoscaler
spec :
downscaleForbiddenWindowSeconds : 60
downscaleDelayBelowWatermarkSeconds : 300
upscaleForbiddenWindowSeconds : 30
upscaleDelayAboveWatermarkSeconds : 30
scaleDownLimitFactor : 30
scaleUpLimitFactor : 50
minReplicas : 4
maxReplicas : 9
scaleTargetRef :
kind : " Deployment "
name : " some_app "
apiVersion : " apps/v1 "
metrics :
- external :
highWatermark : 400m
lowWatermark : 150m
metricName : custom.request_duration.max
metricSelector :
matchLabels :
kubernetes_cluster : mycluster
service : billing
short_image : billing-app
type : External
tolerance : " 0.01 " Sowohl der External als auch der Resource werden unterstützt. Der WPA-Controller verwendet dasselbe Format wie der HPA. Weitere Informationen hier.
Beginnend mit den Wasserzeichen weist der Wert der von Datadog gesammelten Metrik ( watermarkpodautoscaler.wpa_controller_value ) in Lila, wenn er zwischen den Grenzen ( watermarkpodautoscaler.wpa_controller_low_watermark und watermarkpodautoscaler.wpa_controller_high_watermark ) liegt, den Controller an, kein Skalierungsereignis auszulösen. Sie werden als Quantities angegeben, sodass Sie m | "" | k | M | G | T | P | E verwenden können m | "" | k | M | G | T | P | E um den Wert, den Sie verwenden möchten, einfach darzustellen.
Wir können die Metrik watermarkpodautoscaler.wpa_controller_restricted_scaling{reason:within_bounds} verwenden, um zu überprüfen, ob sie tatsächlich eingeschränkt ist. Hinweis : Die Metrik wurde mit 1000 multipliziert, um deutlicher zu machen, dass während dieser Zeit kein Skalierungsereignis vom Controller ausgelöst werden konnte.
Der zweite Satz von Konfigurationsoptionen betrifft die Skalierungsgeschwindigkeit Ihrer Bereitstellung, gesteuert durch scaleDownLimitFactor und scaleUpLimitFactor . Dabei handelt es sich um ganze Zahlen zwischen 0 und 100. Sie stellen das maximale Verhältnis der jeweiligen Verkleinerung bzw. Vergrößerung angesichts der aktuellen Anzahl von Replikaten dar.
Sollten wir in diesem Fall 10 Replikate und eine empfohlene Anzahl von Replikaten von 14 haben (weitere Einzelheiten zur Empfehlung finden Sie im Abschnitt „Algorithmus“) mit einem scaleUpFactor von 30 (%), wären wir auf 13 Replikate begrenzt.
In der folgenden Grafik können wir sehen, dass die vorgeschlagene Anzahl von Replikaten (in Lila), dargestellt durch die Metrik watermarkpodautoscaler.wpa_controller_replicas_scaling_proposal im Vergleich zur aktuellen Anzahl von Replikaten zu hoch ist. Dadurch wird die Upscale-Capping-Logik ausgelöst, die mithilfe der Metrik watermarkpodautoscaler.wpa_controller_restricted_scaling{reason:upscale_capping} überwacht werden kann ( Hinweis : Wie oben wurde die Metrik multipliziert, um sie expliziter zu machen). Somit wird die effektive Anzahl der Replikate „ watermarkpodautoscaler.wpa_controller_replicas_scaling_effective skaliert, jedoch entsprechend dem scaleUpLimitFactor .
In diesem ähnlichen Beispiel vermeiden wir ein zu starkes Herunterskalieren und können denselben Satz von Metriken verwenden, um sicherzustellen, dass wir nur um eine angemessene Anzahl von Replikaten herunterskalieren.
Es ist wichtig zu beachten, dass wir immer konservative Skalierungsentscheidungen treffen.
scaleUpLimitFactor von 29 %: Wenn wir 10 Replikate haben und 13 empfohlen werden, werden wir auf 12 hochskalieren.scaleDownLimitFactor von 29 %: Wenn wir 10 Replikate haben und 7 empfohlen werden, skalieren wir auf 8 herunter.minReplicas und maxReplicas Vorrang haben. Weitere Informationen finden Sie im Abschnitt „Vorrang“. Schließlich sind die letzten verfügbaren Optionen downscaleForbiddenWindowSeconds und upscaleForbiddenWindowSeconds . Diese geben an, wie viel Zeit (in Sekunden) nach einem Skalierungsereignis gewartet werden muss, bevor die Skalierung verkleinert bzw. vergrößert wird. Wir behalten nur das letzte Skalierungsereignis bei und vergleichen die upscaleForbiddenWindowSeconds nicht mit dem letzten Mal, als wir nur hochskaliert haben.
Im folgenden Beispiel können wir sehen, dass die empfohlene Anzahl an Replikaten ignoriert wird, wenn wir uns in einer Abklingzeit befinden. Die Abklingzeit beim Herunterskalieren kann mit watermarkpodautoscaler.wpa_controller_transition_countdown{transition:downscale} visualisiert werden und wird in der folgenden Grafik gelb dargestellt. Wir können sehen, dass sie deutlich höher ist als die Abklingzeit für die Hochskalierung ( transition:upscale ) in Orange in unserem Diagramm. Sobald uns eine Skalierung empfohlen wird, skalieren wir nur, wenn das entsprechende Abklingzeitfenster abgelaufen ist. Dadurch werden beide Countdowns zurückgesetzt.
Um eine Skalierung durch Bursts zu vermeiden, können Sie die folgenden Funktionen verwenden: downscaleDelayBelowWatermarkSeconds und/oder upscaleDelayAboveWatermarkSeconds . Diese Optionen werden als Ganzzahlen angegeben. Die Metrik(en) müssen für die konfigurierte Dauer über oder unter ihrem jeweiligen Wasserzeichen bleiben. Sie können im Status des WPA verfolgen, wie viel Zeit noch übrig ist:
- lastTransitionTime: "2022-11-15T02:02:09Z"
message: Allow downscaling if the value stays under the Watermark
reason: Value below Low Watermark
status: "False"
type: BelowLowWatermark
Oder in den Protokollen des Controllers:
{"level":"info","ts":1668481092517.446,"logger":"controllers.WatermarkPodAutoscaler","msg":"Will not scale: value has not been out of bounds for long enough","watermarkpodautoscaler":"datadog/example-watermarkpodautoscaler","wpa_name":"example-watermarkpodautoscaler","wpa_namespace":"datadog","time_left":3209}
Hinweis: Wenn Sie mit dieser Funktion mehrere Metriken verwenden, wird die Oben-/Unten-Bedingung mithilfe des OR der Metriken berücksichtigt.
Angenommen, Sie haben ein upscaleDelay von 60 Sekunden mit zwei Metriken, M1 und M2. Wenn M1 40 Sekunden lang über seiner oberen Wassermarke bleibt [t0; t40] und der M2 überschreitet 30 Sekunden lang seine Obergrenze und überschneidet sich während der letzten 10 Sekunden mit M1, [t30; t60] , dies validiert die upscaleDelay -Bedingung und ermöglicht ein Upscaling-Ereignis.
Wenn wir den Wert der externen Metrik abrufen, vergleichen wir ihn zunächst mit der Summe highWatermark + tolerance und mit der Differenz lowWatermark - tolerance . Wenn wir außerhalb der Grenzen liegen, berechnen wir die empfohlene Anzahl an Replikaten. Anschließend vergleichen wir diesen Wert mit der aktuellen Anzahl von Replikaten, um möglicherweise die empfohlene Anzahl von Replikaten auch gemäß minReplicas und maxReplicas zu begrenzen. Abschließend prüfen wir, ob wir angesichts der downscaleForbiddenWindowSeconds und upscaleForbiddenWindowSeconds skalieren dürfen.
Um eine detailliertere Kontrolle über die Bedingungen zu haben, unter denen ein Ziel skaliert werden kann, können Sie die folgenden Funktionen verwenden:
minAvailableReplicaPercentage : Gibt den Mindestprozentsatz an Replikaten an, die verfügbar sein müssen, damit der Controller das Ziel automatisch skaliert. Wenn der Wert beispielsweise auf 50 eingestellt ist und sich weniger als die Hälfte der Pods hinter dem Ziel im Status „Verfügbar“ befinden, wird das Ziel vom Controller nicht skaliert.
readinessDelaySeconds : Gibt an, wie lange Replikate ausgeführt werden müssen, bevor sie bei den Skalierungsentscheidungen berücksichtigt werden.
Wenn alle Bedingungen erfüllt sind, skaliert der Controller das Zielobjekt in scaleTargetRef nur dann auf die empfohlene Anzahl von Replikaten, wenn das dryRun -Flag nicht auf true gesetzt ist. Dies wird durch die Protokollierung angezeigt:
{ "level" : " info " , "ts" : 1566327479.866722 , "logger" : " wpa_controller " , "msg" : " DryRun mode: scaling change was inhibited currentReplicas:8 desiredReplicas:12 " }Der Cluster-Agent führt einen Informer für die WPA-Ressourcen aus und analysiert ähnlich wie der HPA beim Erstellen/Aktualisieren/Löschen die Spezifikation, um die Metrik von Datadog abzufragen.
Der Cluster-Agent führt den WPA-Listener nicht standardmäßig aus. Um WPA im Cluster Agent zu aktivieren, legen Sie die Umgebungsvariable DD_EXTERNAL_METRICS_PROVIDER_WPA_CONTROLLER=true fest und aktualisieren Sie die ClusterRole, die dem Cluster Agent-Dienstkonto zugewiesen ist, um Zugriff auf WatermarkPodAutoscaler-Objekte zu haben:
[...]
- apiGroups : ["datadoghq.com"]
resources :
- watermarkpodautoscalers
verbs :
- get
- list
- watch
[...] Hinweis: Um WPA im Cluster Agent mithilfe des Datadog-Helmdiagramms zu aktivieren, setzen Sie clusterAgent.metricsProvider.wpaController auf true . Die ClusterRole wird automatisch aktualisiert.
Sobald Sie diese Änderungen angewendet und ein WPA-Objekt erstellt haben, können Sie, wenn Sie im Datadog-Cluster-Agent-Pod ausführen und agent status ausführen, genauere Details zu den Spezifikationen der analysierten Autoskalierer sehen (unabhängig davon, ob es sich um einen horizontalen oder einen horizontalen Skalierer handelt). Wasserzeichen-Pod-Autoskalierung).
* watermark pod autoscaler: default/example2-watermarkpodautoscaler
- name : example2-watermarkpodautoscaler
- namespace : default
- type : watermark
- uid : ff09b7d8-d99b-11e9-a8c1-42010a8001c4
Metric name : sinus
Labels :
- foo : bar
Value : 75.1297378540039
Timestamp : 15688259400
Valid : true
* horizontal pod autoscaler: default/nginxext
- name : nginxext
- namespace : default
- type : horizontal
- uid : 61ef3f6e-af32-11e9-a8c1-42010a8001c4
Metric name : docker.mem.rss
Labels :
- cluster-location : us-central1-a
- cluster-name : charly
Value : 263888700952
Timestamp : 15688259400
Valid : trueZusätzlich zu den oben genannten Metriken handelt es sich hierbei um Protokolle, die Ihnen helfen, die ordnungsgemäße Funktionsweise des WPA besser zu verstehen.
Alle 15 Sekunden rufen wir die im Abschnitt metrics der Spezifikation aufgeführte Metrik von Datadog ab.
{ "level" : " info " , "ts" : 1668484420515.7678 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Metrics from the External Metrics Provider " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "metrics" :[ 33959 ]}
{ "level" : " info " , "ts" : 1668484420515.8203 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Value is below lowMark " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "usage" : " 33959m " , "replicaCount" : 7 , "currentReadyReplicas" : 8 , "tolerance (%)" : 1 , "adjustedLM" : 34650 , "adjustedUsage" : 33959 }
{ "level" : " info " , "ts" : 1668484420515.8906 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Proposing replicas " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "proposedReplicas" : 7 , "metricName" : " datadogmetric@datadog:example-watermarkpodautoscaler-utilization-metric{map[kube_container_name:my-container service:my-target]} " , "reference" : " Deployment/datadog/example-watermarkpodautoscaler " , "metric timestamp" : " Tue, 15 Nov 2022 03:53:20 UTC " }
{ "level" : " info " , "ts" : 1668484420515.9324 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Normalized Desired replicas " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "desiredReplicas" : 7 }
{ "level" : " info " , "ts" : 1668484420515.946 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Cooldown status " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "backoffUp" : false , "backoffDown" : false , "desiredReplicas" : 7 , "currentReplicas" : 8 }
{ "level" : " info " , "ts" : 1668484420515.9563 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Will not scale: value has not been out of bounds for long enough " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "time_left" : 2335 }Hier beträgt die aktuelle Anzahl der in der Zielbereitstellung angezeigten Replikate sechs. Anschließend sehen wir den vom externen Metrikanbieter abgerufenen Rohwert und vergleichen ihn mit den oberen und unteren Wasserzeichen. Aufgrund des Ergebnisses dieses Vergleichs drucken wir die empfohlene Anzahl an Replikaten. In diesem Fall sind es fünf.
Wenn Sie den External Metrics Provider direkt abfragen möchten, können Sie den folgenden Befehl verwenden:
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces// | jq ."
Sie können optional auch Beschriftungsselektoren hinzufügen, indem Sie ?labelSelector=key%3Dvalue hinzufügen. Wenn wir in diesem Fall unsere Metrik abrufen wollten, könnten wir Folgendes verwenden:
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces// | jq .?labelSelector=key%3Dvalue%2Cotherkey%3Dothervalue%2Cshort_image%3Dimage "
Wenn Sie Protokolle sehen wie:
{ "level" : " info " , "ts" : 1566397216.8918724 , "logger" : " wpa_controller " , "msg" : " failed to compute desired number of replicas based on listed metrics for Deployment/datadog/propjoe-green: failed to get external metric dd.propjoe.request_duration.max: unable to get external metric datadog/propjoe-green/&LabelSelector{MatchLabels:map[string]string{fooa: bar,},MatchExpressions:[],}: no metrics returned from external metrics API " }Dann können Sie überprüfen, ob diese Metrik tatsächlich nicht vom externen Metrikanbieter verfügbar ist. Dies kann an einem Tippfehler in den Beschriftungen liegen oder die Metrik kann nicht von Datadog abgerufen werden (was an verschiedenen Faktoren liegen kann: zu spärlich, API-Down, Ratenlimit-Treffer usw.). Sie können die Protokolle des externen Metrikanbieters zur weiteren Untersuchung durchsehen.
Anschließend überprüfen wir die Skalierungsgeschwindigkeitsbegrenzung und die Abklingzeitfenster. Im Falle einer Skalierungsbegrenzung würden Sie etwa Folgendes sehen:
{ "level" : " info " , "ts" : 1566327268.8839815 , "logger" : " wpa_controller " , "msg" : " Upscaling rate higher than limit of 50.0% up to 9 replicas. Capping the maximum upscale to 9 replicas " }
{ "level" : " info " , "ts" : 1566327268.884001 , "logger" : " wpa_controller " , "msg" : " Returning 9 replicas, condition: ScaleUpLimit reason the desired replica count is increasing faster than the maximum scale rate " }
{ "level" : " info " , "ts" : 1566327479.8845513 , "logger" : " wpa_controller " , "msg" : " -> after normalization: 9 " }Dann berücksichtigen wir die Abklingzeiten. Sie verfügen über Protokolle, aus denen hervorgeht, wann das letzte Skalierungsereignis stattgefunden hat und wann die nächsten Hochskalierungs- und Herunterskalierungsereignisse verboten sind, bis:
{ "level" : " info " , "ts" : 1566327479.8845847 , "logger" : " wpa_controller " , "msg" : " Too early to downscale. Last scale was at 2019-08-20 18:57:44 +0000 UTC, next downscale will be at 2019-08-20 18:58:44 +0000 UTC, last metrics timestamp: 2019-08-20 18:57:59 +0000 UTC " }
{ "level" : " info " , "ts" : 1566327479.8846018 , "logger" : " wpa_controller " , "msg" : " Too early to upscale. Last scale was at 2019-08-20 18:57:44 +0000 UTC, next upscale will be at 2019-08-20 18:58:14 +0000 UTC, last metrics timestamp: 2019-08-20 18:57:59 +0000 UTC " }
{ "level" : " info " , "ts" : 1566327479.884608 , "logger" : " wpa_controller " , "msg" : " backoffUp: true, backoffDown: true, desiredReplicas 5, currentReplicas: 6 " }Schließlich haben wir überprüft, ob die Bereitstellung korrekt automatisch skaliert wurde:
{ "level" : " info " , "ts" : 1566327253.7887673 , "logger" : " wpa_controller " , "msg" : " Successful rescale of watermarkpodautoscaler, old size: 8, new size: 9, reason: cutom_metric.max{map[kubernetes_cluster:my-cluster service:my-service short_image:my-image]} above target " }wpa.datadoghq.com/logs-attributes verwenden, um zusätzliche Schlüsselwerte in den Protokollen hinzuzufügen, die mit dem zugrunde liegenden WPA-Objekt verknüpft sind. Beispiel: apiVersion: datadoghq.com/v1alpha1
kind: WatermarkPodAutoscaler
metadata:
annotations:
wpa.datadoghq.com/logs-attributes: '{"mywpa": "isgreat"}'
name: watermarkpodautoscaler-sinus
namespace: default
[...]
Wird ergeben:
{"level":"info","ts":1643642642091.062,"logger":"controllers.WatermarkPodAutoscaler","msg":"getReadyPodsCount","watermarkpodautoscaler":"default/watermarkpodautoscaler-sinus","mywpa":"isgreat","full podList length":2,"toleratedAsReadyPodCount":2,"incorrectly targeted pods":0}
Was passiert, wenn ich meine Bereitstellung manuell skaliere?
In der nächsten Abgleichsschleife wird die neue Anzahl von Replikaten berücksichtigt, um die gewünschte Anzahl von Replikaten zu berechnen. Möglicherweise sehen Sie ein Protokoll, das besagt, dass die Ressource von jemand anderem geändert wurde. Wenn die Anzahl der konfigurierten Replikate jedoch außerhalb der Grenzen liegt, skaliert der Controller diese auf eine Anzahl von Replikaten innerhalb des akzeptablen Bereichs zurück.
Wie kann ich WPA vorübergehend deaktivieren, um meine Bereitstellung manuell nach oben/unten zu skalieren?
Die empfohlene Methode besteht darin, den WPA in den Probelaufmodus zu versetzen und dann auf die gewünschte Anzahl von Replikaten zu skalieren. Mit diesem Patch-Befehl können Sie die WPA im Probelauf einstellen:
kubectl patch wpa --type='json' -p='[{"op": "replace", "path": "/spec/dryRun", "value":true}]'
Vergessen Sie nicht, den Probelaufmodus nach Ablauf Ihrer vorübergehenden Außerkraftsetzung wieder auf false zurückzusetzen, damit die WPA wieder aktiv ist.
Wie groß ist der Platzbedarf des Controllers?
Unseren Tests zufolge ist dies ein Faktor für die Anzahl der Bereitstellungen im Cluster.
Ist der Controller zustandslos?
Ja.
Unterstützt WPA mehrere Metriken?
Ja, WPA kann auf mehreren Metriken skaliert werden und funktioniert ähnlich wie HPA. WPA wertet jede Metrik separat aus und schlägt die Anzahl der Replikate vor, die der Metrik zugeordnet sind, die die größte Anzahl erfordert. Wenn WPA beispielsweise Metrik1, Metrik2 und Metrik3 auswertet und für jede davon 10, 20 bzw. 30 Replikatvorschläge berechnet, beträgt der endgültige Vorschlag 30.
Da wir alle WPA-Definitionen im gesamten Cluster überwachen, verwenden wir eine Clusterrolle.
Eine nützliche Option besteht darin, sich als Benutzer auszugeben, um die Rechte zu überprüfen. Um beispielsweise zu überprüfen, ob Sie das Recht haben, eine Bereitstellung als Dienstkonto des WPA-Controllers zu erhalten:
kubectl get deploy < your_deploy > --as system:serviceaccount:datadog:watermarkpodautoscaler -n < your_ns >Oder fragen Sie den externen Metrikanbieter ab:
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces//metric --as system:serviceaccount::watermarkpodautoscaler Anforderungen:
Legen Sie nach dem Klonen des Repositorys https://github.com/DataDog/watermarkpodautoscaler einige Umgebungsvariablen fest:
export GO111MODULE=on
unset GOPATH
export PATH= $PATH : $( pwd ) /bin Führen Sie dann make install-tools aus, um einige Tool-Abhängigkeiten zu installieren.
make install-tools : Installieren Sie die Tools, um das Operator-SDK zu verwenden.make build : Den Controller lokal erstellen.make generate : Führen Sie den SDK-Generator für mehrere Operatoren aus, der Code für den Controller und die Registrierung des Informanten generiert.make test : Unit-Tests ausführen.make validate : Führen Sie gängige Golang-Linters ( golangci-lint ) aus.make e2e : Führen Sie End-to-End-Tests auf dem aktuell konfigurierten Kubernetes-Cluster aus.make container : Erstellen Sie das Controller-Docker-Image mit dem Operator-SDK.make container-ci : Erstellen Sie das Controller-Docker-Image mit der mehrstufigen Docker-Datei.Die Dokumentation zum Freigabeprozess finden Sie hier.
Einige der Funktionen wurden vom konfigurierbaren HPA oder CHPA inspiriert. Der größte Teil der Codestruktur wurde auch für den Watermark Pod Autoscaler verwendet, obwohl die gesamte Verpackung des CRD mit dem Operator SDK erfolgte.
