Configura búferes de capacidad

Los búferes de capacidad mejoran la capacidad de respuesta y la confiabilidad de las cargas de trabajo críticas, ya que administran de forma proactiva la capacidad de reserva del clúster y los estados suspendidos de la capacidad aprovisionada y configurada previamente con una definición de recurso personalizado (CRD) de CapacityBuffer de Kubernetes. El uso de búferes de capacidad te permite definir de forma explícita una cantidad específica de capacidad de nodo sin usar dentro de tu clúster. Esta capacidad reservada ayuda a reducir el tiempo de programación de los Pods.

Cuando una carga de trabajo de alta prioridad necesita escalar verticalmente con rapidez, la nueva carga de trabajo puede usar la capacidad vacía de inmediato sin esperar el aprovisionamiento de nodos. Este enfoque minimiza la latencia y evita la contención de recursos durante los aumentos repentinos de la demanda.

En esta página, se proporcionan métodos para configurar búferes de capacidad: un búfer de réplicas fijo, un búfer de límites de recursos y un búfer basado en porcentajes.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste la gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.
  • Crea un clúster de GKE que cumpla con los siguientes requisitos de versión o asegúrate de tener acceso a él:
    • Para los búferes activos, usa la versión 1.35.2-gke.1842000 o posterior en clústeres Standard y Autopilot.
    • Para los búferes de reserva, usa la versión 1.36.0-gke.2253000 o posterior en los clústeres Standard, o la versión 1.36.0-gke.2853000 o posterior en los clústeres de Autopilot con ComputeClasses personalizadas.
  • Habilita el aprovisionamiento automático de nodos en tus clústeres de Standard. En los clústeres de Autopilot, el aprovisionamiento automático de nodos ya está habilitado. El aprovisionamiento automático de nodos es opcional, pero se recomienda para los búferes activos y es obligatorio para los búferes en espera.

Crea objetos de Kubernetes de requisitos previos

Para configurar un CapacityBuffer, necesitas un espacio de nombres que contenga todos los objetos requeridos (el CapacityBuffer en sí y recursos adicionales, como una PodTemplate o una carga de trabajo). PodTemplate y CapacityBuffer deben estar en el mismo espacio de nombres. Puedes crear un espacio de nombres o usar uno existente, incluido el espacio de nombres default.

Según el tipo de CapacityBuffer que configures, también necesitarás uno de los siguientes elementos:

  • PodTemplate: Define los requisitos de recursos para una sola unidad de capacidad de búfer. La configuración especificada en el objeto CapacityBuffer hace referencia a la plantilla de Pod.

  • Carga de trabajo: Es una carga de trabajo existente a la que haces referencia en el objeto CapacityBuffer. En esta guía, se usa un objeto Deployment como ejemplo de carga de trabajo, pero los búferes de capacidad admiten cualquiera de los siguientes tipos de recursos:

    • Implementación
    • ReplicaSet
    • StatefulSet
    • ReplicationController
    • Trabajo

    • CustomResourceDefinitions (CRD) que implementan el subrecurso scale.

En esta sección, se proporcionan ejemplos de estos objetos. Si ya tienes una carga de trabajo que deseas configurar con un búfer de capacidad, continúa con Aplica un búfer de capacidad.

Para crear una carga de trabajo de Kubernetes de ejemplo, completa los siguientes pasos:

  1. Guarda el siguiente manifiesto como namespace.yaml:

    apiVersion: v1
kind: Namespace
metadata:
  name: capacity-buffer-example
  labels:
    name: capacity-buffer-example

    Este manifiesto crea un espacio de nombres llamado capacity-buffer-example.

  2. Opcional: Para usar búferes de capacidad con una ComputeClass personalizada, guarda el siguiente manifiesto como custom-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: ccc-example
spec:
  # Buffers are also created according to these priorities
  priorities:
  - machineFamily: n4
  - machineFamily: n4d
  - machineFamily: c4
  - machineFamily: c4d
  nodePoolAutoCreation:
    enabled: true

    Este manifiesto crea un ComputeClass personalizado que define y controla las prioridades de procesamiento para los nodos que GKE aprovisiona. Para obtener más información, consulta ComputeClasses personalizadas.

  3. Guarda el siguiente manifiesto como buffer-pod-template.yaml:

    apiVersion: v1
