Como usar balanceamento de carga nativo de contêiner

Nesta página, você verá como usar o balanceamento de carga nativo de contêiner no Google Kubernetes Engine.

Visão geral

O balanceamento de carga nativo de contêiner permite que os balanceadores de carga HTTP(S) sejam direcionados para os pods e distribuam uniformemente o tráfego para eles.

Esse balanceamento de carga nativo de contêiner aproveita um modelo de dados denominado grupos de endpoints da rede (NEGs, na sigla em inglês), que são coleções de endpoints de rede representados por pares de portas IP.

Vantagens

O balanceamento de carga nativo de contêiner oferece os seguintes benefícios:

Os pods têm prioridade no balanceamento de carga
O
kube-proxy (em inglês) configura as regras dos nós iptables para distribuir tráfego para os pods. Sem balanceamento de carga nativo de contêiner, o tráfego do balanceador de carga viaja para os grupos de instâncias do nó e é roteado por meio de regras iptables para pods que podem ou não estar no mesmo nó. Com o balanceamento de carga nativo de contêiner, o tráfego do balanceador de carga é distribuído diretamente para os pods destinados a recebê-lo, eliminando o salto extra de rede. O balanceamento de carga nativo de contêiner também ajuda a melhorar a verificação de integridade, visto que é direcionado para os pods.

Diagrama comparando o comportamento padrão (à esquerda) com o comportamento do balanceador de carga nativo de contêiner.
Melhor desempenho de rede
Como o balanceador de carga nativo de contêiner se comunica diretamente com os pods e as conexões têm menos saltos de rede, a latência e a capacidade são aprimoradas.
Maior visibilidade
Você tem visibilidade do tempo de retorno (RTT, na sigla em inglês) do cliente para o balanceador de carga HTTP(S), incluindo a compatibilidade com a IU do Stackdriver. Isso facilita a solução de problemas dos serviços no nível de NEG.
Suporte para recursos de balanceamento de carga HTTP(S)
O balanceamento de carga nativo de contêiner oferece suporte nativo no Google Kubernetes Engine para vários atributos de balanceamento de carga HTTP(S), como a integração com os serviços do GCP, por exemplo, Google Cloud Armor, Cloud CDN e Identity-Aware Proxy. Outro atributo são os algoritmos de balanceamento de carga para distribuição de tráfego precisa.
Suporte para o Traffic Director
O modelo de dados NEG é necessário para usar o Traffic Director, o plano de controle de tráfego totalmente gerenciado do Google Cloud para a malha serviço.

Prontidão do pod

Para os pods relevantes, o controlador de Ingress correspondente gerencia um portão de prontidão (em inglês) do tipo cloud.google.com/load-balancer-neg-ready. O controlador de Ingress pesquisa o status de verificação de integridade do balanceador de carga, que inclui a integridade de todos os endpoints no NEG. Ao indicar que o endpoint correspondente a um pod específico está íntegro, o controlador de Ingress define o valor do portão de prontidão do pod como True. O kubelet em execução em cada nó calcula então a prontidão efetiva do pod, considerando o valor deste portão de prontidão e, se definida, a sondagem de prontidão (em inglês) do pod.

Para balanceamento de carga nativo de contêiner, os portões de prontidão do pod são ativados automaticamente em:

  • Clusters GKE v1.13 executando a v1.13.8 e superior
  • Clusters GKE v1.14 executando a v1.14.4 e superior

Os portões de prontidão controlam a taxa de uma atualização gradual. As versões do GKE listadas acima adicionam portões de prontidão aos pods automaticamente. Ao iniciar uma atualização gradual, conforme o GKE cria novos pods, um endpoint para cada novo pod é adicionado a um NEG. Quando o endpoint estiver íntegro na perspectiva do balanceador de carga, o controlador de Ingress definirá o portão de prontidão como True. Assim, um pod recém-criado precisa passar, pelo menos, seu portão de prontidão antes do GKE remover um pod antigo. Isso garante que o endpoint correspondente do pod já tenha passado pela verificação de integridade do balanceador de carga e que a capacidade do back-end seja mantida.

Se o portão de prontidão de um pod não indicar que ele está pronto devido a uma imagem ruim do contêiner ou uma verificação de integridade do balanceador de carga configurada incorretamente, o balanceador de carga não vai direcionar tráfego para o novo pod. Se isso ocorrer durante o lançamento de uma implantação atualizada, o lançamento será interrompido após tentar criar um novo pod porque o portão de prontidão desse pod nunca será "True". Veja a seção de solução de problemas (em inglês) para mais informações sobre como detectar e corrigir esta situação.

Sem portões de prontidão e balanceamento de carga nativos de contêiner, o GKE não consegue detectar se os endpoints de um balanceador de carga estão íntegros antes de marcar os pods como prontos. Nas versões anteriores do Kubernetes, você controla a taxa de remoção e de substituição dos pods, especificando um período de atraso (minReadySeconds na especificação de implantação).

