Para mejorar la estabilidad de las cargas de trabajo, el modo Autopilot de Google Kubernetes Engine (GKE) gestiona los valores de las solicitudes de recursos de los pods, como la CPU, la memoria o el almacenamiento efímero. En esta página se incluye la siguiente información, que puedes usar para planificar cargas de trabajo eficientes, estables y rentables:
- Valores predeterminados que Autopilot aplica a los pods que no especifican valores.
- Valores mínimos y máximos que Autopilot aplica a las solicitudes de recursos.
- Cómo varían los valores predeterminados, mínimos y máximos en función del hardware que soliciten tus Pods.
Esta página está dirigida a operadores y desarrolladores que aprovisionan y configuran recursos de nube, y despliegan cargas de trabajo. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas de usuario habituales de GKE. Trusted Cloud by S3NS
Ya deberías conocer la gestión de recursos de Kubernetes.
Información general sobre las solicitudes de recursos en Autopilot
Autopilot usa las solicitudes de recursos que especificas en la configuración de tu carga de trabajo para configurar los nodos que ejecutan tus cargas de trabajo. Autopilot aplica solicitudes de recursos mínimas y máximas en función de la clase de computación o de la configuración de hardware que usen tus cargas de trabajo. Si no especifica solicitudes para algunos contenedores, Autopilot asigna valores predeterminados para que esos contenedores se ejecuten correctamente.
Cuando despliegas una carga de trabajo en un clúster de Autopilot, GKE valida la configuración de la carga de trabajo con los valores mínimos y máximos permitidos de la clase de computación o la configuración de hardware seleccionada (como las GPUs). Si tus solicitudes son inferiores al mínimo, Autopilot modificará automáticamente la configuración de tu carga de trabajo para que tus solicitudes se ajusten al intervalo permitido. Si tus solicitudes superan el máximo, Autopilot rechazará tu carga de trabajo y mostrará un mensaje de error.
En la siguiente lista se resumen las categorías de solicitudes de recursos:
- Solicitudes de recursos predeterminadas: Autopilot añade estas solicitudes si no especificas las tuyas para las cargas de trabajo.
- Solicitudes de recursos mínimos y máximos: Autopilot valida las solicitudes que especifiques para asegurarse de que están dentro de estos límites. Si tus solicitudes superan los límites, Autopilot modificará tus solicitudes de carga de trabajo.
- Separación de cargas de trabajo y solicitudes de duración ampliada: Autopilot tiene diferentes valores predeterminados y mínimos para las cargas de trabajo que separas entre sí o para los pods que reciben protección ampliada contra el desalojo iniciado por GKE.
- Solicitudes de recursos de DaemonSets: Autopilot tiene valores predeterminados, mínimos y máximos diferentes para los contenedores de DaemonSets.
Cómo solicitar recursos
En Autopilot, solicitas recursos en la especificación de tu pod. Los recursos mínimos y máximos admitidos que puedes solicitar cambian en función de la configuración de hardware del nodo en el que se ejecutan los pods. Para saber cómo solicitar configuraciones de hardware específicas, consulta las siguientes páginas:
- Elegir clases de computación para pods de Autopilot
- Desplegar cargas de trabajo de GPUs en Autopilot
Solicitudes de recursos predeterminadas
Si no especificas solicitudes de recursos para algunos contenedores de un pod, Autopilot aplicará valores predeterminados. Estos valores predeterminados son adecuados para muchas cargas de trabajo más pequeñas.
Además, Autopilot aplica las siguientes solicitudes de recursos predeterminadas independientemente de la clase de computación o la configuración de hardware seleccionadas:
Contenedores en DaemonSets
- CPU: 50 mCPU
- Memoria: 100 MiB
- Almacenamiento efímero: 100 MiB
Todos los demás contenedores
- Almacenamiento efímero: 1 GiB
Para obtener más información sobre los límites de los clústeres de Autopilot, consulta Cuotas y límites.
Solicitudes predeterminadas de clases de cálculo
Autopilot aplica los siguientes valores predeterminados a los recursos que no se definen en la especificación de los pods que se ejecutan en clases de computación. Si solo defines una de las solicitudes y dejas la otra en blanco, GKE usará la relación entre CPU y memoria definida en la sección Solicitudes mínimas y máximas para asignar a la solicitud que falta un valor que cumpla la relación.
Clase de computación | Recurso | Solicitud predeterminada |
---|---|---|
Uso general (predeterminado) | CPU | 0,5 vCPU |
Memoria | 2 GiB | |
Accelerator | No se ha aplicado ninguna solicitud predeterminada. | |
Equilibrado | CPU | 0,5 vCPU |
Memoria | 2 GiB | |
Rendimiento | No se ha aplicado ninguna solicitud predeterminada. | |
Escalado horizontal | CPU | 0,5 vCPU |
Memoria | 2 GiB |
Peticiones de recursos mínimas y máximas
Los recursos totales solicitados por la configuración de tu implementación deben estar dentro de los valores mínimos y máximos admitidos que permite Autopilot. Se aplican las siguientes condiciones:
Solicitudes de almacenamiento efímero:
El almacenamiento efímero usa el disco de arranque de la VM, a menos que tus nodos tengan unidades SSD locales conectadas.
El hardware de computación que incluye SSDs locales, como las GPUs A100 (80 GB) y H100 (80 GB), o la serie de máquinas Z3 admite una solicitud máxima igual al tamaño del SSD local menos la sobrecarga del sistema. Para obtener información sobre esta sobrecarga del sistema, consulta Almacenamiento efímero respaldado por SSDs locales.
En la versión 1.29.3-gke.1038000 de GKE y versiones posteriores, los pods de clase de rendimiento y los pods de acelerador de hardware admiten una solicitud de almacenamiento efímero máxima de 56 TiB, a menos que el hardware incluya SSDs locales.
En todos los demás pods de Autopilot, independientemente de la versión de GKE, la solicitud de almacenamiento efímero total de todos los contenedores del pod debe estar entre 10 MiB y 10 GiB, a menos que se especifique lo contrario.
Para volúmenes más grandes, usa volúmenes efímeros genéricos, que ofrecen la misma funcionalidad y rendimiento que el almacenamiento efímero, pero con mucha más flexibilidad, ya que se pueden usar con cualquier opción de almacenamiento de GKE. Por ejemplo, el tamaño máximo de un volumen efímero genérico que usa
pd-balanced
es de 64 TiB.
En el caso de los pods de DaemonSet, las solicitudes de recursos mínimas son las siguientes:
- Clústeres que admiten picos de actividad: 1 mCPU por pod, 2 MiB de memoria por pod y 10 MiB de almacenamiento efímero por contenedor en el pod.
- Clústeres que no admiten el bursting: 10 mCPUs por pod, 10 MiB de memoria por pod y 10 MiB de almacenamiento efímero por contenedor en el pod.
Para comprobar si tu clúster admite el bursting, consulta Disponibilidad del bursting en GKE.
Si tu clúster admite el bursting, Autopilot no aplica incrementos de 0,25 vCPU a las solicitudes de CPU de tus pods. Si tu clúster no admite el bursting, Autopilot redondea tus solicitudes de CPU al valor de vCPU más cercano (0,25). Para comprobar si tu clúster admite el bursting, consulta Disponibilidad del bursting en GKE.
La relación entre CPU y memoria debe estar dentro del intervalo permitido para la clase de cálculo o la configuración de hardware seleccionadas. Si la relación entre CPU y memoria está fuera del intervalo permitido, Autopilot aumenta automáticamente el recurso más pequeño. Por ejemplo, si solicitas 1 vCPU y 16 GiB de memoria (relación 1:16) para los pods que se ejecutan en la clase
Scale-Out
, Autopilot aumenta la solicitud de CPU a 4 vCPUs, lo que cambia la relación a 1:4.
Mínimos y máximos de las clases de computación
En la siguiente tabla se describe la relación mínima, máxima y permitida entre CPU y memoria de cada clase de computación compatible con Autopilot:
Clase de computación | Relación CPU:memoria (vCPU:GiB) | Recurso | Mínimo | Máximo |
---|---|---|---|---|
Uso general (predeterminado) | Entre 1:1 y 1:6,5 | CPU | El valor depende de si tu clúster admite el bursting, de la siguiente manera:
Para comprobar si tu clúster admite el bursting, consulta Disponibilidad del bursting en GKE. |
30 vCPUs |
Memoria | El valor depende de si tu clúster admite el bursting, de la siguiente manera:
Para comprobar si tu clúster admite el bursting, consulta Disponibilidad del bursting en GKE. |
110 GiB | ||
Accelerator | Consulta los valores mínimos y máximos de los aceleradores. | |||
Equilibrado | Entre 1:1 y 1:8 | CPU | 0,25 vCPU | 222 vCPUs Si se selecciona Plataforma de CPU mínima:
|
Memoria | 0,5 GiB | 851 GiB Si se selecciona Plataforma de CPU mínima:
|
||
Rendimiento | N/A | CPU | No se aplica ningún mínimo de solicitudes |
|
Memoria | No se aplica ningún mínimo de solicitudes |
|
||
Almacenamiento efímero | No se aplica ningún mínimo de solicitudes |
|
||
Escalado horizontal | Exactamente 1:4 | CPU | 0,25 vCPU |
|
Memoria | 1 GiB |
|
Para saber cómo solicitar clases de computación en tus pods de Autopilot, consulta el artículo Elegir clases de computación para pods de Autopilot.
Mínimos y máximos de los aceleradores
GKE no exige solicitudes mínimas de CPU, memoria o almacenamiento efímero para los pods que usan aceleradores. En la siguiente tabla se describe el número máximo de solicitudes de cada uno de estos recursos en función del número y el tipo de acelerador que utilices.
A menos que se especifique lo contrario, el almacenamiento efímero máximo admitido es de 56 TiB.
Tipo de acelerador | Recurso | Máximo |
---|---|---|
NVIDIA B200nvidia-B200 |
CPU |
|
Memoria |
|
|
Almacenamiento efímero |
|
|
NVIDIA H200 (141 GB)nvidia-h200-141gb |
CPU |
|
Memoria |
|
|
Almacenamiento efímero |
|
|
NVIDIA H100 Mega (80 GB)nvidia-h100-mega-80gb |
CPU |
|
Memoria |
|
|
Almacenamiento efímero |
|
|
NVIDIA H100 (80 GB)nvidia-h100-80gb |
CPU |
|
Memoria |
|
|
Almacenamiento efímero |
|
|
NVIDIA A100 (40 GB)nvidia-tesla-a100 |
CPU |
La suma de las solicitudes de CPU de todos los DaemonSets que se ejecutan en un nodo de GPU A100 no debe superar las 2 vCPUs. |
Memoria |
La suma de las solicitudes de memoria de todos los DaemonSets que se ejecutan en un nodo de GPU A100 no debe superar los 14 GiB. |
|
NVIDIA A100 (80 GB)nvidia-a100-80gb |
CPU |
La suma de las solicitudes de CPU de todos los DaemonSets que se ejecutan en un nodo de GPU A100 (80 GB) no debe superar las 2 vCPUs. |
Memoria |
La suma de las solicitudes de memoria de todos los DaemonSets que se ejecutan en un nodo de GPU A100 (80 GB) no debe superar los 14 GiB. |
|
Almacenamiento efímero |
|
|
NVIDIA L4nvidia-l4 |
CPU |
La suma de las solicitudes de CPU de todos los DaemonSets que se ejecutan en un nodo de GPU L4 no debe superar las 2 vCPUs. |
Memoria |
La suma de las solicitudes de memoria de todos los DaemonSets que se ejecutan en un nodo de GPU L4 no debe superar los 14 GiB. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
Memoria |
|
|
TPU v5etpu-v5-lite-podslice |
CPU |
|
Memoria |
|
|
Almacenamiento efímero | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 280 vCPUs |
Memoria | 448 GiB | |
Almacenamiento efímero | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 240 vCPUs |
Memoria | 407 GiB | |
Almacenamiento efímero | 56 TiB |
Para saber cómo solicitar GPUs en tus pods de Autopilot, consulta el artículo Despliega cargas de trabajo de GPUs en Autopilot.
Solicitudes de recursos para la separación de cargas de trabajo y la duración ampliada
Autopilot te permite manipular la programación y el comportamiento de desalojo de Kubernetes mediante métodos como los siguientes:
- Usa intolerancias y tolerancias y selectores de nodos para asegurarte de que determinados pods solo se coloquen en nodos específicos. Para obtener más información, consulta Configurar la separación de cargas de trabajo en GKE.
- Usa la antafinidades de pods para evitar que los pods se coloquen en el mismo nodo. Las solicitudes de recursos predeterminadas y mínimas de las cargas de trabajo que usan estos métodos para controlar el comportamiento de la programación son más altas que las de las cargas de trabajo que no los usan.
- Usa una anotación para proteger los pods de la expulsión causada por las actualizaciones automáticas de nodos y los eventos de reducción de escala durante un máximo de siete días. Para obtener más información, consulta Ampliar el tiempo de ejecución de los pods de Autopilot.
Si las solicitudes especificadas son inferiores a los mínimos, el comportamiento de Autopilot cambia en función del método que hayas usado, como se indica a continuación:
- Taints, tolerancias, selectores y pods de duración ampliada: Autopilot modifica tus pods para aumentar las solicitudes al programarlos.
- Antiafinidad de pods: Autopilot rechaza el pod y muestra un mensaje de error.
En la siguiente tabla se describen las solicitudes predeterminadas y las solicitudes de recursos mínimas que puedes especificar. Si una configuración o una clase de cálculo no se encuentra en esta tabla, Autopilot no aplica valores mínimos ni predeterminados especiales.
Clase de computación | Recurso | Predeterminado | Mínimo |
---|---|---|---|
Uso general | CPU | 0,5 vCPU | 0,5 vCPU |
Memoria | 2 GiB | 0,5 GiB | |
Equilibrado | CPU | 2 vCPUs | 1 vCPU |
Memoria | 8 GiB | 4 GiB | |
Escalado horizontal | CPU | 0,5 vCPU | 0,5 vCPU |
Memoria | 2 GiB | 2 GiB |
Contenedores init
Los contenedores de inicialización
se ejecutan de forma secuencial y todos deben terminar de ejecutarse para que puedan iniciarse los contenedores de aplicaciones. En los clústeres de Autopilot, si no especificas solicitudes de CPU o memoria para los contenedores init o si asignas explícitamente el valor 0
a las solicitudes, Autopilot modificará tus pods durante la creación para añadir solicitudes de recursos a cada contenedor init. Las solicitudes asignadas a cada contenedor init son iguales a la suma de las solicitudes de todos los contenedores de aplicaciones del pod. Este es el comportamiento predeterminado.
Este comportamiento es diferente al de los clústeres estándar, en los que los contenedores de inicialización usan los recursos no asignados disponibles en el nodo en el que se programa el pod.
Asignación automática de recursos para contenedores init
La asignación automática de recursos para los contenedores init se produce al crear el pod. Te recomendamos que no especifiques manualmente las solicitudes de recursos de los contenedores init en los clústeres Autopilot para que cada contenedor obtenga de forma predeterminada todos los recursos disponibles para el pod.
Si cambias las solicitudes de recursos de los contenedores que no son init en el pod después de la creación, Autopilot no ajustará automáticamente las solicitudes de recursos de los contenedores init. Por lo tanto, es posible que observes cargos que no se correspondan con el uso real de recursos del pod. Tu factura se basa en la solicitud de recursos efectiva del pod, que es el mayor de los siguientes valores:
- La mayor solicitud de recursos de cualquier contenedor init del pod.
- Suma de las solicitudes de todos los contenedores de aplicaciones del pod.
Para obtener más información, consulta Gestión automática de recursos en Autopilot.
Asignación manual de recursos para contenedores init
Si necesitas cambiar las solicitudes de recursos de los contenedores de tu aplicación para gestionar los costes y los recursos, te recomendamos que hagas una de las siguientes acciones para ajustar las solicitudes de tu contenedor init:
- Actualiza manualmente las solicitudes de recursos
del contenedor init para que coincidan con el nuevo total de solicitudes del pod. Ten en cuenta lo siguiente al especificar manualmente las solicitudes de recursos:
- Las solicitudes inferiores a los recursos totales del pod pueden restringir el contenedor init.
- Si las solicitudes superan el total de recursos del pod, los costes pueden aumentar.
- Elimina las solicitudes de recursos para que Autopilot las vuelva a calcular. De forma predeterminada, Autopilot reasignará los recursos a cada contenedor init en función del total de recursos que soliciten todos los contenedores de aplicaciones del pod.
Configurar límites de recursos en Autopilot
Kubernetes te permite definir tanto requests
como limits
para los recursos de tu especificación de pod. El comportamiento de tus pods cambia en función de si tus limits
son diferentes de tus requests
, como se describe en la siguiente tabla:
Valores definidos | Comportamiento de Autopilot |
---|---|
requests es igual a limits |
Los pods usan la clase de QoS Guaranteed .
|
requests definido, limits no definido |
El comportamiento depende de si tu clúster admite picos de actividad, como se indica a continuación:
Para comprobar si tu clúster admite el bursting, consulta Disponibilidad del bursting en GKE. |
requests no se ha definido, limits se ha definido |
Autopilot asigna el valor requests a limits , que es el comportamiento predeterminado de Kubernetes.
Antes: resources: limits: cpu: "400m" Después: resources: requests: cpu: "400m" limits: cpu: "400m" |
requests menos que limits |
El comportamiento depende de si tu clúster admite picos de actividad, como se indica a continuación:
Para comprobar si tu clúster admite el bursting, consulta Disponibilidad del bursting en GKE. |
requests es mayor que limits |
Autopilot asigna el valor de limits a requests .
Antes: resources: requests: cpu: "450m" limits: cpu: "400m" Después: resources: requests: cpu: "400m" limits: cpu: "400m" |
requests no se ha configurado, limits no se ha configurado |
Autopilot asigna El comportamiento de
Para comprobar si tu clúster admite el bursting, consulta Disponibilidad del bursting en GKE. |
En la mayoría de los casos, define solicitudes de recursos adecuadas y límites iguales para tus cargas de trabajo.
En el caso de las cargas de trabajo que necesitan temporalmente más recursos que su estado estable, como durante el arranque o en periodos de mayor tráfico, define límites superiores a tus solicitudes para permitir que los pods tengan picos de actividad. Para obtener más información, consulta Configurar el aumento de pods en GKE.
Gestión automática de recursos en Autopilot
Si las solicitudes de recursos que has especificado para tus cargas de trabajo están fuera de los intervalos permitidos o si no solicitas recursos para algunos contenedores, Autopilot modifica la configuración de tu carga de trabajo para cumplir los límites permitidos. Autopilot calcula las proporciones de recursos y los requisitos de escalado de recursos después de aplicar los valores predeterminados a los contenedores sin ninguna solicitud especificada.
- Faltan solicitudes: si no solicitas recursos en algunos contenedores, Autopilot aplica las solicitudes predeterminadas de la clase de computación o la configuración de hardware.
- Relación CPU:memoria: Autopilot aumenta el recurso más pequeño para que la relación se ajuste al intervalo permitido.
- Almacenamiento efímero: Autopilot modifica tus solicitudes de almacenamiento efímero para cumplir la cantidad mínima que necesita cada contenedor. El valor acumulado de las solicitudes de almacenamiento de todos los contenedores no puede superar el valor máximo permitido. Antes de la versión 1.28.6-gke.1317000, Autopilot reduce el almacenamiento efímero solicitado si el valor supera el máximo. En la versión 1.28.6-gke.1317000 y posteriores, Autopilot rechaza tu carga de trabajo.
- Solicitudes por debajo de los mínimos: si solicitas menos recursos que el mínimo permitido para la configuración de hardware seleccionada, Autopilot modificará automáticamente el pod para que solicite al menos el valor mínimo de recursos.
De forma predeterminada, cuando Autopilot aumenta automáticamente los recursos de un recurso para alcanzar un valor mínimo o predeterminado, GKE asigna la capacidad adicional al primer contenedor del manifiesto del pod. En GKE 1.27.2-gke.2200 y versiones posteriores, puedes indicar a GKE que asigne los recursos adicionales a un contenedor específico añadiendo lo siguiente al campo annotations
del manifiesto de tu pod:
autopilot.gke.io/primary-container: "CONTAINER_NAME"
Sustituye CONTAINER_NAME
por el nombre del contenedor.
Ejemplos de modificación de recursos
En el siguiente ejemplo se muestra cómo modifica Autopilot la configuración de tu carga de trabajo para cumplir los requisitos de tus pods y contenedores en ejecución.
Contenedor único con menos de 0,05 vCPUs
Número de contenedor | Solicitud original | Solicitud modificada |
---|---|---|
1 |
CPU: 30 mCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
CPU: 50 mCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
Varios contenedores con una CPU total inferior a 0,05 vCPU
Número de contenedor | Solicitudes originales | Solicitudes modificadas |
---|---|---|
1 | CPU: 10 mCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
CPU: 30 mCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
2 | CPU: 10 mCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
CPU: 10 mCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
3 | CPU: 10 mvCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
CPU: 10 mCPU Memoria: 0,5 GiB Almacenamiento efímero: 10 MiB |
Recursos totales de pods | CPU: 50 mCPU Memoria: 1,5 GiB Almacenamiento efímero: 30 MiB |
Contenedor único con memoria demasiado baja para la CPU solicitada
En este ejemplo, la memoria es demasiado baja para la cantidad de CPU (1 vCPU:1 GiB como mínimo). La relación mínima permitida entre CPU y memoria es de 1:1. Si la proporción es inferior, se aumenta la solicitud de memoria.
Número de contenedor | Solicitud original | Solicitud modificada |
---|---|---|
1 | CPU: 4 vCPU Memoria: 1 GiB Almacenamiento efímero: 10 MiB |
CPU: 4 vCPU Memoria: 4 GiB Almacenamiento efímero: 10 MiB |
Recursos totales de pods | CPU: 4 vCPU Memoria: 4 GiB Almacenamiento efímero: 10 MiB |
Siguientes pasos
- Consulta cómo seleccionar clases de computación en tus cargas de trabajo de Autopilot.
- Consulta más información sobre las clases de computación de Autopilot admitidas.
- Consulta cómo seleccionar GPUs en tus pods de Autopilot.