Como usar um balanceador de carga TCP/UDP interno

Nesta página, você verá como criar um balanceador de carga TCP/UDP interno no Google Kubernetes Engine (GKE).

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 máquina virtual VM do Compute Engine em execução nessa região na mesma rede VPC.

Nota

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

Arquitetura

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.

O controlador de entrada do GKE implanta e gerencia recursos de balanceamento de carga. Para saber mais sobre o controlador de entrada do GKE, consulte Resumo do comportamento do controlador de entrada do GKE.

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, veja se você realizou as seguintes tarefas:

Veja se você ativou a API do Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Confirme se você instalou a Google Cloud CLI.
Defina as configurações padrão da Google Cloud CLI para o projeto usando um dos seguintes métodos:

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

gcloud init

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 CLI gcloud a usar a 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.
Escolha uma região padrão do Compute Engine.

Observação: para modificar essas configurações padrão na CLI gcloud, use as sinalizações --project, --zone e --region

gcloud config

Defina o ID do projeto padrão:
```
gcloud config set project PROJECT_ID
```
Defina a região padrão do Compute Engine (por exemplo, us-central1):
```
gcloud config set compute/region COMPUTE_REGION
```
Defina a zona padrão do Compute Engine (por exemplo, us-central1-c):
```
gcloud config set compute/zone COMPUTE_ZONE
```
Atualize gcloud para a versão mais recente:
```
gcloud components update
```

Observação: para modificar essas configurações padrão na CLI gcloud, use as sinalizações --project, --zone e --region

Ao definir locais padrão, é possível evitar erros na gcloud CLI, como: One of [--zone, --region] must be supplied: Please specify location.

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: "us-docker.pkg.dev/google-samples/containers/gke/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 caso ilb-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ção cloud.google.com/load-balancer-type: "Internal".
O type: LoadBalancer.
Um campo spec: selector para especificar os pods que o serviço deve segmentar, por exemplo, app: hello.
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

Substitua LOAD_BALANCER_IP pelo seu 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.

Como fazer a limpeza

É possível excluir a implantação e o serviço usando kubectl delete ou o Console.

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 a página Cargas de trabalho no Console.

Acesse "Cargas de trabalho"
Selecione a implantação que você quer excluir e clique em 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 a página Serviços e entradas no console.

Acesse "Serviços e Entrada"
Selecione o serviço que você quer excluir e clique em Excluir.
Quando solicitado a confirmar, clique em Excluir.

Como usar a criação de subagrupamentos do balanceador de carga TCP/UDP interno

O subagrupamento do balanceador de carga interno para o GKE melhora a escalonabilidade dos balanceadores de carga TCP/UDP internos 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 subagrupamentos altera a implantação dos balanceadores de carga TCP/UDP internos. 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.

O diagrama a seguir mostra dois serviços diferentes em um cluster que tem um subagrupamento de balanceador de carga TCP/UDP interno ativado. Cada serviço tem dois pods programados em três nós. O Google Cloud cria um NEG GCE_VM_IP para cada serviço. O controlador do GKE seleciona um subconjunto de nós no cluster para serem membros do NEG e usa o endereço IP de cada nó selecionado como endpoints.

Endereços IP virtuais de nós usados como endpoints para serviços ao criar subagrupamentos. — **Diagrama:** exemplo de subagrupamento em um cluster com serviços.

Seleção de subconjunto de nós de back-end

Quando você ativa o subagrupamento para seu cluster, o controlador do GKE determina automaticamente como criar subconjuntos de nós. É possível usar o valor Local ou Cluster para externalTrafficPolicy, mas a seleção do subconjunto de nós de back-end é diferente para cada valor.

