Balanceamento de carga nativo do contêiner por meio da Entrada

Autopilot Standard

Nesta página, explicamos como usar o balanceamento de carga nativo de contêiner no Google Kubernetes Engine (GKE). O balanceamento de carga nativo de contêiner permite que os balanceadores de carga segmentem os pods do Kubernetes diretamente e distribuam o tráfego aos pods por igual.

Para mais informações sobre benefícios, requisitos e limitações do balanceamento de carga nativo de contêiner, consulte esta página.

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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da gcloud CLI não sejam compatíveis com a execução dos comandos neste documento.
  Observação: em instalações prévias da gcloud CLI, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na gcloud CLI como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

• Verifique se você tem um cluster nativo de VPC. Se precisar, crie um cluster. Por padrão, os clusters do GKE são nativos de VPC.

Usar balanceamento de carga nativo de contêiner

Nas seções a seguir, você será orientado por uma configuração de balanceamento de carga nativo de contêiner no GKE.

Criar uma implantação

No exemplo de implantação a seguir, neg-demo-app executa uma única instância de um servidor HTTP em contêiner. Recomendamos 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:
  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 # Container name
        ports:
        - containerPort: 9376
          protocol: TCP
  

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: registry.k8s.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
        ports:
        - containerPort: 9376
          protocol: TCP
      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:

kubectl apply -f neg-demo-app.yaml

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 exemplo de serviço a seguir, neg-demo-svc, é direcionado para a implantação de exemplo criada na seção anterior:

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc # Name of Service
spec: # Service's specification
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - name: http
    port: 80 # Service's port
    protocol: TCP
    targetPort: 9376

Observação: o serviço é exposto na porta 80 e redireciona o tráfego para a porta 9376, o targetPort. O targetPort corresponde a um containerPort em um pod de veiculação. Também é possível usar um serviço do tipo NodePort com balanceamento de carga nativo de contêiner. Um serviço do tipo ClusterIP é recomendado, a menos que você precise explicitamente do nodePort fornecido por um serviço NodePort. Os serviços LoadBalancer não têm suporte como back-ends de entrada.

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 crie o serviço:

kubectl apply -f neg-demo-svc.yaml

Criar uma entrada para o serviço

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: neg-demo-ing
spec:
  defaultBackend:
    service:
      name: neg-demo-svc # Name of the Service targeted by the Ingress
      port:
        number: 80 # Should match the port used by the Service

Salve este manifesto como neg-demo-ing.yaml e crie a antrada:

kubectl apply -f neg-demo-ing.yaml

Ao criar o Ingress, um balanceador de carga de aplicativo é criado no projeto e os grupos de endpoints de rede (NEGs, na sigla em inglês) 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.

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.

Recuperar o status da entrada:

kubectl describe ingress neg-demo-ing

A saída inclui 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

Testar o 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 de aplicativo 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.

1. Receba uma lista dos serviços de back-end em execução no projeto:

   gcloud compute backend-services list
   

   Registre o nome do serviço de back-end que inclui o nome do serviço, como neg-demo-svc.

2. Receba o status de integridade do serviço de back-end:

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

   Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.

Testar a Entrada

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.

1. Escalone a implantação neg-demo-app de uma instância para duas instâncias:

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

   Esse comando pode levar alguns minutos para ser concluído.

2. Verificar se o lançamento foi concluído:

   kubectl get deployment neg-demo-app
   

   A saída precisa incluir duas réplicas disponíveis:

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

3. Acessar o endereço IP de entrada:

   kubectl describe ingress neg-demo-ing
   

   Se esse comando retornar um erro 404, aguarde alguns minutos para que o balanceador de carga seja iniciado e tente novamente.

4. Contar o número de respostas distintas do balanceador de carga:

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

   Substitua IP_ADDRESS pelo endereço IP da entrada.

   O resultado será assim:

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

   Nessa saída, o número de respostas distintas é igual ao número de réplicas, o que indica que todos os pods de back-end estão disponibilizando tráfego.

Limpar

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 a página do Google Kubernetes Engine no console do Google Cloud .

   Acessar o Google Kubernetes Engine

2. Selecione neg-demo-cluster e clique em Excluir.

3. Quando solicitado a confirmar, clique em Excluir.

A seguir

• Saiba como usar o balanceamento de carga nativo de contêiner por meio de NEGs zonais independentes.
• Saiba mais sobre os clusters nativos de VPC.
• Saiba mais sobre a configuração de entrada.
• Saiba como usar certificados SSL gerenciados pelo Google.