Entrada do GKE para balanceadores de carga de aplicativo

Nesta página, fornecemos uma visão geral do Entrada do Google Kubernetes Engine (GKE) para balanceadores de carga de aplicativo e explicamos como o controlador Entrada provisiona balanceadores de carga de aplicativo para expor aplicativos ao tráfego HTTP(S) de dentro ou de fora da rede VPC.

Esta página serve como o principal ponto de entrada para entender como o GKE Ingress funciona. Para examinar a arquitetura de rede, os padrões de roteamento de tráfego e as implementações de segurança subjacentes com mais detalhes, consulte Sobre o roteamento e a segurança de entrada do GKE.

Nesta página, consideramos que você esteja familiarizado com o seguinte:

Esta página é destinada a especialistas em redes que projetam e arquitetam a rede para a organização e instalam, configuram e oferecem suporte a equipamentos de rede. Para saber mais sobre papéis comuns e tarefas de exemplo que mencionamos no conteúdo doGoogle Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Visão geral

O GKE fornece um controlador de entrada gerenciado e integrado chamado GKE Ingress. Quando você cria um recurso de entrada no GKE, o controlador configura automaticamente um balanceador de carga HTTPS que permite que o tráfego HTTP ou HTTPS chegue aos seus serviços. O controlador Ingress configura o balanceador de carga e encaminha o tráfego para aplicativos executados no cluster com base nas regras especificadas no manifesto Ingress e nos objetos de serviço associados.

Um objeto Ingress está associado a um ou mais objetos de serviço, que, por sua vez, estão associados a um conjunto de pods. Para saber mais sobre como Entrada expõe aplicativos usando Serviços, consulte Visão geral da rede de serviços.

Para usar Entrada, é necessário ativar o complemento de balanceamento de carga HTTP. Os clusters do GKE ativam esse complemento por padrão. Não o desative.

Diferença entre o serviço do Kubernetes e o Google Cloud serviço de back-end

O objeto de serviço do Kubernetes e o objeto Google Cloud backend service têm finalidades semelhantes, mas distintas. Embora estejam fortemente relacionados, a relação nem sempre é de um para um.

O controlador de entrada do GKE atua como o tradutor entre esses dois conceitos. Quando você cria um recurso Entrada, o controlador provisiona um balanceador de cargaGoogle Cloud . Em seguida, o controlador cria um serviço de back-endGoogle Cloud dedicado para cada combinação exclusiva (service.name, service.port) referenciada no manifesto Ingress.

Por exemplo, um manifesto de entrada pode ter o mesmo nome de serviço do Kubernetes, mas apontar para um service.port diferente para duas regras separadas de host ou path. Nesse caso, o controlador de entrada do GKE cria dois serviços de back-end separados. Portanto, um objeto de serviço do Kubernetes pode estar relacionado a vários serviços de back-end Google Cloud .

Entrada para tráfego externo e interno

Há dois tipos de recursos de entrada do GKE:

Ambiente de rede necessário para balanceadores de carga de aplicativo externos

O balanceador de carga de aplicativo externo é um sistema gerenciado e distribuído globalmente que usa proxies do Google Front End (GFE) implantados na rede de borda do Google. Esses proxies não estão localizados na sua rede VPC. Quando um cliente envia uma solicitação ao endereço IP externo do balanceador de carga, ela é roteada usando a rede anycast do Google para o GFE mais próximo. O GFE encerra o tráfego do usuário (incluindo TLS, se configurado) e encaminha o tráfego para os pods de back-end no cluster do GKE.

Para que esse fluxo funcione, o controlador de entrada do GKE cria automaticamente regras de firewall para permitir que o tráfego das GFEs e dos sistemas de verificação de integridade doGoogle Cloudalcancem seus pods. Essas regras permitem o tráfego dos intervalos de endereços IP conhecidos do Google (130.211.0.0/22 e 35.191.0.0/16).

