O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Configurar balanceadores de carga externos

Os balanceadores de carga externos (ELB, na sigla em inglês) expõem serviços para acesso de fora da organização usando um pool de endereços IP atribuídos à organização do pool de IP externo de instância maior.

Os endereços IP virtuais (VIP) do ELB não entram em conflito entre as organizações e são exclusivos em todas as organizações. Por isso, use os serviços do ELB apenas para serviços que os clientes de fora da organização precisam acessar.

As cargas de trabalho em execução na organização podem acessar os serviços do ELB, desde que você permita que elas saiam da organização. Esse padrão de tráfego exige tráfego de saída da organização antes de retornar ao serviço interno.

Há instruções distintas para configurar ELBs para clusters compartilhados e padrão.

Criar um balanceador de carga externo para clusters compartilhados

É possível criar ELBs globais ou zonais. O escopo dos ELBs globais abrange um universo do GDC. O escopo dos ELBs zonais é limitado à zona especificada no momento da criação. Para mais informações, consulte Balanceadores de carga globais e zonais.

Antes de começar

Para configurar os serviços do ELB, é necessário:

Ser proprietário do projeto em que você está configurando o balanceador de carga. Para saber mais, consulte Criar um projeto.
Ter uma política de entrada ProjectNetworkPolicy (PNP) personalizada para permitir o tráfego para esse serviço de ELB. Para mais informações, consulte Configurar o PNP para permitir o tráfego para o ELB.
Ter os papéis de identidade e acesso necessários:
- Administrador de NetworkPolicy do projeto: tem acesso para gerenciar políticas de rede do projeto no namespace do projeto. Peça ao administrador do IAM da organização para conceder a você o papel de Administrador de NetworkPolicy do projeto (project-networkpolicy-admin).
- Administrador do balanceador de carga: peça ao administrador do IAM da organização para conceder a você o papel de Administrador do balanceador de carga (load-balancer-admin).
- Administrador de balanceador de carga global: para ELBs globais, peça ao administrador do IAM da organização para conceder a você o papel de Administrador de balanceador de carga global (global-load-balancer-admin). Para mais informações, consulte Descrições de papéis predefinidos.

Configurar a PNP para permitir o tráfego para o ELB

Para que os serviços do ELB funcionem, é preciso configurar e aplicar sua própria política de entrada ProjectNetworkPolicy personalizada para permitir o tráfego para as cargas de trabalho desse serviço do ELB. As políticas de rede controlam o acesso às cargas de trabalho, não ao balanceador de carga em si. Os ELBs expõem cargas de trabalho à rede do cliente, exigindo políticas de rede explícitas para permitir o tráfego externo para a porta da carga de trabalho, como 8080.

Especifique o endereço CIDR externo para permitir o tráfego para as cargas de trabalho deste ELB:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

Substitua:

MANAGEMENT_API_SERVER: o caminho do kubeconfig do caminho do kubeconfig do servidor de API Management. Se você ainda não gerou um arquivo kubeconfig para o servidor de API na zona de destino, consulte Fazer login para mais detalhes.
PROJECT: o nome do projeto do GDC.
CIDR: o CIDR externo de onde o ELB precisa ser acessado. Essa política é necessária porque o balanceador de carga externo usa o Direct Server Return (DSR), que preserva o endereço IP externo de origem e ignora o balanceador de carga no caminho de retorno. Para mais informações, consulte Criar uma regra de firewall de entrada global para tráfego externo à organização.
PORT: a porta de back-end nos pods atrás do balanceador de carga. Esse valor é encontrado no campo .spec.ports[].targetPort do manifesto do recurso Service. Este campo é opcional.

Crie ELBs usando três métodos diferentes no GDC:

Use a CLI gdcloud para criar ELBs globais ou zonais.
Use a API Networking Kubernetes Resource Model (KRM) para criar ELBs globais ou zonais.
Use o serviço do Kubernetes diretamente no cluster do Kubernetes. Esse método está disponível apenas para ELBs zonais.

É possível segmentar cargas de trabalho de pods ou VMs usando a API KRM e a CLI gdcloud. Só é possível segmentar cargas de trabalho no cluster em que o objeto Service é criado quando você usa o serviço do Kubernetes diretamente no cluster do Kubernetes.

