Implantar um aplicativo de contêiner altamente disponível

Console

1. No menu de navegação, selecione Kubernetes Engine > Clusters.

2. Clique em Criar cluster.

3. No campo Nome, especifique um nome para o cluster.

4. Selecione a versão do Kubernetes para o cluster.

5. Selecione a zona em que o cluster será criado.

6. Clique em Anexar projeto e selecione um projeto para anexar ao cluster. Clique em Salvar. É possível anexar ou desanexar projetos depois de criar o cluster na página Detalhes do projeto. É necessário ter um projeto anexado ao cluster antes de implantar cargas de trabalho de contêineres nele.

7. Clique em Próxima.

8. Configure as definições de rede do cluster. Não é possível mudar essas configurações de rede depois de criar o cluster. O protocolo de Internet padrão e único compatível com clusters do Kubernetes é o protocolo de Internet versão 4 (IPv4).

   1. Especifique o tamanho do pool de endereços IP do balanceador de carga, como 20.

   2. Selecione o CIDR (roteamento entre domínios sem classe) de serviço a ser usado. Seus serviços implantados, como balanceadores de carga, recebem endereços IP desse intervalo.

   3. Selecione o CIDR do pod a ser usado. O cluster aloca endereços IP desse intervalo para seus pods e VMs.

   4. Clique em Próxima.

9. Revise os detalhes do pool de nós padrão gerado automaticamente para o cluster. Clique em edit Editar para modificar o pool de nós padrão.

10. Para criar outros pools de nós, selecione Adicionar pool de nós. Ao editar o pool de nós padrão ou adicionar um novo, personalize-o com as seguintes opções:

    1. Atribua um nome ao pool de nós. Não é possível modificar o nome depois de criar o pool de nós.
    2. Especifique o número de nós de trabalho a serem criados no pool de nós.

    3. Selecione a classe de máquina mais adequada para os requisitos da sua carga de trabalho. Confira a lista das seguintes configurações:

       • Tipo de máquina
       • CPU
       • Memória

    4. Clique em Salvar.

    5. Clique em Criar para gerar o cluster.

11. Repita essas etapas para cada zona no seu universo do GDC. Verifique se um cluster do Kubernetes está em cada zona que você quer para sua estratégia de alta disponibilidade.

API

Para criar um cluster do Kubernetes usando a API diretamente, aplique um recurso personalizado a cada zona do GDC.

1. Crie um recurso personalizado Cluster e implante-o no servidor da API Management para sua zona:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF \
   apiVersion: cluster.gdc.goog/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: platform
   spec:
     clusterNetwork:
       podCIDRSize: POD_CIDR
       serviceCIDRSize: SERVICE_CIDR
     initialVersion:
       kubernetesVersion: KUBERNETES_VERSION
     loadBalancer:
       ingressServiceIPSize: LOAD_BALANCER_POOL_SIZE
     nodePools:
     - machineTypeName: MACHINE_TYPE
       name: NODE_POOL_NAME
       nodeCount: NUMBER_OF_WORKER_NODES
       taints: TAINTS
       labels: LABELS
       acceleratorOptions:
         gpuPartitionScheme: GPU_PARTITION_SCHEME
     releaseChannel:
       channel: UNSPECIFIED
   EOF
   

   Substitua:

   • MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API Management zonal. Para mais informações, consulte Mudar para o contexto zonal.
   • CLUSTER_NAME: o nome do cluster. O nome do cluster não pode terminar com -system. O sufixo -system é reservado para clusters criados pelo GDC.
   • POD_CIDR: o tamanho dos intervalos de rede de que os endereços IP virtuais (VIPs) do pod são alocados. Se não for definido, o valor padrão 21 será usado.
   • SERVICE_CIDR: o tamanho dos intervalos de rede de que os VIPs de serviço são alocados. Se não estiver definido, o valor padrão 23 será usado.
   • KUBERNETES_VERSION: a versão do Kubernetes do cluster, como 1.26.5-gke.2100. Para listar as versões disponíveis do Kubernetes para configuração, consulte Listar as versões disponíveis do Kubernetes para um cluster.
   • LOAD_BALANCER_POOL_SIZE: o tamanho dos pools de endereços IP não sobrepostos usados pelos serviços de balanceador de carga. Se não for definido, o valor padrão 20 será usado.
   • MACHINE_TYPE: o tipo de máquina para os nós de trabalho do pool de nós. Consulte os tipos de máquina disponíveis para saber o que pode ser configurado.
   • NODE_POOL_NAME: o nome do pool de nós.
   • NUMBER_OF_WORKER_NODES: o número de nós de trabalho a serem provisionados no pool de nós.
   • TAINTS: os taints a serem aplicados aos nós deste pool de nós. Esse campo é opcional.
   • LABELS: os rótulos a serem aplicados aos nós deste pool de nós. Ele contém uma lista de pares de chave-valor. Esse campo é opcional.
   • GPU_PARTITION_SCHEME: o esquema de particionamento de GPU, se você estiver executando cargas de trabalho de GPU, como mixed-2. A GPU não será particionada se esse campo não for definido. Para ver os perfis de GPU de várias instâncias (MIG) disponíveis, consulte Perfis de MIG compatíveis.

