Gerenciamento de tráfego de gateway

Autopilot Padrão

---

Nesta página, você vê como o gerenciamento de tráfego do gateway funciona.

Visão geral

A rede do Google Kubernetes Engine (GKE) é criada com base no Cloud Load Balancing. Com o Cloud Load Balancing, um único endereço IP Anycast que fornece gerenciamento de tráfego global. O gerenciamento de tráfego do Google oferece balanceamento de carga global e regional, escalonamento automático e gerenciamento de capacidade para fornecer distribuição de tráfego igual, estável e de baixa latência. Com o controlador de gateway do GKE, os usuários do GKE podem utilizar o controle de gerenciamento de tráfego global do Google de maneira declarativa e nativa do Kubernetes.

Para testar o vazamento de tráfego entre clusters, consulte Como implantar o balanceamento de carga baseado em capacidade. Para testar o escalonamento automático baseado em tráfego, consulte Escalonamento automático baseado no tráfego do balanceador de carga.

Gerenciamento de tráfego

O balanceamento de carga, o escalonamento automático e o gerenciamento de capacidade são a base de um sistema de gerenciamento de tráfego. Essas operações operam juntas para equalizar e estabilizar a carga do sistema.

• O balanceamento de carga distribui o tráfego pelos pods de back-end de acordo com o local, a integridade e os diferentes algoritmos de balanceamento de carga.
• O escalonamento automático dimensiona as réplicas para criar mais capacidade de absorver mais tráfego.
• O gerenciamento de capacidade monitora a utilização de serviços para que o tráfego possa transbordar para back-ends com capacidade em vez de afetar a disponibilidade ou o desempenho do aplicativo.

Esses recursos podem ser combinados de diferentes maneiras, dependendo das suas metas. Por exemplo:

• Se você quiser aproveitar as VMs Spot de baixo custo, otimize para distribuir o tráfego uniformemente entre as VMs Spot ao custo de latência. Usando o balanceamento de carga e o gerenciamento de capacidade, o GKE ultrapassa o tráfego entre as regiões com base na capacidade para que as VMs do Spot sejam totalmente utilizadas onde quer que estejam disponíveis.

• Se você quiser otimizar a latência do usuário ao custo do provisionamento excessivo, implante clusters do GKE em muitas regiões e aumente a capacidade dinamicamente sempre que a carga aumentar. Usar o balanceamento de carga e o escalonamento automático do GKE faz o escalonamento automático do número de pods quando o tráfego aumenta para que o tráfego não precise transbordar para outras regiões. As regiões aumentariam a capacidade para que possam lidar totalmente com a carga o mais próximo possível dos usuários.

O diagrama a seguir mostra o balanceamento de carga, o escalonamento automático e o gerenciamento de capacidade operando juntos:

No diagrama, a carga de trabalho no cluster gke-us falhou. O balanceamento de carga e a verificação de integridade drena conexões ativas e redireciona o tráfego para o próximo cluster mais próximo. A carga de trabalho em gke-asia recebe mais tráfego do que ela tem capacidade, por isso gera uma carga para gke-eu. O gke-eu recebe mais carga do que o normal devido a eventos em gke-us e gke-asia. Por isso, gke-eu é escalonado automaticamente para aumentar a capacidade de tráfego.

Para saber mais sobre como o Cloud Load Balancing processa o gerenciamento de tráfego, consulte Gerenciamento de capacidade global.

Recursos de gerenciamento de tráfego

Os recursos de gateway, HTTPRoute, serviço e política fornecem os controles para gerenciar o tráfego no GKE. O controlador de gateway do GKE é o plano de controle que monitora esses recursos.

Os seguintes recursos de gerenciamento de tráfego estão disponíveis ao implantar serviços no GKE:

• Capacidade de serviço: a capacidade de especificar a quantidade de capacidade de tráfego que um Serviço pode receber antes que os pods sejam escalonados automaticamente ou que o tráfego ultrapasse outros clusters disponíveis.
• Escalonamento automático baseado em tráfego: pods de escalonamento automático em um serviço com base em solicitações HTTP recebidas por segundo.

• Balanceamento de carga de vários clusters: a capacidade de balancear a carga para serviços hospedados em vários clusters do GKE ou várias regiões.

