Colocar um serviço online e um aplicativo de transcodificação de vídeo em colocation - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Contexto

A colocation de cargas de trabalho online e offline no mesmo nó é vantajosa porque suas demandas de recursos são complementares: serviços online têm carga variável e consomem recursos em picos, enquanto jobs em lote offline rodam continuamente e toleram prioridade de recursos mais baixa.

	Carga de trabalho online	Carga de trabalho offline
Aplicações típicas	Serviços web, APIs, microsserviços	Transcodificação de vídeo, processamento de big data, treinamento de IA
Latência	Sensível	Insensível
SLO	Alto	Baixo
Padrão de uso de recursos	Em picos, baseado em tempo	Contínuo
Tolerância a falhas	Baixa — exige alta disponibilidade	Alta — permite falha e nova tentativa

O ack-koordinator utiliza classes de Qualidade de Serviço (QoS) para gerenciar a prioridade de recursos entre cargas de trabalho em colocation. As duas classes usadas neste tópico são:

Classe de QoS	Valor do rótulo	Uso típico	Prioridade de CPU	Prioridade de memória
Sensível à latência (LS)	`koordinator.sh/qosClass: LS`	Serviços online (ex.: NGINX)	Alta	Alta
Melhor esforço (BE)	`koordinator.sh/qosClass: BE`	Jobs em lote offline (ex.: FFmpeg)	Baixa	Baixa

Como funciona

Neste tópico, um serviço NGINX (classe de QoS LS) e um aplicativo de transcodificação de vídeo FFmpeg (classe de QoS BE) rodam no mesmo nó. Dois recursos de colocation atuam juntos para proteger o desempenho do NGINX:

Reutilização de recursos: Cargas de trabalho BE podem usar recursos alocados para cargas LS que estão ociosos no momento, melhorando a utilização dos recursos do cluster. Para mais informações, consulte Sobrecarga dinâmica de recursos.
Isolamento de recursos: Vários mecanismos limitam o uso de recursos pelas cargas BE e priorizam a demanda das cargas LS. Para mais informações, consulte CPU QoS, CPU Suppress e Isolamento de recursos baseado em cache L3 e MBA.

Este tópico implanta os aplicativos em três modos e compara os resultados:

Modo	Descrição
Implantação exclusiva (linha de base)	Apenas o NGINX roda no nó.
Colocation padrão do Kubernetes (controle)	NGINX e FFmpeg rodam no mesmo nó com classes de QoS padrão do Kubernetes — sem recursos estendidos ou recursos de isolamento do ack-koordinator.
Colocation com reconhecimento de SLO (experimental)	NGINX e FFmpeg rodam no mesmo nó com os recursos de isolamento do ack-koordinator ativados.

Pré-requisitos

Antes de começar, certifique-se de ter:

Um cluster ACK Pro com dois nós:
- Nó 1 (máquina de teste): roda o serviço NGINX e o aplicativo FFmpeg. Para obter o melhor desempenho de colocation, use uma instância Bare Metal do Elastic Compute Service (ECS) com Alibaba Cloud Linux como sistema operacional.
- Nó 2 (máquina de teste de estresse): roda a ferramenta de teste de carga wrk e envia solicitações ao serviço NGINX.
- Para etapas de criação do cluster, consulte Criar um cluster ACK Pro.
ack-koordinator (anteriormente ack-slo-manager) instalado com políticas de colocation ativadas. Consulte Guia de introdução. Este tópico usa o ack-koordinator 0.8.0.

O CPU QoS requer Alibaba Cloud Linux como SO do nó. O isolamento de recursos baseado em cache L3 e MBA exige uma instância ECS Bare Metal.

Implantar o serviço NGINX e o wrk

Implante o serviço NGINX na máquina de teste e a ferramenta de teste de carga wrk na máquina de teste de estresse.

Implantar o NGINX

Crie um arquivo chamado ls-nginx.yaml com o seguinte conteúdo:

Mostrar conteúdo do arquivo YAML

---
# NGINX configuration
apiVersion: v1
data:
  config: |-
    user  nginx;
    worker_processes  80; # Number of worker processes — controls concurrent request capacity.

    events {
        worker_connections  1024;  # Maximum connections per worker. Default: 1024.
    }

    http {
        server {
            listen  8000;

            gzip off;
            gzip_min_length 32;
            gzip_http_version 1.0;
            gzip_comp_level 3;
            gzip_types *;
        }
    }

    #daemon off;