Requisitos

Os balanceadores de carga nativos de contêiner no Google Kubernetes Engine têm os seguintes requisitos:

Google Kubernetes Engine v1.13.8 ou v1.14.4

Os balanceadores de carga nativos de contêiner estão geralmente disponíveis em:

  • Clusters GKE v1.13 executando a v1.13.8 e superior
  • Clusters GKE v1.14 executando a v1.14.4 e superior
Cluster nativo de VPC

Para usar o balanceamento de carga nativo de contêiner, os clusters precisam ser nativos de VPC. Para saber mais, consulte Como criar clusters nativos de VPC usando IPs de alias.

Balanceamento de carga HTTP

Para usar o balanceamento de carga nativo do contêiner, o cluster precisa ter o balanceamento de carga HTTP ativado. Os clusters do GKE têm o balanceamento de carga HTTP ativado por padrão. Não o desative.

Restrições

Balanceadores de carga nativos de contêiner não funcionam com redes legadas.

Limitações

Os balanceadores de carga nativos de contêiner não aceitam balanceadores de carga internos ou de rede.

Preços

Você é cobrado pelo balanceador de carga HTTP(S) provisionado pelo Ingress criado neste guia. Para informações sobre preços do balanceador de carga, consulte as Regras de encaminhamento e balanceamento de carga na página de preços do Compute Engine.

Como usar balanceamento de carga nativo de contêiner

Nas seções a seguir, veja instruções de configuração de balanceamento de carga nativo de contêiner no Google Kubernetes Engine.

Como criar um cluster nativo de VPC

Para usar balanceamento de carga nativo de contêiner, é preciso criar um cluster com IPs de alias ativados.

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

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

Como criar uma implantação

Em seguida, implante uma carga de trabalho no cluster.

O exemplo de implantação a seguir, neg-demo-app, executa uma única instância de um servidor HTTP em contêiner. Recomenda-se o uso de cargas de trabalho que utilizem o feedback de prontidão do pod. Veja a seção de prontidão do pod acima para mais informações e requisitos de versão GKE.

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:
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname # Container name
  

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
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname # Container name
      # Note: The following line is necessary only on clusters running GKE v1.11 and lower.
      # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts
      terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
  

Nesta implantação, cada contêiner executa um servidor HTTP. O servidor HTTP retorna o nome do host do servidor de aplicativos (nome do pod em que o servidor é executado) como uma resposta.

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

Como criar um serviço para um balanceador de carga nativo de contêiner

Depois de criar uma implantação, é preciso agrupar os pods correspondentes em um serviço (em inglês).

O exemplo de serviço a seguir, neg-demo-svc, é direcionado para a implantação de amostra criada na seção anterior:

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc # Name of Service
  annotations:
    cloud.google.com/neg: '{"ingress": true}' # Creates a NEG after an Ingress is created
spec: # Service's specification
  type: NodePort
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80 # Service's port
    protocol: TCP
    targetPort: 9376

A anotação do serviço, cloud.google.com/neg: '{"ingress": true}', ativa o balanceamento de carga nativo de contêiner. No entanto, o balanceador de carga não é criado até você criar um Ingress para o serviço.

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

Como criar um Ingress para o serviço

A entrada de amostra (em inglês) a seguir, neg-demo-ing, é direcionada para o serviço criado:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: neg-demo-ing
spec:
  backend:
    serviceName: neg-demo-svc # Name of the Service targeted by the Ingress
    servicePort: 80 # Should match the port used by the Service

Salve este manifesto como neg-demo-ing.yaml e, em seguida, crie a entrada executando o seguinte comando:

kubectl apply -f neg-demo-ing.yaml

Ao criar a entrada, um balanceador de carga HTTP(S) é criado no projeto e os NEGs são criados em cada zona em que o cluster é executado. Os endpoints no NEG e os do serviço são mantidos em sincronia.

Como verificar a entrada

Depois de implantar uma carga de trabalho, agrupar os respectivos pods em um serviço e criar uma entrada para o serviço, é preciso verificar se a entrada provisionou com sucesso o balanceador de carga nativo de contêiner.

Para recuperar o status da entrada, execute o seguinte comando:

kubectl describe ingress neg-demo-ing

Na saída do comando, procure os eventos ADD e CREATE:

Events:
Type     Reason   Age                From                     Message
----     ------   ----               ----                     -------
Normal   ADD      16m                loadbalancer-controller  default/neg-demo-ing
Normal   Service  4s                 loadbalancer-controller  default backend set to neg-demo-svc:32524
Normal   CREATE   2s                 loadbalancer-controller  ip: 192.0.2.0

Como testar a funcionalidade do balanceador de carga

