Configura el aumento de actividad de Pods en GKE


En esta página, se muestra cómo configurar pods para generar un aumento de actividad en la capacidad sin usar disponible en los nodos de Google Kubernetes Engine (GKE).

¿Qué es el aumento de actividad?

El aumento de actividad describe la acción de los Pods que usan de forma temporal más capacidad de procesamiento en el nodo de la que solicitaron en un principio.

Kubernetes te permite solicitar capacidades específicas de recursos, como CPU o memoria, para tus pods. Debes establecer estas solicitudes en el manifiesto de tu Pod. El programador de Kubernetes coloca tus Pods en nodos que tienen suficiente capacidad para satisfacer esas solicitudes de recursos.

Algunas cargas de trabajo no usan el 100% de los recursos solicitados durante todo su tiempo de ejecución. Por ejemplo, una carga de trabajo que consume CPU adicional durante su período de inicio puede que no requiera la misma cantidad de recursos para las operaciones normales. En estas situaciones, puedes establecer los límites de recursos para tu carga de trabajo en un valor más alto que las solicitudes de recursos o dejar los límites sin configurar. GKE permite que la carga de trabajo use de forma temporal más recursos de los que especificaste en las solicitudes, si esa capacidad está disponible.

Para obtener más información sobre cómo funciona este proceso en GKE, consulta Cómo funciona el aumento de actividad en este documento.

Beneficios del aumento de actividad de Pods

El aumento de actividad es útil cuando tus pods solo necesitan recursos adicionales durante períodos breves para adaptarse a los aumentos repentinos de uso de recursos. Entre las situaciones de ejemplo se incluyen las siguientes:

  • Tienes grupos de cargas de trabajo que suelen estar inactivas y envían una pequeña cantidad de solicitudes por segundo, pero en ocasiones experimentan aumentos repentinos en el tráfico y se beneficiarían de recursos adicionales para procesar esas solicitudes.
  • Tus cargas de trabajo necesitan más recursos durante el inicio que durante las operaciones normales.
  • Deseas maximizar el uso de la capacidad de procesamiento que aprovisionas.

El aumento de actividad te permite solicitar solo los recursos que el Pod necesita durante la mayoría de su tiempo de ejecución y, al mismo tiempo, garantizar que el Pod pueda consumir más recursos si es necesario. Los beneficios del aumento de actividad incluyen lo siguiente:

  • Costos de ejecución más bajos: No necesitas solicitar el consumo máximo de recursos esperado de la carga de trabajo. Tus solicitudes pueden ser para los valores de estado estable más bajos. En Autopilot, pagas por la suma de las solicitudes de recursos de Pods, por lo que los costos de ejecución son más bajos.
  • Uso más eficiente de recursos: Evitas la capacidad de procesamiento inactiva porque los Pods generan un aumento de actividad en la capacidad sin usar. Es más probable que tus cargas de trabajo usen todos tus recursos pagos.
  • Rendimiento mejorado: Los pods pueden usar recursos adicionales según sea necesario para reducir el tiempo de procesamiento de solicitudes entrantes o para iniciarse más rápido durante los eventos de escalamiento vertical.

Cuándo no usar el aumento de actividad

Kubernetes asigna la clase Calidad de servicio (QoS) Burstable a los Pods que especifican límites de recursos más altos que sus solicitudes. Es más probable que los pods con clase QoS Burstable se expulsen cuando Kubernetes necesita reclamar recursos en el nodo. Para obtener más información, consulta la clase QoS con capacidad de aumento de actividad en la documentación de Kubernetes.

Antes de comenzar

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

  • Habilita la API de Kubernetes Engine de Google.
  • Habilitar la API de Kubernetes Engine de Google
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  • Asegúrate de tener un clúster de GKE Autopilot que ejecute la versión 1.29.2-gke.1060000 o posterior, o cualquier versión de un clúster de GKE Standard. Para crear un clúster nuevo, consulta Crea un clúster de Autopilot.