kind: PodTemplate
metadata:
  name: buffer-unit-template
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
template:
  spec:
    terminationGracePeriodSeconds: 0
    containers:
    - name: buffer-container
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "1"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "1Gi"
    # Optional: Using buffers with a custom ComputeClass /
    # controls the properties of the provisioned nodes.
    nodeSelector:
      cloud.google.com/compute-class: ccc-example

    Este manifiesto crea un PodTemplate que define los requisitos de recursos para una sola unidad de capacidad de búfer (1 CPU y 1Gi de memoria). Esta configuración especifica el tamaño de las unidades de capacidad que GKE aprovisiona para el búfer. Por ejemplo, con este PodTemplate, GKE no considerará los nodos con menos de 1 CPU y 1 Gi de recursos disponibles como parte del búfer si el clúster se escala verticalmente.

  4. Guarda el siguiente manifiesto como sample-workload-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: critical-workload-ref
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
spec:
  replicas: 10
  selector:
    matchLabels:
      app: critical-workload
  template:
    metadata:
      labels:
        app: critical-workload
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["sleep", "3600"]
        resources:
          requests:
            cpu: 100m
      # Optional: Using buffers with a custom ComputeClass /
      # controls the properties of the provisioned nodes.
      nodeSelector:
        cloud.google.com/compute-class: ccc-example

    En este manifiesto, se crea un Deployment de muestra con 10 réplicas, que es el objeto de referencia para el ejemplo de búfer basado en porcentajes de la siguiente sección.

  5. Aplica los manifiestos a tu clúster.

    kubectl apply -f namespace.yaml -f custom-compute-class.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml

  6. Verifica que GKE haya creado los objetos:

    kubectl get podtemplate -n capacity-buffer-example
kubectl get deployment critical-workload-ref -n capacity-buffer-example

    El resultado es similar a lo siguiente:

    NAME                   AGE
buffer-unit-template   1m

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
critical-workload-ref   10/10   10           10          1m

Aplica un búfer de capacidad

En esta sección, se proporcionan ejemplos de los diferentes tipos de búferes de capacidad que puedes aplicar a tus cargas de trabajo.

Configura un búfer de réplicas fijo

Configurar un CapacityBuffer con réplicas fijas especifica la cantidad exacta de unidades de búfer que deseas según una PodTemplate.

Para crear un búfer con réplicas fijas, completa los siguientes pasos:

  1. Guarda el siguiente manifiesto como cb-fixed-replicas.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: fixed-replica-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  replicas: 3
  provisioningStrategy: "STRATEGY"

    Reemplaza lo siguiente:

    • NAMESPACE: Es el nombre de tu espacio de nombres, por ejemplo, capacity-buffer-example.
    • POD_TEMPLATE: Es la PodTemplate que define los requisitos de recursos, por ejemplo, buffer-unit-template.
    • STRATEGY: Es la estrategia de aprovisionamiento, ya sea "buffer.x-k8s.io/active-capacity" (predeterminada) o "buffer.gke.io/standby-capacity".

    Este manifiesto crea un recurso CapacityBuffer que hace referencia a un PodTemplate para solicitar una cantidad específica de unidades de búfer.

  2. Aplica el manifiesto

    kubectl apply -f cb-fixed-replicas.yaml

  3. Confirma que GKE haya aplicado el búfer de capacidad:

    kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE

    El campo replicas en el estado debería mostrar 3, que refleja la cantidad de réplicas que definiste en el manifiesto. El campo STATUS debe mostrar ReadyForProvisioning.

Configura un búfer de límites de recursos

Puedes usar el campo limits para definir una cantidad máxima de recursos que debe consumir el búfer, calculada en función del tamaño de tu PodTemplate.

