Balanceamento de carga nativa do contentor através de NEGs zonais autónomos

Esta página mostra como criar um serviço do Kubernetes suportado por um grupo de pontos finais de rede (NEG) zonalGCE_VM_IP_PORT num cluster nativo da VPC do Google Kubernetes Engine (GKE).

Para obter informações sobre as vantagens, os requisitos e as limitações do balanceamento de carga nativa do contentor, consulte o artigo Balanceamento de carga nativa do contentor.

Vista geral

Um NEG representa um grupo de pontos finais. O GKE suporta NEGs autónomos do tipo GCE_VM_IP_PORT. GCE_VM_IP_PORT Os NEGs suportam pontos finais que usam o endereço IP interno principal da VM ou um endereço IP de um dos respetivos intervalos de IPs de alias.

No contexto de um cluster nativo da VPC do GKE que usa NEGs autónomos, cada ponto final é um endereço IP do pod e uma porta de destino. Os endereços IP dos pods são provenientes do intervalo de IPs de alias do nó para pods, que é proveniente do intervalo de endereços IP secundários da sub-rede do cluster para pods.

O GKE fornece um controlador NEG para gerir a associação de GCE_VM_IP_PORT NEGs. Pode adicionar os NEGs que cria como back-ends aos serviços de back-end para equilibradores de carga que configura fora da API GKE.

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

Entrada com NEGs

Quando os NEGs são usados com o GKE Ingress, o controlador Ingress facilita a criação de todos os aspetos do equilibrador de carga. Isto inclui a criação do endereço IP virtual, das regras de encaminhamento, das verificações de estado, das regras de firewall e muito mais.

A entrada é a forma recomendada de usar o balanceamento de carga nativo do contentor, uma vez que tem muitas funcionalidades que simplificam a gestão de NEGs. Os NEGs autónomos são uma opção se os NEGs geridos pelo Ingress não servirem para o seu exemplo de utilização.

Grupos de pontos finais de rede autónomos

Quando os NEGs são implementados com balanceadores de carga aprovisionados por qualquer outro elemento que não seja o Ingress, são considerados NEGs autónomos. Os NEGs autónomos são implementados e geridos através do controlador NEG, mas as regras de encaminhamento, as verificações de funcionamento e outros objetos de balanceamento de carga são implementados manualmente.

Os NEGs autónomos não entram em conflito com o balanceamento de carga nativa do contentor ativado por entrada.

A ilustração seguinte mostra as diferenças na forma como os objetos de equilíbrio de carga são implementados em cada cenário:

Prevenção de NEGs com fugas de informação

Com os NEGs autónomos, é responsável por gerir os ciclos de vida dos NEGs e os recursos que compõem o equilibrador de carga. Pode divulgar NEGs das seguintes formas:

• Quando um serviço do GKE é eliminado, o NEG associado não é recolhido como lixo se o NEG ainda for referenciado por um serviço de back-end. Desreferencie o NEG do serviço de back-end para permitir a eliminação do NEG.

• Quando um cluster é eliminado, os NEGs autónomos não são eliminados nos seguintes cenários:

  • O NEG ainda é referenciado por um serviço de back-end.
  • O processo de eliminação do cluster desliga o controlador do NEG antes de o controlador poder eliminar o NEG.

  Para evitar NEGs com fugas, desreferencie o NEG do serviço de back-end e elimine todos os NEGs antes de eliminar o cluster.

Se tiver NEGs com fugas após eliminar o cluster ou o serviço, pode eliminar os NEGs através da CLI Google Cloud.

Exemplos de utilização de NEGs autónomos

Os NEGs autónomos têm várias utilizações críticas. Os NEGs autónomos são muito flexíveis. Isto contrasta com o Ingress (usado com ou sem NEGs), que define um conjunto específico de objetos de equilíbrio de carga que foram escolhidos de forma opinativa para os tornar fáceis de usar.

Os exemplos de utilização para NEGs autónomos incluem:

Serviços heterogéneos de contentores e VMs

Os NEGs podem conter endereços IP de VMs e de contentores. Isto significa que um único endereço IP virtual pode apontar para um back-end que consiste em cargas de trabalho do Kubernetes e não do Kubernetes. Também pode ser usado para migrar cargas de trabalho existentes para um cluster do GKE.

Os NEGs autónomos podem apontar para IPs de VMs, o que permite configurar manualmente os balanceadores de carga para apontarem para back-ends compostos por VMs e contentores para o mesmo VIP de serviço.

Controladores de entrada personalizados

