Vertikales Pod-Autoscaling konfigurieren

Beim vertikalen Pod-Autoscaling werden die CPU- und Arbeitsspeicheranfragen und -limits für Container in Kubernetes-Pods automatisch festgelegt. Beim vertikalen Pod-Autoscaling wird die bisherige und aktuelle Ressourcennutzung analysiert, um Empfehlungen zu geben, die entweder angezeigt oder automatisch angewendet werden können, indem Pods aktualisiert werden. Diese Funktion verbessert die Stabilität und Kosteneffizienz, indem die Ressourcenzuweisungen richtig dimensioniert werden.

Hinweis

Bevor Sie das Vertikales Pod-Autoscaling konfigurieren, müssen die folgenden Voraussetzungen erfüllt sein:

  • Sie haben einen ausgeführten Bare-Metal-Cluster.
  • Sie haben kubectl-Zugriff auf den Cluster.
  • Der Metrics Server ist im Cluster verfügbar. Bare-Metal-Cluster enthalten standardmäßig den Metrics Server.

Vertikales Pod-Autoscaling aktivieren

Aktivieren Sie das vertikale Pod-Autoscaling in Ihrem Bare-Metal-Cluster, indem Sie eine Vorschau-Annotation festlegen und die Clusterspezifikation konfigurieren:

  1. Fügen Sie der benutzerdefinierten Clusterressource die Vorschau-Annotation hinzu oder aktualisieren Sie sie.

    Bearbeiten Sie die benutzerdefinierte Clusterressource direkt oder ändern Sie die Clusterkonfigurationsdatei und verwenden Sie bmctl update.

    metadata:
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable

  2. Ändern Sie die spec der benutzerdefinierten Clusterressource, um das Feld verticalPodAutoscaling einzufügen und die Modi enableUpdater und enableMemorySaver anzugeben:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other cluster spec fields
  verticalPodAutoscaling:
    enableUpdater: true       # Set to true for automated updates
    enableMemorySaver: true   # Set to true to reduce recommender memory usage

  3. Wenn Sie die Clusterkonfigurationsdatei geändert haben, übernehmen Sie die Änderungen mit dem folgenden Befehl:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.

    • KUBECONFIG: Der Pfad der kubeconfig-Datei Ihres Clusters.

Benutzerdefinierte VerticalPodAutoscaler-Ressource erstellen

Nachdem Sie das vertikale Pod-Autoscaling in Ihrem Cluster aktiviert haben, definieren Sie eine benutzerdefinierte VerticalPodAutoscaler-Ressource für bestimmte Arbeitslasten:

  1. Definieren Sie eine VerticalPodAutoscaler-Ressource im selben Namespace wie die Zielarbeitslast.

    Diese benutzerdefinierte Ressource gibt mit targetRef und allen Ressourcenrichtlinien an, auf welche Pods sie ausgerichtet ist.

    apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
    containerPolicies:
      -   containerName: '*'
        minAllowed:
          cpu: 100m
          memory: 50Mi
        maxAllowed:
          cpu: 1
          memory: 500Mi
        controlledResources: ["cpu", "memory"]

  2. Wenden Sie das VerticalPodAutoscaler-Manifest mit dem folgenden Befehl an:

    kubectl apply -f VPA_MANIFEST \
    --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

    • VPA_MANIFEST: Der Pfad der VerticalPodAutoscaler-Manifestdatei.

    • KUBECONFIG: Der Pfad der kubeconfig-Datei des Clusters.

Modi für vertikales Pod-Autoscaling

Das vertikale Pod-Autoscaling funktioniert in verschiedenen Modi, die steuern, wie Ressourcenempfehlungen angewendet werden.

Empfehlungsmodus

Im Empfehlungsmodus installiert das vertikale Pod-Autoscaling die Recommender-Komponente. Diese Komponente analysiert die Ressourcennutzung und veröffentlicht empfohlene Werte für CPU- und Arbeitsspeicheranfragen und -limits im Statusbereich der benutzerdefinierten VerticalPodAutoscaler-Ressourcen, die Sie erstellen.

Verwenden Sie den folgenden Befehl, um Empfehlungen für Ressourcenanfragen und -limits aufzurufen:

