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 HorizontalPodAutoscaler (HPA)-Profils, 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 Entwickler und Betreiber, 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 CloudInhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Hinweis

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 diese Aufgabe 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 HPA-Objekte mit der autoscaling/v2-API erstellt. Die autoscaling/v1 API wird weiterhin unterstützt, ist aber nicht mehr empfehlenswert und unterstützt bestimmte Funktionen wie das Skalieren auf und von null mit HPA nicht.

Beispiel-Deployment erstellen

Bevor Sie ein HPA-Objekt erstellen können, müssen Sie die zu überwachende Arbeitslast einrichten. In den Beispielen auf dieser Seite werden unterschiedliche HPA-Konfigurationen auf das folgende nginx-Deployment angewendet. In separaten Beispielen ist jeweils ein HPA zu sehen, das auf Ressourcennutzung, einem benutzerdefinierten oder externen Messwert und mehreren Messwerten beruht.

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 HPA-Objekt auf ein Beispiel-nginx-Deployment angewendet.

Autoscaling auf Basis der Ressourcennutzung

In diesem Beispiel wird ein HPA-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 HPA 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 bearbeiten.

  4. Klicken Sie im Abschnitt zum horizontalen Pod-Autoscaling auf Auswählen und konfigurieren.

  5. Geben Sie die folgenden Werte an:

    • Mindestanzahl an Replikaten: 1
    • Maximale Anzahl von Replikaten: 10
    • Autoscaling-Messwert: CPU
    • Ziel: 50
    • Einheit: CPUs

  6. Klicken Sie auf Senden.

kubectl apply

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

apiVersion: autoscaling/v2
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
  metrics:
  - type: Resource
    resource:
      # The target average CPU utilization percentage across all Pods.
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Wenn Sie ein Manifest erstellen, das bestimmten Details in Ihrem eigenen Projekt entspricht, achten Sie darauf, dass Sie keine sensiblen Daten in die Felder für horizontales Pod-Autoscaling aufnehmen.

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 HPA-Objekt erstellen, dessen Ziel ausschließlich die durchschnittliche CPU-Auslastung ist:

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

Mit dem folgenden Befehl können Sie eine Liste der HPAs im Cluster abrufen:

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 HPA 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. Klicken Sie auf den Tab Skalierung.

kubectl get

Wenn Sie Details zu HPA abrufen möchten, 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 etwa so aus:

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

Wenn Sie ein Manifest erstellen, das bestimmten Details in Ihrem eigenen Projekt entspricht, dürfen Sie keine vertraulichen Daten in die Felder für horizontales Pod-Autoscaling aufnehmen.

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

kubectl delete hpa nginx

Wenn Sie ein HPA-Objekt löschen, bleibt die Anzahl der Replikate des Deployments erhalten. Ein Deployment wird nicht automatisch auf den Zustand vor der Anwendung des HPA zurückgesetzt.

Weitere Informationen finden Sie unter Ein HPA löschen.

Autoscaling auf Basis eines benutzerdefinierten oder externen Messwerts

Jeder Messwert, der von Ihrer Arbeitslast ausgegeben wird oder den Sie von einer externen Quelle abfragen können, kann für das Autoscaling verwendet werden. GKE bietet in vielen Situationen integrierte Unterstützung für das Autoscaling auf Grundlage benutzerdefinierter und externer Messwerte. Kubernetes unterstützt zusätzliche Messwertadapter wie KEDA und den Prometheus-Adapter.

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.
  • Gateway API in Ihrem Projekt 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 automatischen Skalieren auf Grundlage des Traffics beteiligt sind. Ein HPA-Objekt muss für die Skalierung einer einzelnen Bereitstellung (oder einer beliebigen skalierbaren Ressource) vorgesehen sein, die von einem einzelnen Dienst 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 HPA mit trafficbasierten Messwerten konfigurieren. So wird verhindert, dass Ihr Cluster vorübergehend versucht, das Autoscaling auf Grundlage von Messwerten durchzuführen, die von einem Load-Balancer ausgegeben werden, der sich noch in der Konfigurationsphase 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), kann HPA den höchsten Trafficwert von einzelnen Load Balancern für Skalierungsentscheidungen berücksichtigen, anstatt die Summe der Trafficwerte aller Load Balancer zu verwenden.

Traffic-basiertes Autoscaling bereitstellen

In der folgenden Übung wird HPA 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. Bei Autopilot-Clustern 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 einer zugehörigen GCPBackendPolicy-Einstellung maxRatePerEndpoint, die auf 10 gesetzt 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 ein HPA-Objekt mit den 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 (oder von 0 Replikaten, wenn Sie die Skalierung auf und von null mit HPA konfigurieren).
    • 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 HPA skaliert wird.
    • averageValue: 70: durchschnittlicher Zielwert von 70% Kapazitätsauslastung. Dadurch erhält das HPA eine Wachstumsspanne, sodass die ausgeführten Pods während der Erstellung neuer Pods überschüssigen Traffic verarbeiten können.

    Wenn Sie ein Manifest erstellen, das bestimmten Details in Ihrem eigenen Projekt entspricht, achten Sie darauf, dass Sie keine sensiblen Daten in die Felder für horizontales Pod-Autoscaling aufnehmen.