Pode usar um controlador Ingress personalizado (ou nenhum controlador Ingress) para configurar balanceadores de carga que segmentam NEGs autónomos.

Use o Cloud Service Mesh com o GKE

Pode usar o Cloud Service Mesh com o GKE. O Cloud Service Mesh usa NEGs autónomos para fornecer balanceamento de carga nativo de contentores para a malha de serviços gerida.

Use balanceadores de carga de rede de proxy externos com o GKE

Pode usar NEGs autónomos para equilibrar a carga diretamente para contentores com o equilibrador de carga de rede de proxy externo, que não é suportado nativamente pelo Kubernetes/GKE.

Disposição do agrupamento

Os gates de preparação são uma funcionalidade de extensibilidade do Kubernetes que permite a injeção de feedback ou sinais adicionais no PodStatus para permitir que o pod faça a transição para o estado pronto. O controlador do NEG gere um gateway de disponibilidade personalizado para garantir que o caminho de rede completo do equilibrador de carga do Compute Engine para o pod está funcional. Os gates de prontidão dos pods no GKE são explicados no balanceamento de carga nativa do contentor.

A entrada com NEGs implementa e gere verificações de funcionamento do Compute Engine em nome do balanceador de carga. No entanto, os NEGs autónomos não fazem suposições sobre as verificações de funcionamento do Compute Engine, uma vez que se espera que sejam implementados e geridos separadamente. As verificações de estado do Compute Engine devem ser sempre configuradas juntamente com o equilibrador de carga para impedir o envio de tráfego para back-ends que não estão prontos para receber. Se não existir um estado de verificação de saúde associado ao NEG (normalmente, porque não está configurada nenhuma verificação de saúde), o controlador do NEG marca o valor do portão de disponibilidade do pod como verdadeiro quando o respetivo ponto final é programado no NEG.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

• Certifique-se de que tem um cluster nativo da VPC existente. O seu cluster tem de ter o suplemento HttpLoadBalancing ativado. Os novos clusters do GKE têm o suplemento HttpLoadBalancing ativado por predefinição.

  Para criar um novo cluster padrão, consulte o artigo Crie um cluster nativo da VPC. Por predefinição, os clusters do Autopilot são nativos de VPC.

Usar NEGs autónomos

As instruções seguintes mostram como usar NEGs autónomos com um equilibrador de carga HTTP externo no GKE.

Tem de criar os seguintes objetos:

• Uma Implementação que cria e gere pods.
• Um serviço que cria um NEG.
• Um balanceador de carga criado com a API Compute Engine. Isto difere da utilização de NEGs com o Ingress, em que o Ingress cria e configura um equilibrador de carga para si. Com os NEGs autónomos, é responsável por associar o NEG e o serviço de back-end para ligar os pods ao equilibrador de carga. O balanceador de carga é composto por vários componentes, apresentados no diagrama seguinte:

Crie uma implementação

Os manifestos de exemplo seguintes especificam implementações que executam três instâncias de um servidor HTTP em contentor. O servidor HTTP responde aos pedidos com o nome do anfitrião do servidor de aplicações, o nome do pod no qual o servidor está a ser executado.

Recomendamos que use cargas de trabalho que usem feedback de disponibilidade de pods.

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
  

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
  

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

kubectl apply -f neg-demo-app.yaml

Crie um serviço

O manifesto seguinte especifica um serviço em que:

• Qualquer Pod com a etiqueta run: neg-demo-app é membro deste 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 vai ser associada a um NEG. O campo name opcional especifica que o NEG vai ter o nome NEG_NAME. Se o campo name for omitido, é gerado automaticamente um nome exclusivo. Consulte o artigo Atribuir nomes a NEGs para ver detalhes.
• Cada pod de membro tem de ter um contentor que esteja a ouvir 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 GNE. O nome do GNE tem de ser exclusivo na respetiva região.

Guarde 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

É criado um NEG alguns minutos após a criação do serviço.

Tipos de serviços

Embora este exemplo use um serviço ClusterIP, todos os cinco tipos de serviços suportam NEGs autónomos. Recomendamos o tipo predefinido, ClusterIP.

Atribuir nomes a NEGs

Nas versões 1.18.18-gke.1200 e posteriores do GKE, pode especificar um nome personalizado para os NEGs ou o GKE pode gerar um nome automaticamente. As versões anteriores do GKE só suportam nomes de NEG gerados automaticamente.

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

Especificar um nome

A especificação de um nome de NEG personalizado simplifica a configuração do balanceador de carga porque conhece o nome e as zonas dos NEGs antecipadamente. Os nomes dos GNEs personalizados têm de cumprir os seguintes requisitos:

