Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Criar um balanceador de carga externo baseado em serviço de back-end

Autopilot Standard

Nesta página, mostramos como implantar um Serviço LoadBalancer externo que cria um balanceador de carga de rede de passagem externo baseado em serviço de back-end. Antes de ler esta página, confira se você conhece os seguintes conceitos:

Para saber mais sobre balanceadores de carga de rede de passagem externa em geral, consulte Balanceador de carga de rede de passagem externa baseado em serviço de back-end.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
Observação:em instalações prévias da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Requisitos

Este tutorial usa o spec.loadBalancerClass para criar um balanceador de carga de rede de passagem externa baseado em serviço de back-end com back-ends de NEG GCE_VM_IP. Este tutorial requer o GKE versão 1.33.1-gke.1779000 ou mais recente porque o spec.loadBalancerClass exige o GKE versão 1.33.1-gke.1779000 ou mais recente. A versão 1.33.1-gke.1779000 ou mais recente também excede os requisitos mínimos de versão do GKE para back-ends de NEG ou o recurso de balanceador de carga ponderado.
Se o cluster estiver em uma versão anterior à 1.36, o complemento HttpLoadBalancing precisa ser ativado. Esse complemento é ativado por padrão. Para mais informações, consulte Pré-requisito do balanceamento de carga HTTP.
Para ativar o Cloud Logging em um serviço LoadBalancer externo, seu cluster do GKE precisa usar a versão 1.36.0-gke.2459000 ou mais recente.

Escolher um cluster

É possível criar um cluster ou escolher um que atenda aos requisitos.

Criar um novo cluster

Piloto automático

Para criar um cluster do Autopilot:

gcloud container clusters create-auto CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Substitua:

CLUSTER_NAME: o nome do novo cluster;
RELEASE_CHANNEL: o nome do canal de lançamento do GKE para o cluster.
VERSION: a versão do GKE do cluster.
COMPUTE_LOCATION: a região do Compute Engine do cluster.

Para desativar a criação automática de regras de firewall da VPC para serviços de LoadBalancer, inclua a flag --disable-l4-lb-firewall-reconciliation. Para mais informações, consulte Regras de firewall gerenciadas pelo usuário para serviços do LoadBalancer do GKE.

Padrão

Para criar um cluster padrão:

gcloud container clusters create CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Substitua:

CLUSTER_NAME: o nome do novo cluster;
RELEASE_CHANNEL: o nome do canal de lançamento do GKE para o cluster.
VERSION: a versão do GKE do cluster.
COMPUTE_LOCATION: a região do Compute Engine do cluster.

Fazer upgrade de um cluster atual

Use a CLI gcloud para atualizar um cluster:

gcloud container clusters upgrade CLUSTER_NAME \
    --cluster-version=VERSION \
    --master \
    --location=COMPUTE_LOCATION

Substitua:

CLUSTER_NAME: o nome do cluster existente.
VERSION: a versão específica do GKE para a qual você quer fazer upgrade do cluster. Para mais informações, consulte Como fazer upgrade manual do plano de controle.
COMPUTE_LOCATION: a região do Compute Engine do cluster.

implante uma carga de trabalho de amostra

Implante a seguinte carga de trabalho de exemplo, que fornece os pods de serviço para o serviço LoadBalancer externo.

Salve a seguinte implantação de amostra como store-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: store
spec:
  replicas: 20
  selector:
    matchLabels:
      app: store
  template:
    metadata:
      labels:
        app: store
    spec:
      containers:
      - image: registry.k8s.io/echoserver:1.10
        imagePullPolicy: Always
        name: echoserver
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP

Aplique o manifesto ao cluster:
```
kubectl apply -f store-deployment.yaml
```

Verifique se há 20 pods de exibição para a implantação:

kubectl get pods

O resultado será o seguinte:

NAME                     READY   STATUS    RESTARTS   AGE
store-cdb9bb4d6-s25vw      1/1     Running   0          10s
store-cdb9bb4d6-vck6s      1/1     Running   0          10s
....

Criar o serviço LoadBalancer externo

