Es posible que parte de la información de esta página (o toda) no se aplique a Trusted Cloud de S3NS.

Esta página se ha traducido con Cloud Translation API.

Configurar el aumento de pods en GKE

Autopilot Standard

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

¿Qué es el bursting?

El bursting describe la acción de los pods que usan temporalmente más capacidad de computación en el nodo de la que solicitaron originalmente.

Kubernetes te permite solicitar capacidades específicas de recursos, como CPU o memoria, para tus pods. Estas solicitudes se definen en el manifiesto del pod. El programador de Kubernetes coloca tus pods en nodos que tienen capacidad suficiente para satisfacer esas solicitudes de recursos.

Algunas cargas de trabajo no usan el 100% de los recursos solicitados durante todo el tiempo de ejecución. Por ejemplo, una carga de trabajo que consuma CPU adicional durante su periodo de arranque puede que no requiera la misma cantidad de recursos para las operaciones normales. En estos casos, puede definir los límites de recursos de su carga de trabajo con un valor superior al de las solicitudes de recursos o dejar los límites sin definir. GKE permite que la carga de trabajo use temporalmente más recursos de los que has especificado en las solicitudes, si esa capacidad está disponible.

Para obtener más información sobre cómo funciona este proceso en GKE, consulta la sección Capacidad de ráfaga en GKE de esta página.

Ventajas de la ampliación de pods

El bursting es útil cuando tus pods solo necesitan recursos adicionales durante periodos breves para adaptarse a los picos de uso de recursos. Estos son algunos ejemplos:

Tienes grupos de cargas de trabajo que suelen estar inactivos y envían un pequeño número de solicitudes por segundo, pero que ocasionalmente experimentan picos de 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.
Quieres maximizar el uso de la capacidad de computación que aprovisiones.

El bursting te permite solicitar solo los recursos que tu pod necesita durante la mayor parte de su tiempo de ejecución, al tiempo que te aseguras de que tu pod pueda consumir más recursos si es necesario. Estas son algunas de las ventajas de la publicación en ráfaga:

Costes de ejecución más bajos: no es necesario que solicites el consumo máximo de recursos previsto de la carga de trabajo. Tus solicitudes pueden ser para los valores más bajos del estado estable. En Autopilot, pagas por la suma de las solicitudes de recursos de tus pods, por lo que los costes de ejecución son más bajos.
Uso más eficiente de los recursos: evitas la capacidad de computación inactiva porque tus pods aprovechan la capacidad sin usar. Es más probable que tus cargas de trabajo usen todos los recursos por los que has pagado.
Rendimiento mejorado: los pods pueden usar recursos adicionales según sea necesario para reducir el tiempo de procesamiento de las solicitudes entrantes o para arrancar más rápido durante los eventos de escalado vertical.

Cuándo no usar la publicación en ráfaga

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

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Asegúrate de que tienes un clúster de GKE Autopilot con la versión 1.30.2-gke.1394000 o posterior, o cualquier versión de un clúster estándar de GKE. Para crear un clúster, consulta Crear un clúster de Autopilot.

Disponibilidad de Bursting en GKE

Las cargas de trabajo pueden tener picos en las siguientes situaciones:

Disponibilidad de ráfagas

Modo Autopilot de GKE

Disponibilidad de ráfagas
Modo Autopilot de GKE	Los siguientes tipos de pods pueden usar recursos adicionales en cualquier versión de GKE que admita el hardware que soliciten los pods: Pods que solicitan GPUs Pods que solicitan una serie de máquinas específica En el resto de los tipos de pods, el bursting estará disponible cuando reinicies el plano de control después de asegurarte de que el clúster cumple todas las condiciones siguientes: El clúster ejecuta `cgroupv2`. Los clústeres creados con la versión 1.26 de GKE o una posterior, o que se hayan migrado a `cgroupv2`, cumplirán esta condición. Consulta cómo comprobar el modo de cgroup para determinar la versión actual de cgroup y migrar si es necesario. El clúster ejecuta la versión 1.30.2-gke.1394000 de GKE o una posterior. Para obtener más información, consulta Limitaciones.
Modo Estándar de GKE	Los pods pueden usar recursos adicionales en cualquier versión de GKE.

