A equipe da comunidade de código aberto da China fez sua primeira transmissão ao vivo, contando a história por trás da comunidade de código aberto da China em nome do compartilhamento."

Este artigo foi compartilhado pela comunidade Huawei Cloud " Teste sobre o efeito da antecipação de tarefas on-line, supressão de recursos de CPU para tarefas off-line e garantia de qualidade de serviço para tarefas on-line no cenário de implantação mista nativa da nuvem CCE ". .

fundo

Os ambientes de TI corporativos geralmente executam dois tipos principais de processos: um são serviços online e o outro são operações offline.

Tarefas on-line : longo tempo de execução, tráfego de serviço e utilização de recursos têm características de maré, são sensíveis a atrasos e têm altos requisitos de SLA de serviço, como serviços de transação de comércio eletrônico, etc.

Tarefas offline : O tempo de execução é dividido em intervalos, a taxa de utilização de recursos é alta durante a operação, o atraso não é sensível, a taxa de tolerância a falhas é alta e as interrupções geralmente permitem a repetição da execução, como processamento de big data, etc.

A principal forma de colocalização é melhorar a utilização de recursos implantando tarefas online e offline no mesmo nó. Por exemplo, um nó implantou anteriormente 3 tarefas online com SLA de serviço alto e agora implanta 3 tarefas online e 3 tarefas offline em. de maneira mista, os serviços off-line utilizam os recursos ociosos dos serviços on-line em vários períodos sem afetar a qualidade do serviço dos serviços on-line.

No nível de co-localização do contêiner, envolve principalmente: 1) No nível de agendamento, os recursos de agendamento do nó são sobreprogramados e as tarefas online e offline são misturadas e agendadas para o mesmo nó; 2) No nível da CPU, as tarefas online; são interrompidas e as tarefas offline são suprimidas 3) O nível de memória não é apresentado neste artigo; Através do poder da CPU da tecnologia co-localizada, pode-se perceber que durante o processo de operação, o sistema completará automaticamente a "preempção" e "supressão" online de recursos de tarefas offline de acordo com o uso de recursos de tarefas online e offline para garantir as demandas de recursos dos recursos online. Tomemos como exemplo uma máquina de 4 núcleos:

Quando uma tarefa online requer recursos de CPU de 3 núcleos, o sistema precisa "suprimir" a tarefa offline para usar recursos de CPU de até 1 núcleo;
A tarefa online estava no pico baixo do negócio naquele momento e usava apenas 1 recurso principal da CPU. A tarefa offline poderia usar os recursos restantes da CPU no curto prazo, quando o negócio da tarefa online aumentasse, o sistema garantia que o negócio online; poderia "prevenir" os recursos da CPU comercial off-line;

Preparação ambiental

Requerimentos ambientais

Versão do cluster :

Cluster v1.19: v1.19.16-r4 e superior
Cluster v1.21: v1.21.7-r0 e superior
Cluster v1.23: v1.23.5-r0 e superior
v1.25 e superior

Tipo de cluster : cluster CCE Standard ou cluster CCE Turbo.

SO do nó : EulerOS 2.9 (kernel-4.18.0-147.5.1.6.h729.6.eulerosv2r9.x86_64) ou Huawei Cloud EulerOS 2.0

Tipo de nó : máquina virtual elástica.

Versão do plug-in Volcano : 1.7.0 e superior.

informação ambiental

Cluster CCE implanta plug-ins kube-prometheus-stack, grafana e vulcão

Supressão de CPU e demonstração de preempção

Linha de base do teste de estresse

Crie a carga de trabalho necessária para a demonstração e garanta que as duas cargas de trabalho estejam agendadas para o mesmo nó (como a expressão geral no painel está associada ao nome do pod, é recomendável não usar o nome da carga de trabalho, caso contrário, afetará o exibição normal do painel)

tipo: implantação
apiVersão: apps/v1
metadados:
  nome: redis        
especificação:
  réplicas: 1
  seletor:
    rótulos de correspondência:
      aplicativo: redis
  modelo:
    metadados:
      criaçãoTimestamp: null
      rótulos:
        aplicativo: redis
      anotações:
        prometheus.io/path: /metrics
        prometheus.io/port: '9121'
        prometheus.io/scrape: 'verdadeiro'
    especificação:
      containers:
        - nome: contêiner-1
          imagem: swr.cn-north-4.myhuaweicloud.com/testapp/redis:v6
          recursos:
            limites:
              CPU: '1'
            solicitações de:
              CPU: 250m
        - nome: contêiner-2
          imagem: bitnami/redis-exportador:mais recente
          recursos:
            limites:
              CPU: 250m
              memória: 512Mi
            solicitações de:
              CPU: 250m
              memória: 512Mi
      imagePullSecrets:
        - nome: segredo padrão
      agendadorNome: vulcão
---
tipo: implantação
apiVersão: apps/v1
metadados:
  nome: estresse
