Configura el ajuste de escala automático vertical de Pods

El ajuste de escala automático vertical de Pods automatiza la configuración de las solicitudes y los límites de recursos de CPU y memoria para los contenedores dentro de los Pods de Kubernetes. El escalado automático vertical de Pods analiza el uso de recursos históricos y actuales para proporcionar recomendaciones, que puede mostrar o aplicar automáticamente actualizando los Pods. Esta función mejora la estabilidad y la rentabilidad al ajustar el tamaño de las asignaciones de recursos.

Antes de comenzar

Antes de configurar el ajuste de escala automático vertical de Pods, asegúrate de cumplir con los siguientes requisitos previos:

  • Tienes un clúster de Bare Metal en ejecución.
  • Tienes acceso a kubectl al clúster.
  • Metrics Server está disponible en el clúster. Los clústeres de Bare Metal incluyen Metrics Server de forma predeterminada.

Habilita el Ajuste de escala automático vertical de Pods

Para habilitar el ajuste de escala automático vertical de Pods en tu clúster de Bare Metal, configura una anotación de vista previa y configura la especificación del clúster:

  1. Agrega o actualiza la anotación de vista previa en el recurso personalizado del clúster.

    Edita el recurso personalizado del clúster directamente o modifica el archivo de configuración del clúster y usa bmctl update.

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

  2. Modifica la spec del recurso personalizado del clúster para incluir el campo verticalPodAutoscaling y especificar los modos enableUpdater y enableMemorySaver:

    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. Si modificaste el archivo de configuración del clúster, aplica los cambios con el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre de tu clúster.

    • KUBECONFIG: La ruta de acceso del archivo kubeconfig del clúster.

Crea un recurso personalizado VerticalPodAutoscaler

Después de habilitar el ajuste de escala automático vertical de Pods en tu clúster, define un recurso personalizado VerticalPodAutoscaler para segmentar cargas de trabajo específicas:

  1. Define un recurso VerticalPodAutoscaler en el mismo espacio de nombres que la carga de trabajo de destino.

    Este recurso personalizado especifica a qué Pods se dirige con targetRef y cualquier política de recursos.

    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. Aplica el manifiesto VerticalPodAutoscaler con el siguiente comando:

    kubectl apply -f VPA_MANIFEST \
    --kubeconfig KUBECONFIG

    Reemplaza lo siguiente:

    • VPA_MANIFEST: La ruta de acceso del archivo de manifiesto VerticalPodAutoscaler.

    • KUBECONFIG: La ruta de acceso del archivo kubeconfig del clúster.

Comprende los modos de ajuste de escala automático vertical de Pods

El ajuste de escala automático vertical de Pods opera en diferentes modos que controlan cómo aplica las recomendaciones de recursos.

Modo de recomendaciones

En el modo de recomendaciones, el ajuste de escala automático vertical de Pods instala el componente de recomendador. Este componente analiza el uso de recursos y publica valores recomendados para las solicitudes y los límites de CPU y memoria en la sección de estado de los recursos personalizados VerticalPodAutoscaler que creas.

Para ver las recomendaciones de solicitudes y límites de recursos, usa el siguiente comando:

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.

La respuesta debe contener una sección Status similar al siguiente ejemplo:

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

Los Pods no se actualizan automáticamente en este modo. Usa estas recomendaciones para actualizar manualmente las configuraciones de tus Pods. Este es el comportamiento predeterminado si enableUpdater no está configurado o es false.

Modo de actualización automática

Cuando configuras enableUpdater enableUpdater como true, los controladores del ciclo de vida de Bare Metal implementan los componentes de actualizador y controlador de admisión del ajuste de escala automático vertical de Pods , además del recomendador. El actualizador supervisa los Pods cuyas solicitudes de recursos actuales se desvían significativamente de las recomendaciones.

La política de actualización en el recurso VerticalPodAutoscaler especifica cómo el actualizador aplica las recomendaciones. De forma predeterminada, el modo de actualización es Auto, que dicta que el actualizador asigna parámetros de configuración de recursos actualizados en la creación de Pods. En el siguiente ejemplo de VerticalPodAutoscaler, se muestra cómo configurar el modo de actualización en Initial:

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

