Balanceamento de carga nativo do contêiner com NEGs independentes

Nesta página, mostramos como criar um serviço do Kubernetes respaldado por um grupo de endpoints de rede (NEG, na sigla em inglês) por zona.

Consulte Balanceamento de carga nativo de contêiner para informações sobre os benefícios, os requisitos e as limitações desse recurso.

Visão geral

Um grupo de endpoints de rede (NEG, na sigla em inglês) representa um grupo de back-ends exibidos por um balanceador de carga. Os NEGs são listas de endereços IP gerenciados por um controlador de NEG e são usados pelos balanceadores de carga do Google Cloud. Os endereços IP em um NEG podem ser primários ou secundários em uma VM, o que significa que eles podem ser IPs de pod. Isso permite o balanceamento de carga nativo de contêiner que envia tráfego diretamente para pods de um balanceador de carga do Google Cloud.

O diagrama a seguir descreve como os objetos da API Kubernetes correspondem aos objetos do Compute Engine.

Os serviços do Kubernetes correspondem aos grupos de endpoints da rede do Compute Engine, enquanto os pods do Kubernetes correspondem aos endpoints da rede do Compute Engine. Isso é gerenciado pelo componente do controlador de NEG do mestre do GKE.

Entrada com NEGs

Quando os NEGs são usados com a Entrada do GKE, o controlador da Entrada facilita a criação de todos os aspectos do balanceador de carga L7. Isso inclui a criação do endereço IP virtual, regras de encaminhamento, verificações de integridade, regras de firewall e muito mais.

A Entrada é a maneira recomendada de usar o balanceamento de carga nativo de contêiner, porque tem muitos recursos que simplificam o gerenciamento de NEGs. Os NEGs independentes são uma opção quando os NEGs gerenciados pela Entrada não exibem seu caso de uso.

NEGs independentes

Quando os NEGs são implantados com balanceadores de carga provisionados por algo diferente da Entrada, eles são considerados independentes. Os NEGs independentes são implantados e gerenciados por meio do controlador de NEG, mas as regras de encaminhamento, as verificações de integridade e outros objetos de balanceamento de carga são implantados manualmente.

Os NEGs independentes não entram em conflito com o balanceamento de carga nativo do contêiner de Entrada.

A ilustração a seguir mostra as diferenças na maneira como os objetos de balanceamento de carga são implantados em cada cenário:

Nos NEGs independentes e gerenciados pela Entrada, o controlador de NEG no mestre do GKE gerencia os objetos de endpoints da rede e do NEG. Nos NEGs independentes, todos os outros componentes são gerenciados pelo usuário, conforme descrito nos parágrafos anteriores.

Casos de uso de NEGs independentes

Os NEGs independentes têm vários usos essenciais. Eles são muito flexíveis. Isso é diferente em relação à Entrada (usada com ou sem NEGs) que define um conjunto específico de objetos de balanceamento de carga que foram escolhidos a fim de facilitar o uso.

Os casos de uso de NEGs independentes incluem:

Serviços heterogêneos de contêineres e VMs

Os NEGs podem conter endereços IP da VM e do contêiner. Isso significa que um endereço IP virtual pode apontar para um back-end que consiste em cargas de trabalho do Kubernetes e que não são do Kubernetes. Isso também pode ser usado para migrar cargas de trabalho atuais para um cluster do GKE.

Os NEGs independentes podem apontar para IPs de VM, o que possibilita a configuração manual dos balanceadores de carga com o objetivo de apontar para back-ends compostos por VMs e contêineres no mesmo VIP do serviço.

Controladores de Entrada personalizados

É possível usar um controlador personalizado de Entrada (ou nenhum controlador de Entrada) para configurar balanceadores de carga que visam NEGs independentes.

Usar o Traffic Director com GKE

Traffic Director com GKE. O Traffic Director usa NEGs independentes para fornecer balanceamento de carga nativo de contêiner para a malha de serviço gerenciada.

Usar TCPProxy LB com GKE

É possível usar NEGs independentes para balancear a carga diretamente para contêineres com o balanceador de carga TCPProxy que não é compatível nativamente com Kubernetes/GKE.

Prontidão do pod

Os portões de prontidão são um recurso de extensibilidade do Kubernetes que permite a injeção de feedback ou sinais extras no PodStatus para permitir que o pod migre para o estado de prontidão. O controlador de NEG gerencia um portão de prontidão personalizado para garantir que o caminho de rede completo, desde o balanceador de carga do Compute Engine até o pod, seja funcional. Os portões de prontidão do pod no GKE são explicados no balanceamento de carga nativo de contêiner.

