Crie um balanceador de carga interno

Esta página explica como criar um balanceador de carga de rede de encaminhamento interno ou um balanceador de carga interno no Google Kubernetes Engine (GKE). Para criar um balanceador de carga de rede de encaminhamento externo, consulte o artigo Crie um serviço do tipo LoadBalancer.

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

Usar o balanceador de carga de rede de encaminhamento interno

Os balanceadores de carga de rede de passagem internos tornam os serviços do seu cluster acessíveis aos clientes localizados na rede VPC do cluster e aos clientes em redes que estão ligadas à rede VPC do cluster. Os clientes na rede VPC do cluster podem ser nós ou pods do cluster, ou podem ser VMs fora do cluster. Para mais informações sobre a conetividade de clientes em redes ligadas, consulte o artigo Balanceadores de carga de passagem interna e redes ligadas.

Usar a subdivisão do GKE

A divisão em subconjuntos do GKE melhora a escalabilidade dos serviços LoadBalancer internos porque usa GCE_VM_IP grupos de pontos finais de rede (NEGs) como back-ends em vez de grupos de instâncias. Quando a restrição do GKE está ativada, o GKE cria um NEG por zona de computação por serviço de LoadBalancer interno.

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

Usar afinidade zonal

Quando ativa a afinidade zonal num Network Load Balancer de encaminhamento interno, o GKE encaminha o tráfego originário de uma zona para nós e pods nessa mesma zona. Se não existirem pods em bom estado na zona, o GKE encaminha o tráfego para outra zona. Esta implementação otimiza a latência e o custo.

Para ativar a afinidade zonal num cluster do GKE, tem de ter o subconjunto do GKE ativado.

Requisitos e limitações

Seguem-se os requisitos e as limitações para balanceadores de carga internos.

Requisitos

A subdivisão do GKE tem os seguintes requisitos e limitações:

  • Pode ativar a restrição de subconjuntos do GKE em clusters padrão novos e existentes nas versões 1.18.19-gke.1400 e posteriores do GKE. Não é possível desativar a subdivisão do GKE depois de ativada.
  • Por predefinição, a restrição de subconjuntos do GKE está desativada nos clusters do Autopilot. No entanto, pode ativá-lo depois de criar o cluster.
  • A restrição de subconjuntos do GKE requer que o suplemento HttpLoadBalancing esteja ativado. Este suplemento está ativado por predefinição. Nos clusters do Autopilot, não pode desativar este suplemento obrigatório.
  • Aplicam-se as quotas para grupos de pontos finais da rede. Google Cloud cria um GCE_VM_IP NEG por serviço de balanceador de carga interno por zona.
  • Aplicam-se quotas para regras de encaminhamento, serviços de back-end e verificações de funcionamento. Para mais informações, consulte o artigo Quotas e limites.
  • Não é possível usar a subdivisão do GKE com a anotação para partilhar um serviço de back-end entre vários balanceadores de cargaalpha.cloud.google.com/load-balancer-backend-share.
  • Tem de ter a versão 345.0.0 ou posterior da Google Cloud CLI.

A afinidade zonal tem os seguintes requisitos:

  • Pode ativar a afinidade zonal em clusters novos e existentes na versão 1.33.3-gke.1392000 e posterior do GKE.
  • Tem de ter a restrição de subconjuntos do GKE ativada.
  • Tem de garantir que o suplemento HttpLoadBalancing está ativado para o seu cluster. Este suplemento está ativado por predefinição e permite que o cluster faça a gestão dos equilibradores de carga que usam serviços de back-end.
  • Tem de 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 encaminhamento interno

  • Para clusters que executam a versão 1.7.4 do Kubernetes e posteriores, pode usar balanceadores de carga internos com sub-redes no modo personalizado, além de sub-redes no modo automático.
  • Os clusters que executam a versão 1.7.X e posterior do Kubernetes suportam a utilização de um endereço IP reservado para o equilibrador de carga de passagem interno se criar o endereço IP reservado com a flag --purpose definida como SHARED_LOADBALANCER_VIP. Consulte o artigo Ativar IP partilhado para ver instruções passo a passo. O GKE só preserva o endereço IP de um Network Load Balancer de passagem interno se o serviço fizer referência a um endereço IP interno com esse objetivo. Caso contrário, o GKE pode 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 mude (consulte o ponto anterior), o spec.clusterIP permanece constante.
  • Os balanceadores de carga UDP internos não suportam a utilização de sessionAffinity: ClientIP.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.
  • Certifique-se de que tem um cluster do Autopilot ou Standard existente. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.

Ative a seleção de subconjuntos do GKE num cluster