kind: ConfigMap
metadata:
  name: nginx-conf

---
# Pod for the online NGINX service (LS QoS class)
apiVersion: v1
kind: Pod
metadata:
  labels:
    koordinator.sh/qosClass: LS
    app: nginx
  name: nginx
spec:
  containers:
    - image: 'koordinatorsh/nginx:v1.18-koord-exmaple'
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 8000
          hostPort: 8000 # Port exposed for load testing.
          protocol: TCP
      resources:
        limits:
          cpu: '80'
          memory: 10Gi
        requests:
          cpu: '80'
          memory: 10Gi
      volumeMounts:
        - mountPath: /apps/nginx/conf
          name: config
  hostNetwork: true
  restartPolicy: Never
  volumes:
    - configMap:
        items:
          - key: config
            path: nginx.conf
        name: nginx-conf
      name: config
  nodeName: cn-beijing.192.168.2.93  # Replace with the node name of your tested machine.

Implante o serviço NGINX:
```
kubectl apply -f ls-nginx.yaml
```

Verifique se o pod está em execução:

kubectl get pod -l app=nginx -o wide

Saída esperada:

NAME    READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          43s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

O status Running confirma que o serviço NGINX está ativo na máquina de teste.

Instalar o wrk na máquina de teste de estresse

Execute os seguintes comandos no Nó 2 (a máquina de teste de estresse) para instalar o wrk 4.2.0:

wget -O wrk-4.2.0.tar.gz https://github.com/wg/wrk/archive/refs/tags/4.2.0.tar.gz && tar -xvf wrk-4.2.0.tar.gz
cd wrk-4.2.0 && make && chmod +x ./wrk

Implantar o aplicativo FFmpeg

Implante o aplicativo offline de transcodificação de vídeo FFmpeg na máquina de teste. A configuração YAML difere ligeiramente entre o modo de colocation padrão do Kubernetes e o modo de colocation com reconhecimento de SLO — os comentários relevantes no arquivo explicam cada diferença.

Crie um arquivo chamado be-ffmpeg.yaml com o seguinte conteúdo:

Mostrar conteúdo do arquivo YAML

# Pod for the offline FFmpeg video transcoding application (BE QoS class)
apiVersion: v1
kind: Pod
metadata:
  name: be-ffmpeg
  labels:
    app: ffmpeg
  # Default Kubernetes colocation mode: remove the koordinator.sh/qosClass: BE label.
  # SLO-aware colocation mode: keep the koordinator.sh/qosClass: BE label.
    koordinator.sh/qosClass: BE
spec:
  containers:
    # Increase the process count to control CPU utilization of the transcoding application.
    # Default: 25 processes, each with 2 parallel threads.
    - command:
        - start-ffmpeg.sh
        - '25'
        - '2'
        - /apps/ffmpeg/input/HD2-h264.ts
        - /apps/ffmpeg/
      image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1'
      imagePullPolicy: Always
      name: ffmpeg
      resources:
      # Default Kubernetes colocation mode: remove the kubernetes.io/batch-cpu and
      # kubernetes.io/batch-memory extended resources.
      # SLO-aware colocation mode: keep them, sized to your node's resource spec.
        limits:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
        requests:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
  hostNetwork: true
  restartPolicy: Never
  nodeName: cn-beijing.192.168.2.93  # Replace with the node name of your tested machine.

Implante o aplicativo FFmpeg:
```
kubectl apply -f be-ffmpeg.yaml
```

Verifique se o pod está em execução:

kubectl get pod -l app=ffmpeg -o wide

Saída esperada:

NAME        READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
be-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

Executar os testes de estresse

Execute testes em cada modo de colocation e compare os resultados. As principais métricas são:

Percentis de tempo de resposta (RT): RT-P90 é o tempo máximo para processar 90% das solicitações; RT-P99 cobre 99% das solicitações. Valores menores indicam melhor desempenho do NGINX.
Utilização média de CPU: medida com kubectl top node.

Modo 1: Implantação exclusiva (linha de base)