Disponibilidad del aumento de actividad en GKE

Las cargas de trabajo pueden generar un aumento de actividad en las siguientes situaciones:

Disponibilidad del aumento de actividad
Modo GKE Autopilot

Los Pods que usan la clase de procesamiento Performance o la clase de procesamiento Accelerator pueden generar un aumento de actividad en cualquier versión de GKE que admita esa clase de procesamiento.

En cualquier otra clase de procesamiento y para pods que no especifiquen una clase de procesamiento, el aumento de actividad solo está disponible si el clúster cumple con las siguientes condiciones:

  • Originalmente, creaste el clúster con la versión 1.26 de GKE o una posterior.
  • El clúster ejecuta la versión 1.29.2-gke.1060000 de GKE o una posterior.

Esta restricción existe porque, en los clústeres de Autopilot, el aumento de actividad requiere cgroup v2. cgroup v2 solo está disponible en clústeres que se crearon originalmente con la versión 1.26 y versiones posteriores.

Modo GKE Standard Los Pods pueden tener un aumento de actividad en cualquier versión de GKE.

Los clústeres de Autopilot que se crearon originalmente con una versión anterior a la 1.26 y, luego, se actualizaron a la versión 1.29.2-gke.1060000 y posteriores, no admiten el aumento de actividad. Para comprobar la versión original del clúster, ejecuta el siguiente comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(initialClusterVersion)"

El resultado debe ser la versión 1.26 de GKE o una posterior.

Limitaciones

  • Las cargas de trabajo de Autopilot solo pueden usar el aumento de actividad para solicitudes de CPU y memoria.
  • Los planos de control y los nodos de Autopilot deben usar una versión de GKE compatible. Si actualizaste recientemente tus clústeres a una versión compatible, asegúrate de que los nodos ejecuten esa versión antes de usar el aumento de actividad.

Conéctate al clúster

Ejecuta el siguiente comando:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

Reemplaza lo siguiente:

  • CLUSTER_NAME: Es el nombre del clúster existente.
  • LOCATION: Es la ubicación de tu clúster.

Implementa una carga de trabajo con capacidad de aumento de actividad

  1. Guarda el siguiente manifiesto como burstable-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: helloweb
      labels:
        app: hello
    spec:
      selector:
        matchLabels:
          app: hello
          tier: web
      template:
        metadata:
          labels:
            app: hello
            tier: web
        spec:
          nodeSelector:
            pod-type: "non-critical"
          tolerations:
          - key: pod-type
            operator: Equal
            value: "non-critical"
            effect: NoSchedule
          containers:
          - name: hello-app
            image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
            ports:
            - containerPort: 8080
            resources:
              requests:
                cpu: 250m
              limits:
                cpu: 350m
    

    Este manifiesto tiene los siguientes campos para habilitar el aumento de actividad:

    • resources.requests: Los recursos que el contenedor necesita para funcionar. Establece este valor en la capacidad que necesitará tu contenedor en estado estable.
    • resources.limits: La capacidad máxima de recursos que el contenedor puede usar. Configurar los límites más altos que las solicitudes permite que los Pods generen un aumento de actividad hasta el límite especificado si esa capacidad está disponible en el nodo. Si omites este campo, los Pods pueden generar un aumento de actividad hasta la capacidad de aumento de actividad disponible en el nodo. Esta capacidad se calcula de la siguiente manera:
      • Modo Autopilot: Capacidad sin usar en la suma de las solicitudes de recursos de los Pods en el nodo.
      • Modo Standard: capacidad sin usar en los recursos de nodo.
    • spec.nodeSelector y spec.tolerations: opcional. Indica a GKE que cree nodos nuevos para ejecutar los Pods con capacidad de aumento de actividad. GKE aplica taints a estos nodos nuevos para evitar que otros Pods, como las cargas de trabajo críticas, se ejecuten en los mismos nodos. Si deseas obtener detalles, consulta Configura la separación de cargas de trabajo en GKE.
  2. Implementa la carga de trabajo:

    kubectl apply -f burstable-deployment.yaml
    

    La carga de trabajo puede tardar unos minutos en iniciarse.

  3. Verifica la clase QoS de un Pod:

    kubectl describe pod helloweb | grep -m 1 "QoS"
    

    Esta es la salida:

    QoS Class: Burstable
    