Pode ativar a subdivisão do GKE para um cluster existente através da CLI gcloud ou da Google Cloud consola. Não pode desativar a subdivisão do GKE depois de a ter ativado.

Consola

  1. Na Google Cloud consola, aceda à página Google Kubernetes Engine.

    Aceder ao Google Kubernetes Engine

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

  3. Em Rede, junto ao campo Subconjunto para balanceadores de carga internos de nível 4, clique em Ativar subconjunto para balanceadores de carga internos de nível 4.

  4. Selecione a caixa de verificação Ativar a criação de subconjuntos para balanceadores de carga internos de nível 4.

  5. Clique em Guardar alterações.

gcloud

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

Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster.

A ativação da subdivisão do GKE não interrompe os serviços LoadBalancer internos existentes. Se quiser migrar os serviços LoadBalancer internos existentes para usar serviços de back-end com NEGs GCE_VM_IP como back-ends, tem de implementar um manifesto de serviço de substituição. Para mais detalhes, consulte a secção Agrupamento de nós na documentação de conceitos do serviço LoadBalancer.

Implemente uma carga de trabalho

O manifesto seguinte descreve uma implementação que executa uma imagem de contentor de aplicação Web de exemplo.

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

Crie 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 da firewall da VPC para permitir o tráfego para o seu equilibrador de carga interno, tem a opção de desativar a criação automática de regras da firewall da VPC e gerir as regras da firewall por si. Só pode desativar as regras de firewall da VPC se tiver ativado a subdivisão do GKE para o seu serviço LoadBalancer interno. No entanto, a gestão das regras de firewall da VPC é opcional e pode confiar nas regras automáticas.

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

    Para mais informações sobre a gestão de regras da firewall da VPC, consulte o artigo Faça a gestão da criação automática de regras da firewall e, para saber como desativar a criação automática de regras da firewall, consulte o artigo Regras da firewall geridas pelo utilizador para serviços LoadBalancer do GKE.

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

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

      O manifesto tem de conter o seguinte:

      • Um name para o serviço LoadBalancer interno, neste caso, ilb-svc.
      • Uma anotação que especifica que 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 a política cloud.google.com/load-balancer-type: "Internal".
      • O type: LoadBalancer.
      • Um campo spec: selector para especificar os agrupamentos que o serviço deve segmentar, por exemplo, app: hello.
      • Informações da porta:
        • O elemento port representa a porta de destino na qual a regra de encaminhamento do balanceador de carga de rede de passagem interna recebe pacotes.
        • O targetPort tem de corresponder a um containerPort definido em cada agrupamento de serviço.
        • Os valores port e targetPort não têm de ser iguais. Os nós executam sempre 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 o artigo Tradução do endereço 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 atribui endereços IP ao serviço. O GKE suporta serviços de balanceamento de carga de IP de pilha única (apenas IPv4 ou apenas IPv6) ou de pilha dupla. Um serviço LoadBalancer de pilha dupla é implementado com duas regras de encaminhamento do balanceador de carga de rede de passagem interna separadas: uma para tráfego IPv4 e outra para tráfego IPv6. O serviço LoadBalancer de pilha dupla do GKE está disponível na versão 1.29 ou posterior. Para saber mais, consulte o artigo Serviços de pilha dupla IPv4/IPv6.

      • spec.trafficDistribution para definir como o GKE encaminha o tráfego recebido (pré-visualização). Se definir este campo como PreferClose, o GKE encaminha o tráfego que tem origem numa zona para nós e pods nessa mesma zona. Se não existirem pods em bom estado na zona, o GKE encaminha o tráfego para outra zona. Se incluir este campo, tem de ter a restrição de subconjuntos do GKE ativada.

      Para mais informações, consulte os parâmetros do serviço LoadBalancer

    2. Aplique o manifesto ao cluster:

      kubectl apply -f ilb-svc.yaml

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

    kubectl get service ilb-svc --output yaml

    O resultado é semelhante ao seguinte:

    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 interno está incluído em status.loadBalancer.ingress. Este 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 agrupamento com a etiqueta app: ilb-deployment é um agrupamento de publicação para este serviço. Estes são os pods que recebem pacotes encaminhados pelo balanceador de carga de rede de passagem interno.
    • Os clientes chamam o serviço através deste endereço IP loadBalancer e da porta de destino TCP especificada no campo port do manifesto do serviço. Para ver detalhes completos sobre como os pacotes são encaminhados assim que são recebidos por um nó, consulte o artigo Processamento de pacotes.
    • O GKE atribuiu um nodePort ao serviço. Neste exemplo, a porta 30521 é atribuída. O nodePort não é relevante para o balanceador de carga de rede de encaminhamento interno.

  4. Inspeccione o grupo de pontos finais da rede de serviços:

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

    O resultado é semelhante ao seguinte:

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

    A resposta indica que o GKE criou um grupo de pontos finais de rede com o nome k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Esta anotação está presente em serviços do tipo LoadBalancer que usam a subdivisão do GKE e não está presente em serviços que não usam a subdivisão do GKE.