kubectl describe vpa VPA_NAME \
    --kubeconfig KUBECONFIG \
    -n CLUSTER_NAMESPACE

Replace the following:

*   `VPA_NAME`: the name of the `VerticalPodAutoscaler`
    that's targeting the workloads for which you are considering resource
    adjustments.

*   `KUBECONFIG`: the path of the cluster kubeconfig
    file.

*   `CLUSTER_NAMESPACE`: the name of the cluster that's
    running vertical Pod autoscaling.

Die Antwort sollte einen Status-Abschnitt enthalten, der dem folgenden Beispiel ähnelt:

Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi

In diesem Modus werden Pods nicht automatisch aktualisiert. Verwenden Sie diese Empfehlungen, um Ihre Pod-Konfigurationen manuell zu aktualisieren. Dies ist das Standardverhalten, wenn enableUpdater nicht festgelegt oder falseist.

Automatischer Aktualisierungsmodus

Wenn Sie enableUpdater enableUpdater auf true setzen, stellen die Lebenszyklus-Controller für Bare-Metal-Cluster zusätzlich zur Recommender-Komponente auch die Updater- und Zulassungscontroller-Komponenten für das vertikale Pod-Autoscaling bereit. Der Updater überwacht Pods, deren aktuelle Ressourcenanfragen erheblich von den Empfehlungen abweichen.

Die Aktualisierungsrichtlinie in der VerticalPodAutoscaler-Ressource gibt an, wie der Updater die Empfehlungen anwendet. Standardmäßig ist der Aktualisierungsmodus Auto. Das bedeutet, dass der Updater beim Erstellen von Pods aktualisierte Ressourceneinstellungen zuweist. Im folgenden VerticalPodAutoscaler-Beispiel wird gezeigt, wie Sie den Aktualisierungsmodus auf Initial setzen:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
  updatePolicy:
    updateMode: "Initial"
    ...

Der Updater unterstützt die folgenden fünf Modi:

  • Auto: Der Updater entfernt den Pod. Der Zulassungscontroller fängt die Erstellungsanfrage für den neuen Pod ab und ändert sie so, dass die vom Recommender empfohlenen CPU- und Arbeitsspeicherwerte verwendet werden. Zum Aktualisieren von Ressourcen muss der Pod neu erstellt werden, was zu Unterbrechungen führen kann. Verwenden Sie Budgets für Pod-Störungen, die vom Updater berücksichtigt werden, um den Bereinigungsprozess zu verwalten. Dieser Modus entspricht Recreate.

  • Recreate: Der Updater entfernt Pods und weist beim Neuerstellen des Pods empfohlene Ressourcenanfragen und -limits zu.

  • InPlaceOrRecreate(Alpha): Der Updater versucht, In-Place-Updates durchzuführen, kann aber auf das Neuerstellen des Pods zurückgreifen, wenn In-Place-Updates nicht möglich sind. Weitere Informationen finden Sie in der Dokumentation zur In-Place-Größenänderung von Pods.

  • Initial: Der Updater weist Ressourcenanfragen nur beim Erstellen des Pods zu und ändert sie später nie mehr.

  • Off: Der Updater ändert die Ressourcenanforderungen der Pods nicht automatisch. Die Empfehlungen werden berechnet und können im VerticalPodAutoscaler-Objekt eingesehen werden.

Weitere Informationen zur benutzerdefinierten VerticalPodAutoscaler-Ressource finden Sie unter kubectl, um die benutzerdefinierte Ressourcendefinition verticalpodautoscalercheckpoints.autoscaling.k8s.io abzurufen, die im Cluster der Version 1.33.0 oder höher installiert ist.

Im folgenden Beispiel sehen Sie, wie Ressourcenempfehlungen im Abschnitt Status für den Container hamster aussehen können. Das Beispiel zeigt auch ein Ereignis zum Entfernen eines Pods, das auftritt, wenn der Updater einen Pod entfernt, bevor er dem neu erstellten Pod automatisch die empfohlene Ressourcenkonfiguration zuweist:

