Balanceamento de carga nativo de contêiner por meio de NEGs zonais 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) GCE_VM_IP_PORT zonal em um Cluster nativo de VPC do Google Kubernetes Engine (GKE).

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 NEG representa um grupo de endpoints. O GKE é compatível com NEGs independentes do tipo GCE_VM_IP_PORT. Os NEGs GCE_VM_IP_PORT são compatíveis com endpoints usando o endereço IP interno primário da VM ou um endereço IP de um dos intervalos de IP do alias.

No contexto de um cluster nativo de VPC do GKE usando NEGs independentes, cada endpoint é um endereço IP do pod e uma porta de destino. Os endereços IP do pod são provenientes do intervalo de IP do alias do nó para pods, que vem do intervalo de endereços IP secundário da sub-rede do cluster para pods.

O GKE fornece um controlador NEG para gerenciar a associação de NEGs GCE_VM_IP_PORT. É possível adicionar os NEGs que ele cria como back-ends aos serviços de back-end para balanceadores de carga configurados fora da API GKE.

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 controlador do NEG do plano de controle.

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. Isso inclui a criação de 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 atendem ao 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 da 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 do NEG no plano de controle 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.

Como evitar o vazamento de NEGs

Com os NEGs independentes, você é responsável pelo gerenciamento dos ciclos de vida dos NEGs e dos recursos que compõem o balanceador de carga. O vazamento de NEGs pode ocorrer das seguintes maneiras:

  • Quando um serviço do GKE for excluído, o NEG associado não será coletado como lixo se ele ainda for referenciado por um serviço de back-end. Desreferencie o NEG do serviço de back-end para permitir a exclusão do NEG.
  • Os NEGs independentes não são excluídos quando um cluster é excluído.

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 da Entrada personalizados

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

Usar o Traffic Director com GKE

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

Usar balanceadores de carga de rede de proxy externo com o GKE

É possível usar NEGs independentes para balancear a carga diretamente para contêineres com o balanceador de carga Proxy de rede externo 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

O cluster precisa ser nativo de VPC. Para saber mais, consulte Como criar um cluster nativo de VPC.

O cluster precisa ter o complemento HttpLoadBalancing ativado. Os clusters do GKE têm o complemento HttpLoadBalancing ativado por padrão.

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.

Como usar NEGs independentes

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

Crie os seguintes 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 a seguir:

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

Os clusters do Autopilot são nativos de VPC por padrão, portanto, você pode pular para Implantar uma carga de trabalho.

Para clusters padrão, crie um cluster nativo de VPC na zona us-central1-a:

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

Crie uma implantação

Os manifestos de exemplo a seguir especificam as implantações que executam 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.

Recomenda-se o uso de cargas de trabalho que utilizem 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: registry.k8s.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: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname

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

Crie um serviço.

O manifesto a seguir especifica um serviço em que:

  • 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. O campo opcional name especifica que o NEG será nomeado NEG_NAME. Se o campo name for omitido, um nome exclusivo será gerado automaticamente. Consulte Como nomear NEGs para mais detalhes.
  • 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":{"name": "NEG_NAME"}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

Substitua NEG_NAME pelo nome do NEG. O nome do NEG precisa ser exclusivo na região dele.

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

Um NEG é criado poucos minutos após a criação do serviço.

Tipos de serviço

Embora este exemplo use um serviço ClusterIP, todos os cinco tipos de Serviço são compatíveis com NEGs independentes. Recomendamos o tipo padrão, ClusterIP.

Como nomear NEGs

Nas versões 1.18.18-gke.1200 e posteriores do GKE, é possível especificar um nome personalizado para os NEGs, ou o GKE pode gerar um nome automaticamente. As versões anteriores do GKE são compatíveis apenas com nomes de NEG gerados automaticamente.

O GKE cria um NEG em cada zona usada pelo cluster. Todos os NEGs usam o mesmo nome.

Como especificar um nome

Especificar um nome de NEG personalizado simplifica a configuração do balanceador de carga porque você sabe com antecedência o nome e as zonas dos NEGs. Os nomes de NEGs personalizados precisam atender aos seguintes requisitos:

  • ser exclusivo para a zona do cluster para clusters zonais ou exclusivo para a região para clusters regionais;
  • não pode corresponder ao nome de qualquer NEG que não tenha sido criado pelo controlador de NEG do GKE.
  • Não pode conter sublinhados.

