O Service Mesh (ASM) oferece suporte à liberação progressiva de serviços por meio do LoadRampingPolicy. Ao liberar um novo serviço, configure uma política de liberação progressiva para aumentar o tráfego gradualmente, evitar sobrecarga e garantir um lançamento estável.
Informações básicas
O LoadRampingPolicy aumenta progressivamente as requisições recebidas por um serviço durante a liberação. Ele utiliza os seguintes componentes:
Amostrador de requisições: rejeita uma porcentagem das requisições recebidas. Na fase inicial da liberação, o amostrador rejeita a maioria das requisições enviadas ao serviço.
Medidor de carga: mede a carga do serviço. Enquanto a carga permanecer dentro de um intervalo de limiar especificado, o amostrador reduz gradualmente a porcentagem de rejeição em etapas definidas até que quase todas as requisições sejam aceitas.
Ao liberar um novo serviço em um cluster, o LoadRampingPolicy evita erros causados por picos de tráfego ao aumentar progressivamente o tráfego recebido. Ele monitora a carga do serviço em tempo real e ajusta a porcentagem de tráfego adequadamente.
Pré-requisitos
Um cluster gerenciado do Container Service for Kubernetes (ACK) deve estar adicionado à sua instância ASM, e a versão da instância ASM deve ser V1.21.X.XX ou posterior. Para mais informações, consulte Adicionar um cluster a uma instância ASM.
A injeção automática de proxy sidecar deve estar ativada para o namespace padrão no cluster ACK. Para mais informações, consulte Gerencie namespaces globais.
Conecte-se 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 ASM deve estar ativado. Para mais informações, consulte Ative o conjunto de agendamento de tráfego ASM.
A aplicação HTTPBin deve estar implantada e acessível por meio de um gateway. Para mais informações, consulte Implantar a aplicação HTTPBin.
Etapa 1: Crie o LoadRampingPolicy
Use kubectl para conectar-se à instância ASM. Para mais informações, consulte Acessar recursos Istio com kubectl.
-
Crie um arquivo LoadRampingPolicy.yaml com o seguinte conteúdo:
apiVersion: istio.alibabacloud.com/v1 kind: LoadRampingPolicy metadata: name: load-ramping namespace: istio-system spec: drivers: average_latency_drivers: - selectors: - service: httpbin.default.svc.cluster.local criteria: forward: threshold: 100 reset: threshold: 200 start: true load_ramp: sampler: selectors: - service: httpbin.default.svc.cluster.local steps: - duration: 0s target_accept_percentage: 1 - duration: 300s target_accept_percentage: 100.0A tabela a seguir descreve alguns dos campos. Para obter detalhes sobre os campos relacionados, consulte Descrição dos campos do LoadRampingPolicy.
Campo
Descrição
steps
Define as fases de liberação. Neste exemplo, há duas fases definidas, exigindo que a porcentagem de aceitação de requisições atinja quase 100% em 300 segundos.
selectors
Especifica os serviços aos quais a política de liberação progressiva se aplica. Neste exemplo, a liberação progressiva ocorre em httpbin.default.svc.cluster.local.
criteria
Estabelece os critérios de medição da carga do serviço. Neste exemplo: (1) Se a latência média for inferior a 100 ms, a liberação prossegue. (2) Se a latência média exceder 200 ms, a liberação é reiniciada e o amostrador reverte para a porcentagem máxima de rejeição.
-
Execute o comando a seguir para configurar a política de liberação progressiva de serviços:
kubectl apply -f LoadRampingPolicy.yaml
Etapa 2: Verifique se o LoadRampingPolicy entrou em vigor
Este exemplo utiliza a ferramenta de teste de estresse Fortio. Para mais informações, consulte a seção Installation do Fortio no GitHub.
-
Execute o comando a seguir para realizar testes de estresse na aplicação HTTPBin:
fortio load -c 10 -qps 0 -t 300s -allow-initial-errors -a http://${IP address of the ASM ingress gateway}/status/200NotaSubstitua
${IP address of the ASM ingress gateway}nos comandos anteriores pelo endereço IP do seu gateway de entrada ASM. Para saber como obter o endereço IP do gateway de entrada ASM, consulte a subetapa 1 da Etapa 3 no tópico Roteamento de tráfego baseado em versão com Istio.Saída esperada:
... # target 50% 0.0613214 # target 75% 0.0685102 # target 90% 0.0756739 # target 99% 0.0870132 # target 99.9% 0.115361 Sockets used: 31529 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 200 : 26718 (45.9 %) Code 403 : 31510 (54.1 %) Response Header Sizes : count 58228 avg 111.04245 +/- 120.6 min 0 max 243 sum 6465780 Response Body/Total Sizes : count 58228 avg 185.18012 +/- 52.32 min 137 max 243 sum 10782668 All done 58228 calls (plus 10 warmup) 51.524 ms avg, 194.1 qpsA saída mostra que a latência média das requisições é de 51 ms, dentro do limiar configurado. Cerca de metade das requisições recebe um código de status 403, indicando acesso negado. Durante o teste de 300 segundos, a porcentagem de aceitação do serviço aumenta gradualmente de 1% para 100%.
-
Execute novamente o comando a seguir para testar a aplicação HTTPBin sob estresse:
fortio load -c 10 -qps 0 -t 300s -allow-initial-errors -a http://${IP address of the ASM ingress gateway}/status/200Saída esperada:
... # target 50% 0.0337055 # target 75% 0.0368905 # target 90% 0.0396488 # target 99% 0.0791 # target 99.9% 0.123187 Sockets used: 455 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 200 : 82959 (99.5 %) Code 403 : 445 (0.5 %) Response Header Sizes : count 83404 avg 240.71018 +/- 17.63 min 0 max 243 sum 20076192 Response Body/Total Sizes : count 83404 avg 241.44115 +/- 7.649 min 137 max 243 sum 20137158 All done 83404 calls (plus 10 warmup) 35.970 ms avg, 278.0 qpsA saída indica que apenas 0,5% das requisições foram rejeitadas e 99,5% foram aceitas. A liberação progressiva do serviço foi concluída.
-
Exclua o LoadRampingPolicy.
Use kubectl para conectar-se à instância ASM. Para mais informações, consulte Acessar recursos Istio com kubectl.
Execute o comando a seguir para excluir o LoadRampingPolicy após a liberação do serviço:
kubectl delete loadrampingpolicy load-ramping -n istio-systemImportanteNeste exemplo, o
LoadRampingPolicyusa uma duração de 300s para simular a liberação progressiva. Como você configurou a seçãocriteria.reset.threshold, exclua manualmente o LoadRampingPolicy após verificar o resultado. Caso contrário, flutuações de latência podem reativar a liberação progressiva e interromper a operação normal do serviço.
Referências
Verifique se o LoadRampingPolicy entrou em vigor no Grafana. Certifique-se de que a instância Prometheus para Grafana esteja configurada com o conjunto de agendamento de tráfego ASM.
Importe o conteúdo a seguir para o Grafana para criar um painel do LoadRampingPolicy.
O painel é exibido conforme abaixo.