externalTrafficPolicy: Cluster: as solicitações do cliente são enviadas para o IP do nó, e a carga é balanceada para um pod de back-end. O pod de back-end pode estar no mesmo nó ou em um nó diferente. O controlador do GKE seleciona um subconjunto aleatório de 25 nós. Essa distribuição evita pontos únicos de falha. Se os pods de back-end estiverem hospedados em mais de 25 nós, eles ainda receberão tráfego, mas o tráfego de entrada será feito no cluster por meio de, no máximo, 25 nós que fazem parte do subconjunto. Se o cluster tiver menos de 25 nós, todos os nós farão parte do subconjunto.
externalTrafficPolicy: Local: as solicitações do cliente são enviadas para o IP do nó, e a carga é balanceada apenas para pods de back-end em execução no mesmo nó. Como resultado, o subconjunto de nós de back-end contém apenas nós que hospedam um dos pods de objetos de serviço. O tamanho do subconjunto é o número de nós que hospedam pods deste serviço até um máximo de 250 nós. Não programe esses serviços em mais de 250 nós, já que os nós adicionais não recebem tráfego do balanceador de carga.

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 subagrupamentos em clusters novos e atuais nas versões 1.18.19-gke.1400 e posteriores do GKE.
O cluster precisa ter o complemento HttpLoadBalancing ativado. Esse complemento é ativado por padrão. Um cluster que desativou este complemento não pode usar a criação de subconjuntos. Para saber como executar um controlador de Entrada personalizado com o complemento HttpLoadBalancing ativado, consulte Usar um controlador de Entrada personalizado com o complemento HttpLoadBalancing ativado.
Google Cloud CLI versão 345.0.0 e posterior.
Aplicam-se cotas para grupos de endpoints de rede. O Google Cloud cria um NEG por balanceador de carga TCP/UDP interno por zona.
Cotas para regras de encaminhamento, serviços de back-end e outros recursos de rede são aplicáveis.
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

Crie um cluster com subconjunto de balanceador de carga interno ativado usando a Google Cloud CLI ou o console:

Console

Acesse a página do Google Kubernetes Engine no Console.

Acessar o Google Kubernetes Engine
Clique em Criar.
Configure o cluster como quiser.
No painel de navegação, em Cluster, clique em Rede.
Marque a caixa de seleção Ativar o subagrupamento para balanceadores de carga internos L4.
Clique em Criar.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --region=COMPUTE_REGION

Substitua:

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

Como ativar a criação de subconjuntos do balanceador de carga interno em um cluster atual

É possível ativar o subagrupamento do balanceador de carga interno para um cluster atual usando a gcloud CLI ou o console do Google Cloud. Não é possível desativar o subagrupamento do balanceador de carga interno depois de ativá-la em um cluster.

Console

No console, acesse a página Google Kubernetes Engine.

Acessar o Google Kubernetes Engine
Na lista de clusters, clique no nome do cluster que você quer modificar.
Em Rede, ao lado do campo Subagrupamento de balanceadores de carga internos L4, clique em Ativar o subagrupamento para balanceadores de carga internos L4.
Marque a caixa de seleção Ativar o subagrupamento para balanceadores de carga internos L4.
Clique em Save Changes.

gcloud

gcloud 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: us-docker.pkg.dev/google-samples/containers/gke/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 tipo LoadBalancer 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=COMPUTE_ZONE

Substitua:

NEG_NAME: o nome do grupo de endpoints de rede criado pelo controlador do GKE;
COMPUTE_ZONE: a zona do Compute grupo de endpoints da rede em que operar.

Para determinar a lista de nós íntegros de um balanceador de carga TCP/UDP interno, use o seguinte comando:

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

Substitua:

SERVICE_NAME: o nome do serviço de back-end. Esse valor é igual ao nome do grupo de endpoints da rede criado pelo controlador do GKE.
COMPUTE_REGION: a região Compute em que o serviço de back-end será operado.

Como criar um balanceador de carga TCP/UDP interno com o Private Service Connect

Como produtor de serviço, é possível usar anexos de serviço para disponibilizar seus serviços aos consumidores de serviço em outras redes VPC usando o Private Service Connect. É possível criar, gerenciar e excluir anexos de serviço usando um recurso personalizado ServiceAttachment.

Requisitos e limitações