Criar um ELB zonal

Crie um ELB zonal usando a CLI gdcloud, a API KRM ou o serviço do Kubernetes no cluster do Kubernetes:

gdcloud

Crie um ELB que tenha como destino cargas de trabalho de pod ou VM usando a CLI gdcloud.

Esse ELB segmenta todas as cargas de trabalho no projeto que correspondem ao rótulo definido no objeto Backend.

Para criar um ELB usando a CLI gdcloud, siga estas etapas:

Crie um recurso Backend para definir o endpoint do ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=CLUSTER_NAME
```
Substitua:
- BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
- LABELS: um seletor que define quais endpoints entre pods e VMs usar para esse recurso de back-end. Por exemplo, app=web.
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona a ser usada para essa invocação. Para predefinir a flag de zona para todos os comandos que a exigem, execute: gdcloud config set core/zone ZONE. A flag de zona está disponível apenas em ambientes de várias zonas. Este campo é opcional.
- CLUSTER_NAME: o cluster ao qual o escopo dos seletores definidos está limitado. Se esse campo não for especificado, todos os endpoints com o rótulo fornecido serão selecionados. Este campo é opcional.
Pule esta etapa se o ELB for para cargas de trabalho de pod. Se você estiver configurando um ELB para cargas de trabalho de VM, defina o tipo de verificação de integridade para o ELB. Por exemplo, para criar uma verificação de integridade TCP, defina-a da seguinte maneira:
```
gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE
```
Substitua:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
- CHECK_INTERVAL: o tempo em segundos desde o início de uma sondagem até o início da próxima. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- HEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam ser aprovadas para que o endpoint seja considerado íntegro. O padrão é 5 quando omitido ou definido como 0.
- TIMEOUT: o tempo em segundos de espera antes de declarar falha. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam falhar para que o endpoint seja considerado não íntegro. O padrão é 2 quando omitido ou definido como 0.
- PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80. Este campo é opcional.
- ZONE: a zona em que você está criando o ELB.
Crie um recurso BackendService e adicione a ele o recurso Backend criado anteriormente:
```
gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME
```
Substitua:
- BACKEND_SERVICE_NAME: o nome escolhido para esse serviço de back-end.
- TARGET_PORT: uma lista separada por vírgulas de portas de destino que esse serviço de back-end traduz, em que cada porta de destino especifica o protocolo, a porta na regra de encaminhamento e a porta na instância de back-end. É possível especificar várias portas de destino. Esse campo precisa estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
- HEALTH_CHECK_NAME: o nome do recurso de verificação de integridade. Este campo é opcional. Inclua esse campo apenas se você estiver configurando um ELB para cargas de trabalho de VM.

Adicione o recurso BackendService ao recurso Backend criado anteriormente:

gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

Opcional: use a afinidade da sessão para ELBs para garantir que as solicitações do mesmo cliente sejam encaminhadas de forma consistente para o mesmo back-end. Para ativar a afinidade da sessão para balanceadores de carga, crie uma política de serviço de back-end usando o comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Substitua:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade da sessão. Há dois modos disponíveis:
  - NONE: a afinidade da sessão está desativada. As solicitações são roteadas para qualquer back-end disponível. Esse é o modo padrão.
  - CLIENT_IP_DST_PORT_PROTO: as solicitações da mesma tupla de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são roteadas para o mesmo back-end.
- RESOURCE_LABEL: o seletor de rótulos que seleciona a qual serviço de back-end o recurso BackendServicePolicy é aplicado no namespace do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e pelo menos uma dessas políticas tiver a afinidade da sessão ativada, a afinidade da sessão para esse recurso BackendService será ativada.
Crie um recurso ForwardingRule externo que defina o VIP em que o serviço está disponível:
```
gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME
```
Substitua:
- BACKEND_SERVICE_NAME: o nome do seu serviço de back-end.
- FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para a regra de encaminhamento.
- CIDR: este campo é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool de IPs zonais. Especifique o nome de um recurso Subnet no mesmo namespace que esta regra de encaminhamento. Um recurso Subnet representa as informações de solicitação e alocação de uma sub-rede zonal. Para mais informações sobre os recursos Subnet, consulte Exemplos de recursos personalizados.
- PROTOCOL_PORT: o protocolo e a porta a serem expostos na regra de encaminhamento. Esse campo precisa estar no formato ip-protocol=TCP:80. A porta exposta precisa ser a mesma que o aplicativo real está expondo dentro do contêiner.
Para verificar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Para receber o endereço IP atribuído do balanceador de carga, descreva a regra de encaminhamento:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Verifique o tráfego com uma solicitação curl para o VIP:
1. Para receber o VIP atribuído, descreva a regra de encaminhamento:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
2. Verifique o tráfego com uma solicitação curl para o VIP na porta especificada no campo PROTOCOL_PORT na regra de encaminhamento:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Substitua:
  - FORWARDING_RULE_VIP: o VIP da regra de encaminhamento.
  - PORT: o número da porta do campo PROTOCOL_PORT na regra de encaminhamento.

API

Crie um ELB que segmente cargas de trabalho de pod ou VM usando a API KRM. Esse ELB segmenta todas as cargas de trabalho no projeto que correspondem ao rótulo definido no objeto Backend.

Para criar um ELB zonal usando a API KRM, siga estas etapas:

Crie um recurso Backend para definir os endpoints do ELB. Crie recursos Backend para cada zona em que as cargas de trabalho são colocadas:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF
```
Substitua:
- MANAGEMENT_API_SERVER: o caminho do kubeconfig do servidor de API Management zonal. Para mais informações, consulte Mudar para um contexto zonal.
- PROJECT_NAME: o nome do projeto.
- BACKEND_NAME: o nome do recurso ;Backend
- CLUSTER_NAME: este campo é opcional. Esse campo especifica o cluster ao qual o escopo dos seletores definidos está limitado. Esse campo não se aplica a cargas de trabalho de VM. Se um recurso Backend não tiver o campo clusterName incluído, os rótulos especificados serão aplicados a todas as cargas de trabalho no projeto.
Pule esta etapa se o ELB for para cargas de trabalho de pod. Se você estiver configurando um ELB para cargas de trabalho de VM, defina uma verificação de integridade para o ELB:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF
```
Substitua:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
- PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80.
- TIMEOUT: o tempo em segundos de espera antes de declarar falha. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- CHECK_INTERVAL: o tempo em segundos desde o início de uma sondagem até o início da próxima. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- HEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam ser aprovadas para que o endpoint seja considerado íntegro. O padrão é 2 quando omitido ou definido como 0.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam falhar para que o endpoint seja considerado não íntegro. O padrão é 2 quando omitido ou definido como 0.
Crie um objeto BackendService usando o recurso Backend criado anteriormente. Se você estiver configurando um ELB para cargas de trabalho de VM, inclua o recurso HealthCheck.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF
```
Substitua:
- BACKEND_SERVICE_NAME: o nome escolhido para o recurso BackendService.
- HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente. Não inclua esse campo se estiver configurando um ELB para cargas de trabalho de pod.
Opcional: use a afinidade da sessão para ELBs para garantir que as solicitações do mesmo cliente sejam encaminhadas de forma consistente para o mesmo back-end. Para ativar a afinidade da sessão para balanceadores de carga, crie um recurso BackendServicePolicy. Esse recurso define as configurações de afinidade da sessão e aplica o recurso BackendServicePolicy ao recurso BackendService. Crie e aplique o recurso BackendServicePolicy:
```
 kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL
```
Substitua:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade da sessão. Há dois modos disponíveis:
  - NONE: a afinidade da sessão está desativada. As solicitações são roteadas para qualquer back-end disponível. Esse é o modo padrão.
  - CLIENT_IP_DST_PORT_PROTO: as solicitações da mesma tupla de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são roteadas para o mesmo back-end.