• Divisão de tráfego: distribuição de tráfego explícita e baseada em peso nos back-ends. A divisão de tráfego é compatível com gateways de cluster único no GA.

Suporte de gerenciamento de tráfego

Os recursos de gerenciamento de tráfego disponíveis dependem da GatewayClass implantada. Para uma lista completa de suporte a recursos, consulte Recursos da GatewayClass. A tabela a seguir resume a compatibilidade da GatewayClass para o gerenciamento de tráfego:

GatewayClass	Capacidade do serviço	Escalonamento automático de tráfego	Balanceamento de carga de vários clusters	Divisão de tráfego^1
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc

¹ A divisão de tráfego é compatível com gateways de cluster único no GA.

Balanceamento de carga global, regional e por zona

A capacidade do serviço, o local e a integridade determinam a quantidade de tráfego que o balanceador de carga envia para um determinado back-end. As decisões de balanceamento de carga são tomadas nos seguintes níveis, começando com global para balanceadores de carga globais e regional para balanceadores de carga regionais:

• Global: o tráfego é enviado para a região mais próxima do Google Cloud no cliente que tem back-ends íntegros com capacidade. Contanto que a região tenha capacidade, ela recebe todo o tráfego mais próximo. Se uma região não tiver capacidade, o tráfego excedente excederá a região seguinte mais próxima com capacidade. Saiba mais em Balanceamento de carga global.
• Regional: o tráfego é enviado pelo balanceador de carga para uma região específica. O tráfego é balanceado por carga entre zonas de acordo com a capacidade de veiculação disponível na zona. Saiba mais em Balanceamento de carga regional.
• Por zona: depois que o tráfego é determinado para uma zona específica, o balanceador de carga distribui o tráfego igualmente entre os back-ends dentro dessa zona. As conexões TCP e as configurações de persistência de sessão atuais são preservadas, para que as futuras solicitações vão para os mesmos back-ends, desde que o pod de back-end esteja íntegro. Para saber mais, consulte Balanceamento de carga zonal.

Balanceamento de carga global e estouro de tráfego

Para testar os conceitos a seguir no seu próprio cluster, consulte Balanceamento de carga baseado em capacidade.

Em condições normais, o tráfego é enviado para o back-end mais próximo do cliente. O tráfego termina no ponto de presença (PoP, na sigla em inglês) mais próximo do Google para o cliente e, em seguida, atravessa o backbone do Google até chegar ao back-end mais próximo, conforme determinado pela latência da rede. Quando os back-ends de uma região não têm capacidade restante, o tráfego estoura o próximo cluster mais próximo com back-ends íntegros que têm capacidade. Se menos de 50% dos pods de back-end em uma zona não estiverem íntegros, o tráfego falhará gradualmente para outras zonas ou regiões, independentemente da capacidade configurada.

O estouro de tráfego só ocorre nas seguintes condições:

• Você está usando um gateway de vários clusters.
• Você tem o mesmo serviço implantado em vários clusters, exibidos pelo gateway de vários clusters.
• Você tem capacidades de serviço configuradas de modo que o tráfego exceda as capacidades de serviço em um cluster, mas não em outros.

O diagrama a seguir demonstra como o balanceamento de carga global funciona com o excesso de tráfego:

No diagrama:

• Um gateway de vários clusters fornece balanceamento de carga de Internet global para o serviço store. O serviço é implantado em dois clusters do GKE, um em us-west1 e outro em europe-west1. Cada cluster está executando duas réplicas.
• Cada serviço é configurado com max-rate-per-endpoint="10", o que significa que cada serviço tem uma capacidade total de 2 réplicas * 10 RPS = 20 RPS em cada cluster.
• Os PoPs do Google na América do Norte recebem seis RPS. Todo o tráfego é enviado para o back-end íntegro mais próximo com capacidade, o cluster do GKE em us-west1.
• Os PoPs europeus recebem 30 RPS. Os back-ends mais próximos estão em europe-west1, mas têm apenas 20 RPS de capacidade. Como os back-ends em us-west1 têm capacidade extra, 10 RPS estoura para us-west1 para que ele receba 16 RPS no total e distribui 8 RPS para cada pod.