Los siguientes tipos de pods pueden usar recursos adicionales en cualquier versión de GKE que admita el hardware que soliciten los pods:

En el resto de los tipos de pods, el bursting estará disponible cuando reinicies el plano de control después de asegurarte de que el clúster cumple todas las condiciones siguientes:

El clúster ejecuta cgroupv2. Los clústeres creados con la versión 1.26 de GKE o una posterior, o que se hayan migrado a cgroupv2, cumplirán esta condición. Consulta cómo comprobar el modo de cgroup para determinar la versión actual de cgroup y migrar si es necesario.
El clúster ejecuta la versión 1.30.2-gke.1394000 de GKE o una posterior.

Para obtener más información, consulta Limitaciones.

Modo Estándar de GKE Los pods pueden usar recursos adicionales en cualquier versión de GKE.

Limitaciones

Las cargas de trabajo de Autopilot solo pueden usar el bursting para las solicitudes de CPU y memoria.
Cuando actualizas un clúster de Autopilot a una versión compatible, GKE actualiza los nodos de trabajo para que coincidan con la versión del plano de control a lo largo del tiempo. Para habilitar el bursting, es necesario reiniciar el plano de control, lo que debe ocurrir después de que todos los nodos ejecuten una versión y un modo cgroup compatibles. El plano de control se reinicia automáticamente aproximadamente una vez a la semana durante operaciones como el escalado, las actualizaciones o el mantenimiento.

Para activar manualmente el reinicio del plano de control, haz lo siguiente:
1. Comprueba si todos tus nodos ejecutan la versión 1.30.2-gke.1394000 o una posterior:
```
kubectl get nodes
```
  El resultado debería ser similar al siguiente:
```
NAME                                          STATUS   ROLES    AGE     VERSION
gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000
```
  Todos los nodos de la salida deben mostrar la versión necesaria o una posterior.
2. Confirma que tu clúster ejecuta cgroupv2. Para obtener instrucciones, consulta Comprobar el modo de cgroup.
3. Inicia manualmente una actualización del plano de control a la misma versión que ya usa el clúster.
```
gcloud container clusters upgrade CLUSTER_NAME --master \
    --cluster-version CURRENT_CLUSTER_VERSION
```
  Haz los cambios siguientes:
  - CLUSTER_NAME: el nombre del clúster.
  - CURRENT_CLUSTER_VERSION: la versión que ejecuta tu clúster.

Conéctate al clúster

Ejecuta el siguiente comando:

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

Haz los cambios siguientes:

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

Verificar que el clúster admite ráfagas

El bursting siempre está habilitado en los clústeres del modo Estándar y en las cargas de trabajo del modo Autopilot que solicitan aceleradores o series de máquinas específicas. Ve a la sección Desplegar una carga de trabajo con capacidad de ampliación.

Los siguientes tipos de cargas de trabajo de Autopilot solo pueden aumentar si se ejecuta en el clúster un DaemonSet gestionado por GKE llamado efficiency-daemon:

Pods de Autopilot que solicitan las Scale-Out o Balanced clases de computación predefinidas.
Pods de Autopilot que no solicitan una clase de computación.

GKE implementa el efficiency-daemon DaemonSet cuando tu clúster de Autopilot cumple los requisitos para el bursting, tal como se describe en la sección Disponibilidad del bursting en GKE.

Para comprobar si el DaemonSet efficiency-daemon existe en tu clúster, ejecuta el siguiente comando:

kubectl get daemonset --namespace=kube-system efficiency-daemon

El resultado debería ser similar al siguiente:

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

Si la salida está vacía, asegúrate de que el clúster cumpla todos los requisitos y las limitaciones de la sección Antes de empezar.