Use o campo name na anotação cloud.google.com/neg do Serviço para especificar um nome de NEG:

cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'

Substitua NEG_NAME pelo nome do NEG. O nome do NEG precisa ser exclusivo na região dele.

Como usar um nome gerado automaticamente

Os nomes de NEG gerados automaticamente têm exclusividade garantida. Para usar um nome gerado automaticamente, omita o campo name:

cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'

O nome gerado automaticamente tem o seguinte formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

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":{},
      ...
   }
 }'

Neste exemplo, cada instância de SERVICE_PORT_N é um número de porta distinto que se refere à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 o seguinte comando para recuperar os status dos serviços do cluster:

kubectl get service neg-demo-svc -o yaml

O resultado será assim:

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "SERVICE_PORT_1": "NEG_NAME_1",
      "SERVICE_PORT_2": "NEG_NAME_2",
      ...
   },
   "zones":["ZONE_1", "ZONE_2", ...]
}

Nessa saída, cada elemento no mapeamento network-endpoint-groups é uma porta de serviço (como SERVICE_PORT_1) e o nome dos NEGs gerenciados correspondentes (como NEG_NAME_1). A lista zones contém todas as zonas (como ZONE_1) que têm um NEG.

O resultado será assim:

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":["ZONE_1", "ZONE_2"]}'
  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: {}

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

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.

Há duas maneiras de verificar se o NEG foi criado e se está configurado corretamente. No GKE 1.18.6-gke.6400 e posterior, um recurso personalizado ServiceNetworkEndpointGroup armazena informações de status sobre NEGs criados pelo controlador de Serviço. Nas versões anteriores, é preciso inspecionar os NEGs diretamente.

O recurso ServiceNetworkEndpointGroup

Liste os NEGs de um cluster recebendo todos os recursos ServiceNetworkEndpointGroup:

kubectl get svcneg

Observe o status de um NEG verificando o status do recurso ServiceNetworkEndpointGroup:

kubectl get svcneg NEG_NAME -o yaml

Substitua NEG_NAME pelo nome do NEG individual que você quer inspecionar.

A saída desse comando inclui uma seção de status que pode conter mensagens de erro. Alguns erros são relatados como um evento de serviço. Para mais detalhes, consulte o objeto de serviço:

kubectl describe service SERVICE_NAME

Substitua SERVICE_NAME pelo nome do Serviço relevante.

Para verificar se o controlador de NEG está sincronizando com êxito, confira o campo de status do recurso ServiceNetworkEndpointGroup para uma condição com type:Synced. A hora da sincronização mais recente está no campo status.lastSyncTime.

Os recursos ServiceNetworkEndpointGroup só existem no GKE versão 1.18 e posteriores.

Como inspecionar NEGs diretamente

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 o seguinte formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Use o seguinte comando para listar NEGs:

gcloud compute network-endpoint-groups list

O resultado será assim:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      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 o seguinte comando:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Substitua NEG_NAME pelo nome do NEG em que você quer exibir os endpoints individuais.

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

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

Como anexar um balanceador de carga de aplicativo externo a NEGs independentes

É possível usar NEGs como back-end para um balanceador de carga de aplicativo externo usando a API Compute Engine.

  1. Crie uma regra de firewall. Os balanceadores de carga precisam acessar os endpoints do cluster para realizar verificações de integridade. Este comando cria uma regra de firewall para permitir o 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

    Substitua:

    • NETWORK_NAME: a rede em que o cluster é executado;
    • GKE_NODE_NETWORK_TAGS: as tags de rede nos nós do GKE.

    Se você não criou tags de rede personalizadas para seus nós, o GKE gerará tags automaticamente. É possível procurar essas tags geradas executando o seguinte comando:

    gcloud compute instances describe INSTANCE_NAME

    Substitua INSTANCE_NAME pelo nome da instância de VM do host do Compute Engine que executa o nó do GKE. Por exemplo, a saída na seção anterior exibe os nomes das instâncias na coluna INSTANCE dos nós do GKE. Para clusters padrão, também é possível executar gcloud compute instances list para listar todas as instâncias no projeto.

  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 de aplicativo externo global:

    gcloud compute backend-services create my-bes \
    --protocol HTTP \
    --health-checks http-basic-check \
    --global

  5. Crie um mapa de URL 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

    Substitua HOSTNAME_SERVER_VIP pelo endereço IP a ser usado para o balanceador de carga. Se você omitir --address, o GKE atribuirá automaticamente um endereço IP temporário. Também é possível reservar um novo endereço IP externo estático.

