Container Service for Kubernetes:Scheduling overview

Política

Descripción

Escenario

nodeSelector

Etiquete los nodos con pares clave-valor y utilice nodeSelector para programar pods en los nodos coincidentes.

Por ejemplo, schedule pods to specific nodes o schedule pods to a specific node pool.

Método básico de selección de nodos que no admite funciones de programación más complejas, como reglas de programación flexible.

nodeAffinity

Ofrece mayor flexibilidad y granularidad que nodeSelector. Por ejemplo, incluye la regla estricta requiredDuringSchedulingIgnoredDuringExecution y la regla flexible preferredDuringSchedulingIgnoredDuringExecution.

Programa pods en nodos con características específicas, como regiones, tipos de dispositivo o hardware. Las reglas de anti-afinidad distribuyen los pods entre distintos nodos.

Taints and tolerations

Un taint consta de una clave, un valor y un efecto (efectos comunes: NoSchedule, PreferNoSchedule, NoExecute). Solo los pods con una tolerancia coincidente se programan en nodos con taints.

• Reservar recursos exclusivos en nodos para aplicaciones específicas, como nodos acelerados por GPU para cargas de trabajo de IA o ML.

• Agregar taints o etiquetas a node pools para dirigir los pods de aplicaciones a pools específicos. Consulte Create and manage node pools y Modify a node pool.

• Evictar pods basándose en taints y tolerancias. Por ejemplo, agregue un taint a un nodo con problemas de salud y establezca el efecto en NoExecute.

Inter-pod affinity and anti-affinity

Las etiquetas de los pods determinan la programación de pod a nodo. Admite la regla de afinidad requiredDuringSchedulingIgnoredDuringExecution y la regla de anti-afinidad preferredDuringSchedulingIgnoredDuringExecution.

• Ubicar pods colaborativos en el mismo nodo o en nodos adyacentes para reducir la latencia de red.

• Distribuir pods de aplicaciones críticas en diferentes nodos o dominios de fallo.

Política

Descripción

Escenario

Referencia

Programación de recursos basada en prioridad personalizada

Especifique un valor personalizado de ResourcePolicy durante los despliegues o el escalado para definir el orden de selección de recursos de nodo. Por ejemplo, puede dar preferencia a instancias ECS de suscripción, seguidas de instancias ECS pay-as-you-go y finalmente instancias de contenedor elástico.

La reducción de escala invierte este orden: primero las instancias de contenedor elástico, luego las instancias ECS pay-as-you-go y por último las instancias ECS de suscripción.

• Definir nodos preferidos o evitados para equilibrar el uso de recursos del clúster.

• Programar preferentemente los pods de aplicaciones de alto rendimiento en nodos de alto rendimiento.

• Programar preferentemente los pods no críticos para el rendimiento en preemptible instances o nodos con recursos inactivos, reduciendo así los costos.

Custom priority scheduling for elastic resources

Política

Descripción

Escenario

Referencia

Gang Scheduling

Todos los pods relacionados se programan conjuntamente o ninguno en absoluto, lo que evita que procesos anómalos bloqueen al grupo.

• Trabajos por lotes: Un trabajo contiene varias tareas interdependientes que deben procesarse simultáneamente.

• Computación distribuida: Trabajos de entrenamiento de aprendizaje automático u otras aplicaciones distribuidas que deben ejecutarse al mismo tiempo.

• Computación de alto rendimiento: Un trabajo puede requerir todos los recursos disponibles simultáneamente antes de su ejecución.

Use Gang scheduling

Capacity Scheduling

Reserva recursos para namespaces o grupos de usuarios específicos, y mejora la utilización mediante el uso compartido de recursos cuando los recursos del clúster son limitados.

En clústeres multiinquilino, los distintos ciclos de vida de los recursos y patrones de uso provocan una baja utilización. El uso compartido y la recuperación de recursos mejoran la utilización general.

Work with capacity scheduling

Descripción

Escenario

Referencia

El programador utiliza etiquetas de gang scheduling para garantizar que todas las solicitudes de recursos de los pods se cumplan simultáneamente. La programación consciente de topología itera a través de dominios de topología para encontrar uno que satisfaga todos los requisitos de los pods.

Asocie node pools con deployment sets para programar pods en instancias ECS dentro del mismo conjunto de despliegue de baja latencia y mejorar el rendimiento del trabajo.

En trabajos de aprendizaje automático o big data, los pods necesitan comunicarse frecuentemente. El programador itera a través de dominios de topología para encontrar uno que satisfaga todos los requisitos de los pods, reduciendo así el tiempo de finalización del trabajo.

• Topology-aware scheduling

• Best practices for deployment sets in node pools

Descripción

Escenario

Referencia

El programador de ACK supervisa el historial de carga de los nodos y estima el uso de recursos de los nuevos pods para programarlos en nodos con menor carga, evitando fallos por sobrecarga.

Aplicaciones sensibles a la carga, la latencia de acceso o la QoS de recursos.

Use load-aware scheduling

Política

Descripción

