Estrategias para reducir la latencia de inicio

Google Kubernetes Engine (GKE) proporciona varias estrategias que te ayudan a reducir la latencia de inicio de los Pods cuando tus cargas de trabajo escalan verticalmente. Si reduces los retrasos en el aprovisionamiento de nodos, las extracciones de imágenes de contenedor y la inicialización de aplicaciones, puedes mejorar la capacidad de respuesta del servicio durante los aumentos repentinos de tráfico y equilibrar los costos de infraestructura.

Usa este documento para comparar las estrategias de reducción de latencia de inicio de GKE en el ciclo de vida de inicio de Pods y elegir una sola estrategia o una combinación en capas que se adapte a los requisitos de tu carga de trabajo.

Comprende el ciclo de vida de inicio de Pods

Cuando una carga de trabajo escala verticalmente en GKE y los nodos existentes no tienen suficiente capacidad asignable para los Pods nuevos, la latencia de inicio de extremo a extremo abarca tres etapas secuenciales:

  • Durante la etapa de aprovisionamiento de nodos y programación de Pods, el escalador automático de clústeres aprovisiona una VM nueva de Compute Engine, inicializa el nodo y lo registra en el plano de control para que el programador de Kubernetes pueda colocar el Pod pendiente.
  • Durante la etapa de extracción de imágenes de contenedor, el componente kubelet del nodo descarga y descomprime las imágenes de contenedor que requiere el Pod de tu Container Registry.
  • Durante la etapa de inicialización de la aplicación, el entorno de ejecución del contenedor inicia el proceso de la aplicación, carga las dependencias o los pesos del modelo en la memoria y pasa las sondas de inicio y preparación de Kubernetes.

Las diferentes funciones de GKE se orientan a etapas específicas de este ciclo de vida. Para descubrir qué etapa contribuye más al tiempo de inicio de tu carga de trabajo, consulta Supervisa las métricas de latencia de inicio.

Compara las estrategias de reducción de latencia de inicio

En la siguiente tabla, se comparan las estrategias de reducción de latencia de inicio de GKE en el ciclo de vida de inicio de Pods:

Estrategia Etapa del ciclo de vida Perfil de latencia Perfil de costos y cuota Modo de clúster y compatibilidad con hardware Ideal para
Buffers de capacidad activa (vista previa) Aprovisionamiento de nodos y programación de Pods Programación inmediata de Pods porque los nodos ya se están ejecutando

Tarifas de procesamiento basadas en nodos estándar para ejecutar VMs

Consume cuotas de CPU virtual, memoria, disco y dirección IP de Compute Engine cuotas, además de cuotas de recursos de Kubernetes en el espacio de nombres

Clústeres de Standard y clústeres de Autopilot con ComputeClasses personalizadas (facturación basada en nodos)

Admite CPUs, GPUs y TPUs

 Absorber aumentos repentinos de tráfico y escalar cargas de trabajo de GPU, TPU o CPU sensibles a la latencia
Buffers de capacidad en espera (vista previa) Aprovisionamiento de nodos y programación de Pods Reanuda los nodos suspendidos en aproximadamente 30 a 35 segundos, lo que es más rápido que aprovisionar un nodo nuevo

No se aplican cargos de procesamiento de VM mientras están suspendidas Genera cargos de almacenamiento de Persistent Disk para discos de arranque y estado de memoria almacenado

Consume cuotas de disco y dirección IP mientras está suspendido, además de cuotas de recursos de Kubernetes en el espacio de nombres

Clústeres de Standard (con aprovisionamiento automático de nodos) y clústeres de Autopilot con ComputeClasses personalizadas

Solo admite CPUs (sin GPUs, TPUs ni SSDs locales)

 Mantener una capacidad de aumento rentable para el crecimiento sostenido del tráfico crecimiento.
Nodos de inicio rápido Aprovisionamiento de nodos y programación de Pods Reduce el tiempo de inicio de nodos en frío de la mejor manera posible mediante el uso de hardware preinicializado Se proporciona sin cargo adicional

Clústeres de Autopilot y cargas de trabajo de Autopilot en clústeres de Standard

Admite series de máquinas de uso general y GPU aptas sin SSDs locales ni VMs Spot

 Acelerar el aprovisionamiento de nodos de referencia con cero configuración o costo de capacidad inactiva