Check Point

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 a seguir:

image

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 de front-end.

Adicionar back-ends ao balanceador de carga

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

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

Substitua:

  • NEG_NAME: o nome do grupo de endpoints da rede. Pode ser o nome especificado ao criar o NEG ou um nome gerado automaticamente. Se você não especificou um nome para o NEG, consulte as seguintes instruções para encontrar o nome gerado automaticamente.
  • NEG_ZONE: a zona em que o grupo de endpoints da rede está. Consulte as instruções a seguir para encontrar esse valor.

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

gcloud compute network-endpoint-groups list

O resultado será assim:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

Neste exemplo de saída, o nome do NEG é k8s1-70aa83a6-default-my-service-80-c9710a6f.

Vários NEGs podem ser adicionados ao mesmo serviço de back-end. Serviços de back-end globais, como my-bes, podem ter back-ends NEG em regiões diferentes, 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:

  • Confira se a verificação de integridade está configurada corretamente e gerar relatórios de integridade.
  • Acesse o aplicativo e verifique a resposta.

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

O resultado será assim:

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 é semelhante à seguinte:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-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 anexar um balanceador de carga interno do aplicativo a NEGs independentes

É possível usar NEGs para configurar um balanceador de carga de aplicativo interno para os serviços em execução nos pods autônomos do GKE.

Como configurar a sub-rede somente prox

A sub-rede somente proxy é para todos os balanceadores de carga de aplicativo internos regionais na região do balanceador de carga.

Console

Se você estiver usando o Console do Google Cloud, poderá esperar e criar a sub-rede somente proxy mais tarde.

gcloud

Crie a sub-rede somente proxy com o comando gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=lb-network \
    --range=10.129.0.0/23

Substitua COMPUTE_REGION pelo Compute Engine da sub-rede.

API

Crie a sub-rede somente proxy com o método subnetworks.insert.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Substitua:

  • PROJECT_ID: o ID do projeto.
  • COMPUTE_REGION: o Compute Engine da sub-rede.

Como configurar regras de firewall

Neste exemplo, usamos as seguintes regras de firewall:

  • fw-allow-ssh: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite a conectividade SSH de entrada na porta TCP 22 proveniente de qualquer endereço. Você pode escolher um intervalo de IP de origem mais restritivo para esta regra. Por exemplo, é possível especificar apenas os intervalos de IP do sistema do qual você inicia sessões SSH. Neste exemplo, usamos a tag de destino allow-ssh para identificar as VMs às quais a regra de firewall se aplica.

  • fw-allow-health-check: uma regra de entrada aplicável às instâncias com balanceamento de carga, que autoriza o tráfego TCP proveniente de sistemas de verificação de integridade do Google Cloud (130.211.0.0/22 e 35.191.0.0/16). No exemplo, é usada a tag de destino load-balanced-backend para identificar as instâncias submetidas à regra.

  • fw-allow-proxies: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite o tráfego TCP nas portas 9376, nos proxies gerenciados do balanceador de carga HTTP(S) interno. Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as instâncias às quais ele deve se aplicar.

Sem essas regras de firewall, a regra padrão de negação de entrada bloqueará o tráfego que chega para as instâncias de back-end.