2. Repita a etapa anterior para cada zona em que você quer hospedar o aplicativo de contêiner para sua estratégia de alta disponibilidade.

gdcloud

Crie um ILB que tenha como destino cargas de trabalho de pods usando a CLI gdcloud.

Esse ILB tem como destino todas as cargas de trabalho no projeto que correspondem ao rótulo definido no objeto Backend. O recurso personalizado Backend precisa ser definido como uma zona.

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

1. Crie um recurso zonal Backend em cada zona em que seus pods estão em execução para definir o endpoint do ILB:

   gdcloud compute backends create BACKEND_NAME \
       --labels=LABELS \
       --project=PROJECT \
       --cluster=CLUSTER_NAME \
       --zone=ZONE
   

   Substitua:

   • BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
   • LABELS: o seletor que define quais endpoints entre pods usar para esse recurso de back-end, como app=web.
   • PROJECT: o nome do projeto.
   • CLUSTER_NAME: o cluster do Kubernetes a que o escopo dos seletores definidos é limitado. Se este campo não for especificado, todos os endpoints com o rótulo indicado 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 a exigem, execute gdcloud config set core/zone ZONE. A flag de zona só está disponível em ambientes multizonais. Este campo é opcional.

   Repita essa etapa para cada zona no seu universo do GDC.

2. Crie um recurso BackendService global:

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
       --project=PROJECT \
       --target-ports=TARGET_PORTS \
       --global
   

   Substitua:

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

3. Adicione o recurso BackendService ao recurso Backend criado anteriormente em cada zona:

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

   Substitua:

   • BACKEND_SERVICE_NAME: o nome do serviço de back-end global.
   • ZONE: a zona do back-end.
   • BACKEND_NAME: o nome do back-end zonal.
   • PROJECT: o nome do projeto.

   Conclua esta etapa para cada back-end zonal criado anteriormente.

4. Crie um recurso ForwardingRule interno que defina o endereço IP virtual (VIP) em que 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 \
       --global
   

   Substitua:

   • FORWARDING_RULE_INTERNAL_NAME: o nome da regra de encaminhamento.
   • CIDR: o CIDR a ser usado na regra de encaminhamento. Este campo é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool global de endereços IP. 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 recursos Subnet, consulte Gerenciar sub-redes.
   • 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.

5. Para validar o ILB 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_INTERNAL_NAME --global
      

   2. Verifique o tráfego com uma solicitação curl para o VIP na porta especificada no campo da 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 da regra de encaminhamento.

API

Crie um ILB que tenha como destino cargas de trabalho de contêiner usando a API KRM. Esse ILB tem como destino todas as cargas de trabalho no projeto que correspondem ao rótulo definido no objeto Backend. Para criar um ILB global usando a API KRM, siga estas etapas:

