Horizontales Pod-Autoscaling konfigurieren

Auf dieser Seite wird beschrieben, wie Sie Ihre Bereitstellungen in Google Kubernetes Engine (GKE) skalieren, indem Sie Ihre Ressourcen automatisch anhand von Messwerten wie Ressourcenzuweisung, Load-Balancer-Traffic, benutzerdefinierten Messwerten oder mehreren Messwerten gleichzeitig anpassen. Auf dieser Seite finden Sie auch eine Schritt-für-Schritt-Anleitung zum Konfigurieren eines HPA-Profils (Horizontal Pod Autoscaler), einschließlich Informationen zum Ansehen, Löschen, Bereinigen und Beheben von Problemen mit Ihrem HPA-Objekt. Ein Deployment ist ein Kubernetes-API-Objekt, mit dem Sie mehrere Replikate von Pods ausführen können, die auf die Knoten in einem Cluster verteilt sind.

Diese Seite richtet sich an Operatoren und Entwickler, die die Anwendungsskalierung in GKE verwalten und wissen möchten, wie sie die Leistung durch horizontales Pod-Autoscaling dynamisch optimieren und die Kosteneffizienz aufrechterhalten können. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die in Google Cloud-Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
  • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

API-Versionen für HorizontalPodAutoscaler-Objekte

Wenn Sie die Google Cloud -Konsole verwenden, werden HorizontalPodAutoscaler-Objekte mit der autoscaling/v2 API erstellt.

Wenn Sie kubectl zum Erstellen oder Anzeigen von Informationen zu einem horizontalen Pod-Autoscaling verwenden, können Sie entweder die autoscaling/v1 API oder die autoscaling/v2 API angeben.

  • apiVersion: autoscaling/v1 ist die Standardeinstellung und ermöglicht Ihnen das Autoscaling ausschließlich auf Grundlage der CPU-Auslastung. Für das Autoscaling anhand anderer Messwerte wird die Verwendung von apiVersion: autoscaling/v2 empfohlen. Im Beispiel unter Beispiel-Deployment erstellen wird apiVersion: autoscaling/v1 verwendet.

  • Zum Erstellen neuer HorizontalPodAutoscaler-Objekte wird apiVersion: autoscaling/v2 empfohlen. Es ermöglicht das Autoscaling basierend auf mehreren Messwerten, einschließlich benutzerdefinierter oder externer Messwerte. Für alle anderen Beispiele auf dieser Seite wird apiVersion: autoscaling/v2 verwendet.

Welche API-Versionen unterstützt werden, erfahren Sie durch Verwendung des Befehls kubectl api-versions.

Beim Aufrufen der Details zu einem horizontalen Pod-Autoscaling mit apiVersion: autoscaling/v2 können Sie angeben, welche API verwendet werden soll.

Beispiel-Deployment erstellen

Bevor Sie ein horizontales Pod-Autoscaling erstellen, müssen Sie die zu überwachende Arbeitslast einrichten. In den Beispielen auf dieser Seite werden unterschiedliche Konfigurationen des horizontalen Pod-Autoscalings auf das folgende nginx-Deployment angewendet. Die separaten Beispiele zeigen ein horizontales Pod-Autoscaling, das auf der Ressourcennutzung, auf einem benutzerdefinierten oder externen Messwert und auf mehreren Messwerten basiert

Speichern Sie Folgendes in einer Datei mit dem Namen nginx.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
        resources:
          # You must specify requests for CPU to autoscale
          # based on CPU utilization
          requests:
            cpu: "250m"

Dieses Manifest gibt einen Wert für CPU-Anfragen an. Wenn Sie ein prozentuales Autoscaling basierend auf der Auslastung einer Ressource durchführen möchten, müssen Sie Anforderungen für diese Ressource angeben. Wenn Sie keine Anforderungen angeben, kann das Autoscaling nur basierend auf dem absoluten Wert der Ressourcenauslastung erfolgen, z. B. basierend auf MilliCPUs für die CPU-Auslastung.

