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 Serviço
com uma especificação type: LoadBalancer
e uma anotação para criar um balanceador de carga TCP/UDP interno. A
anotação depende da versão do cluster do GKE.
Para as versões 1.17 e posteriores do GKE, use a anotação
networking.gke.io/load-balancer-type: "Internal"
.
Para versões anteriores, use a anotação
cloud.google.com/load-balancer-type: "Internal"
.
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ço
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:
- Verifique se você ativou a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Verifique se o SDK do Cloud está instalado.
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.
-
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
-
Siga as instruções para autorizar a
gcloud
a usar sua conta do Google Cloud. - Crie uma nova configuração ou selecione uma atual.
- Escolha um projeto do Google Cloud.
- Escolha uma zona padrão do Compute Engine para clusters zonais ou uma região para clusters regionais ou de Autopilot.
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 de Autopilot ou 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:
networking.gke.io/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 casoilb-service
. - Uma anotação que especifica um balanceador de carga TCP/UDP interno. A anotação depende da
versão do cluster do GKE. Para as
versões 1.17 e posteriores do GKE, use a anotação
networking.gke.io/load-balancer-type: "Internal"
. Para versões anteriores, use a anotaçãocloud.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
. - O
port
, a porta pela qual o serviço é exposto, etargetPort
, 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:
Acesse o menu Cargas de trabalho do Google Kubernetes Engine no Console do Cloud.
Selecione a implantação que você quer excluir e clique em delete Excluir.
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:
Acesse o menu Services do Google Kubernetes Engine no Console do Cloud.
Selecione o serviço que você quer excluir e clique em delete Excluir.
Quando solicitado a confirmar, clique em Excluir.
Como usar a criação de subconjuntos do balanceador de carga TCP/UDP interno (visualização)
A subconfiguração do balanceador de carga interno para o GKE melhora a escalonabilidade do balanceador de carga TCP/UDP interno particionando back-ends em grupos menores e sobrepostos. Com a criação de subconjuntos, é possível configurar balanceadores de carga TCP/UDP internos em clusters com mais de 250 nós.
É possível ativar a criação de subconjuntos ao criar um cluster e editar um atual.
Arquitetura
A criação de subconjuntos altera a implantação do balanceador de carga TCP/UDP interno. Sem a criação de subconjuntos, o controlador do GKE coloca todos os nós de um cluster em um ou mais grupos de instâncias não gerenciadas por zona, que são compartilhados por todos os balanceadores de carga internos no cluster do GKE. Por exemplo, todos os balanceadores de carga TCP/UDP internos em um cluster de 40 nós do GKE compartilham os mesmos 40 nós como back-ends.
Com a criação de subconjuntos do balanceador de carga TCP/UDP interno,
o controlador do GKE coloca nós em
GCE_VM_IP zonal network endpoint groups (NEGs)
.
Ao contrário dos grupos de instâncias, os nós podem
ser membros de mais de um NEG zonal, e cada um deles pode ser mencionado
por um balanceador de carga TCP/UDP interno. O controlador do GKE cria um NEG
para cada serviço usando um subconjunto dos nós do GKE como membros. Por exemplo,
um cluster de 40 nós do GKE pode ter um balanceador de carga TCP/UDP
interno com 25 nós em um NEG zonal de back-end e outro balanceador de carga TCP/UDP interno com 25
nós em um NEG zonal back-end diferente.
Quando você ativa a criação de subconjuntos para o cluster, o controlador
do GKE determina automaticamente como subdividir os nós com base em
externalTrafficPolicy
.
Quando externalTrafficPolicy=Cluster
, o número máximo de back-ends no
subconjunto será de 25 nós. O controlador do GKE seleciona os nós como
membros de um subconjunto aleatoriamente.
Quando externalTrafficPolicy=Local
, o número máximo de back-ends no subconjunto
é de 250 nós. O controlador do GKE seleciona nós para serem membros de
um subconjunto aleatoriamente dos nós que hospedam os pods para o serviço. Se os
pods de back-end do serviço forem programados em mais de 250 nós, um
máximo de 250 nós e os pods executados neles receberão tráfego do balanceador
de carga interno.
Requisitos e limitações
A criação de subconjuntos para o GKE tem os seguintes requisitos e limitações:
- É possível ativar a criação de subconjuntos em clusters novos e atuais na versão do GKE 1.18 e posteriores.
- SDK do Cloud versão 322.0.0 e posteriores.
- A criação de subconjuntos não pode ser usada com clusters de Autopilot.
- Aplicam-se cotas para grupos de endpoints de rede. O Google Cloud cria um NEG por balanceador de carga TCP/UDP interno por zona.
- Não é possível desativar a criação de subconjuntos após ativá-la em um cluster.
- A criação de subconjuntos não pode ser usada com a anotação para compartilhar serviços de back-end,
alpha.cloud.google.com/load-balancer-backend-share
.
Como ativar a criação de subconjuntos do balanceador de carga interno em um novo cluster
Para criar um cluster com a subconfiguração do balanceador de carga interno ativada, especifique a opção
--enable-l4-ilb-subsetting
:
gcloud beta container clusters create CLUSTER_NAME \
--cluster-version VERSION \
--enable-l4-ilb-subsetting
{--zone ZONE_NAME | --region REGION_NAME}
Substitua:
CLUSTER_NAME
: o nome do novo cluster;VERSION
: a versão do GKE, que precisa ser 1.18 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 ou posterior.ZONE_NAME
ouREGION_NAME
: o local do cluster. Esses argumentos são mutuamente exclusivos. Para mais informações, consulte Tipos de clusters.
Como ativar a criação de subconjuntos do balanceador de carga interno em um cluster atual
Para ativar a criação de subconjuntos de balanceadores de carga internos em um cluster atual, especifique a
opção --enable-l4-ilb-subsetting
:
gcloud beta container clusters update CLUSTER_NAME \
--enable-l4-ilb-subsetting
Substitua:
CLUSTER_NAME
: o nome do cluster.
Como verificar a criação de subconjuntos do balanceador de carga interno
Para verificar se a criação de subconjuntos do balanceador de carga interno está funcionando corretamente para seu cluster, execute as seguintes etapas:
Implante 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. 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: gcr.io/google-samples/hello-app:1.0
Aplique o manifesto ao cluster:
kubectl apply -f ilb-deployment.yaml
Crie um serviço.
No manifesto a seguir, é descrito um Serviço que cria um balanceador de carga interno na porta TCP 8080. 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: 8080 targetPort: 8080
Aplique o manifesto ao cluster:
kubectl apply -f ilb-svc.yaml
Inspecionar o serviço:
kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
A resposta será semelhante a:
{"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["us-central1-c"]}
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 tipoLoadBalancer
que usam a criação do GKE e não está presente em serviços que não usam a subconfiguração.
Solução de problemas
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 ZONE
Substitua:
NEG_NAME
: o nome do grupo de endpoints de rede criado pelo controlador do GKE;ZONE
: a zona do grupo de endpoints da rede em que operar.
Parâmetros de serviço
Para mais informações sobre os parâmetros do balanceador de carga que podem ser configurados, consulte Como configurar o balanceamento de carga TCP/UDP. Além disso, os serviços LoadBalancer internos são compatíveis com os seguintes parâmetros adicionais:
Recurso | Resumo | Campo de serviço | Compatibilidade da versão do GKE |
---|---|---|---|
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+ GA no GKE 1.17.9-gke.600+ |
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+ |
Sub-rede do balanceador de carga
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:
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.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.
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
Se você estiver reservando um IP estático no projeto que contém a rede, execute este comando:
gcloud compute addresses create IP_ADDR_NAME \ --project PROJECT_ID \ --subnet SUBNET \ --region REGION --purpose SHARED_LOADBALANCER_VIP
Se você estiver reservando um IP estático no projeto de serviço de uma VPC compartilhada, execute este comando:
gcloud compute addresses create IP_ADDR_NAME \ --project SERVICE_PROJECT_ID \ --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \ --region REGION --purpose SHARED_LOADBALANCER_VIP
Substitua:
IP_ADDR_NAME
por um nome para o objeto de endereço IPSERVICE_PROJECT_ID
pelo ID do projeto de serviçoPROJECT_ID
pelo ID do projeto (projeto único)HOST_PROJECT_ID
pelo ID do projeto host da VPC compartilhadaREGION
pela região contendo a sub-rede compartilhadaSUBNET
pelo nome da sub-rede compartilhada
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 compartilhado10.128.2.98
.apiVersion: v1 kind: Service metadata: name: tcp-service namespace: default annotations: networking.gke.io/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
Aplique esta definição de Serviço ao cluster:
kubectl apply -f tcp-service.yaml
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 compartilhado10.128.2.98
.apiVersion: v1 kind: Service metadata: name: udp-service namespace: default annotations: networking.gke.io/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
Aplique este arquivo no cluster:
kubectl apply -f udp-service.yaml
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 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 (visualização)
As regras de encaminhamento internas são
compatíveis com até cinco portas por regra de encaminhamento ou um
parâmetro opcional
--ports=ALL
que encaminha todas as portas na regra de encaminhamento.
Requisitos
Todas as portas no GKE têm os seguintes requisitos e limitações:
- Compatível apenas quando
--enable-l4-ilb-subsetting
está ativado. - Compatível apenas com serviços do balanceador de carga interno.
- Compatível com qualquer número de portas em um máximo de 100 intervalos de portas contíguos.
O controlador do GKE ativa automaticamente todas as portas na regra de encaminhamento quando um serviço tem mais de cinco portas. Por exemplo, o manifesto do serviço a seguir tem seis portas configuradas em dois intervalos contíguos:
apiVersion: v1
kind: Service
metadata:
name: all-ports
annotations:
cloud.google.com/load-balancer-type: "Internal"
spec:
type: LoadBalancer
selector:
app: myapp
ports:
- port: 8081
targetPort: 8081
name: 8081-to-8081
protocol: TCP
- port: 8082
targetPort: 8082
name: 8082-to-8082
protocol: TCP
- port: 8083
targetPort: 8083
name: 8083-to-8083
protocol: TCP
- port: 9001
targetPort: 9001
name: 9001-to-9001
protocol: TCP
- port: 9002
targetPort: 9002
name: 9002-to-9002
protocol: TCP
- port: 9003
targetPort: 9003
name: 9003-to-9003
protocol: TCP
O controlador do GKE ativa todas as portas na regra de encaminhamento porque o serviço tem mais de cinco portas. No entanto, o controlador do GKE cria apenas portas de firewall para as portas especificadas no serviço. Todas as outras regras são bloqueadas por firewalls da VPC.
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, mas 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 networking.gke.io/load-balancer-type: Internal
cria um balanceador de carga interno
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 VPC. Para detalhes, consulte Limites por rede.
Portanto, o número máximo de nós em um cluster do GKE com um balanceador de carga interno é 250. Para remover essa limitação, ative a subconfiguração do balanceador de carga interno. Caso contrário, o escalonamento automático estiver ativado para seu cluster, você precisará garantir que o escalonamento automático não dimensione seu cluster para mais de 250 nós.
Para mais informações sobre os limites da VPC, consulte Cotas e limites.
A seguir
- Leia a visão geral da rede GKE.
- Saiba mais sobre balanceadores de carga do Compute Engine.
- Saiba mais sobre IPs de alias.
- Saiba mais sobre o agente de mascaramento de IP.
- Saiba sobre como configurar redes autorizadas.