Container Compute Service:Use GPU sharing on GPU-HPN nodes

Estados do pod e Qualidade de Serviço

Assim como no gerenciamento de processos do sistema operacional, o módulo de compartilhamento de GPU atribui a cada pod um de três estados:

• Hibernação: O pod não tem demanda de GPU (estado inicial quando um pod é iniciado).

• Pronto: O pod está aguardando a alocação de recursos de GPU.

• Em execução: O pod está usando ativamente recursos de GPU.

Quando vários pods competem por recursos de GPU simultaneamente, o módulo de compartilhamento de GPU aplica políticas de Qualidade de Serviço (QoS) para gerenciar a alocação de forma justa.

Política de fila (apenas modelo share-pool)

Os pods no estado pronto são enfileirados usando First In, First Out (FIFO). O pod que entrou primeiro no estado pronto recebe recursos primeiro. Se os recursos forem insuficientes, a política de preempção será acionada.

Política de preempção (apenas modelo share-pool)

Quando um pod na fila de prontos não consegue obter recursos, o módulo de compartilhamento de GPU tenta preemptar um pod em execução usando os seguintes critérios:

Se nenhum pod em execução atender à condição de filtro, o pod enfileirado continua aguardando.

Escolher um modelo de compartilhamento

O ACS suporta dois modelos de compartilhamento. A principal diferença é se um pod recebe um dispositivo GPU fixo ou pode usar qualquer GPU disponível no nó:

• Use share-pool quando as cargas de trabalho forem intermitentes ou variáveis (como sessões de Notebook). Os pods compartilham recursos de um pool comum de GPU, com mecanismos de QoS (fila e preempção) gerenciando a contenção.

• Use static quando as cargas de trabalho precisarem de acesso garantido e ininterrupto à GPU, sem filas. Cada pod é fixado a um dispositivo GPU específico.

Exemplo: compartilhamento de recursos fora de pico em cenários de Notebook

No desenvolvimento com Notebook, as cargas de trabalho geralmente não mantêm recursos de GPU continuamente. Com o modelo share-pool, os pods usam recursos de GPU apenas quando necessário, e o mecanismo de QoS gerencia o acesso quando vários pods solicitam recursos simultaneamente.

Considere quatro pods em um nó com duas GPUs:

• Pods A e B: requests=0.5, limits=0.5

• Pods C e D: requests=0.5, limits=1

Com base nos requests, todos os quatro pods cabem no nó.

Tempo T1: Os pods A e C estão em execução. Os pods B e D estão na fila de prontos. O módulo de compartilhamento de GPU tenta alocar recursos para o Pod D (primeiro na fila). A GPU 0 tem 0,5 de GPU ociosa, o que satisfaz os requests=0.5 do Pod D, mas o limit=1 do Pod D causaria competição de recursos com o Pod A na mesma GPU. Portanto, o Pod D permanece na fila.

Tempo T2 – Fase 1: O Pod C termina e entra em hibernação. A GPU 1 fica livre e seus recursos são alocados para o Pod D.

Tempo T2 – Fase 2: O Pod B recebe recursos alocados na GPU 0. Como o limit=0.5 do Pod B, ele pode compartilhar a GPU 0 com o Pod A sem competição de recursos.

Pré-requisitos

Antes de começar, certifique-se de que você tem:

• Um cluster ACS com nós GPU-HPN.

• kubectl configurado para conectar-se ao cluster.

• Excluído quaisquer pods no nó de destino que solicitem recursos exclusivos de GPU. Pods que usam apenas CPU e memória não precisam ser excluídos.

Etapa 1: Rotular o nó GPU-HPN

Liste os nós GPU-HPN no cluster:

kubectl get node -l alibabacloud.com/node-type=reserved

Saída esperada:

NAME                     STATUS   ROLES   AGE   VERSION
cn-wulanchabu-c.cr-xxx   Ready    agent   59d   v1.28.3-aliyun

Adicione o rótulo alibabacloud.com/gpu-share-policy=share-pool para ativar o compartilhamento de GPU:

