Como usar um balanceador de carga TCP/UDP interno

Nesta página, você entenderá como criar um balanceador de carga TCP/UDP interno do Compute Engine no Google Kubernetes Engine.

Visão geral

O balanceamento de carga TCP/UDP interno torna os serviços do cluster acessíveis a aplicativos fora do cluster que usam a mesma rede VPC e estão localizados na mesma região do Google Cloud. Por exemplo, suponha que você tem um cluster na região us-west1 e precisa tornar um dos serviços acessíveis para as instâncias da VM do Compute Engine em execução nessa região na mesma rede VPC.

Crie um recurso Services com a anotação cloud.google.com/load-balancer-type: "Internal" e uma especificação type: LoadBalancer para criar um balanceador de carga TCP/UDP interno. As instruções e o exemplo abaixo destacam como fazer isso.

Sem o balanceamento de carga TCP/UDP interno, você precisaria configurar um balanceador de carga externo e regras de firewall para tornar o aplicativo acessível fora do cluster.

O balanceamento de carga TCP/UDP interno cria um endereço IP interno para o serviço que recebe tráfego de clientes na mesma rede VPC e região de computação. Se você ativar o acesso global, os clientes em qualquer região da mesma rede VPC poderão acessar o serviço. Além disso, os clientes em uma rede VPC conectada à rede LoadBalancer usando peering de rede VPC também podem acessar o serviço.

Preços

Você é cobrado pelo modelo de preços do Compute Engine. Para saber mais, consulte os preços de regras de encaminhamento e balanceamento de carga e a página do Compute Engine com a calculadora de preços do Google Cloud.

Antes de começar

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

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar a gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine.

Como usar o gcloud config

  • Defina o ID do projeto padrão: 
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão: 
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão: 
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente: 
    gcloud components update

Criar uma implantação

O manifesto a seguir descreve uma implantação que executa três réplicas de um aplicativo Hello World.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"

O código-fonte e o Dockerfile para este aplicativo de exemplo estão disponíveis no GitHub. Como nenhuma variável de ambiente PORT foi especificada, os contêineres escutam na porta padrão: 8080.

Para criar a implantação, crie o arquivo my-deployment.yaml do manifesto e execute o seguinte comando no shell ou na janela de terminal:

kubectl apply -f my-deployment.yaml

Criar um balanceador de carga TCP interno

As seções a seguir explicam como criar um balanceador de carga TCP interno usando um serviço.

Gravar o arquivo de configuração do serviço

Veja a seguir um exemplo de serviço que cria um balanceador de carga TCP interno:

apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
  labels:
    app: hello
spec:
  type: LoadBalancer
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Requisitos mínimos de serviço

Seu manifesto deve conter o seguinte:

  • Um name para o Serviço, neste caso ilb-service.
  • A anotação: cloud.google.com/load-balancer-type: "Internal", que especifica que deve-se configurar um balanceador de carga TCP/UDP interno.
  • O type: LoadBalancer.
  • Um campo spec: selector para especificar os pods que o serviço deve segmentar, por exemplo, app: hello.
  • O port, a porta pela qual o serviço é exposto, e targetPort, a porta na qual os contêineres estão escutando.

Como implantar o serviço

Para criar o balanceador de carga TCP interno, crie o arquivo my-service.yaml do manifesto e execute o seguinte comando no shell ou na janela de terminal:

kubectl apply -f my-service.yaml

Como inspecionar o serviço

Após a implantação, inspecione o serviço para verificar se ele foi configurado com êxito.

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

kubectl get service ilb-service --output yaml

Na saída, você pode ver o endereço IP do balanceador de carga interno em status.loadBalancer.ingress. Observe que isso é diferente do valor de clusterIP. Neste exemplo, o endereço IP do balanceador de carga é 10.128.15.193:

apiVersion: v1
kind: Service
metadata:
  ...
  labels:
    app: hello
  name: ilb-service
  ...
spec:
  clusterIP: 10.0.9.121
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30835
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: hello
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 10.128.15.193

Qualquer pod que tenha o rótulo app: hello é um membro desse serviço. Esses são os pods que podem ser os destinatários finais das solicitações enviadas para seu balanceador de carga interno.

