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

Nesta página, mostramos como implantar um serviço LoadBalancer externo que cria um balanceador de carga de rede de passagem externo regional baseado em serviço de back-end. Antes de ler esta página, você precisa conhecer:

Para saber mais sobre balanceadores de carga de rede de passagem externa regionais em geral, consulte Balanceador de carga de rede de passagem externa regional 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
  • Para usar a Google Cloud CLI nesta tarefa, instale e 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.

Requisitos

  • Neste tutorial, usamos spec.loadBalancerClass para criar um balanceador de carga de rede de passagem externa regional 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 requer 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 estar ativado no cluster. Esse complemento é ativado por padrão. Para mais informações, consulte o pré-requisito HttpLoadBalancing.

  • Para ativar o Cloud Logging em um serviço LoadBalancer externo, o cluster do GKE precisa usar a versão 1.36.0-gke.2459000 ou posterior.

  • Para usar endereços IPv6 traga seu próprio IP (BYOIP) com um serviço LoadBalancer externo IPv6 de pilha única, o cluster do GKE precisa usar a versão 1.37.1-gke.2097000 ou posterior.

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 novo cluster do Autopilot:

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

Substitua:

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

Padrão

Para criar um novo cluster padrão:

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

Substitua:

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

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:

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

implante uma carga de trabalho de amostra

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

  1. 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

  2. Aplique o manifesto ao cluster:

    kubectl apply -f store-deployment.yaml

  3. 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

  1. Exponha a carga de trabalho de amostra 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:

    • Se o cluster executar o GKE 1.33.1-gke.1779000 para 1.36, defina o campo spec.loadBalancerClass como o valor networking.gke.io/l4-regional-external no momento em que o manifesto for aplicado pela primeira vez ao cluster. Esse campo instrui o GKE a criar um balanceador de carga de rede de passagem externa regional baseado em serviço de back-end. No GKE 1.37 e versões mais recentes, essa configuração é o comportamento padrão, e o campo não é obrigatório. Os balanceadores de carga de rede de passagem externa regionais baseados em serviço de back-end são necessários para oferecer suporte a recursos como tráfego IPv6 e balanceamento de carga ponderado.

    • O GKE usa back-ends de NEG GCE_VM_IP ou back-ends de grupo 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 regional baseado em serviço de back-end usa NEGs GCE_VM_IP. Nas versões anteriores, o balanceador de carga de rede de passagem externa regional baseado em serviço de back-end usa 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 adicioná-lo ou modificá-lo no manifesto de um serviço LoadBalancer atual. Qualquer tentativa de fazer isso resultará em um erro, e a atualização do serviço falhará.

    • Para criar um serviço IPv6 de pilha única em um cluster de pilha dupla, defina o valor do campo spec.ipFamilyPolicy como SingleStack e defina o valor do campo spec.ipFamilies como IPv6. Em um cluster IPv6 de pilha única, esses são os valores padrão e podem ser omitidos. Para mais informações, consulte Serviços LoadBalancer IPv6.

Criar um serviço LoadBalancer externo em um cluster IPv6 de pilha única

Quando você cria um serviço LoadBalancer externo IPv6 de pilha única em um cluster IPv6 de pilha única ou em um cluster de pilha dupla, a sub-rede usada pelo balanceador de carga depende se a sub-rede do nó do cluster usa um tipo de acesso IPv6 EXTERNAL ou INTERNAL. Em um cluster de pilha dupla, defina o valor do campo spec.ipFamilyPolicy como SingleStack e o valor do campo spec.ipFamilies como IPv6 (em um cluster IPv6 de pilha única, esses são os valores padrão e podem ser omitidos). Os serviços LoadBalancer externos IPv6 sempre usam um balanceador de carga de rede de passagem externa regional baseado em serviço de back-end no nível Premium. Os exemplos a seguir definem o campo spec.loadBalancerClass como networking.gke.io/l4-regional-external explicitamente, embora essa variante do balanceador de carga seja o padrão no GKE versão 1.37 e mais recentes:

  • Clusters com nós externos (tipo de acesso GUA EXTERNAL): se os nós do cluster forem executados em uma sub-rede externa com endereços unicast globais (GUA, na sigla em inglês), o balanceador de carga externo usará automaticamente a sub-rede de nós atual. Crie o serviço sem anotações de sub-rede personalizadas:

    apiVersion: v1