Capacidad de aumento de actividad en GKE

Para facilitar el aumento de actividad de Pods, GKE calcula la capacidad de aumento de actividad para cada nodo en un clúster. Este cálculo para un nodo específico es el siguiente:

  • Clústeres de Autopilot: la suma de las solicitudes de recursos de todos los pods en ese nodo, sin importar la capacidad real de recursos del nodo. Si se finaliza un Pod, la capacidad de aumento de actividad se reduce por las solicitudes de ese Pod. La parte de la capacidad de aumento de actividad que no está en uso mediante la ejecución de Pods está disponible para asignar si uno de los Pods necesita generar un aumento de actividad.

    Autopilot también agrega un búfer predefinido a la capacidad de aumento de actividad para que los Pods del sistema en el nodo que tengan un aumento de actividad más allá de sus solicitudes no afecten tus propios Pods con capacidad de aumento de actividad.

  • Clústeres de Standard: la capacidad total de recursos disponible en la VM de nodo.

Prácticas recomendadas para el aumento de actividad

Usa las siguientes prácticas con el aumento de actividad de pods:

  • Configura las solicitudes de recursos para que sean iguales a los límites de cualquier Pod que proporcione una funcionalidad crítica en tu entorno. Esto garantiza que esos pods obtengan la clase de Calidad de servicio (QoS) de Kubernetes Guaranteed.
  • Asegúrate de configurar solo el aumento de actividad de memoria en los Pods que puedan controlar la expulsión cuando Kubernetes necesite recuperar memoria en el nodo.
  • Solicita siempre memoria suficiente para que el Pod se inicie. No dependas del aumento de actividad de memoria para cumplir con los requisitos de inicio.
  • Para evitar que los Pods con capacidad de aumento de actividad que generan constantemente un aumento de actividad en varias de sus solicitudes de CPU puedan interrumpir las cargas de trabajo críticas, usa la separación de cargas de trabajo para evitar colocar esos Pods junto con los Pods críticos.

Optimiza la capacidad de aumento de actividad en los nodos de Autopilot

Autopilot calcula la capacidad de aumento de actividad como la suma de las solicitudes de recursos de todos los pods en un nodo específico, incluidos los pods del sistema y los DaemonSets. Puedes optimizar la capacidad de aumento de actividad en un nodo de las siguientes maneras. Sin embargo, el aumento de actividad es oportunista y no está garantizado.

  • Para aumentar la capacidad de aumento de actividad en los nodos de cargas de trabajo específicas, usa la afinidad de Pods para colocar Pods específicos juntos en el mismo nodo.
  • A fin de garantizar que una capacidad de aumento de actividad específica siempre esté disponible en cada nodo, crea DaemonSets para que se ejecuten en todos los nodos del clúster.

Ejemplo de cómo funciona el aumento de actividad

En esta sección, se usa un Deployment de ejemplo que tiene los siguientes Pods con capacidad de aumento de actividad para demostrar cómo funciona el aumento de actividad de Pods en los clústeres de GKE Autopilot:

  • El Pod 1 solicita 250 m de CPU y no tiene límite de CPU. El Pod 1 usa 100 m de CPU para ejecutarse.
  • El Pod 2 solicita 200 m de CPU y tiene un límite de CPU de 250 m. El Pod 2 usa 100 m de CPU para ejecutarse.

Ambos Pods se ejecutan en el mismo nodo. La capacidad de aumento de actividad total en el nodo es de 450 m de CPU (la suma de las solicitudes de recursos). Cada pod usa solo 100 m de CPU para ejecutarse, lo que significa que el nodo tiene una capacidad de aumento de actividad disponible restante de 250 m.