Desplegar una carga de trabajo con capacidad de ráfaga

Guarda el siguiente archivo de 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:
      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 envío en ráfagas:
- resources.requests: Los recursos que necesita el contenedor para funcionar. Asigna a este campo la capacidad que necesitará tu contenedor en estado estable.
- resources.limits: capacidad máxima de recursos que puede usar el contenedor. Si los límites son superiores a las solicitudes, los pods pueden alcanzar el límite especificado si el nodo tiene capacidad. Si omite este campo, los pods pueden alcanzar la capacidad de ráfaga disponible en el nodo. Esta capacidad se calcula de la siguiente manera:
  - Modo Autopilot: capacidad no utilizada en la suma de las solicitudes de recursos de los pods del nodo.
  - Modo estándar: capacidad no utilizada en los recursos de los nodos.
- spec.nodeSelector y spec.tolerations: opcionales. Añade estos campos con etiquetas personalizadas, como pod-type: "non-critical", para indicar a GKE que cree nodos para ejecutar los pods de ráfaga. GKE aplica intolerancias a estos nuevos nodos para evitar que otros pods, como las cargas de trabajo críticas, se ejecuten en los mismos nodos. Autopilot aplica solicitudes de recursos mínimos más altas para los pods que usan la separación de cargas de trabajo. Para obtener más información, consulta Configurar la separación de cargas de trabajo en GKE y Solicitudes de recursos en Autopilot.
Despliega la carga de trabajo:
```
kubectl apply -f burstable-deployment.yaml
```
La carga de trabajo puede tardar unos minutos en iniciarse.

Comprueba la clase de QoS de un pod:

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

El resultado es el siguiente:

QoS Class: Burstable

Capacidad de ráfaga en GKE

Para facilitar el bursting de pods, GKE calcula la capacidad de bursting de cada nodo de un clúster. El cálculo de un nodo específico es el siguiente:

Clústeres de Autopilot:
- Pods que solicitan aceleradores o series de máquinas específicas: la capacidad de recursos asignables de los nodos, que es la capacidad disponible para el uso de cargas de trabajo. Para obtener más información , consulta Recursos asignables de los nodos.
- Todos los demás pods: la suma de las solicitudes de recursos de todos los pods de ese nodo, independientemente de la capacidad de recursos real del nodo. Si se termina un pod, la capacidad de ráfaga se reduce en función de las solicitudes de ese pod. La parte de la capacidad de burstable que no utilizan los pods en ejecución está disponible para asignarse si uno de los pods necesita aumentar su capacidad.
Autopilot también añade un búfer predefinido a la capacidad de ráfaga para que los pods del sistema del nodo que superen sus solicitudes no afecten a tus pods de ráfaga.
Clústeres estándar: la capacidad de recursos asignables de los nodos, que es la capacidad disponible para el uso de cargas de trabajo. Para obtener más información , consulta Recursos asignables de los nodos.

Prácticas recomendadas para los picos

Sigue estas prácticas con Pod bursting:

Define las solicitudes de recursos iguales a los límites de los pods que proporcionen funciones críticas en tu entorno. De esta forma, esos pods obtienen la clase de calidad del servicio (QoS) Guaranteed de Kubernetes.
Asegúrate de configurar la ampliación de memoria solo en los pods que puedan gestionar la expulsión cuando Kubernetes necesite reclamar memoria en el nodo.
Solicita siempre suficiente memoria para que tu pod se inicie. No confíes en la memoria para cumplir los requisitos de arranque.
Para evitar que los pods con capacidad de ráfaga que se activan de forma constante en múltiplos de sus solicitudes de CPU puedan interrumpir cargas de trabajo críticas, usa la separación de cargas de trabajo para evitar colocar esos pods junto a tus pods críticos.

Optimizar la capacidad de ráfaga en nodos Autopilot

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