- RESOURCE_LABEL: o seletor de rótulos que seleciona a qual serviço de back-end o recurso BackendServicePolicy é aplicado no namespace do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e pelo menos uma dessas políticas tiver a afinidade da sessão ativada, a afinidade da sessão para esse recurso BackendService será ativada.
Crie um recurso ForwardingRule externo que defina o VIP em que o serviço está disponível.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
Substitua:
- BACKEND_SERVICE_NAME: o nome do recurso BackendService.
- FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para o recurso ForwardingRuleExternal.
- CIDR_NAME: o campo cidrRef é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool de IPs zonais. Especifique o nome de um recurso Subnet no mesmo namespace que essa regra de encaminhamento. Um recurso Subnet representa as informações de solicitação e alocação de uma sub-rede zonal. Para mais informações sobre recursos Subnet, consulte Exemplos de recursos personalizados.
- PORT: use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados aos back-ends configurados com essa regra de encaminhamento. É necessário especificar pelo menos uma porta. Use o campo port para especificar um número de porta. A porta exposta precisa ser a mesma que o aplicativo real está expondo dentro do contêiner.
- PROTOCOL: o protocolo a ser usado para a regra de encaminhamento, como TCP. Uma entrada na matriz ports precisa ser semelhante ao seguinte:
```
ports:
- port: 80
  protocol: TCP
```
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Verifique o tráfego com uma solicitação curl para o VIP:
1. Para receber o VIP, use kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  A saída será assim:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
```
2. Verifique o tráfego com uma solicitação curl para o VIP na porta especificada no campo PORT na regra de encaminhamento:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Substitua FORWARDING_RULE_VIP pelo VIP da regra de encaminhamento.

Serviço do Kubernetes

É possível criar ELBs no GDC criando um Service do Kubernetes do tipo LoadBalancer em um cluster do Kubernetes.

Para criar um serviço de ELB, faça o seguinte:

Crie um arquivo YAML para a definição de Service do tipo LoadBalancer.

Observação :ao contrário do processo para balanceadores de carga internos, não adicione anotações ao arquivo. Se você não especificar a anotação internal, o serviço será voltado para o exterior por padrão.

O objeto Service a seguir é um exemplo de serviço do ELB:
```
apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer
```
Substitua:
- ELB_SERVICE_NAME: o nome do serviço do ELB.
- PROJECT_NAME: o namespace do projeto que contém as cargas de trabalho de back-end.
O campo port configura a porta de front-end que você expõe no endereço VIP. O campo targetPort configura a porta de back-end para onde você quer encaminhar o tráfego nas cargas de trabalho de back-end. O balanceador de carga é compatível com a conversão de endereços de rede (NAT). As portas de front-end e back-end podem ser diferentes.
No campo selector da definição de Service, especifique pods ou máquinas virtuais como as cargas de trabalho de back-end.

O seletor define quais cargas de trabalho serão usadas como cargas de trabalho de back-end para esse serviço, com base na correspondência entre os rótulos que você especificar e os rótulos nas cargas de trabalho. O Service só pode selecionar cargas de trabalho de back-end no mesmo projeto e no mesmo cluster em que você define o Service.

Para mais informações sobre a seleção de serviços, consulte https://kubernetes.io/docs/concepts/services-networking/service/.
Salve o arquivo de definição Service no mesmo projeto que as cargas de trabalho de back-end.
Aplique o arquivo de definição Service ao cluster:
```
kubectl apply -f ELB_FILE
```
Substitua ELB_FILE pelo nome do arquivo de definição Service do serviço do ELB.

Quando você cria um ELB, o serviço recebe dois endereços IP. Um é um endereço IP interno acessível apenas no mesmo cluster. O outro é o endereço IP externo, acessível de dentro e de fora da organização. Para ver os endereços IP do serviço do ELB, confira o status do serviço:
```
kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME
```
Substitua:
- PROJECT_NAME: o namespace do projeto que contém as cargas de trabalho de back-end.
- ELB_SERVICE_NAME: o nome do serviço do ELB.
Você vai receber uma saída semelhante a este exemplo:
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h
```
O EXTERNAL-IP é o endereço IP do serviço que pode ser acessado de fora da organização.