1. Crie um recurso Backend para definir os endpoints do ILB. Crie recursos Backend para cada zona em que as cargas de trabalho de contêineres estão localizadas:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

   Substitua:

   • MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API Management zonal. Para mais informações, consulte Mudar para um contexto zonal.
   • PROJECT: o nome do projeto.
   • BACKEND_NAME: o nome do recurso Backend.
   • CLUSTER_NAME: o cluster do Kubernetes a que o escopo dos seletores definidos é limitado. Se este campo não for especificado, todos os endpoints com o rótulo indicado serão selecionados. Este campo é opcional.
   • APP_NAME: o nome do seu aplicativo de contêiner.

   Você pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com conjuntos de rótulos diferentes para cada uma.

2. Crie um objeto BackendService usando o recurso Backend criado anteriormente. Inclua o recurso HealthCheck:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     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:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global.
   • PROJECT: o nome do projeto.
   • BACKEND_SERVICE_NAME: o nome escolhido para o recurso BackendService.
   • HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente.
   • BACKEND_NAME: o nome do recurso zonal Backend.

   • ZONE: a zona em que o recurso Backend está localizado. É possível especificar vários back-ends no campo backendRefs. Exemplo:

     - name: my-backend-1
       zone: us-east1-a
     - name: my-backend-2
       zone: us-east1-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 aceitos.

   • TARGET_PORT: a porta para a qual o valor é traduzido, como 8080. O valor não pode ser repetido em um determinado objeto.

     Um exemplo de targetPorts pode ser assim:

     targetPorts:
       - port: 80
         protocol: TCP
         targetPort: 8080
     

3. Crie um recurso ForwardingRule interno que defina o endereço IP virtual (VIP) em que o serviço está disponível.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleInternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Substitua:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global.
   • PROJECT: o nome do projeto.
   • FORWARDING_RULE_INTERNAL_NAME: o nome escolhido para o recurso ForwardingRuleInternal.
   • CIDR: o CIDR a ser usado na regra de encaminhamento. Este campo é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool global de endereços IP. 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 recursos Subnet, consulte Gerenciar sub-redes.
   • PORT: a porta a ser exposta na regra de encaminhamento. 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 a esta:

     ports:
     - port: 80
       protocol: TCP
     

4. Para validar o ILB 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. Recupere o VIP:

      kubectl get forwardingruleinternal -n PROJECT
      

      A saída será assim:

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

   2. Teste o tráfego com uma solicitação curl ao VIP na porta especificada no campo da 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 na regra de encaminhamento.

gdcloud

Use a CLI gdcloud para criar um ELB global que tenha como destino todas as cargas de trabalho no projeto que correspondem ao rótulo definido no objeto Backend. O recurso personalizado Backend precisa ter escopo em uma zona.

1. Para que os serviços do ELB funcionem, configure e aplique sua própria transferência de dados ProjectNetworkPolicy personalizada na política 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 à 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 GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.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:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor de API global. Se você ainda não gerou um arquivo kubeconfig para o servidor da API global, consulte Gerar manualmente o arquivo kubeconfig para mais detalhes.
   • PROJECT: o nome do projeto.
   • CIDR: o CIDR externo de onde o ELB precisa ser acessado. Essa 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 Criar uma regra de firewall de entrada global para tráfego entre organizações.
   • PORT: a porta de back-end nos pods atrás do balanceador de carga. Esse valor é encontrado no campo .spec.ports[].targetPortfield do manifesto do recurso Service. Este campo é opcional.

   Essa configuração fornece a todos os recursos dentro dos projetos acesso ao intervalo de CIDR especificado.

2. Crie um recurso Backend em cada zona para definir o endpoint do ELB:

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT \
     --cluster=CLUSTER_NAME \
     --zone=ZONE
   

   Substitua:

   • BACKEND_NAME: o nome do recurso de back-end, como my-backend.
   • LABELS: um seletor que define quais endpoints entre pods usar para esse recurso de back-end, como app=web.
   • PROJECT: o nome do projeto.
   • CLUSTER_NAME: o cluster do Kubernetes a que o escopo dos seletores definidos é limitado. Se este campo não for especificado, todos os endpoints com o rótulo indicado 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 a exigem, execute gdcloud config set core/zone ZONE. A flag de zona só está disponível em ambientes multizonais. Este campo é opcional.

   Você pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com conjuntos de rótulos diferentes para cada uma.