Considera las siguientes situaciones en las que se produce un aumento repentino de tráfico:

  • El Pod 1 necesita una CPU de 300 m adicional: puede generar un aumento de actividad y usar 250 m de CPU, que es la capacidad de aumento de actividad disponible. El nodo ya no tiene ninguna capacidad de aumento de actividad disponible.
  • El Pod 2 necesita una CPU adicional de 150 m: puede generar un aumento de actividad y usar una CPU adicional de 150 m. El nodo tiene 100 m de CPU restantes de capacidad de aumento de actividad disponible.
  • El Pod 2 necesita una CPU adicional de 200 m: puede generar un aumento de actividad y usar 150 m de CPU, lo que lleva el uso total a 250 m de CPU para el Pod 2. El Pod 2 tiene un límite de 250 m de CPU y no puede generar un aumento de actividad más allá de ese límite.

Cómo GKE controla los Pods que superan la capacidad de aumento de actividad

Si tus Pods con capacidad de aumento de actividad intentan usar más recursos que la capacidad de aumento de actividad en el nodo, GKE realiza las siguientes acciones:

  • CPU: Si el uso de CPU supera la capacidad de aumento de actividad, GKE limita el uso de CPU de algunos contenedores para que todos los contenedores del nodo obtengan la CPU que solicitan.
  • Memoria: Si el uso de memoria excede la capacidad de aumento de actividad, GKE finaliza los contenedores para recuperar memoria en el nodo. GKE comienza por finalizar los contenedores que requieren muchos recursos en Pods con un QoS más bajo.

Recomendamos que siempre solicites memoria suficiente para el funcionamiento normal del Pod. Si un contenedor depende del aumento de actividad de memoria para funcionar con normalidad, puede fallar de manera repetida si esa memoria no está disponible.

Usa el aumento de actividad de pods con aprovisionamiento de capacidad libre

GKE te permite implementar Pods inactivos para reservar capacidad de procesamiento adicional a fin de lograr un escalamiento de Pods más rápido durante eventos futuros de tráfico alto, como las ofertas relámpago en la tienda en línea. Otros Pods en el mismo nodo pueden generar un aumento de actividad en esta capacidad reservada sin usar, de modo que la capacidad no esté inactiva en el tiempo anterior al evento de tráfico alto. Puedes reservar esta capacidad mediante varios mecanismos de Kubernetes. Por ejemplo, puedes implementar Pods que tienen una PriorityClass baja. Si deseas obtener detalles, consulta Aprovisiona capacidad de procesamiento adicional para el escalamiento rápido de Pod.

Aumento de actividad de Pods en clústeres de GKE Standard

Los clústeres de GKE Standard también admiten el aumento de actividad de Pods al configurar los límites más altos que las solicitudes o al omitir los límites. Sin embargo, en los clústeres de Standard, debes crear y configurar grupos de nodos con la capacidad de recursos adecuada para admitir el aumento de actividad. Obtener la posible reducción de costos de los Pods con capacidad de aumento de actividad en clústeres de Standard requiere una planificación más cuidadosa de nodos y un empaquetado en contenedores de Pods, ya que pagas por las VMs de Compute Engine subyacentes.

Considera lo siguiente en los clústeres de Standard:

  • El límite máximo de consumo de recursos que activa la expulsión de Kubernetes o la limitación de CPU es la capacidad de recursos asignable en el nodo. Para determinar este valor, consulta Planifica los tamaños de los nodos de GKE Standard.

  • Es más probable que el uso de recursos de nodos en clústeres de Standard alcance un umbral de expulsión de Kubernetes porque GKE no limita de forma automática el consumo de recursos si no especificas límites. Por lo tanto, es más probable que los pods que generan un aumento de actividad en la memoria finalicen con la expulsión de presión de nodos de Kubernetes.

¿Qué sigue?