Se você não receber uma saída, verifique se criou o serviço ELB corretamente.

Criar um ELB global

Crie um ELB global usando a CLI gdcloud ou a API KRM.

gdcloud

Crie um ELB que tenha como destino cargas de trabalho de pod ou VM usando a CLI gdcloud.

Esse ELB segmenta todas as cargas de trabalho no projeto que correspondem ao rótulo definido no objeto Backend. O recurso personalizado Backend precisa ter o escopo definido para uma zona.

Para criar um ELB usando a CLI gdcloud, siga estas etapas:

Crie um recurso Backend para definir o endpoint do ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=CLUSTER_NAME \
  --zone=ZONE
```
Substitua:
- BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
- LABELS: um seletor que define quais endpoints entre pods e VMs usar para esse recurso de back-end. Por exemplo, app=web.
- PROJECT_NAME: o nome do projeto.
- CLUSTER_NAME: o cluster ao qual o escopo dos seletores definidos está limitado. Se esse campo não for especificado, todos os endpoints com o rótulo fornecido serão selecionados. Este campo é opcional.
- ZONE: a zona a ser usada para essa invocação. Para predefinir a flag de zona para todos os comandos que exigem isso, execute: gdcloud config set core/zone ZONE. A flag de zona está disponível apenas em ambientes de várias zonas. Este campo é opcional.
Pule esta etapa se o ELB for para cargas de trabalho de pod. Se você estiver configurando um ELB para cargas de trabalho de VM, defina uma verificação de integridade para o ELB:
```
gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global
```
Substitua:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
- CHECK_INTERVAL: o tempo em segundos desde o início de uma sondagem até o início da próxima. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- HEALTHY_THRESHOLD: o tempo de espera antes de declarar falha. O padrão é 5 quando omitido ou definido como 0.
- TIMEOUT: o tempo em segundos de espera antes de declarar falha. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam falhar para que o endpoint seja considerado não íntegro. O padrão é 2 quando omitido ou definido como 0.
- PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80. Este campo é opcional.
Crie um recurso BackendService e adicione a ele o recurso Backend criado anteriormente:
```
gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global
```
Substitua:
- BACKEND_SERVICE_NAME: o nome escolhido para esse serviço de back-end.
- TARGET_PORTS: uma lista separada por vírgulas de portas de destino que esse serviço de back-end traduz, em que cada porta de destino especifica o protocolo, a porta na regra de encaminhamento e a porta na instância de back-end. É possível especificar várias portas de destino. Esse campo precisa estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
- HEALTH_CHECK_NAME: o nome do recurso de verificação de integridade. Este campo é opcional. Inclua esse campo apenas se você estiver configurando um ELB para cargas de trabalho de VM.

Adicione o recurso BackendService ao recurso Backend criado anteriormente:

gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT_NAME \
  --global

Opcional: use a afinidade da sessão para ELBs para garantir que as solicitações do mesmo cliente sejam encaminhadas de forma consistente para o mesmo back-end. Para ativar a afinidade da sessão para balanceadores de carga, crie uma política de serviço de back-end usando o comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Substitua:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade da sessão. Há dois modos disponíveis:
  - NONE: a afinidade da sessão está desativada. As solicitações são roteadas para qualquer back-end disponível. Esse é o modo padrão.
  - CLIENT_IP_DST_PORT_PROTO: as solicitações da mesma tupla de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são roteadas para o mesmo back-end.
- RESOURCE_LABEL: o seletor de rótulos que seleciona a qual serviço de back-end o recurso BackendServicePolicy é aplicado no namespace do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e pelo menos uma dessas políticas tiver a afinidade da sessão ativada, a afinidade da sessão para esse recurso BackendService será ativada.
Crie um recurso ForwardingRule externo que defina o VIP em que o serviço está disponível:
```
gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT_NAME \
  --global
