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 ajuste de escala automático vertical de Pods analiza el uso de recursos histórico y actual para proporcionar recomendaciones, que puede mostrar o aplicar automáticamente actualizando los Pods. Esta función mejora la estabilidad y la rentabilidad ajustando 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 metal desnudo en ejecución.
  • Tienes acceso de kubectl al clúster.
  • El servidor de métricas está disponible en el clúster. Los clústeres de Bare Metal incluyen Metrics Server de forma predeterminada.

Habilitar el Ajuste de escala automático vertical de Pods

Habilita el ajuste de escala automático vertical de Pods en tu clúster de metal desnudo configurando una anotación de vista previa y la especificación del clúster:

  1. Agrega o actualiza la anotación de versión preliminar en el recurso personalizado de Cluster.

    Edita el recurso personalizado de Cluster 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 el spec del recurso personalizado Cluster 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: Es 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: Es la ruta de acceso al archivo de manifiesto VerticalPodAutoscaler.

    • KUBECONFIG: Es la ruta del archivo kubeconfig del clúster.

Información sobre 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 recomendación

En el modo de recomendación, el ajuste de escala automático vertical de Pods instala el componente de recomendación. 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 límites y solicitudes 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 a la siguiente muestra:

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

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

Modo de actualización automática

Cuando configuras enableUpdater enableUpdater en true, los controladores del ciclo de vida de equipos físicos implementan los componentes del actualizador y del 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 indica que el actualizador asigna la configuración de recursos actualizada en la creación del Pod. En el siguiente ejemplo de VerticalPodAutoscaler, se muestra cómo establecer 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 que use los valores recomendados de CPU y memoria que proporciona el recomendador. La actualización de recursos requiere la recreación del 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 equivale 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 locales con el mayor esfuerzo posible, pero puede recurrir a la recreación del Pod si no es posible realizar actualizaciones locales. Para obtener más información, consulta la documentación sobre el cambio de tamaño del pod in situ.

  • Initial: El actualizador solo asigna solicitudes de recursos en la creación del Pod 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 del 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 del contenedor hamster. En la muestra, también se muestra un ejemplo de un evento de desalojo de Pod, que se produce cuando el actualizador desalojó 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 la utilización de memoria del componente de recomendación del ajuste de escala automático vertical de Pods. Cuando configuras enableMemorySaver en true, el recomendador solo hace un seguimiento de las agregaciones y las calcula para los Pods que tienen un recurso personalizado VerticalPodAutoscaler coincidente.

La desventaja es que, cuando creas un recurso personalizado VerticalPodAutoscaler nuevo 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 está false de forma predeterminada para la mayoría de los tipos de clústeres, pero se establece en true para los clústeres perimetrales.

Usa Prometheus como proveedor de historial persistente

De forma predeterminada, el componente de recomendaciones mantiene en la memoria el historial de consumo de recursos de las cargas de trabajo que se ejecutan en el clúster y, periódicamente, guarda su estado en un recurso personalizado VerticalPodAutoscalerCheckpoint en etcd para proporcionar resistencia ante 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 al inicio o reinicio para recuperar datos históricos a largo plazo sobre el uso de recursos de todos los Pods administrados. Recuperar estos datos permite que el sistema de recomendación cree de inmediato su estado interno con un conjunto de datos enriquecido, lo que genera recomendaciones más fundamentadas 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 fundamentadas desde el principio para que puedas optimizar el uso de los recursos del clúster.

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

Puedes habilitar y, luego, 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 extraiga 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 recopilar métricas.

    Para permitir que Prometheus extraiga 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 objeto ClusterRole que contenga estas reglas y asegúrate de que esté vinculado a la cuenta de servicio de Prometheus correcta con un objeto 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 recopilar las siguientes métricas de cAdvisor:

    • container_cpu_usage_seconds_total
    • container_memory_working_set_bytes

    Las siguientes líneas definen los detalles de la extracción 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 recopilar 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 recopilar 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 activa como un volumen o una variable de entorno en el Pod del 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 del clúster con detalles para conectarte a tu instancia de Prometheus.

A continuación, se muestra 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 recuperar 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 Cluster spec para que el campo verticalPodAutoscaling.prometheus especifique la configuración de conexión de tu servidor de Prometheus.

  3. Agrega url a la sección prometheus y configúralo 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 y contraseña)

    • Autenticación con token del portador

    Sin autenticación

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

    Autenticación básica

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

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

      En el siguiente ejemplo, se muestra un objeto 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 garantizar que el secreto de origen y el secreto del clúster de destino estén siempre sincronizados. El Secret se actualiza cuando se actualiza el Secret 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 secreto.

      En el siguiente ejemplo, se muestra una sección basicAuth que hace referencia al nombre de usuario y la contraseña del 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 secreto. Las claves deben ser válidas y provenir del campo data del secreto.

    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 del portador

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

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

      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 garantizar que el secreto de origen y el secreto del clúster de destino estén siempre sincronizados. El Secret se actualiza cuando se actualiza el Secret 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 secreto.

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

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

Inhabilita el ajuste de escala automático vertical de Pods

Inhabilita el ajuste de escala automático vertical de Pods quitando sus recursos personalizados y su configuración del clúster:

  1. Borra los recursos personalizados de VerticalPodAutoscaler que hayas creado.

  2. Modifica el recurso personalizado Cluster y quita toda la sección verticalPodAutoscaling de spec.

    Puedes editar el recurso personalizado de Cluster 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 Cluster.

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 real de la memoria de la carga de trabajo.
  • El actualizador requiere un mínimo de dos réplicas de Pod para que los Deployments reemplacen los Pods con valores de recursos revisados.
  • El actualizador no actualiza rápidamente los Pods que se encuentran en un bucle de fallas debido a errores de memoria insuficiente (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 recurrir a la recreación del Pod si no es posible realizar actualizaciones en el lugar.

¿Qué sigue?