A Entrada com NEGs implanta e gerencia verificações de integridade do Compute Engine em nome do balanceador de carga. No entanto, os NEGs independentes não fazem suposições sobre as verificações de integridade do Compute Engine porque espera-se que eles sejam implantados e gerenciados separadamente. As verificações de integridade do Compute Engine sempre precisam ser configuradas com o balanceador de carga para impedir que o tráfego seja enviado para os back-ends que não estão prontos para recebê-lo. Se não houver status de verificação de integridade associado ao NEG (normalmente porque nenhuma verificação de integridade está configurada), o controlador de NEG marcará o valor do portão de prontidão do pod como "verdadeiro" quando o endpoint correspondente estiver programado no NEG.

Requisitos

Os NEGs independentes estão disponíveis no GKE 1.10 e versões mais recentes. O feedback de prontidão do pod está ativado para os NEGs independentes na versão 1.16.4 e mais recentes.

O cluster precisa ser nativo de VPC. Para saber mais, consulte Como criar clusters nativos de VPC usando IPs de alias.

Seu cluster precisa ter o balanceamento de carga HTTP ativado. Os clusters do GKE têm o balanceamento de carga HTTP ativado por padrão. Não o desative.

Antes de começar

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

Defina configurações gcloud padrão usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão:
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Como usar NEGs independentes

As instruções abaixo mostram como usar NEGs independentes com um balanceador de carga HTTP externo no GKE.

Isso envolve a criação de vários objetos:

  • Uma implantação que cria e gerencia pods.
  • Um serviço que cria um NEG.
  • Um balanceador de carga criado com a API Compute Engine. Isso é diferente do uso de NEGs com a Entrada. Nesse caso, a Entrada cria e configura um balanceador de carga para você. Nos NEGs independentes, você é responsável por associar o NEG e o serviço de back-end para conectar os pods ao balanceador de carga. O balanceador de carga consiste em vários componentes, mostrados no diagrama abaixo:

Os componentes de um balanceador de carga são: regra de encaminhamento, proxy HTTP de destino, mapa de URL, verificação de integridade e serviço de back-end. Isso direciona o tráfego para um NEG que contém endereços IP do pod.

Criar um cluster nativo de VPC

Para usar o balanceamento de carga nativo de contêiner, é preciso criar um cluster com IPs de alias ativados. Veja os requisitos desse cluster:

  • É necessário executar o Google Kubernetes Engine versão 1.16.4 ou mais recente.
  • Ele precisa ser um cluster nativo de VPC.
  • É necessário ter o complemento de balanceamento de carga HTTP ativado. Os clusters do GKE têm o balanceamento de carga HTTP ativado por padrão. Não o desative.

Esse comando cria um cluster, neg-demo-cluster, na zona us-central1-a, com uma sub-rede provisionada automaticamente:

gcloud container clusters create neg-demo-cluster \
        --enable-ip-alias \
        --create-subnetwork="" \
        --network=default \
        --zone=us-central1-a
    

Criar uma implantação

Os manifestos abaixo especificam uma implantação, neg-demo-app, que executa três instâncias de um servidor HTTP em contêiner. O servidor HTTP responde a solicitações com o nome do host do servidor de aplicativos, o nome do pod em que o servidor está sendo executado.

Recomendamos o uso de cargas de trabalho que apliquem o feedback de prontidão do pod, se ele estiver disponível na sua versão do GKE. Consulte a seção Prontidão do pod acima para mais informações e a seção Requisitos para os requisitos de versão do GKE para usar o feedback de prontidão do pod. Avalie a possibilidade de fazer upgrade do cluster para usar o feedback de prontidão do pod.

Como usar o feedback de prontidão do pod

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        run: neg-demo-app # Label for the Deployment
      name: neg-demo-app # Name of Deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          run: neg-demo-app
      template: # Pod template
        metadata:
          labels:
            run: neg-demo-app # Labels Pods from this Deployment
        spec: # Pod specification; each Pod created by this Deployment has this specification
          containers:
          - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
            name: hostname
      