Os clientes chamam o serviço usando o endereço IP loadBalancer e a porta TCP especificada no campo port do manifesto do serviço. A solicitação é encaminhada para um dos pods de membro na porta TCP especificada no campo targetPort. Portanto, no exemplo anterior, um cliente chama o serviço em 10.128.15.193 na porta TCP 80. A solicitação é encaminhada a um dos pods de membro na porta TCP 8080. O pod de membro precisa ter um contêiner escutando na porta 8080.

O valor nodePort de 30835 é irrelevante para seu balanceador de carga interno.

Como visualizar a regra de encaminhamento do balanceador de carga

Um balanceador de carga interno é implementado como uma regra de encaminhamento. A regra de encaminhamento tem um serviço de back-end, que tem um grupo de instâncias.

O endereço do balanceador de carga interno, 10.128.15.193 no exemplo anterior, é o mesmo que o endereço da regra de encaminhamento. Para ver a regra de encaminhamento que implementa o balanceador de carga interno, liste todas as regras de encaminhamento no projeto:

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

Na saída, procure a regra de encaminhamento que tem o mesmo endereço do seu balanceador de carga interno, 10.128.15.193 neste exemplo.

NAME                          ... IP_ADDRESS  ... TARGET
...
aae3e263abe0911e9b32a42010a80008  10.128.15.193   us-central1/backendServices/aae3e263abe0911e9b32a42010a80008

A saída mostra o serviço de back-end associado, que é ae3e263abe0911e9b32a42010a80008 neste exemplo.

Descreva o serviço de back-end:

gcloud compute backend-services describe aae3e263abe0911e9b32a42010a80008 --region us-central1

A saída mostra o grupo de instâncias associadas, que é k8s-ig--2328fa39f4dc1b75 neste exemplo:

backends:
- balancingMode: CONNECTION
  group: .../us-central1-a/instanceGroups/k8s-ig--2328fa39f4dc1b75
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

Como funciona a abstração de serviço

Quando um pacote é manipulado pela sua regra de encaminhamento, o pacote é encaminhado para um dos nós do cluster. Quando o pacote chega ao nó do cluster, os endereços e a porta são os seguintes:

Endereço IP de destino Regra de encaminhamento, 10.128.15.193 neste exemplo
Porta TCP de destino Campo port do serviço, 80 neste exemplo

Observe que a regra de encaminhamento (ou seja, seu balanceador de carga interno) não altera o endereço IP de destino ou a porta de destino. Em vez disso, as regras iptables no nó do cluster direcionam o pacote para um pod apropriado. As regras iptables alteram o endereço IP de destino para um endereço IP do pod e a porta de destino para o valor targetPort do serviço, que é 8080 neste exemplo.

Como verificar o balanceador de carga TCP interno

Execute SSH em uma instância de VM e o seguinte comando:

curl load-balancer-ip

Em que load-balancer-ip é o endereço IP LoadBalancer Ingress.

A resposta mostra a saída de hello-app:

Hello, world!
Version: 2.0.0
Hostname: hello-app-77b45987f7-pw54n

Executar o comando de fora da mesma rede VPC ou fora da mesma região resulta em um erro de tempo limite. Se você configurar acesso global, os clientes em qualquer região na mesma rede VPC poderão acessar o balanceador de carga.

Limpar

Você pode excluir a implantação e o serviço usando kubectl delete ou o Console do Cloud.

kubectl

Excluir a implantação

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

kubectl delete deployment hello-app

Excluir o serviço

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

kubectl delete service ilb-service

Console

Excluir a implantação

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

  1. Acesse o menu Cargas de trabalho do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu “Cargas de trabalho”

  2. No menu, selecione a carga de trabalho pretendida.

  3. Clique em Excluir.

  4. No menu da caixa de diálogo de confirmação, clique em Excluir.

Excluir o serviço

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

  1. Acesse o menu Services do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu Services

  2. No menu, selecione o serviço desejado.

  3. Clique em Excluir.

  4. No menu da caixa de diálogo de confirmação, clique em Excluir.

Considerações para entradas existentes