Zum Erstellen des Deployments wenden Sie das Manifest nginx.yaml an:

kubectl apply -f nginx.yaml

Für das Deployment wurde spec.replicas auf 3 festgelegt, sodass drei Pods bereitgestellt werden. Sie können dies mit dem Befehl kubectl get deployment nginx prüfen.

In jedem der Beispiele auf dieser Seite wird ein anderes horizontales Pod-Autoscaling auf ein Beispiel-nginx-Deployment angewendet.

Autoscaling auf Basis der Ressourcennutzung

In diesem Beispiel wird ein HorizontalPodAutoscaler-Objekt erstellt, um das nginx-Deployment automatisch zu skalieren, wenn die CPU-Auslastung 50 % überschreitet. Damit wird auch dafür gesorgt, dass immer mindestens ein Replikat und maximal zehn Replikate vorhanden sind.

Sie können mit der Google Cloud Console oder dem Befehl kubectl apply ein horizontales Pod-Autoscaling erstellen, das auf die CPU-Auslastung abzielt, oder den Befehl kubectl autoscale verwenden, wenn es nur um die durchschnittliche CPU-Auslastung geht.

Console

  1. Rufen Sie in der Google Cloud -Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Klicken Sie auf den Namen des nginx-Deployments.

  3. Klicken Sie auf Aktionen > Autoscaling.

  4. Geben Sie die folgenden Werte an:

    • Mindestanzahl an Replikaten: 1
    • Maximale Anzahl von Replikaten: 10
    • Autoscaling-Messwert: CPU
    • Ziel: 50
    • Einheit: %
  5. Klicken Sie auf Fertig.

  6. Klicken Sie auf Automatisch skalieren.

kubectl apply

Speichern Sie dieses YAML-Manifest als Datei mit dem Namen nginx-hpa.yaml:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  # Set the minimum and maximum number of replicas the Deployment can scale to.
  minReplicas: 1
  maxReplicas: 10
  # The target average CPU utilization percentage across all Pods.
  targetCPUUtilizationPercentage: 50

Verwenden Sie das Manifest mit dem folgenden Befehl, um das HPA zu erstellen:

kubectl apply -f nginx-hpa.yaml

kubectl autoscale

Sie können mit dem Befehl kubectl autoscale ein HorizontalPodAutoscaler-Objekt erstellen, das nur auf die durchschnittliche CPU-Auslastung ausgerichtet ist:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Mit dem folgenden Befehl rufen Sie eine Liste der horizontalen Pod-Autoscalings im Cluster ab:

kubectl get hpa

Die Ausgabe sieht etwa so aus:

NAME    REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
nginx   Deployment/nginx   0%/50%    1         10        3          61s

Details zum horizontalen Pod-Autoscaling erhalten Sie über die Google Cloud Console oder mit dem Befehl kubectl.

Console

  1. Rufen Sie in der Google Cloud -Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Klicken Sie auf den Namen des nginx-Deployments.

  3. Sehen Sie sich die Konfiguration für das horizontale Pod-Autoscaling im Abschnitt Autoscaling an.

  4. Weitere Details zu Autoscaling-Ereignissen finden Sie im Tab Ereignisse.

kubectl get

Um Details zum horizontalen Pod-Autoscaling zu erhalten, können Sie kubectl get hpa mit dem Flag -o yaml verwenden. Das Feld status enthält Informationen zur aktuellen Anzahl von Replikaten und zu allen aktuellen Autoscaling-Ereignissen.

kubectl get hpa nginx -o yaml