Pods de marcadores de posición de baja prioridad Aprovisionamiento de nodos y programación de Pods Programación inmediata de Pods después de expulsar los Pods de marcadores de posición de menor prioridad

Tarifas de procesamiento estándar para nodos en ejecución

Requiere la administración manual de Deployment y PriorityClass

 Clústeres de Standard y Autopilot Reservar capacidad libre en clústeres que usan la facturación basada en Pods o versiones anteriores a la 1.35
Transmisión de imágenes Extracción de imágenes de contenedor Permite que los contenedores se inicien sin esperar a que se descargue toda la imagen

Se proporciona sin cargo adicional

Requiere Artifact Registry o repositorios de Docker Hub aptos

 Clústeres de Autopilot (habilitados de forma predeterminada) y Standard clusters. Reducir los tiempos de extracción de imágenes para imágenes de contenedor grandes
Discos de arranque secundarios Extracción de imágenes de contenedor Adjunta un Persistent Disk propagado previamente a los nodos nuevos en paralelo con el aprovisionamiento de nodos Se factura el Persistent Disk adjunto en cada nodo y el almacenamiento de imágenes de disco Clústeres de Standard y Autopilot Precargar imágenes de contenedor grandes o conjuntos de datos estáticos, como los pesos del modelo de aprendizaje automático
Instantáneas de Pods Inicialización de la aplicación Restablece las réplicas de Pods nuevos directamente desde un punto de control guardado de la memoria del proceso y el estado del sistema de archivos Se factura el almacenamiento de instantáneas en Cloud Storage

Clústeres de Standard y Autopilot que ejecutan Pods en GKE Sandbox

Admite tipos de máquinas de CPU y GPU aptos (sin TPUs)

 Omitir la inicialización prolongada para modelos y aplicaciones de inferencia de IA con rutinas de inicio pesadas
Aumento de CPU de inicio (vista previa) Inicialización de la aplicación Aumenta temporalmente las solicitudes y los límites de CPU durante el inicio del Pod y, luego, los cambia de tamaño en el lugar Consume temporalmente la capacidad adicional de CPU del nodo durante la ventana de inicio Clústeres de Standard y Autopilot con el ajuste de escala automático vertical de Pods habilitado Acelerar la inicialización vinculada a la CPU para entornos de ejecución como Java, Python o Node.js.

Elige una estrategia por etapa de inicio de Pods

En las siguientes secciones, se describen las opciones disponibles para cada etapa del ciclo de vida de inicio de Pods.

Acelera el aprovisionamiento de nodos y la programación de Pods

Cuando los Pods pendientes no caben en los nodos existentes, esperar a que se inicie un nodo nuevo suele ser el factor que más contribuye a la latencia de escalamiento vertical. Puedes reducir o eliminar este retraso con las siguientes estrategias:

  • Usa buffers de capacidad para reservar de forma declarativa la capacidad de nodo libre:
    • Configura un buffer activo (estrategia buffer.x-k8s.io/active-capacity) para mantener los nodos aprovisionados previamente en ejecución y listos para programar Pods de inmediato. Los buffers activos admiten cargas de trabajo de CPU, GPU y TPU.
    • Configura un buffer en espera (estrategia buffer.gke.io/standby-capacity) para mantener los nodos de CPU aprovisionados previamente en un estado suspendido. Cuando las cargas de trabajo escalan verticalmente, GKE reanuda los nodos en espera en aproximadamente 30 a 35 segundos, lo que evita el costo de procesamiento completo de ejecutar VMs inactivas.
  • Usa nodos de inicio rápido para la preinicialización automática y de la mejor manera posible del hardware en cargas de trabajo de Autopilot y series de máquinas de GPU aptas. Cuando GKE aprovisiona nodos nuevos para una carga de trabajo apta, usa automáticamente nodos de inicio rápido. Esto incluye los nodos creados para rellenar un buffer de capacidad en una ComputeClass personalizada de Autopilot compatible.
  • Implementa Pods de marcadores de posición de baja prioridad con PriorityClasses de Kubernetes si tus cargas de trabajo usan el modelo de facturación basado en Pods de Autopilot o se ejecutan en versiones de GKE anteriores a la 1.35. Para los clústeres que usan la facturación basada en nodos en versiones compatibles de GKE, prefiere los buffers de capacidad declarativos porque no requieren administrar implementaciones de marcadores de posición ni bucles de expulsión de Pods.

