O conjunto de agendamento de tráfego do Service Mesh (ASM) oferece suporte a políticas de agendamento de requisições baseadas em prioridade. Quando o sistema está sobrecarregado, as requisições de alta prioridade são processadas primeiro. Utilize a AverageLatencySchedulingPolicy para priorizar requisições com base em níveis de prioridade configuráveis.
Informações básicas
Uma política de agendamento de requisições baseada em prioridade compara a latência em tempo real com a média histórica para detectar sobrecarga de tráfego e utiliza mecanismos de token bucket e prioridade para agendar as requisições. O fluxo de trabalho é o seguinte:
Detecção de sobrecarga: esta política compara a latência média no período anterior com a latência atual para determinar se o sistema está sobrecarregado.
Ajuste da taxa de emissão de tokens: caso ocorra uma sobrecarga, os dados de monitoramento obtidos na etapa anterior são enviados a um controlador dedicado, que regula a taxa de preenchimento do token bucket.
Agendamento de requisições: diferentes requisições possuem prioridades distintas. Durante uma sobrecarga, requisições com prioridades mais altas têm maior probabilidade de obter tokens.
Esta política coloca as requisições em fila quando os serviços estão congestionados devido à alta concorrência e ao aumento das latências de resposta. Diferentemente das políticas padrão de limitação, que rejeitam requisições diretamente, esta política as insere em uma fila de prioridades. O mecanismo de token bucket limita a taxa de requisições, e a ordem de processamento é ajustada conforme os níveis de prioridade.
Pré-requisitos
Um cluster gerenciado do Container Service for Kubernetes (ACK) foi adicionado à sua instância do ASM, e a versão da instância do ASM é V1.21.6.44 ou posterior. Para mais informações, consulte Adicionar um cluster a uma instância do 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.
Você se conectou ao cluster ACK usando kubectl. Para mais informações, consulte Conectar-se a um cluster ACK usando kubectl.
O conjunto de agendamento de tráfego do ASM está ativado. Para mais informações, consulte Ative o conjunto de agendamento de tráfego do ASM.
A aplicação HTTPBin está implantada e acessível por meio de um gateway do ASM. Para mais informações, consulte Implantar a aplicação HTTPBin.
(Opcional) Os recursos de geração e coleta de logs de acesso do gateway do ASM estão ativados. Para mais informações, consulte Gerar e coletar logs de acesso do gateway do ASM.
Etapa 1: Crie a AverageLatencySchedulingPolicy
Use kubectl para conectar-se à instância do ASM. Para mais informações, consulte Acessar recursos do Istio com kubectl.
-
Crie um arquivo AverageLatencySchedulingPolicy.yaml com o seguinte conteúdo:
apiVersion: istio.alibabacloud.com/v1 kind: AverageLatencySchedulingPolicy metadata: name: workload-prioritization namespace: istio-system spec: load_scheduling_core: aimd_load_scheduler: load_scheduler: workload_latency_based_tokens: true selectors: - service: httpbin.default.svc.cluster.local 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"A tabela a seguir descreve alguns dos campos.
Campo
Descrição
workload_latency_based_tokens
Indica se o número de tokens deve ser ajustado dinamicamente com base na latência média da carga de trabalho. A janela de tempo para estimar a latência média corresponde aos últimos 30 minutos.
service
O serviço no qual a política de agendamento entra em vigor.
workloads
Dois tipos de requisição são definidos com base no user_type nos cabeçalhos da requisição: guest e subscriber. A prioridade de uma requisição do tipo guest é 50, enquanto a do tipo subscriber é 200.
Para mais informações sobre os campos suportados pela AverageLatencySchedulingPolicy, consulte Referência de campos da AverageLatencySchedulingPolicy.
Etapa 2: Execute testes
Neste exemplo, utiliza-se a ferramenta de teste de carga fortio. Para mais informações, consulte Instale o fortio.
Primeiro, simule requisições normais de serviço para estabelecer uma linha de base de latência média:
fortio load -c 20 -qps 100000 -t 60m http://${IP address of the ASM gateway}/status/200Três minutos após executar o comando anterior, abra dois novos terminais e envie requisições de teste. Mantenha o processo do fortio em execução durante todo o teste e não feche seu terminal.
Nos dois terminais, execute os seguintes comandos de teste de carga. Inicie ambos os testes simultaneamente.
fortio load -c 40 -qps 100000 -H "user_type:guest" -t 3m http://${IP address of the ASM gateway}/status/201fortio load -c 40 -qps 100000 -H "user_type:subscriber" -t 3m http://${IP address of the ASM gateway}/status/202Os dois comandos usam caminhos de requisição diferentes para permitir a distinção dos resultados do teste nos logs de acesso.
Etapa 3: Analisar os resultados do teste
Os blocos de código a seguir mostram as últimas linhas da saída do teste no ambiente atual:
Code 201 : 26852 (97.8 %)
Code 503 : 601 (2.2 %)
Response Header Sizes : count 27453 avg 242.91564 +/- 36.35 min 0 max 249 sum 6668763
Response Body/Total Sizes : count 27453 avg 246.17754 +/- 14.56 min 149 max 249 sum 6758312
All done 27453 calls (plus 40 warmup) 262.318 ms avg, 152.4 qpsCode 202 : 52765 (100.0 %)
Response Header Sizes : count 52765 avg 248.86358 +/- 0.5951 min 248 max 250 sum 13131287
Response Body/Total Sizes : count 52765 avg 248.86358 +/- 0.5951 min 248 max 250 sum 13131287
All done 52765 calls (plus 40 warmup) 136.472 ms avg, 292.9 qpsOs resultados indicam que:
Todas as requisições do tipo subscriber foram bem-sucedidas, sem erros HTTP 503, enquanto 2,2% das requisições do tipo guest retornaram HTTP 503.
A latência média para requisições subscriber foi de aproximadamente 136 ms, comparada a cerca de 262 ms para requisições guest. As consultas por segundo (QPS) também diferiram significativamente entre os dois tipos de usuário.
Isso confirma que a AverageLatencySchedulingPolicy prioriza as requisições do tipo subscriber quando a latência aumenta.
Os resultados de teste neste tópico servem apenas como referência. Os dados reais dependem do seu ambiente. Aqui, analisam-se apenas as diferenças relativas entre os pontos de dados.
(Opcional) Etapa 4: Analisar os resultados do teste com base nos logs de acesso do gateway do ASM
Faça login no console do ASM. No painel de navegação à esquerda, escolha .
Na página Mesh Management, clique em nome da instância do ASM. No painel de navegação à esquerda, escolha .
Clique em nome do gateway do ASM para acessar a página Gateway overview. Em seguida, clique em Gateway Logs para visualizar os logs de acesso do gateway do ASM.
Os caminhos de acesso dos usuários guest e subscriber são diferentes. Utilize esses caminhos para recuperar os resultados de acesso de cada usuário respectivamente:
Referências
É possível verificar se a AverageLatencySchedulingPolicy entrou em vigor no Grafana. Certifique-se de que a instância do Prometheus para o Grafana esteja configurada com o conjunto de agendamento de tráfego do ASM.
Importe o conteúdo a seguir para o Grafana a fim de criar um painel para a AverageLatencySchedulingPolicy.
O painel é apresentado a seguir.