• Têm de ser exclusivos da zona do cluster para clusters zonais ou exclusivos da região para clusters regionais.

• Não pode corresponder ao nome de nenhum NEG existente 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 GNE. O nome do GNE tem de ser exclusivo na respetiva região.

Usar um nome gerado automaticamente

Os nomes dos GNEs gerados automaticamente são garantidamente exclusivos. 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

Mapeamento de portas para vários NEGs

Um serviço pode ouvir em mais do que uma porta. Por definição, os NEGs têm apenas um endereço IP e uma porta. Isto significa que, se especificar um serviço com várias portas, é criado 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 existentes do serviço. Para cada porta de serviço listada, o controlador do NEG cria um NEG em cada zona que o cluster ocupa.

Obtenha os estados NEG

Use o seguinte comando para obter os estados dos serviços do cluster:

kubectl get service neg-demo-svc -o yaml

O resultado é semelhante ao seguinte:

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", ...]
}

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

O resultado é semelhante ao seguinte:

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 a NEGs com o nome k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

Valide a criação do NEG

É criado um NEG alguns minutos após a criação do serviço. Se existirem pods que correspondam à etiqueta especificada no manifesto do serviço, após a criação, o NEG vai conter os IPs dos pods.

Existem duas formas de verificar se o NEG foi criado e está configurado corretamente. No GKE 1.18.6-gke.6400 e posterior, um recurso personalizado ServiceNetworkEndpointGroup armazena informações de estado sobre NEGs criados pelo controlador de serviços. Nas versões anteriores, tem de inspecionar os NEGs diretamente.

O recurso ServiceNetworkEndpointGroup

Liste os NEGs num cluster obtendo todos os recursos ServiceNetworkEndpointGroup:

kubectl get svcneg

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

kubectl get svcneg NEG_NAME -o yaml

Substitua NEG_NAME pelo nome do NEG individual que quer inspecionar.

O resultado deste comando inclui uma secção de estado que pode conter mensagens de erro. Alguns erros são comunicados como um evento de serviço. Pode encontrar mais detalhes consultando o objeto Service:

kubectl describe service SERVICE_NAME

Substitua SERVICE_NAME pelo nome do serviço relevante.

Para verificar se o controlador do NEG está a sincronizar o NEG com êxito, verifique o campo de estado 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 na versão 1.18 e posteriores do GKE.

Inspeção direta de NEGs

Verifique se o NEG existe listando os NEGs no seu projeto e procurando um NEG que corresponda ao serviço que criou. Trusted CloudO nome do NEG tem o seguinte formato:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Use o seguinte comando para apresentar uma lista de NEGs:

gcloud compute network-endpoint-groups list

O resultado é semelhante ao seguinte:

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

Esta saída mostra que o SIZE do NEG é 3, o que significa que tem três pontos finais que correspondem aos três pods na implementação.

Identifique os pontos finais individuais com o seguinte comando:

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

Substitua NEG_NAME pelo nome do NEG para o qual quer apresentar os pontos finais individuais.

O resultado mostra três pontos finais, cada um com 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

Anexar um balanceador de carga de aplicações externo a NEGs autónomos

Pode usar NEGs como um back-end para um balanceador de carga de aplicações externo através da API Compute Engine.

1. Crie uma regra de firewall. Os equilibradores de carga têm de aceder aos pontos finais do cluster para realizar verificações de estado. 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 o seguinte:

   • NETWORK_NAME: a rede onde o cluster é executado.
   • GKE_NODE_NETWORK_TAGS: as etiquetas de rede nos nós do GKE.

   Se não criou etiquetas de rede personalizadas para os seus nós, o GKE gera automaticamente etiquetas para si. Pode procurar estas tags geradas executando o seguinte comando:

   gcloud compute instances describe INSTANCE_NAME
   

   Substitua INSTANCE_NAME pelo nome do anfitrião da instância de VM do Compute Engine que executa o nó do GKE. Por exemplo, a saída na secção anterior apresenta os nomes das instâncias na coluna INSTANCE para os nós do GKE.

   Para clusters padrão, também pode executar gcloud compute instances list para listar todas as instâncias no seu 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 funcionamento. Isto é usado pelo equilibrador de carga para detetar a atividade dos pontos finais 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 se trata de um Application Load Balancer 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. Este exemplo é muito simples porque a app serve_hostname usada para este guia tem um único ponto final e não inclui 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. É isto 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 usar para o equilibrador de carga. Se omitir --address, o GKE atribui automaticamente um endereço IP efémero.

   Também pode reservar um novo endereço IP externo estático.