Nas seções a seguir, explicaremos como testar a funcionalidade de um balanceador de carga nativo do contêiner.

Visite o endereço IP do Ingress

Aguarde alguns minutos para que o balanceador de carga HTTP(S) seja configurado.

É possível verificar se o balanceador de carga nativo do contêiner está funcionando acessando o endereço IP do Ingress.

Para conseguir o endereço IP da entrada, execute o seguinte comando:

kubectl get ingress neg-demo-ing

Na saída do comando, o endereço IP do Ingress é exibido na coluna ADDRESS. Visite o endereço IP em um navegador da Web.

Verificar status de integridade do serviço de back-end

Também é possível receber o status de integridade do serviço de back-end do balanceador de carga.

Primeiro, receba uma lista dos serviços de back-end em execução no projeto:

gcloud compute backend-services list

Cópia do nome do back-end que inclui o nome do serviço, como neg-demo-svc. Em seguida, receba o status de integridade do serviço de back-end:

gcloud compute backend-services get-health [BACKEND_SERVICE_NAME] --global

Como verificar a funcionalidade do Ingress

Outra maneira de testar se o balanceador de carga funciona conforme o esperado é dimensionar o exemplo de implantação. Para isso, basta enviar solicitações de teste para o Ingress e verificar se o número correto de réplicas responde.

O comando a seguir dimensiona a implantação neg-demo-app, aumentando-a de uma para duas instâncias:

kubectl scale deployment neg-demo-app --replicas 2

Aguarde alguns minutos até que a distribuição seja concluída. Para verificar se a distribuição foi concluída, execute o seguinte comando:

kubectl get deployment neg-demo-app

Na saída do comando, verifique se há duas réplicas disponíveis:

NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
neg-demo-app   2         2         2            2           26m

Em seguida, execute o seguinte comando para contar o número de respostas distintas provenientes do balanceador de carga:

for i in `seq 1 100`; do \
  curl --connect-timeout 1 -s [IP_ADDRESS] && echo; \
done  | sort | uniq -c

em que [IP_ADDRESS] é o endereço IP da entrada. É possível conseguir o endereço IP da entrada em kubectl describe ingress neg-demo-ing.

Na resposta ao comando, observe que o número de respostas distintas é igual ao número de réplicas, indicando que todos os pods de back-end estão disponibilizando tráfego:

44 neg-demo-app-7f7dfd7bc6-dcn95
56 neg-demo-app-7f7dfd7bc6-jrmzf

Limpeza

Depois de concluir as tarefas nesta página, siga estas etapas para remover os recursos e evitar cobranças indesejadas na conta:

Excluir o cluster

gcloud

gcloud container clusters delete neg-demo-cluster

Console

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Selecione neg-demo-cluster.

  3. Clique em Excluir.

Resolver problemas

Use as técnicas abaixo para verificar a configuração de rede. Nas seções a seguir, você verá como resolver problemas comuns relacionados ao balanceamento de carga nativo de contêiner.

  • Veja a documentação de balanceamento de carga para saber como listar grupos de endpoints de rede.

  • É possível encontrar o nome e as zonas do NEG correspondente a um serviço na anotação neg-status do serviço. Veja a especificação do serviço com:

    kubectl get svc svc-name -o yaml

    A anotação metadata:annotations:cloud.google.com/neg-status lista as zonas e o nome do NEG correspondente ao serviço.

  • É possível verificar a integridade do serviço de back-end correspondente a um NEG com o seguinte comando:

    gcloud compute backend-services [--project PROJECT_NAME] \
      get-health BACKEND_SERVICE_NAME --global
    

    O serviço de back-end tem o mesmo nome que o NEG.

  • Para imprimir os logs de eventos de um serviço:

    kubectl describe svc [SERVICE_NAME]
    

    A string do nome do serviço inclui o nome e o namespace do serviço correspondente do GKE.

Não é possível criar um cluster com IPs de alias

Sintomas
Ao tentar criar um cluster com IPs de alias, é possível encontrar o seguinte erro:
ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Causas possíveis
Esse erro aparecerá se você tentar criar um cluster com IPs de alias que também usa uma rede legada.
Resolução
Certifique-se de não criar um cluster com IPs de alias e uma rede legada ativada simultaneamente. Para mais informações sobre como usar IPs de alias, consulte Como criar clusters nativos de VPC usando IPs de alias.

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

Sintomas
Erros 502 ou conexões rejeitadas.
Causas possíveis

Novos endpoints geralmente se tornam acessíveis depois de anexados ao balanceador de carga, desde que respondam a verificações de integridade. Poderão ocorrer erros 502 ou conexões rejeitadas se o tráfego não conseguir alcançar os endpoints.

Erros 502 e conexões rejeitadas também podem ser causados por um contêiner que não lida com SIGTERM. Se um contêiner não lida com SIGTERM de maneira explícita, ele encerra imediatamente e para de processar as solicitações. O balanceador de carga continua a enviar tráfego de entrada para este contêiner encerrado, causando erros.

