HTTP/2 para balanceamento de carga com Entrada

Nesta página, mostramos como usar os objetos de Entrada e Serviço do Kubernetes para configurar um balanceador de carga HTTP(S) a fim de usar o HTTP/2 para comunicação com serviços de back-end. Este recurso está disponível a partir da versão 1.11.2 do Google Kubernetes Engine.

Visão geral

Um balanceador de carga HTTP(S) atua como um proxy entre seus clientes e o 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 em execução em um pod do Google Kubernetes Engine for capaz de receber solicitações HTTP/2, configure o balanceador de carga para usar HTTP/2 quando encaminhar solicitações para seu aplicativo.

Diagrama que mostra HTTP/2 do balanceador de carga para o pod (clique para ampliar)

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

Prepare-se para a tarefa tomando as seguintes medidas:

  • Verifique se você ativou a API Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Verifique se o SDK do Cloud está instalado.
  • Defina o código do projeto padrão:
    gcloud config set project [PROJECT_ID]
  • Se você estiver trabalhando com clusters zonais, defina a zona de computação padrão:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Se você estiver trabalhando com clusters regionais, defina a região de computação padrão:
    gcloud config set compute/region [COMPUTE_REGION]
  • Atualize a gcloud para a versão mais recente:
    gcloud components update

Como criar a implantação

Este manifesto de implantação declara que você quer executar duas réplicas do aplicativo da Web echoheaders:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: echoheaders
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: echoheaders
    spec:
      containers:
      - name: echoheaders
        image: k8s.gcr.io/echoserver:1.10
        ports:
        - containerPort: 8443

Copie o manifesto para um arquivo denominado my-deployment.yaml e crie a implantação:

kubectl apply -f my-deployment.yaml

Como criar o serviço

Veja aqui um manifesto de um serviço:

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

Salve o manifesto em um arquivo denominado my-service.yaml e crie o serviço:

kubectl apply -f my-service.yaml

Veja o serviço:

kubectl get service echoheaders --output yaml

A resposta é semelhante a esta:

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
...

Para os fins deste exercício, estes são os pontos mais importantes a serem observados sobre seu serviço:

  • O serviço tem o tipo NodePort. Esse tipo é necessário para os Serviços que serão associados a uma Entrada.

  • Qualquer pod que tenha o rótulo app: echoheaders é um membro do serviço. O campo selector especifica isso.

  • O serviço tem uma porta chamada my-port. A anotação cloud.google.com/app-protocols especifica que my-port precisa usar o protocolo HTTP/2.

  • O tráfego direcionado ao serviço na porta TCP 443 é encaminhado para a porta TCP 8443 em um dos pods membros. Os campos port e targetPort especificam isso.

Como criar a Entrada

Veja aqui um manifesto de uma Entrada:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echomap
spec:
  backend:
    serviceName: echoheaders
    servicePort: 443

Copie o manifesto para um arquivo denominado my-ingress.yaml e crie a Entrada:

kubectl apply -f my-ingress.yaml

Aguarde alguns minutos para que o controlador de Entrada do Kubernetes configure um balanceador de carga HTTP(S) e visualize a Entrada:

kubectl get ingress echomap --output yaml

A resposta é semelhante a esta:

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

Para os fins deste exercício, estes são os pontos mais importantes a serem observados sobre a Entrada:

  • O endereço IP para o tráfego de entrada é listado em loadBalancer:ingress.

  • As solicitações recebidas são encaminhadas para um pod que é membro do serviço echoheaders. Neste exercício, os pods membros têm o rótulo app: echoheaders.

  • As solicitações são encaminhadas para o pod na porta de destino especificada no manifesto do serviço echoheaders. Neste exercício, a porta de destino do pod é 8443.

Como verificar se seu balanceador de carga é compatível com HTTP/2

gcloud

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

    gcloud compute backend-services list
    
  2. Descreva seu serviço de back-end:

    gcloud beta compute backend-services describe [BACKEND_SERVICE_NAME] --global
    

    em que [BACKEND_SERVICE_NAME] é o nome do seu serviço de back-end.

  3. Na resposta, verifique se o protocolo é HTTP/2:

    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 Platform.
    Acessar a página Balanceamento de carga

  2. Em Nome, localize seu balanceador de carga.

    Captura de tela do balanceador de carga HTTP exibido no Console do Google Cloud Platform (clique para ampliar)
  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.

    Captura de tela do serviço de back-end HTTP/2 exibido no Console do Google Cloud Platform (clique para ampliar)

Como chamar o serviço

Aguarde alguns minutos até que o balanceador de carga e o serviço de back-end sejam configurados. Digite o endereço IP externo do seu balanceador de carga na barra de endereços do navegador.

A resposta mostra informações sobre a solicitação do balanceador de carga para o pod:

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
...

Para os fins deste exercício, estes são os pontos mais importantes a serem observados sobre a resposta anterior:

  • A linha request_version=2 indica que a solicitação entre o balanceador de carga e o pod usou HTTP/2.

  • A linha x-forwarded-proto=http indica que a solicitação entre você e o balanceador de carga usou HTTP 1.1, não HTTP/2.

A seguir

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

Enviar comentários sobre…

Documentação do Kubernetes Engine