Escenario

Referencia

CPU Burst

El sistema operativo puede limitar el uso de CPU del contenedor dentro de un ciclo (limitación de CPU). CPU Burst permite que los contenedores inactivos acumulen segmentos de tiempo de CPU y superen el límite de CPU durante picos de demanda, mejorando el rendimiento y reduciendo la latencia.

• Contenedores que consumen mucha CPU durante el inicio y la carga, pero requieren un uso regular de CPU posteriormente.

• Aplicaciones con picos repentinos de CPU, como comercio electrónico, videojuegos y otros servicios web, que deben responder rápidamente a aumentos de tráfico.

Enable the CPU Burst performance optimization policy

Programación de CPU consciente de topología

Fija pods sensibles a la CPU a núcleos específicos para evitar la degradación del rendimiento causada por cambios frecuentes de contexto y acceso a memoria cross-NUMA.

• Aplicaciones no adaptadas a entornos cloud-native; por ejemplo, recuentos de hilos basados en núcleos físicos en lugar de especificaciones del contenedor, lo que causa degradación del rendimiento.

• Aplicaciones en instancias ECS Bare Metal multinúcleo con CPU Intel o AMD que experimentan degradación del rendimiento debido al acceso a memoria cross-NUMA.

• Aplicaciones altamente sensibles al cambio de contexto de CPU que no toleran fluctuaciones de rendimiento.

Enable CPU topology-aware scheduling

Programación de GPU consciente de topología

Cuando varios pods intensivos en GPU se ejecutan simultáneamente, pueden competir por recursos de GPU y alternar entre GPUs o nodos NUMA, degradando el rendimiento. La programación de GPU consciente de topología asigna cargas de trabajo a GPUs específicas, reduciendo el acceso a memoria cross-NUMA y mejorando el rendimiento.

• Computación distribuida a gran escala que requiere transferencia eficiente de datos, como la computación de alto rendimiento.

• Cargas de trabajo de aprendizaje automático y aprendizaje profundo que requieren amplios recursos de GPU y una asignación adecuada de trabajos de entrenamiento entre GPUs.

• Renderizado gráfico y desarrollo de videojuegos que requieren una asignación eficiente de trabajos de renderizado entre GPUs.

• GPU topology-aware scheduling

• Enable NUMA topology-aware scheduling

Sobreasignación dinámica de recursos

Recupera recursos asignados pero no utilizados por los pods y los programa para trabajos de baja prioridad, permitiendo la sobreasignación. Utilice conjuntamente las siguientes políticas de QoS de nodo único para evitar que las aplicaciones se afecten mutuamente:

• CPU Suppress: Limita los recursos de CPU disponibles para pods de baja prioridad cuando el uso general del nodo está por debajo del umbral, garantizando la estabilidad del contenedor.

• CPU QoS: Garantiza una asignación suficiente de CPU para aplicaciones de alta prioridad.

• Memory QoS: Garantiza una asignación suficiente de memoria para aplicaciones de alta prioridad y retrasa la recuperación de memoria.

• Aislamiento de recursos basado en caché L3 y Memory Bandwidth Allocation (MBA): Prioriza la caché L3 y MBA para aplicaciones de alta prioridad.

Mejora la utilización de recursos del clúster mediante la coubicación. Los escenarios típicos incluyen entrenamiento e inference de modelos de ML, procesamiento y análisis por lotes de big data, servicios en línea y copias de seguridad sin conexión.

• Enable dynamic resource overcommitment

• Enable CPU Suppress

• Enable CPU QoS for containers

• Memory QoS

• Enable resource isolation based on the L3 cache and MBA

• Best practices for colocation

Modificar dinámicamente los parámetros de recursos de un pod

En Kubernetes 1.27 o anterior, modificar parámetros del contenedor requiere eliminar y recrear el pod. ACK le permite modificar límites de CPU, memoria e IOPS de disco sin reiniciar el pod.

Ajustes temporales de recursos de CPU o memoria.

Dynamically modify pod resource parameters

Política

Descripción

Escenario

Referencia

Desprogramación

Reprograma pods ubicados incorrectamente hacia nodos óptimos cuando se forman puntos críticos debido a un uso desigual de recursos o cambios en atributos de nodos, garantizando la alta disponibilidad y eficiencia de la carga de trabajo.

• Distribución desigual de cargas de trabajo con nodos sobrecargados, por ejemplo en escenarios de coubicación.

• Baja utilización de recursos del clúster que requiere la eliminación de nodos para reducir costos.

• La fragmentación de recursos impide que nodos individuales tengan recursos suficientes a pesar de haber capacidad adecuada en todo el clúster.

• Se agregan o eliminan taints o etiquetas de un nodo.

• Descheduling

• Enable the descheduling feature

Trabajo conjunto con desprogramación de puntos críticos consciente de carga

Combina la programación consciente de carga y la desprogramación de puntos críticos para supervisar las cargas de los nodos y reequilibrar automáticamente aquellos que superan el umbral de carga.

Load-aware hotspot descheduling