HPA 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 HPA-Algorithmus 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 von mehreren Messwerten

In diesem Beispiel wird ein HPA-Objekt erstellt, das basierend auf der CPU-Auslastung und einem benutzerdefinierten Messwert namens packets_per_second automatisch skaliert wird.

Wenn Sie das vorherige Beispiel ausgeführt haben und immer noch ein HPA-Objekt mit dem Namen nginx haben, 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 HPA-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

Wenn Sie ein Manifest erstellen, das bestimmten Details in Ihrem eigenen Projekt entspricht, achten Sie darauf, dass Sie keine sensiblen Daten in die Felder für horizontales Pod-Autoscaling aufnehmen.

Wenden Sie das YAML-Manifest an:

kubectl apply -f nginx-multiple.yaml

Nach der Erstellung überwacht der HPA das Deployment nginx auf die durchschnittliche CPU-Auslastung, die durchschnittliche Speicherauslastung und (wenn Sie das Kommentarzeichen entfernt haben) den benutzerdefinierten Messwert packets_per_second. HPA skaliert das Deployment automatisch anhand des Messwerts, dessen Wert das größere Autoscaling-Ereignis erstellen würde.

Auf null und von null skalieren

Ab GKE-Version 1.37 können Sie das HPA so konfigurieren, dass ein Deployment bei fehlender Arbeitslast auf null (0) Replikate skaliert und bei steigender Nachfrage automatisch wieder hochskaliert wird. Beim Hochskalieren von null umgeht GKE die standardmäßigen Toleranzprüfungen für Messwerte, um Pods ohne Verzögerung zu aktivieren.

Wenn Sie die Skalierung auf und von null mit HPA konfigurieren möchten, müssen Sie Folgendes tun:

  1. Achten Sie darauf, dass in Ihrem Cluster die GKE-Version 1.37 oder höher ausgeführt wird.
  2. Konfigurieren Sie mindestens einen benutzerdefinierten oder externen Messwert mit der Ressource AutoscalingMetric.
  3. Legen Sie das Feld/Wert-Paar minReplicas: 0 in einem HPA-Manifest fest, das die autoscaling/v2 API verwendet.

Eine detaillierte Anleitung finden Sie unter GKE-Arbeitslasten mit HPA auf null und von null skalieren.

HPA-Profil für Leistung konfigurieren

Das HPA-Leistungsprofil verbessert die Reaktionszeit des horizontalen Pod-Autoscalings und trägt dazu bei, dass der HPA eine große Anzahl von Objekten verarbeiten 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 infrage kommenden Autopilot-Clustern mit einer Steuerungsebene mit GKE-Version 1.32 oder höher aktiviert. Bei Standard-Clustern wird das Profil automatisch für geeignete Cluster mit einer Steuerungsebene aktiviert, auf der die GKE-Version 1.33 oder höher ausgeführt wird.

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

  • 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 „Leistung“ auch auf vorhandenen Clustern aktivieren, wenn diese die Anforderungen erfüllen.

Voraussetzungen

Prüfen Sie, ob Ihre Autopilot- und Standardcluster die folgenden Anforderungen erfüllen, um das HPA-Profil „Leistung“ zu aktivieren:

HPA-Profil für Leistung aktivieren

Verwenden Sie den folgenden Befehl, um das HPA-Profil für Leistung 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: Computing-Zone oder -Region (z.B. us-central1-a oder us-central1) für den Cluster.
  • PROJECT_ID: Ihre Google Cloud Projekt-ID

HPA-Profil „Leistung“ deaktivieren

Verwenden Sie den folgenden Befehl, um das HPA-Profil für die Leistung 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 HorizontalPodAutoscaler ansehen

Verwenden Sie den folgenden Befehl, um die Konfiguration und Statistiken eines HPA anzuzeigen:

kubectl describe hpa HPA_NAME

Ersetzen Sie HPA_NAME durch den Namen Ihres HPA-Objekts.

Der aktuelle Status jedes HPA-Objekts wird im Feld Conditions angezeigt und Autoscaling-Ereignisse werden 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>

HorizontalPodAutoscaler löschen

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

Console

So löschen Sie das HPA-Objekt nginx:

  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 HPA-Objekt nginx zu löschen:

kubectl delete hpa nginx

Wenn Sie ein HPA-Objekt löschen, behält die Bereitstellung (oder ein anderes Bereitstellungsobjekt) ihre aktuelle Skalierung bei und wird nicht auf die Anzahl der Replikate im ursprünglichen Manifest der Bereitstellung 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 HPA-Objekt, falls 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