Configure balanceadores de carga internos

Os balanceadores de carga internos (ILB) expõem serviços na organização a partir de um conjunto de IPs internos atribuído à organização. Um serviço ILB nunca está acessível a partir de um ponto final fora da organização.

Por predefinição, pode aceder aos serviços ILB no mesmo projeto a partir de qualquer cluster na organização. A política de rede do projeto predefinida não lhe permite aceder a recursos do projeto a partir do exterior do projeto, e esta restrição também se aplica aos serviços ILB. Se o administrador da plataforma (PA) configurar políticas de rede do projeto que permitam o acesso ao seu projeto a partir de outros projetos, o serviço ILB também fica acessível a partir desses outros projetos na mesma organização.

Antes de começar

Para configurar ILBs, tem de:

• Ser proprietário do projeto para o qual está a configurar o equilibrador de carga. Para mais informações, consulte Crie um projeto.

• Ter as funções de identidade e acesso necessárias:

  • Peça ao administrador de IAM da organização para lhe conceder a função de administrador do Load Balancer (load-balancer-admin).
  • Para ILBs globais, peça ao administrador de IAM da organização para lhe conceder 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.

• Conheça o tipo de cluster que aloja as suas cargas de trabalho. Existem instruções distintas para configurar ILBs para clusters partilhados e padrão.

Crie um balanceador de carga interno para clusters partilhados

Pode criar ILBs globais ou zonais para clusters partilhados. O âmbito dos ILBs globais abrange um universo de GDCs. O âmbito dos blocos de anúncios indiretos zonais está limitado à zona especificada no momento da criação. Para mais informações, consulte o artigo Equilibradores de carga globais e zonais.

Crie ILBs com três métodos diferentes no GDC:

• Use a CLI gdcloud para criar ILBs globais ou zonais.
• Use a API Networking Kubernetes Resource Model (KRM) para criar ILBs globais ou zonais.
• Use o serviço Kubernetes diretamente no cluster Kubernetes. Este método só está disponível para ILBs 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 a partir do cluster Kubernetes.

Crie um ILB zonal

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

gdcloud

Crie um ILB que segmenta cargas de trabalho de VMs ou pods através da CLI gdcloud.

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

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

1. Crie um recurso Backend para definir o ponto final do ILB:

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT_NAME \
     --zone=ZONE \
     --cluster-name=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, todos os pontos finais com a etiqueta fornecida são selecionados. Este campo é opcional.

2. Ignore este passo se este ILB for para cargas de trabalho de pods. Se estiver a configurar um ILB para cargas de trabalho de VMs, defina o tipo de verificação de funcionamento para o ILB. Por exemplo, para criar uma verificação de funcionamento de TCP, defina-a da seguinte forma:

   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 número de sondagens sequenciais que têm de ser aprovadas para que o ponto final seja considerado em bom estado. O valor predefinido é 5. Este campo é opcional.
   • TIMEOUT: o período de tempo em segundos a aguardar antes de reclamar 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 ILB.

3. 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_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 ILB para cargas de trabalho de VMs.

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

5. Crie um recurso ForwardingRule interno que defina o VIP no qual o serviço está disponível:

   gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=INTERNAL \
     --zone=ZONE \
     --project=PROJECT_NAME
   

   Substitua o seguinte:

   • BACKEND_SERVICE_NAME: o nome do seu serviço de back-end.
   • FORWARDING_RULE_INTERNAL_NAME com 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 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.

6. Para validar o ILB 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_INTERNAL_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 ILB que segmenta cargas de trabalho de VMs ou pods através da API KRM. Este ILB segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend.

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

1. Crie um recurso Backend para definir os pontos finais do ILB. Crie recursos Backend para cada zona onde 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 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.

   Pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com diferentes conjuntos de etiquetas para cada zona.

2. Ignore este passo se este ILB for para cargas de trabalho de pods. Se estiver a configurar um ILB para cargas de trabalho de VMs, defina uma verificação de funcionamento para o ILB:

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

3. Crie um objeto BackendService com o recurso Backend criado anteriormente. Se estiver a configurar um ILB 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 ILB para cargas de trabalho de pods.

4. Crie um recurso ForwardingRule interno 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: ForwardingRuleInternal
   metadata:
     namespace: PROJECT_NAME
     Name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       Protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Substitua o seguinte:

   • FORWARDING_RULE_INTERNAL_NAME: o nome escolhido para o seu recurso ForwardingRuleInternal.
   • CIDR: este campo é opcional. Se não for especificado, é reservado automaticamente um IPv4/32CIDR 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.
   • 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
     

5. Para validar o ILB 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 forwardingruleinternal -n PROJECT_NAME
      

      O resultado tem o seguinte aspeto:

      NAME           BACKENDSERVICE                               CIDR              READY
      ilb-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 ILBs no GDC criando um objeto Service do Kubernetes do tipo LoadBalancer num cluster do Kubernetes. Este ILB segmenta apenas cargas de trabalho no cluster onde o objeto Service é criado.