kind: Service
metadata:
  name: ext-ipv6-svc
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080

  • Clusters com nós internos (tipo de acesso ULA INTERNAL): se os nós do cluster forem executados em uma sub-rede interna com endereços unicast locais exclusivos (ULA, na sigla em inglês), um balanceador de carga externo não poderá usar essa sub-rede diretamente. É preciso provisionar uma sub-rede IPv6 externa (EXTERNAL) dedicada e referenciá-la usando a anotação networking.gke.io/load-balancer-subnet no Serviço:

    1. Crie uma sub-rede IPv6 externa dedicada:

      gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=EXTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

      Substitua:

      • SUBNET_NAME: o nome da sub-rede a ser criada.
      • NETWORK_NAME: o nome da rede VPC em que você cria essa sub-rede.
      • COMPUTE_REGION: a região do Compute Engine da sub-rede.

    2. Crie o Serviço que faz referência ao nome da sub-rede dedicada na anotação networking.gke.io/load-balancer-subnet:

      apiVersion: v1
kind: Service
metadata:
  name: ext-ipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: SUBNET_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080

  1. Verifique o endereço IP do serviço atribuído:

    kubectl get svc ext-ipv6-svc

    A saída confirma que as colunas CLUSTER-IP e EXTERNAL-IP (um endereço GUA público) estão preenchidas:

    NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP                      PORT(S)        AGE
ext-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c401   2600:1900:4000:2714:8000:0:0:0   80:31114/TCP   51s

Para mais informações, consulte Serviços LoadBalancer IPv6.

Usar seus próprios endereços IPv6 (BYOIPv6)

No GKE versão 1.37.1-gke.2097000 e posterior, é possível configurar um serviço LoadBalancer externo IPv6 de pilha única para usar traga seus próprios endereços IPv6 (BYOIPv6) de um subprefixo IPv6 regional de um prefixo delegado público (PDP) no modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

Antes de criar o serviço, verifique se você atende aos seguintes requisitos:

  • O cluster executa o GKE versão 1.37.1-gke.2097000 ou posterior. O cluster pode ser de pilha única IPv6 ou de pilha dupla (o serviço precisa ser de pilha única IPv6 em ambos os casos), e a sub-rede do cluster pode ter um tipo de acesso IPv6 INTERNAL ou EXTERNAL. Um intervalo de sub-rede IPv6 externo não é necessário porque o intervalo de endereços vem do prefixo público delegado.
  • Você tem um subprefixo IPv6 regional no modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION com um comprimento de prefixo alocável de /96 e o status ANNOUNCED, na mesma região do cluster. Para instruções, consulte Criar subprefixos IPv6.

  • O agente de serviço do GKE (service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com) tem o papel de Administrador de IP público do Compute (roles/compute.publicIpAdmin) no projeto que possui o prefixo público delegado. Para conceder o papel, execute o seguinte comando:

    gcloud projects add-iam-policy-binding PDP_PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role="roles/compute.publicIpAdmin"

    Substitua:

    • PDP_PROJECT_ID: o ID do projeto que tem o prefixo delegado público.
    • PROJECT_NUMBER: o número do projeto que contém o cluster.

  • O Serviço é um Serviço IPv6 de pilha única (spec.ipFamilyPolicy: SingleStack e spec.ipFamilies: ["IPv6"]) que define o campo spec.loadBalancerClass como networking.gke.io/l4-regional-external e usa o nível Premium. Os serviços de pilha dupla, os serviços IPv4 e o nível Standard não são compatíveis com o BYOIPv6.

  • O serviço não inclui a anotação networking.gke.io/load-balancer-subnet, que não pode ser combinada com a anotação networking.gke.io/ip-collection-v6.

