Como usar o HTTP/2 para balanceamento de carga com a Entrada

Nesta página, mostramos como usar os objetos Entrada e Serviço do Kubernetes para configurar um balanceador de carga de aplicativo externo a ser usado em HTTP/2 para comunicação com os serviços de back-end.

Visão geral

Um balanceador de carga de aplicativo atua como um proxy entre seus clientes e seu aplicativo. Os clientes podem usar HTTP/1.1 ou HTTP/2 para se comunicar com o proxy do balanceador de carga. Porém, a conexão entre o proxy do balanceador de carga e o aplicativo usa o HTTP/1.1 por padrão. Se o aplicativo, executado em um pod do Google Kubernetes Engine (GKE), for capaz de receber solicitações HTTP/2, configure o balanceador de carga externo para usar HTTP/2 ao encaminhar solicitações para o aplicativo.

Neste exercício, você cria uma implantação, um serviço e uma entrada. Coloque uma anotação em cloud.google.com/app-protocols no seu manifesto de serviço para especificar que o balanceador de carga precisa usar HTTP/2 para se comunicar com seu aplicativo. Em seguida, chame o serviço e verifique se o aplicativo recebeu uma solicitação HTTP/2.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.

Criar a implantação

  1. Copie o seguinte manifesto para um arquivo chamado my-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoheaders
spec:
  replicas: 2
  selector:
    matchLabels:
      app: echoheaders
  template:
    metadata:
      labels:
        app: echoheaders
    spec:
      containers:
      - name: echoheaders
        image: registry.k8s.io/echoserver:1.10
        ports:
        - containerPort: 8443

    Nesse manifesto, é descrita uma implantação com duas réplicas do aplicativo da Web echoheaders.

  2. Aplique o manifesto ao cluster:

    kubectl apply -f my-deployment.yaml

Criar o serviço

  1. Copie o seguinte manifesto para um arquivo chamado my-service.yaml:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
  name: echoheaders
  labels:
    app: echoheaders
spec:
  type: NodePort
  ports:
  - port: 443
    targetPort: 8443
    protocol: TCP
    name: my-port
  selector:
    app: echoheaders

    Esse manifesto descreve um serviço com as seguintes propriedades:

    • type: NodePort: especifica que esse é um serviço do tipo NodePort.
    • app: echoheaders: especifica que qualquer pod que tenha esse rótulo é membro do serviço.
    • cloud.google.com/app-protocols: especifica que my-port precisa usar o protocolo HTTP/2.
    • port: 443, protocol: TCP e targetPort: 8433: especifique que o tráfego direcionado ao serviço na porta TCP 443 precisa ser encaminhado para a porta TCP 8422 em um dos pods membros.

  2. Aplique o manifesto ao cluster:

    kubectl apply -f my-service.yaml

  3. Veja o serviço:

    kubectl get service echoheaders --output yaml

    O resultado será assim:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
    ...
  labels:
    app: echoheaders
  name: echoheaders
  ...
spec:
  clusterIP: 10.39.251.148
  ...
  ports:
  - name: my-port
    nodePort: 30647
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    app: echoheaders
  ...
  type: NodePort
...

Criar a entrada

  1. Copie o seguinte manifesto para um arquivo chamado my-ingress.yaml:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echomap
spec:
  defaultBackend:
    service:
      name: echoheaders
      port:
        number: 443

    Nesse manifesto, você encontra a descrição de uma entrada que especifica que as solicitações recebidas sejam enviadas a um pod membro do serviço echoheaders. As solicitações são encaminhadas para o pod no targetPort especificado no manifesto do serviço echoheaders. Neste exercício, o pod targetPort é 8443.

  2. Aplique o manifesto ao cluster:

    kubectl apply -f my-ingress.yaml

    Esse comando pode levar vários minutos para ser concluído enquanto o controlador de entrada do Kubernetes configura o balanceador de carga de aplicativo.

  3. Veja a entrada:

    kubectl get ingress echomap --output yaml

    O resultado será assim:

    kind: Ingress
metadata:
  ...
  name: echomap
  ...
spec:
  backend:
    serviceName: echoheaders
    servicePort: 443
status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.2

    Nessa saída, o endereço IP da entrada é 203.0.113.2.

Testar o balanceador de carga

gcloud

  1. Liste seus serviços de back-end:

    gcloud compute backend-services list

  2. Descreva o serviço de back-end:

    gcloud beta compute backend-services describe BACKEND_SERVICE_NAME --global

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

    A saída especifica que protocol é HTTP2:

    backends:
...
description: '{...,"kubernetes.io/service-port":"443","x-features":["HTTP2"]}'
...
kind: compute#backendService
loadBalancingScheme: EXTERNAL
protocol: HTTP2
...

Console

  1. Acesse a página Balanceamento de carga no Console do Google Cloud.

    Acessar o "Balanceamento de carga"

  2. Em Nome, localize seu balanceador de carga.

  3. Clique no nome do balanceador de carga para visualizar o serviço de back-end.

  4. Verifique se o protocolo do endpoint para o serviço de back-end é HTTP/2.

Chamar o serviço

Aguarde alguns minutos até que o GKE configure o balanceador de carga e o serviço de back-end. Em seguida, digite o endereço IP externo do seu balanceador de carga na barra de endereço do navegador.

O resultado será assim:

Hostname: echoheaders-7886d5bc68-xnrwj
...
Request Information:
  ...
  method=GET
  real path=/
  query=
  request_version=2
  request_scheme=https
  ...

Request Headers:
  ...
  x-forwarded-for=[YOUR_IP_ADDRESS], 203.0.113.2
  x-forwarded-proto=http
...

Com isso, informações sobre a solicitação serão enviadas do balanceador de carga para o pod:

  • request_version=2: indica que a solicitação entre o balanceador de carga e o pod usou HTTP/2.
  • x-forwarded-proto=http: indica que a solicitação entre o navegador e o balanceador de carga usou HTTP 1.1, não HTTP/2.

A seguir