Limites de escalonamento do Cloud Service Mesh no GKE

Este documento descreve os limites de escalonamento do plano de controle para arquiteturas gerenciadas do Cloud Service Mesh no GKE para que você possa tomar decisões informadas sobre suas implantações.

Visão geral

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 nos limites de escalonamento do plano de controle. Consulte as práticas recomendadas de escalabilidade para conferir as práticas recomendadas de escalabilidade do plano de dados.

Alguns dos limites de escalonamento documentados são aplicados por restrições de cota. Se exceder esse limite, será necessário solicitar um aumento de cota. Outros não são estritamente aplicados, mas podem levar a um comportamento indefinido e desempenho se forem excedidos.

Para entender como os recursos do Istio são convertidos em recursos Google Cloud , consulte primeiro o guia Noções básicas sobre recursos da API.

Limites de escalonamento de serviços

O escalonamento de serviços é limitado em duas dimensões

Depois que o Cloud Service Mesh for ativado para uma assinatura específica (por exemplo, cluster do GKE), todos os serviços do Kubernetes no cluster serão convertidos em serviços do Cloud Service Mesh, incluindo aqueles que são direcionados a cargas de trabalho sem um sidecar do Cloud Service Mesh. O Cloud Service Mesh cria grupos de endpoints de rede zonais para todos os serviços no cluster do GKE. Se o cluster for regional, os grupos de endpoints de rede serão criados para todas as zonas do pool de nós na região.

Serviços do Cloud Service Mesh e do Kubernetes

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

Por exemplo, esse serviço do Kubernetes é traduzido internamente em dois serviços do 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

Ao 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 DestinationRule a seguir que tem como destino o serviço do 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

Novos serviços sintéticos serão criados para cada um dos subconjuntos definidos. Se o serviço do Kubernetes original criou dois serviços do Cloud Service Mesh, o DestinationRule vai criar mais quatro serviços do Cloud Service Mesh, dois para cada subconjunto, resultando em um total de seis serviços do Cloud Service Mesh.

Implantações de vários projetos

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

Serviços sem cabeça do Kubernetes

Os serviços sem comando do Kubernetes têm um limite mais baixo em comparação com os serviços regulares. O Cloud Service Mesh oferece suporte apenas a 50 serviços headless do Cloud Service Mesh por cluster. Consulte a documentação de rede do Kubernetes para conferir um exemplo.

Limites de escalonamento de endpoint

Os limites de escalonamento de endpoints geralmente são definidos da seguinte forma:

  • Serviço do Cloud Service Mesh

  • Cluster do GKE

Serviços regulares do Kubernetes

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

Serviços sem cabeça do Kubernetes

Para o serviço sem comando do Kubernetes, o Cloud Service Mesh oferece suporte a, no máximo, 36 endpoints por serviço sem comando. Consulte a documentação de rede do Kubernetes para conferir um exemplo.

Limites de cluster do GKE

O Cloud Service Mesh oferece suporte a até 5.000 endpoints (IPs de pod) por cluster.

Limite de escalonamento do gateway

Ao usar gateways do Istio, principalmente para encerrar conexões HTTPS usando credenciais TLS em segredos do Kubernetes, o Cloud Service Mesh oferece suporte a, no máximo, o seguinte número de pods:

  • 1.500 pods de gateway ao usar clusters regionais do GKE

  • 500 pods de gateway ao usar clusters do GKE Zonal ou Autopilot