Console

  1. Acesse a página de políticas de firewall no console do Google Cloud.

    Acessar Políticas de firewall

  2. Clique em Criar regra de firewall para criar uma regra que autorize conexões SSH de entrada:

    • Name: fw-allow-ssh
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: allow-ssh
    • Filtro de origem: IPv4 ranges
    • Intervalos IPv4 de origem: 0.0.0.0/0
    • Protocolos e portas:
      • Selecione Portas e protocolos especificados.
      • Marque a caixa de seleção tcp e especifique a porta 22.

  3. Clique em Criar.

  4. Clique em Criar regra de firewall para criar a regra que permita as verificações de integridade do Google Cloud:

    • Name: fw-allow-health-check
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: load-balanced-backend
    • Filtro de origem: IPv4 ranges
    • Intervalos IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas:
      • Selecione Portas e protocolos especificados.
      • Marque a caixa de seleção tcp e especifique a porta 80. Como prática recomendada, limite esta regra somente aos protocolos e portas que correspondem aos usados por sua verificação de integridade. Se você usar tcp:80 para o protocolo e a porta, o Google Cloud pode contatar suas VMs usando HTTP na porta 80, mas não pode entrar em contato com elas usando HTTPS na porta 443.

  5. Clique em Criar.

  6. Clique novamente em Criar regra de firewall novamente para criar a regra que permite que os servidores proxy do balanceador de carga se conectem aos back-ends:

    • Name: fw-allow-proxies
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação se houver correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: load-balanced-backend
    • Filtro de origem: IPv4 ranges
    • Intervalos IPv4 de origem: 10.129.0.0/23
    • Protocolos e portas:
      • Selecione Portas e protocolos especificados.
      • Marque a caixa de seleção tcp e especifique a porta 9376.

  7. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-allow-ssh que permita a conectividade SSH para VMs com a tag de rede allow-ssh. Se você omitir source-ranges, o Google Cloud interpretará que a regra autoriza a conexão proveniente de qualquer origem.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  2. Crie a regra fw-allow-health-check para permitir verificações de integridade do Google Cloud. Neste exemplo, é permitido todo o tráfego TCP de sondagens de verificação de integridade. No entanto, é possível configurar um conjunto mais restrito de portas para atender às suas necessidades.

    gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp

  3. Crie a regra fw-allow-proxies para permitir que os proxies do balanceador de carga HTTP(S) interno se conectem aos back-ends.

    gcloud compute firewall-rules create fw-allow-proxies \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.129.0.0/23 \
    --target-tags=load-balanced-backend \
    --rules=tcp:9376

API

Crie a regra de firewall fw-allow-ssh fazendo uma solicitação POST ao método firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Substitua PROJECT_ID pela ID do seu projeto.

Crie a regra de firewall fw-allow-health-check fazendo uma solicitação POST ao método firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Crie a regra de firewall fw-allow-proxies para permitir ao tráfego TCP dentro da sub-rede proxy o método firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "9376"
      ]
    }
  ],
  "direction": "INGRESS"
}

Substitua PROJECT_ID pela ID do seu projeto.

Como configurar o balanceador de carga

Para o endereço IP da regra de encaminhamento, use uma sub-rede de back-end. Se você tentar usar a sub-rede apenas de proxy, a criação da regra de encaminhamento falhará.

Console

Selecionar um tipo de balanceador de carga

  1. Acesse a página Criar balanceador de carga no Console do Google Cloud. Acesse Criar um balanceador de carga
  2. Em Balanceamento de carga HTTP(S), clique em Iniciar configuração.
  3. Selecione Apenas entre minhas VMs. Essa configuração implica que o balanceador de carga é interno.
  4. Clique em Continuar.

Preparar o balanceador de carga

  1. Em Nome do balanceador de carga, digite l7-ilb-gke-map.
  2. Em Região, selecione a região em que você criou a sub-rede.
  3. Em Rede, selecione lb-network.

Reservar uma sub-rede somente proxy

Reserve uma sub-rede somente proxy:

  1. Clique em Reservar uma sub-rede.
  2. Em Nome, insira proxy-only-subnet.
  3. Em Intervalo de endereços IP, digite 10.129.0.0/23.
  4. Clique em Adicionar.