Observação: se você estiver usando gateways de cluster único, um Serviço do tipo LoadBalancer ou recursos de entrada, esse exemplo de balanceamento de carga global não se aplica, porque esses recursos só fazem o balanceamento de carga para um único cluster em uma única região. Recomendamos os gateways de vários clusters se você tiver requisitos globais de balanceamento de carga.

Como evitar o excesso de tráfego

O excesso de tráfego ajuda a evitar que a capacidade do aplicativo seja excedida, o que pode afetar o desempenho ou a disponibilidade.

No entanto, talvez você não queira transbordar tráfego. Aplicativos sensíveis à latência, por exemplo, podem não se beneficiar do estouro de tráfego para um back-end muito mais distante.

Use qualquer um dos métodos a seguir para evitar o estouro de tráfego:

• Use apenas gateways de cluster único que possam hospedar Serviços em apenas um cluster.

• Mesmo que esteja usando gateways de vários clusters, as réplicas de um aplicativo implantado em vários clusters poderão ser implantadas como Serviços separados. Da perspectiva do gateway, isso permite o balanceamento de carga de vários clusters, mas não agrega todos os endpoints de um Serviço entre clusters.

• Definir as capacidades do Serviço em um nível alto o suficiente para que a capacidade do tráfego nunca seja excedida de maneira realista, a menos que seja absolutamente necessário.

Balanceamento de carga em uma região

Em uma região, o tráfego é distribuído entre as zonas de acordo com as capacidades disponíveis dos back-ends. Não se trata de sobrecarga, mas sim balanceamento de carga em proporção direta com as capacidades do Serviço em cada zona. Qualquer fluxo ou sessão individual é sempre enviado para um único pod de back-end consistente e não é dividido.

O diagrama a seguir mostra como o tráfego é distribuído dentro de uma região:

No diagrama:

• Um serviço é implantado em um cluster regional do GKE. O serviço tem quatro pods implantados de maneira uniforme nas zonas. 3 pods estão na zona A, 1 pod está na zona B e 0 pods estão na zona C.
• O serviço é configurado com max-rate-per-endpoint="10". A zona A tem 30 RPS de capacidade total, a zona B tem 10 RPS de capacidade total, e a zona C tem 0 RPS de capacidade total, porque não tem pods.
• O gateway recebe um total de 16 RPS do tráfego de diferentes clientes. Esse tráfego é distribuído entre zonas de acordo com a capacidade restante de cada uma.
• O fluxo de tráfego de qualquer origem ou cliente tem uma carga balanceada consistentemente para um único pod de back-end de acordo com as configurações de persistência da sessão. A distribuição do tráfego é dividida em diferentes fluxos de tráfego de origem. Assim, os fluxos individuais nunca são divididos. Como resultado, é preciso ter uma quantidade mínima de diversidade de origem ou cliente para distribuir o tráfego de maneira granular entre os back-ends.

Por exemplo, se o tráfego de entrada aumentar de 16 para 60 para RPS, um dos seguintes cenários ocorrerá:

• Se estiver usando gateways de cluster único, não haverá outros clusters ou regiões para esse tráfego excedente. O tráfego continua sendo distribuído de acordo com as capacidades zonais relativas, mesmo que o tráfego de entrada exceda a capacidade total. Como resultado, a zona A recebe 45 RPS, e a zona B, 15 RPS.
• Se estiver usando gateways de vários clusters com serviços distribuídos em vários clusters, o tráfego poderá transbordar para outros clusters e outras regiões, conforme descrito em Balanceamento de carga global e estouro de tráfego. A zona A recebe 30 RPS, a zona B recebe 10 RPS, e 20 estouros de RPS transborda para outro cluster.

Observação: o Cloud Load Balancing não descartará automaticamente o tráfego quando os back-ends estiverem acima da capacidade. O tráfego estoura para qualquer back-end disponível que tenha capacidade. Se todos os back-ends estiverem acima da capacidade, o tráfego excedente será distribuído em todos os back-ends na proporção de suas capacidades totais. Isso excede a capacidade total do Serviço.

Balanceamento de carga dentro de uma zona

