criar um balanceador de carga interno

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 externo, saiba como Criar um serviço do tipo LoadBalancer.

Como usar a subconfiguração do 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 na rede VPC do cluster e a clientes em redes conectadas à rede VPC do cluster. Os clientes não precisam estar localizados no seu cluster. Por exemplo, um serviço LoadBalancer interno pode ser acessível a instâncias de máquina virtual (VM) localizadas na rede VPC do cluster.

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 é ativada, ele cria um NEG por zona de computação por serviço LoadBalancer interno. Os endpoints de membro no NEG são os endereços IP dos nós que têm pelo menos um dos pods de exibição do serviço. Para mais informações sobre a criação de subconjuntos do GKE, consulte Agrupamento de nós.

Requisitos e limitações

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 subconfiguração do GKE está desativada nos clusters do Autopilot.
  • 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

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 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 gcloud components update.

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

É possível criar um cluster do Standard com a subconfiguração do GKE ativada usando a CLI do Google Cloud, o console do Google Cloud ou o Terraform. Um cluster criado com a subconfiguração do GKE ativada sempre usa essa subconfiguração.

Console

  1. Acesse a página Google Kubernetes Engine no console do Google Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Configure o cluster como quiser.

  4. No painel de navegação, em Cluster, clique em Rede.

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

  6. Clique em Criar.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

Substitua:

  • CLUSTER_NAME: o nome do novo cluster;
  • VERSION: a versão do GKE, que precisa ser 1.18.19-gke.1400 ou posterior. Também é possível usar a opção --release-channel para selecionar um canal de lançamento. O canal de lançamento precisa ter uma versão padrão 1.18.19-gke.1400 ou posterior.
  • COMPUTE_LOCATION: a região do Compute Engine para o cluster.

Se você quiser usar uma rede ou sub-rede que não seja a padrão, execute o seguinte comando:

  gcloud container clusters create CLUSTER_NAME \
      --cluster-version=VERSION \
      --network NETWORK_NAME \
      --subnetwork SUBNETWORK_NAME \
      --enable-l4-ilb-subsetting \
      --location=COMPUTE_LOCATION

Substitua:

  • SUBNET_NAME: o nome da nova sub-rede; Nas versões 1.22.4-gke.100 e posteriores do GKE, é possível especificar uma sub-rede em um projeto diferente usando o URL de recurso totalmente qualificado para esse campo. Você pode conseguir o URL do recurso totalmente qualificado usando o comando gcloud compute networks subnets describe.
  • NETWORK_NAME: o nome da rede VPC da sub-rede;

Terraform

Para criar um cluster do Standard com a subconfiguração do GKE ativada usando o Terraform, consulte o exemplo a seguir:

resource "google_container_cluster" "default" {
  name               = "gke-standard-regional-cluster"
  location           = "us-central1"
  initial_node_count = 1

  enable_l4_ilb_subsetting = true

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

Para saber mais como usar o Terraform, consulte o Suporte do Terraform para GKE.

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

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

Console

  1. No Console do Google Cloud, acesse a página do 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

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 em que a regra de encaminhamento usa a porta 80, mas, em seguida, encaminha o tráfego para os pods de back-end na porta 8080:

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

    apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster
  selector:
    app: ilb-deployment
  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.

    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
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  type: LoadBalancer
status:
  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

O endereço IP da regra de encaminhamento do balanceador de carga de rede de passagem interno é 10.128.15.245 no exemplo incluído na seção Criar um serviço LoadBalancer interno. É possível ver que 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

É possível descrever 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.

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

Para determinar a lista de nós em um subconjunto de um serviço, use o comando a seguir:

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.

Para determinar a lista de nós íntegros de um balanceador de carga de rede de passagem interna, use o seguinte comando:

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

Conecte-se por SSH a uma instância de VM na mesma rede VPC e na mesma região do cluster e, em seguida, execute o seguinte comando:

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 console do Google 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 do 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 do 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 Serviço (ou regra de encaminhamento) pode ter, no máximo, cinco 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
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  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
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  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

Restrições e limites

Restrições para 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.

Restrições para balanceadores de carga UDP internos

  • Os balanceadores de carga UDP internos não aceitam o uso de sessionAffinity: ClientIP.

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