Die Ausgabe sieht in etwa so aus:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  annotations:
    autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ScaleDownStabilized","message":"recent
      recommendations were higher than current one, applying the highest recent recommendation"},{"type":"ScalingActive","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ValidMetricFound","message":"the
      HPA was able to successfully calculate a replica count from cpu resource utilization
      (percentage of request)"},{"type":"ScalingLimited","status":"False","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"DesiredWithinRange","message":"the
      desired count is within the acceptable range"}]'
    autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":"Resource","resource":{"name":"cpu","currentAverageUtilization":0,"currentAverageValue":"0"}}]'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"},"targetCPUUtilizationPercentage":50}}
  creationTimestamp: "2019-10-30T19:42:43Z"
  name: nginx
  namespace: default
  resourceVersion: "220050"
  selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/nginx
  uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  targetCPUUtilizationPercentage: 50
status:
  currentCPUUtilizationPercentage: 0
  currentReplicas: 3
  desiredReplicas: 3

Löschen Sie das HPA, bevor Sie mit den restlichen Beispielen auf dieser Seite fortfahren:

kubectl delete hpa nginx

Wenn Sie ein horizontales Pod-Autoscaling löschen, bleibt die Anzahl der Replikate des Deployments erhalten. Der Zustand eines Deployments vor der Anwendung des horizontalen Pod-Autoscalings wird nicht automatisch wiederhergestellt.

Weitere Informationen finden Sie unter Horizontales Pod-Autoscaling löschen.

Autoscaling auf Basis des Load-Balancer-Traffics

Traffic-basiertes Autoscaling ist eine Funktion von GKE, die Signale zur Traffic-Auslastung von Load-Balancern in Autoscaling-Pods integriert.

Die Verwendung von Traffic als Autoscaling-Signal kann nützlich sein, da der Traffic ein führender Indikator für die Last ist, der CPU und Arbeitsspeicher ergänzt. Durch die Einbindung in GKE wird sichergestellt, dass die Einrichtung einfach ist und dass das Autoscaling schnell auf Traffic-Spitzen reagiert, um den Bedarf zu decken.

Traffic-basiertes Autoscaling wird vom Gateway-Controller und dessen globalen Traffic-Verwaltungsfunktionen ermöglicht. Weitere Informationen finden Sie unter Traffic-basiertes Autoscaling.

Das auf dem Load-Balancer-Traffic basierende Autoscaling ist nur für Gateway-Arbeitslasten verfügbar.

Voraussetzungen

Für das traffic-basierte Autoscaling gelten folgende Anforderungen:

  • Unterstützt ab GKE-Version 1.31.
  • Die Gateway API ist in Ihrem GKE-Cluster aktiviert.
  • Unterstützt für Traffic, der über Load-Balancer geleitet wird, die mit der Gateway API und entweder der GatewayClass gke-l7-global-external-managed, gke-l7-regional-external-managed, gke-l7-rilb oder gke-l7-gxlb bereitgestellt werden.

Beschränkungen

Für das traffic-basierte Autoscaling gelten folgende Anforderungen:

  • Nicht unterstützt von den Multi-Cluster-GatewayClasses (gke-l7-global-external-managed-mc, gke-l7-regional-external-managed-mc, gke-l7-rilb-mc und gke-l7-gxlb-mc).
  • Nicht unterstützt für Traffic mit Services vom Typ LoadBalancer.
  • Es muss eine klare und isolierte Beziehung zwischen den Komponenten bestehen, die am verkehrsbasierten Autoscaling beteiligt sind. Ein horizontales Pod-Autoscaling muss für die Skalierung eines einzelnen Deployments (oder einer beliebigen skalierbaren Ressource) vorgesehen sein, das von einem einzelnen Service bereitgestellt wird.
  • Nachdem Sie die Kapazität Ihres Dienstes mit dem Feld maxRatePerEndpoint konfiguriert haben, warten Sie ausreichend lange (normalerweise eine Minute, in großen Clustern möglicherweise bis zu 15 Minuten), bis der Load Balancer mit dieser Änderung aktualisiert wurde, bevor Sie das horizontale Pod-Autoscaling mit verkehrsbasierten Messwerten konfigurieren. So wird verhindert, dass Ihr Dienst vorübergehend in eine Situation gerät, in der Ihr Cluster versucht, das Autoscaling auf der Grundlage von Messwerten durchzuführen, die von einem Load-Balancer ausgegeben werden, der sich noch in der Konfiguration befindet.
  • Wenn das traffic-basierte Autoscaling für einen Service verwendet wird, der von mehreren Load Balancern bereitgestellt wird (z. B. von einem Ingress und einem Gateway oder von zwei Gateways), berücksichtigt das horizontale Pod-Autoscaling möglicherweise den höchsten Traffic-Wert der einzelnen Load Balancer, um Skalierungsentscheidungen zu treffen, anstatt die Summe der Traffic-Werte aller Load Balancer.

