Entrada para balanceadores de carga de aplicações internos

Esta página explica como funciona a entrada para balanceadores de carga de aplicações internos no Google Kubernetes Engine (GKE). Também pode saber como configurar e usar o Ingress para balanceadores de carga de aplicações internos.

No GKE, o balanceador de carga de aplicações interno é um balanceador de carga regional de camada 7 baseado em proxy que lhe permite executar e dimensionar os seus serviços atrás de um endereço IP de balanceamento de carga interno. Os objetos Ingress do GKE suportam o balanceador de carga de aplicações interno de forma nativa através da criação de objetos Ingress em clusters do GKE.

Para obter informações gerais sobre a utilização da entrada para o balanceamento de carga no GKE, consulte o artigo Balanceamento de carga HTTP(S) com a entrada.

Vantagens da utilização da entrada para balanceadores de carga de aplicações internos

A utilização da entrada do GKE para balanceadores de carga de aplicações internos oferece as seguintes vantagens:

  • Um controlador Ingress altamente disponível e gerido pelo GKE.
  • Balanceamento de carga para comunicação interna entre serviços.
  • Balanceamento de carga nativa do contentor com grupos de pontos finais da rede (NEG).
  • Encaminhamento de aplicações com suporte de HTTP e HTTPS.
  • Verificações de estado do Compute Engine de alta fidelidade para serviços resilientes.
  • Proxies baseados no Envoy que são implementados a pedido para satisfazer as necessidades de capacidade de tráfego.

Suporte para Google Cloud funcionalidades

O Ingress para balanceadores de carga de aplicações internos suporta várias funcionalidades adicionais.

Ambiente de rede necessário para balanceadores de carga de aplicações internos

O balanceador de carga da aplicação interno fornece um conjunto de proxies para a sua rede. Os proxies avaliam para onde cada pedido HTTP(S) deve ir com base em fatores como o mapa de URLs, a afinidade de sessão do BackendService e o modo de equilíbrio de carga de cada NEG de back-end.

Um Application Load Balancer interno de uma região usa a sub-rede apenas de proxy dessa região na sua rede VPC para atribuir endereços IP internos a cada proxy criado por Google Cloud.

Por predefinição, o endereço IP atribuído a uma regra de encaminhamento de um balanceador de carga provém do intervalo de sub-rede do nó atribuído pelo GKE em vez da sub-rede só de proxy. Também pode especificar manualmente um endereço IP para a regra de encaminhamento a partir de qualquer sub-rede quando cria a regra.

O diagrama seguinte oferece uma vista geral do fluxo de tráfego para um balanceador de carga de aplicações interno, conforme descrito no parágrafo anterior.

imagem

Veja como funciona o balanceador de carga de aplicações interno:

  1. Um cliente estabelece uma ligação ao endereço IP e à porta da regra de encaminhamento do balanceador de carga.
  2. Um proxy recebe e termina a ligação de rede do cliente.
  3. O proxy estabelece uma ligação ao ponto final adequado (Pod) num NEG, conforme determinado pelo mapa de URLs do equilibrador de carga e pelos serviços de back-end.

Cada proxy escuta o endereço IP e a porta especificados pela regra de encaminhamento do balanceador de carga correspondente. O endereço IP de origem de cada pacote enviado de um proxy para um ponto final é o endereço IP interno atribuído a esse proxy a partir da sub-rede apenas de proxy.

HTTPS (TLS) entre o balanceador de carga e a sua aplicação

Um balanceador de carga de aplicações interno funciona como um proxy entre os seus clientes e a sua aplicação. Os clientes podem usar HTTP ou HTTPS para comunicar com o proxy do balanceador de carga. A ligação do proxy do balanceador de carga à sua aplicação usa HTTP por predefinição. No entanto, se a sua aplicação for executada num pod do GKE e puder receber pedidos HTTPS, pode configurar o balanceador de carga para usar HTTPS quando encaminha pedidos para a sua aplicação.

Para configurar o protocolo usado entre o balanceador de carga e a sua aplicação, use a anotação cloud.google.com/app-protocols no manifesto do serviço.

O manifesto de serviço seguinte especifica duas portas. A anotação especifica que um balanceador de carga de aplicações interno deve usar HTTP quando segmenta a porta 80 do serviço e usar HTTPS quando segmenta a porta 443 do serviço.

Tem de usar o campo name da porta na anotação. Não use um campo diferente, como targetPort.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

O que se segue?