Valide os componentes do balanceador de carga de encaminhamento interno

Esta secção mostra como validar os componentes principais do seu Network Load Balancer de encaminhamento interno.

  • 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 ativou a afinidade zonal, o resultado inclui o parâmetro spec.trafficDistribution com o campo definido como PreferClose.

  • Valide o endereço IP da regra de encaminhamento do balanceador de carga de rede de passagem interno. O endereço IP da regra de encaminhamento do balanceador de carga de rede de encaminhamento interno é 10.128.15.245 no exemplo incluído na secção Crie um serviço LoadBalancer interno. Verifique se esta regra de encaminhamento está incluída na lista de regras de encaminhamento no projeto do cluster através da CLI do Google Cloud:

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

    O resultado inclui a regra de encaminhamento do balanceador de carga de passagem interno relevante, o respetivo 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 através da CLI Google Cloud:

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

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

    Se ativou a afinidade zonal:

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

    O resultado inclui o NEG ou os NEGs de back-end para o serviço (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r neste exemplo).GCE_VM_IP

    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 desativou a afinidade zonal, o campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover deve ser definido como ZONAL_AFFINITY_DISABLED ou não ser incluído. Tenha em atenção que a afinidade zonal é desativada automaticamente se o seu cluster estiver numa versão anterior à 1.33.3-gke.1392000.

  • Determinar a lista de nós num subconjunto para um serviço:

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

    Substitua o seguinte:

    • NEG_NAME: o nome do grupo de pontos finais da rede criado pelo controlador do GKE.
    • COMPUTE_ZONE: a zona de computação do grupo de pontos finais de rede no qual operar.

  • Determine a lista de nós em bom estado para um balanceador de carga de rede de encaminhamento interno:

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

    Substitua o seguinte:

    • SERVICE_NAME: o nome do serviço de back-end. Este valor é igual ao nome do grupo de pontos finais de rede criado pelo controlador do GKE.
    • COMPUTE_REGION: a região de computação do serviço de back-end no qual operar.

Teste a conetividade ao balanceador de carga de encaminhamento interno

Execute o seguinte comando na mesma região que o 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 o resultado de ilb-deployment:

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

O balanceador de carga de rede de passagem interno só é acessível na mesma rede da VPC (ou numa rede ligada). Por predefinição, a regra de encaminhamento do balanceador de carga tem o acesso global desativado. Por isso, as VMs do cliente, os túneis da Cloud VPN ou os anexos do Cloud Interconnect (VLANs) têm de estar localizados na mesma região que o Network Load Balancer de passagem interno. Para suportar clientes em todas as regiões, pode ativar o acesso global na regra de encaminhamento do balanceador de carga incluindo a anotação global access no manifesto do serviço.

Elimine o serviço LoadBalancer interno e os recursos do balanceador de carga

Pode eliminar a implementação e o serviço através da kubectl delete ou da consolaGoogle Cloud .

kubectl

Elimine a implementação

Para eliminar a implementação, execute o seguinte comando:

kubectl delete deployment ilb-deployment

Elimine o serviço

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

kubectl delete service ilb-svc

Consola

Elimine a implementação

Para eliminar a implementação, siga os passos abaixo:

  1. Aceda à página Workloads na Google Cloud consola.

    Aceda a Cargas de trabalho

  2. Selecione a implementação que quer eliminar e, de seguida, clique em Eliminar.

  3. Quando lhe for pedido para confirmar, selecione a caixa de verificação Eliminar Horizontal Pod Autoscaler associado à implementação selecionada e, de seguida, clique em Eliminar.

Elimine o serviço

Para eliminar o serviço, siga estes passos:

  1. Aceda à página Serviços e entrada na Google Cloud consola.

    Aceda a Serviços e entrada

  2. Selecione o serviço que quer eliminar e, de seguida, clique em Eliminar.

  3. Quando lhe for pedido que confirme, clique em Eliminar.

IP partilhado

O Network Load Balancer de passagem interno permite a partilha de um endereço IP virtual entre várias regras de encaminhamento. Isto é útil para expandir o número de portas simultâneas no mesmo IP ou para aceitar tráfego UDP e TCP no mesmo IP. Permite um máximo de 50 portas expostas por endereço IP. Os IPs partilhados são suportados nativamente em clusters do GKE com serviços de LoadBalancer internos. Durante a implementação, o campo loadBalancerIP do serviço é usado para indicar que IP deve ser partilhado entre serviços.