Exponha a carga de trabalho de exemplo criando um serviço LoadBalancer externo.
1. Salve o seguinte manifesto de serviço como store-v1-lb-svc.yaml:
```
apiVersion: v1
kind: Service
metadata:
  name: store-v1-lb-svc
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080
```
2. Aplique o manifesto ao cluster:
```
kubectl apply -f store-v1-lb-svc.yaml
```
Observe os seguintes pontos sobre este exemplo de manifesto:
- Defina o campo spec.loadBalancerClass com o valor networking.gke.io/l4-regional-external no momento em que o manifesto é aplicado ao cluster pela primeira vez. Esse campo instrui o GKE a criar um balanceador de carga de rede de passagem externa baseado em serviço de back-end. Os balanceadores de carga de rede de passagem externa baseados em serviço de back-end são necessários para oferecer suporte a recursos como IPv6 e balanceamento de carga ponderado.
- O GKE usa back-ends de NEG GCE_VM_IP ou back-ends de grupos de instâncias não gerenciadas, dependendo da versão do cluster. Em clusters com a versão 1.32.2-gke.1652000, o balanceador de carga de rede de passagem externa baseado em serviço de back-end usa NEGs GCE_VM_IP. Em versões anteriores, o balanceador de carga de rede de passagem externa baseado em serviço de back-end usava grupos de instâncias não gerenciadas.
- Esse campo spec.loadBalancerClass é imutável e precisa ser definido quando você cria o serviço. Como esse campo é imutável, não é possível adicionar ou modificar o manifesto de um serviço LoadBalancer existente. Qualquer tentativa de fazer isso vai resultar em um erro e a atualização do serviço vai falhar.

Ativar o balanceamento de carga ponderado

Para distribuir novas conexões proporcionalmente aos nós com base em quantos pods de exibição, prontos e não encerrados estão presentes em cada nó, ative o balanceamento de carga ponderado adicionando a anotação networking.gke.io/weighted-load-balancing: "pods-per-node" ao manifesto do serviço.

Adicione a anotação networking.gke.io/weighted-load-balancing: "pods-per-node" ao manifesto do serviço store-v1-lb-svc.yaml e defina o valor externalTrafficPolicy: Local para que ele fique assim:

apiVersion: v1
kind: Service
metadata:
  name: store-v1-lb-svc
  annotations:
    networking.gke.io/weighted-load-balancing: "pods-per-node"
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  externalTrafficPolicy: Local
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080

Aplique o manifesto ao cluster:
```
kubectl apply -f store-v1-lb-svc.yaml
```

Observe o seguinte sobre este exemplo de balanceamento de carga ponderado:

O manifesto do serviço usa externalTrafficPolicy: Local. Se você não precisar ativar o balanceamento de carga ponderado, também poderá usar externalTrafficPolicy: Cluster. Para detalhes sobre como o externalTrafficPolicy define o agrupamento de nós, quais nós passam nas verificações de integridade do balanceador de carga e como os pacotes são processados, consulte Conceitos do serviço LoadBalancer.
Se você ativar o balanceamento de carga ponderado, o GKE não vai impedir o uso de externalTrafficPolicy: Cluster, mas externalTrafficPolicy: Cluster desativa o balanceamento de carga ponderado porque o pacote pode ser encaminhado, após o balanceador de carga, para um nó diferente.

Também é possível ativar o balanceamento de carga ponderado em um serviço LoadBalancer externo usando kubectl edit svc service-name. O comando kubectl edit abre o manifesto de serviço do balanceador de carga atual no editor de texto configurado, em que é possível modificar o manifesto e salvar as mudanças. Ao editar um serviço LoadBalancer externo, observe os seguintes pontos:

O serviço LoadBalancer externo precisa ter resultado na criação de um balanceador de carga de rede de passagem externa baseado em serviço de back-end. Isso significa que o serviço LoadBalancer externo precisa ter o campo spec.loadBalancerClass definido como networking.gke.io/l4-regional-external quando o manifesto foi aplicado ao cluster pela primeira vez.