Posto de controlo

Estes são os recursos que 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 URLs da verificação de estado do Compute Engine
• O serviço de back-end
• A verificação de funcionamento do Compute Engine

A relação entre estes recursos é apresentada no diagrama seguinte:

Estes recursos em conjunto formam um equilibrador de carga. No passo seguinte, vai adicionar servidores de back-end ao equilibrador de carga.

Uma das vantagens dos NEGs autónomos demonstradas aqui é que os ciclos de vida do balanceador de carga e do back-end podem ser completamente independentes. O balanceador de carga pode continuar a ser executado após a eliminação da aplicação, dos respetivos serviços ou do cluster do GKE. Pode adicionar e remover novos NEGs ou vários NEGs do equilibrador de carga sem alterar nenhum dos objetos do equilibrador de carga de front-end.

Adicione back-ends ao balanceador de carga

Use gcloud compute backend-services add-backend para associar o NEG ao balanceador de carga adicionando-o como 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 o seguinte:

• NEG_NAME: o nome do grupo de pontos finais da rede. O nome é o nome que especificou quando criou o NEG ou um nome gerado automaticamente. Se 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 seu grupo de pontos finais de rede se encontra. Consulte as instruções seguintes para encontrar este valor.

Use este comando para obter o nome e a localização do NEG:

gcloud compute network-endpoint-groups list

O resultado é semelhante ao seguinte:

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

Neste exemplo de resultado, o nome do GAE é k8s1-70aa83a6-default-my-service-80-c9710a6f.

É possível adicionar vários NEGs ao mesmo serviço de back-end. Os serviços de back-end globais, como my-bes, podem ter back-ends de NEG em diferentes regiões, enquanto os serviços de back-end regionais têm de ter back-ends numa única região.

Valide se o equilibrador de carga funciona

Existem duas formas de validar se o balanceador de carga que configurou está a funcionar:

• Verifique se a verificação de funcionamento está configurada corretamente e a indicar um estado de funcionamento.
• Aceda à aplicação e valide a respetiva resposta.

Valide as verificações de funcionamento

Verifique se o serviço de back-end está associado à verificação de estado e aos grupos de pontos finais da rede, e se os pontos finais individuais estão em bom estado.

Use este comando para verificar se o serviço de back-end está associado à sua verificação de estado e ao seu grupo de pontos finais de rede:

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

O resultado é semelhante ao seguinte:

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 o estado dos pontos finais individuais:

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

A secção status: do resultado é 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

Aceda à aplicação

Aceda à aplicação através do endereço IP do equilibrador de carga para confirmar que tudo está a funcionar.

Primeiro, obtenha o endereço IP virtual do equilibrador de carga:

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

O resultado inclui um endereço IP. Em seguida, envie um pedido para esse endereço IP (34.98.102.37 neste exemplo):

curl 34.98.102.37

A resposta da app serve_hostname deve ser neg-demo-app.

Anexar um balanceador de carga de aplicações interno a NEGs autónomos

Pode usar NEGs para configurar um Application Load Balancer interno para os seus serviços em execução em pods do GKE autónomos.

Configurar a sub-rede só de proxy

A sub-rede apenas de proxy destina-se a todos os Application Load Balancers internos regionais na região do balanceador de carga.

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

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"
}

Configurar regras de firewall

Este exemplo usa as seguintes regras de firewall:

• fw-allow-ssh: Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite a conetividade SSH de entrada na porta TCP 22 a partir de qualquer endereço. Pode escolher um intervalo de IPs de origem mais restritivo para esta regra. Por exemplo, pode especificar apenas os intervalos de IP do sistema a partir do qual inicia sessões SSH. Este exemplo usa a etiqueta 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 permite todo o tráfego TCP dos sistemas de verificação de estado (em 130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a etiqueta de destino load-balanced-backend para identificar as instâncias às quais deve ser aplicada. Trusted Cloud

• fw-allow-proxies: Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite o tráfego TCP na porta 9376 dos proxies geridos do balanceador de carga de HTTP(S) interno. Este exemplo usa a etiqueta de destino load-balanced-backend para identificar as instâncias às quais deve aplicar-se.

Sem estas regras de firewall, a regra de negação predefinida de entrada bloqueia o tráfego de entrada para as instâncias de back-end.

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"
}

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"
}

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"
}

Configurar o balanceador de carga

Para o endereço IP da regra de encaminhamento, use uma sub-rede de back-end. Se tentar usar a sub-rede só de proxy, a criação da regra de encaminhamento falha.

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"
   }
}

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"
}

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"
}

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"
}

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",
}

