Limites de escalabilidade para a Cloud Service Mesh no GKE

Este documento descreve os limites de escalabilidade do plano de controlo para arquiteturas de malha de serviços na nuvem geridas no GKE, para que possa tomar decisões informadas relativamente às suas implementações.

Vista geral

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 foca-se nos limites de escalabilidade do plano de controlo. Consulte as práticas recomendadas de escalabilidade para conhecer as práticas recomendadas de escalabilidade do plano de dados.

Alguns dos limites de escalabilidade documentados são aplicados por restrições de quota. Excedê-los requer pedidos de aumento da quota. Outros não são aplicados rigorosamente, mas podem levar a um comportamento e um desempenho indefinidos se forem excedidos.

Para compreender como os recursos do Istio são traduzidos em Google Cloud recursos, consulte primeiro o guia Compreender os recursos da API.

Limites de escalabilidade do serviço

O dimensionamento do serviço está limitado a duas dimensões

Tenha em atenção que, assim que o Cloud Service Mesh é ativado para uma determinada associação (ou seja, um cluster do GKE), todos os serviços Kubernetes no cluster são traduzidos para serviços do Cloud Service Mesh, incluindo os que segmentam cargas de trabalho sem um sidecar do Cloud Service Mesh. O Cloud Service Mesh cria grupos de pontos finais de rede zonais para todos os serviços no cluster do GKE. Se o cluster for regional, os grupos de pontos finais de rede são criados para todas as zonas do conjunto de nós na região.

Serviços do Cloud Service Mesh versus serviços do Kubernetes

Os serviços do Cloud Service Mesh não são iguais aos serviços do Kubernetes, uma vez que os serviços do Cloud Service Mesh são um serviço por porta.

Por exemplo, este serviço Kubernetes é traduzido internamente em dois serviços Cloud Service Mesh, um para cada porta.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    -   port: 80
      targetPort: 80
      protocol: TCP
      name: http
    -   port: 443
      targetPort: 443
      protocol: TCP
      name: https

Subconjuntos de regras de destino

Quando configurar a API Istio Destination Rule com subconjuntos, cada subconjunto pode resultar na geração de vários novos serviços do Cloud Service Mesh.

Por exemplo, considere o seguinte DestinationRule que segmenta o serviço kubernetes definido anteriormente:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destinationrule
spec:
  host: my-service
  subsets:
  -   name: testversion
    labels:
      version: v3
  -   name: prodversion
    labels:
      version: v2

Serão criados novos serviços sintéticos para cada um dos subconjuntos definidos. Se o serviço Kubernetes original tiver criado dois serviços Cloud Service Mesh, o DestinationRule cria 4 serviços Cloud Service Mesh adicionais, 2 para cada subconjunto, o que resulta num total de 6 serviços Cloud Service Mesh.

Implementações em vários projetos

Quando uma única malha é implementada em cargas de trabalho em diferentes Google Cloud projetos, todos os recursos de serviço da Cloud Service Mesh são criados no projeto anfitrião da frota. Isto significa que estão todos sujeitos às limitações de escalabilidade do Cloud Service Mesh no projeto de anfitrião da frota.

Serviços sem cabeça do Kubernetes

Os serviços sem cabeça do Kubernetes têm um limite inferior em comparação com os serviços normais. O Cloud Service Mesh só suporta 50 serviços headless do Cloud Service Mesh por cluster. Consulte a documentação de rede do Kubernetes para ver um exemplo.

Limites de escalabilidade de pontos finais

Os limites de escalabilidade dos pontos finais são normalmente os seguintes:

  • Serviço do Cloud Service Mesh

  • Cluster do GKE

Serviços normais do Kubernetes

As quotas de pontos finais por NEG afetam o número máximo de pontos finais que podem pertencer a um único serviço do Kubernetes.

Serviços sem cabeça do Kubernetes

Para o serviço sem cabeça do Kubernetes, o Cloud Service Mesh suporta um máximo de 36 pontos finais por serviço sem cabeça. Consulte a documentação de rede do Kubernetes para ver um exemplo.

Limites de clusters do GKE

O Cloud Service Mesh suporta até 5000 pontos finais (IPs de pods) por cluster.

Limite de escalabilidade do gateway

Quando usa gateways do Istio, especialmente para terminar ligações HTTPS com credenciais TLS em segredos do Kubernetes, o Cloud Service Mesh suporta, no máximo, o seguinte número de pods:

  • 1500 pods de gateway quando usa clusters do GKE regionais

  • 500 pods de gateway quando usar clusters do GKE zonais ou do Autopilot