El actualizador admite los siguientes cinco modos:

  • Auto: El actualizador expulsa el Pod. El controlador de admisión intercepta la solicitud de creación del Pod nuevo y la modifica para usar los valores recomendados de CPU y memoria que proporciona el recomendador. La actualización de recursos requiere volver a crear el Pod, lo que puede causar interrupciones. Usa presupuestos de interrupción de Pods , que el actualizador respeta, para administrar el proceso de expulsión. Este modo es equivalente a Recreate.

  • Recreate: El actualizador expulsa los Pods y asigna solicitudes y límites de recursos recomendados cuando se vuelve a crear el Pod.

  • InPlaceOrRecreate(alfa): El actualizador intenta realizar actualizaciones en el lugar con el mejor esfuerzo, pero puede volver a crear el Pod si las actualizaciones en el lugar no son posibles. Para obtener más información, consulta la documentación sobre el cambio de tamaño de Pods in-place.

  • Initial: El actualizador solo asigna solicitudes de recursos en la creación de Pods y nunca las cambia más adelante.

  • Off: El actualizador no cambia automáticamente los requisitos de recursos de los Pods. Las recomendaciones se calculan y se pueden inspeccionar en el objeto VerticalPodAutoscaler.

Para obtener más información sobre el recurso personalizado VerticalPodAutoscaler, usa kubectl para recuperar la definición de recurso personalizado verticalpodautoscalercheckpoints.autoscaling.k8s.io que está instalada en el clúster de la versión 1.33.0 o posterior.

En el siguiente ejemplo, se muestra cómo podrían aparecer las recomendaciones de recursos en la sección Status para el contenedor hamster. En el ejemplo, también se muestra un evento de expulsión de Pods, que ocurre cuando el actualizador expulsa un Pod antes de asignar automáticamente la configuración de recursos recomendada al Pod recreado:

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.

Modo de ahorro de memoria

El modo de ahorro de memoria reduce el espacio en memoria del componente de recomendador del escalado automático vertical de Pods. Cuando configuras enableMemorySaver como true, el recomendador solo realiza un seguimiento y calcula las agregaciones de los Pods que tienen un recurso personalizado VerticalPodAutoscaler coincidente.

La desventaja es que, cuando creas un nuevo recurso personalizado VerticalPodAutoscaler para una carga de trabajo existente, el recomendador tarda un tiempo (hasta 24 horas) en recopilar el historial suficiente para proporcionar recomendaciones precisas. Este modo es false de forma predeterminada para la mayoría de los tipos de clústeres, pero se establece en true de forma predeterminada para los clústeres perimetrales.

Usa Prometheus como proveedor de historial persistente

De forma predeterminada, el componente de recomendador mantiene el historial de consumo de recursos de las cargas de trabajo que se ejecutan en el clúster en la memoria y, de forma periódica, guarda su estado en un recurso personalizado VerticalPodAutoscalerCheckpoint en etcd para proporcionar resiliencia contra los reinicios.

A partir de la versión 1.34 de Google Distributed Cloud, puedes usar tu propia instancia de Prometheus como proveedor de historial persistente para los datos de consumo de recursos, es decir, las métricas de uso de CPU y memoria. Cuando se habilita esta integración, el recomendador puede consultar el servidor de Prometheus cuando se inicia o reinicia para recuperar datos históricos de uso de recursos a largo plazo para todos los Pods administrados. La recuperación de estos datos permite que el recomendador compile de inmediato su estado interno con un conjunto de datos enriquecido, lo que genera recomendaciones más informadas y precisas desde el principio.

Usar Prometheus como proveedor de historial persistente ofrece las siguientes ventajas:

  • Optimización del uso de recursos: genera recomendaciones precisas y bien informadas en cuanto se inicia para que puedas optimizar el uso de recursos del clúster.

  • Prevención de errores de falta de memoria (OOM): Prometheus elimina la necesidad de almacenar el estado interno del recomendador en recursos personalizados (CRs) VerticalPodAutoscalerCheckpoint, lo que hace que el uso de la memoria de ETCD sea más eficiente. Cuando se reinicia el componente de recomendador, pierde los datos históricos en la memoria. Cuando usas Prometheus como proveedor de historial, el recomendador recupera las métricas históricas de Prometheus en el reinicio, lo que elimina la necesidad del CR VerticalPodAutoscalerCheckpoint y guarda la memoria de ETCD.