Testes

Crie uma instância de VM na zona para testar a conetividade:

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

Inicie sessão na instância do cliente para verificar se os serviços HTTP(S) nos back-ends são acessíveis através do endereço IP da regra de encaminhamento do Application Load Balancer interno e se o tráfego está a ser balanceado de carga entre os pontos finais no NEG.

Ligue-se a cada instância do cliente através de SSH:

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

Verifique se o IP está a publicar o respetivo nome de anfitrião:

curl 10.1.2.199

Para testar o 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 flag -k faz com que curl ignore a validação de certificados.

Execute 100 pedidos e confirme que têm equilíbrio de carga.

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
}

Anexe um balanceador de carga de rede de proxy externo a NEGs autónomos

Pode usar NEGs autónomos para equilibrar a carga diretamente para contentores com o equilibrador de carga de rede de proxy externo, que não é suportado nativamente pelo Kubernetes nem pelo GKE. Os balanceadores de carga de rede de proxy destinam-se apenas ao tráfego TCP, com ou sem SSL. Para tráfego HTTP(S), recomendamos que use um Application Load Balancer.

1. Crie uma regra de firewall para permitir verificações de funcionamento.

   Os balanceadores de carga têm de aceder aos pontos finais do cluster para realizar verificações de estado. O comando seguinte cria uma regra de firewall para permitir o acesso:

   gcloud compute firewall-rules create allow-tcp-lb-and-health \
      --network=NETWORK_NAME \
      --target-tags=GKE_NODE_NETWORK_TAGS \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --allow tcp:9376
   

   Substitua o seguinte:

   • NETWORK_NAME: a rede onde o cluster é executado.
   • GKE_NODE_NETWORK_TAGS: as etiquetas de rede nos nós do GKE.

   Se não criou etiquetas de rede personalizadas para os seus nós, o GKE gera automaticamente etiquetas para si. Pode procurar estas tags geradas executando o seguinte comando:

   gcloud compute instances describe INSTANCE_NAME
   

   Substitua INSTANCE_NAME pelo nome do anfitrião da instância de VM do Compute Engine que executa o nó do GKE. Por exemplo, a saída na secção Inspeção direta de NEGs apresenta os nomes das instâncias na coluna INSTANCE para os nós do GKE.

   Para clusters padrão, também pode executar o comando gcloud compute instances list para listar todas as instâncias no seu projeto.

   Para clusters do Autopilot, segmente a conta de serviço do cluster em vez das etiquetas de rede.

   Substituir a flag --target-tags=GKE_NODE_NETWORK_TAGS por --target-service-accounts=SERVICE_ACCOUNT_EMAIL. Recomendamos que use uma conta de serviço com privilégios mínimos personalizada para o cluster.

2. Crie um endereço IP virtual global para o balanceador de carga:

   gcloud compute addresses create tcp-lb-static-ipv4 \
      --ip-version=IPV4 \
      --global
   

3. Defina uma verificação de funcionamento para os pontos finais do back-end.

   O balanceador de carga usa verificações de funcionamento para detetar a atividade de pontos finais individuais no NEG.

   gcloud compute health-checks create tcp my-tcp-health-check \
      --use-serving-port
   

4. Crie um serviço de back-end com afinidade de sessão.

   Este serviço de back-end especifica que este é um balanceador de carga de rede de proxy externo com CLIENT_IP afinidade de sessão:

   gcloud compute backend-services create my-tcp-lb \
      --load-balancing-scheme EXTERNAL_MANAGED \
      --global-health-checks \
      --global \
      --protocol TCP \
      --health-checks my-tcp-health-check \
      --timeout 5m \
      --session-affinity=CLIENT_IP
   

5. Crie um proxy TCP de destino para o balanceador de carga.

   Se quiser ativar o cabeçalho do proxy, defina-o como PROXY_V1 em vez de NONE.

   gcloud beta compute target-tcp-proxies create my-tcp-lb-target-proxy \
       --backend-service my-tcp-lb \
       --proxy-header NONE
   

6. Crie uma regra de encaminhamento para encaminhar o tráfego.

   Esta regra de encaminhamento cria o balanceador de carga.

    gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
       --load-balancing-scheme EXTERNAL_MANAGED \
       --global \
       --target-tcp-proxy my-tcp-lb-target-proxy \
       --address tcp-lb-static-ipv4 \
       --ports 80
   

Valide a criação de recursos do balanceador de carga

Criou os seguintes recursos:

• Um endereço IP virtual externo
• A regra de encaminhamento
• A regra de firewall
• O proxy de destino
• O serviço de back-end
• A verificação de funcionamento do Compute Engine

O endereço IP virtual externo está ligado à regra de encaminhamento, que direciona o tráfego permitido pela regra de firewall para o proxy de destino. O proxy de destino comunica então com o serviço de back-end, que é verificado periodicamente pela verificação de estado. A relação entre estes recursos é apresentada no diagrama seguinte:

Estes recursos em conjunto formam um equilibrador de carga. No passo seguinte, vai adicionar back-ends ao equilibrador de carga.

Uma das vantagens dos NEGs autónomos 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 a ser executado após a eliminação da aplicação, dos respetivos serviços ou do cluster do GKE. Pode adicionar e remover novos NEGs ou vários NEGs do equilibrador de carga sem alterar nenhum dos objetos do equilibrador de carga de front-end.

Adicione NEGs autónomos como back-ends ao balanceador de carga

Use gcloud compute backend-services add-backend para ligar o NEG ao balanceador de carga adicionando-o como back-end do serviço de back-end my-tcp-lb:

gcloud compute backend-services add-backend my-tcp-lb \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode CONNECTION \
    --max-connections 100

Substitua o seguinte:

• NEG_NAME: o nome do grupo de pontos finais da rede. O nome é o nome que especificou quando criou o NEG ou um nome gerado automaticamente. Se 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 seu grupo de pontos finais de rede se encontra. Consulte as instruções seguintes para encontrar este valor.

Para obter o nome e a localização dos GNEs, use este comando:

gcloud compute network-endpoint-groups list

O resultado é semelhante ao seguinte:

NAME: k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
LOCATION: us-central1-a
ENDPOINT_TYPE: GCE_VM_IP_PORT
SIZE: 3

Neste exemplo de saída, o nome do NEG é kk8s1-65a95e90-default-neg-demo-svc-80-663a85e4 e a zona é us-central1-a.

É possível adicionar vários NEGs ao mesmo serviço de back-end. Os serviços de back-end globais, como my-tcp-lb, podem ter back-ends NEG em diferentes regiões, enquanto os serviços de back-end regionais têm de ter back-ends numa única região.

Valide a configuração e a conetividade do balanceador de carga

Existem duas formas de validar se o balanceador de carga que configurou está a funcionar:

• Verifique se a verificação de funcionamento está configurada corretamente e se está a comunicar como em bom estado.
• Aceda à aplicação e valide a respetiva resposta.

Valide as verificações de funcionamento

Verifique se o serviço de back-end está associado à verificação de estado e aos grupos de pontos finais da rede, e se os pontos finais individuais estão em bom estado.

Para verificar se o serviço de back-end está associado à verificação de estado e ao grupo de pontos finais de rede, use este comando:

gcloud compute backend-services describe my-tcp-lb --global

O resultado é semelhante ao seguinte:

backends:
- balancingMode: CONNECTION
  group: ... /networkEndpointGroups/k8s1-65a95e90-default-neg-demo-svc-80-663a85e4
  maxConnections: 100
...
healthChecks:
- ... /healthChecks/my-tcp-health-check
...
name: my-tcp-lb
...

Em seguida, verifique o estado dos pontos finais individuais:

gcloud compute backend-services get-health my-tcp-lb --global

A secção status: do resultado é 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

Valide a conetividade da aplicação

Para verificar se o balanceador de carga está a funcionar corretamente, aceda à aplicação através do endereço IP externo do balanceador de carga.

1. Obtenha o endereço IP externo do balanceador de carga:

   Para obter o endereço IP externo que reservou para o balanceador de carga, use o seguinte comando:

   gcloud compute addresses describe tcp-lb-static-ipv4 --global | grep "address:"
   

   Este comando produz o endereço IP.

2. Enviar um pedido para o endereço IP:

   Use o comando curl para enviar um pedido para o endereço IP externo.

   curl EXTERNAL_IP_ADDRESS
   

   Substitua EXTERNAL_IP_ADDRESS pelo endereço IP que obteve no passo anterior:

   A resposta da aplicação serve_hostname deve começar com neg-demo-app.

Implementação de serviços heterogéneos (VMs e contentores)

Os balanceadores de carga podem ser front-ends para cargas de trabalho mistas do Kubernetes e não do Kubernetes. Isto pode fazer parte de uma migração de VMs para contentores ou de uma arquitetura permanente que beneficia de um equilibrador de carga partilhado. Isto pode ser conseguido através da criação de balanceadores de carga que segmentam diferentes tipos de back-ends, incluindo NEGs autónomos.

