criar um balanceador de carga interno

Autopilot Standard

Nesta página, explicamos como criar um balanceador de carga de rede de passagem interna ou um balanceador de carga interno no Google Kubernetes Engine (GKE). Para criar um balanceador de carga de rede de passagem externa, consulte Criar um serviço do tipo LoadBalancer.

Antes de ler esta página, você deve conhecer os seguintes conceitos:

• Serviço LoadBalancer.
• Parâmetros de Serviço LoadBalancer.
• Balanceador de carga de rede de passagem externa baseado em serviço de back-end.

Como usar um balanceador de carga de rede de passagem interna

Os balanceadores de carga de rede de passagem internos tornam os Serviços do cluster acessíveis a clientes localizados na rede VPC do cluster e a clientes em redes conectadas à rede VPC do cluster. Os clientes na rede VPC do cluster podem ser nós ou pods do cluster ou VMs fora dele. Para mais informações sobre a conectividade de clientes em redes conectadas, consulte Balanceadores de carga de rede de passagem interna e redes conectadas.

Como usar o subconjunto do GKE

A subcriação do GKE melhora a escalonabilidade dos serviços LoadBalancer internos porque usa grupos de endpoints de rede (NEGs, na sigla em inglês) GCE_VM_IP como back-ends em vez de grupos de instâncias. Quando a criação de subconjuntos do GKE está ativada, ele cria um NEG por zona de computação por serviço LoadBalancer interno.

O externalTrafficPolicy do serviço controla a associação de nós nos back-ends GCE_VM_IP NEG. Para mais informações, consulte Associação de nós a back-ends de GCE_VM_IP NEG.

Como usar a afinidade zonal

Observação: a afinidade zonal está na fase de pré-lançamento.

Quando você ativa a afinidade zonal em um balanceador de carga de rede de passagem interna, o GKE encaminha o tráfego originado de uma zona para nós e pods dentro dessa mesma zona. Se não houver pods íntegros na zona, o GKE vai rotear o tráfego para outra zona. Essa implementação otimiza a latência e o custo.

Para ativar a afinidade zonal em um cluster do GKE, é preciso ativar a criação de subconjuntos do GKE.

Requisitos e limitações

Confira abaixo os requisitos e limitações dos balanceadores de carga internos.

Requisitos

O subconjunto do GKE tem os seguintes requisitos e limitações:

• É possível ativar a criação de subconjuntos do GKE em clusters Standard novos e atuais nas versões 1.18.19-gke.1400 e posteriores do GKE. Não é possível desativar a criação de subconjuntos do GKE depois que ela é ativada.
• A criação de subconjuntos do GKE é desativada por padrão nos clusters do Autopilot. No entanto, é possível ativar esse recurso depois de criar o cluster.
• A criação de subconjuntos do GKE requer que o complemento HttpLoadBalancing esteja ativado. Esse complemento é ativado por padrão. Nos clusters do Autopilot, não é possível desativar esse complemento necessário.
• Aplicam-se cotas para grupos de endpoints de rede.O Google Cloud cria um NEG GCE_VM_IP por serviço LoadBalancer interno por zona.
• São aplicadas cotas para regras de encaminhamento, serviços de back-end e verificações de integridade. Para mais informações, consulte Cotas e limites.
• A criação de subconjuntos do GKE não pode ser usada com a anotação para compartilhar um serviço de back-end entre vários balanceadores de carga, alpha.cloud.google.com/load-balancer-backend-share.
• É necessário ter a CLI do Google Cloud versão 345.0.0 ou posterior

A afinidade zonal tem os seguintes requisitos:

• É possível ativar a afinidade zonal em clusters novos e atuais nas versões 1.33.3-gke.1392000 e posteriores do GKE.
• É necessário ativar a criação de subconjuntos do GKE.
• Verifique se o complemento HttpLoadBalancing está ativado para seu cluster. Esse complemento é ativado por padrão e permite que o cluster gerencie balanceadores de carga que usam serviços de back-end.
• Você precisa incluir spec.trafficDistribution: PreferClose no manifesto do serviço LoadBalancer.

