Gestão de tráfego do gateway

Esta página explica como funciona a gestão de tráfego do gateway.

Esta página destina-se a programadores, operadores e especialistas em redes que querem implementar e gerir tráfego através da Gateway API.

Vista geral

A rede do Google Kubernetes Engine (GKE) baseia-se no Cloud Load Balancing. Com o Cloud Load Balancing, um único endereço IP anycast oferece gestão de tráfego global. A gestão de tráfego da Google oferece balanceamento de carga global e regional, escalabilidade automática e gestão de capacidade para fornecer uma distribuição de tráfego igualizada, estável e de baixa latência. Através do controlador do GKE Gateway, os utilizadores do GKE podem usar o controlo de gestão de tráfego global da Google de forma declarativa e nativa do Kubernetes.

Para experimentar a sobreposição de tráfego entre clusters, consulte o artigo Implementar o equilíbrio de carga baseado na capacidade. Para experimentar a escala automática baseada no tráfego, consulte o artigo Escala automática baseada no tráfego do equilibrador de carga.

Gestão de tráfego

O equilíbrio de carga, a escala automática e a gestão da capacidade são as bases de um sistema de gestão de tráfego. Funcionam em conjunto para igualizar e estabilizar a carga do sistema.

• O balanceamento de carga distribui o tráfego pelos pods de back-end de acordo com a localização, o estado e diferentes algoritmos de balanceamento de carga.
• A autoscaling dimensiona as réplicas da carga de trabalho para criar mais capacidade de absorver mais tráfego.
• A gestão da capacidade monitoriza a utilização dos serviços para que o tráfego possa transbordar para back-ends com capacidade, em vez de afetar a disponibilidade ou o desempenho da aplicação.

Estas capacidades podem ser combinadas de diferentes formas, consoante os seus objetivos. Por exemplo:

• Se quiser tirar partido das VMs do Spot de baixo custo, pode otimizar a distribuição uniforme do tráfego pelas VMs do Spot ao custo da latência. Com o equilíbrio de carga e a gestão da capacidade, o GKE transborda o tráfego entre regiões com base na capacidade, para que as VMs do Spot sejam totalmente utilizadas onde quer que estejam disponíveis.

• Se quiser otimizar a latência do utilizador à custa do aprovisionamento excessivo, pode implementar clusters do GKE em muitas regiões e aumentar a capacidade dinamicamente sempre que a carga aumentar. Usando o equilíbrio de carga e a escala automática, o GKE dimensiona automaticamente o número de pods quando o tráfego aumenta, para que o tráfego não tenha de transbordar para outras regiões. As regiões aumentariam a capacidade para poderem processar totalmente a carga o mais próximo possível dos utilizadores.

O diagrama seguinte mostra o balanceamento de carga, o dimensionamento automático e a gestão da capacidade a funcionar em conjunto:

No diagrama, a carga de trabalho no cluster gke-us falhou. O equilíbrio de carga e a verificação de funcionamento esgotam as ligações ativas e redirecionam o tráfego para o cluster mais próximo seguinte. A carga de trabalho em gke-asia recebe mais tráfego do que tem capacidade, pelo que reduz a carga para gke-eu. O gke-eu recebe mais carga do que o normal devido a eventos em gke-us e gke-asia e, por isso, o gke-eu é dimensionado automaticamente para aumentar a respetiva capacidade de tráfego.

Para saber como o Cloud Load Balancing processa a gestão de tráfego, consulte a secção sobre a gestão de capacidade global.

Capacidades de gestão de tráfego e extensões de serviços

Os recursos Gateway, HTTPRoute, Service e Policy fornecem os controlos para gerir o tráfego no GKE. O controlador do GKE Gateway é o plano de controlo que monitoriza estes recursos.

As extensões de serviço do GKE Gateway personalizam e expandem a gestão de tráfego no GKE. As extensões injetam lógica personalizada para o controlo avançado de tráfego.

As seguintes capacidades de gestão de tráfego estão disponíveis quando implementa serviços no GKE:

• Capacidade do serviço: a capacidade de especificar a quantidade de capacidade de tráfego que um serviço pode receber antes de os pods serem dimensionados automaticamente ou o tráfego transbordar para outros clusters disponíveis.
• Escala automática baseada no tráfego: escala automática de pods num serviço com base nos pedidos HTTP recebidos por segundo.
• Equilíbrio de carga em vários clusters: a capacidade de equilibrar a carga para os serviços alojados em vários clusters do GKE ou várias regiões.
• Divisão de tráfego: distribuição de tráfego explícita baseada em ponderação entre back-ends.

• Gestão de tráfego personalizada com extensões de serviços:

  As extensões de serviços permitem-lhe fazer o seguinte:

  • Modificar cabeçalhos e payloads para pedidos e respostas HTTP.
  • Implemente uma lógica de encaminhamento personalizada para controlar o fluxo de tráfego.
  • Integrar com serviços externos para funções como a autorização.

Apoio técnico de gestão de tráfego

As capacidades de gestão de tráfego disponíveis dependem da GatewayClass que implementa. Para ver uma lista completa do suporte de funcionalidades, consulte as capacidades da GatewayClass. A tabela seguinte resume o suporte da GatewayClass para a gestão de tráfego:

Gestão de tráfego com balanceamento de carga baseado em métricas personalizadas

Trusted Cloud by S3NS Os balanceadores de carga de aplicações distribuem o tráfego com base em métricas personalizadas. Estas métricas podem incluir a carga de utilização da GPU ou outros sinais de utilização específicos da aplicação. As métricas personalizadas oferecem uma vista mais precisa do desempenho da carga de trabalho. A sua aplicação comunica estas métricas através da norma de agregação de custos de pedidos abertos (ORCA). Para mais informações, consulte o artigo Métricas personalizadas para o Application Load Balancer.

No GKE, pode integrar esta capacidade de gestão de tráfego avançada através da API GKE Gateway. A API é útil para cargas de trabalho com utilização de recursos variável, como a inferência de IA generativa. Pode configurar um comportamento de tráfego personalizado configurando as seguintes políticas:

• GCPBackendPolicy para a seleção de back-ends: o recurso GCPBackendPolicy permite um controlo preciso sobre a forma como os serviços de back-end de um balanceador de carga distribuem o tráfego pelos respetivos back-ends. Esta política inclui campos específicos que lhe permitem configurar vários modos de equilíbrio de carga, como a utilização de métricas personalizadas. Para configurar a seleção do back-end com GCPBackendPolicy, consulte o artigo Configure a seleção do back-end usando a GCPBackendPolicy.

• GCPTrafficDistributionPolicy para o encaminhamento ao nível do ponto final: o elemento GCPTrafficDistributionPolicy configura o algoritmo de balanceamento de carga para a seleção de pontos finais num back-end. Quando seleciona WEIGHTED_ROUND_ROBIN, o balanceador de carga usa ponderações derivadas de métricas comunicadas (incluindo métricas personalizadas) para distribuir o tráfego por instâncias ou pontos finais individuais. Para configurar métricas ao nível do ponto final, consulte o artigo Configure o encaminhamento ao nível do ponto final com GCPTrafficDistributionPolicy.

Políticas baseadas na localização

Pode aplicar estas políticas baseadas na localização a Trusted Cloud by S3NS zonas ou regiões específicas através de um especificador de localização. Especificadores de localização úteis para implementações de teste beta, implementações faseadas ou testar alterações de políticas em regiões isoladas. Para mais informações, consulte o artigo Configure recursos de gateway através de políticas.

Monitorize métricas personalizadas para back-ends do GKE

Os balanceadores de carga de aplicações externos globais e os balanceadores de carga de aplicações internos oferecem capacidades de registo e monitorização que lhe permitem observar métricas personalizadas comunicadas pelos seus back-ends do GKE para estatísticas detalhadas do tráfego. Para mais informações, consulte o artigo Registo e monitorização do balanceador de carga de aplicações externo global.

Pode usar as etiquetas de métricas do GKE para consultar métricas personalizadas por serviço, cluster e espaço de nomes do GKE.

Para ver as métricas personalizadas comunicadas pelos seus back-ends do GKE, aceda ao Cloud Monitoring e veja as métricas personalizadas no network.googleapis.com/loadbalancer/backend/ recurso monitorizado. Pode usar etiquetas específicas do GKE para consultar e filtrar estas métricas.