Traffic-basiertes Autoscaling bereitstellen

In der folgenden Übung wird der HorizontalPodAutoscaler verwendet, um das store-autoscale-Deployment anhand des empfangenen Traffics automatisch zu skalieren. Ein Gateway akzeptiert eingehenden Traffic aus dem Internet für die Pods. Das Autoscaling vergleicht die Traffic-Signale vom Gateway mit der Traffic-Kapazität pro Pod, die für die store-autoscale-Service-Ressource konfiguriert ist. Durch das Generieren von Traffic zum Gateway beeinflussen Sie die Anzahl der bereitgestellten Pods.

Das folgende Diagramm zeigt, wie das traffic-basierte Autoscaling funktioniert:

HorizontalPodAutoscaler, der ein Deployment basierend auf dem Traffic skaliert.

Führen Sie die folgenden Schritte aus, um traffic-basiertes Autoscaling bereitzustellen:

  1. Prüfen Sie bei Standardclustern, ob die GatewayClasses in Ihrem Cluster installiert sind. Für Autopilot-Cluster werden die GatewayClasses standardmäßig installiert.

    kubectl get gatewayclass
    

    Die Ausgabe bestätigt, dass die GKE-GatewayClass-Ressourcen in Ihrem Cluster verwendet werden können:

    NAME                               CONTROLLER                  ACCEPTED   AGE
    gke-l7-global-external-managed     networking.gke.io/gateway   True       16h
    gke-l7-regional-external-managed   networking.gke.io/gateway   True       16h
    gke-l7-gxlb                        networking.gke.io/gateway   True       16h
    gke-l7-rilb                        networking.gke.io/gateway   True       16h
    

    Wenn diese Ausgabe nicht angezeigt wird, aktivieren Sie die Gateway API in Ihrem GKE-Cluster.

  2. Stellen Sie die Beispielanwendung und den Gateway-Load-Balancer in Ihrem Cluster bereit:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yaml
    

    Die Beispielanwendung erstellt Folgendes:

    • Ein Deployment mit zwei Replikaten.
    • Ein Dienst mit der zugehörigen Einstellung GCPBackendPolicy maxRatePerEndpoint, die auf 10 festgelegt ist. Weitere Informationen zu Gateway-Funktionen finden Sie unter GatewayClass-Funktionen.
    • Ein externes Gateway für den Zugriff auf die Anwendung im Internet. Weitere Informationen zur Verwendung von Gateway-Load-Balancern finden Sie unter Gateways bereitstellen.
    • Eine HTTPRoute, die dem gesamten Traffic entspricht und ihn an den store-autoscale-Service sendet.

    Die Service-Kapazität ist bei der Verwendung des traffic-basierten Autoscalings ein entscheidendes Element, da sie die Menge des Traffic pro Pod bestimmt, der ein Autoscaling-Ereignis auslöst. Sie wird mit dem Feld maxRatePerEndpoint in einer GCPBackendPolicy konfiguriert, die dem Service zugeordnet ist. Damit wird der maximale Traffic definiert, den ein Service in Anfragen pro Sekunde und Pod empfangen soll. Die Service-Kapazität ist spezifisch für Ihre Anwendung.

    Weitere Informationen finden Sie unter Kapazität Ihres Service ermitteln.

  3. Speichern Sie das folgende Manifest als hpa.yaml:

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: store-autoscale
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: store-autoscale
      # Set the minimum and maximum number of replicas the Deployment can scale to.
      minReplicas: 1
      maxReplicas: 10
      # This section defines that scaling should be based on the fullness of load balancer
      # capacity, using the following configuration.
      metrics:
      - type: Object
        object:
          describedObject:
            kind: Service
            name: store-autoscale
          metric:
            # The name of the custom metric which measures how "full" a backend is
            # relative to its configured capacity.
            name: "autoscaling.googleapis.com|gclb-capacity-fullness"
          target:
            # The target average value for the metric. The autoscaler adjusts the number
            # of replicas to maintain an average capacity fullness of 70% across all Pods.
            averageValue: 70
            type: AverageValue
    

    Dieses Manifest beschreibt einen HorizontalPodAutoscaler mit folgenden Attributen:

    • minReplicas und maxReplicas: legt die minimale und maximale Anzahl an Replikaten für dieses Deployment fest. In dieser Konfiguration kann die Anzahl der Pods von 1 bis 10 Replikate skaliert werden.
    • describedObject.name: store-autoscale: der Verweis auf den store-autoscale-Service, der die Traffic-Kapazität definiert.
    • scaleTargetRef.name: store-autoscale: der Verweis auf das store-autoscale-Deployment, das die Ressource definiert, die vom horizontalen Pod-Autoscaling skaliert wird.
    • averageValue: 70: durchschnittlicher Zielwert von 70% Kapazitätsauslastung. Dadurch erhält das horizontale Pod-Autoscaling eine Wachstumsspanne, sodass die ausgeführten Pods während der Erstellung neuer Pods überschüssigen Traffic verarbeiten können.