Spec:
  Resource Policy:
    Container Policies:
      Container Name:  *
      Controlled Resources:
        cpu
        memory
      Max Allowed:
        Cpu:     1
        Memory:  500Mi
      Min Allowed:
        Cpu:     100m
        Memory:  50Mi
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         hamster
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi
Events:
  Type    Reason      Age   From         Message
  ----    ------      ----  ----         -------
  Normal  EvictedPod  49s   vpa-updater  VPA Updater evicted Pod hamster-7cb59fb657-lkrk4 to apply resource recommendation.

Arbeitsspeicher-Sparmodus

Im Arbeitsspeicher-Sparmodus wird der Speicherbedarf der Recommender-Komponente für das vertikale Pod-Autoscaling reduziert. Wenn Sie enableMemorySaver auf true setzen, werden vom Empfehlungstool nur Aggregationen für Pods erfasst und berechnet, die eine übereinstimmende VerticalPodAutoscaler benutzerdefinierte Ressource haben.

Der Nachteil ist, dass es einige Zeit (bis zu 24 Stunden) dauert, bis der Recommender genügend Verlaufsdaten erfasst hat, um genaue Empfehlungen zu geben, wenn Sie eine neue benutzerdefinierte VerticalPodAutoscaler-Ressource für eine vorhandene Arbeitslast erstellen. Dieser Modus ist für die meisten Clustertypen standardmäßig false, für Edge-Cluster jedoch true.

Prometheus als Anbieter für dauerhaften Verlauf verwenden

Standardmäßig speichert die Recommender-Komponente den Verlauf des Ressourcenverbrauchs der im Cluster ausgeführten Arbeitslasten im Arbeitsspeicher und speichert ihren Zustand regelmäßig in einer benutzerdefinierten VerticalPodAutoscalerCheckpoint-Ressource in etcd, um die Ausfallsicherheit bei Neustarts zu gewährleisten.

Ab Google Distributed Cloud Version 1.34 können Sie Ihre eigene Prometheus-Instanz als Anbieter für dauerhaften Verlauf für Daten zum Ressourcenverbrauch verwenden, nämlich Messwerte zur CPU- und Arbeitsspeichernutzung. Wenn diese Integration aktiviert ist, kann der Recommender beim Start oder Neustart den Prometheus-Server abfragen, um langfristige Verlaufsdaten zur Ressourcennutzung für alle verwalteten Pods abzurufen. Durch das Abrufen dieser Daten kann der Recommender seinen internen Zustand sofort mit einem umfangreichen Dataset erstellen, was von Anfang an zu fundierteren und genaueren Empfehlungen führt.

Die Verwendung von Prometheus als Anbieter für dauerhaften Verlauf bietet folgende Vorteile:

  • Optimierung der Ressourcennutzung:generiert sofort nach dem Start fundierte und genaue Empfehlungen, sodass Sie die Ressourcennutzung des Clusters optimieren können.

  • Vermeidung von Fehlern wegen unzureichendem Arbeitsspeicher:Mit Prometheus ist es nicht mehr erforderlich, den internen Status des Empfehlungstools in benutzerdefinierten VerticalPodAutoscalerCheckpoint-Ressourcen zu speichern, wodurch die Arbeitsspeichernutzung von ETCD effizienter wird. Wenn die Empfehlungskomponente neu gestartet wird, gehen die Verlaufsdaten im Arbeitsspeicher verloren. Wenn Sie Prometheus als Anbieter für den Verlauf verwenden, ruft der Recommender beim Neustart Verlaufsdaten aus Prometheus ab. Dadurch ist die benutzerdefinierte Ressource VerticalPodAutoscalerCheckpoint nicht mehr erforderlich und ETCD-Arbeitsspeicher wird gespart.

Sie können die Verwendung von Prometheus als Anbieter für dauerhaften Verlauf jederzeit aktivieren und deaktivieren.

Voraussetzungen für die Verwendung von Prometheus mit vertikalem Pod-Autoscaling

