Como usar balanceamento de carga nativo de contêiner

Nesta página, explicamos 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) fiquem direcionados para os pods e distribuam uniformemente o tráfego para eles.

Esse tipo de 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 configura regras iptables de nós para distribuir o tráfego para os pods. Sem o balanceamento de carga nativo de contêiner, o tráfego do balanceador de carga viaja para os grupos de instâncias de nó e é encaminhado por 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 receber o tráfego, 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 seus serviços no nível de NEG.
Suporte para recursos de balanceamento de carga HTTP(S)
Oferece suporte nativo no Google Kubernetes Engine para vários recursos de balanceamento de carga HTTP(S), como integração com serviços GCP como Cloud Armor, Cloud CDN e Cloud Identity-Aware Proxy. Ele também oferece algoritmos de balanceamento de carga para distribuição de tráfego precisa.

Requisitos

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

Google Kubernetes Engine versão 1.10
Os balanceadores de carga nativos de contêiner estão disponíveis nos clusters do Google Kubernetes Engine a partir da versão 1.10.
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.

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 pela entrada criada 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.

A implantação de amostra a seguir, neg-demo-app, executa uma única instância de um servidor HTTP em contêiner:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec: # Deployment's specification
  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
      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 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, você precisa agrupar os pods correspondentes em um serviço.

O serviço de amostra 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 an 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 uma entrada para o serviço.

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

kubectl apply -f neg-demo-svc.yaml

Como criar uma entrada para o serviço

O Ingress de amostra a seguir, neg-demo-ing, é direcionado para o serviço que você criou:

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 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 do Ingress, 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 conseguir 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 seu projeto:

gcloud beta 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, enviando 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 do neg-demo-app de uma instância 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. Você pode conseguir o endereço IP da entrada com 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 GCP.

    Acessar o menu do Google Kubernetes Engine

  2. Selecione neg-demo-cluster.

  3. Clique em Excluir.

Solução de problemas

As seções a seguir explicam como resolver problemas comuns relacionados ao balanceamento de carga nativo de contêiner.

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

Sintomas
Quando você tenta criar um cluster com IPs de alias, pode encontrar o seguinte erro:
ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Causas possíveis
Você encontrará esse erro se 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 saber 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.
Resolução

Para resolver esse problema, verifique se as regras de firewall permitem tráfego TCP de entrada para seus 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. O serviço de back-end relevante tem o nome do serviço correspondente do Google Kubernetes Engine:

gcloud beta compute backend-services list

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

gcloud beta 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. É possível verificar isso executando 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 beta compute network-endpoint-groups list-network-endpoints [NEG]

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

Problemas conhecidos

O balanceamento de carga nativo de contêiner no Google Kubernetes Engine apresenta os seguintes problemas conhecidos na versão Beta:

Como alinhar distribuições de carga de trabalho com propagação de ponto de extremidade

Quando você implanta uma carga de trabalho no seu cluster ou quando atualiza uma carga de trabalho existente, o balanceador de carga nativo de contêiner pode levar mais tempo para propagar novos pontos de extremidade do que leva para concluir a distribuição da carga de trabalho. A implantação de amostra neste guia usa dois campos para alinhar a distribuição com a propagação de pontos de extremidade: terminationGracePeriodSeconds e minReadySeconds.

terminationGracePeriodSeconds permite o desligamento suave do pod ao aguardar o encerramento das conexões após um pod ser programado para exclusão.

minReadySeconds adiciona um período de latência depois que um pod é criado. Você especifica um número mínimo de segundos em que um novo pod precisa estar no status Ready sem que nenhum dos contêineres dele falhe para que seja considerado disponível.

Configure os valores minReadySeconds e terminationGracePeriodSeconds das suas cargas de trabalho com 60 segundos ou mais para garantir que o serviço não seja interrompido devido a distribuições de carga 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.

Coleta de lixo incompleta

O lixo do Google Kubernetes Engine coleta balanceadores de carga nativos de contêiner a cada 10 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 beta 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 beta compute network-endpoint-groups delete [NEG]

Interrupção de cargas de trabalho com escalonamento para zero

As cargas de trabalho com escalonamento para zero podem sofrer interrupções momentâneas quando o número de pontos de extremidade em um NEG varia de zero para diferente de zero e vice-versa. Durante essas interrupções, o balanceador de carga pode retornar respostas diferentes de 200 e os back-ends podem parecer não íntegros.

A seguir

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

Enviar comentários sobre…

Documentação do Kubernetes Engine