Esta página foi traduzida pela API Cloud Translation.

Configure balanceadores de carga externos

Os equilibradores de carga externos (ELB) expõem serviços para acesso a partir do exterior da organização a partir dos endereços IP de um conjunto atribuídos à organização a partir do conjunto de IPs externos de instâncias maior.

Os endereços IP virtuais (VIP) do ELB não entram em conflito entre organizações e são únicos em todas as organizações. Por este motivo, tem de usar os serviços ELB apenas para serviços aos quais os clientes fora da organização têm necessariamente de aceder.

As cargas de trabalho executadas na organização podem aceder aos serviços ELB, desde que permita que as cargas de trabalho saiam da organização. Este padrão de tráfego requer efetivamente tráfego de saída da organização antes de regressar ao serviço interno.

Antes de começar

Para configurar os serviços ELB, tem de ter o seguinte:

Ser proprietário do projeto para o qual está a configurar o equilibrador de carga. Para mais informações, consulte Crie um projeto.
Uma política de entrada (PNP) ProjectNetworkPolicy personalizada para permitir o tráfego para este serviço ELB. Para mais informações, consulte o artigo Configure o PNP para permitir tráfego para o ELB.
As funções de identidade e acesso necessárias:
- Administrador de NetworkPolicy do projeto: tem acesso à gestão de políticas de rede do projeto no espaço de nomes do projeto. Peça ao administrador do IAM da organização que lhe conceda a função de administrador de NetworkPolicy do projeto (project-networkpolicy-admin).
- Administrador do balanceador de carga: peça ao administrador do IAM da organização para lhe conceder a função de administrador do balanceador de carga (load-balancer-admin).
- Administrador do balanceador de carga global: para ELBs globais, peça ao administrador do IAM da organização que lhe conceda a função de administrador do balanceador de carga global (global-load-balancer-admin). Para mais informações, consulte o artigo Descrições de funções predefinidas.

Configure o PNP para permitir tráfego para o ELB

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

Especifique o endereço CIDR externo para permitir 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 o seguinte:

MANAGEMENT_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor da API Management. Se ainda não gerou um ficheiro kubeconfig para o servidor da API na sua zona segmentada, consulte Iniciar sessão para ver detalhes.
PROJECT: o nome do seu projeto do GDC.
CIDR: o CIDR externo a partir do qual o ELB tem de ser acedido. Esta política é necessária porque o balanceador de carga externo usa o retorno direto do servidor (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 o artigo Crie uma regra de firewall de entrada global para tráfego externo à organização.
PORT: a porta de back-end nos agrupamentos atrás do balanceador de carga. Este valor encontra-se no campo .spec.ports[].targetPortService do manifesto para o recurso Service. Este campo é opcional.

Crie um balanceador de carga externo

Pode criar ELBs globais ou zonais. O âmbito dos ELBs globais abrange um universo de GDCs. O âmbito dos ELBs zonais está limitado à zona especificada no momento da criação. Para mais informações, consulte o artigo Equilibradores de carga globais e zonais.

Crie ELBs com 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 Kubernetes diretamente no cluster Kubernetes. Este método só está disponível para ELBs zonais.

Pode segmentar cargas de trabalho de pods ou VMs através da API KRM e da CLI gdcloud. Só pode segmentar cargas de trabalho no cluster onde o objeto Service é criado quando usa o serviço Kubernetes diretamente no cluster Kubernetes.

Crie um ELB zonal

Crie um ELB zonal através da CLI gdcloud, da API KRM ou do serviço Kubernetes no cluster Kubernetes:

gdcloud

Crie um ELB que tenha como destino cargas de trabalho de pods ou VMs através da CLI gdcloud.

Este ELB segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend.

Para criar um ELB através da CLI gdcloud, siga estes passos:

Crie um recurso Backend para definir o ponto final do ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=CLUSTER_NAME
```
Substitua o seguinte:
- BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
- LABELS: um seletor que define que pontos finais entre pods e VMs usar para este recurso de back-end. Por exemplo, app=web.
- PROJECT_NAME: o nome do seu projeto.
- ZONE: a zona a usar para esta invocação. Para predefinir a flag de zona para todos os comandos que a requerem, execute: gdcloud config set core/zone ZONE. O indicador de zona só está disponível em ambientes com várias zonas. Este campo é opcional.
- CLUSTER_NAME: o cluster ao qual o âmbito dos seletores definidos está limitado. Se este campo não for especificado, são selecionados todos os pontos finais com a etiqueta fornecida. Este campo é opcional.
Ignore este passo se este ELB for para cargas de trabalho de pods. Se estiver a configurar um ELB para cargas de trabalho de VMs, defina uma verificação de funcionamento 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 \
  --zone=ZONE
```
Substitua o seguinte:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação do estado de funcionamento, como my-health-check.
- CHECK_INTERVAL: o período em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5. Este campo é opcional.
- HEALTHY_THRESHOLD: o tempo de espera antes de reclamar a falha. O valor predefinido é 5. Este campo é opcional.
- TIMEOUT: o período de tempo em segundos a aguardar antes de declarar a falha. O valor predefinido é 5. Este campo é opcional.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2. Este campo é opcional.
- PORT: a porta na qual a verificação de funcionamento é realizada. O valor predefinido é 80. Este campo é opcional.
- ZONE: a zona na qual está a criar este ELB.
Crie um recurso BackendService e adicione-lhe 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 o seguinte:
- BACKEND_SERVICE_NAME: o nome escolhido para este serviço de back-end.
- TARGET_PORT: uma lista de portas de destino separada por vírgulas que este 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. Pode especificar várias portas de destino. Este campo tem de estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
- HEALTH_CHECK_NAME: o nome do recurso de verificação de estado. Este campo é opcional. Inclua este campo apenas se estiver a configurar um ELB para cargas de trabalho de VMs.

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 de sessão para ELBs para garantir que os pedidos do mesmo cliente são encaminhados de forma consistente para o mesmo back-end. Para ativar a afinidade de sessão para balanceadores de carga, crie uma política de serviço de back-end com o comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Substitua o seguinte:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade de sessão. São suportados dois modos:
  - NONE: a afinidade de sessão está desativada. Os pedidos são encaminhados para qualquer back-end disponível. Este é o modo predefinido.
  - CLIENT_IP_DST_PORT_PROTO: os pedidos do mesmo conjunto de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são encaminhados para o mesmo back-end.
- RESOURCE_LABEL: o seletor de etiquetas que seleciona a que serviço de back-end o recurso BackendServicePolicy é aplicado no espaço de nomes do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e, pelo menos, uma destas políticas tiver a afinidade de sessão ativada, a afinidade de sessão para este recurso BackendService fica ativada.
Crie um recurso ForwardingRule externo que defina o VIP no qual 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 o seguinte:
- 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, é reservado automaticamente um IPv4/32 CIDR do conjunto de IPs zonais. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede zonal. Para mais informações sobre os recursos Subnet, consulte o artigo Exemplos de recursos personalizados.
- PROTOCOL_PORT: o protocolo e a porta a expor na regra de encaminhamento. Este campo tem de estar no formato ip-protocol=TCP:80. A porta exposta tem de ser a mesma que a aplicação real está a expor no contentor.
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Para obter 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. Valide o tráfego com um curl pedido ao VIP:
1. Para obter o VIP atribuído, descreva a regra de encaminhamento:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
2. Valide o tráfego com um pedido curl para o VIP na porta especificada no campo PROTOCOL_PORT na regra de encaminhamento:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Substitua o seguinte:
  - 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 pods ou VMs através da API KRM. Este ELB segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend.

Para criar um ELB zonal através da API KRM, siga estes passos:

Crie um recurso Backend para definir os pontos finais do ELB. Crie recursos Backend para cada zona em que as cargas de trabalho estão localizadas:
```
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 o seguinte:
- MANAGEMENT_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor da API Management zonal. Para mais informações, consulte o artigo Mude para um contexto zonal.
- PROJECT_NAME: o nome do seu projeto.
- BACKEND_NAME: o nome do recurso Backend.
- CLUSTER_NAME: este é um campo opcional. Este campo especifica o cluster ao qual o âmbito dos seletores definidos está limitado. Este campo não se aplica a cargas de trabalho de VMs. Se um recurso Backend não tiver o campo clusterName incluído, as etiquetas especificadas aplicam-se a todas as cargas de trabalho no projeto.
Ignore este passo se este ELB for para cargas de trabalho de pods. Se estiver a configurar um ELB para cargas de trabalho de VMs, defina uma verificação de funcionamento 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 o seguinte:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação do estado de funcionamento, como my-health-check.
- PORT: a porta na qual a verificação de funcionamento é realizada. O valor predefinido é 80.
- TIMEOUT: o período de tempo em segundos a aguardar antes de declarar a falha. O valor predefinido é 5.
- CHECK_INTERVAL: o período em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5.
- HEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de ser aprovadas para que o ponto final seja considerado em bom estado. O valor predefinido é 2.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2.
Crie um objeto BackendService com o recurso Backend criado anteriormente. Se estiver a configurar um ELB para cargas de trabalho de VMs, 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 o seguinte:
- BACKEND_SERVICE_NAME: o nome escolhido para o seu recurso BackendService.
- HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente. Não inclua este campo se estiver a configurar um ELB para cargas de trabalho de pods.
Opcional: use a afinidade de sessão para ELBs para garantir que os pedidos do mesmo cliente são encaminhados de forma consistente para o mesmo back-end. Para ativar a afinidade de sessão para balanceadores de carga, crie um recurso BackendServicePolicy. Este recurso define as definições de afinidade de 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 o seguinte:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade de sessão. São suportados dois modos:
  - NONE: a afinidade de sessão está desativada. Os pedidos são encaminhados para qualquer back-end disponível. Este é o modo predefinido.
  - CLIENT_IP_DST_PORT_PROTO: os pedidos do mesmo conjunto de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são encaminhados para o mesmo back-end.
- RESOURCE_LABEL: o seletor de etiquetas que seleciona a que serviço de back-end o recurso BackendServicePolicy é aplicado no espaço de nomes do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e, pelo menos, uma destas políticas tiver a afinidade de sessão ativada, a afinidade de sessão para este recurso BackendService fica ativada.
Crie um recurso ForwardingRule externo que defina o VIP no qual 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: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
Substitua o seguinte:
- BACKEND_SERVICE_NAME: o nome do seu recurso BackendService.
- FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para o seu recurso ForwardingRuleExternal.
- CIDR: este campo é opcional. Se não for especificado, é reservado automaticamente um IPv4/32 CIDR do conjunto de IPs zonais. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede zonal. Para mais informações sobre Subnet recursos, consulte o artigo Exemplos de recursos personalizados.
- PORT: use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados para os back-ends configurados com esta regra de encaminhamento. Tem de especificar, pelo menos, uma porta. Use o campo port para especificar um número de porta. A porta exposta tem de ser a mesma que a aplicação real está a expor no contentor.
- PROTOCOL: o protocolo a usar para a regra de encaminhamento, como TCP. Uma entrada na matriz ports tem de ter o seguinte aspeto:
```
ports:
- port: 80
  protocol: TCP
```
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Valide o tráfego com um curl pedido ao VIP:
1. Para receber o VIP, use a app kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  O resultado tem o seguinte aspeto:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
```
2. Valide o tráfego com um pedido 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

Pode criar ELBs no GDC criando um Kubernetes Service do tipo LoadBalancer num cluster Kubernetes.

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

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

Nota: ao contrário do processo para equilibradores de carga internos, não adicione anotações no ficheiro. Se não especificar a anotação internal, o serviço é orientado para o exterior por predefinição.

O objeto Service seguinte é um exemplo de um serviço 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 o seguinte:
- ELB_SERVICE_NAME: o nome do serviço ELB.
- PROJECT_NAME: o espaço de nomes do seu projeto que contém as cargas de trabalho de back-end.
O campo port configura a porta de front-end que expõe no endereço VIP. O campo targetPort configura a porta de back-end para a qual quer encaminhar o tráfego nas cargas de trabalho de back-end. O balanceador de carga suporta a tradução de endereços de rede (NAT). As portas de front-end e back-end podem ser diferentes.
No campo selector da definição Service, especifique pods ou máquinas virtuais como as cargas de trabalho de back-end.

O seletor define que cargas de trabalho devem ser consideradas cargas de trabalho de back-end para este serviço, com base na correspondência das etiquetas especificadas com as etiquetas nas cargas de trabalho. O Service só pode selecionar cargas de trabalho de back-end no mesmo projeto e no mesmo cluster onde define o Service.

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

Quando cria um ELB, o serviço recebe dois endereços IP. Um é um endereço IP interno acessível apenas a partir do mesmo cluster. O outro é o endereço IP externo, acessível a partir do interior e exterior da organização. Pode obter os endereços IP do serviço ELB consultando o estado do serviço:
```
kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME
```
Substitua o seguinte:
- PROJECT_NAME: o espaço de nomes do seu projeto que contém as cargas de trabalho de back-end.
- ELB_SERVICE_NAME: o nome do serviço ELB.
Tem de obter um resultado semelhante ao seguinte 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 acessível a partir de fora da organização.

Se não obtiver um resultado, certifique-se de que criou o serviço ELB com êxito.

Crie um ELB global

Crie um ELB global através da CLI gdcloud ou da API KRM.

gdcloud

Crie um ELB que tenha como destino cargas de trabalho de pods ou VMs através da CLI gdcloud.

Este ELB segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend. O recurso personalizado Backend tem de ter o âmbito de uma zona.

Para criar um ELB através da CLI gdcloud, siga estes passos:

Crie um recurso Backend para definir o ponto final do ELB:
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster=CLUSTER_NAME \
  --zone=ZONE
```
Substitua o seguinte:
- BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
- LABELS: um seletor que define que pontos finais entre pods e VMs usar para este recurso de back-end. Por exemplo, app=web.
- PROJECT_NAME: o nome do seu projeto.
- CLUSTER_NAME: o cluster ao qual o âmbito dos seletores definidos está limitado. Se este campo não for especificado, são selecionados todos os pontos finais com a etiqueta fornecida. Este campo é opcional.
- ZONE: a zona a usar para esta invocação. Para predefinir a flag de zona para todos os comandos que a requerem, execute: gdcloud config set core/zone ZONE. O indicador de zona só está disponível em ambientes com várias zonas. Este campo é opcional.
Ignore este passo se este ELB for para cargas de trabalho de pods. Se estiver a configurar um ELB para cargas de trabalho de VMs, defina uma verificação de funcionamento 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 o seguinte:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação do estado de funcionamento, como my-health-check.
- CHECK_INTERVAL: o período em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5. Este campo é opcional.
- HEALTHY_THRESHOLD: o tempo de espera antes de reclamar a falha. O valor predefinido é 5. Este campo é opcional.
- TIMEOUT: o período de tempo em segundos a aguardar antes de declarar a falha. O valor predefinido é 5. Este campo é opcional.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2. Este campo é opcional.
- PORT: a porta na qual a verificação de funcionamento é realizada. O valor predefinido é 80. Este campo é opcional.
Crie um recurso BackendService e adicione-lhe 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 o seguinte:
- BACKEND_SERVICE_NAME: o nome escolhido para este serviço de back-end.
- TARGET_PORTS: uma lista de portas de destino separada por vírgulas que este 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. Pode especificar várias portas de destino. Este campo tem de estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
- HEALTH_CHECK_NAME: o nome do recurso de verificação de estado. Este campo é opcional. Inclua este campo apenas se estiver a configurar um ELB para cargas de trabalho de VMs.

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 de sessão para ELBs para garantir que os pedidos do mesmo cliente são encaminhados de forma consistente para o mesmo back-end. Para ativar a afinidade de sessão para balanceadores de carga, crie uma política de serviço de back-end com o comando gdcloud compute load-balancer-policy create:
```
 gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL
```
Substitua o seguinte:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade de sessão. São suportados dois modos:
  - NONE: a afinidade de sessão está desativada. Os pedidos são encaminhados para qualquer back-end disponível. Este é o modo predefinido.
  - CLIENT_IP_DST_PORT_PROTO: os pedidos do mesmo conjunto de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são encaminhados para o mesmo back-end.
- RESOURCE_LABEL: o seletor de etiquetas que seleciona a que serviço de back-end o recurso BackendServicePolicy é aplicado no espaço de nomes do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e, pelo menos, uma destas políticas tiver a afinidade de sessão ativada, a afinidade de sessão para este recurso BackendService fica ativada.
Crie um recurso ForwardingRule externo que defina o VIP no qual 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 o seguinte:
- 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, é reservado automaticamente um IPv4/32CIDR do conjunto de IPs global. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede global. Para mais informações sobre os recursos Subnet, consulte o artigo Exemplos de recursos personalizados.
- PROTOCOL_PORT: o protocolo e a porta a expor na regra de encaminhamento. Este campo tem de estar no formato ip-protocol=TCP:80. A porta exposta tem de ser a mesma que a aplicação real está a expor no contentor.
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Para obter 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. Valide o tráfego com um curl pedido ao VIP:
1. Para obter o VIP atribuído, descreva a regra de encaminhamento:
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global
```
2. Valide o tráfego com um pedido curl para o VIP na porta especificada no campo PROTOCOL_PORT na regra de encaminhamento:
```
curl http://FORWARDING_RULE_VIP:PORT
```
  Substitua o seguinte:
  - 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 pods ou VMs através da API KRM. Este ELB segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto de back-end. Para criar um ELB zonal através da API KRM, siga estes passos:

Crie um recurso Backend para definir os pontos finais do ELB. Crie recursos Backend para cada zona em que as cargas de trabalho estão localizadas:
```
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 o seguinte:
- MANAGEMENT_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor da API de gestão global. Para mais informações, consulte o artigo Mude para o contexto global.
- PROJECT_NAME: o nome do seu projeto.
- BACKEND_NAME: o nome do recurso Backend.
- CLUSTER_NAME: este é um campo opcional. Este campo especifica o cluster ao qual o âmbito dos seletores definidos está limitado. Este campo não se aplica a cargas de trabalho de VMs. Se um recurso Backend não tiver o campo clusterName incluído, as etiquetas especificadas aplicam-se a todas as cargas de trabalho no projeto.
Ignore este passo se este ELB for para cargas de trabalho de pods. Se estiver a configurar um ELB para cargas de trabalho de VMs, defina uma verificação de funcionamento 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 o seguinte:
- HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação do estado de funcionamento, como my-health-check.
- PORT: a porta na qual a verificação de funcionamento é realizada. O valor predefinido é 80.
- TIMEOUT: o período de tempo em segundos a aguardar antes de declarar a falha. O valor predefinido é 5.
- CHECK_INTERVAL: o período em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5.
- HEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de ser aprovadas para que o ponto final seja considerado em bom estado. O valor predefinido é 2.
- UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2.
Uma vez que se trata de um ELB global, crie a verificação de funcionamento na API global.
Crie um objeto BackendService com o recurso Backend criado anteriormente. Se estiver a configurar um ELB para cargas de trabalho de VMs, 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 o seguinte:
- BACKEND_SERVICE_NAME: o nome escolhido para o seu recurso BackendService.
- HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente. Não inclua este campo se estiver a configurar um ELB para cargas de trabalho de pods.
- ZONE: a zona na qual o recurso Backend é criado. Pode especificar vários backends no campo backendRefs. Por exemplo:
```
- name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B
```
- O campo targetPorts é opcional. Este recurso apresenta as portas que este recurso BackendServicetraduz. Se estiver a usar este objeto, forneça valores para o seguinte:
  - PORT: a porta exposta pelo serviço.
  - PROTOCOL: o protocolo de camada 4 com o qual o tráfego tem de corresponder. Apenas são suportados os protocolos TCP e UDP.
  - TARGET_PORT: a porta para a qual o valor PORT é traduzido, como 8080. Não pode repetir o valor de TARGET_PORT num determinado objeto. Um exemplo para targetPorts pode ter o seguinte aspeto:
```
targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080
```
Opcional: use a afinidade de sessão para ELBs para garantir que os pedidos do mesmo cliente são encaminhados de forma consistente para o mesmo back-end. Para ativar a afinidade de sessão para balanceadores de carga, crie um recurso BackendServicePolicy. Este recurso define as definições de afinidade de 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 o seguinte:
- POLICY_NAME: o nome escolhido para a política de serviço de back-end.
- MODE: o modo de afinidade de sessão. São suportados dois modos:
  - NONE: a afinidade de sessão está desativada. Os pedidos são encaminhados para qualquer back-end disponível. Este é o modo predefinido.
  - CLIENT_IP_DST_PORT_PROTO: os pedidos do mesmo conjunto de quatro elementos (endereço IP de origem, endereço IP de destino, porta de destino e protocolo) são encaminhados para o mesmo back-end.
- RESOURCE_LABEL: o seletor de etiquetas que seleciona a que serviço de back-end o recurso BackendServicePolicy é aplicado no espaço de nomes do projeto. Se vários recursos BackendServicePolicy corresponderem ao mesmo serviço de back-end e, pelo menos, uma destas políticas tiver a afinidade de sessão ativada, a afinidade de sessão para este recurso BackendService fica ativada.
Crie um recurso ForwardingRule externo que defina o VIP no qual 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: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
Substitua o seguinte:
- FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para o seu recurso ForwardingRuleExternal.
- CIDR: este campo é opcional. Se não for especificado, é reservado automaticamente um IPv4/32CIDR do conjunto de IPs global. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede global. Para mais informações sobre os recursos Subnet, consulte o artigo Exemplos de recursos personalizados.
- PORT: use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados para os back-ends configurados com esta regra de encaminhamento. Tem de especificar, pelo menos, uma porta. Use o campo port para especificar um número de porta. A porta exposta tem de ser a mesma que a aplicação real está a expor no contentor.
- PROTOCOL: o protocolo a usar para a regra de encaminhamento, como TCP. Uma entrada na matriz ports tem de ter o seguinte aspeto:
```
ports:
- port: 80
  protocol: TCP
```
Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Valide o tráfego com um curl pedido ao VIP:
1. Para receber o VIP, use a app kubectl get:
```
kubectl get forwardingruleexternal -n PROJECT_NAME
```
  O resultado tem o seguinte aspeto:
```
NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
```
2. Valide o tráfego com um pedido 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.

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

Antes de começar

Configure o PNP para permitir tráfego para o ELB

Crie um balanceador de carga externo

Crie um ELB zonal

gdcloud

API

Serviço do Kubernetes

Crie um ELB global

gdcloud

API

Configure balanceadores de carga externos