Wenn Sie Ihre eigene Prometheus-Instanz als Anbieter für den Verlauf für das vertikale Pod-Autoscaling verwenden möchten, müssen Sie sie so konfigurieren, dass die erforderlichen Messwerte erfasst werden. Dazu sind folgende Schritte erforderlich:

  1. Stellen Sie bei Bedarf den Prometheus-Operator in dem Cluster bereit, für den Sie ihn als Anbieter für dauerhaften Verlauf für das vertikale Pod-Autoscaling verwenden möchten. Weitere Informationen finden Sie unter Prometheus-Operator in Kubernetes bereitstellen und konfigurieren.

  2. Konfigurieren Sie Berechtigungen zum Erfassen von Messwerten.

    Damit Prometheus Messwerte aus cAdvisor mithilfe einer Konfigurationsdatei erfassen kann, müssen Sie dem Dienstkonto, das vom Prometheus-Server verwendet wird, zusätzliche Berechtigungen gewähren. Erstellen oder aktualisieren Sie eine ClusterRole, die diese Regeln enthält, und sorgen Sie dafür, dass sie mit einer ClusterRoleBinding an das richtige Prometheus-Dienstkonto gebunden ist:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
   name: prometheus-role
   labels:
      app: prometheus-server
rules:
   - apiGroups: [""]
     resources:
       - nodes
     verbs:
       - get
       - list
       - watch
   - apiGroups: [""]
     resources:
       - nodes/proxy
       - nodes/metrics
     verbs:
       - get
    ---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-binding
  labels:
    app: prometheus-server
subjects:
  - kind: ServiceAccount
    name: prometheus-server        # Service account being used by prometheus
    namespace: prometheus          # Service account's namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-role            # Name of the ClusterRole created above

  3. Aktualisieren Sie die Prometheus-Konfigurationsdatei, um die folgenden Messwerte aus cAdvisor zu erfassen:

    • container_cpu_usage_seconds_total
    • container_memory_working_set_bytes

    In den folgenden Zeilen werden die Details zum Erfassen der cAdvisor-Messwerte definiert:

    - job_name: 'kubernetes-cadvisor'
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  kubernetes_sd_configs:
    - role: node
  relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - target_label: __address__
      replacement: kubernetes.default.svc:443
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

  metric_relabel_configs:
  # Keep only the metrics VPA uses to save disk space
    - source_labels: [__name__]
      regex: (container_cpu_usage_seconds_total|container_memory_working_set_bytes)
      action: keep

  4. Aktualisieren Sie die Prometheus-Konfigurationsdatei, um den folgenden Messwert aus dem kube-state-metrics-Dienst zu erfassen:

    • kube_pod_labels

    1. Stellen Sie einen kube-state-metrics-Dienst in Ihrem Cluster bereit.

      Mit den folgenden Helm-Befehlen können Sie den neuen Dienst installieren:

      helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

    2. Erstellen Sie eine ksm-values.yaml-Datei mit folgendem Inhalt:

      fullnameOverride: vpa-kube-state-metrics
metricAllowlist:
  - kube_pod_labels
metricLabelsAllowlist:
  - "pods=[*]"

    3. Installieren Sie ein Helm-Diagramm basierend auf der Werte-Datei aus dem vorherigen Schritt:

      helm install vpa-ksm prometheus-community/kube-state-metrics \
    -f ksm-values.yaml --namespace kube-system

    4. Fügen Sie der Prometheus-Konfigurationsdatei die folgenden Zeilen hinzu, um den Messwert kube_pod_labels aus dem installierten kube-state-metrics-Dienst zu erfassen:

      - job_name: 'kube-state-metrics'
  static_configs:
    - targets: ['vpa-kube-state-metrics.kube-system.svc.cluster.local:8080']
  metric_relabel_configs:
    - source_labels: [ __name__ ]
      regex: 'kube_pod_labels'
      action: keep

Prometheus aktivieren und verwenden

Das vertikale Pod-Autoscaling unterstützt sowohl die Basisauthentifizierung als auch die auf Bearertokens basierende Authentifizierung für die Verbindung zu Prometheus. Wenn Sie die Authentifizierung verwenden, müssen Sie im Cluster-Namespace ein Secret mit den erforderlichen Anmeldedaten erstellen. Der Controller leitet dieses Secret an den Zielcluster weiter und stellt es als Volume oder Umgebungsvariable im Pod des Recommenders bereit. Sie können Prometheus auch ohne Authentifizierung verwenden.