Depois que o tráfego é enviado a uma zona, ele é distribuído de maneira uniforme em todos os back-ends dentro dela. As sessões HTTP são permanentes, dependendo da configuração de afinidade da sessão. A menos que o back-end fique indisponível, as conexões TCP existentes nunca são movidas para outro back-end. Isso significa que conexões de longa duração continuam indo para o mesmo pod de back-end, mesmo que novas conexões excedam por causa da capacidade limitada. O balanceador de carga prioriza a manutenção de conexões existentes em vez de novas.

Capacidade do serviço

Com a capacidade do serviço, é possível definir um valor de solicitações por segundo (RPS, na sigla em inglês) por pod em um Serviço. Esse valor representa o RPS máximo por pod, em média, que um Serviço pode receber. Esse valor é configurável nos Serviços e é usado para determinar o escalonamento automático e o balanceamento de carga baseados em capacidade.

Requisitos

A capacidade de serviço tem os seguintes requisitos e limitações:

• Compatível apenas com os recursos GatewayClass e tipos de Entrada definidos no Suporte ao gerenciamento de tráfego.

• Essa mudança afeta o balanceamento de carga apenas se você estiver usando escalonamento automático baseado em tráfego ou gateways de vários clusters. Se você não estiver usando esses recursos, a capacidade do serviço não terá efeito no tráfego de rede.

Configurar a capacidade do serviço

Para configurar a capacidade do serviço, crie um usando a anotação networking.gke.io/max-rate-per-endpoint. O manifesto a seguir descreve um serviço com um RPS máximo:

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Substitua RATE_PER_SECOND pelo máximo de solicitações HTTP/HTTPS por segundo que um único pod neste Serviço deve receber.

O valor max-rate-per-endpoint cria uma capacidade dinâmica para um Serviço com base no número de pods no Serviço. O valor total da capacidade do serviço é calculado multiplicando-se o valor max-rate-per-endpoint pelo número de réplicas, conforme descrito na seguinte fórmula:

Total Service capacity = max-rate-per-endpoint * number of replicas

Se um escalonador automático aumentar o número de pods em um serviço, a capacidade total dele será calculada de acordo. Se um serviço for reduzido a zero pods, ele não terá capacidade e não receberá tráfego do balanceador de carga.

Observação: a configuração da capacidade do serviço usando a anotação max-rate-per-endpoint só se aplica ao tráfego que entra por meio de um gateway compatível. Ele não influencia o balanceamento de carga baseado em capacidade para balanceamento de carga ClusterIP dentro do cluster ou para serviços do tipo LoadBalancer.

Capacidade de serviço e NEGs independentes

A capacidade do serviço também pode ser configurada ao usar NEGs independentes. No entanto, ela não usa a anotação max-rate-per-endpoint. Ao usar NEGs independentes, o max-rate-per-endpoint é configurado manualmente ao adicionar o NEG a um recurso de serviço de back-end. Usando o comando gcloud compute backend-services add- backend, a sinalização --max-rate-per-endpoint pode configurar a capacidade para cada NEG individualmente.

Isso pode ser útil para qualquer um dos seguintes fluxos de trabalho:

• Ao implantar balanceadores de carga internos e externos manualmente usando NEGs independentes
• Ao implantar o Traffic Director no GKE usando NEGs independentes

Não há diferença funcional ao configurar a capacidade de serviço com NEGs independentes. Tanto o escalonamento automático quanto o transbordamento de tráfego são compatíveis.

Determine a capacidade do seu serviço

Para determinar o valor de max-rate-per-endpoint, é preciso entender as características de desempenho dos aplicativos e suas metas de balanceamento de carga. As estratégias a seguir podem ajudar a definir as características de desempenho do aplicativo:

• Observe o aplicativo nos ambientes de teste e produção quando configurado sem a capacidade do serviço.
• Use o Cloud Monitoring para criar uma correlação entre solicitações de tráfego e seus objetivos de nível de serviço (SLOs, na sigla em inglês) de desempenho.

• Use métricas do balanceador de carga, como https ou request_count, para mapear os níveis do RPS.

• Defina quais são os SLOs de desempenho para o aplicativo. Eles podem ser um ou mais dos seguintes, dependendo do que você considera um desempenho "ruim" ou "instável". É possível coletar todas as informações a seguir das métricas do balanceador de carga do Cloud Monitoring:
  • Códigos de erro de resposta
  • Latência total ou de resposta
  • Não integridade ou inatividade do back-end