Apenas o serviço NGINX roda na máquina de teste.

Implante o NGINX conforme descrito em Implantar o serviço NGINX e o wrk.

Envie carga da máquina de teste de estresse:

# Replace node_ip with the IP address of the tested machine.
./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

Verifique a utilização da CPU:

kubectl top node

Saída esperada:

NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
cn-beijing.192.168.2.93   29593m       29%    xxxx            xxxx
cn-beijing.192.168.2.94   6874m        7%     xxxx            xxxx

A utilização da CPU na máquina de teste é de aproximadamente 29%.

Após a conclusão do teste, revise a saída do wrk. Para resultados precisos, execute vários testes. Saída esperada:

Running 1m test @ http://192.168.2.94:8000/
  6 threads and 54 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   402.18us    1.07ms  59.56ms   99.83%
    Req/Sec    24.22k     1.12k   30.58k    74.15%
  Latency Distribution
     50%  343.00us
     75%  402.00us
     90%  523.00us
     99%  786.00us
  8686569 requests in 1.00m, 6.88GB read
Requests/sec: 144537.08
Transfer/sec:    117.16MB

A seção Latency Distribution mostra os valores percentis de RT. No modo exclusivo: RT-P50 é 343 microssegundos, RT-P90 é 523 microssegundos e RT-P99 é 786 microssegundos.

Modo 2: Colocation padrão do Kubernetes (controle)

Tanto o NGINX quanto o FFmpeg rodam na máquina de teste sem os recursos de isolamento do ack-koordinator.

Implante o NGINX conforme descrito em Implantar o serviço NGINX e o wrk e, em seguida, implante o aplicativo FFmpeg usando be-ffmpeg.yaml com as seguintes modificações:

Remova o rótulo koordinator.sh/qosClass: BE.
Remova os recursos estendidos kubernetes.io/batch-cpu e kubernetes.io/batch-memory.

Execute o teste de carga com wrk e colete a utilização da CPU como no Modo 1. Nesta configuração de controle, a utilização da CPU do nó atinge aproximadamente 65%.

Modo 3: Colocation com reconhecimento de SLO (experimental)

Tanto o NGINX quanto o FFmpeg rodam na máquina de teste com os recursos de isolamento do ack-koordinator ativados.

Siga o guia Guia de introdução para ativar a colocation com reconhecimento de SLO e configure cada recurso:
- Sobrecarga dinâmica de recursos: Use a configuração padrão. Isso permite que o sistema aloque recursos ociosos de pods LS para pods BE como recursos em lote sobrecarregados (kubernetes.io/batch-cpu e kubernetes.io/batch-memory).
- CPU Suppress: Defina cpuSuppressThresholdPercent como 65. Use os padrões para outras configurações. Quando a utilização da CPU do nó excede 65%, este recurso limita o uso de CPU dos pods BE para proteger o desempenho dos pods LS.
- CPU QoS: Use a configuração padrão. Isso ativa a capacidade CPU Identity no Alibaba Cloud Linux, dando aos pods LS prioridade de agendamento sobre os pods BE — inclusive quando o multithreading simultâneo (SMT) executa threads de ambos os pods no mesmo núcleo físico.
- Isolamento de recursos baseado em cache L3 e MBA: Use a configuração padrão. Em instâncias ECS Bare Metal, isso isola o cache L3 (cache de último nível) e a alocação de largura de banda de memória (MBA) para que os pods LS tenham acesso prioritário.
Importante
O CPU QoS requer Alibaba Cloud Linux como SO do nó. O isolamento de cache L3 e MBA exige uma instância ECS Bare Metal.
Implante o NGINX conforme descrito em Implantar o serviço NGINX e o wrk.

Crie um arquivo chamado besteffort-ffmpeg.yaml com o seguinte conteúdo: Mostrar conteúdo do arquivo YAML

# Pod for the offline FFmpeg video transcoding application (BE QoS class, SLO-aware mode)
apiVersion: v1
kind: Pod
metadata:
  name: besteffort-ffmpeg
  labels:
    app: ffmpeg
    # Set the QoS class to BE for SLO-aware scheduling.
    koordinator.sh/qosClass: BE