Como usar o atraso fixado no código

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        run: neg-demo-app # Label for the Deployment
      name: neg-demo-app # Name of Deployment
    spec:
      minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
      replicas: 3
      selector:
        matchLabels:
          run: neg-demo-app
      template: # Pod template
        metadata:
          labels:
            run: neg-demo-app # Labels Pods from this Deployment
        spec: # Pod specification; each Pod created by this Deployment has this specification
          containers:
          - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
            name: hostname
          # Note: The following line is necessary only on clusters running GKE v1.11 and lower.
          # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts
          terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
      

Salve este manifesto como neg-demo-app.yaml e, em seguida, crie a implantação executando o seguinte comando:

kubectl apply -f neg-demo-app.yaml
    

Criar um serviço

O manifesto abaixo especifica um serviço, neg-demo-svc.

  • Qualquer pod com o rótulo run: neg-demo-app é membro desse serviço.
  • O serviço tem um campo ServicePort com a porta 80.
  • A anotação cloud.google.com/neg especifica que a porta 80 será associada a um NEG.
  • Cada pod membro precisa ter um contêiner que faça detecções na porta TCP 9376.
apiVersion: v1
    kind: Service
    metadata:
      name: neg-demo-svc
      annotations:
        cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    spec:
      type: ClusterIP
      selector:
        run: neg-demo-app # Selects Pods labelled run: neg-demo-app
      ports:
      - port: 80
        protocol: TCP
        targetPort: 9376
    

Salve este manifesto como neg-demo-svc.yaml e, em seguida, crie o serviço executando o seguinte comando:

kubectl apply -f neg-demo-svc.yaml
    

Tipos de serviço

Embora esse exemplo use um serviço ClusterIP, todos os cinco tipos de serviço são compatíveis com NEG. Recomendamos o tipo padrão, ClusterIP, para a maioria dos casos de uso, porque ele não expõe o serviço fora do cluster além do balanceador de carga criado para apontar para o NEG.

Como correlacionar portas a vários NEGs

Um serviço pode fazer a detecção em mais de uma porta. Por definição, os NEGs têm apenas um único endereço IP e porta. Isso significa que, se você especificar um serviço com várias portas, ele criará um NEG para cada porta.

O formato da anotação cloud.google.com.neg é:

cloud.google.com/neg: '{
       "exposed_ports":{
          "service-port-1":{},
          "service-port-2":{},
          "service-port-3":{},
          ...
       }'

em que service-port-n são números de porta distintos que se referem às portas de serviço atuais do serviço. Para cada porta de serviço listada, o controlador de NEG cria um NEG em cada zona ocupada pelo cluster.

Recuperar status de NEG

Use este comando para recuperar os status dos serviços do cluster:

kubectl get service neg-demo-svc -o yaml

Esse comando gera o status dos NEGs neste formato:

cloud.google.com/neg-status: '{
       "network-endpoint-groups":{
          "service-port-1": "neg-name-1",
          "service-port-1": "neg-name-2",
          ...
       },
       "zones":["zone-1", "zone-2", ...]
    }

em que cada elemento no mapeamento network-endpoint-groups é uma porta de serviço (service-port-1) e o nome dos NEGs gerenciados correspondentes (como neg-name-1). A lista zones contém todas as zonas (como zona-1) que têm um NEG.

O exemplo abaixo é a saída completa do comando:

apiVersion: v1
    kind: Service
    metadata:
      annotations:
        cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
        cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["us-central1-a", "us-central1-b"]}'
      labels:
        run: neg-demo-app
      name: neg-demo-app
      namespace: default
      selfLink: /api/v1/namespaces/default/services/neg-demo-app
      ...
    spec:
      clusterIP: 10.0.14.252
      ports:
      - port: 80
        protocol: TCP
        targetPort: 9376
      selector:
        run: neg-demo-app
      sessionAffinity: None
    status:
      loadBalancer: {}

Nesse exemplo, a anotação mostra que a porta de serviço 80 está exposta aos NEGs denominados k8s1-cca197ad-default-neg-demo-app-80-4db81e02 localizados nas zonas us-central1-a e us-central1-b.

Validar criação de NEG

Um NEG é criado poucos minutos após a criação do serviço. Se houver pods que correspondam ao rótulo especificado no manifesto do serviço, então, na criação, o NEG conterá os IPs dos pods.

Verifique se o NEG existe listando os NEGs no seu projeto do Google Cloud e verificando se um NEG corresponde ao serviço que você criou. O nome do NEG tem este formato: k8s1-cluster-uid-namespace-service-port-random-hash