Wenn Sie Ihre eigene Prometheus-Instanz mit dem vertikalen Pod-Autoscaling aktivieren und verwenden möchten, müssen Sie den Abschnitt verticalPodAutoscaling in Ihrer Clusterspezifikation mit Details für die Verbindung zu Ihrer Prometheus-Instanz konfigurieren.

Hier ist ein Beispiel für die Konfiguration in der Clusterspezifikation zur Verwendung mit einem Bearertoken:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vertical Pod autoscaling configurations ...
    # Add this new section to configure the vpa to use prometheus using bearer token authentication as history provider
    prometheus:
      url: "http://prometheus.prometheus.monitoring.svc.cluster.local:9090"
      auth:
        bearerTokenAuth:
            name: prom-bearer-creds
            key: bearertoken

So aktivieren Sie Prometheus für die Verwendung mit dem vertikalen Pod-Autoscaling:

  1. Achten Sie darauf, dass Ihre Prometheus-Instanz so eingerichtet ist, dass die erforderlichen Messwerte erfasst werden, wie unter Voraussetzungen für die Verwendung von Prometheus mit vertikalem Pod Autoscaling beschrieben.

  2. Aktualisieren Sie die benutzerdefinierte Clusterressource spec so, dass im Feld verticalPodAutoscaling.prometheus die Verbindungseinstellungen für Ihren Prometheus-Server angegeben sind.

  3. Fügen Sie die url dem Abschnitt prometheus hinzu und legen Sie sie auf den vollqualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) fest, um aus dem Cluster heraus eine Verbindung zu Prometheus herzustellen:

    spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vpa configurations ...
    # Add this new section to configure the vpa to use prometheus as history provider
    prometheus:
      # Required: The URL of the Prometheus server
      url: "http://prometheus.prometheus.svc.cluster.local:9090"

  4. Geben Sie die Verbindungsdetails an:

    Das vertikale Pod-Autoscaling unterstützt die folgenden drei Verbindungsmethoden:

    • Keine Authentifizierung
    • Basisauthentifizierung (Nutzername, Passwort)

    • Authentifizierung mit Bearertoken

    Keine Authentifizierung

    Wenn für Ihre Prometheus-Instanz keine Authentifizierung erforderlich ist, sind Sie fertig. Der Abschnitt prometheus darf nur ein Feld url enthalten.

    Basisauthentifizierung

    Führen Sie die folgenden Schritte aus, um die Basisauthentifizierung für Prometheus anzugeben:

    1. Erstellen Sie ein Secret, das im stringData Abschnitt einen Nutzernamen und ein Passwort sowie die baremetal.cluster.gke.io/mark-source: "true" Annotation enthält.

      Das folgende Beispiel zeigt ein Secret, das die Basisauthentifizierung unterstützt:

      apiVersion: v1
kind: Secret
metadata:
  name: prom-basic-creds
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  username: admin
  password: pwd

      Die Annotation ist erforderlich, um sicherzustellen, dass das Quell-Secret und das Secret im Zielcluster immer synchron sind. Das Secret wird aktualisiert, wenn das Quell-Secret aktualisiert wird.

    2. Aktualisieren Sie den Abschnitt prometheus.auth.basicAuth der Clusterspezifikation, um auf den Nutzernamen und das Passwort aus dem Feld data im Secret zu verweisen.

      Das folgende Beispiel zeigt einen basicAuth-Abschnitt, der auf den Nutzernamen und das Passwort im Secret aus dem vorherigen Schritt verweist:

      # ... other vpa configurations ...