```
Substitua:
- BACKEND_SERVICE_NAME: o nome do seu serviço de back-end.
- FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para a regra de encaminhamento.
- CIDR: este campo é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool de IPs global. Especifique o nome de um recurso Subnet no mesmo namespace que esta regra de encaminhamento. Um recurso Subnet representa as informações de solicitação e alocação de uma sub-rede global. Para mais informações sobre os recursos do Subnet, consulte Exemplos de recursos personalizados.
- PROTOCOL_PORT: o protocolo e a porta a serem expostos na regra de encaminhamento. Esse campo precisa estar no formato ip-protocol=TCP:80. A porta exposta precisa ser a mesma que o aplicativo real está expondo dentro do contêiner.
Para verificar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Para receber o endereço IP atribuído do balanceador de carga, descreva a regra de encaminhamento:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Verifique o tráfego com uma solicitação curl para o VIP:
1. Para receber o VIP atribuído, descreva a regra de encaminhamento:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global
```
2. Verifique o tráfego com uma solicitação curl para o VIP na porta especificada no campo PROTOCOL_PORT na regra de encaminhamento:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Substitua:
  - FORWARDING_RULE_VIP: o VIP da regra de encaminhamento.
  - PORT: o número da porta do campo PROTOCOL_PORT na regra de encaminhamento.