• Observe o aplicativo sob carga de tráfego em ambientes de teste e produção. Em ambientes de teste, force o aplicativo sob um aumento de carga de solicitação para que você possa ver como as diferentes métricas de desempenho são afetadas à medida que o tráfego aumenta. Em ambientes de produção, observe os níveis de padrões de tráfego realistas.

Capacidade padrão de serviço

Todos os serviços anexados aos recursos do GKE têm uma capacidade de serviço padrão configurada, mesmo que não seja explicitamente configurada usando a anotação. Para saber mais, consulte Capacidade padrão de serviço.

A tabela a seguir descreve as capacidades padrão:

Tipo de recurso de balanceamento de carga	max-rate-per-endpoint padrão
Entrada (interna e externa)	1 RPS
Gateway (todos os GatewayClasses)	100.000.000 RPS
MultiClusterIngress	100.000.000 RPS

Escalonamento automático baseado em tráfego

O escalonamento automático baseado em tráfego é um recurso do GKE que integra nativamente sinais de tráfego de balanceadores de carga para escalonamento automático de pods. O escalonamento automático baseado em tráfego só é compatível com gateways de cluster único.

Para usar o escalonamento automático baseado em tráfego, consulte Escalonamento automático baseado no tráfego do balanceador de carga.

O escalonamento automático baseado em tráfego oferece os seguintes benefícios:

• Aplicativos que não são estritamente vinculados à CPU ou à memória podem ter limites de capacidade que não são refletidos no uso da CPU ou da memória.
• O tráfego ou as solicitações por segundo (RPS, na sigla em inglês) são uma métrica mais fácil de entender em alguns casos, porque estão mais alinhados com o uso do app e com métricas de negócios, como visualizações de página ou usuários ativos por dia (DAUs, na sigla em inglês).
• O tráfego é um indicador principal que representa a demanda instantânea em comparação com a CPU ou a memória que são indicadores de atraso.
• A combinação de métricas de CPU, memória e escalonamento automático de tráfego fornece uma maneira holística de aplicativos de escalonamento automático que usa várias dimensões para garantir que a capacidade seja provisionada adequadamente.

Veja no diagrama a seguir como o escalonamento automático baseado em tráfego funciona:

No diagrama:

• O proprietário do serviço configura a capacidade do serviço e uma meta de utilização para a implantação.
• O gateway recebe tráfego dos clientes que acessam o serviço store. O gateway envia a telemetria de utilização para o escalonador automático de pod do GKE. A utilização é igual ao tráfego real recebido por um pod individual dividido pela capacidade configurada do pod.
• O escalonador automático do pod do GKE faz o escalonamento vertical dos pods de acordo com a meta de utilização configurada.

Comportamento de escalonamento automático

O diagrama a seguir mostra como o escalonamento automático baseado em tráfego funciona em um aplicativo que recebe 10 RPS por meio do balanceador de carga:

No diagrama, o proprietário configurou a capacidade do serviço da loja para 10 RPS, o que significa que cada pod pode receber no máximo 10 RPS. O HorizontalPodAutoscaler está configurado com averageUtilization como definido como 70, o que significa que a utilização de destino é 70% de 10 RPS por pod.

O escalonador automático tenta escalonar réplicas para alcançar a seguinte equação:

replicas = ceiling[ current traffic / ( averageUtilization * max-rate-per-endpoint) ]

No diagrama, essa equação é calculada para:

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

10 RPS do tráfego resulta em duas réplicas. Cada réplica recebe 6 RPS, que está abaixo da meta de utilização de 7 RPS.

Observação: alterações nos níveis ou no pico de tráfego podem fazer com que o autoescalador se aproxime da equação das réplicas de destino. Em condições de estado estável, a quantidade de réplicas se aproxima do destino, mas nem sempre é exata, especialmente com tráfego flutuante.

Divisão de tráfego

A divisão de tráfego usa uma proporção explícita, chamada de peso, que define a proporção de solicitações HTTP enviadas para um Serviço. Os recursos HTTPRoute permitem que você configure pesos em uma lista de serviços. Os pesos relativas entre os serviços definem a divisão do tráfego entre eles. Isso é útil para dividir o tráfego durante lançamentos, alterações canárias ou emergências.