Veja como o balanceador de carga de aplicativo externo funciona:

  1. Um cliente envia uma solicitação para o endereço IP e a porta da regra de encaminhamento do balanceador de carga.
  2. A solicitação é encaminhada para um proxy do Google Front End (GFE) na rede global do Google. Esse proxy encerra a conexão de rede do cliente.
  3. O proxy do GFE encaminha a solicitação para o endpoint do pod de back-end apropriado no cluster do GKE, conforme determinado pelo mapa de URL do balanceador de carga e pelos serviços de back-end.

Ao contrário do balanceador de carga de aplicativo interno, não é necessário configurar uma sub-rede somente proxy na rede VPC para um balanceador de carga de aplicativo externo.

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

Comportamento do controlador de Ingress do GKE

Se o controlador de entrada do GKE processa uma entrada depende do valor da anotação kubernetes.io/ingress.class:

Valor de kubernetes.io/ingress.class Valor de ingressClassName Comportamento do controlador de Ingress do GKE
Não definido Não definido Processe o manifesto do Ingress e crie um balanceador de carga de aplicativo externo.
Não definido Qualquer valor Não precisa fazer nada. O manifesto do Ingress poderá ser processado por um controlador de entrada de terceiros se ele tiver sido implantado.
gce Qualquer valor Este campo é ignorado. Processe o manifesto do Ingress e crie um balanceador de carga de aplicativo externo.
gce-internal Qualquer valor Este campo é ignorado. Processe o manifesto do Ingress e crie um balanceador de carga de aplicativo interno.
Defina com um valor diferente de gce ou gce-internal. Qualquer valor Não precisa fazer nada. O manifesto do Ingress poderá ser processado por um controlador de entrada de terceiros se ele tiver sido implantado.

Descontinuação de anotação kubernetes.io/ingress.class

A anotação kubernetes.io/ingress.class é descontinuada no Kubernetes, mas o GKE continua a usar essa anotação. É necessário usar essa anotação para identificar a classe de entrada.

Ao aplicar a configuração, talvez você encontre um aviso de suspensão de uso. Esse aviso informa que a anotação foi descontinuada e instrui você a usar o campo ingressClassName. Você pode ignorar o aviso porque o GKE Ingress continua dependendo exclusivamente da anotação kubernetes.io/ingress.class.

Entrada para os mapeamentos de recursos do Compute Engine

O controlador de Ingress do GKE implanta e gerencia os recursos do balanceador de carga do Compute Engine com base nos recursos da Ingress implantados no cluster. O mapeamento dos recursos do Compute Engine depende da estrutura do recurso Ingress.

