Práticas recomendadas de escalonamento para o Cloud Service Mesh no GKE

Este guia descreve as práticas recomendadas para resolver problemas de escalonamento de arquiteturas Cloud Service Mesh gerenciadas no Google Kubernetes Engine. O objetivo principal dessas recomendações é garantir o desempenho, a confiabilidade e a utilização de recursos ideais para seus aplicativos de microsserviços à medida que eles crescem.

A escalabilidade do Cloud Service Mesh no GKE depende da operação eficiente dos dois componentes principais, o plano de dados e o plano de controle. Este documento se concentra principalmente na escalação do plano de dados.

Como identificar problemas de escalonamento do plano de controle e do plano de dados

No Cloud Service Mesh, problemas de escalonamento podem ocorrer no plano de controle ou no plano de dados. Veja como identificar o tipo de problema de escalonamento que você está enfrentando:

Sintomas de problemas de escalonamento do plano de controle

Descoberta de serviço lenta:novos serviços ou endpoints demoram muito para ser descobertos e ficarem disponíveis.

Atrasos na configuração:as mudanças nas regras de gerenciamento de tráfego ou nas políticas de segurança levam muito tempo para se propagar.

Latência aumentada nas operações do plano de controle:operações como a criação, atualização ou exclusão de recursos do Cloud Service Mesh ficam lentas ou não respondem.

Erros relacionados ao Traffic Director:é possível observar erros nos registros do Cloud Service Mesh ou nas métricas do plano de controle indicando problemas com conectividade, esgotamento de recursos ou limitação de API.

Escopo do impacto:os problemas do plano de controle geralmente afetam toda a malha, causando uma degradação de desempenho generalizada.

Sintomas de problemas de escalonamento do plano de dados

Maior latência na comunicação entre serviços:as solicitações para um serviço na malha apresentam latência ou tempos limite mais altos, mas não há uso elevado de CPU/memória nos contêineres do serviço.

Alto uso de CPU ou memória em proxies do Envoy:o uso alto de CPU ou memória pode indicar que os proxies estão com dificuldades para lidar com a carga de tráfego.

Impacto localizado:os problemas do plano de dados geralmente afetam serviços ou cargas de trabalho específicos, dependendo dos padrões de tráfego e da utilização de recursos dos proxies do Envoy.

Como dimensionar o plano de dados

Para dimensionar o plano de dados, tente estas técnicas:

Configurar o escalonamento automático horizontal de pods (HPA) para cargas de trabalho

Use o escalonamento automático de pod horizontal (HPA) para escalonar dinamicamente as cargas de trabalho com outros pods com base na utilização de recursos. Considere o seguinte ao configurar a HPA:

  • Use o parâmetro --horizontal-pod-autoscaler-sync-period para kube-controller-manager ajustar a taxa de pesquisa do controlador de HPA. A taxa de pesquisa padrão é de 15 segundos, e você pode definir um valor menor se espera picos de tráfego mais rápidos. Para saber mais sobre quando usar o HPA com o GKE, consulte Escalonamento automático horizontal de pods.

  • O comportamento de escalonamento padrão pode resultar na implantação (ou no encerramento) de um grande número de pods de uma só vez, o que pode causar um pico no uso de recursos. Use políticas de escalonamento para limitar a taxa de implantação de pods.

  • Use EXIT_ON_ZERO_ACTIVE_CONNECTIONS para evitar a perda de conexões durante a redução de escala.

Para mais detalhes sobre o HPA, consulte Escalonamento automático horizontal de pods na documentação do Kubernetes.

Otimizar a configuração do proxy do Envoy

Para otimizar a configuração do proxy do Envoy, considere estas recomendações:

Limites de recurso

É possível definir solicitações e limites de recursos para sidecars do Envoy nas especificações do pod. Isso evita a contenção de recursos e garante um desempenho consistente.

Também é possível configurar limites de recursos padrão para todos os proxies do Envoy na sua malha usando anotações de recurso.

Os limites de recursos ideais para os proxies do Envoy dependem de fatores, como volume de tráfego, complexidade da carga de trabalho e recursos do nó do GKE. Monitore e ajuste sua malha de serviço continuamente para garantir o desempenho ideal.

Consideração importante:

  • Qualidade de serviço (QoS): definir solicitações e limites garante que os proxies do Envoy tenham uma qualidade de serviço previsível.

Agrupar dependências de serviço

Considere reduzir o gráfico de dependência da malha declarando todas as dependências pela API Sidecar. Isso limita o tamanho e a complexidade da configuração enviada para uma determinada carga de trabalho, o que é essencial para malhas maiores.

Confira abaixo o gráfico de tráfego do aplicativo de exemplo de boutique on-line.

Árvore de gráfico de tráfego do aplicativo de exemplo da Online Boutique com muitas folhas

Muitos desses serviços são folhas no gráfico e, portanto, não precisam ter informações de saída para nenhum dos outros serviços na malha. É possível aplicar um recurso sidecar que limita o escopo da configuração do sidecar para esses serviços de folha, conforme mostrado no exemplo abaixo.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

Consulte o aplicativo de exemplo Online Boutique para saber como implantar esse aplicativo de exemplo.

Outro benefício do escopo do sidecar é reduzir as consultas DNS desnecessárias. O escopo das dependências de serviço garante que um sidecar do Envoy só faça consultas DNS para serviços com os quais ele vai se comunicar, em vez de todos os clusters na malha de serviço.

Para implantações em grande escala que enfrentam problemas com tamanhos de configuração grandes nos sidecars, o escopo das dependências de serviço é altamente recomendado para a escalabilidade da malha.

Monitorar e ajustar

