Alibaba Cloud Service Mesh:Balanceamento de carga baseado na latência da carga de trabalho usando EWMA

Quando usar o peak EWMA

Escolha PEAK_EWMA quando:

• Os pods de backend apresentarem tempos de resposta inconsistentes (por exemplo, devido a contenção de recursos ou hardware heterogêneo).

• Seu serviço lidar com tráfego em rajada que possa sobrecarregar temporariamente pods individuais.

• A latência de cauda (P95/P99) for mais importante que a latência média para o seu caso de uso.

Etapa 1: Ative o monitoramento de métricas

Ative o monitoramento de métricas da instância do ASM para observar as alterações de latência antes e depois de ativar o peak EWMA. Consulte Coletar métricas para o Managed Service for Prometheus.

Etapa 2: Implantar o ambiente de teste

1. Conecte-se ao cluster ACK com kubectl e crie um arquivo sleep.yaml com o seguinte conteúdo:

   Show sleep.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "infinity"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---

   Implante a aplicação sleep:

   kubectl apply -f sleep.yaml

2. Crie um arquivo simple.yaml com o seguinte conteúdo:

   Show simple.yaml

   apiVersion: v1
   kind: Service
   metadata:
     name: simple-server
     labels:
       app: simple-server
       service: simple-server
   spec:
     ports:
     - port: 8080
       name: http
     selector:
       app: simple-server
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: simple-server
     name: simple-server-normal
     namespace: default
   spec:
     progressDeadlineSeconds: 600
     replicas: 1
     revisionHistoryLimit: 10
     selector:
       matchLabels:
         app: simple-server
     strategy:
       rollingUpdate:
         maxSurge: 25%
         maxUnavailable: 25%
       type: RollingUpdate
     template:
       metadata:
         creationTimestamp: null
         labels:
           app: simple-server
       spec:
         containers:
         - args:
           - --delayMin
           - "50"
           - --delayMax
           - "100"
           image: registry-cn-hangzhou.ack.aliyuncs.com/test-public/simple-server:v1.0.0.0-g88293ca-aliyun
           imagePullPolicy: IfNotPresent
           name: simple-server
           ports:
           - containerPort: 80
             protocol: TCP
           resources:
             limits:
               cpu: 500m
           terminationMessagePath: /dev/termination-log
           terminationMessagePolicy: File
         dnsPolicy: ClusterFirst
         restartPolicy: Always
         schedulerName: default-scheduler
         securityContext: {}
         terminationGracePeriodSeconds: 30
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: simple-server
     name: simple-server-high-latency
     namespace: default
   spec:
     progressDeadlineSeconds: 600
     replicas: 1
     revisionHistoryLimit: 10
     selector:
       matchLabels:
         app: simple-server
     strategy:
       rollingUpdate:
         maxSurge: 25%
         maxUnavailable: 25%
       type: RollingUpdate
     template:
       metadata:
         creationTimestamp: null
         labels:
           app: simple-server
       spec:
         containers:
         - args:
           - --delayMin
           - "500"
           - --delayMax
           - "2000"
           image: registry-cn-hangzhou.ack.aliyuncs.com/test-public/simple-server:v1.0.0.0-g88293ca-aliyun
           imagePullPolicy: IfNotPresent
           name: simple-server
           ports:
           - containerPort: 80
             protocol: TCP
           resources:
             limits:
               cpu: 500m
           terminationMessagePath: /dev/termination-log
           terminationMessagePolicy: File
         dnsPolicy: ClusterFirst
         restartPolicy: Always
         schedulerName: default-scheduler
         securityContext: {}
         terminationGracePeriodSeconds: 30
   ---

   Implante ambos os deployments de servidor:

   kubectl apply -f simple.yaml

Etapa 3: Execute um teste de linha de base com o algoritmo padrão

O algoritmo padrão LEAST_REQUEST serve como linha de base. Envie 100 requisições do pod sleep para o serviço simple-server:

kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do time curl simple-server:8080/hello; echo "request $i done"; done'

Saída esperada (abreviada):

hello
 this is port: 8080real 0m 0.06s
user    0m 0.00s
sys     0m 0.00s
request 1 done
hello
 this is port: 8080real 0m 0.09s
...
hello
 this is port: 8080real 0m 1.72s
user    0m 0.00s
sys     0m 0.00s
request 100 done

Após a conclusão do teste, visualize as métricas de latência:

1. Na página Mesh Management, clique em nome da sua instância do ASM. No painel de navegação à esquerda, escolha Observability Management Center > Monitoring metrics.

2. Clique em aba Cloud ASM Istio Service e defina os seguintes filtros:

   Filtro	Valor
   Namespace	default
   Service	simple-server.default.svc.cluster.local
   Reporter	destination
   Client Workload Namespace	default
   Client Workload	sleep
   Service Workload Namespace	default
   Service Workload	simple-server-normal + simple-server-high-latency

3. Clique em Client Workloads para visualizar o painel Incoming Request Duration By Source.

Os resultados da linha de base mostram uma latência P50 de 87,5 ms e uma latência P95 de 2,05 s. Como o LEAST_REQUEST distribui o tráfego uniformemente, o pod lento inflaciona a latência de cauda geral.

Etapa 4: Ative o peak EWMA e execute o teste novamente

1. Crie uma DestinationRule para ativar o peak EWMA no serviço simple-server. Siga as etapas em Configure o peak EWMA usando o seguinte YAML:

   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: simple-server
     namespace: default
   spec:
     host: simple-server.default.svc.cluster.local
     trafficPolicy:
       loadBalancer:
         simple: PEAK_EWMA

2. Execute o mesmo teste novamente:

   kubectl exec -it deploy/sleep -c sleep -- sh -c 'for i in $(seq 1 100); do time curl simple-server:8080/hello; echo "request $i done"; done'

3. Visualize as métricas de latência usando os mesmos filtros da Etapa 3.

As latências P90, P95 e P99 caem significativamente. O peak EWMA detecta que o pod de alta latência responde lentamente e reduz sua parcela de tráfego, roteando a maioria das requisições para o pod mais rápido. A latência geral das requisições para o serviço diminui substancialmente.