spec:
  containers:
    - command:
        - start-ffmpeg.sh
        - '30'
        - '2'
        - /apps/ffmpeg/input/HD2-h264.ts
        - /apps/ffmpeg/
      image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1'
      imagePullPolicy: Always
      name: ffmpeg
      resources:
        # Request dynamically overcommitted resources.
        limits:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
        requests:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
  hostNetwork: true
  restartPolicy: Never
  nodeName: cn-beijing.192.168.2.93  # Replace with the node name of your tested machine.

Implante o aplicativo FFmpeg:
```
kubectl apply -f besteffort-ffmpeg.yaml
```

Verifique se o pod do FFmpeg está em execução:

kubectl get pod -l app=ffmpeg -o wide

Saída esperada:

NAME                READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
besteffort-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

Envie carga da máquina de teste de estresse:

# Replace node_ip with the IP address of the tested machine.
./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

Verifique a utilização da CPU:

kubectl top node

Saída esperada:

NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
cn-beijing.192.168.2.93   65424m       63%    xxxx            xxxx
cn-beijing.192.168.2.94   7040m        7%     xxxx            xxxx

A utilização da CPU na máquina de teste é de aproximadamente 63%.

Após a conclusão do teste, revise a saída do wrk e compare com os resultados dos outros modos.

Resultados dos testes

A tabela a seguir compara o tempo de resposta do NGINX e a utilização da CPU do nó nos três modos.

Métrica	Linha de base (exclusivo)	Controle (Kubernetes padrão)	Experimental (reconhecimento de SLO)
NGINX RT-P90 (ms)	0,533	0,574 (+7,7%)	0,548 (2,8%)
NGINX RT-P99 (ms)	0,93	1,07 (+16%)	0,96 (+3,2%)
Utilização média de CPU	29,6%	65,1%	64,8%

Principais observações:

Colocation padrão do Kubernetes vs. linha de base: A utilização da CPU aumenta de 29,6% para 65,1%, mas o RT-P90 do NGINX sobe 7,7% e o RT-P99 sobe 16%. A distribuição de latência apresenta uma cauda longa.
Colocation com reconhecimento de SLO vs. linha de base: A utilização da CPU aumenta de 29,6% para 64,8%, enquanto o RT-P90 sobe apenas 2,8% e o RT-P99 sobe apenas 3,2%.
Colocation com reconhecimento de SLO vs. colocation padrão do Kubernetes: A utilização da CPU é semelhante (~65%), mas os tempos de resposta do NGINX são significativamente menores e próximos à linha de base de implantação exclusiva.

A colocation com reconhecimento de SLO atinge praticamente a mesma melhoria na utilização da CPU que a colocation padrão, mantendo a latência do NGINX muito mais próxima da linha de base sem colocation.

Perguntas frequentes

Por que o wrk relata "Socket errors: connect 54,"?

Esse erro significa que o cliente wrk não consegue estabelecer conexões com o servidor NGINX porque o número de conexões excede o limite do SO. Corrija isso ativando a reutilização de conexões TCP na máquina de teste de estresse (não na máquina de teste).

Verifique se a reutilização de conexões TCP está ativada:
```
sudo sysctl -n net.ipv4.tcp_tw_reuse
```
Um valor de retorno de 0 ou 2 significa que o recurso está desativado.
Ative a reutilização de conexões TCP:
```
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
```
Execute novamente o teste de estresse com wrk. Se Socket errors: connect 54 não aparecer mais, a correção funcionou.

Após a conclusão dos testes, desative a reutilização de conexões TCP para evitar efeitos indesejados em outros serviços: sysctl -w net.ipv4.tcp_tw_reuse=0 .

Container Service for Kubernetes:Colocar um serviço online e um aplicativo de transcodificação de vídeo em colocation

Contexto

Como funciona

Pré-requisitos

Implantar o serviço NGINX e o wrk

Instalar o wrk na máquina de teste de estresse

Implantar o aplicativo FFmpeg

Executar os testes de estresse

Modo 1: Implantação exclusiva (linha de base)

Modo 2: Colocation padrão do Kubernetes (controle)

Modo 3: Colocation com reconhecimento de SLO (experimental)

Resultados dos testes

Perguntas frequentes

Por que o wrk relata "Socket errors: connect 54,"?

Próximos passos