Container Service for Kubernetes:CPU topology-aware scheduling

Cómo funciona

De forma predeterminada, Kubernetes utiliza el Completely Fair Scheduler (CFS) del kernel para distribuir los intervalos de tiempo de CPU entre todos los núcleos. El CFS ignora la topología física de la CPU y puede generar una latencia impredecible en aplicaciones sensibles al rendimiento.

El CPU Manager de Kubernetes (con la directiva static) permite vincular pods a núcleos de CPU exclusivos, pero presenta tres limitaciones:

• Falta de detección de topología a nivel de clúster: el kube-scheduler nativo opera únicamente a nivel de nodo y no tiene visibilidad de la topología de CPU de todo el clúster.

• Falta de compatibilidad con NUMA: la directiva static no considera la arquitectura NUMA al asignar núcleos. Esto puede forzar el acceso a memoria entre nodos NUMA e introducir latencia adicional.

• Guaranteed QoS only: esta directiva aplica únicamente a pods con la clase de QoS Guaranteed. No es compatible con pods Burstable ni BestEffort.

ACK resuelve estas limitaciones mediante la colaboración entre el kube-scheduler de ACK y ack-koordinator, basados en el Scheduling Framework de Kubernetes:

1. Reporte de topología del nodo: ack-koordinator detecta continuamente la topología física local de la CPU (sockets, nodos NUMA y cachés) y envía estos datos al centro de programación.

2. Programación global con detección de topología: el kube-scheduler usa los datos de topología de todo el clúster para seleccionar el nodo óptimo de cada pod y planificar la asignación de núcleos. De forma predeterminada, el programador busca el núcleo con menos aplicaciones vinculadas. El esquema de asignación resultante se escribe en la anotación del pod.

3. Fijación local de núcleos: cuando el pod llega al nodo de destino, ack-koordinator lee su anotación y modifica el archivo cpuset.cpus en el cgroup del pod. Así vincula el pod a los núcleos físicos asignados.

Casos de uso

La programación de CPU con detección de topología ofrece mejores resultados en las siguientes cargas de trabajo:

• Aplicaciones sensibles a la latencia: los sistemas de negociación de alta frecuencia y los pipelines de procesamiento de datos en tiempo real no toleran retrasos por cambios de contexto de CPU. Sin la fijación de CPU, el programador CFS puede migrar el proceso entre núcleos durante la ejecución. Esto resulta inofensivo en un entorno de pruebas, pero genera un impacto medible en producción bajo carga.

• Aplicaciones sensibles a NUMA: las cargas de trabajo en servidores multisocket (como las instancias Elastic Bare Metal de AMD o Intel) presentan una latencia notable cuando los accesos a memoria cruzan límites NUMA. Fijar los núcleos dentro de un solo nodo NUMA elimina esta sobrecarga.

• Cómputo determinista: los trabajos de cómputo científico y análisis de big data requieren un throughput de CPU estable y predecible. La fijación elimina la variabilidad que introduce compartir núcleos con otras cargas de trabajo.

• Aplicaciones heredadas que ignoran los límites de CPU del contenedor: algunas aplicaciones generan hilos según el número total de núcleos físicos del host, en lugar del límite de CPU del contenedor. Estas aplicaciones se benefician de la fijación, ya que vincula el proceso a un conjunto específico de núcleos.

Elegir una directiva de fijación

ACK proporciona dos directivas de fijación:

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

• Un clúster administrado de ACK de edición Pro

• Un node pool con cpuManagerPolicy establecido en none. Para obtener más información, consulte Customize kubelet configurations for a node pool

• ack-koordinator instalado en la versión 0.2.0 o posterior. Para consultar las instrucciones de instalación, consulte ack-koordinator

Paso 2: Habilitar la programación de CPU con detección de topología

Habilite la programación de CPU con detección de topología mediante la adición de anotaciones a la especificación del pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      annotations:
        cpuset-scheduler: "true"  # Enables CPU topology-aware scheduling
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0
        ports:
        - containerPort: 80
        command:
        - "sleep"
        - "infinity"
        resources:
          requests:
            cpu: 4
            memory: 8Gi
          limits:
            cpu: 4       # Must be an integer
            memory: 8Gi

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      annotations:
        cpuset-scheduler: "true"    # Enables CPU topology-aware scheduling
        cpu-policy: "static-burst"  # Enables automatic pinning and NUMA affinity
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0
        ports:
        - containerPort: 80
        command:
        - "sleep"
        - "infinity"
        resources:
          requests:
            cpu: 4
            memory: 8Gi
          limits:
            cpu: 4       # Must be an integer
            memory: 8Gi

Aplicar en producción

Deshabilitar la programación de CPU con detección de topología

1. Edite el archivo YAML de la aplicación. Elimine la anotación cpuset-scheduler: "true" y, si existe, la anotación cpu-policy: "static-burst" de spec.template.metadata.annotations.

2. Aplique el archivo YAML modificado fuera del horario de mayor actividad. Los cambios surten efecto después de reiniciar el pod.

Facturación

La instalación y el uso de ack-koordinator son gratuitos. Pueden aplicarse cargos adicionales en los siguientes casos:

• ack-koordinator es un componente no administrado que consume recursos de los nodos worker después de la instalación. Configure las solicitudes de recursos de cada módulo durante la instalación.

• Si selecciona la opción Enable Prometheus monitoring for ACK-Koordinator y utiliza Alibaba Cloud Prometheus, las métricas de monitoreo se contabilizan como métricas personalizadas y generan cargos. El costo depende del tamaño del clúster y de la cantidad de aplicaciones. Antes de habilitar esta opción, revise la información de facturación de Prometheus para conocer la cuota gratuita y los precios. Haga un seguimiento de su consumo mediante la consulta de sus datos de uso.

Pasos siguientes

• GPU topology-aware scheduling: seleccione la combinación óptima de GPU en un nodo para maximizar la velocidad de entrenamiento.

• Dynamic resource overcommitment: recupere los recursos del clúster asignados pero no utilizados y asígnelos a trabajos de baja prioridad.