Use este comando para listar NEGs:

gcloud compute network-endpoint-groups list
    

A saída é semelhante a:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
    k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  GCE_VM_IP_PORT  3
    

Essa saída mostra que SIZE do NEG é 3, o que significa que ele tem três endpoints que correspondem aos três pods na implantação.

Identifique os endpoints individuais com este comando:

gcloud compute network-endpoint-groups list-network-endpoints \
        k8s1-70aa83a6-default-my-service-80-c9710a6f

A saída mostra três endpoints. Cada um tem um endereço IP e porta do pod:

INSTANCE                                           IP_ADDRESS  PORT
    gke-standard-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
    gke-standard-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
    gke-standard-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376
    

Anexar balanceadores de carga a NEGs independentes

Os balanceadores de carga do Google Cloud listados na Visão geral dos grupos de endpoints de rede por zona são compatíveis como front-ends para NEGs independentes. As etapas a seguir mostram como criar um balanceador de carga HTTP externo usando a API Compute Engine.

  1. Primeiro, crie regras de firewall. Os balanceadores de carga precisam acessar os endpoints do cluster para realizar verificações de integridade. Este comando cria regras de firewall que permitem esse acesso:

    gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
          --network=network-name \
          --action=allow \
          --direction=ingress \
          --target-tags=gke-node-network-tags \
          --source-ranges=130.211.0.0/22,35.191.0.0/16 \
          --rules=tcp:9376

    em que gke-node-network-tags são tags de rede nos nós do GKE e network-name é a rede em que o cluster é executado.

    Se você não criou tags de rede personalizadas para seus nós, o GKE gerou tags para você. É possível procurar essas tags geradas automaticamente verificando os nós com:

    gcloud compute instances describe node-name
        
  2. Crie um endereço IP virtual global para o balanceador de carga:

    gcloud compute addresses create hostname-server-vip \
          --ip-version=IPV4 \
          --global
  3. Crie uma verificação de integridade. É usado pelo balanceador de carga para detectar a atividade de endpoints individuais no NEG.

    gcloud compute health-checks create http http-basic-check \
          --use-serving-port
  4. Crie um serviço de back-end que especifique que esse é um balanceador de carga HTTP(S) externo global:

    gcloud compute backend-services create my-bes \
          --protocol HTTP \
          --health-checks http-basic-check \
          --global
  5. Crie um mapa de URLs e um proxy de destino para o balanceador de carga. Esse exemplo é muito simples porque o aplicativo serve_hostname usado neste guia tem um único endpoint e não apresenta URLs.

    gcloud compute url-maps create web-map \
          --default-service my-bes
    gcloud compute target-http-proxies create http-lb-proxy \
          --url-map web-map
  6. Crie uma regra de encaminhamento. É isso que cria o balanceador de carga.

    gcloud compute forwarding-rules create http-forwarding-rule \
          --address=hostname-server-vip \
          --global \
          --target-http-proxy=http-lb-proxy \
          --ports=80

    hostname-server-vip é o endereço IP que será usado para o balanceador de carga. É possível reservar um novo endereço IP externo estático para essa finalidade. Também é possível omitir a opção --address, e um endereço IP temporário será atribuído automaticamente.

Conferência

Estes são os recursos que você criou até agora:

  • Um endereço IP virtual externo
  • As regras de encaminhamento
  • As regras de firewall
  • O proxy HTTP de destino
  • O mapa de URL para a verificação de integridade do Compute Engine
  • O serviço de back-end
  • A verificação de integridade do Compute Engine

A relação entre esses recursos é mostrada no diagrama abaixo:

Esses recursos juntos são um balanceador de carga. Na próxima etapa, você adicionará back-ends ao balanceador de carga. Um dos benefícios dos NEGs independentes demonstrados aqui é que os ciclos de vida do balanceador de carga e do back-end podem ser completamente independentes. O balanceador de carga pode continuar em execução após a exclusão do aplicativo, dos seus serviços ou do cluster do GKE. É possível adicionar e remover novos ou vários NEGs do balanceador de carga sem alterar nenhum dos objetos do balanceador de carga à frente.

Adicionar back-ends ao balanceador de carga

Use gcloud compute backend-services add-backend para conectar o NEG ao balanceador de carga adicionando-o como um back-end do serviço de back-end my-sit:

gcloud compute backend-services add-backend my-bes --global \
       --network-endpoint-group network-endpoint-group-name \
       --network-endpoint-group-zone network-endpoint-group-zone \
       --balancing-mode RATE --max-rate-per-endpoint 5

em que:

  • network-endpoint-group-name é o nome do grupo de endpoints da rede. Veja as instruções abaixo para encontrar esse valor;
  • network-endpoint-group-zone é a zona em que está o grupo de endpoints da rede. Veja as instruções abaixo para encontrar esse valor.

Use este comando para ver o nome e o local do NEG:

gcloud compute network-endpoint-groups list
    

A saída é semelhante a:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
    k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  GCE_VM_IP_PORT  3
    

Neste exemplo de saída, o nome do NEG é k8s1-70aa83a6-default-my-service-80-c9710a6f e ele está na zona `us-central1-a

Vários NEGs podem ser adicionados ao mesmo serviço de back-end. Serviços de back-end globais, como my-sit, podem ter back-ends de NEG em diferentes regiões, enquanto os serviços de back-end regionais precisam ter back-ends em uma única região.

Validar se o balanceador de carga funciona

Há duas maneiras de validar se o balanceador de carga que você configurou está funcionando: a primeira é conferir se a verificação de integridade está configurada corretamente e gerar relatórios de integridade. A segunda é acessar o aplicativo e verificar a resposta dele.

Conferir verificações de integridade

Verifique se o serviço de back-end está associado à verificação de integridade e aos grupos de endpoints da rede e se os endpoints individuais estão íntegros.

Use este comando para verificar se o serviço de back-end está associado à verificação de integridade e ao grupo de endpoints da rede:

gcloud compute backend-services describe my-bes --global

A saída será semelhante a:

backends:
    - balancingMode: RATE
      capacityScaler: 1.0
      group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
    ...
    healthChecks:
    - ... /healthChecks/http-basic-check
    ...
    name: my-bes
    ...
    

Em seguida, verifique a integridade dos endpoints individuais:

gcloud compute backend-services get-health my-bes --global

A seção status: da saída será semelhante a:

status:
      healthStatus:
      - healthState: HEALTHY
        instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
        ipAddress: 10.12.1.43
        port: 50000
      - healthState: HEALTHY
        instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
        ipAddress: 10.12.1.44
        port: 50000
      - healthState: HEALTHY
        instance: ... gke-standard-cluster-3-default-pool-4cc71a15-w9nk
        ipAddress: 10.12.2.26
        port: 50000
    

Acessar o aplicativo

Acesse o aplicativo por meio do endereço IP do balanceador de carga para confirmar que tudo está funcionando.

Primeiro, veja o endereço IP virtual do balanceador de carga:

gcloud compute addresses describe hostname-server-vip --global | grep "address:"
    

A saída incluirá um endereço IP. Em seguida, envie uma solicitação para esse endereço IP (neste exemplo, 34.98.102.37):

curl 34.98.102.37
    

A resposta do aplicativo serve_hostname precisa ser neg-demo-app.

Como implementar serviços heterogêneos (VMs e contêineres)

Os balanceadores de carga podem ser front-ends para cargas de trabalho mistas do Kubernetes e que não são do Kubernetes. Isso pode ser parte de uma migração de VMs para contêineres ou uma arquitetura permanente que se beneficia de um balanceador de carga compartilhado. Para isso, crie balanceadores de carga que visam diferentes tipos de back-ends, inclusive NEGs independentes.

VMs e contêineres no mesmo serviço de back-end

Neste exemplo, mostramos como criar um NEG que aponta para uma VM existente que executa uma carga de trabalho e como adicionar esse NEG como outro back-end de um backendService existente. Dessa forma, um único balanceador de carga faz o balanceamento entre VMs e contêineres do GKE.

Estes exemplos estendem o exemplo acima que usa um balanceador de carga HTTP externo.

Como todos os endpoints são agrupados pelo mesmo backendService, os endpoints da VM e do contêiner são considerados o mesmo serviço. Isso significa que a correspondência de host/caminho tratará todos os back-ends de maneira idêntica com base nas regras de mapa de URL.

Um diagrama que mostra a arquitetura descrita acima. O balanceador de carga criado aponta para dois NEGs, o NEG para contêineres criados anteriormente e um novo NEG que contém o endereço IP de uma VM

Quando você usa um NEG como back-end para um serviço de back-end, todos os outros back-ends nesse serviço também precisam ser NEGs. Não é possível usar grupos de instância e NEGs como back-end no mesmo serviço de back-end. Além disso, os contêineres e as VMs não podem existir como endpoints no mesmo NEG. Portanto, eles precisam sempre ser configurados com NEGs separados.

  1. Implante uma VM no Compute Engine com o comando:

    gcloud compute instances create vm1 --zone zone --network=network \
         --subnet=subnet --image-project=cos-cloud \
         --image-family=cos-stable --tags=vm-neg-tag
  2. Implante um aplicativo na VM:

    gcloud compute ssh vm1 --zone=${ZONE} --command="docker run -d --rm --network=host \
         k8s.gcr.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"

    Esse comando implanta na VM o mesmo aplicativo de exemplo usado no exemplo anterior. Para simplificar, o aplicativo é executado como um contêiner do Docker, mas isso não é essencial. O comando iptables é necessário para permitir o acesso de firewall ao contêiner em execução.

  3. Valide se o aplicativo está sendo exibido na porta 9376 e informando que está sendo executado na vm1:

    gcloud compute ssh vm1 --zone=zone --command="curl -s localhost:9376"

    O servidor responderá com vm1.

  4. Crie um NEG para usar com o endpoint da VM. Os contêineres e as VMs podem ser endpoints de NEG, mas um único NEG não pode ter endpoints de VM e de contêineres.

    gcloud compute network-endpoint-groups create vm-neg \
        --subnet=subnet --zone=zone
  5. Anexe o endpoint da VM ao NEG:

    gcloud compute network-endpoint-groups update vm-neg --zone=zone \
         --add-endpoint="instance=vm1,ip=vm-primary-ip,port=9376"
  6. Confirme se o NEG tem o endpoint da VM:

    gcloud compute network-endpoint-groups list-network-endpoints vm-neg --zone zone
  7. Anexe o NEG ao serviço de back-end usando o mesmo comando usado para adicionar um back-end de contêiner:

    gcloud compute backend-services add-backend my-bes --global \
         --network-endpoint-group vm-neg \
         --network-endpoint-group-zone zone \
         --balancing-mode RATE --max-rate-per-endpoint 10
  8. Abra o firewall para permitir a verificação de integridade da VM:

    gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
        --network=network \
        --action=allow \
        --direction=ingress \
        --target-tags=vm-neg-tag \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --rules=tcp:9376
        
  9. Confirme se o balanceador de carga está encaminhando o tráfego para o novo back-end vm1 e para o back-end existente enviando tráfego de teste:

    for i in `seq 1 100`; do curl ${VIP};echo; done

    Você verá as respostas dos endpoints do contêiner (neg-demo-app) e da VM (vm1).

VMs e contêineres para diferentes serviços de back-end

Neste exemplo, mostramos como criar um NEG que aponta para uma VM existente que executa uma carga de trabalho e como adicionar esse NEG como back-end a um novo backendService. Isso é útil para os casos em que os contêineres e as VMs são serviços diferentes, mas precisam compartilhar o mesmo balanceador de carga L7, como no caso dos serviços compartilharem o mesmo endereço IP ou nome de domínio.

Este exemplo estende o exemplo anterior que tem um back-end de VM no mesmo serviço de back-end que o back-end do contêiner. Este exemplo reutiliza essa VM.

Como os endpoints do contêiner e da VM são agrupados em backendServices separados, eles são considerados serviços diferentes. Isso significa que o mapa de URL corresponderá a back-ends e direcionará o tráfego para a VM ou o contêiner com base no nome do host.

O diagrama a seguir mostra como um único endereço IP virtual corresponde a dois nomes de host, que, por sua vez, correspondem a um serviço de back-end baseado em contêiner e a um serviço de back-end baseado em VM.

O diagrama a seguir mostra a arquitetura descrita acima:

A arquitetura tem dois NEGs, um para o serviço implementado com contêineres e outro para o serviço implementado com VMs. Há um objeto de serviço de back-end para cada NEG. O objeto do mapa de URL direciona o tráfego para o serviço de back-end correto com base no URL solicitado.

  1. Crie um novo serviço de back-end para a VM:

    gcloud compute backend-services create my-vm-bes \
          --protocol HTTP \
          --health-checks http-basic-check \
          --global
  2. Anexe o NEG da VM, vm-neg, ao serviço de back-end:

    gcloud compute backend-services add-backend my-vm-bes --global \
         --network-endpoint-group vm-neg \
         --network-endpoint-group-zone zone \
         --balancing-mode RATE --max-rate-per-endpoint 10
  3. Adicione uma regra de host ao mapa de URL para direcionar solicitações para o host container.example.com ao serviço de back-end do contêiner:

    gcloud compute url-maps add-path-matcher web-map \
          --path-matcher-name=container-path --default-service=my-bes \
          --new-hosts=container.example.com --global
        
  4. Adicione outra regra de host ao mapa de URL para direcionar solicitações para o host vm.example.com ao serviço de back-end da VM:

    gcloud compute url-maps add-path-matcher web-map \
          --path-matcher-name=vm-path --default-service=my-vm-bes \
          --new-hosts=vm.example.com --global
        
  5. Valide se o balanceador de carga envia tráfego para o back-end da VM com base no caminho solicitado:

    curl -H "vm.example.com" virtual-ip

Limitações de NEGs independentes

  • Erros de validação de anotação são expostos ao usuário por meio de eventos do Kubernetes.
  • Nomes de NEGs são gerados pelo controlador de NEG. Não é possível fornecer nomes personalizados para NEGs.
  • As limitações de NEGs também se aplicam aos NEGs independentes.
  • NEGs independentes não funcionam com redes legadas.
  • Os NEGs independentes só podem ser usados com serviços de rede compatíveis, incluindo Traffic Director e os tipos de balanceador de carga compatíveis.

Preços

Consulte a seção de balanceamento de carga da página de preços para ver detalhes sobre os preços do balanceador de carga. Não há cobrança extra para NEGs.

Solução de problemas

Nenhum NEG independente configurado

Sintoma: nenhum NEG criado.

Possível resolução:

  • Verifique os eventos associados ao serviço e procure mensagens de erro.
  • Verifique se a anotação do NEG independente é um JSON bem formado e se as portas expostas correspondem às portas existentes na especificação do serviço.
  • Verifique a anotação de status de NEG e veja se as portas de serviço esperadas têm NEGs correspondentes.
  • Verifique se os NEGs foram criados nas zonas esperadas, com o comando gcloud compute network-endpoint-groups list.

O tráfego não alcança os endpoints

Sintoma: erros 502 ou conexões rejeitadas.

Possível resolução:

  • Após a configuração do serviço, novos endpoints geralmente se tornarão acessíveis depois de serem anexados ao NEG, desde que respondam às verificações de integridade.
  • Se, após esse período, o tráfego ainda não conseguir alcançar os endpoints, resultando no código de erro 502 para HTTP(S) ou em conexões rejeitadas para balanceadores de carga TCP/SSL, verifique o seguinte:
    • Verifique se as regras de firewall autorizam o tráfego TCP de entrada nos seus endpoints proveniente dos seguintes intervalos: 130.211.0.0/22 e 35.191.0.0/16.
    • Verifique se os endpoints estão íntegros usando a gcloud ou chamando a API getHealth no BackendService ou a API listEndpoints no NEG com o parâmetro showHealth definido como SHOW.

Lançamento interrompido

Sintoma: uma implantação atualizada é interrompida e o número de réplicas atualizadas não corresponde ao número desejado.

Possível resolução:

As verificações de integridade da implantação estão falhando. A imagem do contêiner pode estar corrompida ou a verificação de integridade pode estar mal configurada. A substituição gradual dos pods aguarda até que o pod recém-iniciado passe pelo portão de prontidão do pod (em inglês). Isso só ocorrerá se o pod estiver respondendo às verificações de integridade do balanceador de carga. Se o pod não estiver respondendo ou se a verificação de integridade estiver configurada incorretamente, as condições do portão de prontidão não serão cumpridas e o lançamento não poderá continuar.

  • Se o kubectl 1.13 ou mais recente estiver sendo usado, será possível verificar o status dos portões de prontidão de um pod com o seguinte comando:

    kubectl get my-Pod -o wide

    Verifique a coluna READINESS GATES.

    Esta coluna não existe no kubectl 1.12 e versões anteriores. Um pod marcado com o estado READY pode ter um portão de prontidão com falha. Para verificar isso, use o seguinte comando:

    kubectl get my-pod -o yaml

    Os portões de prontidão e os status deles são listados na saída.

  • Verifique se a imagem do contêiner na especificação do pod da implantação está funcionando corretamente e se pode responder às verificações de integridade.

  • Confira se as verificações de integridade estão configuradas corretamente.

A seguir