Tempo de arranque do agrupamento
Esta secção explica os problemas comuns do Cloud Service Mesh com o tempo de arranque dos pods e como resolvê-los. Se precisar de assistência adicional, consulte a secção Receber apoio técnico.
Sincronização do arranque do pod e da configuração do Envoy
Um problema comum observado durante o arranque do pod em alguns ambientes do Cloud Service Mesh e do Istio envolve a sincronização entre a disponibilidade da aplicação e a configuração do proxy Envoy. O problema surge do início simultâneo do contentor da aplicação e do sidecar do Envoy. A aplicação pode sinalizar que está pronta antes de o proxy Envoy concluir a respetiva inicialização e receber a respetiva configuração do plano de controlo. Isto cria uma condição de concorrência em que os pedidos recebidos são direcionados para um proxy do Envoy não configurado que não está pronto para receber tráfego. Isto pode levar a que os pedidos sejam ignorados, encaminhados incorretamente ou processados incorretamente durante a fase inicial do arranque da aplicação, uma vez que não existe nenhum sidecar para encaminhar o tráfego.
Estratégias de mitigação
As secções seguintes descrevem métodos que podem mitigar este problema.
Configuração da malha global: holdApplicationUntilProxyStarts
A primeira opção é definir holdApplicationUntilProxyStarts: true na configuração da malha do Istio. Tenha em atenção que está desativada por predefinição. A flag adiciona hooks para atrasar o início da aplicação até que o proxy do pod esteja pronto para aceitar tráfego.
A adição da configuração elimina esta condição de concorrência, mas pode introduzir um atraso nos tempos de preparação da aplicação para novos pods se não tiver sido ativada anteriormente.
Sondas de prontidão
Outra solução é implementar testes de prontidão que incorporem verificações de funcionamento da aplicação e do Envoy. As sondas de prontidão informam o Kubernetes quando um pod está pronto para aceitar tráfego. É fundamental que a lógica da sondagem de disponibilidade verifique não só a disponibilidade da aplicação, mas também o estado do proxy Envoy. Isto pode ser conseguido consultando a porta do administrador do Envoy para saber o respetivo estado de funcionamento. Ao combinar ambas as verificações, o Kubernetes impede que o tráfego seja direcionado para o pod até que a aplicação e o Envoy estejam totalmente inicializados e configurados.
Esta abordagem é mais flexível e permite uma lógica de arranque e preparação mais complicada, mas tem um custo de maior complexidade.
Crie o ficheiro healthcheck.sh a partir do seguinte código:
#!/bin/sh
APP_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:8080/health)
ENVOY_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:9901/ready)
if [[ "$APP_HEALTH" -eq 200 && "$ENVOY_HEALTH" -eq 200 ]]; then
exit 0
else
exit 1
fi
Substitua os IPs/portas pelos do contentor da aplicação e do Envoy.
O ficheiro YAML seguinte define uma sondagem de prontidão que usa o script que criou anteriormente:
apiVersion: v1
kind: Pod
metadata:
name: my-app-with-envoy
spec:
containers:
- name: application
<…>
readinessProbe:
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
exec:
command:
- /healthcheck.sh # using the script
- name: envoy
<…>