Para criar um ILB com o objeto Service, siga estes passos:

1. Crie um ficheiro YAML para a definição Service do tipo LoadBalancer. Tem de criar o serviço ILB como interno através da anotação networking.gke.io/load-balancer-type: internal.

   Nota: o valor internal é sensível a maiúsculas e minúsculas e tem de estar em minúsculas.

   O objeto Service seguinte é um exemplo de um serviço ILB:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       networking.gke.io/load-balancer-type: internal
     name: ILB_SERVICE_NAME
     namespace: PROJECT_NAME
   spec:
     ports:
     - port: 1234
       protocol: TCP
       targetPort: 1234
     selector:
       k8s-app: my-app
     type: LoadBalancer
   

   Substitua o seguinte:

   • ILB_SERVICE_NAME: o nome do serviço ILB.
   • 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.

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

3. Guarde o ficheiro de definição Service no mesmo projeto que as cargas de trabalho de back-end. O serviço ILB só pode selecionar cargas de trabalho que estejam no mesmo cluster que a definição de Service.

4. Aplique o ficheiro de definição Service ao cluster:

   kubectl apply -f ILB_FILE
   

   Substitua ILB_FILE pelo nome do ficheiro de definição Service para o serviço ILB.

   Quando cria um serviço ILB, o serviço recebe um endereço IP. Pode obter o endereço IP do serviço ILB vendo o estado do serviço:

   kubectl -n PROJECT_NAME get svc ILB_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.
   • ILB_SERVICE_NAME: o nome do serviço ILB.

   Tem de obter um resultado semelhante ao seguinte exemplo:

   NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
   ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h
   

   Os campos CLUSTER-IP e EXTERNAL-IP têm de apresentar o mesmo valor, que é o endereço IP do serviço ILB. Este endereço IP está agora acessível a partir de outros clusters na organização, de acordo com as políticas de rede do projeto que o projeto tem.

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

   O GDC suporta nomes do Sistema de Nomes de Domínio (DNS) para serviços. No entanto, esses nomes só funcionam no mesmo cluster para serviços ILB. A partir de outros clusters, tem de usar o endereço IP para aceder ao serviço ILB.

   Importante: se os valores de CLUSTER-IP e EXTERNAL-IP não forem iguais, significa que configurou o serviço como um serviço de balanceamento de carga externo (ELB). Certifique-se de que a anotação networking.gke.io/load-balancer-type: internal está correta na definição Service. As chaves e os valores das anotações são sensíveis a maiúsculas e minúsculas.

Crie um ILB global

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

gdcloud

Crie um ILB que segmenta cargas de trabalho de VMs ou pods através da CLI gdcloud.

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

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

1. Crie um recurso Backend para definir o ponto final do ILB:

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT_NAME \
     --cluster-name=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, todos os pontos finais com a etiqueta fornecida são selecionados. 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.

2. Ignore este passo se este ILB for para cargas de trabalho de pods. Se estiver a configurar um ILB para cargas de trabalho de VMs, defina uma verificação de funcionamento para o ILB:

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

3. 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 ILB para cargas de trabalho de VMs.

4. Adicione o recurso BackendService ao recurso Backend criado anteriormente:

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

5. Crie um recurso ForwardingRule interno que defina o VIP no qual o serviço está disponível:

   gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=INTERNAL \
     --project=PROJECT_NAME \
     --global
   

   Substitua o seguinte:

   • FORWARDING_RULE_INTERNAL_NAME: o nome escolhido para a regra de encaminhamento.
   • CIDR: 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. Se não for especificado, é reservado automaticamente um IPv4/32CIDR do conjunto de IPs global. Este campo é opcional.
   • 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.

6. Para validar o ILB 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_INTERNAL_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 ILB que segmenta cargas de trabalho de VMs ou pods através da API KRM. Este ILB destina-se a todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend. Para criar um ILB zonal através da API KRM, siga estes passos:

1. Crie um recurso Backend para definir os pontos finais do ILB. Crie recursos Backend para cada zona onde as cargas de trabalho estão localizadas:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.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.

   Pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com diferentes conjuntos de etiquetas para cada zona.

2. Ignore este passo se este ILB for para cargas de trabalho de pods. Se estiver a configurar um ILB para cargas de trabalho de VMs, defina uma verificação de funcionamento para o ILB:

   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
   

   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 reclamar 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 ILB global, crie a verificação de funcionamento na API global.

3. Crie um objeto BackendService com o recurso Backend criado anteriormente. Se estiver a configurar um ILB 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 ILB para cargas de trabalho de pods.

   • ZONE: a zona na qual o recurso Backend é criado. Pode especificar vários back-ends 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
       