Limitações se aplicam ao Private Service Connect.
É possível criar um anexo de serviço nas versões 1.21.4-gke.300 e posteriores do GKE.
Não é possível usar a mesma sub-rede em várias configurações de anexos do serviço.
Crie um serviço do GKE que use um balanceador de carga TCP/UDP interno.
Não é possível especificar uma sub-rede em um projeto diferente (VPC compartilhada) para versões do GKE anteriores a 1.22.4-gke.100. Para a VPC compartilhada, verifique se todos os requisitos da VPC compartilhada foram atendidos.

Como criar um ServiceAttachment

Crie uma sub-rede.

É necessário criar uma nova sub-rede para cada ServiceAttachment.
```
gcloud beta compute networks subnets create SUBNET_NAME \
    --project PROJECT_ID \
    --network NETWORK_NAME \
    --region REGION \
    --range SUBNET_RANGE \
    --purpose PRIVATE_SERVICE_CONNECT
```
Substitua:
- SUBNET_NAME: o nome da nova sub-rede; Nas versões 1.22.4-gke.100 e posteriores do GKE, é possível especificar uma sub-rede em um projeto diferente usando o URL de recurso totalmente qualificado para esse campo. Você pode conseguir o URL do recurso totalmente qualificado usando o comando gcloud compute networks subnets describe.
- PROJECT_ID: o ID do seu projeto do Google Cloud;
- NETWORK_NAME: o nome da rede VPC da sub-rede;
- REGION: a região da nova sub-rede. Use a mesma região do serviço criado;
- SUBNET_RANGE: o intervalo de endereços IP a ser usado para a sub-rede.

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 my-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: psc-ilb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: psc-ilb
  template:
    metadata:
      labels:
        app: psc-ilb
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.8
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          timeoutSeconds: 1

Aplique o manifesto ao cluster:
```
kubectl apply -f my-deployment.yaml
```

Crie um serviço O manifesto a seguir descreve um serviço que cria um balanceador de carga TCP/UDP interno na porta TCP 8080. Salve o manifesto como my-service.yaml:

 apiVersion: v1
 kind: Service
 metadata:
   name: SERVICE_NAME
   annotations:
     networking.gke.io/load-balancer-type: "Internal"
 spec:
   type: LoadBalancer
   selector:
     app: psc-ilb
   ports:
   - port: 80
     targetPort: 8080
     protocol: TCP

Substitua:

SERVICE_NAME: o nome do novo serviço;

Aplique o manifesto ao cluster:
```
kubectl apply -f my-service.yaml
```
Criar ServiceAttachment.

O manifesto a seguir descreve um ServiceAttachment que expõe o serviço criado para os consumidores de serviço. Salve o manifesto como my-psc.yaml:
```
apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
 name: SERVICE_ATTACHMENT_NAME
 namespace: default
spec:
 connectionPreference: ACCEPT_AUTOMATIC
 natSubnets:
 - SUBNET_NAME
 proxyProtocol: false
 resourceRef:
   kind: Service
   name: SERVICE_NAME
```
Observação: para versões do GKE anteriores a 1.23.3-gke.900, use networking.gke.io/v1beta1 em vez de networking.gke.io/v1.

Substitua:
- SERVICE_ATTACHMENT_NAME: o nome do novo anexo de serviço.
- SUBNET_NAME: o nome da nova sub-rede. Nas versões 1.22.4-gke.100 e posteriores do GKE, é possível especificar uma sub-rede em um projeto diferente usando o URL de recurso totalmente qualificado para esse campo. Você pode conseguir o URL do recurso totalmente qualificado usando o comando gcloud compute networks subnets describe. Para uma configuração de VPC compartilhada, use o seguinte formato: projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME.
Observação: o recurso ServiceAttachment terá eventos de erro até que o controlador do GKE crie o balanceador de carga TCP/UDP interno definido pelo serviço. Após o provisionamento do balanceador de carga TCP/UDP interno, os erros não serão mais publicados.

