Entrada para balanceadores de carga de aplicativo internos

Nesta página, explicamos como o Ingress para balanceadores de carga internos de aplicativos funciona no Google Kubernetes Engine (GKE). Saiba também como configurar e usar o Ingress para balanceadores de carga internos de aplicativos.

No GKE, o balanceador de carga interno de aplicativo é regional, baseado em proxy e de camada 7. Com ele, é possível executar e escalonar serviços para aceitar um endereço IP de balanceamento de carga interno. Os objetos do Ingress do GKE são compatíveis com o balanceador de carga interno de aplicativo de forma nativa por meio da criação desses objetos nos clusters do GKE.

Para informações gerais sobre como usar o Ingress do balanceamento de carga no GKE, consulte Balanceamento de carga HTTP(S) com o Ingress.

Benefícios do uso do Ingress para balanceadores de carga internos de aplicativos

O uso da Entrada do GKE para balanceadores de carga internos de aplicativos oferece os seguintes benefícios:

  • Um controlador de Ingress altamente disponível e gerenciado pelo GKE.
  • Balanceamento de carga para comunicação interna entre serviços.
  • Balanceamento de carga nativo de contêiner com grupos de endpoint de rede (NEG, na sigla em inglês).
  • Roteamento de aplicativos com suporte a HTTP e HTTPS.
  • Verificações de integridade de alta fidelidade do Compute Engine para garantir serviços resilientes.
  • Proxies baseados no Envoy que são implantados sob demanda para atender às necessidades da capacidade de tráfego.

Suporte para recursos do Google Cloud

O Ingress para balanceadores de carga internos de aplicativos é compatível com vários outros recursos.

Ambiente de rede necessário para balanceadores de carga internos de aplicativos

O balanceador de carga de aplicativo interno fornece um pool de proxies para sua rede. Os proxies avaliam para onde cada solicitação HTTP(S) precisa ir com base em fatores como o mapa de URL, a afinidade da sessão do BackendService e o modo de balanceamento de cada NEG de back-end.

O balanceador de carga de aplicativo interno de uma região usa a sub-rede somente proxy dessa região na rede VPC para atribuir endereços IP internos a cada proxy criado pelo Google Cloud.

Por padrão, o endereço IP atribuído à regra de encaminhamento de um balanceador de carga vem do intervalo de sub-rede do nó atribuído pelo GKE em vez da sub-rede somente proxy. Também é possível especificar manualmente um endereço IP para a regra de encaminhamento de qualquer sub-rede ao criar a regra.

O diagrama a seguir fornece uma visão geral do fluxo de tráfego para um balanceador de carga interno do aplicativo, conforme descrito no parágrafo anterior.

imagem

Veja como o balanceador de carga interno do aplicativo funciona:

  1. Um cliente estabelece uma conexão com o endereço IP e a porta da regra de encaminhamento do balanceador de carga.
  2. Um proxy recebe e encerra a conexão de rede do cliente.
  3. O proxy estabelece uma conexão com o endpoint apropriado (pod) em um NEG, conforme determinado pelos serviços de back-end e o mapa de URL do balanceador de carga.

Cada proxy detecta 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 endpoint é o endereço IP interno atribuído a esse proxy a partir da sub-rede somente proxy.

HTTPS (TLS) entre o balanceador de carga e o aplicativo

Um balanceador de carga de aplicativo interno atua como um proxy entre seus clientes e seu aplicativo. Os clientes podem usar HTTP ou HTTPS para a comunicação com o proxy do balanceador de carga. A conexão entre o proxy do balanceador de carga e seu aplicativo usa HTTP por padrão. No entanto, se o aplicativo for executado em um pod do GKE e puder receber solicitações HTTPS, será possível configurar o balanceador de carga para usar HTTPS quando encaminhar solicitações para o aplicativo.

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

O manifesto do serviço a seguir especifica duas portas. A anotação especifica que um balanceador de carga de aplicativo interno deve usar HTTP quando segmentar a porta 80 do Serviço e usar HTTPS quando segmentar a porta 443 do Serviço.

Use 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

A seguir