API

Crie um ELB que segmente cargas de trabalho de pod ou VM usando a API KRM. Esse ELB tem como destino todas as cargas de trabalho no projeto que correspondem ao rótulo definido no objeto de back-end. Para criar um ELB zonal usando a API KRM, siga estas etapas:

Crie um recurso Backend para definir os endpoints do ELB. Crie recursos Backend para cada zona em que as cargas de trabalho são colocadas:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF
```
Substitua:
- MANAGEMENT_API_SERVER: o caminho do kubeconfig do servidor de API Management global. Para mais informações, consulte Mudar para o contexto global.
- PROJECT_NAME: o nome do projeto.
- BACKEND_NAME: o nome do recurso ;Backend
- CLUSTER_NAME: este campo é opcional. Esse campo especifica o cluster ao qual o escopo dos seletores definidos está limitado. Esse campo não se aplica a cargas de trabalho de VM. Se um recurso Backend não tiver o campo clusterName incluído, os rótulos especificados serão aplicados a todas as cargas de trabalho no projeto.
Pule esta etapa se o ELB for para cargas de trabalho de pod. Se você estiver configurando um ELB para cargas de trabalho de VM, defina uma verificação de integridade para o ELB:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF
```
Substitua:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
- PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80.
- TIMEOUT: o tempo em segundos de espera antes de declarar falha. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- CHECK_INTERVAL: o tempo em segundos desde o início de uma sondagem até o início da próxima. O padrão é 5 quando omitido ou definido como 0. Não é recomendável definir um tempo limite maior que checkInterval.
- HEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam ser aprovadas para que o endpoint seja considerado íntegro. O padrão é 2 quando omitido ou definido como 0.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam falhar para que o endpoint seja considerado não íntegro. O padrão é 2 quando omitido ou definido como 0.
Como esse é um ELB global, crie a verificação de integridade na API global.
Crie um objeto BackendService usando o recurso Backend criado anteriormente. Se você estiver configurando um ELB para cargas de trabalho de VM, inclua o recurso HealthCheck.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF
```
Substitua:
- BACKEND_SERVICE_NAME: o nome escolhido para o recurso BackendService.
- HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente. Não inclua esse campo se estiver configurando um ELB para cargas de trabalho de pod.
- ZONE: a zona em que o recurso Backend é criado. É possível especificar vários back-ends no campo backendRefs. Exemplo:
```
- name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B
```
- O campo targetPorts é opcional. Esse recurso lista as portas que o recurso BackendService traduz. Se você estiver usando esse objeto, forneça valores para o seguinte:
  - PORT: a porta exposta pelo serviço.
  - PROTOCOL: o protocolo da camada 4 que o tráfego precisa corresponder. Somente TCP e UDP são compatíveis.
  - TARGET_PORT: a porta para a qual o valor PORT é convertido, como 8080. O valor de TARGET_PORT não pode ser repetido em um determinado objeto. Um exemplo para targetPorts seria assim:
```
targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080
```
Opcional: use a afinidade da sessão para ELBs para garantir que as solicitações do mesmo cliente sejam encaminhadas de forma consistente para o mesmo back-end. Para ativar a afinidade da sessão para balanceadores de carga, crie um recurso BackendServicePolicy. Esse recurso define as configurações de afinidade da sessão e aplica o recurso BackendServicePolicy ao recurso BackendService. Crie e aplique o recurso BackendServicePolicy:
```
 kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL
```
Substitua:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade da sessão. Há dois modos disponíveis:
  - NONE: a afinidade da sessão está desativada. As solicitações são roteadas para qualquer back-end disponível. Esse é o modo padrão.
  - CLIENT_IP_DST_PORT_PROTO: as solicitações da mesma tupla de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são roteadas para o mesmo back-end.
- RESOURCE_LABEL: o seletor de rótulos que seleciona a qual serviço de back-end o recurso BackendServicePolicy é aplicado no namespace do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e pelo menos uma dessas políticas tiver a afinidade da sessão ativada, a afinidade da sessão para esse recurso BackendService será ativada.
Crie um recurso ForwardingRule externo que defina o VIP em que o serviço está disponível.
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
Substitua:
- FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para o recurso ForwardingRuleExternal.
- CIDR_NAME: o campo cidrRef é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool de IPs global. Especifique o nome de um recurso Subnet no mesmo namespace que esta regra de encaminhamento. Um recurso Subnet representa as informações de solicitação e alocação de uma sub-rede global. Para mais informações sobre os recursos do Subnet, consulte Exemplos de recursos personalizados.
- PORT: use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados aos back-ends configurados com essa regra de encaminhamento. É necessário especificar pelo menos uma porta. Use o campo port para especificar um número de porta. A porta exposta precisa ser a mesma que o aplicativo real está expondo dentro do contêiner.
- PROTOCOL: o protocolo a ser usado para a regra de encaminhamento, como TCP. Uma entrada na matriz ports precisa ser semelhante ao seguinte:
```
ports:
- port: 80
  protocol: TCP
```
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Verifique o tráfego com uma solicitação curl para o VIP:
1. Para receber o VIP, use kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  A saída será assim:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
```
2. Verifique o tráfego com uma solicitação curl para o VIP na porta especificada no campo PORT na regra de encaminhamento:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Substitua FORWARDING_RULE_VIP pelo VIP da regra de encaminhamento.

Criar um balanceador de carga externo para clusters padrão

Um proprietário de aplicativo (AO, na sigla em inglês) pode criar um serviço do Kubernetes do tipo LoadBalancer para expor serviços externamente. Esse serviço só pode selecionar os back-ends no cluster padrão em que o serviço é criado. Isso equivale a um ELB com escopo de cluster zonal. O ELB global não é compatível com clusters padrão. Para mais informações, consulte Balanceadores de carga globais e zonais.

Antes de começar

Para configurar os serviços do ELB, é necessário:

Ser proprietário do projeto em que você está configurando o balanceador de carga. Para saber mais, consulte Criar um projeto.
Ter uma política de entrada ProjectNetworkPolicy (PNP) personalizada para permitir o tráfego para esse serviço de ELB. Para mais informações, consulte Configurar o PNP para permitir o tráfego para o ELB em clusters padrão.
Ter os papéis de identidade e acesso necessários:
- Administrador de NetworkPolicy do projeto: tem acesso para gerenciar políticas de rede do projeto no namespace do projeto. Peça ao administrador da organização do IAM para conceder a você o papel de administrador de NetworkPolicy do projeto (project-networkpolicy-admin).
- Administrador do balanceador de carga: peça ao administrador do IAM da organização para conceder a você o papel de Administrador do balanceador de carga (load-balancer-admin).

Configurar o PNP para permitir o tráfego para o ELB em clusters padrão

O exemplo de arquivo YAML de política de rede do projeto a seguir permite que o tráfego de uma carga de trabalho em outro projeto acesse uma carga de trabalho no projeto atual pelo ELB.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: my-sc-1
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: my-app-ns
        workloads:
          matchLabels:
            app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

Criar um ELB zonal para clusters padrão

É possível criar ELBs no GDC criando um Service do Kubernetes do tipo LoadBalancer no cluster padrão do Kubernetes.

Para criar um serviço de ELB, faça o seguinte:

Crie um arquivo YAML para a definição de Service do tipo LoadBalancer.

Observação :ao contrário do processo para balanceadores de carga internos, não adicione anotações ao arquivo. Se você não especificar a anotação internal, o serviço será voltado para o exterior por padrão.

O objeto Service a seguir é um exemplo de serviço do ELB:
```
apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: ELB_SERVICE_NAMESPACE
spec:
  ports:
  - port: PORT
    protocol: TCP
    targetPort: TARGET_PORT
  selector:
    k8s-app: my-app # Example selector, replace with your workload's labels
  type: LoadBalancer
```
Substitua:
- ELB_SERVICE_NAME: o nome do serviço do ELB.
- ELB_SERVICE_NAMESPACE: o namespace no cluster padrão que contém as cargas de trabalho de back-end.
- PORT: a porta exposta pelo próprio serviço do Kubernetes. Outros serviços ou clientes externos no cluster vão se conectar a essa porta no endereço IP do Serviço.
- TARGET_PORT: a porta dentro do contêiner do pod em que o aplicativo está sendo executado e detectando conexões recebidas. Pode ser uma porta numérica ou uma porta nomeada definida na especificação do contêiner do pod.
O campo port configura a porta de front-end que você expõe no endereço VIP. O campo targetPort configura a porta de back-end para onde você quer encaminhar o tráfego nas cargas de trabalho de back-end. O balanceador de carga é compatível com a conversão de endereços de rede (NAT). As portas de front-end e back-end podem ser diferentes.
No campo selector da definição de Service, especifique pares de chave-valor para corresponder às cargas de trabalho de back-end. Para clusters padrão, apenas pods são compatíveis como cargas de trabalho.

que você define, com base na correspondência dos rótulos especificados com os rótulos nas cargas de trabalho. O Service só pode selecionar cargas de trabalho de back-end no mesmo projeto e cluster em que você define o Service.

Para mais informações sobre a seleção de serviços, consulte https://kubernetes.io/docs/concepts/services-networking/service/.
Salve a especificação Service em um arquivo YAML. Substitua o nome do arquivo por ELB_FILE no comando a seguir.
Aplique o arquivo de definição Service ao cluster:
```
export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ELB_FILE
```
Substitua:
- ELB_FILE:o nome do arquivo de definição Service para o serviço ELB.
- KUBECONFIG_PATH: o caminho para o arquivo kubeconfig do cluster padrão.
Para conferir os endereços IP do serviço do ELB, consulte o status do serviço:
```
kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME
```
Substitua:
- ELB_SERVICE_NAMESPACE: o namespace que contém as cargas de trabalho de back-end.
- ELB_SERVICE_NAME: o nome do serviço do ELB.
Você vai receber uma saída semelhante a este exemplo:
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h
```
O EXTERNAL-IP é o endereço IP do serviço que pode ser acessado de fora da organização.

Selecionar uma VM como back-end para um balanceador de carga

Para vincular uma VM ao balanceador de carga:

Verifique se a VM tem um rótulo que corresponde ao seletor de rótulos usado na configuração do balanceador de carga.

Por exemplo, se a VM não tiver um rótulo apropriado, adicione o rótulo especificado do objeto de back-end da zona correspondente à VM:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL
```
Substitua:
- LABEL: um rótulo que corresponde ao LabelSelector na configuração do balanceador de carga, como app=server.
- VM_NAME: o nome da máquina virtual que está sendo vinculada.
- PROJECT_NAME: o nome do projeto.
Verifique se o servidor está detectando na mesma porta especificada no objeto HealthCheck.

Configurar balanceadores de carga externos Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Criar um balanceador de carga externo para clusters compartilhados

Antes de começar

Configurar a PNP para permitir o tráfego para o ELB

Criar um ELB zonal

gdcloud

API

Serviço do Kubernetes

Criar um ELB global

gdcloud

API

Criar um balanceador de carga externo para clusters padrão

Antes de começar

Configurar o PNP para permitir o tráfego para o ELB em clusters padrão

Criar um ELB zonal para clusters padrão

Selecionar uma VM como back-end para um balanceador de carga

Configurar balanceadores de carga externos