Tempo de inicialização do pod

Esta seção explica problemas comuns do Cloud Service Mesh com o tempo de inicialização do pod e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.

Inicialização do pod e sincronização da configuração do Envoy

Um problema comum observado durante a inicialização do pod em alguns ambientes do Cloud Service Mesh e do Istio envolve a sincronização entre a prontidão do aplicativo e a configuração do proxy Envoy. O problema surge da inicialização simultânea do contêiner do aplicativo e do sidecar do Envoy. O aplicativo pode sinalizar a prontidão antes que o proxy do Envoy conclua a inicialização e receba a configuração do plano de controle. Isso cria uma condição de corrida em que as solicitações de entrada são direcionadas para um proxy Envoy não configurado que não está pronto para receber tráfego. Isso pode fazer com que as solicitações sejam descartadas, redirecionadas ou processadas incorretamente durante a fase inicial de inicialização do aplicativo, já que não há sidecar para encaminhar o tráfego.

Estratégias de mitigação

As seções a seguir descrevem métodos que podem reduzir esse problema.

Configuração de malha global: holdApplicationUntilProxyStarts

A primeira opção é definir holdApplicationUntilProxyStarts: true na configuração da malha do Istio. Ela está desativada por padrão. A flag adiciona ganchos para atrasar a inicialização do aplicativo até que o proxy do pod esteja pronto para aceitar tráfego.

Adicionar a configuração elimina essa corrida, mas pode atrasar os tempos de prontidão do aplicativo para novos pods se ela não tiver sido ativada anteriormente.

Sondagens de prontidão

Outra solução é implementar sondagens de prontidão que incorporem verificações de integridade do aplicativo e do Envoy. As sondagens de prontidão informam ao Kubernetes quando um pod está pronto para aceitar tráfego. A lógica da sondagem de prontidão precisa verificar não apenas a prontidão do aplicativo, mas também o status do proxy do Envoy. Isso pode ser feito consultando o status de integridade da porta administradora do Envoy. Ao combinar as duas verificações, o Kubernetes impede que o tráfego seja direcionado ao pod até que o aplicativo e o Envoy sejam totalmente inicializados e configurados.

Essa abordagem é mais flexível e permite uma lógica de inicialização e preparação mais complicada, mas tem o custo de maior complexidade.

Crie o arquivo healthcheck.sh com base no 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 o IP/portas pelo contêiner do aplicativo e pelo Envoy.

O arquivo YAML a seguir define uma sondagem de prontidão que usa o script que você 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
    <…>

A seguir