Escolha se você quer alocar um intervalo de endereços BYOIPv6 externo temporário ou usar um intervalo de endereços BYOIPv6 externo estático reservado:

  • Intervalo de endereços BYOIPv6 externo temporário: adicione a anotação networking.gke.io/ip-collection-v6 ao manifesto do serviço e defina-a como o URL completo do recurso ou o caminho parcial do recurso do seu subprefixo regional:

    apiVersion: v1
kind: Service
metadata:
  name: ext-byoipv6-svc
  annotations:
    networking.gke.io/ip-collection-v6: "projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME"
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

    Substitua:

    • PROJECT_ID: o ID do projeto que contém o subprefixo.
    • REGION: a região do cluster.
    • SUB_PREFIX_NAME: o nome do subprefixo regional no modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

    Se você alterar a anotação networking.gke.io/ip-collection-v6 posteriormente, o GKE vai recriar a regra de encaminhamento IPv6 com um novo endereço do novo prefixo, o que interrompe brevemente o tráfego para o Serviço. Se você remover a anotação, o Serviço vai reverter para um endereço fornecido pelo Google de uma sub-rede com um intervalo IPv6 externo. Se a sub-rede do cluster tiver um intervalo IPv6 interno, adicione a anotação networking.gke.io/load-balancer-subnet ao mesmo tempo.

  • Intervalo de endereços BYOIPv6 externo estático: reserve um intervalo de endereços IPv6 /96 externo estático regional do subprefixo e faça referência a ele usando a anotação networking.gke.io/load-balancer-ip-addresses:

    1. Crie um intervalo de endereços IPv6 externos estáticos regionais com base no subprefixo:

      gcloud compute addresses create STATIC_BYOIPV6_NAME \
    --region=REGION \
    --ip-version=IPV6 \
    --endpoint-type=NETLB \
    --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME

      Substitua:

      • STATIC_BYOIPV6_NAME: um nome para o recurso de endereço IPv6 estático.
      • REGION: a região do cluster.
      • PROJECT_ID: o ID do projeto que contém o subprefixo.
      • SUB_PREFIX_NAME: o nome do subprefixo regional no modo EXTERNAL_IPV6_FORWARDING_RULE_CREATION.

      A anotação networking.gke.io/ip-collection-v6 é opcional quando você usa um intervalo de endereços BYOIPv6 externo estático. Se você definir essa anotação, ela precisará referenciar o mesmo subprefixo de onde você reservou o intervalo de endereços.

    2. Faça referência ao nome do recurso de endereço IPv6 estático reservado no manifesto do serviço:

      apiVersion: v1
kind: Service
metadata:
  name: ext-static-byoipv6-svc
  annotations:
    networking.gke.io/load-balancer-ip-addresses: STATIC_BYOIPV6_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-external
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: store
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

Para mais informações, consulte Traga seus próprios endereços IPv6 (BYOIPv6).

Ativar o balanceamento de carga ponderado

Para distribuir novas conexões proporcionalmente aos nós com base em quantos pods de disponibilizaçã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.

  1. 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

  2. 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 impedirá o uso de externalTrafficPolicy: Cluster, mas externalTrafficPolicy: Cluster desativará o balanceamento de carga ponderado porque o pacote pode ser roteado, 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 alterações. Ao editar um serviço LoadBalancer externo, observe os seguintes pontos:

  • O serviço LoadBalancer externo atual precisa ter resultado na criação de um balanceador de carga de rede de passagem externa regional baseado em serviço de back-end. Para clusters que executam versões do GKE anteriores à 1.37, esse requisito significa que o serviço LoadBalancer externo atual precisa ter o campo spec.loadBalancerClass definido como networking.gke.io/l4-regional-external quando o manifesto foi aplicado pela primeira vez ao cluster.

    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 regional baseado em pool de destino não tem efeito.

  • Ao atualizar o manifesto do serviço LoadBalancer externo, defina o valor externalTrafficPolicy: Local. O uso de 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 exibição estão 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 visualizar registros de um balanceador de carga de rede de passagem externa regional baseado em serviço de back-end.

Para configurar o Cloud Logging, crie um recurso personalizado L4LBConfig que especifique 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 vai deixar o serviço de back-end no último estado conhecido. Para mais informações, consulte Entender o comportamento de desaceleração.