Para aumentar la capacidad de ráfaga de los nodos en cargas de trabajo específicas, usa la afinidad de pods para colocar pods específicos en el mismo nodo.
Para asegurarte de que siempre haya una capacidad de ráfaga específica disponible en todos los nodos, crea DaemonSets para que se ejecuten en todos los nodos del clúster.

Ejemplo de cómo funciona el bursting

En esta sección se usa un ejemplo de Deployment que tiene los siguientes pods con capacidad de ráfaga para mostrar cómo funciona la ráfaga de pods en clústeres de Autopilot de GKE:

El pod 1 solicita 250 m de CPU y no tiene ningún 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 250 m de CPU. El pod 2 usa 100 m de CPU para ejecutarse.

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

Veamos las siguientes situaciones en las que se produce un pico de tráfico:

El pod 1 necesita 300 m de CPU adicionales: puede usar 250 m de CPU, que es la capacidad de ráfaga disponible. El nodo ya no tiene capacidad de burst disponible.
El pod 2 necesita 150 m de CPU adicionales: puede usar 150 m de CPU adicionales. El nodo tiene 100 m de CPU restantes de la capacidad de ráfaga disponible.
El pod 2 necesita 200 m de CPU adicionales: puede usar 150 m de CPU, lo que eleva el uso total a 250 m de CPU para el pod 2. El pod 2 tiene un límite de CPU de 250 m y no puede superar ese límite.

Cómo gestiona GKE los pods que superan la capacidad de ráfaga

Si tus pods con capacidad de ráfaga intentan usar más recursos que la capacidad de ráfaga del nodo, GKE hará lo siguiente:

CPU: si el uso de la CPU supera la capacidad de ráfaga, GKE limita el uso de la CPU de algunos contenedores para que todos los contenedores del nodo obtengan la CPU que solicitan.
Memoria: si el uso de memoria supera la capacidad de ráfaga, GKE finaliza los contenedores para recuperar memoria en el nodo. GKE empieza por finalizar los contenedores que consumen muchos recursos en los pods con una QoS inferior.

Te recomendamos que siempre solicites suficiente memoria para el funcionamiento normal del pod. Si un contenedor depende de la ampliación de memoria para funcionar con normalidad, es posible que falle repetidamente si esa memoria no está disponible.

Usar el bursting de pods con el aprovisionamiento de capacidad de reserva

GKE te permite desplegar pods inactivos para reservar capacidad de computación adicional y, de esta forma, escalar los pods más rápido durante eventos futuros de alto tráfico, como las ofertas flash de tiendas online. Otros pods del mismo nodo pueden usar esta capacidad reservada sin utilizar para que no esté inactiva antes del evento de alto tráfico. Puedes reservar esta capacidad mediante varios mecanismos de Kubernetes. Por ejemplo, puedes desplegar pods que tengan un PriorityClass bajo. Para obtener más información, consulta Proporcionar capacidad de computación adicional para escalar pods rápidamente.

Pod bursting en clústeres de GKE Standard

Los clústeres estándar de GKE también admiten el aumento de pods si se definen límites superiores a las solicitudes o si se omiten los límites. Sin embargo, en los clústeres estándar, debes crear y configurar grupos de nodos con la capacidad de recursos adecuada para admitir el aumento repentino. Para obtener la posible reducción de costes de los pods con capacidad de ráfaga en los clústeres estándar, es necesario planificar los nodos y el empaquetado de los pods con más cuidado, ya que se pagan las VMs de Compute Engine subyacentes.

Ten en cuenta lo siguiente en los clústeres estándar:

El límite máximo de consumo de recursos que activa el desalojo de Kubernetes o la limitación de la CPU es la capacidad de recursos asignable del nodo. Para determinar este valor, consulta Planificar los tamaños de los nodos de GKE Standard.
Es más probable que el uso de recursos de los nodos en los clústeres estándar alcance un umbral de desalojo de Kubernetes porque GKE no limita automáticamente el consumo de recursos si no especificas límites. Por lo tanto, es más probable que Kubernetes termine los pods que aumentan el uso de memoria mediante la expulsión por presión de nodos.