especificação:
  réplicas: 1
  seletor:
    rótulos de correspondência:
      aplicativo: estresse
  modelo:
    metadados:
      rótulos:
        aplicativo: estresse
    especificação:
      containers:
        - nome: contêiner-1
          imagem: swr.cn-north-4.myhuaweicloud.com/testapp/centos-stress:v1
          comando:
            - /bin/bash
          argumentos:
            - '-c'
            - enquanto verdadeiro; faça eco olá; dormir 10; feito
          recursos:
            limites:
              CPU: '4'
              memória: 4Gi
            solicitações de:
              CPU: 2500m
              memória: 1Gi
      imagePullSecrets:
        - nome: segredo padrão
      nome do agendador: vulcão
      afinidade:
        podAfinidade:
          necessárioDuringSchedulingIgnoredDuringExecution:
            - rótuloSeletor:
                corresponderExpressões:
                  - chave: aplicativo
                    operador: Em
                    valores:
                      - redis
              espaços para nome:
                - padrão
              chave de topologia: kubernetes.io/hostname

Use o comando redis-benchmark para testar a resistência do redis 192.168.1.159para o Pod ip do redis ;

./redis-benchmark -h 192.168.1.159 -p 6379 -n 3000000 -c 100 –q -t SET,INCR,LPUSH,LPOP,RPOP,SADD,HSET,SPOP,ZADD,ZPOPMIN

Observe os indicadores redis e o uso da CPU na página grafana, que pode ser usada como dados de referência de linha de base sem interferência.

Cena não mista

Crie um pool de nós para implantação híbrida e reimplante as cargas de trabalho acima em novos nós

Use o comando redis-benchmark novamente para testar a resistência do redis 192.168.1.172para o Pod ip do redis ;

./redis-benchmark -h 192.168.1.172 -p 6379 -n 3000000 -c 100 –q -t SET,INCR,LPUSH,LPOP,RPOP,SADD,HSET,SPOP,ZADD,ZPOPMIN

Entre no contêiner de estresse Depois que o indicador redis atingir a linha de base e ficar estável, execute o comando para aumentar o uso da CPU.

estresse de -c 4 -t 3600

Observe os indicadores do redis e o uso da CPU na página do grafana e descubra que os dados de desempenho do redis degradaram rapidamente durante o teste de estresse do contêiner de estresse.

Cena mista

Atualize o pool de nós e configure o rótulo híbrido do nó na configuração avançada:volcano.sh/colocation="true"

Clique no gerenciamento de configuração do componente pool de nós-kubelet para ativar o recurso de colocalização de nós

Modifique o limite de remoção do nó para 100 para evitar a remoção direta quando o uso da CPU exceder o limite durante o teste de estresse.

nó de anotação kubectl 192.168.0.209 vulcão.sh/evicting-cpu-high-watermark=100

Modifique a anotação da carga de trabalho de estresse e marque o estresse como negócio offline. A carga de trabalho do Redis não precisa ser modificada.

tipo: implantação
apiVersão: apps/v1
metadados:
  nome: estresse
especificação:
  réplicas: 1
  seletor:
    rótulos de correspondência:
      aplicativo: estresse
  modelo:
    metadados:
      rótulos:
        aplicativo: estresse
      anotações:          
        vulcão.sh/qos-level: "-1" # Anotações de trabalho off-line
    especificação:
      containers:
        - nome: contêiner-1
          imagem: swr.cn-north-4.myhuaweicloud.com/testapp/centos-stress:v1
          comando:
            - /bin/bash
          argumentos:
            - '-c'
            - enquanto verdadeiro; faça eco olá; dormir 10; feito
          recursos:
            limites:
              CPU: '4'
              memória: 4Gi
            solicitações de:
              CPU: 2500m
              memória: 1Gi
      imagePullSecrets:
        - nome: segredo padrão
      nome do agendador: vulcão
      afinidade:
        podAfinidade:
          necessárioDuringSchedulingIgnoredDuringExecution:
            - rótuloSeletor:
                corresponderExpressões:
                  - chave: aplicativo
                    operador: Em
                    valores:
                      - redis
              espaços para nome:
                - padrão
              chave de topologia: kubernetes.io/hostname

Use o comando redis-benchmark para testar a resistência do redis 192.168.1.172 para o Pod ip do redis ;

./redis-benchmark -h 192.168.1.172 -p 6379 -n 3000000 -c 100 –q -t SET,INCR,LPUSH,LPOP,RPOP,SADD,HSET,SPOP,ZADD,ZPOPMIN

Entre no contêiner de estresse Depois que o indicador redis atingir a linha de base e ficar estável, execute o comando para aumentar o uso da CPU.

estresse de -c 4 -t 3600

Observe os indicadores redis e o uso da CPU na página do grafana. No cenário misto, mesmo que as tarefas offline tentem esgotar a CPU do nó, o sistema operacional ainda mantém as demandas de CPU das tarefas online, garantindo a qualidade do serviço das tarefas online. .

Clique para seguir e conhecer as novas tecnologias da Huawei Cloud o mais rápido possível~

Casos de teste no cenário de colocalização nativa da nuvem CCE