Acelera las extracciones de imágenes de contenedor

Después de que el programador coloca un Pod en un nodo, el nodo debe extraer la imagen de contenedor antes de iniciar el contenedor. Puedes reducir la latencia de extracción de imágenes con las siguientes estrategias:

  • Habilita la transmisión de imágenes para permitir que los contenedores se inicien en cuanto los archivos necesarios se transmitan por la red, mientras que el resto de la imagen se descarga en segundo plano. Los clústeres de Autopilot habilitan la transmisión de imágenes de forma predeterminada para las imágenes aptas en Artifact Registry.
  • Configura discos de arranque secundarios para precargar capas base de contenedores grandes o conjuntos de datos estáticos en una imagen de disco personalizada. Cuando GKE crea un nodo, adjunta un Persistent Disk creado a partir de tu imagen de disco en paralelo con el aprovisionamiento de nodos.
  • Ejecuta un DaemonSet para precargar imágenes de contenedor en buffers en espera durante la ventana de inicialización del nodo (buffer.gke.io/standby-capacity-init-time anotación). Antes de que GKE suspenda un nodo en espera, el DaemonSet extrae las imágenes de tu carga de trabajo al disco de arranque del nodo para que las imágenes ya estén almacenadas en caché cuando se reanude el nodo.

Acelera la inicialización de la aplicación

Incluso después de que un nodo se está ejecutando y la imagen de contenedor está presente, las aplicaciones pueden tardar mucho tiempo en cargar frameworks, compilar código Just-In-Time (JIT) o cargar pesos del modelo en la memoria. Puedes reducir el tiempo de inicialización con las siguientes estrategias:

  • Configura instantáneas de Pods para capturar un punto de control de la memoria de un Pod en ejecución y el estado del sistema de archivos en GKE Sandbox. Cuando tu carga de trabajo escala horizontalmente, GKE restablece las réplicas nuevas desde la instantánea en Cloud Storage para que el Pod reanude la ejecución desde el punto en que se tomó la instantánea en lugar de inicializar desde un estado nuevo.
  • Configura el aumento de CPU de inicio en un VerticalPodAutoscaler para asignar CPU adicional a un Pod durante la admisión y la inicialización. Después de que el Pod alcanza el estado Ready y finaliza la duración del aumento configurada, GKE reduce la solicitud de CPU del Pod a su nivel de referencia en el lugar sin reiniciar el contenedor.

Combina estrategias para la optimización de extremo a extremo

Debido a que estas estrategias operan en diferentes etapas del ciclo de vida de inicio de Pods, puedes superponerlas para optimizar el tiempo de escalamiento vertical de extremo a extremo:

  • Combina un buffer de capacidad activa pequeño con un buffer de capacidad en espera más grande. Durante un aumento repentino de tráfico, el buffer activo absorbe el aumento inicial de Pods de inmediato. Mientras tanto, GKE reanuda los nodos del buffer en espera en aproximadamente 30 a 35 segundos para reabastecer el buffer activo y controlar el crecimiento sostenido. En segundo plano, el escalador automático de clústeres aprovisiona y suspende nodos nuevos para rellenar el buffer en espera.
  • Para los buffers de capacidad en espera, habilita la transmisión de imágenes o precarga imágenes de contenedor con un DaemonSet antes de que se suspenda el nodo para que el nodo no pierda tiempo descargando imágenes de contenedor grandes cuando se reanude.
  • Superpone el aumento de CPU de inicio o las instantáneas de Pods sobre los buffers de capacidad o los nodos de inicio rápido para que, después de que GKE programe un Pod en un nodo aprovisionado previamente o preinicializado, el Pod evite la limitación de CPU durante el inicio o se restablezca directamente desde una instantánea guardada.

Para medir el efecto de cualquier estrategia única o combinada en tus cargas de trabajo, consulta los gráficos Distribución de latencia de inicio de Pods y Latencia de primer estado listo de Pods en Cloud Monitoring y, luego, inspecciona los registros de latencia de programación en Cloud Logging. Para obtener instrucciones, consulta Supervisa las métricas de latencia de inicio.

¿Qué sigue?