Adicionar a anotação networking.gke.io/weighted-load-balancing: "pods-per-node" a um serviço LoadBalancer externo que usa um balanceador de carga de rede de passagem externa baseado em pool de destino não tem efeito.
Ao atualizar o manifesto do serviço LoadBalancer externo, defina o valor externalTrafficPolicy: Local. Usar externalTrafficPolicy: Cluster desativa efetivamente o balanceamento de carga ponderado porque o pacote pode ser roteado, após o balanceador de carga, para um nó diferente.

Desativar o balanceamento de carga ponderado

Para distribuir novas conexões para nós, independentemente de quantos pods de serviço estejam presentes em cada nó, desative o balanceamento de carga ponderado removendo a anotação networking.gke.io/weighted-load-balancing: "pods-per-node" do manifesto do serviço.

Ativar a geração de registros para serviços de back-end

É possível ativar, desativar e ver registros de um balanceador de carga de rede de passagem externa com base em serviço de back-end.

Para configurar o Cloud Logging, crie um recurso personalizado L4LBConfig que especifica as configurações de geração de registros. O recurso L4LBConfig está vinculado a um serviço do Kubernetes no manifesto do serviço. Depois de aplicar o manifesto, o controlador do GKE configura a geração de registros para o serviço de back-end. Se você não vincular um recurso L4LBConfig ao serviço, o controlador vai parar de gerenciar a configuração de geração de registros e deixar o serviço de back-end no último estado conhecido. Para mais informações, consulte Entender o comportamento de custo.

É possível configurar os seguintes campos:

enabled: se definido como true, ativa a geração de registros para este serviço e os registros ficam disponíveis no Cloud Logging. Caso contrário, a geração de registros será desativada para este serviço.
sampleRate: especifica um valor de 0 a 1,000,000 (padrão), em que 0 significa que nenhum pacote é registrado e 1,000,000 significa que 100% dos pacotes são registrados. O campo sampleRate é opcional e só é relevante se o valor do campo enable estiver definido como true.
optionalMode: controla quais campos de metadados opcionais são incluídos nos registros gerados para o balanceador de carga. O campo aceita um dos seguintes valores de string:
- EXCLUDE_ALL_OPTIONAL: configuração padrão se optionalMode não for especificado. Quando definido, nenhum campo opcional é incluído nos registros, fornecendo o formato de registro mais conciso.
- INCLUDE_ALL_OPTIONAL: ativa a geração de registros para todos os campos opcionais disponíveis, fornecendo as entradas de registro mais detalhadas.
- CUSTOM: especifica uma lista personalizada de campos opcionais incluídos nos registros. No modo CUSTOM, também é necessário usar o parâmetro optionalFields para fornecer uma lista separada por vírgulas dos campos desejados.
optionalFields: string separada por vírgulas de nomes de campos. Define os campos de metadados opcionais exatos que você quer incluir nos registros gerados. Esse campo só é usado quando optionalMode é definido como CUSTOM. Caso contrário, todos os valores são ignorados.

Para configurar o Cloud Logging, crie o recurso L4LBConfig no mesmo namespace que o recurso Service. O exemplo de manifesto L4LBConfig a seguir ativa o Cloud Logging e define a taxa de amostragem como 50% das solicitações para um determinado serviço de balanceador de carga.

Salve o seguinte manifesto como svc-l4lb-config.yaml:

apiVersion: networking.gke.io/v1
kind: L4LBConfig
metadata:
  name: svc-l4lb-config
  namespace: default
spec:
  logging:
    enabled: true # must be included
    sampleRate: 500000
    optionalMode: "INCLUDE_ALL_OPTIONAL"

Aplique o manifesto L4LBConfig ao cluster:
```
kubectl apply -f svc-l4lb-config.yaml
```

Adicione a anotação networking.gke.io/l4lb-config ao manifesto do serviço store-v1-lb-svc.yaml:

apiVersion: v1
kind: Service
metadata:
  name: store-v1-lb-svc
  annotations:
    cloud.google.com/l4-rbs: "enabled"
    networking.gke.io/l4lb-config: "svc-l4lb-config"
spec:
  type: LoadBalancer
  selector:
    app: store
  ports:
    - name: tcp-port
      protocol: TCP
      port: 8080
      targetPort: 8080

Aplique o manifesto do serviço ao cluster:
```
kubectl apply -f store-v1-lb-svc.yaml
```