Das horizontale Pod-Autoscaling führt zu folgendem Traffic-Verhalten:

  • Die Anzahl der Pods wird zwischen 1 und 10 Replikaten angepasst, um 70 % der maximalen Rate pro Endpunkt zu erreichen. Dies führt zu 7 RPS pro Pod bei maxRatePerEndpoint=10.
  • Bei mehr als 7 RPS pro Pod werden Pods hochskaliert, bis sie das Maximum von 10 Replikaten oder durchschnittlich 7 RPS pro Pod erreichen.
  • Wenn der Traffic reduziert wird, werden Pods mithilfe des Algorithmus des horizontalen Pod-Autoscalings auf eine angemessene Rate herunterskaliert.

Sie können auch einen Traffic-Generator bereitstellen, um das traffic-basierte Autoscaling-Verhalten zu validieren.

Bei 30 RPS wird das Deployment auf 5 Replikate skaliert, sodass jedes Replikat idealerweise 6 RPS an Traffic empfängt, was einer Auslastung von 60 % pro Pod entspricht. Dies liegt unter der Zielauslastung von 70 %. Die Pods werden daher entsprechend skaliert. Je nach Traffic-Schwankungen kann die Anzahl der automatisch skalierten Replikate ebenfalls variieren. Eine ausführlichere Beschreibung der Berechnung der Anzahl von Replikaten finden Sie unter Autoscaling-Verhalten.

Autoscaling auf Basis eines benutzerdefinierten oder externen Messwerts

Informationen zum Erstellen von horizontalen Pod-Autoscalings für benutzerdefinierte und externe Messwerte finden Sie unter Pod-Autoscaling anhand von Messwerten optimieren.

Autoscaling auf Basis von mehreren Messwerten

In diesem Beispiel wird ein horizontales Pod-Autoscaling erstellt, das basierend auf der CPU-Auslastung und einem benutzerdefinierten Messwert mit dem Namen packets_per_second automatisch skaliert.