Não é possível ter um balanceador de carga TCP/UDP interno e uma entrada que use o modo de balanceamento UTILIZATION. Para usar um balanceamento de carga TCP e UDP interno e uma entrada, a entrada deve usar o modo de balanceamento RATE.

Se seu cluster tiver um recurso de entrada existente criado com o Kubernetes versão 1.7.1 ou inferior, ele não será compatível com os balanceadores de carga TCP/UDP internos. Os primeiros BackendService recursos criados pelos objetos do recurso de entrada do Kubernetes foram criados sem o modo de balanceamento especificado. Por padrão, a API usou o modo de balanceamento UTILIZATION para balanceadores de carga HTTP. No entanto, os balanceadores de carga TCP/UDP internos não podem ser apontados para grupos de instâncias com outros balanceadores de carga que usam UTILIZATION.

Como determinar o modo de balanceamento de entrada

Para determinar qual é o modo de balanceamento de entrada, execute os seguintes comandos pelo shell ou pela janela de terminal:

GROUPNAME=`kubectl get configmaps ingress-uid -o jsonpath='k8s-ig--{.data.uid}' --namespace=kube-system`
gcloud compute backend-services list --format="table(name,backends[].balancingMode,backends[].group)" | grep $GROUPNAME

Esses comandos exportam uma variável de shell, GROUPNAME, que busca o nome do grupo de instâncias do cluster. Em seguida, os recursos backend service do Compute Engine do seu projeto são pesquisados e os resultados são restringidos de acordo com o conteúdo de $GROUPNAME.

A resposta será semelhante a:

k8s-be-31210--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...
k8s-be-32125--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...

Se a saída retornar RATE entradas ou zero entradas forem retornadas, os balanceadores de carga internos serão compatíveis e não será necessário realizar um trabalho adicional.

Se a saída retornar entradas marcadas com UTILIZATION, suas entradas não serão compatíveis.

Para atualizar seus recursos de entrada para serem compatíveis com um balanceador de carga TCP/UDP interno, crie um novo cluster que execute o Kubernetes versão 1.7.2 ou superior e migre seus serviços para esse cluster.

Parâmetros de serviço

Os parâmetros a seguir são compatíveis com os serviços LoadBalancer internos do GKE.

Recurso Resumo Campo de serviço Compatibilidade da versão do GKE
Política de tráfego externo local Configura se o tráfego externo é ou não balanceado por carga nos nós do GKE. spec:externalTrafficPolicy:Local GKE 1.14+
Intervalos de origem do balanceador de carga Configura regras de firewall opcionais no GKE e na VPC para permitir apenas determinados intervalos de origem. spec:loadBalancerSourceRanges Todas as versões compatíveis
IP do balanceador de carga Especifica um IP para os balanceadores de carga spec:loadBalancerIP Todas as versões compatíveis
Sub-rede do balanceador de carga Especifica de qual sub-rede o balanceador de carga deve provisionar automaticamente um IP metadata:annotations: networking.gke.io/internal-load-balancer-subnet Beta no GKE 1.17+ e 1.16.8-gke.10+
Acesso global Permite que o VIP do balanceador de carga TCP/UDP seja acessível por clientes nas regiões do GCP metadata:annotations: networking.gke.io/internal-load-balancer-allow-global-access Beta no GKE 1.16+
GA no GKE 1.17.9-gke.600+
Todas as portas A capacidade do balanceador de carga TCP/UDP de encaminhar todas as portas em vez de portas específicas N/D Sem suporte nativo

Política de tráfego externa

O externalTrafficPolicy é uma opção de serviço padrão que define como e se o tráfego de entrada para um nó do GKE é balanceado por carga. Cluster é a política padrão, mas Local costuma ser usada para preservar o IP de origem do tráfego que entra em um nó do cluster. O Local desativa efetivamente o balanceamento de carga no nó do cluster para que o tráfego recebido por um pod local veja o endereço de origem original.

externalTrafficPolicy é compatível com os serviços LoadBalancer internos (via balanceador de carga TCP/UDP), mas o comportamento do balanceamento de carga depende da origem do tráfego e da política de tráfego configurada.

