Configurar balanceadores de carga internos

Os balanceadores de carga internos (ILB, na sigla em inglês) expõem serviços dentro da organização de um pool de IPs internos atribuído a ela. Um serviço ILB nunca é acessível de qualquer endpoint fora da organização.

Por padrão, é possível acessar serviços de ILB no mesmo projeto de qualquer cluster na organização. A política de rede do projeto padrão não permite acessar recursos do projeto de fora dele, e essa restrição também se aplica aos serviços de ILB. Se o administrador da plataforma (PA) configurar políticas de rede do projeto que permitam o acesso ao seu projeto de outros projetos, o serviço ILB também poderá ser acessado desses outros projetos na mesma organização.

Antes de começar

Para configurar ILBs, você precisa do seguinte:

  • Ser proprietário do projeto em que você está configurando o balanceador de carga. Para mais informações, consulte Criar um projeto.

  • Os papéis necessários de identidade e acesso:

    • Peça ao administrador do IAM da organização para conceder a você o papel de administrador do balanceador de carga (load-balancer-admin).
    • Para ILBs globais, peça ao administrador do IAM da organização para conceder a você o papel de administrador do balanceador de carga global (global-load-balancer-admin). Para mais informações, consulte Descrições de papéis predefinidos.

criar um balanceador de carga interno

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

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

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

Criar um ILB zonal

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

gdcloud

Crie um ILB que tenha como destino cargas de trabalho de pod ou VM 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.

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

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

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

    Substitua:

    • BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
    • LABELS: um seletor que define quais endpoints entre pods e VMs usar para esse recurso de back-end. Por exemplo, app=web.
    • PROJECT_NAME: o nome do projeto.
    • ZONE: a zona a ser usada para essa invocação. Para definir previamente a flag de zona para todos os comandos que a exigem, execute: gdcloud config set core/zone ZONE. A flag de zona está disponível apenas em ambientes multizona. Este campo é opcional.
    • CLUSTER_NAME: o cluster a que o escopo dos seletores definidos é limitado. Se esse campo não for especificado, todos os endpoints com o rótulo indicado serão selecionados. Este campo é opcional.

  2. Pule esta etapa se o ILB for para cargas de trabalho de pod. Se você estiver configurando um ILB para cargas de trabalho de VM, defina uma verificação de integridade 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 \
  --zone=ZONE

    Substitua:

    • HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
    • CHECK_INTERVAL: o tempo em segundos entre o início de uma sondagem e o início da próxima. O valor padrão é 5. Este campo é opcional.
    • HEALTHY_THRESHOLD: o tempo a ser aguardado antes de declarar falha. O valor padrão é 5. Este campo é opcional.
    • TIMEOUT: o tempo em segundos para aguardar antes de declarar falha. O valor padrão é 5. Este campo é opcional.
    • UNHEALTHY_THRESHOLD: o número de sondagens seguidas que precisam falhar para que o endpoint seja considerado não íntegro. O valor padrão é 2. Este campo é opcional.
    • PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80. Este campo é opcional.
    • ZONE: a zona em que você está criando o ILB.

  3. Crie um recurso BackendService e adicione a ele o recurso Backend criado anteriormente:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    Substitua:

    • BACKEND_SERVICE_NAME: o nome escolhido para esse serviço de back-end.
    • TARGET_PORTS: uma lista separada por vírgulas de portas de destino que esse serviço de back-end traduz, em que cada porta de destino especifica o protocolo, a porta na regra de encaminhamento e a porta na instância de back-end. É possível especificar várias portas de destino. Esse campo precisa estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
    • HEALTH_CHECK_NAME: o nome do recurso de verificação de integridade. Este campo é opcional. Inclua esse campo apenas se você estiver configurando um ILB para cargas de trabalho de VM.

  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 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 \
  --zone=ZONE \
  --project=PROJECT_NAME

    Substitua:

    • 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, um CIDR IPv4/32 será reservado automaticamente do pool de IP zonal. Especifique o nome de um recurso Subnet no mesmo namespace que esta regra de encaminhamento. Um recurso Subnet representa as informações de solicitação e alocação de uma sub-rede zonal. Para mais informações sobre recursos Subnet, consulte Exemplo de recursos personalizados.
    • PROTOCOL_PORT: o protocolo e a porta a serem expostos na regra de encaminhamento. Esse campo precisa estar no formato ip-protocol=TCP:80. A porta exposta precisa ser a mesma que o aplicativo real está expondo dentro do contêiner.

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

    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 ILB que tenha como destino cargas de trabalho de pod ou VM 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 zonal 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 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:

    • MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API Management zonal. Para mais informações, consulte Mudar para um contexto zonal.
    • PROJECT_NAME: o nome do projeto.
    • BACKEND_NAME: o nome do recurso ;Backend
    • CLUSTER_NAME: este é um campo opcional. Esse campo especifica o cluster a que o escopo dos seletores definidos está limitado. Esse campo não se aplica a cargas de trabalho de VM. Se um recurso Backend não tiver o campo clusterName incluído, os rótulos especificados serão aplicados a todas as cargas de trabalho no projeto.

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

  2. Pule esta etapa se o ILB for para cargas de trabalho de pod. Se você estiver configurando um ILB para cargas de trabalho de VM, defina uma verificação de integridade 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:

    • HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
    • PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80.
    • TIMEOUT: o tempo em segundos para aguardar antes de declarar falha. O valor padrão é 5.
    • CHECK_INTERVAL: o tempo em segundos entre o início de uma sondagem e o início da próxima. O valor padrão é 5.
    • HEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam ser aprovadas para que o endpoint seja considerado íntegro. O valor padrão é 2.
    • UNHEALTHY_THRESHOLD: o número de sondagens seguidas que precisam falhar para que o endpoint seja considerado não íntegro. O valor padrão é 2.

  3. Crie um objeto BackendService usando o recurso Backend criado anteriormente. Se você estiver configurando um ILB para cargas de trabalho de VM, inclua o recurso HealthCheck.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

    Substitua:

    • BACKEND_SERVICE_NAME: o nome escolhido para o recurso BackendService.
    • HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente. Não inclua esse campo se estiver configurando um ILB para cargas de trabalho de pod.

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: 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:

    • FORWARDING_RULE_INTERNAL_NAME: o nome escolhido para o recurso ForwardingRuleInternal.
    • CIDR: este campo é opcional. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool de IP zonal. Especifique o nome de um recurso Subnet no mesmo namespace que esta regra de encaminhamento. Um recurso Subnet representa as informações de solicitação e alocação de uma sub-rede zonal. Para mais informações sobre recursos Subnet, consulte Exemplo de recursos personalizados.
    • PORT: use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados aos back-ends configurados com essa regra de encaminhamento. É necessário especificar pelo menos uma porta. Use o campo port para especificar um número de porta. A porta exposta precisa ser a mesma que o aplicativo real está expondo dentro do contêiner.

    • PROTOCOL: o protocolo a ser usado para a regra de encaminhamento, como TCP. Uma entrada na matriz ports precisa ser assim:

      ports:
- port: 80
  protocol: TCP

  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 conseguir o VIP, use kubectl get:

      kubectl get forwardingruleinternal -n PROJECT_NAME

      A saída será assim:

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

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

      curl http://FORWARDING_RULE_VIP:PORT

      Substitua FORWARDING_RULE_VIP pelo VIP da regra de encaminhamento.

Serviço do Kubernetes

Para criar ILBs no GDC, crie um objeto Service do Kubernetes do tipo LoadBalancer em um cluster do Kubernetes. Esse ILB tem como destino apenas cargas de trabalho no cluster em que o objeto Service é criado.

Para criar um ILB com o objeto Service, siga estas etapas:

  1. Crie um arquivo YAML para a definição Service do tipo LoadBalancer. Você precisa projetar o serviço ILB como interno usando a anotação networking.gke.io/load-balancer-type: internal.

    O objeto Service a seguir é 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:

    • ILB_SERVICE_NAME: o nome do serviço ILB.
    • PROJECT_NAME: o namespace do projeto que contém as cargas de trabalho de back-end.

    O campo port configura a porta de front-end que você expõe no endereço VIP. O campo targetPort configura a porta de back-end para onde você quer encaminhar o tráfego nas cargas de trabalho de back-end. O balanceador de carga é compatível com a conversão de endereços de rede (NAT, na sigla em inglês). 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 quais cargas de trabalho serão usadas como back-end para esse serviço, com base na correspondência entre os rótulos especificados e os rótulos das cargas de trabalho. O Service só pode selecionar cargas de trabalho de back-end no mesmo projeto e cluster em que você define o Service.

    Para mais informações sobre a seleção de serviços, consulte https://kubernetes.io/docs/concepts/services-networking/service/.

  3. Salve o arquivo 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 estão no mesmo cluster da definição de Service.

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

    kubectl apply -f ILB_FILE

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

    Quando você cria um serviço ILB, ele recebe um endereço IP. Para conseguir o endereço IP do serviço ILB, confira o status dele:

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

    Substitua:

    • PROJECT_NAME: o namespace do projeto que contém as cargas de trabalho de back-end.
    • ILB_SERVICE_NAME: o nome do serviço ILB.

    Você vai receber uma saída semelhante a este 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 precisam mostrar o mesmo valor, que é o endereço IP do serviço ILB. Agora, esse endereço IP está acessível de outros clusters na organização, de acordo com as políticas de rede do projeto que ele tem.

    Se você não receber uma saída, verifique se criou o serviço ILB com sucesso.

    O GDC aceita 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. Em outros clusters, use o endereço IP para acessar o serviço ILB.

Criar um ILB global

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

gdcloud

