Práticas recomendadas de escalabilidade para a Cloud Service Mesh no GKE

Este guia descreve as práticas recomendadas para resolver problemas de escalabilidade para arquiteturas de Cloud Service Mesh geridas no Google Kubernetes Engine. O objetivo principal destas recomendações é garantir o desempenho, a fiabilidade e a utilização de recursos ideais para as suas aplicações de microsserviços à medida que crescem.

Para compreender as limitações de escalabilidade, consulte o artigo Limites de escalabilidade da Cloud Service Mesh

A escalabilidade da Cloud Service Mesh no GKE depende do funcionamento eficiente dos seus dois componentes principais, o plano de dados e o plano de controlo. Este documento centra-se principalmente no dimensionamento do plano de dados.

Identificar problemas de escalabilidade do plano de controlo versus plano de dados

No Cloud Service Mesh, podem ocorrer problemas de escalabilidade no plano de controlo ou no plano de dados. Veja como pode identificar o tipo de problema de dimensionamento que está a enfrentar:

Sintomas de problemas de escalabilidade do plano de controlo

Descoberta lenta de serviços: os novos serviços ou pontos finais demoram muito tempo a ser descobertos e a ficarem disponíveis.

Atrasos na configuração: as alterações às regras de gestão de tráfego ou às políticas de segurança demoram muito tempo a propagar-se.

Aumento da latência nas operações do plano de controlo: as operações como a criação, a atualização ou a eliminação de recursos do Cloud Service Mesh tornam-se lentas ou não respondem.

Erros relacionados com o Traffic Director: pode observar erros nos registos do Cloud Service Mesh ou nas métricas do plano de controlo que indicam problemas com a conetividade, o esgotamento de recursos ou a limitação da API.

Âmbito do impacto: os problemas do plano de controlo afetam normalmente toda a malha, o que provoca uma degradação generalizada do desempenho.

Sintomas de problemas de escalabilidade do plano de dados

Aumento da latência na comunicação de serviço a serviço: os pedidos a um serviço na malha registam uma latência ou tempos limite mais elevados, mas não existe uma utilização elevada da CPU/memória nos contentores do serviço.

Utilização elevada da CPU ou da memória em proxies Envoy: a utilização elevada da CPU ou da memória pode indicar que os proxies estão a ter dificuldades em processar a carga de tráfego.

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

Dimensionar o plano de dados

Para dimensionar o plano de dados, experimente as seguintes técnicas:

Configure a escala automática horizontal de pods (HPA) para cargas de trabalho

Use a escala automática horizontal de pods (HPA) para dimensionar dinamicamente as cargas de trabalho com pods adicionais com base na utilização de recursos. Considere o seguinte ao configurar o HPA:

  • Use o parâmetro --horizontal-pod-autoscaler-sync-period para kube-controller-manager ajustar a taxa de sondagem do controlador HPA. A taxa de sondagem predefinida é de 15 segundos e pode considerar defini-la como inferior se esperar picos de tráfego mais rápidos. Para saber mais sobre quando usar o HPA com o GKE, consulte o artigo Escala automática de pods horizontal.

  • O comportamento de escalabilidade predefinido pode resultar na implementação (ou no encerramento) de um grande número de pods de uma só vez, o que pode causar um aumento acentuado na utilização de recursos. Considere usar políticas de escalabilidade para limitar a taxa à qual os pods podem ser implementados.

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

Para mais detalhes sobre a HPA, consulte o artigo Escala automática horizontal de pods na documentação do Kubernetes.

Otimize a configuração do proxy Envoy

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

Limites de recursos

Pode definir pedidos de recursos e limites para sidecars do Envoy nas especificações do seu pod. Isto evita a contenção de recursos e garante um desempenho consistente.

Também pode configurar limites de recursos predefinidos para todos os proxies Envoy na sua malha através de anotações de recursos.

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

Consideração importante:

  • Qualidade de serviço (QoS): a definição de pedidos e limites garante que os proxies Envoy têm uma qualidade de serviço previsível.

Defina o âmbito das dependências do serviço

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

Por exemplo, segue-se o gráfico de tráfego da aplicação de exemplo da boutique online.

Árvore de gráfico de tráfego de aplicação de exemplo de boutique online com muitas folhas

Muitos destes serviços são folhas no gráfico e, como tal, não precisam de ter informações de saída para nenhum dos outros serviços na malha. Pode aplicar um recurso Sidecar que limite o âmbito da configuração do sidecar para estes serviços de folha, conforme mostrado no exemplo seguinte.

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 a aplicação de exemplo Online Boutique para ver detalhes sobre como implementar esta aplicação de exemplo.

Outra vantagem do âmbito do sidecar é a redução das consultas DNS desnecessárias. A definição do âmbito das dependências de serviços garante que um sidecar do Envoy apenas faz consultas DNS para serviços com os quais vai comunicar efetivamente, em vez de todos os clusters na malha de serviços.

Para implementações em grande escala que enfrentam problemas com tamanhos de configuração grandes nos respetivos sidecars, é fortemente recomendado definir o âmbito das dependências de serviço para a escalabilidade da malha.

Monitorize e ajuste

Depois de definir os limites de recursos iniciais, é fundamental monitorizar os proxies do Envoy para garantir que estão a ter um desempenho ideal. Use os painéis de controlo do GKE para monitorizar a utilização da CPU e da memória, e ajustar os limites de recursos conforme necessário.