O ServiceAttachment tem os seguintes campos:
- connectionPreference: a preferência de conexão que determina como os clientes se conectam ao serviço. É possível usar a aprovação automática do projeto usando ACCEPT_AUTOMATIC ou a aprovação explícita do projeto usando ACCEPT_MANUAL. Para mais informações, consulte Como publicar serviços usando o Private Service Connect.
- natSubnets: uma lista de nomes de recurso de sub-rede a serem usados para o anexo de serviço.
- proxyProtocol: quando definido como verdadeiro, o IP de origem do consumidor e o ID da conexão do Private Service Connect estão disponíveis nas solicitações. Esse campo é opcional e o padrão será falso se não for fornecido.
- consumerAllowList: a lista de projetos de consumidor que têm permissão para se conectar ao ServiceAttachment. Este campo só pode ser usado quando connectionPreference é ACCEPT_MANUAL. Para mais informações sobre esse campo, consulte Como publicar serviços usando o Private Service Connect.
  - project: o ID ou o número do projeto do consumidor.
  - connectionLimit: o limite de conexão do projeto do consumidor. Este campo é opcional.
  - forceSendFields: os nomes de campo a serem enviados para incluir nas solicitações de API. Este campo é opcional.
  - nullFields: os nomes de campo a serem incluídos nas solicitações de API com um valor nulo. Este campo é opcional.
- consumerRejectList: a lista de IDs de projeto ou números de consumidores que não têm permissão para se conectar a ServiceAttachment. Este campo só pode ser usado quando connectionPreference é ACCEPT_MANUAL. Para mais informações sobre esse campo, consulte Como publicar serviços usando o Private Service Connect.
- resourceRef: uma referência ao recurso do Kubernetes.
  - kind: o tipo do recurso do Kubernetes. Você precisa usar Service.
  - name: o nome do recurso do Kubernetes que precisa estar no mesmo namespace que o balanceador de carga TCP/UDP interno.
Observação: depois que um anexo de serviço é conectado a um balanceador de carga TCP/UDP interno, não é possível excluir ou atualizar o balanceador de carga TCP/UDP interno. Se você tentar excluir ou atualizar o balanceador de carga TCP/UDP interno, uma mensagem de erro será exibida. Para mais informações, consulte Solução de problemas.
Aplique o manifesto ao cluster:
```
kubectl apply -f my-psc.yaml
```

Verifique se o controlador do Private Service Connect criou o anexo de serviço:

gcloud beta compute service-attachments list

A saída mostra um anexo de serviço com um nome gerado automaticamente:

NAME        REGION       PRODUCER_FORWARDING_RULE          CONNECTION_PREFERENCE
k8s1-sa-... us-central1  a3fea439c870148bdba5e59c9ea9451a  ACCEPT_AUTOMATIC

Como visualizar um ServiceAttachment

Para visualizar os detalhes de uma ServiceAttachment, use o seguinte comando:

kubectl describe serviceattachment SERVICE_ATTACHMENT_NAME

A saída será assim:

 kubectl describe serviceattachment foo-sa
Name:        <sa-name>
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         ServiceAttachment
Metadata:
  ...
Status:
  Forwarding Rule URL:      https://www.googleapis.com/compute/beta/projects/<project>/regions/<region>/forwardingRules/<fr-name>
  Last Modified Timestamp:  2021-07-08T01:32:39Z
  Service Attachment URL:   https://www.googleapis.com/compute/beta/projects/<projects>/regions/<region>/serviceAttachments/<gce-service-attachment-name>
Events:                     <none>

Como consumir um ServiceAttachment

Para consumir o serviço de outro projeto, siga estas etapas:

Consiga o URL do ServiceAttachment:

kubectl get serviceattachment SERVICE_ATTACHMENT_NAME -o=jsonpath="{.status.serviceAttachmentURL}"

A saída será assim:

  serviceAttachmentURL: https://www.googleapis.com/compute/alpha/projects/<project>/region/<region>/serviceAttachments/k8s1-...my-sa

Crie um endpoint do Private Service Connect usando o URL do ServiceAttachment.

Verifique se é possível se conectar ao serviço implantado no projeto do produtor usando um comando curl de uma VM no projeto do consumidor:

curl PSC_IP_ADDRESS

Substitua PSC_IP_ADDRESS pelo endereço IP da regra de encaminhamento no projeto do consumidor.

A saída será assim:

{
  "cluster_name":"cluster",
  "host_header":"10.128.15.200",
  "node_name":"gke-psc-default-pool-be9b6e0e-dvxg.c.gke_project.internal",
  "pod_name":"foo-7bf648dcfd-l5jf8",
  "pod_name_emoji":"👚",
  "project_id":"gke_project",
  "timestamp":"2021-06-29T21:32:03",
  "zone":"us-central1-c"
}

Como atualizar um ServiceAttachment

É possível atualizar um ServiceAttachment usando as seguintes etapas:

Edite o manifesto ServiceAttachment em my-psc.yaml:

apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
  name: my-sa
  namespace: default
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
  - my-nat-subnet
  proxyProtocol: false
  resourceRef:
    kind: Service
    name: ilb-service

Aplique o manifesto ao cluster:
```
kubectl apply -f my-psc.yaml
```

Como fazer a limpeza

Não é possível excluir um balanceador de carga TCP/UDP interno conectado a um anexo de serviço. É necessário excluir o anexo de serviço e o serviço do GKE separadamente.

Exclua o anexo de serviço:
```
kubectl delete serviceattachment SERVICE_ATTACHMENT_NAME --wait=false
```
Esse comando marca o anexo de serviço para exclusão, mas o recurso continua a existir. Também é possível aguardar a conclusão da exclusão omitindo a sinalização --wait.
Exclua o serviço:
```
kubectl delete svc SERVICE_NAME
```

Exclua a sub-rede:

gcloud compute networks subnets delete SUBNET_NAME

Solução de problemas

É possível ver as mensagens de erro usando o seguinte comando:

kubectl get events -n NAMESPACE

Substitua NAMESPACE pelo namespace do balanceador de carga TCP/UDP interno.

Uma mensagem de erro semelhante à seguinte ocorre se você tentar excluir um balanceador de carga TCP/UDP interno que está sendo usado por um anexo de serviço. Você precisa excluir o ServiceAttachment antes de excluir o balanceador de carga TCP/UDP interno.