Depois de definir os limites iniciais de recursos, é crucial monitorar os proxies do Envoy para garantir que eles tenham o desempenho ideal. Use os painéis do GKE para monitorar o uso da CPU e da memória e ajustar os limites de recursos conforme necessário.

Para determinar se um proxy do Envoy precisa de limites de recursos maiores, monitore o consumo de recursos em condições normais e de pico de tráfego. Confira o que procurar:

  • Uso alto da CPU:se o uso da CPU do Envoy se aproxima ou excede consistentemente o limite, ele pode ter dificuldade para processar solicitações, o que leva a uma maior latência ou perda de solicitações. Considere aumentar o limite da CPU.

    Talvez você queira usar o escalonamento horizontal nesse caso, mas, se o proxy sidecar não conseguir processar as solicitações com a mesma rapidez que o contêiner do aplicativo, ajustar os limites da CPU pode produzir os melhores resultados.

  • Alto uso de memória:se o uso de memória do Envoy se aproximar ou exceder o limite, ele poderá começar a perder conexões ou apresentar erros de falta de memória (OOM). Aumente o limite de memória para evitar esses problemas.

  • Registros de erros:examine os registros do Envoy em busca de erros relacionados à exaustão de recursos, como erro de conexão upstream ou desconexão ou redefinição antes dos cabeçalhos ou muitos arquivos abertos. Esses erros podem indicar que o proxy precisa de mais recursos. Consulte os documentos de solução de problemas de dimensionamento para conferir outros erros relacionados a problemas de dimensionamento.

  • Métricas de desempenho:monitore as principais métricas de desempenho, como latência de solicitações, taxas de erros e capacidade. Se você notar uma degradação no desempenho correlacionada à alta utilização de recursos, talvez seja necessário aumentar os limites.

Ao definir e monitorar ativamente os limites de recursos dos proxies do plano de dados, é possível garantir que a malha de serviços seja dimensionada de forma eficiente no GKE.

Como criar resiliência

Você pode ajustar as seguintes configurações para dimensionar o plano de controle:

Detecção de outlier

A detecção de outliers monitora hosts em um serviço upstream e os remove do pool de balanceamento de carga ao atingir um limite de erro.

  • Configuração da chave:
    • outlierDetection: configurações que controlam a remoção de hosts não íntegros do pool de balanceamento de carga.
  • Benefícios:mantém um conjunto saudável de hosts no pool de balanceamento de carga.

Para mais informações, consulte Detecção de valores discrepantes na documentação do Istio.

Novas tentativas

Reduza os erros temporários repetindo automaticamente as solicitações com falha.

  • Configuração da chave:
    • attempts: número de novas tentativas.
    • perTryTimeout: tempo limite por tentativa de nova tentativa. Defina um valor menor que o tempo limite geral. Ele determina por quanto tempo você vai esperar por cada tentativa de nova tentativa.
    • retryBudget: número máximo de novas tentativas simultâneas.
  • Benefícios:taxas de sucesso mais altas para solicitações e redução do impacto de falhas intermitentes.

Fatores a considerar:

  • Idempotência:verifique se a operação que está sendo repetida é idempotente, o que significa que ela pode ser repetida sem efeitos colaterais não intencionais.
  • Novas tentativas máximas:limite o número de novas tentativas (por exemplo, no máximo três) para evitar loops infinitos.
  • Quebra de circuito:integre novas tentativas com disjuntores para evitar novas tentativas quando um serviço falhar constantemente.

Para mais informações, consulte Repetição na documentação do Istio.

Tempo limite

Use timeouts para definir o tempo máximo permitido para o processamento de solicitações.

  • Configuração da chave:
    • timeout: tempo limite da solicitação para um serviço específico.
    • idleTimeout: tempo que uma conexão pode permanecer inativa antes do fechamento.
  • Benefícios:melhora na capacidade de resposta do sistema, prevenção de vazamentos de recursos e aumento da proteção contra tráfego malicioso.

Fatores a considerar:

  • Latência da rede:considere o tempo de ida e volta esperado (RTT) entre os serviços. Deixe um buffer para atrasos inesperados.
  • Gráfico de dependência de serviço:para solicitações em cadeia, verifique se o tempo limite de um serviço de chamada é menor do que o tempo limite cumulativo das dependências dele para evitar falhas em cascata.
  • Tipos de operações:tarefas de longa duração podem precisar de tempos limite mais longos do que a recuperação de dados.
  • Tratamento de erros:os timeouts precisam acionar a lógica de tratamento de erros adequada, como repetição, fallback e interrupção de circuito.

Para mais informações, consulte Tempos limite na documentação do Istio.

Monitorar e ajustar

Comece com as configurações padrão de tempos limite, detecção de outliers e tentativas e ajuste-as gradualmente com base nos requisitos de serviço específicos e nos padrões de tráfego observados. Por exemplo, analise dados reais sobre quanto tempo seus serviços geralmente levam para responder. Em seguida, ajuste os tempos limite para corresponder às características específicas de cada serviço ou endpoint.

Telemetria

Use a telemetria para monitorar continuamente a malha de serviços e ajustar a configuração dela para otimizar a performance e a confiabilidade.

  • Métricas:use métricas abrangentes, especificamente, volumes de solicitações, latência e taxas de erro. Integrar com o Cloud Monitoring para visualização e alertas.
  • Rastreamento distribuído:ative a integração do rastreamento distribuído com o Cloud Trace para ter insights profundos sobre os fluxos de solicitações em todos os serviços.
  • Registro:configure o registro de acesso para coletar informações detalhadas sobre solicitações e respostas.

Informações adicionais