Verificar o serviço LoadBalancer externo e os componentes dele

Verifique se o serviço está em execução:
```
kubectl get svc store-v1-lb-svc
```
O resultado será assim:
```
NAME               TYPE           CLUSTER-IP        EXTERNAL-IP     PORT(S)          AGE
store-v1-lb-svc   LoadBalancer   10.44.196.160     35.193.28.231   8080:32466/TCP   11m
```
O GKE atribuiu um EXTERNAL_IP para o balanceador de carga de rede de passagem externa.

Observação: pode levar alguns minutos para que o GKE aloque um endereço IP externo antes que o balanceador de carga esteja pronto para disponibilizar o aplicativo.

Teste a conexão com o balanceador de carga:

curl EXTERNAL_IP:PORT

Substitua:

EXTERNAL_IP: o endereço IP de alocação para o balanceador de carga de rede de passagem externa.
PORT: o número da porta alocada para o balanceador de carga de rede de passagem externa.

O resultado será o seguinte:

Hostname: store-v1-lb-svc-cdb9bb4d6-hflxd

Pod Information:
  -no pod information available-

Server values:
  server_version=nginx: 1.13.3 - lua: 10008

Request Information:
  client_address=10.128.0.50
  method=GET
  real path=/
  query=
  request_version=1.1
  request_scheme=http
  request_uri=EXTERNAL_IP