VMs e contentores no mesmo serviço de back-end

Este exemplo mostra como criar um NEG que aponta para uma VM existente que executa uma carga de trabalho e como adicionar este NEG como outro back-end de um backendService existente. Desta forma, um único balanceador de carga equilibra entre VMs e contentores do GKE.

Estes exemplos expandem o exemplo anterior que usa um balanceador de carga de HTTP externo.

Uma vez que todos os pontos finais estão agrupados pelo mesmo backendService, os pontos finais da VM e do contentor são considerados o mesmo serviço. Isto significa que a correspondência de anfitriões ou caminhos trata todos os back-ends de forma idêntica com base nas regras do mapa de URLs.

Quando usa um NEG como back-end para um serviço de back-end, todos os outros back-ends nesse serviço de back-end também têm de ser NEGs. Não pode usar grupos de instâncias e NEGs como back-ends no mesmo serviço de back-end. Além disso, os contentores e as VMs não podem existir como pontos finais no mesmo NEG, pelo que têm de ser sempre configurados com NEGs separados.

1. Implemente uma VM no Compute Engine com este 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 o seguinte:

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

2. Implemente uma aplicação 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"
   

   Este comando implementa na VM a mesma aplicação de exemplo usada no exemplo anterior. Para simplificar, a aplicação é executada como um contentor do Docker, mas isto não é essencial. O comando iptables é necessário para permitir o acesso da firewall ao contentor em execução.

3. Valide se a aplicação está a ser publicada na porta 9376 e a comunicar que está a ser executada em vm1:

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

   O servidor deve responder com vm1.

4. Crie um NEG para usar com o ponto final da VM. Os contentores e as VMs podem ser pontos finais de NEG, mas um único NEG não pode ter pontos finais de VM e de contentor.

   gcloud compute network-endpoint-groups create vm-neg \
       --subnet=SUBNET \
       --zone=COMPUTE_ZONE
   

5. Anexe o ponto final 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 que o NEG tem o ponto final da VM:

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
       --zone COMPUTE_ZONE
   

7. Associe o NEG ao serviço de back-end através do mesmo comando que usou para adicionar um back-end de contentor:

   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 a firewall para permitir a verificação de funcionamento 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. Valide se o equilibrador de carga está a encaminhar tráfego para o novo back-end vm1 e o back-end de contentor existente enviando tráfego de teste:

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

   Deve ver respostas dos pontos finais do contentor (neg-demo-app) e da VM (vm1).

VMs e contentores para diferentes serviços de back-end

Este exemplo mostra como criar um NEG que aponta para uma VM existente que executa uma carga de trabalho e como adicionar este NEG como o back-end a um novo backendService. Isto é útil quando os contentores e as VMs são serviços diferentes, mas precisam de partilhar o mesmo equilibrador de carga de camada 7, por exemplo, se os serviços partilharem o mesmo endereço IP ou nome de domínio.

Estes exemplos expandem o exemplo anterior que tem um back-end de VM no mesmo serviço de back-end que o back-end de contentor. Este exemplo reutiliza essa VM.

Uma vez que os pontos finais do contentor e da VM estão agrupados em serviços de back-end separados, são considerados serviços diferentes. Isto significa que o mapa de URLs vai corresponder aos back-ends e direcionar o tráfego para a VM ou o contentor com base no nome do anfitrião.

O diagrama seguinte mostra como um único endereço IP virtual corresponde a dois nomes de anfitrião, que, por sua vez, correspondem a um serviço de back-end baseado em contentores e a um serviço de back-end baseado em VMs.

O diagrama seguinte mostra a arquitetura descrita na secção anterior:

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 para a 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 anfitrião ao mapa de URLs para direcionar pedidos para o anfitrião container.example.com para o serviço de back-end do contentor:

   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 anfitrião ao mapa de URLs para direcionar pedidos para vm.example.com host para o 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 pedido:

   curl -H "HOST:vm.example.com" VIRTUAL_IP
   

   Substitua VIRTUAL_IP pela morada IP virtual.

Limitações dos NEGs autónomos

• Os erros de validação de anotações são expostos ao utilizador através de eventos do Kubernetes.
• As limitações dos NEGs também se aplicam aos NEGs autónomos.
• Os NEGs autónomos não funcionam com redes antigas.
• Os NEGs autónomos só podem ser usados com serviços de rede compatíveis, incluindo a Cloud Service Mesh e os tipos de equilibradores de carga compatíveis.

Resolução de problemas