É 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 esse 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 que são incluídos nos registros. Com o modo CUSTOM, você também precisa usar o parâmetro optionalFields para fornecer uma lista separada por vírgulas dos campos que você quer.
  • 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 é usado apenas 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 do recurso de Serviço. O exemplo de manifesto L4LBConfig a seguir ativa o Cloud Logging e define a taxa de amostragem como 50% das solicitações de um determinado serviço de balanceador de carga.

  1. 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"

  2. Aplique o manifesto L4LBConfig ao cluster:

    kubectl apply -f svc-l4lb-config.yaml

  3. 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

  4. Aplique o manifesto de serviço ao cluster:

    kubectl apply -f store-v1-lb-svc.yaml

Verificar o serviço LoadBalancer externo e os componentes dele

  1. Verifique se o serviço está em execução:

    kubectl get svc store-v1-lb-svc

    O resultado será o seguinte:

    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 externo regional.

  2. 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 regional.
    • PORT: o número da porta alocada para o balanceador de carga de rede de passagem externa regional.

    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-

  3. Verifique seu serviço LoadBalancer e o conjunto de anotações que descreve os recursos doGoogle Cloud :

    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 regional baseado em serviço de back-end e os recursos do Google Cloud 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 recurso doGoogle Cloud 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[]. Veja mais detalhes sobre as regras de firewall para os serviços LoadBalancer em 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 os NEGs usados pelo balanceador de carga e as zonas deles. 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 que foi definido como o valor networking.gke.io/l4-regional-external estava presente no manifesto do serviço quando foi aplicado ao cluster.

  4. 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 Google Cloud 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 Google Cloud 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 Google Cloud 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 integridade 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 os 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 de 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 zona do Google Cloud que contém o NEG.

  5. 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 de amostra store-v1-lb-svc, use o seguinte comando:

kubectl delete service store-v1-lb-svc

O GKE remove automaticamente todos os recursos do 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 criam balanceadores de carga de rede de passagem externa regionais baseados em serviço de back-end se forem criados no GKE 1.37 ou posterior, especificarem o valor networking.gke.io/l4-regional-external para o campo spec.loadBalancerClass ou incluírem a anotação cloud.google.com/l4-rbs: "enabled". Dependendo da versão do GKE do cluster, o GKE usa grupos de endpoints de rede GCE_VM_IP ou grupos de instâncias não gerenciadas como back-ends:

  • Se o manifesto de serviço foi aplicado a um cluster que executa o GKE versão 1.32.2-gke.1652000 ou posterior, o balanceador de carga de rede de passagem externa regional resultante usa back-ends de grupo de endpoints de rede (NEG) GCE_VM_IP.

  • Se o manifesto de Serviço foi aplicado a um cluster que executa uma versão anterior do GKE, o balanceador de carga de rede de passagem externa regional 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 do LoadBalancer.

É possível criar um novo serviço LoadBalancer externo com tecnologia de um balanceador de carga de rede de passagem externo regional baseado em serviço de back-end que use 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 regional baseado em serviço de back-end com back-ends de grupo de instâncias
  • Um balanceador de carga de rede de passagem externa regional baseado em pool de destino

Para preservar um endereço IPv4 externo ao mudar para um balanceador de carga de rede de passagem externa regional baseado em serviço de back-end que usa back-ends de NEG GCE_VM_IP (os serviços LoadBalancer externos IPv6 não exigem essa migração):

  1. Se ainda não tiver feito isso, faça upgrade do cluster para a versão 1.32.2-gke.1652000 ou mais recente do GKE.

  2. Identifique o serviço LoadBalancer externo que você quer mudar para um balanceador de carga de rede de passagem externa regional 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 LoadBalancer externo.

    • 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 depois de LoadBalancer Ingress.

  3. Recupere o manifesto do serviço LoadBalancer atual:

    • É melhor 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 de serviço original:

      • Execute o comando a seguir para receber uma cópia YAML do manifesto de serviço que representa a implementação atual do balanceador de carga:

        kubectl get svc SERVICE_NAME -n SERVICE_NAMESPACE -o yaml

      • Copie o YAML do manifesto 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 como o valor networking.gke.io/l4-regional-external. Se você estiver migrando de um balanceador de carga de rede de passagem externa regional 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.

  4. 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.

  5. 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.

  6. Exclua o Serviço atual:

    kubectl delete svc SERVICE_NAME -n SERVICE_NAMESPACE

  7. 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 nos parâmetros de serviço do LoadBalancer.

  8. Aplique o manifesto de serviço atualizado ao cluster:

    kubectl apply -f MANIFEST_FILE_PATH

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

    gcloud compute addresses delete IP_ADDRESS_NAME --region=CLUSTER_REGION