Configurar o serviço de back-end

  1. Clique em Configuração do back-end.
  2. No menu Criar ou selecionar serviços de back-end, selecione Criar um serviço de back-end.
  3. Defina o Nome do serviço de back-end como l7-ilb-gke-backend-service.
  4. Em Tipo de back-end, selecione Grupos de endpoints de rede.
  5. No cartão Novo back-end da seção Back-ends, siga estas etapas:
    1. Defina Grupo de endpoints de rede como o NEG criado pelo GKE. Para receber o nome do NEG, consulte Validar a criação de NEG.
    2. Em RPS máximo, especifique uma taxa máxima de 5 RPS por endpoint. O Google Cloud excederá esse limite máximo se necessário.
    3. Clique em Concluído.
  6. Na lista suspensa Verificação de integridade, selecione Criar verificação de integridade e especifique os seguintes parâmetros:
    1. Name: l7-ilb-gke-basic-check
    2. Protocolo: HTTP
    3. Especificação de portas: porta de exibição
    4. Clique em Salvar e continuar.
  7. Clique em Criar.

Configurar o mapa de URL

  1. Clique em Regras de roteamento. Certifique-se de que o l7-ilb-gke-backend-service seja o único serviço de back-end para qualquer host e caminho sem correspondência.

Configure o front-end

Clique em Configuração de front-end e siga estas instruções:

Para HTTP:

  1. Clique em Configuração de front-end.
  2. Clique em Adicionar IP e porta de front-end.
  3. Defina o Nome como l7-ilb-gke-forwarding-rule.
  4. Defina o Protocolo como HTTP.
  5. Defina a Sub-rede como backend-subnet.
  6. Em IP interno, selecione Reservar um endereço IP interno estático.
  7. No painel exibido, forneça os seguintes detalhes:
    1. Name: l7-ilb-gke-ip
    2. Na seção Endereço IP estático, selecione Quero escolher.
    3. Na seção Endereço IP personalizado, insira 10.1.2.199.
    4. Clique em Reservar.
  8. Defina Porta como 80.
  9. Clique em Concluído.

Para HTTPS:

Se você usa o HTTPS entre o cliente e o balanceador de carga, um ou mais recursos de certificado SSL serão necessários para configurar o proxy. Consulte as informações sobre como criar recursos de certificado SSL em Certificados SSL. Os certificados gerenciados pelo Google não são compatíveis com balanceadores de carga HTTP(S) internos.

  1. Clique em Configuração de front-end.
  2. Clique em Adicionar IP e porta de front-end.
  3. No campo Nome, use l7-ilb-gke-forwarding-rule.
  4. No campo Protocolo, selecione HTTPS (includes HTTP/2).
  5. Defina a Sub-rede como sub-rede de back-end.
  6. Em IP interno, selecione Reservar um endereço IP interno estático.
  7. No painel exibido, forneça os seguintes detalhes:
    1. Name: l7-ilb-gke-ip
    2. Na seção Endereço IP estático, selecione Quero escolher.
    3. Na seção Endereço IP personalizado, insira 10.1.2.199.
    4. Clique em Reservar.
  8. Certifique-se de que a Porta esteja definida como 443, para permitir tráfego HTTPS.
  9. Clique na lista suspensa Certificado.
    1. Se você já tiver um recurso de certificado SSL autogerenciado que você quer usar como o certificado SSL principal, selecione-o no menu suspenso.
    2. Caso contrário, selecione Criar um novo certificado.
      1. Preencha um Nome para l7-ilb-cert.
      2. Nos campos apropriados, faça o upload dos arquivos formatados em PEM:
        • Certificado de chave pública
        • Cadeia de certificados
        • Chave privada
      3. Clique em Criar.
  10. Para adicionar recursos de certificado além do certificado SSL principal, siga estas etapas:
    1. Clique em Adicionar certificado.
    2. Selecione um certificado na lista Certificados ou clique em Criar um novo certificado e siga as instruções.
  11. Clique em Concluído.

Concluir a configuração

Clique em Criar.