O manifesto do serviço LoadBalancer pode usar externalTrafficPolicy: Local ou externalTrafficPolicy: Cluster.

Limitações

Balanceadores de carga de rede de passagem interna

• Para clusters que executam o Kubernetes versão 1.7.4 e posterior, é possível usar balanceadores de carga internos com sub-redes de modo personalizado, além de sub-redes de modo automático.
• Os clusters que executam a versão 1.7.X ou posterior do Kubernetes aceitam um endereço IP reservado para o balanceador de carga de rede de passagem interno se você criar o endereço IP reservado com o--purpose sinalização definida comoSHARED_LOADBALANCER_VIP , Consulte Como ativar o IP compartilhado para instruções detalhadas. O GKE só preserva o endereço IP de um balanceador de carga de rede de passagem interno se o Serviço referir-se a um endereço IP interno com essa finalidade. Caso contrário, o GKE poderá alterar o endereço IP do balanceador de carga (spec.loadBalancerIP) se o Serviço for atualizado (por exemplo, se as portas forem alteradas).
• Mesmo que o endereço IP do balanceador de carga seja alterado (consulte o ponto anterior), o spec.clusterIP permanecerá constante.
• Os balanceadores de carga UDP internos não aceitam o uso de sessionAffinity: ClientIP.

Antes de começar

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

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. 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 gcloud CLI, 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 gcloud CLI 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.

• Verifique se você tem um cluster do Autopilot ou Standard. Para criar um novo cluster, consulte Criar um cluster do Autopilot.

Ativar a criação de subconjuntos do GKE em um cluster

É possível ativar a criação de subconjuntos do GKE para um cluster atual usando a CLI gcloud ou o console Google Cloud . Não é possível desativar a criação de subconjuntos do GKE depois de ativá-la.

Console

1. No console Google Cloud , acesse a página Google Kubernetes Engine.

   Acessar o Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que você quer modificar.

3. Em Rede, ao lado do campo Subagrupamento de balanceadores de carga internos L4, clique em Ativar o subagrupamento para balanceadores de carga internos L4.

4. Marque a caixa de seleção Ativar o subagrupamento para balanceadores de carga internos L4.

5. Clique em Save Changes.

gcloud

gcloud container clusters update CLUSTER_NAME \
    --enable-l4-ilb-subsetting

Substitua:

• CLUSTER_NAME: o nome do cluster.

Ativar a criação de subconjuntos do GKE não interrompe os serviços LoadBalancer internos. Se você quiser migrar os serviços LoadBalancer internos para usar serviços de back-end com NEGs GCE_VM_IP como back-ends, implante um manifesto de serviço substituto. Para mais detalhes, consulte Agrupamento de nós na documentação de conceitos do serviço LoadBalancer.

Implantar uma carga de trabalho

No manifesto a seguir, veja uma implantação que executa uma imagem de amostra do contêiner de aplicativo da Web.

1. Salve o manifesto como ilb-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ilb-deployment
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: ilb-deployment
     template:
       metadata:
         labels:
           app: ilb-deployment
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

2. Aplique o manifesto ao cluster:

   kubectl apply -f ilb-deployment.yaml
   

Criar um serviço LoadBalancer interno

1. (Opcional) Desative a criação automática de regras de firewall da VPC:

   Embora o GKE crie automaticamente regras de firewall da VPC para permitir o tráfego para o balanceador de carga interno, você pode desativar a criação automática de regras de firewall da VPC e gerenciar as regras por conta própria. Só é possível desativar as regras de firewall da VPC se você tiver ativado a criação de subconjuntos do GKE para seu serviço LoadBalancer interno. No entanto, o gerenciamento das regras de firewall da VPC é opcional, e você pode usar as regras automáticas.

   Antes de desativar a criação automática de regras de firewall da VPC, defina regras de permissão que permitam que o tráfego alcance o balanceador de carga e os pods de aplicativos.

   Para mais informações sobre como gerenciar regras de firewall da VPC, consulte gerenciar a criação automática de regras de firewall e, para saber como desativar a criação automática de regras de firewall, consulte Regras de firewall gerenciadas pelo usuário para serviços do LoadBalancer do GKE.