kubectl label node cn-wulanchabu-c.cr-xxx alibabacloud.com/gpu-share-policy=share-pool

Etapa 2: Verificar o status do nó

Após aplicar o rótulo, verifique se o recurso está ativo no nó:

kubectl get node cn-wulanchabu-c.cr-xxx -o yaml

Saída esperada (trecho):

# The actual output may vary.
apiVersion: v1
kind: Node
spec:
  # ...
status:
  allocatable:
    # GPU shared resource description
    alibabacloud.com/gpu-core.percentage: "1600"
    alibabacloud.com/gpu-memory.percentage: "1600"
    # CPU, memory, and storage reserved for the GPU sharing module
    cpu: "144"
    memory: 1640Gi
    nvidia.com/gpu: "16"
    ephemeral-storage: 4608Gi
  capacity:
    # GPU shared resource description
    alibabacloud.com/gpu-core.percentage: "1600"
    alibabacloud.com/gpu-memory.percentage: "1600"
    cpu: "176"
    memory: 1800Gi
    nvidia.com/gpu: "16"
    ephemeral-storage: 6Ti
  conditions:
  # Indicates whether the GPU share policy configuration is valid
  - lastHeartbeatTime: "2025-01-07T04:13:04Z"
    lastTransitionTime: "2025-01-07T04:13:04Z"
    message: gpu share policy is valid.
    reason: Valied
    status: "True"
    type: GPUSharePolicyValid
  # Indicates the GPU share policy in effect on this node
  - lastHeartbeatTime: "2025-01-07T04:13:04Z"
    lastTransitionTime: "2025-01-07T04:13:04Z"
    message: gpu share policy is share-pool.
    reason: share-pool
    status: "True"
    type: GPUSharePolicy

Confirme os seguintes itens na saída para verificar se o recurso está ativo:

• allocatable e capacity incluem alibabacloud.com/gpu-core.percentage e alibabacloud.com/gpu-memory.percentage.

• A condição GPUSharePolicyValid tem status: "True".

• A condição GPUSharePolicy tem reason: share-pool.

Se os recursos do nó não forem atualizados conforme descrito, a configuração falhou. Verifique os campos reason e message da condição GPUSharePolicyValid para obter detalhes. Consulte Condições do nó para valores de motivo.

Etapa 3: Implantar um pod com recursos compartilhados de GPU

Crie um arquivo chamado gpu-share-demo.yaml. Defina o modelo de compartilhamento de GPU como share-pool, correspondendo à configuração do nó:

apiVersion: v1
kind: Pod
metadata:
  labels:
    alibabacloud.com/compute-class: "gpu-hpn"
    # Set the GPU sharing model to share-pool, matching the node configuration
    alibabacloud.com/gpu-share-policy: "share-pool"
  name: gpu-share-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: registry-cn-wulanchabu-vpc.ack.aliyuncs.com/acs/stress:v1.0.4
    args:
      - '1000h'
    command:
      - sleep
    resources:
      limits:
        cpu: '5'
        memory: 50Gi
        alibabacloud.com/gpu-core.percentage: 100   # Upper limit of computing power usage
        alibabacloud.com/gpu-memory.percentage: 100  # Upper limit of GPU memory usage; exceeding this causes a CUDA OOM error
      requests:
        cpu: '5'
        memory: 50Gi
        alibabacloud.com/gpu-core.percentage: 10    # Controls how many pods can be scheduled on the node
        alibabacloud.com/gpu-memory.percentage: 10   # Controls how many pods can be scheduled on the node

Implante o pod:

kubectl apply -f gpu-share-demo.yaml

Etapa 4: Verificar o uso de recursos de GPU

Faça login no container para verificar o uso de recursos de GPU:

kubectl exec -it gpu-share-demo -- /bin/bash

Dentro do container, use nvidia-smi para visualizar a alocação e o uso de recursos de GPU. O comando a ser usado depende do tipo da sua placa GPU — nvidia-smi aplica-se a dispositivos GPU NVIDIA. Para outros tipos de placa, abra um ticketabra um ticket para obter assistência.