Para crear un búfer de límites de recursos, completa los siguientes pasos:

  1. Guarda el siguiente manifiesto como cb-resource-limits.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: resource-limit-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  limits:
    cpu: "5"
    memory: "5Gi"
  provisioningStrategy: "STRATEGY"

    Reemplaza lo siguiente:

    • NAMESPACE: Es el nombre de tu espacio de nombres, por ejemplo, capacity-buffer-example.
    • POD_TEMPLATE: Es la PodTemplate que define los requisitos de recursos, por ejemplo, buffer-unit-template.
    • STRATEGY: Es la estrategia de aprovisionamiento, ya sea "buffer.x-k8s.io/active-capacity" (predeterminada) o "buffer.gke.io/standby-capacity".

    Este manifiesto crea un recurso CapacityBuffer con un límite total de 5 CPU y 5 GiB de memoria. Si usas el ejemplo de PodTemplate del paso anterior, defines cada unidad como CPU 1 y memoria 1Gi, lo que debería dar como resultado 5 unidades de búfer.

  2. Aplica el manifiesto

    kubectl apply -f cb-resource-limits.yaml

  3. Confirma que GKE haya aplicado el búfer de capacidad:

    kubectl get capacitybuffer resource-limit-buffer -n NAMESPACE

    Verifica el estado de CapacityBuffer. El campo replicas debe mostrar un valor derivado de los límites que definiste. Si usas el ejemplo de PodTemplate de la sección anterior, deberías ver 5 unidades de búfer, ya que esta es la cantidad máxima de unidades que se ajustan a los límites definidos.

Configura un búfer basado en porcentajes

Configurar un búfer basado en un porcentaje ajusta dinámicamente el tamaño del búfer según un porcentaje de una carga de trabajo escalable existente. Los búferes de capacidad basados en porcentajes solo se admiten para objetos escalables de Kubernetes que implementan el subrecurso de escalamiento, como Deployments, StatefulSets, ReplicaSets o Jobs. No puedes definir un búfer basado en porcentajes para las plantillas de Pod porque no tienen un campo replicas.

En la mayoría de los casos, comienza con réplicas fijas o estrategias de límite de recursos, en lugar de búferes basados en porcentajes. Ten en cuenta lo siguiente cuando decidas:

  • Los búferes basados en porcentajes son menos responsivos a los aumentos de escala repentinos si la carga de trabajo se escala a números bajos o a cero, ya que el margen de seguridad disminuye en proporción a los Pods activos.
  • Los nodos en espera generan cargos de procesamiento durante su período de inicialización antes de suspenderse. El ajuste de escala dinámico de los búferes en espera junto con las fluctuaciones de la carga de trabajo desperdicia recursos de procesamiento, por lo que, en su lugar, usa réplicas fijas o límites de recursos para los búferes en espera.
  • Los búferes basados en porcentajes son útiles, principalmente, para los búferes activos en implementaciones grandes que nunca se reducen a recuentos de réplicas bajos.

En la versión 1.36.3-gke.1244000 y posteriores de GKE, para mantener un tamaño de búfer mínimo cuando la carga de trabajo a la que se hace referencia reduce su escala verticalmente, configura el campo replicas junto con el campo percentage. GKE usa el campo que genere más unidades de búfer. Para limitar el tamaño del búfer, también debes configurar el campo limits.

Por ejemplo, considera un búfer con percentage: 20 y replicas: 3 que hace referencia a un Deployment con 10 réplicas. Como el 20% de 10 réplicas es 2, que es menor que el valor de replicas de 3, GKE aprovisiona 3 unidades de búfer. Si el Deployment se escala a 20 réplicas, el búfer aumenta a 4 unidades. Para obtener más información, consulta la documentación de referencia de CapacityBuffer.

Para crear un búfer basado en porcentajes, completa los siguientes pasos:

  1. Guarda el siguiente manifiesto como cb-percentage-based.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: percentage-buffer
  namespace: NAMESPACE
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: SCALABLE_RESOURCE_NAME
  percentage: 20
  provisioningStrategy: "STRATEGY"

    Reemplaza lo siguiente:

    • NAMESPACE: Es el nombre de tu espacio de nombres.
    • SCALABLE_RESOURCE_NAME: Es el nombre de tu recurso escalable, por ejemplo, critical-workload-ref.
    • STRATEGY: Es la estrategia de aprovisionamiento, ya sea "buffer.x-k8s.io/active-capacity" (predeterminada) o "buffer.gke.io/standby-capacity".

    Este manifiesto crea un recurso CapacityBuffer que solicita un tamaño de búfer equivalente al 20% de las réplicas del recurso al que se hace referencia. Si usas el ejemplo de Deployment de la sección anterior, el valor de la réplica se establece en 10.

  2. Aplica el manifiesto

    kubectl apply -f cb-percentage-based.yaml

  3. Confirma que GKE haya aplicado el búfer de capacidad:

    kubectl get capacitybuffer percentage-buffer -n NAMESPACE

    Verifica el estado de CapacityBuffer. El campo replicas debe mostrar un valor del cálculo de porcentaje. Si usas el ejemplo de Deployment de la sección anterior, deberías ver 2 unidades de búfer, que es el 20% de las 10 réplicas definidas en el Deployment.

  4. Prueba el escalamiento dinámico aumentando manualmente la escala del Deployment a 20 réplicas:

    kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20

    El controlador de CapacityBuffer reacciona y ajusta automáticamente el búfer a 4 réplicas.