O diagrama a seguir descreve um exemplo de configuração de divisão de tráfego:

No diagrama:

• O proprietário do serviço configura dois serviços para uma única rota, com uma regra dividindo o tráfego em 90% para store-v1 e 10% em store-v2.
• O gateway recebe tráfego de clientes que vão para o URL do aplicativo da loja, e o tráfego é dividido de acordo com a regra configurada. 90% das rotas de tráfego para store-v1 e 10% para store-v2.

A divisão de tráfego é compatível entre serviços no mesmo cluster e também entre serviços em clusters diferentes:

• Divisão de tráfego entre serviços: usada para dividir o tráfego para lançamentos de versão de aplicativo. Usando o exemplo da divisão de tráfego, você teria duas implantações separadas, store-v1 e store-v2, cada com seu próprio serviço, store-v1 e store-v2. Os pesos são configurados entre os dois Serviços para alterar gradualmente o tráfego até que store-v2 seja totalmente implantado.

  Observação: o GatewayClass gke-l7-gxlb não é compatível com a divisão de tráfego.

• Divisão de tráfego entre ServiceImports: usada para transferir tráfego de ou para clusters específicos para manutenção, migração ou emergências. ServiceImports representam serviços de vários clusters e permitem a divisão de tráfego entre diferentes serviços em clusters distintos. O exercício Roteamento azul-verde com vários clusters usando o gateway demonstra a divisão do tráfego entre clusters.

  Observação: o GatewayClass gke-l7-gxlb-mc não é compatível com a divisão de tráfego.

Peso x capacidade

Os pesos e as capacidades controlam quanto tráfego é enviado para diferentes serviços. Embora tenham efeitos semelhantes, eles operam de forma diferente e têm casos de uso distintos. Eles podem e devem ser usados juntos, mas para diferentes fins.

Peso

O peso é um controle explícito do tráfego. Ele define as proporções exatas de tráfego, independentemente do tráfego de entrada e da utilização de back-ends. No exemplo de divisão de tráfego, se store-v2 ultrapassasse a capacidade ou se todas as réplicas falhassem, 10% do tráfego ainda seria alocado para store-v2, possivelmente causando queda no tráfego. Isso ocorre porque o peso não altera a proporção do tráfego com base na utilização ou na integridade.

O peso é mais adequado para os seguintes casos de uso:

• Mudança do tráfego entre diferentes versões de um serviço para lançamentos.
• Integração manual de serviços usando divisões de tráfego explícitas.
• Afastar o tráfego de um conjunto de back-ends para fins de emergência ou manutenção.

Capacidade

Capacidade é um controle implícito do tráfego. Ela define as proporções de tráfego indiretamente, já que elas dependem da quantidade de tráfego de entrada, da utilização de back-end e do local de origem do tráfego. A capacidade é uma propriedade inerente de um Serviço e normalmente é atualizada com muito menos frequência.

A capacidade é mais adequada para os seguintes casos de uso:

• Como evitar o uso excessivo do back-end durante picos de tráfego.
• Como controlar a taxa de escalonamento automático em relação ao tráfego.

Configurar a capacidade do serviço para estourar o tráfego nem sempre é um comportamento que você quer. Considere o exemplo de balanceamento de carga global. A capacidade do serviço protege os back-ends contra o uso excessivo ao transbordar o tráfego, mas isso pode resultar em latência extra para as solicitações que excederam o limite, já que essas solicitações estão indo para uma região mais remota.

Se o aplicativo não for muito sensível ao uso excessivo, configure uma capacidade de serviço muito alta para que o tráfego provavelmente não transborde para outra região. Se a disponibilidade ou latência do aplicativo for sensível ao uso excessivo, o excesso de tráfego para outros clusters ou regiões poderá ser melhor do que absorver o tráfego em excesso em back-ends sobrecarregados. Para saber mais sobre como configurar a capacidade do serviço para seu aplicativo, consulte Determinar a capacidade do serviço.

A seguir

• Saiba mais sobre Como implantar gateways.

• Saiba mais sobre Como implantar gateways de vários clusters.