Você aprenderá a usar o gerenciamento de tráfego em alguns casos específicos. Muitos outros casos de uso são possíveis.
O documento contém exemplos para os seguintes balanceadores de carga:
- Balanceador de carga de aplicativo externo regional
- Balanceador de carga de aplicativo interno regional
- Balanceador de carga de aplicativo interno entre regiões
Balanceador de carga de aplicativo externo regional comparado com o balanceador de carga de aplicativo interno regional. Para a configuração de gerenciamento de tráfego dos balanceadores de carga regionais, a documentação da API de mapa de URL regional e da API de serviço de back-end regional fornece uma lista completa de campos, incluindo semântica relacionada a relacionamentos, restrições e cardinalidade.
A única diferença entre esses dois balanceadores de carga é o esquema de balanceamento de carga, da seguinte maneira:
- Os balanceadores de carga de aplicativo externos regionais usam
EXTERNAL_MANAGED
. - Os balanceadores de carga de aplicativo internos regionais usam
INTERNAL_MANAGED
.
Balanceador de carga de aplicativo interno regional em comparação com o balanceador de carga de aplicativo interno regional entre regiões. Para a configuração de gerenciamento de tráfego:
Os balanceadores de carga de aplicativo internos regionais usam a API de mapa de URL regional , e a documentação da API de serviço de back-end regional fornece uma lista completa de campos, incluindo semântica relacionada a relacionamentos, restrições e cardinalidade.
Os balanceadores de carga internos de aplicativo entre regiões usam a API de mapa de URL global , e a documentação da API do serviço de back-end global fornece uma lista completa de campos, incluindo semântica relacionada a relacionamentos, restrições e cardinalidade.
Além dos recursos avançados de roteamento descritos nesta página, alguns balanceadores de carga de aplicativo se integram às extensões de serviço para permitir injetar lógica personalizada no caminho de dados de balanceamento de carga ao configurar frases de destaque de extensões de serviço.
Antes de começar
Entenda como o gerenciamento de tráfego funciona. Para mais informações, leia Conceitos do gerenciamento de tráfego.
Siga as instruções em Configurar um balanceador de carga de aplicativo interno e configure os hosts de VM ou clusters do GKE necessários.
Crie a verificação de integridade necessária ou reutilize uma que já exista, como descrito em Como configurar o balanceador de carga.
Configurar o gerenciamento de tráfego
No ambiente de configuração escolhido, defina o gerenciamento de tráfego por meio de configurações YAML. Um mapa de URL e um serviço de back-end têm seus próprios arquivos YAML. Dependendo da funcionalidade pretendida, você precisa gravar um arquivo YAML de mapa de URL, de serviço de back-end ou ambos.
Se precisar de ajuda para gravar esses arquivos YAML, use os exemplos nesta página e a documentação da API Cloud Load Balancing.
No caso do balanceador de carga de aplicativo interno regional, também é possível usar o console do Google Cloud para configurar o gerenciamento de tráfego.Para balanceadores de carga de aplicativo regionais internos e externos, a documentação da API de mapa de URL regional e da API de serviço de back-end regional fornece uma lista completa de campos, incluindo semântica relacionada a relacionamentos, restrições e cardinalidade.
Acessar os exemplos de YAML no Console do Google Cloud
Para acessar exemplos de YAML no Console do Google Cloud:
No Console do Google Cloud, acesse a página Balanceamento de carga.
- Clique em Criar balanceador de carga.
- Conclua as etapas do assistente para criar um balanceador de carga de aplicativo regional interno.
- Na configuração Regras de roteamento, selecione Regra avançada de host, caminho e rota.
- Clique em Adicionar hosts e correspondência de caminho.
- Clique no link Orientação de código.
A página Exemplos YAML de correspondência de caminho será exibida.
Mapear o tráfego para um único serviço
Envie todo o tráfego para um serviço. Lembre-se de substituir os marcadores de posição.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
Dividir o tráfego entre dois serviços
Divida o tráfego entre dois ou entre vários serviços. Lembre-se de substituir os marcadores de posição:
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
weight: 5
Configurar um redirecionamento de URL
O exemplo a seguir retorna um código de resposta 3xx configurável. Ele também
define o cabeçalho de resposta Location
com o URI apropriado. O host e o caminho
são substituídos conforme especificado na ação de redirecionamento.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
urlRedirect:
hostRedirect: "new-host-name.com" # Omit to keep the requested host
pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
redirectResponseCode: FOUND
stripQuery: True
Espelhar tráfego
Além de encaminhar a solicitação ao serviço de back-end selecionado, envie uma solicitação idêntica ao serviço de back-end do espelhamento configurado em uma base atire e esqueça. O balanceador de carga não espera por uma resposta do back-end a que envia a solicitação espelhada. O espelhamento é útil para testar uma nova versão de um serviço de back-end. Ele pode ser usado também para depurar erros de produção em uma versão de depuração do serviço de back-end, mas não na versão de produção.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
Reescrever o URL solicitado
Regrave a parte do nome do host do URL, a parte do caminho do URL ou ambos antes de enviar uma solicitação para o serviço de back-end selecionado. Lembre-se de substituir os marcadores de posição.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
urlRewrite:
hostRewrite: "new-host-name.com" # Omit to keep the requested host
pathPrefixRewrite: "/new-path/" # Omit to keep the requested path
Repetir uma solicitação
Configure as condições em que o balanceador de carga tenta repetir as solicitações com falha, quanto tempo o balanceador de carga aguarda antes de tentar novamente e o número máximo de novas tentativas permitidas.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
Especificar o tempo limite da rota
Especifique o tempo limite da rota selecionada. O tempo limite é calculado a partir do momento do processamento total da solicitação e da resposta. O tempo limite inclui todas as novas tentativas. Lembre-se de substituir os marcadores de posição.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 500000000
Configurar injeção de falhas
Apresente erros ao atender às solicitações de serviço para simular falhas, incluindo alta latência, sobrecarga de serviço, falhas de serviço e particionamento de rede. Esse recurso é útil para testar a resiliência de um serviço a falhas simuladas.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 500000000
percentage: 25
abort:
httpStatus: 503
percentage: 50
Configurar o CORS
Configure políticas de Compartilhamento de recursos entre origens (CORS) para gerenciar as configurações de aplicação de solicitações CORS.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: my-domain.com
allowMethods: GET, POST
allowHeaders: Authorization, Content-Type
maxAge: 1200
allowCredentials: True
Adicionar e remover cabeçalhos de solicitação e resposta
Adicione e remova cabeçalhos da solicitação antes de enviar uma solicitação ao serviço de back-end. Além disso, adicione e remova cabeçalhos de resposta depois de receber uma resposta do serviço de back-end.
Os balanceadores de carga regionais e internos de aplicativos também são compatíveis com o uso de variáveis em cabeçalhos personalizados. É possível especificar uma ou mais variáveis nos campos do valor do cabeçalho personalizado (headerValue
) que serão convertidos nos valores correspondentes por solicitação. Para ver uma lista de valores de cabeçalho compatíveis, consulte
Criar cabeçalhos personalizados em mapas
de URLs.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
headerAction:
requestHeadersToAdd:
- headerName: header-1-name
headerValue: header-1-value
replace: True
requestHeadersToRemove:
- header-2-name
- header-3-name
responseHeadersToAdd:
- headerName: header-4-name
headerValue: header-4-value
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
Configurar detecção de outlier
Especifique os critérios para remoção de VMs ou endpoints de back-end não íntegros em NEGs, com critérios que definem quando um back-end ou endpoint é considerado íntegro o suficiente para receber tráfego novamente. Lembre-se de substituir os marcadores de posição.
loadBalancingScheme: LOAD_BALANCING_SCHEME
localityLbPolicy: RANDOM
name: regions/REGION/backendServices/BACKEND_SERVICE_1
outlierDetection:
baseEjectionTime:
nanos: 0
seconds: '30'
consecutiveErrors: 5
consecutiveGatewayFailure: 3
enforcingConsecutiveErrors: 2
enforcingConsecutiveGatewayFailure: 100
enforcingSuccessRate: 100
interval:
nanos: 0
seconds: '1'
maxEjectionPercent: 50
successRateMinimumHosts: 5
successRateRequestVolume: 100
successRateStdevFactor: 1900
region: region/REGION
Configurar quebra de circuito
A quebra de circuito permite definir limites de falha para impedir que as solicitações do cliente sobrecarreguem os back-ends. Depois que as solicitações atingirem um limite definido, o balanceador de carga deixará de permitir novas conexões ou de enviar solicitações adicionais, permitindo que os back-ends se recuperem. Assim, a quebra de circuito evita falhas em cascata retornando um erro ao cliente em vez de sobrecarregar um back-end. Isso permite que pouco tráfego seja vinculado enquanto fornece tempo para gerenciar a situação de sobrecarga, como lidar com um pico de tráfego aumentando a capacidade com escalonamento automático.
Defina limites superiores em solicitações por conexão, bem como o volume de conexões com um serviço de back-end. Além disso, limite o número de solicitações pendentes e novas tentativas.
loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
localityLbPolicy: RANDOM
affinityCookieTtlSec: 0
backends:
- balancingMode: UTILIZATION
capacityScaler: 1.0
group: region/REGION/instanceGroups/INSTANCE_GROUP
maxUtilization: 0.8
circuitBreakers:
maxConnections: 1000
maxPendingRequests: 200
maxRequests: 1000
maxRequestsPerConnection: 100
maxRetries: 3
connectionDraining:
drainingTimeoutSec: 0
healthChecks:
- region/REGION/healthChecks/HEALTH_CHECK
Configurar a divisão de tráfego: etapas detalhadas
Neste exemplo, demonstramos as seguintes etapas:
Criar modelos distintos para diferentes serviços.
Criar grupos de instâncias para esses modelos.
Criar regras de roteamento que configurem a divisão de tráfego em 95% e 5%.
Enviar comandos curl, mostrando que as porcentagens de divisão de tráfego correspondem aproximadamente à configuração.
Os pressupostos destas instruções são os seguintes:
- A região é
us-west1
. Um proxy de destino e uma regra de encaminhamento foram criados, junto com um mapa de URLs chamado
regional-lb-map
.O mapa de URLs envia todo o tráfego para um serviço de back-end, chamado
red-service
, que é o serviço padrão.Você configura um caminho alternativo que envia 5% do tráfego para
blue-service
e 95% do tráfego paragreen-service
.É usada uma correspondência de caminho.
Você está usando o Cloud Shell ou outro ambiente com o bash instalado.
Definir os serviços
A função bash a seguir cria um serviço de back-end, incluindo o modelo da instância e o grupo de instâncias gerenciadas.
Estas instruções pressupõem que uma verificação de integridade de HTTP (regional-lb-basic-check
) foi
criada. Para mais instruções, consulte Configurar um balanceador de carga interno de aplicativo.
function make_service() { local name="$1" local region="$2" local zone="$3" local network="$4" local subnet="$5" local subdir="$6" www_dir="/var/www/html/$subdir" (set -x; \ gcloud compute instance-templates create "${name}-template" \ --region="$region" \ --network="$network" \ --subnet="$subnet" \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-10 \ --image-project=debian-cloud \ --metadata=startup-script="#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl sudo mkdir -p $www_dir /bin/hostname | sudo tee ${www_dir}index.html systemctl restart apache2"; \ gcloud compute instance-groups managed create \ "${name}-instance-group" \ --zone="$zone" \ --size=2 \ --template="${name}-template"; \ gcloud compute backend-services create "${name}-service" \ --load-balancing-scheme=LOAD_BALANCING_SCHEME\ --protocol=HTTP \ --health-checks=regional-lb-basic-check \ --health-checks-region="$region" \ --region="$region"; \ gcloud compute backend-services add-backend "${name}-service" \ --balancing-mode='UTILIZATION' \ --instance-group="${name}-instance-group" \ --instance-group-zone="$zone" \ --region="$region") }
Criar os serviços
Chame a função para criar três serviços: red
, green
e blue
. O
serviço red
funciona como o serviço padrão das solicitações para /
. Os serviços green
e
blue
estão configurados em /PREFIX
para lidar com 95% e 5% do tráfego, respectivamente.
make_service red us-west1 us-west1-a lb-network backend-subnet "" make_service green us-west1 us-west1-a lb-network backend-subnet /PREFIX make_service blue us-west1 us-west1-a lb-network backend-subnet /PREFIX
Criar o mapa de URL
gcloud
Exporte o mapa de URLs atual usando o comando
gcloud compute url-maps export
:gcloud compute url-maps export regional-lb-map \ --destination=regional-lb-map-config.yaml \ --region=us-west1
Atualize o arquivo do mapa de URLs
regional-lb-map-config.yaml
adicionando-o ao fim do arquivo:hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: regions/us-west1/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: regions/us-west1/backendServices/green-service weight: 95 - backendService: regions/us-west1/backendServices/blue-service weight: 5
Atualize o mapa de URLs usando o comando
gcloud compute url-maps import
:gcloud compute url-maps import regional-lb-map \ --region=us-west1 \ --source=regional-lb-map-config.yaml
Testar a configuração
Para testar a configuração, primeiro verifique se as solicitações para o
endereço IP do balanceador de carga configurado anteriormente, são operadas pela configuração red
padrão.
Verifique se as solicitações enviadas para
FORWARDING_RULE_IP_ADDRESS/PREFIX
são divididas conforme o esperado.
Criar uma VM cliente
Para mais instruções, consulte Como criar uma instância de VM na zona para testar a conectividade.
Enviar solicitações para FORWARDING_RULE_IP_ADDRESS
Use
ssh
para se conectar ao cliente.gcloud compute ssh global-lb-client-us-west1-a \ --zone=us-west1-a
Execute este comando:
for LB_IP in FORWARDING_RULE_IP_ADDRESS; do RESULTS= for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1 IFS=':' echo "***" echo "*** Results of load balancing to $LB_IP: " echo "***" for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c echo done
Verificar os resultados
*** ***Results of load balancing to FORWARDING_RULE_IP_ADDRESS: *** 502 red-instance-group-9jvq 498 red-instance-group-sww8
Enviar solicitações para FORWARDING_RULE_IP_ADDRESS/PREFIX
Envie solicitações para FORWARDING_RULE_IP_ADDRESS/PREFIX
e
observe a divisão de tráfego.
for LB_IP in FORWARDING_RULE_IP_ADDRESS; do RESULTS= for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1 IFS=':' echo "***" echo "*** Results of load balancing to $LB_IP/PREFIX: " echo "***" for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c echo done
Verificar os resultados
*** ***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX: *** 21 blue-instance-group-8n49 27 blue-instance-group-vlqc 476 green-instance-group-c0wv 476 green-instance-group-rmf4
A configuração canário envia 95% de solicitações /PREFIX
para
o serviço green
e 5% para o serviço blue
.
Configurar a afinidade de sessão com base em HTTP_COOKIE
É possível usar o controle de tráfego para configurar a afinidade de sessão com base em um cookie. Para configurar a afinidade da sessão com base em HTTP_COOKIE para um serviço de back-end
denominado red-service
, siga estas instruções.
Use o comando
gcloud compute backend-services export
para acessar a configuração do serviço de back-end.gcloud compute backend-services export red-service \ --destination=red-service-config.yaml \ --region=us-west1
Atualize o arquivo
red-service-config.yaml
da seguinte forma:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 500000000 minimumRingSize: 10000
No arquivo
red-service-config.yaml
, exclua a seguinte linha:sessionAffinity: NONE
Atualize o arquivo de configuração do serviço de back-end:
gcloud compute backend-services import red-service \ --source=red-service-config.yaml \ --region=us-west1
Como solucionar problemas
Use estas informações para solucionar problemas quando o tráfego não estiver sendo encaminhado de acordo com as regras de roteamento e as políticas de tráfego que você tiver configurado.
Para saber informações sobre geração de registros e monitoramento, consulte Geração de registro e monitoramento de HTTP(S) interno.Sintomas:
- Aumento do tráfego para serviços em regras acima da regra em questão.
- Aumento inesperado nas respostas HTTP 4xx e 5xx para uma determinada regra de rota.
Solução: verifique a ordem das suas regras de rota. As regras de rota são interpretadas na ordem em que são especificadas.
As regras de rota em um mapa de URLs são interpretadas na ordem em que são especificadas. Isso é diferente de como as regras de caminho são interpretadas pela correspondência de prefixo mais longa. Para uma regra de caminho, os balanceadores de carga de aplicativo internos selecionarão somente uma regra de caminho. No entanto, mais de uma opção pode ser aplicada quando você usa regras de rota.
Ao definir regras de rota, verifique se as regras na parte superior da lista não encaminham inadvertidamente o tráfego que, de outra forma, seria roteado por outra regra de rota. O serviço que recebe tráfego direcionado incorretamente provavelmente rejeitará as solicitações, e o serviço nas regras de rota receberá tráfego reduzido ou nenhum tráfego.