Personaliza el comportamiento del búfer en espera

Puedes usar anotaciones para personalizar la forma en que se inician y actualizan los búferes en espera. Agrega estas anotaciones al campo metadata.annotations de tu recurso CapacityBuffer:

  • buffer.gke.io/standby-capacity-init-time: Es la cantidad de tiempo que un nodo permanece activo después de su creación antes de que GKE lo suspenda. Especifica una cadena de duración, como 5m o 1h. El valor predeterminado es 5m.

  • buffer.gke.io/standby-capacity-refresh-frequency: Indica con qué frecuencia GKE actualiza los nodos suspendidos. Especifica una cadena de duración, como 12h o 24h. El valor predeterminado es 24h.

En el siguiente ejemplo, se muestra un manifiesto con estos campos opcionales para personalizar el comportamiento de los búferes en espera:

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: customized-standby-buffer
  namespace: my-namespace
  annotations:
    buffer.gke.io/standby-capacity-init-time: "15m"
    buffer.gke.io/standby-capacity-refresh-frequency: "12h"
spec:
  podTemplateRef:
    name: buffer-unit-template
  replicas: 3
  provisioningStrategy: "buffer.gke.io/standby-capacity"

Carga previamente las imágenes en búferes en espera

Para acelerar los tiempos de inicio de las cargas de trabajo cuando se reanuda un nodo en espera, puedes precargar imágenes de contenedor con un DaemonSet. DaemonSet se ejecuta durante el período de inicio antes de que se suspenda el nodo.

Para precargar imágenes con DaemonSet, completa los siguientes pasos:

  1. Guarda el siguiente manifiesto como image-puller-daemonset.yaml:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-prefetch-daemonset
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      name: image-prefetch
  template:
    metadata:
      labels:
        name: image-prefetch
    spec:
      tolerations:
      - key: "buffer.gke.io/standby-capacity-node-suspended"
        operator: "Exists"
      initContainers:
      - name: image-puller
        image: IMAGE_NAME
        command: ["sh", "-c", "true"]
      containers:
      - name: pause
        image: registry.k8s.io/pause:3.9

    Reemplaza lo siguiente:

    • NAMESPACE: Es el espacio de nombres del DaemonSet, por ejemplo, capacity-buffer-example.
    • IMAGE_NAME: Es el nombre de la imagen que se cargará previamente, por ejemplo, your-app-image:latest.

    Este manifiesto incluye la tolerancia buffer.gke.io/standby-capacity-node-suspended para que el DaemonSet siga programado en los nodos en espera después de que GKE los suspenda.

  2. Aplica el manifiesto de DaemonSet a tu clúster:

    kubectl apply -f image-puller-daemonset.yaml

  3. Verifica que se haya creado el DaemonSet:

    kubectl get daemonset image-prefetch-daemonset -n NAMESPACE

  4. Verifica que el búfer de capacidad se haya creado y esté listo para el aprovisionamiento:

    kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

    Verifica el estado. El campo STATUS debe mostrar ReadyForProvisioning.

Supervisa el estado y el rendimiento del búfer de capacidad

Puedes supervisar el estado y el buen funcionamiento de tus búferes de capacidad con los comandos de kubectl y las métricas de Cloud Monitoring.

Verifica el estado del recurso CapacityBuffer

Para verificar el estado de tus búferes de capacidad y confirmar que están listos para recibir cargas de trabajo, completa los siguientes pasos:

  1. Obtén el estado de todos los búferes de capacidad en el clúster:

    kubectl get capacitybuffer -A

  2. Inspecciona el estado detallado, las condiciones y los registros de eventos de un búfer específico:

    kubectl describe capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Identifica los nodos de búfer en espera suspendidos

Las VMs de búfer en espera se aprovisionan con anticipación, pero se mantienen en un estado suspendido para ayudar a reducir los costos. Puedes reconocer estos nodos suspendidos porque tienen una condición personalizada. Para auditar las instancias de nodo suspendidas, ejecuta el siguiente comando:

kubectl get nodes -o custom-columns='NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status'

El estado True indica que una VM en espera está suspendida. El estado False o <none> indica que el nodo está activo y en ejecución.

Supervisa el rendimiento con Cloud Monitoring

Para supervisar el impacto de extremo a extremo de los búferes de capacidad en los tiempos de escalamiento vertical, usa los paneles de Latencia de inicio en la consola de Google Cloud . Usa los gráficos Distribución de la latencia de inicio de Pods y Latencia de inicio de Pods para hacer un seguimiento de la métrica kubernetes.io/pod/latencies/pod_first_ready desde la creación de los Pods hasta que estén listos. También puedes consultar los eventos Scheduled en Cloud Logging para medir la latencia de programación de Pods. Para obtener instrucciones, consulta Supervisa las métricas de latencia de inicio.

Quita los búferes de capacidad

Si ya no necesitas un búfer de capacidad para tus cargas de trabajo, borra el objeto CapacityBuffer. Esto quita los Pods de marcador de posición y permite que el escalador automático del clúster reduzca la escala verticalmente de los nodos.

kubectl delete capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Reemplaza CAPACITY_BUFFER_NAME por el nombre del CapacityBuffer que deseas borrar.

Soluciona problemas

En la siguiente sección, se incluye información para resolver problemas habituales con los búferes de capacidad.

El búfer de capacidad no está listo debido al modelo de facturación

Si creas un CapacityBuffer para una carga de trabajo que usa el modelo de facturación basado en Pods (pago por Pod), el búfer de capacidad no estará listo para el aprovisionamiento.

Para identificar este problema, verifica el estado de CapacityBuffer:

kubectl describe capacitybuffer BUFFER_NAME -n NAMESPACE

Busca una condición del tipo ReadyForProvisioning con un estado de False.

Para resolver este problema, asegúrate de que tu CapacityBuffer haga referencia a una carga de trabajo o un PodTemplate que sea compatible con la facturación basada en nodos.

Errores de permisos para recursos escalables personalizados

Si configuras un CapacityBuffer para que funcione con objetos escalables personalizados (con el campo scalableRef), es posible que el escalador automático del clúster no pueda escalar el búfer si no tiene los permisos necesarios. Este problema solo ocurre en las versiones de GKE anteriores a la 1.36.0-gke.2459000.