gcloud

  1. Defina a verificação de integridade HTTP com o comando gcloud compute health-checks create http.

    gcloud compute health-checks create http l7-ilb-gke-basic-check \
    --region=COMPUTE_REGION \
    --use-serving-port

  2. Defina o serviço de back-end com o comando gcloud compute backend-services create.

    gcloud compute backend-services create l7-ilb-gke-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-gke-basic-check \
    --health-checks-region=COMPUTE_REGION \
    --region=COMPUTE_REGION

  3. Defina a variável DEPLOYMENT_NAME:

    export DEPLOYMENT_NAME=NEG_NAME

    Substitua NEG_NAME pelo nome do NEG.

  4. Adicione back-ends de NEG ao serviço de back-end com o comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend l7-ilb-gke-backend-service \
    --network-endpoint-group=$DEPLOYMENT_NAME \
    --network-endpoint-group-zone=COMPUTE_ZONE-b \
    --region=COMPUTE_REGION \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=5

  5. Crie o mapa de URL com o comando gcloud compute url-maps create.

    gcloud compute url-maps create l7-ilb-gke-map \
    --default-service=l7-ilb-gke-backend-service \
    --region=COMPUTE_REGION

  6. Crie o proxy de destino.

    Para HTTP:

    Use o comando gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create l7-ilb-gke-proxy \
    --url-map=l7-ilb-gke-map \
    --url-map-region=COMPUTE_REGION \
    --region=COMPUTE_REGION

    Para HTTPS:

    Consulte as informações sobre como criar recursos de certificado SSL em Certificados SSL. Os certificados gerenciados pelo Google não são compatíveis com balanceadores de carga HTTP(S) internos.

    Atribua os caminhos de arquivo aos nomes de variáveis.

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE

    export LB_PRIVATE_KEY=PATH_TO_PEM_FORMATTED_FILE

    Use o comando gcloud compute ssl-certificates create para criar um certificado SSL regional.

    gcloud compute ssl-certificates create

    gcloud compute ssl-certificates create l7-ilb-cert \
    --certificate=$LB_CERT \
    --private-key=$LB_PRIVATE_KEY \
    --region=COMPUTE_REGION

    Use o certificado SSL regional para criar um proxy de destino com o comando gcloud compute target-https-proxies create.

    gcloud compute target-https-proxies create l7-ilb-gke-proxy \
    --url-map=l7-ilb-gke-map \
    --region=COMPUTE_REGION \
    --ssl-certificates=l7-ilb-cert

  7. Crie a regra de encaminhamento.

    Para redes personalizadas, referencie a sub-rede na regra de encaminhamento. Observe que esta é a sub-rede da VM, não a do proxy.

    Para HTTP:

    Use o comando gcloud compute forwarding-rules create com as sinalizações corretas.

    gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.199 \
    --ports=80 \
    --region=COMPUTE_REGION \
    --target-http-proxy=l7-ilb-gke-proxy \
    --target-http-proxy-region=COMPUTE_REGION

    Para HTTPS:

    Use o comando gcloud compute forwarding-rules create com as sinalizações corretas.

    gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.199 \
    --ports=443 \
    --region=COMPUTE_REGION \
    --target-https-proxy=l7-ilb-gke-proxy \
    --target-https-proxy-region=COMPUTE_REGION

API

Crie a verificação de integridade fazendo uma solicitação POST ao método regionHealthChecks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

Substitua PROJECT_ID pelo ID do projeto.

Crie um serviço de back-end regional fazendo uma solicitação POST ao método regionBackendServices.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

Substitua:

  • PROJECT_ID: o ID do projeto;
  • NEG_NAME: o nome do NEG.

Crie o mapa de URLs fazendo uma solicitação POST ao método regionUrlMaps.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}

Substitua PROJECT_ID pelo ID do projeto.

Crie o proxy HTTP de destino fazendo uma solicitação POST ao método regionTargetHttpProxies.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "COMPUTE_REGION"
}

Substitua PROJECT_ID pelo ID do projeto.

Crie a regra de firewall fazendo uma solicitação POST ao método forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Substitua PROJECT_ID pelo ID do projeto.

Teste

Criar uma instância de VM na zona para testar a conectividade:

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=l7-ilb-client,allow-ssh

Faça login na instância do cliente para que os serviços HTTP(S) nos back-ends sejam acessados pelo endereço IP da regra de encaminhamento do balanceador de carga de aplicativo interno e o balanceamento de carga do tráfego seja feito entre os endpoints no NEG.

Conecte-se a cada instância do cliente usando SSH:

gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE-b

Verifique se o IP está exibindo o nome do host:

curl 10.1.2.199

Para fazer testes em HTTPS, execute o seguinte comando:

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

A sinalização -k faz com que curl ignore a validação do certificado.