4. Crie um recurso ForwardingRule interno 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: ForwardingRuleInternal
   metadata:
     namespace: PROJECT_NAME
     Name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       Protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Substitua o seguinte:

   • FORWARDING_RULE_INTERNAL_NAME: o nome escolhido para o seu recurso ForwardingRuleInternal.
   • CIDR: 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. Se não for especificado, é reservado automaticamente um IPv4/32CIDR do conjunto de IPs global. Este campo é opcional.
   • 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
     

5. Para validar o ILB 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 forwardingruleinternal -n PROJECT_NAME
      

      O resultado tem o seguinte aspeto:

      NAME           BACKENDSERVICE                               CIDR              READY
      ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True
      

   2. Teste o tráfego com um pedido curl ao 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.

Crie um balanceador de carga interno para clusters padrão

Pode criar ILBs zonais para clusters padrão. Os ILBs globais não são suportados. O âmbito dos ILBs zonais está limitado à zona especificada no momento da criação. Para mais informações, consulte o artigo Balanceadores de carga globais e zonais.

Crie ILBs zonais para clusters padrão através do serviço Kubernetes diretamente no cluster Kubernetes. Só pode segmentar cargas de trabalho no cluster onde o objeto Service é criado quando usa o serviço Kubernetes diretamente a partir do cluster Kubernetes.

Crie um ILB zonal para clusters padrão

Pode criar ILBs no GDC criando um objeto Service do Kubernetes do tipo LoadBalancer num cluster do Kubernetes. Este ILB segmenta apenas cargas de trabalho no cluster onde o objeto Service é criado.

Para criar um ILB com o objeto Service, siga estes passos:

1. Crie um ficheiro YAML para a definição Service do tipo LoadBalancer. Tem de criar o serviço ILB como interno através da anotação networking.gke.io/load-balancer-type: internal.

   Nota: o valor internal é sensível a maiúsculas e minúsculas e tem de ser em minúsculas.

   O objeto Service seguinte é um exemplo de um serviço ILB:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       networking.gke.io/load-balancer-type: internal
     name: ILB_SERVICE_NAME
     namespace: ILB_SERVICE_NAMESPACE
   spec:
     ports:
     - port: 1234
       protocol: TCP
       targetPort: 1234
     selector:
       k8s-app: my-app
     type: LoadBalancer
   

   Substitua o seguinte:

   • ILB_SERVICE_NAME: o nome do serviço ILB.
   • ILB_SERVICE_NAMESPACE: o espaço de nomes 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.

2. No campo selector da definição Service, especifique os agrupamentos que vão servir como 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/.

3. Guarde a especificação Service num ficheiro YAML. Substitua o nome do ficheiro por ILB_FILE no seguinte comando. O serviço ILB só pode selecionar cargas de trabalho que estejam no mesmo cluster que a definição Service.

4. Aplique o ficheiro de definição Service ao cluster:

   export KUBECONFIG=KUBECONFIG_PATH
   kubectl apply -f ILB_FILE
   

   Substitua o seguinte:

   • ILB_FILE:o nome do ficheiro de definição do serviço ILB.Service
   • KUBECONFIG_PATH: o caminho para o ficheiro kubeconfig do cluster padrão.

   Quando cria um serviço ILB, o serviço recebe um endereço IP. Pode obter o endereço IP do serviço ILB vendo o estado do serviço:

   kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME
   

   Substitua o seguinte:

   • ILB_SERVICE_NAMESPACE: o espaço de nomes que contém as cargas de trabalho de back-end.
   • ILB_SERVICE_NAME: o nome do serviço ILB.
   • KUBECONFIG_PATH: o caminho para o ficheiro kubeconfig do cluster padrão.

   Vai obter um resultado semelhante ao seguinte exemplo:

   NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
   ilb-service             LoadBalancer   10.0.0.1      198.51.0.1        1234:31930/TCP   22h
   

   Este endereço IP está agora acessível a partir de outros clusters na organização, de acordo com as políticas de rede do projeto que o projeto tem.

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

Para associar uma VM ao balanceador de carga:

1. Certifique-se de que a VM tem uma etiqueta correspondente ao seletor de etiquetas usado na configuração do equilibrador de carga.

   Por exemplo, se a sua VM não tiver uma etiqueta adequada, pode adicionar a etiqueta especificada do objeto de back-end da zona correspondente à VM:

   kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL
   

   Substitua o seguinte:

   • LABEL: uma etiqueta que corresponde ao LabelSelector na configuração do balanceador de carga, como app=server.
   • VM_NAME: o nome da máquina virtual que está a ser associada.
   • PROJECT_NAME: o nome do seu projeto.

2. Certifique-se de que o servidor está a ouvir na mesma porta especificada no objeto HealthCheck.