A ConcurrencySchedulingPolicy, fornecida pelo conjunto de agendamento de tráfego, permite agendar requisições por prioridade sob concorrência controlada.
Informações de fundo
A ConcurrencySchedulingPolicy determina se há sobrecarga de tráfego com base nos limites de requisições simultâneas. Quando o número de requisições simultâneas excede o limite superior especificado, as requisições subsequentes entram em fila e são agendadas conforme suas prioridades. O fluxo geral é o seguinte:
Um limitador de concorrência registra o número de requisições em andamento e verifica se o limite superior de concorrência foi atingido.
Ao atingir o limite superior de concorrência, as requisições seguintes são enfileiradas e encaminhadas ao serviço de destino à medida que as anteriores são concluídas. Requisições de alta prioridade saem da fila primeiro, garantindo atendimento antes das de menor prioridade.
Diferentemente da ConcurrencyLimitingPolicy, que rejeita requisições ao alcançar o limiar, a ConcurrencySchedulingPolicy coloca o excesso de requisições em uma fila de prioridades em vez de descartá-las. Em seguida, o sistema agenda essas requisições por prioridade, mantendo o volume de requisições simultâneas dentro do limite superior estabelecido.
Pré-requisitos
Um cluster gerenciado do Container Service for Kubernetes (ACK) está adicionado à sua instância do Service Mesh (ASM), e a versão da instância ASM é V1.21.6.97 ou posterior. Para mais informações, consulte Adicionar um cluster a uma instância ASM.
A injeção automática de proxy sidecar está ativada para o namespace padrão no cluster ACK. Para mais informações, consulte Gerencie namespaces globais.
Conexão estabelecida com o cluster ACK usando kubectl. Para mais informações, consulte Conectar-se a um cluster ACK usando kubectl.
O conjunto de agendamento de tráfego ASM está ativado. Para mais informações, consulte Ative o conjunto de agendamento de tráfego ASM.
A aplicação HTTPBin está implantada e acessível por meio de um gateway de entrada ASM. Para mais informações, consulte Implantar a aplicação HTTPBin.
Etapa 1: Crie ConcurrencySchedulingPolicy
Use kubectl para conectar-se à sua instância ASM. Para mais informações, consulte Acessar recursos Istio com kubectl.
-
Crie um arquivo concurrencyschedulingpoilcy.yaml com o seguinte conteúdo:
apiVersion: istio.alibabacloud.com/v1 kind: ConcurrencySchedulingPolicy metadata: name: concurrencyscheduling namespace: istio-system spec: concurrency_scheduler: max_concurrency: 10 concurrency_limiter: max_inflight_duration: 60s scheduler: workloads: - label_matcher: match_labels: http.request.header.user_type: guest parameters: priority: 50.0 name: guest - label_matcher: match_labels: http.request.header.user_type: subscriber parameters: priority: 200.0 name: subscriber selectors: - service: httpbin.default.svc.cluster.localA tabela a seguir descreve alguns parâmetros. Para obter mais detalhes sobre os itens de configuração, consulte Campos da ConcurrencySchedulingPolicy.
Campo
Descrição
max_concurrency
Número máximo de requisições simultâneas. Neste exemplo, o campo está definido como 10, indicando que o serviço pode processar 10 requisições por vez.
max_inflight_duration
Tempo limite para processamento de requisições. Devido a eventos inesperados, como reinicialização de pods no cluster, o conjunto de agendamento de tráfego ASM pode falhar ao registrar eventos de término de requisição. Para evitar que tais requisições afetem o julgamento do algoritmo de limitação de concorrência, especifique o tempo limite de processamento. Caso as requisições não recebam resposta antes desse período, o sistema considera que foram processadas. Defina este campo avaliando o tempo máximo esperado de resposta de uma requisição. Neste exemplo, o valor é 60s.
workloads
Dois tipos de requisição são definidos com base no user_type nos cabeçalhos: guest e subscriber. A prioridade de uma requisição do tipo guest é 50, enquanto a do tipo subscriber é 200.
selectors
Serviços aos quais a política de limitação se aplica. Neste exemplo, usa-se service: httpbin.default.svc.cluster.local, indicando que a política de limitação de concorrência afeta o serviço httpbin.default.svc.cluster.local.
-
Execute o comando abaixo para criar a ConcurrencySchedulingPolicy:
kubectl apply -f concurrencyschedulingpoilcy.yaml
Etapa 2: Verifique o resultado do agendamento de requisições baseado em prioridade em cenários de concorrência controlada
Este exemplo utiliza a ferramenta de teste de estresse Fortio. Para mais informações, veja a seção Installation do Fortio no GitHub.
-
Abra dois terminais e execute simultaneamente os comandos de teste de estresse a seguir. Durante todo o processo, garanta que ambos os terminais funcionem corretamente. Nos testes dos dois terminais, 10 requisições simultâneas são enviadas ao serviço com um QPS (consultas por segundo) de 10.000, valor que supera significativamente a capacidade de requisições simultâneas suportada pelo serviço.
fortio load -c 10 -qps 10000 -H "user_type:guest" -t 30s -timeout 60s -a http://${IP address of the ASM ingress gateway}/status/201fortio load -c 10 -qps 10000 -H "user_type:subscriber" -t 30s -timeout 60s -a http://${IP address of the ASM ingress gateway}/status/202NotaSubstitua
${IP address of the ASM gateway}nos comandos acima pelo endereço IP do seu gateway de entrada ASM. Para saber como obter esse endereço, consulte a subetapa 1 da Etapa 3 no tópico Roteamento de tráfego baseado em versão com Istio.Saída esperada do teste 1:
... # target 50% 4.35294 # target 75% 5.39689 # target 90% 5.89697 # target 99% 6.19701 # target 99.9% 6.22702 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 201 : 84 (100.0 %) Response Header Sizes : count 84 avg 249.88095 +/- 0.3587 min 248 max 250 sum 20990 Response Body/Total Sizes : count 84 avg 249.88095 +/- 0.3587 min 248 max 250 sum 20990 All done 84 calls (plus 10 warmup) 3802.559 ms avg, 2.6 qps Successfully wrote 5186 bytes of Json data to xxxxxx.jsonAnote o nome do arquivo JSON gerado pelo teste 1, por exemplo, xxxxxx.json.
Saída esperada do teste 2:
... # target 50% 1.18121 # target 75% 1.63423 # target 90% 1.90604 # target 99% 2.22941 # target 99.9% 2.28353 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 202 : 270 (100.0 %) Response Header Sizes : count 270 avg 250.52963 +/- 0.5418 min 249 max 251 sum 67643 Response Body/Total Sizes : count 270 avg 250.52963 +/- 0.5418 min 249 max 251 sum 67643 All done 270 calls (plus 10 warmup) 1117.614 ms avg, 8.8 qps Successfully wrote 5305 bytes of Json data to yyyyyy.jsonAnote o nome do arquivo JSON gerado pelo teste 2, por exemplo, yyyyyy.json.
As saídas acima mostram que a latência média das requisições do teste 2 corresponde a aproximadamente 1/4 da latência do teste 1, enquanto o QPS é cerca de quatro vezes maior. Isso ocorre porque, na política definida anteriormente, a prioridade das requisições do tipo subscriber é quatro vezes superior à das requisições do tipo guest.
-
(Opcional) Visualize os resultados graficamente.
-
No diretório local onde você executou os dois comandos na etapa anterior, execute o comando a seguir para iniciar o servidor Fortio local:
fortio server -
Acesse
http://localhost:8080/fortio/browseem um navegador e clique em no nome do arquivo JSON correspondente anotado na subetapa 1 para visualizar os resultados do teste.Exemplo de resultados visuais do teste 1:
Exemplo de resultados visuais do teste 2:
Os resultados visuais indicam que, exceto por algumas requisições sem restrição, a maioria das requisições do tipo guest apresenta latência entre 4.000 e 6.000 ms. Por outro lado, grande parte das requisições do tipo subscriber tem latência entre 1.000 e 2.000 ms. Quando as requisições ao serviço ultrapassam o limite superior, as do tipo subscriber recebem resposta prioritariamente. Além disso, as requisições simultâneas enviadas ao serviço permanecem limitadas a um valor específico.
-
Referências
Para verificar se a ConcurrencySchedulingPolicy entrou em vigor, utilize o Grafana. Certifique-se de que a instância Prometheus do Grafana esteja configurada com o conjunto de agendamento de tráfego ASM.
Importe o conteúdo abaixo no Grafana para criar um painel para a ConcurrencySchedulingPolicy.
A figura a seguir mostra um exemplo de painel.