Wenn Sie das vorherige Beispiel angewendet haben und noch ein horizontales Pod-Autoscaling mit dem Namen nginx vorhanden ist, löschen Sie es, bevor Sie dieses Beispiel ausführen.

Für dieses Beispiel ist apiVersion: autoscaling/v2 erforderlich. Weitere Informationen zu den verfügbaren APIs finden Sie unter API-Versionen für HorizontalPodAutoscaler-Objekte.

Speichern Sie dieses YAML-Manifest als Datei mit dem Namen nginx-multiple.yaml.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics: # The metrics to base the autoscaling on.
  - type: Resource
    resource:
      name: cpu # Scale based on CPU utilization.
      target:
        type: Utilization
        averageUtilization: 50
        # The HPA will scale the replicas to try and maintain an average
        # CPU utilization of 50% across all Pods.
  - type: Resource
    resource:
      name: memory # Scale based on memory usage.
      target:
        type: AverageValue
        averageValue: 100Mi
        # The HPA will scale the replicas to try and maintain an average
        # memory usage of 100 Mebibytes (MiB) across all Pods.
  # Uncomment these lines if you create the custom packets_per_second metric and
  # configure your app to export the metric.
  # - type: Pods
  #   pods:
  #     metric:
  #       name: packets_per_second
  #     target:
  #       type: AverageValue
  #       averageValue: 100

Wenden Sie das YAML-Manifest an:

kubectl apply -f nginx-multiple.yaml

Sobald das horizontale Pod-Autoscaling erstellt wurde, erfolgt ein Monitoring des Deployments nginx auf durchschnittliche CPU-Auslastung, durchschnittliche Speichernutzung sowie zum benutzerdefinierten Messwert packets_per_second, sofern Sie zuvor die Kommentarzeichen entfernt haben. Das horizontale Pod-Autoscaling skaliert das Deployment automatisch anhand des Messwerts, dessen Wert das umfassendere Autoscaling-Ereignis bestimmt.

HPA-Profil für Leistung konfigurieren

Das HPA-Profil für die Leistung verbessert die Reaktionszeit des horizontalen Pod-Autoscalers, sodass eine große Anzahl von HorizontalPodAutoscaler-Objekten schnell neu berechnet werden kann (bis zu 1.000 Objekte in den Nebenversionen 1.31–1.32 und 5.000 Objekte in Version 1.33 oder höher).

Dieses Profil wird automatisch in entsprechenden Autopilot-Clustern mit einer Steuerungsebene mit GKE-Version 1.32 oder höher aktiviert. Bei Standardclustern wird das Profil automatisch in berechtigten Clustern mit einer Steuerungsebene mit GKE-Version 1.33 oder höher aktiviert.

Ein Standardcluster ist von der automatischen Aktivierung des HPA-Profils „Leistung“ ausgenommen, wenn alle folgenden Bedingungen erfüllt sind:

  • Der Cluster wird von einer früheren Version auf Version 1.33 oder höher aktualisiert.
  • Der Cluster hat mindestens einen Knotenpool mit einem der folgenden Maschinentypen: e2-micro, e2-custom-micro, g1-small, f1-micro.
  • Die automatische Knotenbereitstellung ist nicht aktiviert.

Sie können das HPA-Profil für die Leistung auch für vorhandene Cluster aktivieren, sofern diese die Anforderungen erfüllen.

Voraussetzungen

Wenn Sie das HPA-Profil „Leistung“ aktivieren möchten, müssen Ihre Autopilot- und Standardcluster die folgenden Anforderungen erfüllen:

HPA-Profil für Leistung aktivieren

Verwenden Sie den folgenden Befehl, um das Leistungsprofil für HPA in Ihrem Cluster zu aktivieren:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --hpa-profile=performance