Etapa 5 (opcional): Desativar o compartilhamento de GPU no nó

1. Exclua o pod:

   kubectl delete pod gpu-share-demo

2. Defina a política de compartilhamento de GPU como none:

   kubectl label node cn-wulanchabu-c.cr-xxx alibabacloud.com/gpu-share-policy=none

3. Verifique o status do nó:

   • allocatable e capacity não incluem mais alibabacloud.com/gpu-core.percentage ou alibabacloud.com/gpu-memory.percentage.

   • A condição GPUSharePolicy tem status: "False" e reason: none.

   • A CPU e a memória em allocatable são restauradas aos seus valores originais.

   kubectl get node cn-wulanchabu-c.cr-xxx -o yaml

   Saída esperada (trecho):

   apiVersion: v1
   kind: Node
   spec:
     # ...
   status:
     allocatable:
       # Reserved CPU and memory are restored after the feature is disabled
       cpu: "176"
       memory: 1800Gi
       nvidia.com/gpu: "16"
       ephemeral-storage: 4608Gi
     capacity:
       cpu: "176"
       memory: 1800Gi
       nvidia.com/gpu: "16"
       ephemeral-storage: 6Ti
     conditions:
     - lastHeartbeatTime: "2025-01-07T04:13:04Z"
       lastTransitionTime: "2025-01-07T04:13:04Z"
       message: gpu share policy config is valid.
       reason: Valid
       status: "True"
       type: GPUSharePolicyValid
     - lastHeartbeatTime: "2025-01-07T04:13:04Z"
       lastTransitionTime: "2025-01-07T04:13:04Z"
       message: gpu share policy is none.
       reason: none
       status: "False"
       type: GPUSharePolicy

   Confirme os seguintes itens na saída:

Rótulo de ativação

Defina o rótulo alibabacloud.com/gpu-share-policy em um nó para ativar ou desativar o compartilhamento de GPU.

apiVersion: v1
kind: Node
metadata:
  labels:
    alibabacloud.com/gpu-share-policy: share-pool  # or: static, none

Configuração de QoS

Configure os parâmetros de Qualidade de Serviço (QoS) para compartilhamento de GPU usando a anotação de nó alibabacloud.com/gpu-share-qos-config. Esses parâmetros aplicam-se apenas ao modelo share-pool.

apiVersion: v1
kind: Node
metadata:
  annotations:
    alibabacloud.com/gpu-share-qos-config: '{"preemptEnabled": true, "podMaxDurationMinutes": 120, "reservedEphemeralStorage": "1.5Ti"}'

Campos de recursos compartilhados

Quando o compartilhamento de GPU está ativado, os seguintes campos são adicionados a allocatable e capacity do nó. Eles são removidos quando o recurso é desativado.

Condições do nó

O campo conditions do nó relata dois tipos de condição de compartilhamento de GPU.

GPUSharePolicyValid — se a configuração de compartilhamento de GPU é válida:

GPUSharePolicy — a política de compartilhamento de GPU atualmente ativa:

apiVersion: v1
kind: Pod
metadata:
  labels:
    alibabacloud.com/compute-class: "gpu-hpn"         # Only gpu-hpn is supported
    alibabacloud.com/gpu-share-policy: "share-pool"   # Must match the node's sharing model
  name: gpu-share-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: registry-cn-wulanchabu-vpc.ack.aliyuncs.com/acs/stress:v1.0.4
    args:
      - '1000h'
    command:
      - sleep
    resources:
      limits:
        cpu: '5'
        memory: 50Gi
        alibabacloud.com/gpu-core.percentage: 100
        alibabacloud.com/gpu-memory.percentage: 100
      requests:
        cpu: '5'
        memory: 50Gi
        alibabacloud.com/gpu-core.percentage: 10
        alibabacloud.com/gpu-memory.percentage: 10

Classe de computação

Política de compartilhamento de GPU

Solicitações de recursos

Especifique recursos compartilhados de GPU no campo resources do container usando porcentagens do poder de computação e da memória de uma única GPU.

Tanto alibabacloud.com/gpu-core.percentage quanto alibabacloud.com/gpu-memory.percentage devem ser especificados em requests e limits.

O número de pods que podem ser agendados em um nó também é limitado pela CPU, memória e contagem máxima de pods do nó.

O que acontece com um pod aguardando na fila de prontos?

O pod registra periodicamente seu status de espera:

You have been waiting for ${1} seconds. Approximate position: ${2}

${1} é o número de segundos que o pod está aguardando. ${2} é sua posição atual na fila de prontos.

Quais métricas de monitoramento estão disponíveis para pods de compartilhamento de GPU?

As seguintes métricas estão disponíveis para pods share-pool:

Como as métricas de utilização de GPU diferem para pods com GPU compartilhada?

As métricas de utilização de GPU funcionam da mesma forma que para pods com GPU exclusiva, com algumas diferenças para pods com GPU compartilhada:

• Monitoramento de pods ACS: A utilização do poder de computação da GPU e o uso de memória da GPU são valores absolutos baseados em toda a placa GPU, assim como em cenários de GPU exclusiva.

• Visualização dentro do container (ex.: nvidia-smi): O uso de memória da GPU é um valor absoluto, mas a utilização do poder de computação é um valor relativo onde o denominador é o limit do pod.

• IDs de dispositivo: O ID do dispositivo nas métricas corresponde ao ID real no nó e nem sempre começa em 0.

• Modelo share-pool: O número do dispositivo nas métricas pode mudar porque o pod pode usar diferentes dispositivos GPU do pool ao longo do tempo.

Como evitar conflitos de agendamento quando o compartilhamento de GPU está ativado apenas em alguns nós?

O agendador padrão do ACS corresponde automaticamente os tipos de pod e nó, evitando conflitos.

Se você usar um agendador personalizado, um pod de GPU exclusiva pode ser agendado em um nó de compartilhamento de GPU porque o nó expõe tanto nvidia.com/gpu quanto recursos compartilhados de GPU em sua capacity. Use uma destas abordagens:

• Plugin de agendador: Escreva um plugin que leia rótulos de nó do ACS e campos Condition para filtrar nós com uma política de compartilhamento de GPU incompatível. Consulte Scheduling Framework.

• Rótulos ou taints: Adicione um rótulo ou taint aos nós de compartilhamento de GPU e configure políticas de afinidade ou tolerância em seus pods.

Quais informações estão disponíveis quando um pod de compartilhamento de GPU é preemptado?

Para pods share-pool, a preempção gera tanto um Event quanto uma Condition no pod.

Eventos:

# This pod's GPU resources were preempted by <new-pod-name>
Warning  GPUSharePreempted  5m15s  gpushare   GPU is preempted by <new-pod-name>.
# This pod preempted GPU resources from <old-pod-name>
Warning  GPUSharePreempt    3m47s  gpushare   GPU is preempted from <old-pod-name>.

Condition:

- type: Interruption.GPUShareReclaim   # Condition type for GPU sharing preemption events
  status: "True"                        # True: a preemption or preemption-by action occurred
  reason: GPUSharePreempt               # GPUSharePreempt: this pod preempted another pod; GPUSharePreempted: this pod was preempted
  message: GPU is preempted from <old-pod-name>.
  lastTransitionTime: "2025-04-22T08:12:09Z"
  lastProbeTime: "2025-04-22T08:12:09Z"

Como maximizar a densidade de pods em um cenário de Notebook?

Para pods de compartilhamento de GPU, você também pode definir requests de CPU e memória menores que limits para aumentar a densidade de pods em um nó. Quando o total de limits entre os pods em um nó excede os recursos allocatable do nó, os pods competem por CPU e memória.

• CPU: A competição aparece como CPU Steal Time nas métricas do pod.

• Memória: A competição pode desencadear um erro de falta de memória (OOM) no nível do nó, causando a eliminação de alguns pods.

Planeje as prioridades dos pods e as especificações de recursos com base nas características de cada aplicação. Para dados de utilização de recursos no nível do nó, consulte Métricas de monitoramento no nível de nó ACS GPU-HPN.