O tráfego proveniente de fora do cluster para um balanceador de carga TCP/UDP terá o seguinte comportamento, se houver pelo menos um pod íntegro do serviço no cluster:

  • Política Cluster: o tráfego será balanceado por carga para qualquer nó íntegro do GKE no cluster e, em seguida, o kube-proxy o enviará para um nó com o pod.
  • Política Local: os nós que não têm um dos pods de back-end serão exibidos como não íntegros para o balanceador de carga TCP/UDP. O tráfego só será enviado para um dos nós de cluster íntegros restantes que tenham o pod. O tráfego não é roteado novamente pelo kube-proxy e, em vez disso, é enviado diretamente para o pod local com as informações do cabeçalho IP intactas.

Se o tráfego para um determinado IP de serviço do LoadBalancer for proveniente de um nó do GKE dentro do cluster, haverá um comportamento de tráfego diferente. A tabela a seguir resume o comportamento do tráfego proveniente de um nó ou pod dentro do cluster destinado a um pod membro de um serviço LoadBalancer:

externalTrafficPolicy O pod membro do serviço está em execução no mesmo nó de origem do tráfego? Comportamento do tráfego
Cluster Sim Os pacotes são entregues a qualquer pod de membro, seja no nó ou em um nó diferente.
Cluster Não Os pacotes são entregues a qualquer pod de membro, que deve estar em um nó diferente.
Treinamento Sim Os pacotes são entregues a qualquer pod de membro no mesmo nó.
Treinamento Não

Kubernetes 1.14 e anteriores: os pacotes são descartados.

Kubernetes 1.15 e posteriores: os pacotes são entregues a qualquer pod de membro, que precisa estar em um nó diferente.

Intervalos de origem do balanceador de carga

A matriz spec: loadBalancerSourceRanges especifica um ou mais intervalos de endereços de IPs internos. loadBalancerSourceRanges restringe o tráfego por meio do balanceador de carga para os IPs especificados nesse campo. Ao usar essa configuração, kube-proxy cria as regras iptables correspondentes nos nós do Kubernetes. O GKE também cria uma regra de firewall na sua rede VPC automaticamente. Se você omitir esse campo, seu Serviço aceitará o tráfego de qualquer endereço IP (0.0.0.0/0).

Para mais informações sobre a especificação de serviço, consulte a Referência da API de serviço.

IP do balanceador de carga

O spec: loadBalancerIP permite que você escolha um endereço IP específico para o balanceador de carga. O endereço IP não pode estar em uso por outro balanceador de carga TCP/UDP interno ou serviço. Se omitido, um IP temporário será atribuído. Para mais informações, consulte Como reservar um endereço IP interno estático.

Sub-rede do balanceador de carga (Beta)

Por padrão, o GKE implantará um balanceador de carga TCP/UDP interno usando o intervalo de sub-rede do nó. A sub-rede pode ser especificada pelo usuário por serviço usando a anotação networking.gke.io/internal-load-balancer-subnet. Isso é útil para ter um firewall separado dos IPs do balanceador de carga interno dos IPs do nó ou para compartilhar a mesma sub-rede de serviço em vários clusters do GKE. Esse parâmetro é relevante apenas para os serviços internosTCP/UDP do LoadBalancer.

A sub-rede precisa existir antes de ser referenciada pelo recurso de serviço, já que o GKE não gerencia o ciclo de vida da sub-rede. A sub-rede também precisa estar na mesma VPC e região que o cluster do GKE. Nesta etapa, ele é criado fora da banda do GKE:

gcloud compute networks subnets create gke-vip-subnet \
    --network=default \
    --range=10.23.0.0/24 \
    --region=us-central1

A definição de serviço a seguir usa o internal-load-balancer-subnet para fazer referência à sub-rede por nome. Por padrão, um IP disponível da sub-rede será escolhido automaticamente. Também é possível especificar o loadBalancerIP, mas ele precisa fazer parte da sub-rede referenciada.

Há várias maneiras de compartilhar essa sub-rede do balanceador de carga interno para ter diferentes casos de uso:

  • Várias sub-redes para grupos de serviços no mesmo cluster
  • Uma única sub-rede para todos os serviços em um cluster
  • Uma única sub-rede compartilhada entre vários clusters e vários serviços
apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
    networking.gke.io/internal-load-balancer-subnet: "gke-vip-subnet"
  labels:
    app: hello
spec:
  type: LoadBalancer
  loadBalancerIP: 10.23.0.15
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Acesso global

O acesso global é um parâmetro opcional para serviços internos do LoadBalancer que permite que clientes de qualquer região na rede VPC acessem o balanceador de carga TCP/UDP interno. Sem acesso global, o tráfego proveniente de clientes na rede VPC precisa estar na mesma região que o balanceador de carga. O acesso global permite que clientes em qualquer região acessem o balanceador de carga. As instâncias de back-end ainda precisam estar localizadas na mesma região que o balanceador de carga.

O acesso global é ativado por serviço usando a seguinte anotação: networking.gke.io/internal-load-balancer-allow-global-access: "true".

O acesso global não é compatível com redes legadas. Os custos de usar o acesso global entre regiões são os normais de tráfego entre regiões. Consulte Preços de rede para ver informações sobre preços para saída de regiões. O acesso global está disponível na versão Beta nos clusters do GKE 1.16+ e GA em 1.17.9-gke.600+.

IP compartilhado (Beta)

O balanceador de carga TCP/UDP interno 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.
  • As tuplas de protocolo/porta não podem se sobrepor entre Serviços que compartilham o mesmo IP.
  • 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.

  2. Implante até dez Serviços LoadBalancer internos usando esse IP estático no campo loadBalancerIP. Os balanceadores de carga TCP/UDP 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.

    gcloud beta compute addresses create internal-10-128-2-98 \
    --region=us-central1 \
    --subnet=default \
    --addresses=10.128.2.98 \
    --purpose=SHARED_LOADBALANCER_VIP

  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. Ele usa o IP compartilhado 10.128.2.98.

    apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: 10.128.2.98
  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 compartilhado 10.128.2.98.

    apiVersion: v1
kind: Service
metadata:
  name: udp-service
  namespace: default
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: 10.128.2.98
  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 LB 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 endereço IP compartilhado 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

Todas as portas

Se você criar um balanceador de carga TCP/UDP interno usando um serviço anotado, não será possível configurar uma regra de encaminhamento que use todas as portas. No entanto, se você criar um balanceador de carga TCP/UDP interno manualmente, poderá escolher o grupo de instâncias de nós do Google Kubernetes Engine como o back-end. Os serviços do Kubernetes de type: NodePort estão disponíveis por meio do ILB.

Restrições para balanceadores de carga TCP/UDP internos

  • Para clusters que executam o Kubernetes versão 1.7.3 e anterior, é possível usar balanceadores de carga TCP/UDP internos com modo automático. No entanto, com 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.
  • Para clusters que executam o Kubernetes 1.7.X ou posterior, enquanto o clusterIP permanece inalterado, os balanceadores de carga TCP/UDP internos não podem usar endereços IP reservados. O campo spec.loadBalancerIP ainda pode ser definido usando um endereço IP não utilizado para atribuir um IP interno específico. Alterações feitas em portas, protocolos ou afinidade da sessão podem fazer com que esses endereços IP sejam alterados.

Restrições para balanceadores de carga UDP internos

  • Os balanceadores de carga UDP internos não são compatíveis com sessionAffinity: ClientIP.

Limites

Um serviço do Kubernetes com type: Loadbalancer e a anotação cloud.google.com/load-balancer-type: Internal cria um ILB que segmenta o serviço do Kubernetes. O número desses serviços é limitado pelo número de regras de encaminhamento internas que você consegue criar em uma rede de VPC. Para detalhes, consulte Limites por rede.

Em um cluster do GKE, uma regra de encaminhamento interna aponta para todos os nós no cluster. Cada nó no cluster é uma VM de back-end para o ILB. O número máximo de VMs de back-end para um ILB é 250, independentemente de como as VMs estão associadas aos grupos de instâncias. Portanto, o número máximo de nós em um cluster do GKE com um ILB é 250. Se o escalonamento automático estiver ativado para seu cluster, você deverá garantir que o escalonamento automático não dimensione seu cluster para mais de 250 nós.

Para mais informações sobre esses limites, consulte Cotas de recursos de VPC.

A seguir