2. O exemplo a seguir cria um serviço LoadBalancer interno usando a porta TCP 80. O GKE implanta um balanceador de carga de rede de passagem interna cuja regra de encaminhamento usa a porta 80, mas encaminha o tráfego para pods de back-end na porta 8080:

   1. Salve o manifesto como ilb-svc.yaml:

      apiVersion: v1
      kind: Service
      metadata:
        name: ilb-svc
        # Request an internal load balancer.
        annotations:
          networking.gke.io/load-balancer-type: "Internal"
      spec:
        type: LoadBalancer
        # Evenly route external traffic to all endpoints.
        externalTrafficPolicy: Cluster
        # Prioritize routing traffic to endpoints that are in the same zone.
        trafficDistribution: PreferClose
        selector:
          app: ilb-deployment
        # Forward traffic from TCP port 80 to port 8080 in backend Pods.
        ports:
        - name: tcp-port
          protocol: TCP
          port: 80
          targetPort: 8080
      

      Seu manifesto deve conter o seguinte:

      • Um name para o serviço LoadBalancer interno, neste caso ilb-svc.
      • Uma anotação que especifica que você precisa de um serviço LoadBalancer interno. Para as versões 1.17 e posteriores do GKE, use a anotação networking.gke.io/load-balancer-type: "Internal", conforme mostrado no manifesto de exemplo. Para versões anteriores, use cloud.google.com/load-balancer-type: "Internal".
      • O type: LoadBalancer.
      • Um campo spec: selector para especificar os pods que o serviço deve segmentar, por exemplo, app: hello.
      • Informações da porta:
        • port representa a porta de destino em que a regra de encaminhamento do balanceador de carga de rede de passagem interna recebe pacotes.
        • O targetPort precisa corresponder a um containerPort definido em cada pod de exibição.
        • Os valores port e targetPort não precisam ser iguais. Os nós sempre executam o NAT de destino, alterando o endereço IP da regra de encaminhamento do balanceador de carga de destino e port para um endereço IP do pod de destino e targetPort. Para mais detalhes, consulte Conversão de endereços de rede de destino em nós na documentação de conceitos do serviço LoadBalancer.

      O manifesto pode conter o seguinte:

      • spec.ipFamilyPolicy e ipFamilies para definir como o GKE aloca endereços IP para o serviço. O GKE é compatível com serviços de LoadBalancer de pilha única (somente IPv4 ou IPv6) ou de pilha dupla de IP. Um serviço LoadBalancer de duas pilhas é implementado com duas regras de encaminhamento do balanceador de carga de rede de passagem interno: uma para o tráfego IPv4 e outra para o tráfego IPv6. O serviço LoadBalancer de pilha dupla do GKE está disponível na versão 1.29 ou mais recente. Para saber mais, consulte Serviços de pilha dupla IPv4/IPv6.

      • spec.trafficDistribution para definir como o GKE roteia o tráfego de entrada (visualização). Se você definir esse campo como PreferClose, o GKE vai encaminhar o tráfego originado de uma zona para nós e pods dentro dessa mesma zona. Se não houver pods íntegros na zona, o GKE vai rotear o tráfego para outra zona. Se você incluir esse campo, o subconjunto do GKE precisará estar ativado.

        Observação: também é possível ativar ou desativar a afinidade zonal em um serviço LoadBalancer interno usando o comando kubectl edit svc service-name. O comando kubectl edit abre o manifesto do serviço do balanceador de carga atual no editor de texto configurado, onde você pode adicionar ou remover o parâmetro spec.trafficDistribution e salvar as mudanças. O tráfego pode ser brevemente interrompido ao modificar esse parâmetro.

      Para mais informações, consulte Parâmetros de serviço do LoadBalancer.

   2. Aplique o manifesto ao cluster:

      kubectl apply -f ilb-svc.yaml
      