Puedes habilitar y inhabilitar el uso de Prometheus como proveedor de historial persistente en cualquier momento.

Requisitos previos para usar Prometheus con el ajuste de escala automático vertical de Pods

Para usar tu propia instancia de Prometheus como proveedor de historial para el ajuste de escala automático vertical de Pods, debes configurarla para que analice las métricas necesarias, lo que implica los siguientes pasos:

  1. Si es necesario, implementa el operador de Prometheus en el clúster para el que deseas usarlo como proveedor de historial persistente para el ajuste de escala automático vertical de Pods. Para obtener más información, consulta Cómo implementar y configurar el operador de Prometheus en Kubernetes.

  2. Configura los permisos para analizar las métricas.

    Para permitir que Prometheus analice las métricas de cAdvisor con un archivo de configuración, debes otorgar permisos adicionales a la cuenta de servicio que usa el servidor de Prometheus. Crea o actualiza un ClusterRole que contenga estas reglas y asegúrate de que esté vinculado a la cuenta de servicio de Prometheus correcta con un ClusterRoleBinding:

    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. Actualiza el archivo de configuración de Prometheus para analizar las siguientes métricas de cAdvisor:

    • container_cpu_usage_seconds_total
    • container_memory_working_set_bytes

    Las siguientes líneas definen los detalles del análisis para las métricas de cAdvisor:

    - 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. Actualiza el archivo de configuración de Prometheus para analizar la siguiente métrica del servicio kube-state-metrics:

    • kube_pod_labels

    1. Implementa un servicio kube-state-metrics en tu clúster.

      Puedes usar los siguientes comandos de Helm para instalar el nuevo servicio:

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

    2. Crea un archivo ksm-values.yaml con el siguiente contenido:

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

    3. Instala un gráfico de Helm basado en el archivo de valores del paso anterior:

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

    4. Agrega las siguientes líneas al archivo de configuración de Prometheus para analizar la métrica kube_pod_labels del servicio kube-state-metrics instalado:

      - 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

Habilita y usa Prometheus

El ajuste de escala automático vertical de Pods admite la autenticación básica y la autenticación basada en tokens de portador para conectarse a Prometheus. Cuando usas la autenticación, debes crear un Secret que contenga las credenciales necesarias en el espacio de nombres del clúster. El controlador reenvía este Secret al clúster de destino y lo instala como un volumen o una variable de entorno en el Pod de recomendador. También puedes usar Prometheus sin autenticación.

Para habilitar y usar tu propia instancia de Prometheus con el ajuste de escala automático vertical de Pods, debes configurar la sección verticalPodAutoscaling en la especificación de tu clúster con detalles para conectarte a tu instancia de Prometheus.

Este es un ejemplo de la configuración en la especificación del clúster para usar con un token de portador:

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

