Criar um balanceador de carga externo baseado em serviço de back-end


Nesta página, mostramos como implantar um Serviço LoadBalancer externo que cria um balanceador de carga de rede de passagem externo baseado em serviço de back-end. Antes de ler este documento, confira se você conhece os seguintes conceitos:

Balanceador de carga de rede de passagem externa baseado em serviço de back-end

Como administrador de cluster, é possível criar um serviço LoadBalancer externo para que clientes fora do cluster possam enviar pacotes para os pods do serviço. O diagrama a seguir ilustra dois balanceadores de carga de rede de passagem externa baseados em serviço de back-end criados para dois Serviços LoadBalancer externos (store-v1-lb-svc e store-v2-lb-svc). Os dois balanceadores de carga distribuem pacotes para os nós no cluster, e os nós encaminham pacotes para pods de disponibilização.

Serviços LoadBalancer externos via balanceadores de carga de rede de passagem externos baseados no serviço de back-end regional.

Este guia mostra como configurar um serviço LoadBalancer externo chamado store-v1-lb-svc com as seguintes etapas:

  1. Crie um cluster com o complemento HttpLoadBalancing ativado.
  2. Crie um serviço que inclua a anotação cloud.google.com/l4-rbs. Essa anotação instrui o GKE a criar um balanceador de carga de rede de passagem externa baseado em serviço de back-end que usa o serviço de back-end regional.
  3. Verificar se o balanceador de carga entrega pacotes aos pods do serviço store-v1-lb-svc. Verifique também se o GKE criou os componentes do balanceador de carga de rede de passagem externa baseado em serviço de back-end:

    • Regra de encaminhamento
    • Serviço de back-end regional
    • Grupo de instâncias
    • Verificação de integridade
    • Regras de firewall da VPC
  4. Exclua o serviço LoadBalancer externo store-v1-lb-svc.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.

Configurar o cluster

Crie um cluster

Use a CLI gcloud para criar um novo cluster compatível com a criação de balanceadores de carga de rede de passagem externa baseados em serviço de back-end:

gcloud container clusters create-auto CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Substitua:

  • CLUSTER_NAME: o nome do novo cluster;
  • RELEASE_CHANNEL: o nome do canal de lançamento do GKE para o cluster.
  • VERSION: a versão do GKE do cluster, que precisa ser 1.24.9 ou posterior.
  • COMPUTE_LOCATION: a região do Compute Engine do cluster.

O novo cluster tem o complemento HttpLoadBalancing ativado por padrão. Esse complemento é necessário para que o plano de controle possa criar e gerenciar balanceadores de carga de rede de passagem externa baseados em serviço de back-end.

Fazer upgrade de um cluster atual

Use a CLI gcloud para atualizar um cluster existente a fim de permitir a criação de balanceadores de carga de rede de passagem externa baseados em serviço de back-end.

  1. Faça upgrade do plano de controle para a versão 1.24.9 ou posterior do GKE:

    gcloud container clusters upgrade CLUSTER_NAME \
        --cluster-version=VERSION \
        --master \
        --location=COMPUTE_LOCATION
    

    Substitua:

Criar o serviço LoadBalancer externo

  1. Salve a seguinte implantação de amostra como store-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: store
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: store
      template:
        metadata:
          labels:
            app: store
        spec:
          containers:
          - image: gcr.io/google_containers/echoserver:1.10
            imagePullPolicy: Always
            name: echoserver
            ports:
              - name: http
                containerPort: 8080
            readinessProbe:
              httpGet:
                path: /healthz
                port: 8080
                scheme: HTTP
    
  2. Aplique o manifesto ao cluster:

    kubectl apply -f store-deployment.yaml
    
  3. Verifique se há dois pods de exibição para a implantação:

    kubectl get pods
    

    O resultado será assim:

    NAME                     READY   STATUS    RESTARTS   AGE
    store-cdb9bb4d6-s25vw      1/1     Running   0          10s
    store-cdb9bb4d6-vck6s      1/1     Running   0          10s
    
  4. Salve o seguinte manifesto de serviço como store-v1-lb-svc.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: store-v1-lb-svc
      annotations:
        cloud.google.com/l4-rbs: "enabled"
    spec:
      type: LoadBalancer
      externalTrafficPolicy: Cluster
      selector:
        app: store
      ports:
      - name: tcp-port
        protocol: TCP
        port: 8080
        targetPort: 8080
    

    Esse serviço LoadBalancer externo usa o externalTrafficPolicy padrão de Cluster. Para detalhes sobre como o externalTrafficPolicy define o agrupamento de nós, quais nós passam nas verificações de integridade do balanceador de carga e o processamento de pacotes, consulte Conceitos do serviço LoadBalancer.

    Se você estiver usando um cluster de pilha dupla IPv4/IPv6, adicione spec.ipFamilyPolicy e ipFamilies para definir como o GKE aloca endereços IP para o Serviço. Considere as seguintes condições ao usar as especificações ipFamilyPolicy e ipFamilies:

    • Quando você cria um balanceador de carga de rede de passagem externa baseado em serviço de back-end, o GKE adiciona automaticamente a anotação cloud.google.com/l4-rbs aos novos Serviços criados nos clusters de pilha dupla IPv4/IPv6. No entanto, se você adicionar a anotação cloud.google.com/l4-rbs: "enabled" aos manifestos de Serviço existentes, os Serviços LoadBalancer que já existem no cluster continuarão usando balanceadores de carga de rede de passagem externa baseados em pool de destino, que são apenas IPv4. Para mais informações, consulte Agrupamento de nós.
    • O GKE pode alocar serviços de LoadBalancer de pilha única (somente IPv4 ou IPv6) ou de pilha dupla. Um Serviço LoadBalancer de pilha dupla é implementado separadamente com duas regras de encaminhamento do balanceador de carga de rede de passagem externa: uma para lidar com o tráfego TCP por IPv4 e outra para lidar com o tráfego TCP por IPv6. Para mais informações, consulte Serviços.
  5. Aplique o manifesto ao cluster:

    kubectl apply -f store-v1-lb-svc.yaml
    
  6. Verifique se o serviço está em execução:

    kubectl get svc store-v1-lb-svc
    

    O resultado será assim:

    NAME               TYPE           CLUSTER-IP        EXTERNAL-IP     PORT(S)          AGE
    store-v1-lb-svc   LoadBalancer   10.44.196.160     35.193.28.231   8080:32466/TCP   11m
    

    O GKE atribuiu um EXTERNAL_IP para o balanceador de carga de rede de passagem externa.

  7. Teste a conexão com o balanceador de carga:

    curl EXTERNAL_IP:PORT
    

    Substitua:

    • EXTERNAL_IP: o endereço IP de alocação para o balanceador de carga de rede de passagem externa.
    • PORT: o número da porta alocada para o balanceador de carga de rede de passagem externa.

    O resultado será assim:

    Hostname: store-v1-lb-svc-cdb9bb4d6-hflxd
    
    Pod Information:
      -no pod information available-
    
    Server values:
      server_version=nginx: 1.13.3 - lua: 10008
    
    Request Information:
      client_address=10.128.0.50
      method=GET
      real path=/
      query=
      request_version=1.1
      request_scheme=http
      request_uri=EXTERNAL_IP
    
    Request Headers:
      accept=*/*
      host=EXTERNAL_IP
      user-agent=curl/7.81.0
    
    Request Body:
      -no body in request-
    
    

Verificar o serviço LoadBalancer externo e os componentes dele

  1. Verifique seu serviço LoadBalancer e o conjunto de anotações que descreve os recursos do Google Cloud:

    kubectl describe svc store-v1-lb-svc
    

    O resultado será assim:

    Name:                     store-v1-lb-svc
    Namespace:                default
    Labels:                   <none>
    Annotations:              cloud.google.com/l4-rbs: enabled
                              service.kubernetes.io/backend-service: k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
                              service.kubernetes.io/firewall-rule: k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
                              service.kubernetes.io/firewall-rule-for-hc: k8s2-c086604n-l4-shared-hc-fw
                              service.kubernetes.io/healthcheck: k8s2-c086604n-l4-shared-hc
                              service.kubernetes.io/tcp-forwarding-rule: a683373f85bfe433ba929a50ca8d72e2
    Selector:                 app=store
    Type:                     LoadBalancer
    IP Family Policy:         SingleStack
    IP Families:              IPv4
    IP:                       10.44.196.160
    IPs:                      10.44.196.160
    LoadBalancer Ingress:     35.193.28.231
    Port:                     tcp-port  8080/TCP
    TargetPort:               8080/TCP
    NodePort:                 tcp-port  32466/TCP
    Endpoints:                10.48.0.5:8080,10.48.2.8:8080
    Session Affinity:         None
    External Traffic Policy:  Cluster
    Events:
      Type    Reason                Age                   From                     Message
      ----    ------                ----                  ----                     -------
      Normal  ADD                   2m42s                 loadbalancer-controller  default/store-v1-lb-svc
      Normal  EnsuringLoadBalancer  102s (x2 over 2m42s)  service-controller       Ensuring load balancer
      Normal  Annotations           102s                  loadbalancer-controller  map[cloud.google.com/l4-rbs:enabled kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"v1","kind":"Service","metadata":{"annotations":
    {"cloud.google.com/l4-rbs":"enabled"},"name":"store-v1-lb-svc","namespace":"default"}
    ,"spec":{"externalTrafficPolicy":"Cluster","ports":
    [{"name":"tcp-port","port":8080,"protocol":"TCP","targetPort":8080}],
    "selector":{"app":"store"},"type":"LoadBalancer"}}
    ] -> map[cloud.google.com/l4-rbs:enabled
    kubectl.kubernetes.io/last-applied-configuration:{"apiVersion":"v1","kind":
    "Service","metadata":{"annotations":{"cloud.google.com/l4-rbs":"enabled"},
    "name":"store-v1-lb-svc","namespace":"default"},"spec":{"externalTrafficPolicy"
    :"Cluster","ports":[{"name":"tcp-port","port":8080,"protocol":"TCP","targetPort"
    :8080}],"selector":{"app":"store"},"type":"LoadBalancer"}}
    service.kubernetes.io/backend-service:k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
    service.kubernetes.io/firewall-rule:k8s2-c086604n-default-store-v1-lb-svc-aip4ty1x
    service.kubernetes.io/firewall-rule-for-hc:k8s2-c086604n-l4-shared-hc-fw
    service.kubernetes.io/healthcheck:k8s2-c086604n-l4-shared-hc
    service.kubernetes.io/tcp-forwarding-rule:a683373f85bfe433ba929a50ca8d72e2]
    Normal  SyncLoadBalancerSuccessful  16s (x3 over 102s)  loadbalancer-controller  Successfully ensured L4 External LoadBalancer resources
    

    Há vários campos que indicam que um balanceador de carga de rede de passagem externa baseado em serviço de back-end e seus respectivos recursos do Google Cloud foram criados com sucesso:

    • Campo Events. Este campo fica vazio quando o serviço LoadBalancer e os recursos dele foram criados com sucesso. Se ocorrer um erro, ele será listado aqui.
    • Lista de Annotations ativadas: o GKE adiciona a seguinte lista de anotações somente leitura ao manifesto do serviço. Cada anotação com um nome que começa com service.kubernetes.io/ é usada para indicar o nome de um recurso do Google Cloud criado como parte ou para oferecer suporte ao balanceador de carga.

    • A anotação service.kubernetes.io/backend-service indica o nome do serviço de back-end do balanceador de carga.

    • A anotação service.kubernetes.io/healthcheck indica o nome da verificação de integridade do balanceador de carga usada pelo serviço de back-end.

    • A anotação service.kubernetes.io/tcp-forwarding-rule ou service.kubernetes.io/udp-forwarding-rule indica o nome da regra de encaminhamento do balanceador de carga.

    • A anotação service.kubernetes.io/firewall-rule indica o nome da regra de firewall criada para permitir o tráfego para os nós do cluster. Os intervalos de origem desta regra de firewall são personalizáveis usando spec.loadBalancerSourceRanges[]. Veja mais detalhes sobre as regras de firewall para os serviços LoadBalancer em Regras de firewall e lista de permissões de endereços IP de origem.

    • A anotação service.kubernetes.io/firewall-rule-for-hc indica o nome da regra de firewall necessária para as verificações de integridade do balanceador de carga.

  2. Verifique se os recursos do balanceador de carga e as regras de firewall foram criados para o serviço LoadBalancer externo:

  • Para ver a regra de encaminhamento, execute o seguinte comando:

      gcloud compute forwarding-rules describe FWD_RULE_NAME \
        --region=REGION_NAME
    

    Substitua:

    • FWD_RULE_NAME: o nome da regra de encaminhamento fornecido pelas anotações somente leitura service.kubernetes.io/tcp-forwarding-rule ou service.kubernetes.io/udp-forwarding-rule. Para conferir essas anotações, execute kubectl describe svc SERVICE_NAME.
    • REGION_NAME: a região do Google Cloud que contém o cluster. Para clusters zonais, a região contém a zona usada pelo cluster.
  • Para ver o serviço de back-end, execute o seguinte comando:

    gcloud compute backend-services describe BACKEND_SERVICE_NAME \
      --region=REGION_NAME
    

    Substitua:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end fornecido pela anotação somente leitura service.kubernetes.io/backend-service. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.
    • REGION_NAME: a região do Google Cloud que contém o cluster. Para clusters zonais, a região contém a zona usada pelo cluster.
  • Para ver a verificação de integridade do balanceador de carga, execute o seguinte comando:

    gcloud compute health-checks describe HEALTH_CHECK_NAME \
      --region=REGION_NAME
    

    Substitua:

    • HEALTH_CHECK_NAME: o nome da verificação de saúde do balanceador de carga. O nome da verificação de saúde é fornecido pela anotação somente leitura service.kubernetes.io/healthcheck. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.
    • REGION_NAME: a região do Google Cloud que contém o cluster. Para clusters zonais, a região contém a zona usada pelo cluster.
  • Para ver as regras de firewall, execute os seguintes comandos:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME \
    gcloud compute firewall-rules describe HEALTH_CHECK_FIREWALL_RULE_NAME
    

    Substitua:

    • FIREWALL_RULE_NAME: o nome da regra de firewall que permite o tráfego para o balanceador de carga. O nome da regra de firewall é fornecido pela anotação somente leitura service.kubernetes.io/firewall-rule. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.
    • HEALTH_CHECK_FIREWALL_RULE_NAME: o nome da regra de firewall que permite verificações de saúde dos back-ends do balanceador de carga (os nós do cluster). O nome da regra de firewall é fornecido pela anotação somente leitura service.kubernetes.io/firewall-rule-for-hc. Para verificar essa anotação somente leitura, execute kubectl describe svc SERVICE_NAME.

Excluir o serviço LoadBalancer externo e os componentes dele

Exclua o serviço LoadBalancer externo store-v1-lb-svc.

kubectl delete service store-v1-lb-svc

O GKE exclui os seguintes recursos:

  • A regra de encaminhamento do balanceador de carga.
  • O serviço de back-end do balanceador de carga.
  • A verificação de integridade do balanceador de carga.
  • As regras de firewall da VPC necessárias para o balanceador de carga e o tráfego de verificação de integridade.
  • Os back-ends zonais de grupos de instâncias, apenas se o GKE não precisar usá-los como back-ends para outros balanceadores de carga criados pelo cluster.

A seguir