Para resolver este problema, otorga de forma manual los permisos necesarios creando un ClusterRole y un ClusterRoleBinding, como en el siguiente ejemplo:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-scale-getter
rules:
- apiGroups: ["api.example.com"]
  resources: ["customreplicatedresources/scale"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ca-custom-scale-getter
subjects:
- kind: User
  name: "system:cluster-autoscaler"
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-scale-getter

Para obtener más información sobre cómo configurar el RBAC, consulta la documentación de RBAC de Kubernetes.

Los Pods de búfer no se programan en nodos aprovisionados por ComputeClasses personalizadas

Si la dependencia de configuración de CapacityBuffer (por ejemplo, un PodTemplate) selecciona una ComputeClass personalizada, es posible que encuentres un problema en el que los Pods de búfer no se programen en los nodos recién aprovisionados. Este problema hace que el escalador automático del clúster cree repetidamente grupos de nodos y nodos redundantes mientras se borran los nodos inactivos.

Este problema se produce si la ComputeClass personalizada aprovisiona nodos con taints o requisitos de entorno de ejecución específicos, y tus Pods de búfer (o la PodTemplate en la que se basan) no tienen tolerancias o parámetros de configuración que coincidan.

Para resolver este problema, actualiza la configuración de CapacityBuffer para especificar las tolerancias, los selectores de nodos o las clases de entorno de ejecución requeridos. Por ejemplo, si tu dependencia selecciona una ComputeClass personalizada configurada con GKE Sandbox, actualiza la dependencia para que realice una de las siguientes acciones:

  • Especifica el campo spec.runtimeClassName: gvisor.
  • Incluye una tolerancia explícita para el taint sandbox.gke.io/runtime=gvisor:NoSchedule.

Para obtener más información, consulta la documentación de ComputeClass personalizada.

Los nodos de búfer en espera no se reanudan

Es posible que los nodos de búfer en espera suspendidos no se reanuden por uno de los siguientes motivos:

  • Para reanudar un nodo en espera suspendido, se requiere capacidad disponible de Compute Engine en la zona para el tipo de máquina del nodo y la generación de la plataforma de CPU específica, como dentro de la serie de máquinas E2 o N2. Si la zona no tiene capacidad de procesamiento suficiente para esa configuración exacta, el nodo no se reanudará. Para obtener más información, consulta Limitaciones de suspensión y reanudación de Compute Engine.
  • Si tu ComputeClass personalizada habilita la migración activa a nodos de mayor prioridad (activeMigration.optimizeRulePriority: true) y coloca las VMs Spot en una prioridad más alta que las VMs on-demand, GKE migra los nodos en espera on-demand a VMs Spot con el tiempo. Debido a que las VMs Spot están más sujetas a restricciones de capacidad y las VMs Spot suspendidas no se pueden convertir en VMs a pedido cuando se reanudan, estas restricciones pueden impedir que esos nodos en espera se reanuden.
  • Reanudar el nodo supera las cuotas de Compute Engine de tu proyecto. Para obtener más información, consulta El búfer de capacidad no se aprovisiona debido a los límites de cuota.

Para identificar por qué un nodo en espera no se reanudó, consulta los registros de auditoría de Compute Engine en el Explorador de registros para ver los errores ZONE_RESOURCE_POOL_EXHAUSTED o QUOTA_EXCEEDED en las operaciones compute.instances.resume.

Para resolver o mitigar este problema, realiza una o más de las siguientes acciones:

  • Usa clústeres regionales para que el escalador automático del clúster pueda aprovisionar o reanudar nodos en varias zonas.
  • Configura varias familias de máquinas en la lista spec.priorities de tu ComputeClass personalizado. Si los nodos suspendidos no se pueden reanudar, el escalador automático del clúster puede recurrir a la creación de nodos nuevos según una regla de prioridad diferente. Estos nodos nuevos tardan más en estar listos que los nodos en espera reanudados. Esta configuración no ayuda a que se reanuden los nodos suspendidos, ya que un nodo suspendido solo se puede reanudar con su tipo de máquina original.
  • Usa una ComputeClass personalizada dedicada con VMs a pedido o configura el campo activeMigration.optimizeRulePriority como false para la ComputeClass que usa tu búfer de reserva.
  • Combina tu búfer de reserva con un pequeño búfer activo para absorber los picos de tráfico inmediatos.

El búfer de capacidad no se aprovisiona debido a los límites de cuota

Un búfer de capacidad puede aprovisionar menos réplicas de las solicitadas o no escalar verticalmente si supera las ResourceQuotas de Kubernetes o las cuotas de Compute Engine.

Para identificar qué cuota limita el búfer, verifica una o más de las siguientes cuotas:

  • Verifica si una ResourceQuota de Kubernetes en el espacio de nombres limita el búfer:

    kubectl describe capacitybuffer \
    CAPACITY_BUFFER_NAME \
    -n NAMESPACE

    En el resultado de status.conditions, busca una condición LimitedByQuotas con un estado de True. Tanto las unidades de búfer activas como las de espera, incluidas las unidades respaldadas por nodos de espera suspendidos, se consideran para los límites de ResourceQuota del espacio de nombres como si los Pods de búfer se estuvieran ejecutando. Cuando un búfer supera la cuota del espacio de nombres, GKE limita el campo status.replicas para que se ajuste a la cuota disponible.

  • Verifica si las cuotas del proyecto de Compute Engine están bloqueando el aprovisionamiento de nodos. En el Explorador de registros, busca en el registro container.googleapis.com/cluster-autoscaler-visibility los eventos no.scale.up.nap.quota.exceeded o busca en los registros de auditoría de Compute Engine los errores QUOTA_EXCEEDED.

    Cuando verifiques las cuotas de Compute Engine para los búferes de reserva, verifica las siguientes cuotas además de las cuotas de CPU virtual y memoria:

    • Los nodos en espera suspendidos conservan sus direcciones IP internas y externas, lo que consume la cuota de direcciones IP en uso.
    • Cuando se suspende una VM en espera, Compute Engine escribe la memoria del nodo en el disco, lo que consume una cuota de disco de Persistent disk standard (GB) proporcional al tamaño de la memoria del nodo.

Para resolver el límite de cuota, realiza una de las siguientes acciones:

¿Qué sigue?