Executar 100 solicitações e confirmar o balanceamento de carga delas

Para HTTP:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Para HTTPS:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

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 atual que executa uma carga de trabalho e como adicionar esse NEG como outro back-end de um backendService atual. Dessa forma, um único balanceador de carga faz o balanceamento entre VMs e contêineres do GKE.

Este exemplo estende o exemplo anterior 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 ou 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. 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=COMPUTE_ZONE \
    --network=NETWORK \
    --subnet=SUBNET \
    --image-project=cos-cloud \
    --image-family=cos-stable --tags=vm-neg-tag

    Substitua:

    • COMPUTE_ZONE: o nome da zona.
    • NETWORK: o nome da rede.
    • SUBNET: o nome da sub-rede associada à rede.

  2. Implante um aplicativo na VM:

    gcloud compute ssh vm1 \
    --zone=COMPUTE_ZONE \
    --command="docker run -d --rm --network=host registry.k8s.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=COMPUTE_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=COMPUTE_ZONE

  5. Anexe o endpoint da VM ao NEG:

    gcloud compute network-endpoint-groups update vm-neg \
    --zone=COMPUTE_ZONE \
    --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"

    Substitua VM_PRIMARY_IP pelo endereço IP principal da VM.

  6. Confirme se o NEG tem o endpoint da VM:

    gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
    --zone COMPUTE_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 COMPUTE_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 atual 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 atual 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 serviço de back-end 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 na seção anterior:

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 COMPUTE_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 "HOST:vm.example.com" VIRTUAL_IP

    Substitua VIRTUAL_IP pelo endereço IP virtual.

Limitações de NEGs independentes

  • Erros de validação de anotação são expostos ao usuário por meio de eventos do Kubernetes.
  • As limitações de NEGs também se aplicam aos NEGs independentes.

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

Nesta seção, apresentamos as etapas de solução de problemas comuns que podem ser encontrados com os NEGs independentes.

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.
  • Se estiver usando a versão 1.18 ou posterior do GKE, verifique se o recurso svcneg do Serviço existe. Caso contrário, consulte a condição Initialized para ver informações sobre o erro.
  • Se você estiver usando nomes personalizados de NEG, verifique se cada nome de NEG é exclusivo em sua região.

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 Google Cloud CLI 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 escolhido.

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. 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 poderão ser 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 de implantação está funcionando corretamente e se é capaz de responder a verificações de integridade.

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

O NEG não é coletado como lixo

Sintoma: um NEG que deveria ter sido excluído ainda existe.

Possível resolução:

  • O NEG não é coletado como lixo se o NEG é referenciado por um Serviço de back-end. Consulte Como evitar NEGs vazados para ver detalhes.
  • Se estiver usando a versão 1.18 ou posterior, verifique se há eventos no recurso ServiceNetworkEndpointGroup usando o procedimento negativo de serviço.
  • Verifique se o NEG ainda é necessário para ser usado por um serviço. Verifique o recurso svcneg do serviço que corresponde ao NEG e se há uma anotação de Serviço.

O NEG não é sincronizado com o Serviço

Sintoma: os endpoints esperados (IP do pod) não existem no NEG, o NEG não está sincronizado ou o erro Failed to sync NEG_NAME (will not retry): neg name NEG_NAME is already in use, found a custom named neg with an empty description

Possível resolução:

Se você estiver usando o GKE 1.18 ou posterior, verifique o recurso svcneg para mais informações:

  • Verifique o valor status.lastSyncTime para verificar se o NEG foi sincronizado recentemente.
  • Verifique a condição Synced em busca de erros que ocorreram na sincronização mais recente.

Se você estiver usando o GKE 1.19.9 ou posterior, verifique se há um NEG com o nome e a zona correspondentes ao nome e à zona do NEG que o controlador do NEG do GKE precisa criar. Por exemplo, um NEG com o nome que o controlador de NEG precisa usar pode ter sido criado usando a gcloud CLI ou o Console do Google Cloud na zona do cluster (ou uma das zonas do cluster). Nesse caso, é necessário excluir o NEG antes que o controlador de NEG possa sincronizar os endpoints. A criação e assinatura independentes de NEG foram projetadas para serem gerenciadas pelo controlador de NEG.

A seguir