Limitações

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

  • Cada regra de encaminhamento pode ter até cinco portas (contíguas ou não contíguas) ou pode ser configurada para corresponder e encaminhar tráfego em todas as portas. Se um serviço de balanceamento de carga interno definir mais de cinco portas, a regra de encaminhamento é automaticamente definida para corresponder a todas as portas.
  • Um máximo de dez serviços (regras de encaminhamento) podem partilhar um endereço IP. Isto resulta num máximo de 50 portas por IP partilhado.
  • Cada regra de encaminhamento que partilha o mesmo endereço IP tem de usar uma combinação única de protocolos e portas. Por conseguinte, cada serviço LoadBalancer interno tem de usar um conjunto único de protocolos e portas.
  • É suportada uma combinação de serviços apenas TCP e apenas UDP no mesmo IP partilhado. No entanto, não pode expor portas TCP e UDP no mesmo serviço.

Ativar IP partilhado

Para permitir que os serviços LoadBalancer internos partilhem um IP comum, siga estes passos:

  1. Crie um IP interno estático com --purpose SHARED_LOADBALANCER_VIP. Tem de criar um endereço IP com este objetivo para permitir a sua partilha. Se criar o endereço IP interno estático numa VPC partilhada, tem de criar o endereço IP no mesmo projeto de serviço que a instância que vai usar o endereço IP, mesmo que o valor do endereço IP seja proveniente do intervalo de IPs disponíveis numa sub-rede partilhada selecionada da rede VPC partilhada. Consulte o artigo sobre reservar um IP interno estático na página Aprovisionamento da VPC partilhada para mais informações.

  2. Implemente até dez serviços LoadBalancer internos através deste IP estático no campo loadBalancerIP. Os balanceadores de carga de rede de passagem interna são reconciliados pelo controlador de serviço do GKE e implementados com o mesmo IP de front-end.

O exemplo seguinte demonstra como isto é feito para suportar várias portas TCP e UDP no mesmo IP do balanceador de carga interno.

  1. Crie um IP estático na mesma região que o cluster do GKE. A sub-rede tem de ser a mesma que o equilibrador de carga usa, que, por predefinição, é a mesma que os IPs dos nós do cluster do GKE usam.

    Se o cluster e a rede de 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 num projeto de serviço de VPC partilhada, mas usar uma rede de VPC partilhada num projeto anfitrião:

    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 o seguinte:

    • 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 seu projeto (projeto único).
    • HOST_PROJECT_ID: o ID do projeto anfitrião da VPC partilhada.
    • COMPUTE_REGION: a região de computação que contém a sub-rede partilhada.
    • IP_ADDRESS: um endereço IP interno não usado do intervalo de endereços IP principal da sub-rede selecionada. Se omitir a especificação de um endereço IP,o sistema seleciona um endereço IP interno não utilizado do intervalo de endereços IP principal da sub-rede selecionada. Google Cloud Para determinar uma morada selecionada automaticamente, tem de executar gcloud compute addresses describe.
    • SUBNET: o nome da sub-rede partilhada.

  2. Guarde a seguinte configuração do serviço TCP num ficheiro denominado tcp-service.yaml e, em seguida, implemente-o no cluster. Substitua IP_ADDRESS pelo endereço IP que escolheu no passo 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 seu cluster:

    kubectl apply -f tcp-service.yaml

  4. Guarde a seguinte configuração do serviço UDP num ficheiro com o nome udp-service.yaml e, em seguida, implemente-o. Também usa o IP_ADDRESS que especificou no passo 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 ficheiro ao seu cluster:

    kubectl apply -f udp-service.yaml

  6. Valide se o VIP é partilhado entre as regras de encaminhamento do balanceador de carga: liste-as e filtre-as pelo IP estático. Isto mostra que existe uma regra de encaminhamento UDP e TCP a ouvir em sete portas diferentes no IP_ADDRESS partilhado, 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

Limite de tempo da ligação a cada 10 minutos

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

  • 1.18.19-gke.1700 e posteriores
  • 1.19.10-gke.1000 e posterior
  • 1.20.6-gke.1000 e posterior

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

Quando cria um Network Load Balancer de encaminhamento interno num projeto com o nível de rede predefinido do projeto definido como Standard, é apresentada a seguinte mensagem de erro:

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 este problema em versões do GKE anteriores a 1.23.3-gke.900, configure o nível de rede predefinido do projeto como Premium.

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

O controlador do GKE cria equilibradores de carga de rede de passagem internos no nível de rede Premium, mesmo que o nível de rede predefinido do projeto esteja definido como Standard.

O que se segue?