Esta secção fornece passos de resolução de problemas comuns que pode encontrar com os NEGs autónomos.

Nenhum NEG autónomo configurado

Sintoma: não é criado nenhum NEG.

Potencial resolução:

• Verifique os eventos associados ao serviço e procure mensagens de erro.
• Verifique se a anotação NEG autónoma é um JSON com formato correto e se as portas expostas correspondem às portas existentes na especificação do serviço.
• Verifique a anotação do estado do 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 a usar a versão 1.18 ou posterior do GKE, verifique se o recurso svcneg para o serviço existe. Se sim, verifique a condição Initialized para obter informações sobre erros.
• Se estiver a usar nomes de NEG personalizados, certifique-se de que cada nome de NEG é único na respetiva região.

O tráfego não chega aos pontos finais

Sintoma: erros 502 ou ligações rejeitadas.

Potencial resolução:

• Depois de o serviço ser configurado, os novos pontos finais tornam-se geralmente acessíveis depois de os associar ao NEG, desde que respondam às verificações de estado.
• Se, após este período, o tráfego continuar a não conseguir alcançar os pontos finais, o que resulta no código de erro 502 para HTTP(S) ou na rejeição de ligações para equilibradores de carga TCP/SSL, verifique o seguinte:
  • Verifique se as regras de firewall permitem o tráfego TCP de entrada para os seus pontos finais a partir dos seguintes intervalos: 130.211.0.0/22 e 35.191.0.0/16.
  • Verifique se os seus pontos finais estão em bom estado através da CLI Google Cloud ou chamando a API getHealth no backendService ou a API listEndpoints no NEG com o parâmetro showHealth definido como SHOW.

Implementação interrompida

Sintoma: a implementação de uma implementação atualizada fica bloqueada e o número de réplicas atualizadas não corresponde ao número de réplicas escolhido.

Potencial resolução:

As verificações de funcionamento da implementação estão a falhar. A imagem do contentor pode estar danificada ou a verificação de estado pode estar mal configurada. A substituição progressiva de pods aguarda até que o pod iniciado recentemente passe o respetivo portão de prontidão. Isto só ocorre se o pod estiver a responder às verificações de funcionamento do balanceador de carga. Se o pod não responder ou se a verificação de funcionamento estiver configurada incorretamente, as condições do Readiness Gate não podem ser cumpridas e a implementação não pode continuar.

• Se estiver a usar o kubectl 1.13 ou superior, pode verificar o estado das readiness gates 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 inferior. Um pod marcado como estando no estado READY pode ter um readiness gate com falhas. Para validar esta ação, use o seguinte comando:

  kubectl get my-pod -o yaml
  

  As portas de prontidão e o respetivo estado são apresentados no resultado.

• Verifique se a imagem do contentor na especificação do pod da sua implementação está a funcionar corretamente e se consegue responder às verificações de estado.

• Verifique se as verificações de funcionamento estão configuradas corretamente.

O NEG não é recolhido como lixo

Sintoma: um GNE que devia ter sido eliminado ainda existe.

Potencial resolução:

• O NEG não é recolhido como lixo se for referenciado por um serviço de back-end. Consulte o artigo Impedir a fuga de NEGs para ver detalhes.
• Se estiver a usar a versão 1.18 ou posterior, pode verificar a existência de eventos no recurso ServiceNetworkEndpointGroup através do procedimento de negociação do serviço.
• Verifique se o NEG ainda é necessário para um serviço. Verifique o recurso do serviço que corresponde ao NEG e verifique se existe uma anotação de serviço.svcneg

O NEG não está sincronizado com o serviço

Sintoma: os pontos finais 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

Potencial resolução:

Se estiver a usar o GKE 1.18 ou posterior, consulte o recurso svcneg para obter informações:

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

Se estiver a usar o GKE 1.19.9 ou posterior, verifique se existe um NEG cujo nome e zona correspondam ao nome e à zona do NEG que o controlador do NEG do GKE precisa de criar. Por exemplo, um NEG com o nome que o controlador do NEG tem de usar pode ter sido criado com a CLI gcloud ou a Trusted Cloud consola na zona do cluster (ou numa das zonas do cluster). Neste caso, tem de eliminar o NEG existente antes de o controlador NEG poder sincronizar os respetivos pontos finais. A criação e a associação de NEG autónomos foram concebidas para serem geridas pelo controlador de NEG.

O que se segue?

• Vista geral dos grupos de pontos finais de rede zonais
• Serviços de back-end
• Criar verificações de saúde
• Usar proxies de destino
• Usar regras de encaminhamento