O CRD QuotaSchedulingPolicy, parte do conjunto de agendamento de tráfego do Service Mesh (ASM), permite o agendamento de requisições com base em prioridade dentro de uma cota de chamadas especificada. Quando a taxa de requisições em andamento excede a cota, as requisições subsequentes são enfileiradas e as de maior prioridade são processadas primeiro.
Informações de fundo
O QuotaSchedulingPolicy utiliza o algoritmo de token bucket para controlar a taxa de requisições de um serviço específico e enfileira as requisições quando a taxa excede a cota. O funcionamento é o seguinte:
Um limitador de taxa baseado no algoritmo de token bucket restringe a frequência de requisições. Para mais detalhes sobre o algoritmo, consulte a seção Informações de fundo em Use RateLimitingPolicy to implement user-specific throttling.
Se a taxa de requisições ultrapassar a cota, as requisições seguintes entram em uma fila e são encaminhadas ao serviço de destino após a conclusão das anteriores. Isso mantém a taxa de requisições no valor especificado. As requisições de alta prioridade são retiradas da fila e encaminhadas primeiro.
Diferente do throttling, o QuotaSchedulingPolicy não rejeita requisições que excedem a cota. Em vez disso, ele as coloca em uma fila de prioridades e as agenda conforme a prioridade, mantendo a taxa de requisições dentro da cota definida.
Pré-requisitos
Um cluster gerenciado do Container Service for Kubernetes (ACK) deve estar adicionado à sua instância do ASM, e a versão da instância do ASM deve ser V1.21.6.95 ou posterior. Para mais informações, consulte Add a cluster to an ASM instance.
Conecte-se ao cluster ACK usando kubectl. Para mais informações, consulte Connect to an ACK cluster using kubectl.
O conjunto de agendamento de tráfego do ASM deve estar ativado. Para mais informações, consulte Enable the ASM traffic scheduling suite.
A injeção automática de proxy sidecar deve estar habilitada para o namespace padrão no cluster ACK. Para mais informações, consulte Manage global namespaces.
Crie um ASM ingress gateway chamado ingressgateway com a porta 80 habilitada. Para mais informações, consulte Create an ingress gateway.
A aplicação HTTPBin deve estar implantada e acessível via gateway. Para mais informações, consulte Deploy the HTTPBin application.
Etapa 1: Criar QuotaSchedulingPolicy
Use kubectl para se conectar à instância do ASM. Para mais informações, consulte Access Istio resources with kubectl.
-
Crie um arquivo quotaschedulingpolicy.yaml com o seguinte conteúdo:
apiVersion: istio.alibabacloud.com/v1 kind: QuotaSchedulingPolicy metadata: name: quotascheduling namespace: istio-system spec: quota_scheduler: bucket_capacity: 10 fill_amount: 10 rate_limiter: interval: 1s 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 dos campos. Para mais informações sobre os campos relacionados, consulte QuotaSchedulingPolicy field reference.
Campo
Descrição
fill_amount
Quantidade de tokens adicionados por intervalo. Neste exemplo, o valor é 10, o que significa que 10 tokens são adicionados ao bucket após cada intervalo.
interval
Frequência com que os tokens são adicionados ao bucket. Neste exemplo, o valor é 1s, então 10 tokens são adicionados a cada segundo.
bucket_capacity
Número máximo de tokens no bucket. Quando a taxa de requisições é inferior à taxa de preenchimento, os tokens se acumulam até atingir
bucket_capacity, permitindo certo nível de tráfego em rajada. Neste exemplo, o valor é 10, igual afill_amount, portanto não há permissão para tráfego em rajada.workloads
Dois tipos de requisição são definidos com base em
user_typenos cabeçalhos da requisição:guestesubscriber. A prioridade de uma requisição do tipoguesté 50, e a de uma requisição do tiposubscriberé 200.selectors
Serviços aos quais a política de cota se aplica. Neste exemplo, a limitação de cota é aplicada ao serviço httpbin.default.svc.cluster.local.
Execute o comando a seguir para criar o QuotaSchedulingPolicy:
kubectl apply -f quotaschedulingpolicy.yamlEtapa 2: Verificar se o QuotaSchedulingPolicy entrou em vigor
Neste exemplo, utiliza-se a ferramenta de teste de estresse Fortio. Para mais informações, consulte a seção Installation do Fortio no site do GitHub.
-
Abra dois terminais e execute simultaneamente os comandos de teste de estresse a seguir. Em ambos os testes, 10 conexões simultâneas enviam requisições a 10.000 QPS, valor muito superior à cota configurada para o 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 ingress gateway}nos comandos acima pelo endereço IP do seu ASM ingress gateway. Para saber como obter o endereço IP do ASM ingress gateway, consulte a subetapa 1 da Etapa 3 no tópico Version-based traffic routing with Istio.Saída esperada do teste 1:
... # target 50% 4.83333 # target 75% 5.20763 # target 90% 5.38203 # target 99% 5.48668 # target 99.9% 5.49714 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 201 : 70 (100.0 %) Response Header Sizes : count 70 avg 249.94286 +/- 0.2871 min 248 max 250 sum 17496 Response Body/Total Sizes : count 70 avg 249.94286 +/- 0.2871 min 248 max 250 sum 17496 All done 70 calls (plus 10 warmup) 4566.839 ms avg, 2.1 qps Successfully wrote 4693 bytes of Json data to 2024-07-26-232250_114_55_5_155_status_201_iZbp1cz9ur77robaiv085tZ.jsonSaída esperada do teste 2:
fortio load -c 10 -qps 10000 -H "user_type:subscriber" -t 30s -timeout 60s -a http://114.55.xx.xx/status/202 ... # target 50% 0.253333 # target 75% 1.875 # target 90% 4.26635 # target 99% 4.47301 # target 99.9% 4.49367 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 202 : 250 (100.0 %) Response Header Sizes : count 250 avg 250.264 +/- 0.4408 min 250 max 251 sum 62566 Response Body/Total Sizes : count 250 avg 250.264 +/- 0.4408 min 250 max 251 sum 62566 All done 250 calls (plus 10 warmup) 1226.657 ms avg, 8.0 qps Successfully wrote 4509 bytes of Json data to 2024-07-26-232250_114_55_5_155_status_202_iZbp1cz9ur77robaiv085tZ.jsonA saída mostra que o teste 2 apresenta cerca de 1/4 da latência média e 4 vezes o QPS do teste 1, pois a prioridade do assinante (200) é quatro vezes maior que a do convidado (50). Um total de 320 requisições foram processadas em 30 segundos considerando ambos os testes. Excluindo as 20 requisições de aquecimento, a taxa efetiva é de exatamente 10 requisições por segundo, confirmando que o serviço permanece dentro da cota.
Referências
É possível verificar se o QuotaSchedulingPolicy entrou em vigor no Grafana. Certifique-se de que a instância do Prometheus para o Grafana esteja configurada com o ASM traffic scheduling suite.
Importe o conteúdo a seguir para o Grafana a fim de criar um painel do QuotaSchedulingPolicy.
O painel é exibido da seguinte forma:
