Vertikales Pod-Autoscaling konfigurieren

Beim vertikalen Pod-Autoscaling werden CPU- und Arbeitsspeicherressourcenanforderungen 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 Ressourcen richtig dimensioniert werden.

Hinweise

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

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

Vertikales Pod-Autoscaling aktivieren

Aktivieren Sie das vertikale Pod-Autoscaling in Ihrem Bare-Metal-Cluster, indem Sie eine Preview-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 einzuschließen 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, wenden Sie die Änderungen mit dem folgenden Befehl an:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.

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

Benutzerdefinierte VerticalPodAutoscaler-Ressource erstellen

Nachdem Sie das vertikale Pod-Autoscaling für Ihren 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.

    Mit dieser benutzerdefinierten Ressource wird angegeben, auf welche Pods sie mit targetRef und allen Ressourcenrichtlinien 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. Führen Sie den folgenden Befehl aus, um das Manifest VerticalPodAutoscaler anzuwenden:

    kubectl apply -f VPA_MANIFEST \
    --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

    • VPA_MANIFEST: der Pfad der Manifestdatei VerticalPodAutoscaler.

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

Modi für vertikales Pod-Autoscaling

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

Empfehlungsmodus

Im Empfehlungsmodus wird durch das vertikale Pod-Autoscaling die Empfehlungskomponente installiert. Diese Komponente analysiert die Ressourcennutzung und veröffentlicht empfohlene Werte für CPU- und Speicheranforderungen 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

Pods werden in diesem Modus nicht automatisch aktualisiert. Anhand dieser Empfehlungen können Sie Ihre Pod-Konfigurationen manuell aktualisieren. Dies ist das Standardverhalten, wenn enableUpdater nicht festgelegt oder false ist.

Automatischer Aktualisierungsmodus

Wenn Sie enableUpdater enableUpdater auf true festlegen, stellen Bare-Metal-Lifecycle-Controller zusätzlich zum Empfehlungsmodul die Komponenten für vertikales Pod-Autoscaling-Updater und Admission-Controller bereit. Der Updater überwacht Pods, deren aktuelle Ressourcenanforderungen erheblich von den Empfehlungen abweichen.

Die Aktualisierungsrichtlinie in der VerticalPodAutoscaler-Ressource gibt an, wie der Updater die Empfehlungen anwendet. Der Standardaktualisierungsmodus ist 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 festlegen:

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

Das Updater-Tool unterstützt die folgenden fünf Modi:

  • Auto: Der Updater entfernt den Pod. Der Admission Controller fängt die Erstellungsanfrage für den neuen Pod ab und ändert sie so, dass die vom Recommender empfohlenen CPU- und Speicherwerte 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 bereinigt Pods und weist empfohlene Ressourcenanfragen und ‑limits zu, wenn der Pod neu erstellt wird.

  • InPlaceOrRecreate(Alpha): Der Updater versucht, In-Place-Updates nach bestem Wissen und Gewissen 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 zum Anpassen der Größe von Pods am selben Ort.

  • Initial: Der Updater weist Ressourcenanfragen nur bei der Pod-Erstellung zu und ändert sie später nie mehr.

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

Weitere Informationen zur benutzerdefinierten Ressource VerticalPodAutoscaler erhalten Sie mit kubectl, um die benutzerdefinierte Ressourcendefinition verticalpodautoscalercheckpoints.autoscaling.k8s.io abzurufen, die auf dem Cluster mit Version 1.33.0 oder höher installiert ist.

Das folgende Beispiel zeigt, wie Ressourcenempfehlungen im Abschnitt Status für den Container hamster angezeigt werden können. Das Beispiel zeigt auch ein Beispiel für ein Pod-Entfernungsereignis, 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 Speichersparmodus wird der Speicherbedarf der Empfehlungskomponente für vertikales Pod-Autoscaling reduziert. Wenn Sie enableMemorySaver auf true festlegen, werden vom Recommender nur Aggregationen für Pods mit einer entsprechenden benutzerdefinierten VerticalPodAutoscaler-Ressource erfasst und berechnet.

Wenn Sie eine neue benutzerdefinierte VerticalPodAutoscaler-Ressource für eine vorhandene Arbeitslast erstellen, benötigt der Recommender einige Zeit (bis zu 24 Stunden), um genügend Daten zu sammeln, um genaue Empfehlungen zu geben. Dieser Modus ist für die meisten Clustertypen standardmäßig false, für Edge-Cluster jedoch true.

Prometheus als Anbieter für den persistenten Verlauf verwenden

Standardmäßig speichert die Empfehlungskomponente den Ressourcenverbrauch der Arbeitslasten, die im Cluster ausgeführt werden, im Arbeitsspeicher und speichert den Status regelmäßig in einer VerticalPodAutoscalerCheckpoint-benutzerdefinierten 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 den persistenten Verlauf von Daten zum Ressourcenverbrauch verwenden, nämlich Messwerte zur CPU- und Arbeitsspeichernutzung. Wenn diese Integration aktiviert ist, kann der Empfehlungsdienst beim Start oder Neustart den Prometheus-Server abfragen, um langfristige historische Daten zur Ressourcennutzung für alle verwalteten Pods abzurufen. Durch den Abruf dieser Daten kann der Empfehlungsdienst seinen internen Status sofort mit einem umfangreichen Datensatz aufbauen, was von Anfang an zu fundierteren und genaueren Empfehlungen führt.