Para determinar se um proxy Envoy requer limites de recursos aumentados, monitorize o respetivo consumo de recursos em condições de tráfego típicas e de pico. Veja o que procurar:

  • Utilização elevada da CPU: se a utilização da CPU do Envoy se aproximar ou exceder consistentemente o respetivo limite, pode ter dificuldades em processar pedidos, o que leva a um aumento da latência ou a pedidos rejeitados. Pondere aumentar o limite de CPU.

    Neste caso, pode ter tendência para dimensionar através do dimensionamento horizontal, mas se o proxy sidecar não conseguir processar consistentemente os pedidos tão rapidamente quanto o contentor da aplicação, o ajuste dos limites da CPU pode produzir os melhores resultados.

  • Utilização elevada de memória: se a utilização de memória do Envoy se aproximar ou exceder o respetivo limite, pode começar a perder ligações ou a ter erros de falta de memória (OOM). Aumente o limite de memória para evitar estes problemas.

  • Registos de erros: examine os registos do Envoy para ver se existem erros relacionados com o esgotamento de recursos, como erro de ligação a montante ou desligamento ou reposição antes dos cabeçalhos ou erros de demasiados ficheiros abertos. Estes erros podem indicar que o proxy precisa de mais recursos. Consulte os documentos de resolução de problemas de escalabilidade para outros erros relacionados com problemas de escalabilidade.

  • Métricas de desempenho: monitorize as principais métricas de desempenho, como a latência de pedidos, as taxas de erro e a taxa de transferência. Se notar uma degradação do desempenho correlacionada com uma utilização elevada de recursos, pode ser necessário aumentar os limites.

Ao definir e monitorizar ativamente os limites de recursos para os proxies do plano de dados, pode garantir que a sua malha de serviços é dimensionada de forma eficiente no GKE.

Desenvolver a resiliência

Pode ajustar as seguintes definições para dimensionar o seu plano de controlo:

Deteção de valores atípicos

A deteção de valores atípicos monitoriza os anfitriões num serviço a montante e remove-os do conjunto de equilíbrio de carga quando atingem um determinado limite de erro.

  • Configuração principal:
    • outlierDetection: definições que controlam a remoção de anfitriões não íntegros do conjunto de balanceamento de carga.
  • Vantagens: mantém um conjunto saudável de anfitriões no conjunto de equilíbrio de carga.

Para mais informações, consulte o artigo Deteção de valores atípicos na documentação do Istio.

Novas tentativas

Mitigar erros transitórios repetindo automaticamente os pedidos com falhas.

  • Configuração principal:
    • attempts: número de tentativas.
    • perTryTimeout: limite de tempo por tentativa de repetição. Defina este valor inferior ao limite de tempo geral. Determina o tempo de espera para cada tentativa individual.
    • retryBudget: máximo de novas tentativas simultâneas.
  • Vantagens: taxas de êxito mais elevadas para pedidos, impacto reduzido de falhas intermitentes.

Fatores a considerar:

  • Idempotência: certifique-se de que a operação que está a ser repetida é idempotente, o que significa que pode ser repetida sem efeitos secundários não intencionais.
  • Máximo de tentativas: limite o número de tentativas (por exemplo, um máximo de 3 tentativas) para evitar ciclos infinitos.
  • Interrupção de circuito: integre novas tentativas com interrupções de circuito para evitar novas tentativas quando um serviço falha consistentemente.

Para mais informações, consulte a secção Voltas a tentar na documentação do Istio.

Limites de tempo

Use limites de tempo para definir o tempo máximo permitido para o processamento de pedidos.

  • Configuração principal:
    • timeout: limite de tempo do pedido para um serviço específico.
    • idleTimeout: tempo que uma ligação pode permanecer inativa antes do encerramento.
  • Vantagens: melhor capacidade de resposta do sistema, prevenção de fugas de recursos e proteção contra tráfego malicioso.

Fatores a considerar:

  • Latência da rede: tenha em conta o tempo de resposta esperado (RTT) entre os serviços. Deixe alguma margem para atrasos inesperados.
  • Gráfico de dependência de serviços: para pedidos encadeados, certifique-se de que o limite de tempo de um serviço de chamada é inferior ao limite de tempo cumulativo das respetivas dependências para evitar falhas em cascata.
  • Tipos de operações: as tarefas de longa duração podem precisar de limites de tempo significativamente mais longos do que as obtenções de dados.
  • Processamento de erros: os limites de tempo devem acionar a lógica de processamento de erros adequada (por exemplo, nova tentativa, alternativa, interrupção do circuito).

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

Monitorize e ajuste

Considere começar com as predefinições para limites de tempo, deteção de valores atípicos e novas tentativas e, em seguida, ajustá-las gradualmente com base nos requisitos específicos do seu serviço e nos padrões de tráfego observados. Por exemplo, analise dados do mundo real sobre o tempo que os seus serviços demoram normalmente a responder. Em seguida, ajuste os limites de tempo para corresponderem às características específicas de cada serviço ou ponto final.

Telemetria

Use a telemetria para monitorizar continuamente a sua malha de serviços e ajustar a respetiva configuração para otimizar o desempenho e a fiabilidade.

  • Métricas: use métricas abrangentes, especificamente, volumes de pedidos, latência e taxas de erro. Integre-se com o Cloud Monitoring para visualização e alertas.
  • Rastreio distribuído: ative a integração do rastreio distribuído com o Cloud Trace para obter estatísticas detalhadas sobre os fluxos de pedidos nos seus serviços.
  • Registo: configure o registo de acesso para capturar informações detalhadas sobre pedidos e respostas.

Leitura adicional