Crie um ILB que tenha como destino cargas de trabalho de pod ou VM 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 ter escopo em uma zona.

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

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

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

    Substitua:

    • BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
    • LABELS: um seletor que define quais endpoints entre pods e VMs usar para esse recurso de back-end. Por exemplo, app=web.
    • PROJECT_NAME: o nome do projeto.
    • CLUSTER_NAME: o cluster a que o escopo dos seletores definidos é limitado. Se esse 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 definir 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.

  2. Pule esta etapa se o ILB for para cargas de trabalho de pod. Se você estiver configurando um ILB para cargas de trabalho de VM, defina uma verificação de integridade 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:

    • HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
    • CHECK_INTERVAL: o tempo em segundos entre o início de uma sondagem e o início da próxima. O valor padrão é 5. Este campo é opcional.
    • HEALTHY_THRESHOLD: o tempo a ser aguardado antes de declarar falha. O valor padrão é 5. Este campo é opcional.
    • TIMEOUT: o tempo em segundos para aguardar antes de declarar falha. O valor padrão é 5. Este campo é opcional.
    • UNHEALTHY_THRESHOLD: o número de sondagens seguidas que precisam falhar para que o endpoint seja considerado não íntegro. O valor padrão é 2. Este campo é opcional.
    • PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80. Este campo é opcional.

  3. Crie um recurso BackendService e adicione a ele o recurso Backend criado anteriormente:

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

    Substitua:

    • BACKEND_SERVICE_NAME: o nome escolhido para esse serviço de back-end.
    • TARGET_PORTS: uma lista separada por vírgulas de portas de destino que esse serviço de back-end traduz, em que cada porta de destino especifica o protocolo, a porta na regra de encaminhamento e a porta na instância de back-end. É possível especificar várias portas de destino. Esse campo precisa estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
    • HEALTH_CHECK_NAME: o nome do recurso de verificação de integridade. Este campo é opcional. Inclua esse campo apenas se você estiver configurando um ILB para cargas de trabalho de VM.

  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 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_NAME \
  --global

    Substitua:

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

  6. 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 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 ILB que tenha como destino cargas de trabalho de pod ou VM 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 zonal 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 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:

    • MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API Management global. Para mais informações, consulte Mudar para o contexto global.
    • PROJECT_NAME: o nome do projeto.
    • BACKEND_NAME: o nome do recurso ;Backend
    • CLUSTER_NAME: este é um campo opcional. Esse campo especifica o cluster a que o escopo dos seletores definidos está limitado. Esse campo não se aplica a cargas de trabalho de VM. Se um recurso Backend não tiver o campo clusterName incluído, os rótulos especificados serão aplicados a todas as cargas de trabalho no projeto.

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

  2. Pule esta etapa se o ILB for para cargas de trabalho de pod. Se você estiver configurando um ILB para cargas de trabalho de VM, defina uma verificação de integridade 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:

    • HEALTH_CHECK_NAME: o nome escolhido para o recurso de verificação de integridade, como my-health-check.
    • PORT: a porta em que a verificação de integridade é realizada. O valor padrão é 80.
    • TIMEOUT: o tempo em segundos para aguardar antes de declarar falha. O valor padrão é 5.
    • CHECK_INTERVAL: o tempo em segundos entre o início de uma sondagem e o início da próxima. O valor padrão é 5.
    • HEALTHY_THRESHOLD: o número de sondagens sequenciais que precisam ser aprovadas para que o endpoint seja considerado íntegro. O valor padrão é 2.
    • UNHEALTHY_THRESHOLD: o número de sondagens seguidas que precisam falhar para que o endpoint seja considerado não íntegro. O valor padrão é 2.

    Como este é um ILB global, crie a verificação de integridade na API global.

  3. Crie um objeto BackendService usando o recurso Backend criado anteriormente. Se você estiver configurando um ILB para cargas de trabalho de VM, inclua o recurso HealthCheck.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    Substitua:

    • BACKEND_SERVICE_NAME: o nome escolhido para o recurso BackendService.
    • HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente. Não inclua esse campo se você estiver configurando um ILB para cargas de trabalho de pod.

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

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • O campo targetPorts é opcional. Esse recurso lista as portas que o recurso BackendService traduz. Se você estiver usando esse objeto, forneça valores para o seguinte:

      • PORT: a porta exposta pelo serviço.
      • PROTOCOL: o protocolo da camada 4 que o tráfego precisa corresponder. Somente TCP e UDP são aceitos.

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

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

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: 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:

    • FORWARDING_RULE_INTERNAL_NAME: o nome escolhido para o recurso ForwardingRuleInternal.
    • CIDR: 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 Exemplo de recursos personalizados. Se não for especificado, um CIDR IPv4/32 será reservado automaticamente do pool de IP global. Este campo é opcional.
    • PORT: use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados aos back-ends configurados com essa regra de encaminhamento. É necessário especificar pelo menos uma porta. Use o campo port para especificar um número de porta. A porta exposta precisa ser a mesma que o aplicativo real está expondo dentro do contêiner.

    • PROTOCOL: o protocolo a ser usado para a regra de encaminhamento, como TCP. Uma entrada na matriz ports precisa ser assim:

      ports:
- port: 80
  protocol: TCP

  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 conseguir o VIP, use kubectl get:

      kubectl get forwardingruleinternal -n PROJECT_NAME

      A saída será assim:

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

    2. Teste 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 pelo VIP da regra de encaminhamento.