As métricas disponíveis incluem:

• /error_rate: erros publicados por cada grupo de back-end por segundo.
• /custom_metrics: utilização atual por cada grupo de back-end, com base nas métricas personalizadas definidas.
• /fullness: a capacidade atual (carga ou capacidade) de cada grupo de back-end, que os balanceadores de carga usam para decisões de encaminhamento.
• /rate: pedidos recebidos por cada grupo de back-end por segundo.

As etiquetas específicas do GKE que melhoram a monitorização destas métricas incluem gke_service_name, gke_namespace e gke_cluster. Pode usar estas etiquetas para explorar dados de métricas por serviço, namespace e cluster do GKE. Tenha em atenção que estas etiquetas do GKE só são preenchidas se o valor de backend_type for ZONAL_NETWORK_ENDPOINT_GROUP.

A tabela seguinte lista as etiquetas específicas do GKE:

As entradas de registo dos balanceadores de carga de aplicações externos globais contêm informações úteis para monitorizar e depurar o seu tráfego HTTP(S).

Balanceamento de carga global, regional e zonal

A capacidade, a localização e o estado do serviço 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 pelo nível global para balanceadores de carga globais e pelo nível regional para balanceadores de carga regionais:

• Global: o tráfego é enviado para a região Trusted Cloud mais próxima do cliente que tenha back-ends em bom estado com capacidade. Desde que a região tenha capacidade, recebe todo o tráfego mais próximo. Se uma região não tiver capacidade, o tráfego em excesso transborda para a região mais próxima com capacidade. Para saber mais, consulte o artigo sobre o equilíbrio de carga global.
• Regional: o tráfego é enviado pelo balanceador de carga para uma região específica. O tráfego é equilibrado entre as zonas proporcionalmente à capacidade de publicação disponível da zona. Para saber mais, consulte o artigo sobre o equilíbrio de carga regional.
• Zonal: depois de o tráfego ser determinado para uma zona específica, o balanceador de carga distribui o tráfego uniformemente pelos back-ends nessa zona. As ligações TCP existentes e as definições de persistência da sessão são preservadas, para que os pedidos futuros sejam encaminhados para os mesmos back-ends, desde que o pod de back-end esteja em bom estado. Para saber mais, consulte o artigo sobre o balanceamento de carga zonal.

Balanceamento de carga global e overflow de tráfego

Para experimentar os seguintes conceitos no seu próprio cluster, consulte o artigo Equilíbrio de carga baseado na 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) da Google mais próximo do cliente e, em seguida, atravessa a rede principal da Google até chegar ao back-end mais próximo, conforme determinado pela latência da rede. Quando os back-ends numa região não têm capacidade restante, o tráfego transborda para o cluster mais próximo seguinte com back-ends em bom estado que têm capacidade. Se mais de 50% dos pods de back-end numa zona estiverem em mau estado, o tráfego é transferido gradualmente para outras zonas ou regiões, independentemente da capacidade configurada.

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

• Está a usar um gateway com vários clusters.
• Tem o mesmo serviço implementado em vários clusters, publicado pelo gateway de vários clusters.
• Tem capacidades de serviço configuradas de modo que o tráfego excede as capacidades de serviço num cluster, mas não noutros.

O diagrama seguinte 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 da Internet global para o serviço store. O serviço é implementado em dois clusters do GKE, um em us-west1 e outro em europe-west1. Cada cluster está a executar 2 réplicas.
• Cada serviço está 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 da Google na América do Norte recebem 6 RPS. Todo o tráfego é enviado para o backend em bom estado de funcionamento mais próximo com capacidade, o cluster do GKE em us-west1.
• Os PoPs europeus recebem 30 RPS cumulativos. Os backends mais próximos estão em europe-west1, mas só têm 20 RPS de capacidade. Uma vez que os backends em us-west1 têm capacidade excessiva, 10 RPS transbordam para us-west1, para que receba um total de 16 RPS e distribua 8 RPS a cada pod.

Evitar o excesso de tráfego

O excesso de tráfego ajuda a evitar exceder a capacidade da aplicação, o que pode afetar o desempenho ou a disponibilidade.