O manifesto a seguir descreve um Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Esse manifesto do Ingress instrui o GKE a criar os seguintes recursos do Compute Engine:

  • Uma regra de encaminhamento e um endereço IP.
  • Regras de firewall do Compute Engine que permitem tráfego para verificações de integridade do balanceador de carga e para aplicativos dos proxies do Google Front End ou Envoy
  • Um proxy HTTP de destino e um proxy HTTPS de destino, se você tiver configurado o TLS.
  • Um mapa de URLs que, com uma única regra de host, refere-se a uma única correspondência de caminho. A correspondência de caminho tem duas regras de caminho, uma para /* e outra para /discounted. Cada regra de caminho mapeia um serviço de back-end exclusivo.
  • NEGs que contêm uma lista de endereços IP de pods de cada serviço como endpoints. Eles são criados como resultado dos serviços my-discounted-products e my-products.

Métodos de balanceamento de carga

O GKE é compatível com o balanceamento de carga nativo de contêiner e grupos de instâncias.

Balanceamento de carga nativo de contêiner

O balanceamento de carga nativo de contêiner é a prática de balancear a carga diretamente para os endpoints do pod no GKE. O balanceamento de carga nativo de contêiner usa grupos de endpoints de rede (NEGs) do tipo GCE_VM_IP_PORT, em que os endpoints são os endereços IP dos pods.

O balanceamento de carga nativo de contêiner é sempre usado para Entrada interna do GKE e é opcional para Entrada externa. O controlador de entrada cria o balanceador de carga, incluindo o endereço IP virtual, as regras de encaminhamento, as verificações de integridade e as regras de firewall.

O balanceamento de carga nativo de contêiner é compatível com a afinidade de sessão baseada em pods.

O GKE ativa automaticamente o balanceamento de carga nativo de contêiner quando todas as condições a seguir são atendidas:

  • O cluster é nativo de VPC.
  • O cluster não usa uma rede VPC compartilhada.
  • O cluster não usa a política de rede do GKE.
  • O cluster tem o complemento HttpLoadBalancing ativado. Os clusters do GKE têm o complemento HttpLoadBalancing ativado por padrão. Não o desative.

Quando o GKE ativa o balanceamento de carga nativo do contêiner, os serviços são anotados automaticamente com cloud.google.com/neg: '{"ingress": true}'. Essa anotação aciona a criação de um NEG que espelha os IPs dos pods, permitindo que os balanceadores de carga do Compute Engine se comuniquem diretamente com os pods.

Para clusters em que os NEGs não são o padrão, ainda é altamente recomendado usar o balanceamento de carga nativo de contêiner, mas ele precisa ser ativado explicitamente em cada Serviço.

Para mais flexibilidade, também é possível criar NEGs autônomos. Nesse caso, você é responsável por criar e gerenciar todos os aspectos do balanceador de carga.

Vantagens

Ao usar NEGs, o balanceamento de carga nativo de contêiner oferece uma rede mais eficiente e estável:

Melhor desempenho da rede: sem o balanceamento de carga nativo de contêiner, o tráfego viaja para os grupos de instâncias de nó e depende das regras iptables configuradas por kube-proxy para roteamento ao pod de destino. Com o balanceamento de carga nativo de contêiner, o tráfego é balanceado por carga diretamente para os pods, sem precisar passar pelo IP da VM e pela rede kube-proxy no nó. Esse fluxo elimina saltos de rede extras e melhora a latência e a capacidade.

Verificações de integridade avançadas: os portões de prontidão do pod são implementados para determinar a integridade do pod da perspectiva do balanceador de carga, em vez de depender apenas de sondagens de integridade no cluster. Esse recurso essencial faz com que o balanceador de carga reconheça eventos do ciclo de vida do pod (inicialização, perda etc.) e melhora a estabilidade do tráfego. Para saber mais sobre como os portões de prontidão de pods são usados para determinar a integridade do pod, consulte Prontidão do pod.

Maior visibilidade: com o balanceamento de carga nativo de contêiner, você tem visibilidade da latência do balanceador de carga de aplicativo diretamente para cada pod. Como a latência não é mais agregada no nível do IP do nó, fica mais fácil resolver problemas dos seus serviços no nível do NEG.

Suporte para o Cloud Service Mesh: o modelo de dados NEG é necessário para usar o Cloud Service Mesh, o plano de controle de tráfego totalmente gerenciado do Google Cloudpara malha de serviço.

Limitações dos balanceadores de carga nativos de contêiner

Os balanceadores de carga nativos de contêiner por meio do tráfego de entrada no GKE têm os seguintes requisitos:

  • Os balanceadores de carga nativos de contêiner não são compatíveis com balanceadores de carga de rede de passagem externa.
  • Não altere ou atualize manualmente a configuração do balanceador de carga de aplicativo criado pelo GKE. Todas as alterações feitas são substituídas pelo GKE.

Preços de balanceadores de carga nativos de contêiner

Você vai receber cobranças pelo balanceador de carga de aplicativo provisionado pelo Ingress criado neste guia. Para informações sobre preços do balanceador de carga, consulte as Regras de encaminhamento e balanceamento de carga na página de preços da VPC.

Grupos de instâncias

Ao usar grupos de instâncias, os balanceadores de carga do Compute Engine enviam tráfego para endereços IP de VM como back-ends. Ao executar contêineres em VMs, eles compartilharão a mesma interface de host. Isso introduz as seguintes limitações:

  • Há dois saltos de balanceamento de carga: um do balanceador de carga para a VM NodePort e outro pelo roteamento do kube-proxy para os endereços IP do pod (que podem residir em uma VM diferente).
  • Saltos extras aumentam a latência e tornam o caminho de tráfego mais complexo.
  • O balanceador de carga do Compute Engine não tem visibilidade direta para os pods, resultando em um equilíbrio de tráfego abaixo do ideal.
  • Eventos de ambiente, como perda de VM ou de pod, têm maior probabilidade de causar perda intermitente de tráfego devido ao salto de tráfego duplo.

Ingress externo e clusters baseados em rotas

Se você usa clusters baseados em rotas com Ingress externo, o controlador de Ingress do GKE não pode usar o balanceamento de carga nativo de contêiner usando grupos de endpoints de rede (NEGs, na sigla em inglês) GCE_VM_IP_PORT. Em vez disso, o controlador de Ingress usa back-ends de grupos de instâncias não gerenciadas que incluem todos os nós em todos os pools de nós. Se esses grupos de instâncias não gerenciadas também forem usados por LoadBalancer, isso poderá causar problemas relacionados à limitação do grupo de instâncias com balanceamento de carga único.

Alguns objetos mais antigos do Ingress externo criados em clusters nativos de VPC podem usar back-ends de grupos de instâncias nos serviços de back-end de cada balanceador de carga de aplicativo externo criado. Isso não é relevante para Ingress interno porque os recursos internos sempre usam GCE_VM_IP_PORT NEGs e exigem clusters nativos de VPC.

Para saber como resolver erros 502 com Ingress externo, consulte Ingress externo produz erros HTTP 502.

Limitações do controlador de entrada do GKE

  • O GKE Ingress não é compatível com certificados gerenciados pelo Certificate Manager. Para usar certificados gerenciados pelo Certificate Manager, use a API Gateway.

  • Em clusters que usam NEGs, o tempo de reconciliação de entrada pode ser afetado pelo número de entradas. Por exemplo, um cluster com 20 entradas, cada um contendo 20 back-ends de NEG distintos, pode resultar em uma latência de mais de 30 minutos para que uma alteração de entrada seja reconciliada. Isso afeta especialmente os clusters regionais devido ao maior número de NEGs necessários.

  • Cotas para mapas de URL são aplicáveis.

  • Sujeito a cotas para recursos do Compute Engine.

  • Se você não estiver usando NEGs com o controlador de entrada do GKE,os clusters do GKE terão um limite de 1.000 nós. Quando os serviços são implantados com NEGs, não há limite de nós do GKE. Todos os Serviços não NEG expostos pela Entrada não funcionam corretamente em clusters com mais de 1.000 nós.

  • Para que o controlador de entrada do GKE use os readinessProbes como verificação de integridade, os pods de uma entrada precisam existir no momento da criação dela. Se as réplicas forem dimensionadas para 0, a verificação de integridade padrão será aplicada. Para mais informações, consulte este comentário de problema do GitHub sobre verificações de integridade.

  • As mudanças no readinessProbe de um pod não afetam o Entrada depois que ele é criado.

  • Um balanceador de carga de aplicativo externo encerra o TLS em locais distribuídos globalmente, de modo a minimizar a latência entre os clientes e o balanceador de carga. Se você precisar de controle geográfico sobre o local em que o TLS é encerrado, use um controlador de Ingress personalizado exposto por meio de um Serviço do GKE do tipo LoadBalancer e encerre o TLS nos back-ends localizados em regiões adequadas às suas necessidades.

  • Não há suporte para combinar vários recursos do Entrada em um único balanceador de carga Google Cloud .

  • É preciso desativar o TLS mútuo no aplicativo porque ele não tem suporte para balanceadores de carga de aplicativo externos.

  • Entrada só pode expor as portas HTTP 80 e 443 para o front-end.

A seguir