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. Assim, você pode tomar decisões fundamentadas sobre suas implantações.

Visão geral

A escalonabilidade do Cloud Service Mesh no GKE depende da operação eficiente dos dois principais componentes: 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 escalonabilidade para o plano de dados.

Alguns dos limites de escalonamento documentados são aplicados por restrições de cota. Se você exceder esses limites, será necessário solicitar um aumento de cota. Outros não são aplicados de forma estrita, mas podem levar a um comportamento e desempenho indefinidos se forem excedidos.

Para entender como os recursos do Istio são traduzidos em recursos do 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 é ativado para uma assinatura específica (por exemplo, um cluster do GKE), todos os serviços do Kubernetes no cluster são traduzidos para serviços do Cloud Service Mesh, incluindo aqueles que têm como destino cargas de trabalho sem um arquivo secundário 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 x serviços do Kubernetes

Os serviços do Cloud Service Mesh não são iguais aos serviços do Kubernetes, já que os serviços do Cloud Service Mesh 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 de regra de destino do Istio 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 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 original do Kubernetes tiver criado 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 projetos do Google Cloud, 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 do Cloud Service Mesh no projeto host da frota.

Serviços sem cabeçalho do Kubernetes

Os serviços headless do Kubernetes têm um limite inferior em comparação com os serviços regulares. O Cloud Service Mesh é compatível apenas com 50 serviços headless do Cloud Service Mesh por cluster. Consulte a documentação de rede do Kubernetes para ver um exemplo.

Recursos de sidecar do Istio

Para a API Istio Sidecar, os seguintes limites se aplicam:

  • Arquivo secundário sem workloadSelector: 150 por cluster

  • Arquivo secundário com workloadSelector: 20 por cluster

Limites de escalonamento de endpoints

Os limites de escalonamento de endpoints geralmente são por:

  • 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çalho do Kubernetes

Para serviços headless do Kubernetes, o Cloud Service Mesh aceita no máximo 36 endpoints por serviço headless. Consulte a documentação de rede do Kubernetes para ver um exemplo.

Limites de cluster do GKE

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

Limite de escalonamento do gateway

Ao usar gateways do Istio, especialmente para encerrar conexões HTTPS usando credenciais TLS em secrets 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 zonais ou do Autopilot do GKE