3. Veja informações detalhadas sobre o serviço:

   kubectl get service ilb-svc --output yaml
   

   O resultado será assim:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       cloud.google.com/neg: '{"ingress":true}'
       cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
       networking.gke.io/load-balancer-type: Internal
       service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
       service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
       service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
     creationTimestamp: "2022-07-22T17:26:04Z"
     finalizers:
     - gke.networking.io/l4-ilb-v2
     - service.kubernetes.io/load-balancer-cleanup
     name: ilb-svc
     namespace: default
     resourceVersion: "51666"
     uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
   spec:
     allocateLoadBalancerNodePorts: true
     clusterIP: 10.88.2.141
     clusterIPs:
     - 10.88.2.141
     externalTrafficPolicy: Cluster
     internalTrafficPolicy: Cluster
     ipFamilies:
     - IPv4
     ipFamilyPolicy: SingleStack
     ports:
     - name: tcp-port
       # Kubernetes automatically allocates a port on the node during the
       # process of implementing a Service of type LoadBalancer.
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     trafficDistribution: PreferClose
     type: LoadBalancer
   status:
     # IP address of the load balancer forwarding rule.
     loadBalancer:
       ingress:
       - ip: 10.128.15.245
   

   A saída tem os seguintes atributos:

   • O endereço IP da regra de encaminhamento do balanceador de carga de rede de passagem interna está incluído em status.loadBalancer.ingress. Esse endereço IP é diferente do valor de clusterIP. Neste exemplo, o endereço IP da regra de encaminhamento do balanceador de carga é 10.128.15.245.
   • Qualquer pod que tenha o rótulo app: ilb-deployment é um pod de exibição para este serviço. Esses são os pods que recebem pacotes roteados pelo balanceador de carga de rede de passagem interna.
   • Os clientes chamam o serviço usando o endereço IP loadBalancer e a porta TCP de destino especificada no campo port do manifesto do serviço. Para detalhes completos sobre como os pacotes são roteados depois de recebidos por um nó, consulte Processamento de pacotes.
   • O GKE atribuiu um nodePort ao Serviço. Neste exemplo, a porta 30521 foi atribuída. O nodePort não é relevante para o balanceador de carga de rede de passagem interna.