Ersetzen Sie:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION: Compute-Zone oder -Region (z.B. us-central1-a oder us-central1) für den Cluster.
  • PROJECT_ID: Ihre Google Cloud Projekt-ID

HPA-Profil für Leistung deaktivieren

Verwenden Sie den folgenden Befehl, um das Leistungsprofil für HPA in einem Cluster zu deaktivieren:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --hpa-profile=none

Ersetzen Sie:

  • CLUSTER_NAME ist der Name des Clusters.
  • LOCATION: Compute-Zone oder -Region (z.B. us-central1-a oder us-central1) für den Cluster.
  • PROJECT_ID: Ihre Google Cloud Projekt-ID

Details zu einem horizontalen Pod-Autoscaling ansehen

Verwenden Sie den folgenden Befehl, um die Konfiguration und die Statistiken des horizontalen Pod-Autoscalings aufzurufen:

kubectl describe hpa HPA_NAME

Ersetzen Sie HPA_NAME durch den Namen Ihres HorizontalPodAutoscaler-Objekts.

Wenn das horizontale Pod-Autoscaling apiVersion: autoscaling/v2 nutzt und auf mehreren Messwerten basiert, wird mit dem Befehl kubectl describe hpa nur der CPU-Messwert ausgegeben. Mit dem folgenden Befehl können Sie stattdessen alle Messwerte anzeigen lassen:

kubectl describe hpa.v2.autoscaling HPA_NAME

Ersetzen Sie HPA_NAME durch den Namen Ihres HorizontalPodAutoscaler-Objekts.

Der aktuelle Status jedes horizontalen Pod-Autoscalings wird im Feld Conditions angezeigt. Autoscaling-Ereignisse sind im Feld Events aufgeführt.

Die Ausgabe sieht etwa so aus:

Name:                                                  nginx
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           kubectl.kubernetes.io/last-applied-configuration:
                                                         {"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"s...
CreationTimestamp:                                     Tue, 05 May 2020 20:07:11 +0000
Reference:                                             Deployment/nginx
Metrics:                                               ( current / target )
  resource memory on pods:                             2220032 / 100Mi
  resource cpu on pods  (as a percentage of request):  0% (0) / 50%
Min replicas:                                          1
Max replicas:                                          10
Deployment pods:                                       1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:                                                <none>

Horizontales Pod-Autoscaling löschen

Sie können ein horizontales Pod-Autoscaling in der Google Cloud Console oder mit dem Befehl kubectl delete löschen.

Console

So löschen Sie das horizontale nginx-Pod-Autoscaling:

  1. Rufen Sie in der Google Cloud -Console die Seite Arbeitslasten auf.

    Zu Arbeitslasten

  2. Klicken Sie auf den Namen des nginx-Deployments.

  3. Klicken Sie auf Aktionen > Autoscaling.

  4. Klicken Sie auf Löschen.

kubectl delete

Verwenden Sie den folgenden Befehl, um das horizontale nginx-Pod-Autoscaling zu löschen:

kubectl delete hpa nginx

Wenn Sie ein horizontales Pod-Autoscaling löschen, bleibt die Skalierung des Deployments oder eines anderen Deployment-Objekts erhalten und wird nicht auf die Anzahl der Replikate im ursprünglichen Manifest des Deployments zurückgesetzt. Sie können den Befehl kubectl scale verwenden, um die Skalierung des Deployments manuell auf drei Pods zurückzusetzen.

kubectl scale deployment nginx --replicas=3

Bereinigen

  1. Löschen Sie das horizontale Pod-Autoscaling, sofern noch nicht geschehen:

    kubectl delete hpa nginx
    
  2. Löschen Sie das Deployment nginx:

    kubectl delete deployment nginx
    
  3. Optional: Löschen Sie den Cluster.

Fehlerbehebung

Tipps zur Fehlerbehebung finden Sie unter Fehlerbehebung beim horizontalen Pod-Autoscaling.

Nächste Schritte