No entanto, pode não querer ter um excesso de tráfego. As aplicações sensíveis à latência, por exemplo, podem não beneficiar do excesso de tráfego para um back-end muito mais distante.

Pode usar qualquer um dos seguintes métodos para evitar o excesso de tráfego:

• Use apenas gateways de cluster único que possam alojar serviços num único cluster.

• Mesmo que use gateways de vários clusters, as réplicas de uma aplicação implementada em vários clusters podem ser implementadas como serviços separados. Do ponto de vista da gateway, isto permite o equilíbrio de carga em vários clusters, mas não agrega todos os pontos finais de um serviço entre clusters.

• Defina as capacidades de serviço a um nível suficientemente elevado para que a capacidade de tráfego nunca seja excedida de forma realista, a menos que seja absolutamente necessário.

Balanceamento de carga numa região

Numa região, o tráfego é distribuído pelas zonas de acordo com as capacidades disponíveis dos back-ends. Isto não usa o excesso, mas sim o equilíbrio de carga em proporção direta às capacidades do serviço em cada zona. Qualquer fluxo ou sessão individual é sempre enviado para um pod de back-end único e consistente e não é dividido.

O diagrama seguinte mostra como o tráfego é distribuído numa região:

No diagrama:

• Um serviço é implementado num cluster do GKE regional. O serviço tem 4 pods que são implementados de forma desigual 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 está configurado com maxRatePerEndpoint=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 de tráfego de diferentes clientes. Este tráfego é distribuído pelas zonas proporcionalmente à capacidade restante em cada zona.
• O fluxo de tráfego de qualquer origem ou cliente individual é sempre equilibrado para um único pod de back-end de acordo com as definições de persistência de sessão. A distribuição de divisões de tráfego em diferentes fluxos de tráfego de origem, para que nenhum fluxo individual seja dividido. Como resultado, é necessário um valor mínimo de diversidade de origens ou clientes para distribuir detalhadamente o tráfego pelos back-ends.

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

• Se usar gateways de cluster único, não existem outros clusters nem regiões para onde este tráfego possa transbordar. O tráfego continua a ser 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 recebe 15 RPS.
• Se usar gateways de vários clusters com serviços distribuídos por vários clusters, o tráfego pode transbordar para outros clusters e outras regiões, conforme descrito em Equilíbrio de carga global e transbordo de tráfego. A zona A recebe 30 RPS, a zona B recebe 10 RPS e 20 RPS transbordam para outro cluster.

Balanceamento de carga numa zona

Assim que o tráfego é enviado para uma zona, é distribuído uniformemente por todos os servidores de back-end nessa zona. As sessões HTTP são persistentes consoante a definição de afinidade da sessão. A menos que o back-end fique indisponível, as ligações TCP existentes nunca são movidas para um back-end diferente. Isto significa que as ligações de longa duração continuam a ser encaminhadas para o mesmo pod de back-end, mesmo que as novas ligações excedam o limite devido à capacidade limitada. O balanceador de carga dá prioridade à manutenção das ligações existentes em detrimento das novas.

Capacidade de serviço

Com a capacidade do serviço, pode definir um valor de pedidos por segundo (RPS) por agrupamento num serviço. Este valor representa o RPS máximo por agrupamento, em média, que um serviço pode receber. Este valor é configurável nos serviços e é usado para determinar a escala automática baseada no tráfego e o equilíbrio de carga baseado na capacidade.

Requisitos

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

• Apenas suportado com os recursos GatewayClass e os tipos de entrada definidos no Suporte de gestão de tráfego.
• Só afeta o equilíbrio de carga se estiver a usar o dimensionamento automático baseado no tráfego ou gateways de vários clusters. Se não estiver a usar estas capacidades, a capacidade do serviço não tem qualquer efeito no tráfego de rede.

Configure a capacidade do serviço

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: RATE_PER_SECOND
  targetRef:
    group: ""
    kind: Service
    name: store

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 número máximo de pedidos HTTP/HTTPS por segundo que um único agrupamento neste serviço deve receber.

O valor maxRatePerEndpoint 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 o valor maxRatePerEndpoint pelo número de réplicas, conforme descrito na seguinte fórmula:

Total Service capacity = maxRatePerEndpoint * number of replicas