4. Inspecione o grupo de endpoints da rede de serviço:

   kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
   

   O resultado será assim:

   {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
   

   A resposta indica que o GKE criou um grupo de endpoints de rede chamado k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Essa anotação está presente em serviços do tipo LoadBalancer que usam a criação do GKE e não está presente em serviços que não usam o subconjunto do GKE.

Verificar os componentes do balanceador de carga de rede de passagem interna

Nesta seção, mostramos como verificar os principais componentes do balanceador de carga de rede de passagem interna.

• Verifique se o serviço está em execução:

  kubectl get service SERVICE_NAME --output yaml
  

  Substitua SERVICE_NAME pelo nome do manifesto do serviço.

  Se você ativou a afinidade zonal, a saída vai incluir o parâmetro spec.trafficDistribution com o campo definido como PreferClose.

• Verifique o endereço IP da regra de encaminhamento do balanceador de carga de rede de passagem interna. O endereço IP da regra de encaminhamento do balanceador de carga de rede de passagem interna é 10.128.15.245 no exemplo incluído na seção Criar um serviço LoadBalancer interno. Verifique se essa regra de encaminhamento está incluída na lista de regras de encaminhamento no projeto do cluster usando a Google Cloud CLI:

  gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
  

  A saída inclui a regra de encaminhamento do balanceador de carga de rede interno relevante, o endereço IP e o serviço de back-end referenciado pela regra de encaminhamento (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r neste exemplo).

  NAME                          ... IP_ADDRESS  ... TARGET
  ...
  k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  

• Descreva o serviço de back-end do balanceador de carga usando a Google Cloud CLI:

  gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
  

  Substitua COMPUTE_REGION pela região do Compute do serviço de back-end.

  Se você ativou a afinidade zonal:

  • O campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover precisa ser definido como ZONAL_AFFINITY_SPILL_CROSS_ZONE.
  • O campo networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio precisa ser definido como 0 ou não ser incluído.

  A saída inclui o NEG ou NEGs GCE_VM_IP de back-end para o Serviço (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r neste exemplo).

  backends:
  - balancingMode: CONNECTION
    group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
  ...
  kind: compute#backendService
  loadBalancingScheme: INTERNAL
  name: aae3e263abe0911e9b32a42010a80008
  networkPassThroughLbTrafficPolicy:
    zonalAffinity:
      spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
  protocol: TCP
  ...
  

  Se você desativou a afinidade zonal, o campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover precisa ser definido como ZONAL_AFFINITY_DISABLED ou não ser incluído. A afinidade zonal é desativada automaticamente se o cluster estiver em uma versão anterior a 1.33.3-gke.1392000.

• Determine a lista de nós em um subconjunto de um serviço:

  gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
      --zone=COMPUTE_ZONE
  

  Substitua:

  • NEG_NAME: o nome do grupo de endpoints de rede criado pelo controlador do GKE;
  • COMPUTE_ZONE: a zona do Compute grupo de endpoints da rede em que operar.

• Determine a lista de nós íntegros de um balanceador de carga de rede de passagem interna:

  gcloud compute backend-services get-health SERVICE_NAME \
      --region=COMPUTE_REGION
  

  Substitua:

  • SERVICE_NAME: o nome do serviço de back-end. Esse valor é igual ao nome do grupo de endpoints da rede criado pelo controlador do GKE.
  • COMPUTE_REGION: a região Compute em que o serviço de back-end será operado.

Testar a conectividade com o balanceador de carga de rede de passagem interna

Execute o seguinte comando na mesma região do cluster:

curl LOAD_BALANCER_IP:80

Substitua LOAD_BALANCER_IP pelo endereço IP da regra de encaminhamento do balanceador de carga.

A resposta mostra a saída de ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

O balanceador de carga de rede de passagem interna só é acessível na mesma rede VPC (ou em uma rede conectada). Por padrão, a regra de encaminhamento do balanceador de carga tem acesso global desativado. Portanto, as VMs clientes, os túneis do Cloud VPN ou os anexos do Cloud Interconnect (VLANs) precisam estar localizados na mesma região que o balanceador de carga de rede de passagem interno. Para oferecer suporte a clientes em todas as regiões, ative o acesso global na regra de encaminhamento do balanceador de carga incluindo a anotação de acesso global no manifesto do serviço.

Excluir os recursos internos do serviço LoadBalancer e do balanceador de carga

É possível excluir a implantação e o serviço usando kubectl delete ou o consoleGoogle Cloud .

kubectl

Excluir a implantação

Para excluir a implantação, execute o comando a seguir:

kubectl delete deployment ilb-deployment

Excluir o serviço

Para excluir o serviço, execute o seguinte comando:

kubectl delete service ilb-svc

Console

Excluir a implantação

Para excluir a implantação, execute as seguintes etapas:

1. Acesse a página Cargas de trabalho no console Google Cloud .

   Acesse "Cargas de trabalho"

2. Selecione a implantação que você quer excluir e clique em Excluir.

3. Quando solicitado a confirmar, marque a caixa de seleção Excluir escalonador automático de pod horizontal associado à implantação selecionada e clique em Excluir.

Excluir o serviço

Para excluir o serviço, execute as seguintes etapas:

1. Acesse a página Serviços e entradas no console Google Cloud .

   Acesse "Serviços e Entrada"

2. Selecione o serviço que você quer excluir e clique em Excluir.

3. Quando precisar confirmar, clique em Excluir.

IP compartilhado

O balanceador de carga de rede de passagem interna permite o compartilhamento de um endereço IP virtual entre várias regras de encaminhamento. Isso é útil para ampliar o número de portas simultâneas no mesmo IP ou para aceitar tráfego UDP e TCP no mesmo IP. Ele permite até 50 portas expostas por endereço IP. Os IPs compartilhados são compatíveis nativamente em Clusters do GKE com Serviços LoadBalancer internos. Ao realizar a implantação, o campo loadBalancerIP do Serviço é usado para indicar qual IP deve ser compartilhado entre os Serviços.

Limitações

Um IP compartilhado para vários balanceadores de carga tem as seguintes limitações e recursos:

• Cada regra de encaminhamento pode ter até cinco portas (contíguas ou não contíguas) ou ser configurada para corresponder e encaminhar o tráfego em todas as portas. Se um serviço Internal LoadBalancer definir mais de cinco portas, a regra de encaminhamento será definida automaticamente para corresponder a todas as portas.
• Dez Serviços (regras de encaminhamento), no máximo, podem compartilhar um endereço IP. Isso resulta em um máximo de 50 portas por IP compartilhado.
• Cada regra de encaminhamento que compartilha o mesmo endereço IP deve usar uma combinação exclusiva de protocolos e portas. Portanto, todo serviço LoadBalancer interno precisa usar um conjunto exclusivo de protocolos e portas.
• Uma combinação de Serviços somente TCP e UDP é compatível com o mesmo IP compartilhado. No entanto, não é possível expor as portas TCP e UDP no mesmo Serviço.

Como ativar o IP compartilhado

Para ativar um Serviço LoadBalancer interno para compartilhar um IP comum, siga estas etapas:

1. Crie um IP interno estático com --purpose SHARED_LOADBALANCER_VIP. Um endereço IP precisa ser criado com essa finalidade para poder ser compartilhado. Se você criar o endereço IP interno estático em uma VPC compartilhada, será necessário criá-lo no mesmo projeto de serviço da instância que usará o endereço IP, mesmo que o valor desse endereço venha do intervalo de IPs disponíveis em uma sub-rede compartilhada selecionada da rede VPC compartilhada. Para mais informações, consulte como reservar um IP interno estático na página Como provisionar a VPC compartilhada.

2. Implante até dez Serviços LoadBalancer internos usando esse IP estático no campo loadBalancerIP. Os balanceadores de carga de rede de passagem internos são reconciliados pelo controlador de serviços do GKE e implantados usando o mesmo IP de front-end.

O exemplo a seguir demonstra como isso é feito para oferecer suporte a várias portas TCP e UDP em relação ao mesmo IP de balanceador de carga interno.

1. Crie um IP estático na mesma região do Cluster do GKE. A sub-rede precisa ser a mesma usada pelo balanceador de carga, que por padrão é a mesma sub-rede usada pelos IPs de nós dos Clusters do GKE.

   Se o cluster e a rede VPC estiverem no mesmo projeto:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=PROJECT_ID \
       --subnet=SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Se o cluster estiver em um projeto de serviço de VPC compartilhada, mas usar uma rede VPC compartilhada em um projeto host:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=SERVICE_PROJECT_ID \
       --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Substitua:

   • IP_ADDR_NAME: um nome para o objeto de endereço IP.
   • SERVICE_PROJECT_ID: o ID do projeto de serviço.
   • PROJECT_ID: o ID do projeto (projeto único).
   • HOST_PROJECT_ID: o ID do projeto host da VPC compartilhada.
   • COMPUTE_REGION: a região do Compute que contém a sub-rede compartilhada.
   • IP_ADDRESS: um endereço IP interno não utilizado do intervalo de endereços IP principal da sub-rede selecionada. Se você omitir a especificação de um endereço IP,o Google Cloud selecionará um endereço IP interno não utilizado do intervalo de endereços IP primário da sub-rede selecionada. Para determinar um endereço selecionado automaticamente, execute gcloud compute addresses describe.
   • SUBNET: o nome da sub-rede compartilhada.

2. Salve a seguinte configuração do Serviço TCP em um arquivo chamado tcp-service.yaml e, depois, faça a implantação no cluster. Substitua IP_ADDRESS pelo endereço IP escolhido na etapa anterior.

   apiVersion: v1
   kind: Service
   metadata:
     name: tcp-service
     namespace: default
     # Request an internal load balancer.
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     type: LoadBalancer
     # Use an IP address that you create.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: myapp
     ports:
     - name: 8001-to-8001
       protocol: TCP
       port: 8001
       targetPort: 8001
     - name: 8002-to-8002
       protocol: TCP
       port: 8002
       targetPort: 8002
     - name: 8003-to-8003
       protocol: TCP
       port: 8003
       targetPort: 8003
     - name: 8004-to-8004
       protocol: TCP
       port: 8004
       targetPort: 8004
     - name: 8005-to-8005
       protocol: TCP
       port: 8005
       targetPort: 8005
   

3. Aplique esta definição de Serviço ao cluster:

   kubectl apply -f tcp-service.yaml
   

4. Salve a seguinte configuração do Serviço UDP em um arquivo chamado udp-service.yaml e, depois, faça a implantação. Ele também usa o IP_ADDRESS que você especificou na etapa anterior.

   apiVersion: v1
   kind: Service
   metadata:
     name: udp-service
     namespace: default
     # Request an internal load balancer.
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     type: LoadBalancer
     # Use the same IP address that you used for the TCP Service.
     loadBalancerIP: IP_ADDRESS
     selector:
       app: my-udp-app
     ports:
     - name: 9001-to-9001
       protocol: UDP
       port: 9001
       targetPort: 9001
     - name: 9002-to-9002
       protocol: UDP
       port: 9002
       targetPort: 9002
   

5. Aplique este arquivo no cluster:

   kubectl apply -f udp-service.yaml
   

6. Valide se o VIP é compartilhado entre as regras de encaminhamento do balanceador de carga listando essas regras e filtrando o IP estático. Isso mostra que há um UDP e uma regra de encaminhamento de TCP que realizam detecções em sete portas diferentes no IP_ADDRESS compartilhado, que neste exemplo é 10.128.2.98.

   gcloud compute forwarding-rules list | grep 10.128.2.98
   ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
   acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
   

Problemas conhecidos

Tempo limite de conexão a cada 10 minutos

Os serviços LoadBalancer internos criados com a configuração de subconjuntos podem observar interrupções de tráfego aproximadamente a cada 10 minutos. Esse bug foi corrigido nas versões:

• 1.18.19-gke.1700 e superior
• 1.19.10-gke.1000 e superior
• 1.20.6-gke.1000 e superior

Erro ao criar o balanceador de carga no nível Standard

Quando você cria um balanceador de carga de rede de passagem interno em um projeto com o nível de rede padrão do projeto definido como Padrão, a seguinte mensagem de erro é exibida:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Para resolver esse problema nas versões do GKE anteriores à 1.23.3-gke.900, configure o nível de rede padrão do projeto para Premium.

Esse problema é resolvido nas versões 1.23.3-gke.900 e posteriores do GKE quando a criação de subconjuntos do GKE está ativada.

O controlador do GKE cria balanceadores de carga de rede de passagem internos no nível de rede Premium, mesmo que o nível de rede padrão do projeto esteja definido como Padrão.

A seguir

• Leia a visão geral da rede GKE.
• Saiba mais sobre balanceadores de carga do Compute Engine.
• Saiba como criar um cluster nativo de VPC.
• Resolver problemas de balanceamento de carga no GKE.
• Saiba mais sobre o agente de mascaramento de IP.
• Saiba sobre como configurar redes autorizadas.