prometheus:
  url: "http://prometheus.prometheus.svc.cluster.local:9090"
  auth:
    basicAuth:
      usernameRef:
        name: prom-basic-creds
        key: username
      passwordRef:
        name: prom-basic-creds
        key: password

      Der Nutzername und das Passwort müssen sich im selben Secret befinden. Die Schlüssel müssen gültige Schlüssel aus dem Feld data des Secrets sein.

    Die Prometheus-Instanz sollte als Bereitsteller für den Verlauf für das vertikale Pod-Autoscaling funktionieren, wenn die benutzerdefinierte Clusterressource aktualisiert wird.

    Authentifizierung mit Bearertoken

    Führen Sie die folgenden Schritte aus, um die Authentifizierung mit Bearertoken für Prometheus anzugeben:

    1. Erstellen Sie ein Secret, das im stringData Abschnitt ein Bearertoken und die baremetal.cluster.gke.io/mark-source: "true" Annotation enthält.

      Das folgende Beispiel zeigt ein Secret, das die Authentifizierung mit Bearertoken unterstützt:

      apiVersion: v1
kind: Secret
metadata:
  name: prom-bearer-creds
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  bearertoken: "SAMPLE_TOKEN"

      Die Annotation ist erforderlich, um sicherzustellen, dass das Quell-Secret und das Secret im Zielcluster immer synchron sind. Das Secret wird aktualisiert, wenn das Quell-Secret aktualisiert wird.

    2. Aktualisieren Sie den Abschnitt prometheus.auth.bearerTokenAuth der Clusterspezifikation, um auf das Bearertoken aus dem Feld data im Secret zu verweisen.

      Das folgende Beispiel zeigt einen bearerTokenAuth-Abschnitt, der auf das Bearertoken im Secret aus dem vorherigen Schritt verweist:

      # ... other vertical Pod autoscaling configurations ...
prometheus:
  url: "http://prometheus.prometheus.svc.cluster.local:9090"
  auth:
    bearerTokenAuth:
        name: prom-bearer-creds
        key: bearertoken

      Der Schlüssel muss ein gültiger Schlüssel aus dem Feld data des Secrets sein.

    Die Prometheus-Instanz sollte als Anbieter für den Verlauf für das vertikale Pod-Autoscaling funktionieren, wenn die benutzerdefinierte Clusterressource aktualisiert wird.

Verwendung von Prometheus deaktivieren

Wenn Sie die Verwendung von Prometheus mit dem vertikalen Pod-Autoscaling deaktivieren möchten, entfernen Sie den Abschnitt prometheus aus dem Abschnitt verticalPodAutoscaling der benutzerdefinierten Clusterressource.

Vertikales Pod-Autoscaling deaktivieren

Deaktivieren Sie das vertikale Pod-Autoscaling, indem Sie die benutzerdefinierten Ressourcen und die Konfiguration aus Ihrem Cluster entfernen:

  1. Löschen Sie alle benutzerdefinierten VerticalPodAutoscaler-Ressourcen, die Sie erstellt haben.

  2. Ändern Sie die benutzerdefinierte Clusterressource und entfernen Sie den gesamten Abschnitt verticalPodAutoscaling aus der spec.

    Sie können die benutzerdefinierte Clusterressource direkt bearbeiten oder die Clusterkonfigurationsdatei ändern und bmctl update verwenden.

  3. Entfernen Sie die Annotation preview.baremetal.cluster.gke.io/vertical-pod-autoscaler aus der benutzerdefinierten Clusterressource.

Beschränkungen

Beachten Sie die folgenden Einschränkungen, wenn Sie das Vertikales Pod-Autoscaling verwenden:

  • Das vertikale Pod-Autoscaling ist aufgrund der eingeschränkten Sichtbarkeit der tatsächlichen Arbeitsspeichernutzung der Arbeitslast noch nicht bereit für die Verwendung mit JVM-Arbeitslasten.
  • Der Updater benötigt mindestens zwei Pod-Replikate für Deployments, um Pods durch überarbeitete Ressourcenwerte zu ersetzen.
  • Der Updater aktualisiert Pods, die aufgrund von Fehlern wegen unzureichendem Arbeitsspeicher in einer Crash-Schleife sind, nicht schnell.
  • Die Aktualisierungsrichtlinie InPlaceOrRecreate für Pods ist eine Alphafunktion im vertikalen Pod-Autoscaling. Sie versucht, In-Place-Updates durchzuführen, kann aber auf das Neuerstellen des Pods zurückgreifen, wenn In-Place-Updates nicht möglich sind.

Nächste Schritte