Resolver problemas

Nesta seção, descrevemos os problemas que podem ser encontrados ao configurar um serviço LoadBalancer externo baseado em serviço de back-end.

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

Se você não definir o valor de 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.

Erro ao criar um balanceador de carga IPv6 no nível Standard

Se um serviço LoadBalancer externo IPv6 mostrar um evento SyncExternalLoadBalancerFailed com a mensagem Network tier Standard is not supported for IPv6 External Load Balancer, remova a anotação cloud.google.com/network-tier: Standard do manifesto do serviço. Os serviços LoadBalancer externos IPv6 são compatíveis apenas no nível Premium.

Erros ao configurar o recurso Traga seus próprios endereços IPv6 (BYOIPv6)

Ao configurar traga seus próprios endereços IPv6 (BYOIPv6) para um serviço LoadBalancer externo, talvez você veja eventos de aviso SyncExternalLoadBalancerFailed ao executar o comando kubectl describe service SERVICE_NAME. A mensagem de evento começa com Error ensuring Resource for L4 External LoadBalancer, err: seguido por um dos seguintes erros:

  • networking.gke.io/ip-collection-v6 is currently only supported for IPv6-only Services: verifique se o manifesto do Serviço especifica spec.ipFamilyPolicy: SingleStack e spec.ipFamilies: ["IPv6"].
  • static IPv6 address "ADDRESS_NAME" is a BYOIP address from IP collection "SUB_PREFIX", which is currently only supported for IPv6-only Services: verifique se o manifesto do Serviço especifica spec.ipFamilyPolicy: SingleStack e spec.ipFamilies: ["IPv6"]. Esse erro indica que o Serviço é de pilha dupla ou IPv4, mas faz referência a um endereço BYOIPv6 estático.
  • cannot specify both networking.gke.io/load-balancer-subnet ("SUBNET") and networking.gke.io/ip-collection-v6 ("SUB_PREFIX") for LoadBalancer: remova a anotação networking.gke.io/load-balancer-subnet do manifesto do serviço ao usar a anotação networking.gke.io/ip-collection-v6.
  • invalid networking.gke.io/ip-collection-v6 "VALUE": expected projects/PROJECT/regions/REGION/publicDelegatedPrefixes/NAME ou invalid networking.gke.io/ip-collection-v6 "VALUE": the public delegated prefix must be in the cluster region REGION: defina a anotação como o URL completo do recurso ou o caminho parcial do recurso (projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME) de um subprefixo na mesma região do cluster. Um nome de subprefixo simples não é aceito.
  • reserved address ("ADDRESS_NAME") is not valid, err: ipCollection mismatch, expected "SUB_PREFIX_A", actual: "SUB_PREFIX_B": verifique se a anotação networking.gke.io/ip-collection-v6 corresponde ao prefixo público delegado que você usou para reservar o endereço IPv6 estático ou omita a anotação networking.gke.io/ip-collection-v6 ao usar a anotação networking.gke.io/load-balancer-ip-addresses.
  • googleapi: Error 403: Required 'compute.publicDelegatedPrefixes.use' permission for 'SUB_PREFIX', forbidden: conceda o papel de Administrador de IP público do Compute (roles/compute.publicIpAdmin) ao agente de serviço do GKE (service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com) no projeto que possui o prefixo público delegado. O GKE precisa dessa permissão sempre que sincroniza o Serviço. Portanto, não remova o papel depois que o GKE criar o Serviço.

A seguir