3. Crie um recurso BackendService global:

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
     --project=PROJECT \
     --target-ports=TARGET_PORTS \
     --health-check=HEALTH_CHECK_NAME \
     --global
   

   Substitua:

   • BACKEND_SERVICE_NAME: o nome escolhido para esse serviço de back-end.
   • PROJECT: o nome do projeto.
   • TARGET_PORTS: uma lista separada por vírgulas de portas de destino que esse serviço de back-end traduz. 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.

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

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

   Conclua esta etapa para cada back-end zonal criado anteriormente.

5. 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 \
     --global
   

   Substitua:

   • FORWARDING_RULE_EXTERNAL_NAME: o nome da regra de encaminhamento.
   • CIDR: o CIDR a ser usado na regra de encaminhamento. Este campo é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool global de endereços IP. 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 recursos Subnet, consulte Gerenciar sub-redes.
   • 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 está expondo dentro do contêiner.
   • PROJECT: o nome do projeto.

6. 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 da 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 tenha como destino cargas de trabalho de pod usando a API KRM. Esse ELB direciona 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:

1. Para que os serviços do ELB funcionem, configure e aplique sua própria transferência de dados ProjectNetworkPolicy personalizada na política 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 à 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 GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.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:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor de API global. Se você ainda não gerou um arquivo kubeconfig para o servidor da API global, consulte Gerar manualmente o arquivo kubeconfig para mais detalhes.
   • PROJECT: o nome do projeto.
   • CIDR: o CIDR externo de onde o ELB precisa ser acessado. Essa 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 Criar uma regra de firewall de entrada global para tráfego entre organizações.
   • PORT: a porta de back-end nos pods atrás do balanceador de carga. Esse valor é encontrado no campo .spec.ports[].targetPortfield do manifesto do recurso Service. Este campo é opcional.

2. Crie um recurso Backend para definir os endpoints 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: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

   Substitua:

   • MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API Management zonal. Se você ainda não gerou um arquivo kubeconfig para o servidor da API na zona de destino, consulte Gerar manualmente o arquivo kubeconfig para mais detalhes.
   • PROJECT: o nome do projeto.
   • BACKEND_NAME: o nome do recurso ;Backend
   • CLUSTER_NAME: o cluster do Kubernetes a que o escopo dos seletores definidos é limitado. Se este campo não for especificado, todos os endpoints com o rótulo indicado serão selecionados. Este campo é opcional.
   • APP_NAME: o nome do seu aplicativo de contêiner.

   Você pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com conjuntos de rótulos diferentes para cada uma.

3. Crie um objeto BackendService usando o recurso Backend criado anteriormente:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     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 você estiver configurando um ELB para cargas de trabalho de pod.
   • ZONE: a zona em que o recurso Backend está localizado. É possível especificar vários back-ends no campo backendRefs. Exemplo:

   - name: my-backend-1
     zone: us-east1-a
   - name: my-backend-2
     zone: us-east1-b
   

4. Crie um recurso ForwardingRule externo que defina o VIP em que o serviço está disponível.

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleExternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_EXTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

   Substitua:

   • FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para o recurso ForwardingRuleExternal.
   • CIDR: o CIDR a ser usado na regra de encaminhamento. Este campo é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool global de endereços IP. 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 recursos Subnet, consulte Gerenciar sub-redes.
   • PORT: a porta a ser exposta na regra de encaminhamento. Use o campo ports para especificar uma matriz de portas L4 em que os pacotes são encaminhados para os 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 assim:

   ports:
   - port: 80
     protocol: TCP
   

5. Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Teste o tráfego com uma solicitação curl para o VIP.

   1. Recupere o VIP do projeto:

      kubectl get forwardingruleexternal -n PROJECT
      

      A saída será assim:

      NAME           BACKENDSERVICE                  CIDR              READY
      elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
      

   2. Verifique o tráfego com uma solicitação curl para o VIP na porta especificada no campo PORT da regra de encaminhamento:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Substitua FORWARDING_RULE_VIP:PORT pelo VIP e pela porta da regra de encaminhamento, como 192.0.2.0:80.