Se um escalador automático aumentar o número de pods num serviço, a capacidade total do serviço é calculada em conformidade. Se um serviço for reduzido para zero pods, tem capacidade zero e não recebe tráfego do equilibrador de carga.

Capacidade de serviço e NEGs autónomos

Também é possível configurar a capacidade do serviço quando usa NEGs autónomos. No entanto, não usa a definição maxRatePerEndpoint. Quando usa NEGs autónomos, o maxRatePerEndpoint é configurado manualmente quando adiciona o NEG a um recurso Backend Service. Usando o comando gcloud compute backend-services add-backend, a flag --max-rate-per-endpoint pode configurar a capacidade para cada NEG individualmente.

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

• Quando implementa balanceadores de carga internos e externos manualmente através de NEGs autónomos
• Quando implementa o Cloud Service Mesh no GKE com NEGs autónomos

Não existe diferença funcional quando configura a capacidade do serviço com NEGs autónomos. São suportados o dimensionamento automático e o transbordo de tráfego.

Determine a capacidade do seu serviço

A determinação do valor para maxRatePerEndpoint requer a compreensão das caraterísticas de desempenho das suas aplicações e dos seus objetivos de equilíbrio de carga. As seguintes estratégias podem ajudar a definir as caraterísticas de desempenho das suas aplicações:

• Observe a sua aplicação em ambientes de teste e de produção quando configurada sem capacidade de serviço.

• Use o Cloud Monitoring para criar uma correlação entre os pedidos de tráfego e os objetivos ao nível do serviço (SLOs) de desempenho.

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

• Defina os SLOs de desempenho da sua aplicação. Podem ser um ou mais dos seguintes, consoante o que considerar um desempenho "mau" ou "instável". É possível recolher todas as seguintes informações a partir das métricas do equilibrador de carga do Cloud Monitoring:

  • Códigos de erro de resposta
  • Tempo de resposta ou latência total
  • Mau estado de funcionamento ou tempo de inatividade do back-end

• Observe a sua aplicação sob carga de tráfego em ambientes de teste e de produção. Em ambientes de teste, teste a sua aplicação sob uma carga de pedidos crescente para poder ver o impacto nas diferentes métricas de desempenho à medida que o tráfego aumenta. Em ambientes de produção, observe níveis de padrões de tráfego realistas.

Capacidade do serviço predefinido

Todos os serviços anexados a recursos do GKE têm uma capacidade de serviço predefinida configurada, mesmo que não esteja configurada explicitamente. Para saber mais, consulte o artigo Capacidade de serviço predefinida.

A tabela seguinte descreve as capacidades predefinidas:

Escala automática com base no tráfego

A escala automática baseada no tráfego é uma capacidade do GKE que integra nativamente sinais de tráfego de equilibradores de carga para criar uma escala automática de pods. O ajuste de escala automático baseado no tráfego só é suportado para gateways de cluster único.

Para usar a escala automática baseada no tráfego, consulte o artigo Escala automática baseada no tráfego do equilibrador de carga.

O dimensionamento automático com base no tráfego oferece as seguintes vantagens:

• As aplicações que não estão estritamente limitadas pela CPU ou pela memória podem ter limites de capacidade que não se refletem na respetiva utilização da CPU ou da memória.
• O tráfego ou os pedidos por segundo (RPS) são uma métrica mais fácil de compreender em alguns casos, porque estão mais alinhados com a utilização da app e as métricas empresariais, como as visualizações de páginas ou os utilizadores ativos diariamente (UAD).
• O tráfego é um indicador principal que representa a procura instantânea em comparação com a CPU ou a memória, que são indicadores atrasados.
• A combinação de métricas de escalamento automático de CPU, memória e tráfego oferece uma forma holística de criar uma escala automática de aplicações que usa várias dimensões para garantir que a capacidade é aprovisionada adequadamente.

O diagrama seguinte demonstra como funciona o ajuste de escala automático baseado no tráfego:

No diagrama:

• O proprietário do serviço configura a capacidade do serviço e uma utilização alvo para a implementação.
• O gateway recebe tráfego de clientes que acedem ao serviço store. O gateway envia telemetria de utilização para o GKE Pod Autoscaler. A utilização é igual ao tráfego real recebido por um pod individual dividido pela capacidade configurada do pod.
• O redimensionador automático de pods do GKE aumenta ou diminui a escala dos pods de acordo com a utilização alvo configurada.

Comportamento da escala automática

O diagrama seguinte mostra como o dimensionamento automático baseado no tráfego funciona numa aplicação que recebe 10 RPS através do equilibrador de carga:

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

O escalador automático tenta dimensionar as réplicas para alcançar a seguinte equação:

replicas = ceiling[ current traffic / ( averageValue * maxRatePerEndpoint) ]

No diagrama, esta equação resulta em:

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

10 RPS de tráfego resultam em 2 réplicas. Cada réplica recebe 5 RPS, o que está abaixo da utilização alvo de 7 RPS.

Divisão de tráfego

A divisão de tráfego usa uma proporção explícita, denominada ponderação, que define a proporção de pedidos HTTP enviados para um serviço. Os recursos HTTPRoute permitem-lhe configurar ponderações numa lista de serviços. As ponderações relativas entre os serviços definem a divisão do tráfego entre eles. Isto é útil para dividir o tráfego durante implementações, testes canary ou em caso de emergência.

O diagrama seguinte descreve uma configuração de divisão de tráfego de exemplo:

No diagrama:

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

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

• Divisão do tráfego entre serviços: usada para dividir o tráfego para implementações de versões de aplicações. Usando o exemplo de divisão de tráfego, teria duas implementações separadas, store-v1 e store-v2, que têm cada uma o seu próprio serviço, store-v1 e store-v2. Os pesos são configurados entre os dois serviços para mudar gradualmente o tráfego até que o store-v2 seja implementado na totalidade.

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

Peso vs. capacidade

Os pesos e as capacidades controlam a quantidade de tráfego enviado para diferentes serviços. Embora tenham efeitos semelhantes, funcionam de forma diferente e têm exemplos de utilização diferentes. Podem e devem ser usados em conjunto, embora para fins diferentes.

Peso

O peso é um controlo explícito do tráfego. Define as proporções exatas do tráfego, independentemente do tráfego recebido e da utilização do back-end. No exemplo de divisão de tráfego, se store-v2 estivesse acima da capacidade ou se todas as respetivas réplicas falhassem, 10% do tráfego continuaria a ser atribuído a store-v2, o que poderia fazer com que o tráfego fosse ignorado. Isto deve-se ao facto de o peso não alterar a proporção do tráfego com base na utilização ou no estado.

O peso é mais adequado para os seguintes exemplos de utilização:

• Transferir tráfego entre diferentes versões de um serviço para implementações.
• Incorporação manual de serviços através de divisões de tráfego explícitas.
• Desviar o tráfego de um conjunto de back-ends para fins de emergência ou manutenção.

Capacidade

A capacidade é um controlo implícito do tráfego. Define as proporções do tráfego indiretamente, uma vez que dependem da quantidade de tráfego recebido, da utilização do back-end e da localização 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 exemplos de utilização:

• Impedir a utilização excessiva do back-end durante picos de tráfego.
• Controlar a taxa de escala automática relativamente ao tráfego.

A configuração da capacidade do serviço para o tráfego de overflow pode nem sempre ser um comportamento desejado. Considere o exemplo de balanceamento de carga global. A capacidade do serviço protege os back-ends da utilização excessiva devido ao excesso de tráfego, mas isto pode resultar numa latência adicional para os pedidos que excederam o limite, uma vez que esses pedidos estão a viajar para uma região mais remota.

Se a sua aplicação não for muito sensível à utilização excessiva, recomendamos que configure uma capacidade de serviço muito elevada para que seja improvável que o tráfego transborde para outra região. Se a disponibilidade ou a latência da sua aplicação for sensível à utilização excessiva, o transbordo de tráfego para outros clusters ou regiões pode ser melhor do que absorver o tráfego excessivo em back-ends sobreutilizados. Para saber como configurar a capacidade do serviço para a sua aplicação, consulte o artigo Determine a capacidade do seu serviço.

O que se segue?

• Saiba mais sobre a Implementação de gateways.
• Saiba como implementar gateways de vários clusters.