Request Headers:
  accept=*/*
  host=EXTERNAL_IP
  user-agent=curl/7.81.0

Request Body:
  -no body in request-

Verifique seu serviço LoadBalancer e o conjunto de anotações que descreve os recursos do Cloud de Confiance :
```
kubectl describe svc store-v1-lb-svc
```
O resultado será o seguinte:
```
Name:                     store-v1-lb-svc
Namespace:                default
Labels:                   <none>
Annotations:              cloud.google.com/neg-status: {"network_endpoint_groups":{"0":"k8s2-qvveq1d8-default-my-service-ext-5s55db85"},"zones":["us-central1-c"]} #This annotation appears in the output only if the service uses NEG backends.
                          networking.gke.io/weighted-load-balancing: pods-per-node #This annotation appears in the output only if weighted load balancing is enabled.
                          service.kubernetes.io/backend-service: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                          service.kubernetes.io/firewall-rule: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                          service.kubernetes.io/firewall-rule-for-hc: k8s2-qvveq1d8-default-my-service-ext-5s55db85-fw
                          service.kubernetes.io/healthcheck: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                          service.kubernetes.io/tcp-forwarding-rule: a808124abf8ce406ca51ab3d4e7d0b7d
Selector:                 app=store
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.18.102.23
IPs:                      10.18.102.23
LoadBalancer Ingress:     35.184.160.229
Port:                     tcp-port  8080/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-port  31864/TCP
Endpoints:                10.20.1.28:8080,10.20.1.29:8080
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30394

Events:
  Type    Reason                Age                    From                     Message
  ----    ------                ----                   ----                     -------
  Normal  ADD                   4m55s                  loadbalancer-controller  default/my-service-ext
```
Há vários campos que indicam que um balanceador de carga de rede de passagem externa baseado em serviço de back-end e seus recursos Cloud de Confiance foram criados com sucesso:
- Campo Events. Este campo fica vazio quando o serviço LoadBalancer e os recursos dele foram criados com sucesso. Se ocorrer um erro, ele será listado aqui.
- Lista de Annotations ativadas: o GKE adiciona a seguinte lista de anotações somente leitura ao manifesto do serviço. Cada anotação com um nome que começa com service.kubernetes.io/ é usada para indicar o nome de um recursoCloud de Confiance criado como parte ou para oferecer suporte ao balanceador de carga.
  - A anotação networking.gke.io/weighted-load-balancing: pods-per-node indica que o balanceamento de carga ponderado foi aplicado e que o balanceador de carga distribui o tráfego para os pods de back-end com base no número de pods em execução em cada nó.
  - A anotação service.kubernetes.io/backend-service indica o nome do serviço de back-end do balanceador de carga.
  - A anotação service.kubernetes.io/healthcheck indica o nome da verificação de integridade do balanceador de carga usada pelo serviço de back-end.
  - A anotação service.kubernetes.io/tcp-forwarding-rule ou service.kubernetes.io/udp-forwarding-rule indica o nome da regra de encaminhamento do balanceador de carga.
  - A anotação service.kubernetes.io/firewall-rule indica o nome da regra de firewall criada para permitir o tráfego para os nós do cluster. Os intervalos de origem desta regra de firewall são personalizáveis usando spec.loadBalancerSourceRanges[]. Para mais detalhes sobre as regras de firewall para os serviços LoadBalancer, consulte Regras de firewall e lista de permissões de endereços IP de origem.
  - A anotação service.kubernetes.io/firewall-rule-for-hc indica o nome da regra de firewall necessária para as verificações de integridade do balanceador de carga.
  - A anotação cloud.google.com/neg-status indica as NEGs usadas pelo balanceador de carga e as zonas delas. Essa anotação só está presente quando as duas condições a seguir são verdadeiras:
    - O cluster estava executando o GKE versão 1.32.2-gke.1652000 ou mais recente quando o manifesto foi aplicado ao cluster.
    - O campo spec.loadBalancerClass definido como o valor networking.gke.io/l4-regional-external estava presente no manifesto do serviço quando ele foi aplicado ao cluster.
Verifique se os recursos do balanceador de carga e as regras de firewall foram criados para o serviço LoadBalancer externo:
- Para ver a regra de encaminhamento, execute o seguinte comando:
```
  gcloud compute forwarding-rules describe FWD_RULE_NAME \
    --region=REGION_NAME
```
  Substitua:
  - FWD_RULE_NAME: o nome da regra de encaminhamento fornecido pelas anotações somente leitura service.kubernetes.io/tcp-forwarding-rule ou service.kubernetes.io/udp-forwarding-rule. Para conferir essas anotações, execute kubectl describe svc SERVICE_NAME.
  - REGION_NAME: a Cloud de Confiance região que contém o cluster. Para clusters zonais, a região contém a zona usada pelo cluster.
- Para ver o serviço de back-end, execute o seguinte comando:
```
gcloud compute backend-services describe BACKEND_SERVICE_NAME \
  --region=REGION_NAME
```
  Substitua:
  - BACKEND_SERVICE_NAME: o nome do serviço de back-end fornecido pela anotação somente leitura service.kubernetes.io/backend-service. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.
  - REGION_NAME: a Cloud de Confiance região que contém o cluster. Para clusters zonais, a região contém a zona usada pelo cluster.
- Para ver a verificação de integridade do balanceador de carga, execute o seguinte comando:
```
gcloud compute health-checks describe HEALTH_CHECK_NAME \
  --region=REGION_NAME
```
  Substitua:
  - HEALTH_CHECK_NAME: o nome da verificação de integridade do balanceador de carga. O nome da verificação de integridade é fornecido pela anotação somente leitura service.kubernetes.io/healthcheck. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.
  - REGION_NAME: a Cloud de Confiance região que contém o cluster. Para clusters zonais, a região contém a zona usada pelo cluster.
- Para ver as regras de firewall, execute os seguintes comandos:
```
gcloud compute firewall-rules describe FIREWALL_RULE_NAME
```
```
gcloud compute firewall-rules describe HEALTH_CHECK_FIREWALL_RULE_NAME
```
  Substitua:
  - FIREWALL_RULE_NAME: o nome da regra de firewall que permite o tráfego para o balanceador de carga. O nome da regra de firewall é fornecido pela anotação somente leitura service.kubernetes.io/firewall-rule. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.
  - HEALTH_CHECK_FIREWALL_RULE_NAME: o nome da regra de firewall que permite verificações de saúde dos back-ends do balanceador de carga (os nós do cluster). O nome da regra de firewall é fornecido pela anotação somente leitura service.kubernetes.io/firewall-rule-for-hc. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.
- Para ver as NEGs do balanceador de carga, execute o seguinte comando:
```
gcloud compute network-endpoint-groups describe NEG_NAME \
  --zone=ZONE_NAME
```
  Substitua:
  - NEG_NAME: o nome do NEG do balanceador de carga. O nome do NEG é fornecido pela anotação somente leitura cloud.google.com/neg-status. Para verificar essa anotação somente leitura, execute o comando kubectl describe svc SERVICE_NAME. A anotação contém dados estruturados com informações sobre os nomes e as zonas do NEG usados pelo balanceador de carga. Para clusters zonais, essa anotação contém informações sobre um NEG. Para clusters regionais, essa anotação contém informações sobre um NEG em cada zona em que o cluster está localizado.
  - ZONE_NAME: a Cloud de Confiance zona que contém o NEG.
Verifique se o Cloud Logging foi ativado para o serviço de back-end:
```
kubectl get svc SERVICE_NAME --output yaml
```
Substitua:
- SERVICE_NAME: o nome do serviço de back-end.
Na saída, verifique se o campo Status.Conditions tem Type: LoggingConfigManaged e Reason: Reconciled.

Excluir o serviço LoadBalancer externo

Para excluir o serviço LoadBalancer externo store-v1-lb-svc de exemplo, use o comando a seguir:

kubectl delete service store-v1-lb-svc

O GKE remove automaticamente todos os recursos de balanceador de carga que ele criou para o serviço LoadBalancer externo.

Migrar para back-ends de NEG `GCE_VM_IP`

Os serviços LoadBalancer externos com o campo spec.loadBalancerClass definido como o valor networking.gke.io/l4-regional-external ou com a anotação cloud.google.com/l4-rbs: "enabled" criam balanceadores de carga de rede de passagem externa baseados em serviço de back-end que usam o grupo de endpoints de rede GCE_VM_IP ou back-ends de grupo de instâncias, dependendo da versão do GKE do cluster:

Se o manifesto do serviço foi aplicado a um cluster que executa a versão 1.32.2-gke.1652000 ou mais recente do GKE, o balanceador de carga de rede de passagem externa resultante usa back-ends de grupo de endpoints de rede (NEG) GCE_VM_IP.
Se o manifesto do serviço foi aplicado a um cluster que executa uma versão anterior do GKE, o balanceador de carga de rede de passagem externa resultante usa back-ends de grupo de instâncias não gerenciadas.

Para mais informações, consulte Agrupamento de nós em "Sobre os serviços LoadBalancer".

É possível criar um novo serviço LoadBalancer externo com tecnologia de um balanceador de carga de rede de passagem externa baseado em serviço de back-end que usa back-ends de NEG GCE_VM_IP se o serviço atual usar um dos seguintes balanceadores de carga:

Um balanceador de carga de rede de passagem externa baseado em serviço de back-end com back-ends de grupo de instâncias
Um balanceador de carga de rede de passagem externa baseado em pool de destino

Para mudar para um balanceador de carga de rede de passagem externa baseado em serviço de back-end usando back-ends de NEG GCE_VM_IP:

Se ainda não tiver feito isso, faça upgrade do cluster para a versão do GKE 1.32.2-gke.1652000 ou mais recente.
Identifique o serviço LoadBalancer externo que você quer mudar para um balanceador de carga de rede de passagem externa baseado em serviço de back-end usando back-ends de NEG GCE_VM_IP. Descreva o serviço usando o seguinte comando:
```
kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
```
Substitua:
- SERVICE_NAME: o nome do serviço de LoadBalancer externo atual.
- SERVICE_NAMESPACE: o namespace do serviço LoadBalancer externo atual.
Na resposta ao comando, anote o endereço IPv4 externo do balanceador de carga listado após LoadBalancer Ingress.
Recupere o manifesto do serviço para o serviço LoadBalancer atual:
- O ideal é ter o manifesto de serviço original que você aplicou ao cluster no passado. Por exemplo, você pode ter isso em um repositório de controle de origem.
- Se você não tiver o manifesto do serviço original:
  - Execute o comando a seguir para receber uma cópia YAML do manifesto do serviço que representa a implementação atual do balanceador de carga:
```
kubectl get svc SERVICE_NAME -n SERVICE_NAMESPACE -o yaml
```
  - Copie o manifesto YAML para um editor de texto. Remova o atributo status e os seguintes atributos metadata:
    - Todas as seguintes anotações:
      - A anotação kubectl.kubernetes.io/last-applied-configuration
      - Todas as anotações que começam com service.kubernetes.io
    - creationTimestamp
    - finalizers
    - resourceVersion
    - uid
- Verifique se o manifesto inclui o campo spec.loadBalancerClass definido com o valor networking.gke.io/l4-regional-external. Se você estiver migrando de um balanceador de carga de rede de passagem externa baseado em pool de destino, o campo precisará ser adicionado.
Salve o arquivo de manifesto e anote onde ele foi salvo. O restante deste procedimento se refere ao caminho em que você salvou o manifesto como MANIFEST_FILE_PATH.
Configure um recurso de endereço IPv4 externo estático para armazenar o endereço IPv4 externo usado pelo balanceador de carga atual:
```
gcloud compute addresses create IP_ADDRESS_NAME --region=CLUSTER_REGION --addresses LB_EXTERNAL_IP
```
Substitua:
- IP_ADDRESS_NAME: o nome do endereço IP externo estático. O nome precisa seguir as convenções de nomenclatura para recursos do Compute Engine.
- CLUSTER_REGION: a região que contém o cluster. Para clusters zonais, essa é a região que contém a zona do cluster.
- LB_EXTERNAL_IP: o endereço IPv4 externo usado pelo balanceador de carga atual, determinado na segunda etapa deste procedimento.
Verifique se o recurso de endereço IPv4 externo estático foi criado:
```
gcloud compute addresses describe IP_ADDRESS_NAME --region=CLUSTER_REGION
```
Substitua as variáveis conforme indicado na etapa anterior.

Exclua o serviço atual:

kubectl delete svc SERVICE_NAME -n SERVICE_NAMESPACE

Adicione a seguinte anotação ao arquivo de manifesto do serviço MANIFEST_FILE_PATH:
```
networking.gke.io/load-balancer-ip-addresses: IP_ADDRESS_NAME
```
Para mais informações sobre essa anotação, consulte Endereços IP estáticos em Parâmetros do serviço LoadBalancer.
Aplique o manifesto de serviço atualizado ao cluster:
```
kubectl apply -f MANIFEST_FILE_PATH
```

(Opcional) Libere o recurso de endereço IPv4 estático.

gcloud compute addresses delete IP_ADDRESS_NAME --region=CLUSTER_REGION

Resolver problemas

Esta seção descreve um problema que pode ocorrer ao configurar o balanceamento de carga ponderado.

Política de tráfego externo incorreta para balanceamento de carga ponderado

Se você não definir o valor externalTrafficPolicy: Local ao ativar o balanceamento de carga ponderado, poderá receber um evento de aviso ao descrever o serviço usando o seguinte comando:

kubectl describe svc store-v1-lb-svc`

Events:
  Type     Reason                   Age      From                     Message
  ----     ------                   ----     ----                     -------
  Warning  UnsupportedConfiguration 4m55s    loadbalancer-controller  Weighted load balancing by pods-per-node has no effect with External Traffic Policy: Cluster.

Para ativar o balanceamento de carga ponderado, defina o valor externalTrafficPolicy: Local.

A seguir

Para uma visão geral dos serviços do balanceador de carga, consulte Serviços do LoadBalancer.
Para uma descrição dos parâmetros dos serviços do balanceador de carga, consulte Parâmetros do serviço LoadBalancer.
Resolver problemas de balanceamento de carga no GKE.

Criar um balanceador de carga externo baseado em serviço de back-end

Antes de começar

Requisitos

Escolher um cluster

Criar um novo cluster

Fazer upgrade de um cluster atual

implante uma carga de trabalho de amostra

Criar o serviço LoadBalancer externo

Ativar o balanceamento de carga ponderado

Desativar o balanceamento de carga ponderado

Ativar a geração de registros para serviços de back-end

Verificar o serviço LoadBalancer externo e os componentes dele

Excluir o serviço LoadBalancer externo

Migrar para back-ends de NEG GCE_VM_IP

Resolver problemas

Política de tráfego externo incorreta para balanceamento de carga ponderado

A seguir

Migrar para back-ends de NEG `GCE_VM_IP`