Para habilitar Prometheus para usarlo con el ajuste de escala automático vertical de Pods, haz lo siguiente:

  1. Asegúrate de que tu instancia de Prometheus esté configurada para analizar las métricas requeridas, como se describe en Requisitos previos para usar Prometheus con el ajuste de escala automático vertical de Pods

  2. Actualiza el recurso personalizado del clúster spec para que el verticalPodAutoscaling.prometheus campo especifique la configuración de conexión de tu servidor de Prometheus.

  3. Agrega la url a la sección prometheus y configúrala con el nombre de dominio completamente calificado (FQDN) para conectarte a Prometheus desde el clúster:

    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. Especifica los detalles de la conexión:

    El ajuste de escala automático vertical de Pods admite los siguientes tres métodos de conexión:

    • Sin autenticación
    • Autenticación básica (nombre de usuario, contraseña)

    • Autenticación con token de portador

    Sin autenticación

    Si tu instancia de Prometheus no requiere autenticación, ya terminaste. La sección prometheus solo debe incluir un campo url.

    Autenticación básica

    Sigue estos pasos para especificar la autenticación básica para Prometheus:

    1. Crea un Secret que contenga un nombre de usuario y una contraseña en la stringData sección y la baremetal.cluster.gke.io/mark-source: "true" anotación.

      En el siguiente ejemplo, se muestra un Secret que admite la autenticación básica:

      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

      La anotación es necesaria para asegurarse de que el secreto de origen y el secreto en el clúster de destino estén siempre sincronizados. El Secret se actualiza cuando se actualiza el secreto de origen.

    2. Actualiza la sección prometheus.auth.basicAuth de la especificación del clúster para hacer referencia al nombre de usuario y la contraseña del campo data en el Secret.

      En el siguiente ejemplo, se muestra una sección basicAuth que hace referencia al nombre de usuario y la contraseña en el Secret del paso anterior:

      # ... 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

      El nombre de usuario y la contraseña deben estar en el mismo Secret. Las claves deben ser claves válidas del campo data del Secret.

    La instancia de Prometheus debería comenzar a funcionar como proveedor de historial para el ajuste de escala automático vertical de Pods cuando se actualice el recurso personalizado del clúster.

    Autenticación con token de portador

    Sigue estos pasos para especificar la autenticación con token de portador para Prometheus:

    1. Crea un Secret que contenga un token de portador en la stringData sección y la baremetal.cluster.gke.io/mark-source: "true" anotación.

      En el siguiente ejemplo, se muestra un Secret que admite la autenticación con token de portador:

      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"

      La anotación es necesaria para asegurarse de que el secreto de origen y el secreto en el clúster de destino estén siempre sincronizados. El Secret se actualiza cuando se actualiza el secreto de origen.

    2. Actualiza la sección prometheus.auth.bearerTokenAuth de la especificación del clúster para hacer referencia al token de portador del campo data en el Secret.

      En el siguiente ejemplo, se muestra una sección bearerTokenAuth que hace referencia al token de portador en el Secret del paso anterior:

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

      La clave debe ser una clave válida del campo data del Secret.

    La instancia de Prometheus debería comenzar a funcionar como proveedor de historial para el ajuste de escala automático vertical de Pods cuando se actualice el recurso personalizado del clúster.

Inhabilita el uso de Prometheus

Para inhabilitar el uso de Prometheus con el ajuste de escala automático vertical de Pods, quita la sección prometheus de la sección verticalPodAutoscaling del recurso personalizado del clúster.

Inhabilita el Ajuste de escala automático vertical de Pods

Para inhabilitar el Ajuste de escala automático vertical de Pods, quita sus recursos personalizados y su configuración de tu clúster:

  1. Borra los recursos personalizados VerticalPodAutoscaler que hayas creado.

  2. Modifica el recurso personalizado del clúster y quita toda la sección verticalPodAutoscaling de la spec.

    Puedes editar el recurso personalizado del clúster directamente o modificar el archivo de configuración del clúster y usar bmctl update.

  3. Quita la anotación preview.baremetal.cluster.gke.io/vertical-pod-autoscaler del recurso personalizado del clúster.

Limitaciones

Ten en cuenta las siguientes limitaciones cuando uses el Ajuste de escala automático vertical de Pods:

  • El ajuste de escala automático vertical de Pods aún no está listo para usarse con cargas de trabajo basadas en JVM debido a la visibilidad limitada del uso de memoria real de la carga de trabajo.
  • El actualizador requiere un mínimo de dos réplicas de Pods para que las implementaciones reemplacen los Pods con valores de recursos revisados.
  • El actualizador no actualiza rápidamente los Pods que están en un bucle de fallas debido a errores de falta de memoria (OOM).
  • La política de actualización InPlaceOrRecreate para Pods es una función alfa dentro del ajuste de escala automático vertical de Pods. Intenta realizar actualizaciones en el lugar con el mejor esfuerzo, pero puede volver a crear el Pod si las actualizaciones en el lugar no son posibles.

¿Qué sigue?