Error syncing load balancer: failed to ensure load balancer: googleapi:
Error 400: The forwarding_rule resource '<fwd-rule-URL>' is already being used
by '<svc-attachment-URL>', resourceInUseByAnotherResource.

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 endereço IP virtual do balanceador de carga TCP/UDP interno possa ser acessado por clientes nas regiões do Google Cloud	`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 do balanceador de carga TCP/UDP interno.

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

Para clientes locais, o acesso global permite que os clientes acessem o balanceador de carga usando o Cloud VPN ou o Cloud Interconnect (VLAN) em qualquer região. Para mais informações, consulte Como usar o Cloud VPN e o Cloud Interconnect.

IP compartilhado

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.

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

Salve a seguinte configuração do Serviço TCP em um arquivo chamado tcp-service.yaml e, depois, faça a implantação no cluster. Substitua IP_ADDRESS pelo endereço IP escolhido na etapa anterior.

apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: IP_ADDRESS
  selector:
    app: myapp
  ports:
  - name: 8001-to-8001
    protocol: TCP
    port: 8001
    targetPort: 8001
  - name: 8002-to-8002
    protocol: TCP
    port: 8002
    targetPort: 8002
  - name: 8003-to-8003
    protocol: TCP
    port: 8003
    targetPort: 8003
  - name: 8004-to-8004
    protocol: TCP
    port: 8004
    targetPort: 8004
  - name: 8005-to-8005
    protocol: TCP
    port: 8005
    targetPort: 8005

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_ADDRESS que você especificou na etapa anterior.

apiVersion: v1
kind: Service
metadata:
  name: udp-service
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: IP_ADDRESS
  selector:
    app: my-udp-app
  ports:
  - name: 9001-to-9001
    protocol: UDP
    port: 9001
    targetPort: 9001
  - name: 9002-to-9002
    protocol: UDP
    port: 9002
    targetPort: 9002

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

Todas as portas

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:
    networking.gke.io/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.4 e posterior, é possível usar balanceadores de carga internos com sub-redes de modo personalizado, além de sub-redes de modo automático.
Os clusters que executam a versão 1.7.X ou posterior do Kubernetes aceitam um endereço IP reservado para o balanceador de carga TCP/UDP interno se você criar o endereço IP reservado com o--purpose sinalização definida comoSHARED_LOADBALANCER_VIP , Consulte Como ativar o IP compartilhado para instruções detalhadas. O GKE só preserva o endereço IP de um balanceador de carga TCP/UDP interno se o Serviço referir-se a um endereço IP interno com essa finalidade. Caso contrário, o GKE poderá alterar o endereço IP do balanceador de carga (spec.loadBalancerIP) se o Serviço for atualizado (por exemplo, se as portas forem alteradas).
Mesmo que o endereço IP do balanceador de carga seja alterado (consulte o ponto anterior), o spec.clusterIP permanecerá constante.

Restrições para balanceadores de carga UDP internos

Os balanceadores de carga UDP internos não 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.

O número máximo de nós em um cluster do GKE com um balanceador de carga TCP/UDP interno depende do valor de externalTrafficPolicy:

externalTrafficPolicy: Cluster: o back-end do balanceador de carga TCP/UDP interno usa no máximo 250 nós selecionados aleatoriamente. Se o cluster tiver mais de 250 nós, todo o tráfego do balanceador de carga entrará no cluster por meio dos 250 nós e será encaminhado para um pod correspondente selecionado aleatoriamente. Não é recomendável usar esse modo com mais de 250 nós.
externalTrafficPolicy: Local: o back-end do balanceador de carga TCP/UDP interno usa no máximo 250 nós selecionados aleatoriamente. Se nenhum dos 250 nós selecionados executarem os pods de back-end para o serviço do balanceador de carga TCP/UDP interno, as conexões com o IP LoadBalancer falharão. Não é possível usar esse modo com mais de 250 nós.

Para remover essa limitação, ative a subconfiguração do balanceador de carga interno.

Para mais informações sobre os limites da VPC, consulte Cotas e limites.

Problemas conhecidos

Tempo limite de conexão a cada 10 minutos

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

1.18.19-gke.1700 e superior
1.19.10-gke.1000 e superior
1.20.6-gke.1000 e superior

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

Quando você cria um balanceador de carga TCP/UDP 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 foi resolvido nas versões 1.23.3-gke.900 e posteriores do GKE. O controlador do GKE cria balanceadores de carga TCP/UDP internos no nível de rede Premium, mesmo que o nível de rede padrão do projeto esteja definido como Padrão.

Como usar um balanceador de carga TCP/UDP interno

Visão geral

Nota

Arquitetura

Preços

Antes de começar

gcloud init

gcloud config

Criar uma implantação

Criar um balanceador de carga TCP interno

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

Requisitos mínimos de serviço

Como implantar o serviço

Como inspecionar o serviço

Como visualizar a regra de encaminhamento do balanceador de carga

Como funciona a abstração de serviço

Como verificar o balanceador de carga TCP interno

Como fazer a limpeza

kubectl

Excluir a implantação

Excluir o serviço

Console

Excluir a implantação

Excluir o serviço

Como usar a criação de subagrupamentos do balanceador de carga TCP/UDP interno

Arquitetura

Seleção de subconjunto de nós de back-end

Requisitos e limitações

Como ativar a criação de subconjuntos do balanceador de carga interno em um novo cluster

Console

gcloud

Como ativar a criação de subconjuntos do balanceador de carga interno em um cluster atual

Console

gcloud

Como verificar a criação de subconjuntos do balanceador de carga interno

Solução de problemas

Como criar um balanceador de carga TCP/UDP interno com o Private Service Connect

Requisitos e limitações

Como criar um ServiceAttachment

Como visualizar um ServiceAttachment

Como consumir um ServiceAttachment

Como atualizar um ServiceAttachment

Como fazer a limpeza

Solução de problemas

Parâmetros de serviço

Sub-rede do balanceador de carga

Acesso global

IP compartilhado

Limitações

Como ativar o IP compartilhado

Todas as portas

Requisitos

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

Restrições para balanceadores de carga UDP internos

Limites

Problemas conhecidos

Tempo limite de conexão a cada 10 minutos

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

A seguir