Resolução

Configure os contêineres para lidar com SIGTERM e continuar a responder às solicitações durante o período de carência do encerramento (30 segundos por padrão). Configure os pods para começarem a falhar nas verificações de integridade ao receberem SIGTERM. Isso envia um sinal para que o balanceador de carga pare de enviar tráfego para o pod enquanto a desprogramação do endpoint estiver em andamento.

Para mais informações, veja a documentação sobre encerramento de pod e esta postagem sobre práticas recomendadas para encerramento de pods (links em inglês).

Para solucionar problemas de tráfego que não alcança os endpoints, verifique se as regras de firewall permitem o tráfego TCP de entrada para os endpoints nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Para saber mais, consulte Como adicionar verificações de integridade na documentação do Cloud Load Balancing.

Veja os serviços de back-end no seu projeto. A string de nome do serviço de back-end relevante inclui o nome e o namespace do serviço do Google Kubernetes Engine correspondente:

gcloud compute backend-services list

Recupere o status de integridade do back-end do serviço correspondente:

gcloud compute backend-services get-health [BACKEND_SERVICE_NAME]

Se nenhum back-end estiver íntegro, significa que pode haver problemas na configuração de seu firewall, sua entrada ou seu serviço.

Se alguns back-ends não estiverem íntegros por um curto período de tempo, a causa poderá ser a latência de programação de rede.

Se alguns back-ends não aparecerem na lista de serviços de back-end, a causa poderá ser a latência de programação. Para verificar isso, execute o seguinte comando, em que [NEG] é o nome do serviço de back-end. NEGs e serviços de back-end compartilham o mesmo nome:

gcloud compute network-endpoint-groups list-network-endpoints [NEG]

Verifique se todos os endpoints esperados estão no NEG.

Lançamento interrompido

Sintomas
O lançamento de uma implantação atualizada é interrompido e o número de réplicas atualizadas não corresponde ao esperado.
Causas possíveis

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. O lançamento da substituição dos pods está esperando até que o pod recém-iniciado passe o portão de prontidão do pod (em inglês). Isso só ocorrerá se o pod estiver respondendo às verificações de integridade do balanceador de carga. Se o pod não estiver respondendo ou se a verificação de integridade estiver configurada incorretamente, as condições do portão de prontidão não poderão ser cumpridas e o lançamento não poderá continuar.

Se você estiver usando kubectl 1.13 ou superior, é 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.

Essa coluna não existe em kubectl 1,12 ou inferior. Um pod marcado como READY pode ter um portão de prontidão falho. 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.

Resolução

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. Verifique se as verificações de integridade estão configuradas corretamente.

Problemas conhecidos

O balanceamento de carga nativo do contêiner no Google Kubernetes Engine apresenta os seguintes problemas conhecidos:

Coleta de lixo incompleta

O Google Kubernetes Engine coleta lixo de balanceadores de carga nativos do recipiente a cada dois minutos. Se um cluster for excluído antes que os balanceadores de carga sejam totalmente removidos, você precisará excluir manualmente os NEGs do balanceador de carga.

Veja os NEGs do seu projeto executando o seguinte comando:

gcloud compute network-endpoint-groups list

Na saída do comando, procure os NEGs relevantes.

Para excluir um NEG, execute o seguinte comando, em que [NEG] é o nome do NEG:

gcloud compute network-endpoint-groups delete [NEG]

Como alinhar lançamentos de carga de trabalho com propagação de endpoint

Ao implantar uma carga de trabalho no cluster ou atualizar uma carga de trabalho atual, o balanceador de carga nativo de contêiner pode levar mais tempo para propagar novos endpoints do que leva para concluir o lançamento da carga de trabalho. A implantação de exemplo implantada neste guia usa dois campos para alinhar o lançamento com a propagação de endpoints: terminationGracePeriodSeconds e minReadySeconds.

terminationGracePeriodSeconds (em inglês) permite que o pod encerre normalmente esperando que as conexões sejam encerradas após um pod ser programado para exclusão.

minReadySeconds (em inglês) adiciona um período de latência depois que um pod é criado. Especifique um número mínimo de segundos para que um novo pod fique no status Ready (em inglês), sem que nenhum contêiner apresente falhas, para que o pod seja considerado disponível.

Configure os valores minReadySeconds e terminationGracePeriodSeconds das cargas de trabalho como 60 segundos ou mais para garantir que o serviço não seja interrompido devido ao lançamento de cargas de trabalho.

terminationGracePeriodSeconds está disponível em todas as especificações do pod e minReadySeconds está disponível para implantações e DaemonSets.

Para saber mais sobre o ajuste fino de distribuições, consulte RollingUpdateStrategy (em inglês).

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine