criar um balanceador de carga interno

Nesta página, mostramos como implantar um serviço LoadBalancer interno que cria um balanceador de carga de rede de passagem interna. Antes de ler esta página, confira se você conhece os seguintes conceitos:

Para saber mais sobre balanceadores de carga de rede de passagem interna em geral, consulte Visão geral do balanceador de carga de rede de passagem interna.

Antes de começar

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

  • Ative a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

Requisitos

  • Este tutorial usa spec.loadBalancerClass para criar um balanceador de carga de rede de passagem interno com back-ends de NEG GCE_VM_IP. Este tutorial requer o GKE versão 1.33.1-gke.1779000 ou mais recente porque spec.loadBalancerClass exige o GKE versão 1.33.1-gke.1779000 ou mais recente.

  • A afinidade zonal requer o GKE versão 1.33.3-gke.1392000 e mais recente.

  • Seu cluster precisa ter a subconfiguração do GKE ativada:

    • A subdivisão do GKE é ativada por padrão em clusters que executam a versão 1.36 e mais recentes. Para essas versões, o subagrupamento fica ativo independente do valor da flag de subagrupamento do cluster.

    • Em versões compatíveis do GKE anteriores à 1.36, é necessário ativar a criação de subconjuntos do GKE explicitamente. É possível ativar a subconfiguração do GKE ao criar ou atualizar um cluster. Depois de ativada, não é possível desativar a criação de subconjuntos do GKE. Para mais informações, consulte Verificar e ativar a inclusão de subconjuntos do GKE.

  • Se o cluster estiver em uma versão anterior à 1.36, o complemento HttpLoadBalancing precisa ser ativado. Esse complemento é ativado por padrão.

Verificar e ativar o subagrupamento do GKE

Verifique se o subagrupamento do GKE está ativado:

  • A criação de subconjuntos do GKE está sempre ativada na versão 1.36 e mais recentes do GKE.

  • É possível ativar a criação de subconjuntos do GKE manualmente em clusters Standard e do Autopilot novos e atuais que executam o GKE versão 1.18.19-gke.1400 e posterior, mas antes da versão 1.36 do GKE. Não é possível desativar a criação de subconjuntos do GKE depois de ativá-la.

Para saber por que a subcriação do GKE é importante, consulte Considerações especiais para serviços LoadBalancer internos.

Para determinar se o subconjunto do GKE está ativado, execute o seguinte comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION : a zona ou região do cluster.

A saída do comando mostra a versão do plano de controle do cluster seguida por True ou False para o atributo networkConfig.enableL4ilbSubsetting. Interprete a saída da seguinte maneira:

  • Se a versão do plano de controle for 1.36 ou mais recente, o subconjunto do GKE será ativado, independente de o atributo networkConfig.enableL4ilbSubsetting ser True ou False.
  • Se a versão do plano de controle for anterior a 1.36:
    • True significa que a subconfiguração do GKE está ativada.
    • False significa que a subconfiguração do GKE está desativada.

Para ativar a criação de subconjuntos do GKE em um cluster que executa a versão 1.18.19-gke.1400 e posterior, mas antes da versão 1.36 do GKE, use a CLI gcloud ou o console Google Cloud .

Console

  1. No console do 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 \
    --location=LOCATION
    --enable-l4-ilb-subsetting

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION : a zona ou região do cluster.

Ativar a criação de subconjuntos do GKE usando a CLI gcloud, o Google Cloud console ou fazendo upgrade do cluster para a versão 1.36 ou mais recente não modifica os serviços LoadBalancer internos atuais. Se você quiser migrar um serviço LoadBalancer interno para usar back-ends NEG GCE_VM_IP, implante um manifesto de serviço substituto.

Implantar uma carga de trabalho

O manifesto a seguir descreve uma implantação que executa uma imagem de contêiner de aplicativo da Web de amostra.

  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 o 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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # 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.
      • O campo spec.loadBalancerClass definido como o valor networking.gke.io/l4-regional-internal para especificar um serviço LoadBalancer interno, conforme mostrado no manifesto de exemplo.
      • 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 (prévia) para definir como o GKE encaminha o tráfego de entrada. Para ativar a afinidade zonal, defina o valor desse campo como PreferSameZone. A afinidade zonal significa que o GKE prioriza o roteamento do tráfego originado de uma zona para nós e pods dentro dessa mesma zona. Se não houver pods íntegros disponíveis nessa zona, o tráfego será roteado para outra zona. Para versões de cluster anteriores a 1.35.0-gke.1811000, use PreferClose como valor. A afinidade zonal requer que a subconfiguração do GKE esteja ativada.

      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: PreferSameZone
  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 inclui o parâmetro spec.trafficDistribution. O valor desse campo é definido como PreferSameZone ou PreferClose se a versão do cluster for anterior a 1.35.0-gke.1811000.

  • 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 o valor 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 a confirmação for solicitada, 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 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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # 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 as seguintes configurações de 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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # 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

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