Die Verwendung von Prometheus als Anbieter für den persistenten Verlauf bietet die folgenden Vorteile:

  • Ressourcennutzung optimieren:Sobald die Funktion gestartet wird, werden fundierte und genaue Empfehlungen generiert, damit Sie die Nutzung von Clusterressourcen optimieren können.

  • OOM-Fehler („Out Of Memory“) verhindern:Bei Prometheus muss der interne Status des Empfehlungstools nicht in VerticalPodAutoscalerCheckpoint-benutzerdefinierten Ressourcen (Custom Resources, CRs) gespeichert werden, wodurch die ETCD-Speicherauslastung effizienter wird. Wenn die Empfehlungskomponente neu gestartet wird, gehen die im Arbeitsspeicher gespeicherten Verlaufsdaten verloren. Wenn Sie Prometheus als Verlaufsanbieter verwenden, ruft der Empfehlungsdienst beim Neustart Verlaufs-Messwerte aus Prometheus ab. Dadurch ist die VerticalPodAutoscalerCheckpoint-CR nicht mehr erforderlich und ETCD-Arbeitsspeicher wird gespart.

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

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

Wenn Sie Ihre eigene Prometheus-Instanz als Verlaufsanbieter für vertikales Pod-Autoscaling verwenden möchten, müssen Sie sie so konfigurieren, dass die erforderlichen Messwerte erfasst werden. Dazu sind die folgenden Schritte erforderlich:

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

  2. Berechtigungen für das Erheben von Messwerten konfigurieren

    Damit Prometheus Messwerte aus cAdvisor mithilfe einer Konfigurationsdatei erfassen kann, müssen Sie dem Dienstkonto, das vom Prometheus-Server verwendet wird, zusätzliche Berechtigungen erteilen. Erstellen oder aktualisieren Sie eine ClusterRole mit diesen Regeln 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 von cAdvisor zu extrahieren:

    • container_cpu_usage_seconds_total
    • container_memory_working_set_bytes

    In den folgenden Zeilen werden die Scrape-Details für die 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 Wertedatei 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 Authentifizierung mit Bearertokens für die Verbindung zu Prometheus. Wenn Sie die Authentifizierung verwenden, müssen Sie im Clusternamespace ein Secret mit den erforderlichen Anmeldedaten erstellen. Der Controller leitet dieses Secret an den Zielcluster weiter und stellt es als Volume oder Umgebungsvariable im Empfehlungs-Pod bereit. Sie können Prometheus auch ohne Authentifizierung verwenden.

Wenn Sie Ihre eigene Prometheus-Instanz mit vertikalem 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 sehen Sie 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 vertikalem 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 Cluster-Ressource spec, sodass im Feld verticalPodAutoscaling.prometheus die Verbindungseinstellungen für Ihren Prometheus-Server angegeben sind.

  3. Fügen Sie url dem Abschnitt prometheus hinzu und legen Sie ihn auf den vollqualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) für die Verbindung zu Prometheus innerhalb des Clusters fest:

    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:

    Vertikales Pod-Autoscaling unterstützt die folgenden drei Verbindungsmethoden:

    • Keine Authentifizierung
    • Basisauthentifizierung (Nutzername, Passwort)

    • Inhabertoken-Authentifizierung

    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

    So geben Sie die Basisauthentifizierung für Prometheus an:

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

      Das folgende Beispiel zeigt ein Secret, das die einfache Authentifizierung 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, damit das Quell-Secret und das Secret im Zielcluster immer synchronisiert sind. Das Secret wird aktualisiert, wenn das Quell-Secret aktualisiert wird.

    2. Aktualisieren Sie den Abschnitt prometheus.auth.basicAuth der Clusterspezifikation, damit er auf den Nutzernamen und das Passwort aus dem Feld data im Secret verweist.

      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 Verlaufsanbieter für das vertikale Pod-Autoscaling fungieren, sobald die benutzerdefinierte Clusterressource aktualisiert wird.

    Inhabertoken-Authentifizierung

    Gehen Sie so vor, um die Bearer-Token-Authentifizierung für Prometheus anzugeben:

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

      Das folgende Beispiel zeigt ein Secret, das die Bearer-Token-Authentifizierung 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, damit das Quell-Secret und das Secret im Zielcluster immer synchronisiert sind. Das Secret wird aktualisiert, wenn das Quell-Secret aktualisiert wird.

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

      Das folgende Beispiel zeigt einen bearerTokenAuth-Abschnitt, der auf das Bearer-Token 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 Verlaufsanbieter für das vertikale Pod-Autoscaling fungieren, sobald die benutzerdefinierte Clusterressource aktualisiert wird.

Verwendung von Prometheus deaktivieren

Wenn Sie die Verwendung von Prometheus mit vertikalem 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 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 vertikales Pod-Autoscaling verwenden:

  • Vertikales Pod-Autoscaling ist aufgrund der eingeschränkten Sichtbarkeit der tatsächlichen Arbeitsspeichernutzung der Arbeitslast noch nicht bereit für die Verwendung mit JVM-Arbeitslasten.
  • Für das Updater-Tool sind mindestens zwei Pod-Replikate für Deployments erforderlich, um Pods durch überarbeitete Ressourcenwerte zu ersetzen.
  • Der Updater aktualisiert Pods, die aufgrund von Out-Of-Memory-Fehlern (OOM) in einer Crash-Schleife hängen, nicht schnell.
  • Die InPlaceOrRecreate-Aktualisierungsrichtlinie für Pods ist eine Alphafunktion im vertikalen Pod-Autoscaling. Es wird versucht, Updates direkt durchzuführen. Wenn das nicht möglich ist, wird der Pod neu erstellt.

Nächste Schritte