Sobre gateways de vários clusters

Neste documento, descrevemos como os gateways de vários clusters operam no Google Kubernetes Engine (GKE). Os gateways de vários clusters são uma solução de rede poderosa que permite gerenciar o tráfego de serviços implantados em vários clusters do GKE.

Este documento é destinado a arquitetos de nuvem e especialistas em redes que projetam e arquitetam a rede da organização. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Papéis e tarefas comuns de usuário corporativo do GKE Enterprise.

Visão geral

O gateway de vários clusters é configurado usando os recursos da API Gateway do Kubernetes. O controlador de gateway do GKE monitora esses recursos (Gateway, HTTPRoute e TLSRoute) e provisiona e mantém automaticamente a infraestrutura de balanceamento de carga Google Cloud necessária. Essa infraestrutura oferece gerenciamento avançado de tráfego para serviços implantados em vários clusters do GKE em uma frota. Os gateways de vários clusters usam a infraestrutura de balanceamento de carga do Google Cloudpara fornecer um único ponto de entrada unificado para seus aplicativos. Essa abordagem tem os seguintes benefícios:

  • Simplifica o gerenciamento
  • Melhora a confiabilidade
  • Ativa recursos avançados de gerenciamento de tráfego

Recursos de gerenciamento de tráfego

Os gateways de vários clusters oferecem recursos avançados para gerenciar o tráfego em vários clusters. É possível implementar estratégias de roteamento sofisticadas, como lançamentos em fases e estratégias azul-verde, para implantar mudanças com segurança. Para um controle mais detalhado, use a correspondência baseada em cabeçalho para testar mudanças com uma pequena porcentagem de tráfego ou divida o tráfego por peso para mudar gradualmente as solicitações entre diferentes back-ends de cluster.

Os gateways de vários clusters também permitem espelhar o tráfego, o que envia uma cópia das solicitações de usuários ativos para um novo serviço para testar o desempenho sem afetar os usuários. Para garantir a confiabilidade e evitar sobrecargas, os gateways de vários clusters são compatíveis com failover baseado em integridade e balanceamento de carga baseado em capacidade, que distribui solicitações com base na capacidade definida dos serviços.

Para o tráfego TLS que exige criptografia de ponta a ponta sem encerrar o TLS no balanceador de carga, os gateways de vários clusters são compatíveis com o roteamento baseado em SNI com TLSRoute.

Como funciona o gateway de vários clusters

Todos os clusters do GKE que participam de uma configuração de gateway de vários clusters precisam ser registrados em uma frota. Uma frota fornece um grupo lógico de clusters, o que permite o gerenciamento e a comunicação consistentes entre os clusters. Um cluster do GKE na frota é designado como o cluster de configuração.

O cluster de configuração atua como um ponto de controle centralizado para a configuração do gateway de vários clusters. Você implanta todos os recursos da API Gateway de vários clusters, como Gateway, HTTPRoute e TLSRoute, apenas nesse cluster designado. O controlador de gateway do GKE observa o servidor de API Kubernetes do cluster de configuração para esses recursos.

Para escolher um cluster de configuração, considere um cluster regional ou outro cluster do GKE de alta disponibilidade. Isso ajuda a garantir que as atualizações dos recursos da API Gateway possam ser reconciliadas continuamente pelo controlador.

O controlador de gateway de vários clusters usa serviços de vários clusters (MCS, na sigla em inglês) para descobrir e acessar serviços do Kubernetes em vários clusters do GKE em uma frota. O MCS é um recurso do GKE que permite a descoberta de serviços e a conectividade entre Serviços executados em diferentes clusters do GKE em uma frota.

O MCG usa o MCS para descobrir quais Serviços estão disponíveis em quais clusters para rotear o tráfego externo para os Serviços. O controlador do MCG usa recursos da API MCS para agrupar pods em um único serviço endereçável e que abrange vários clusters.

Com base nas configurações definidas nos recursos da API Gateway, o controlador de gateway do GKE fornece um balanceador de carga de aplicativo externo ou interno (para HTTPRoute) ou um balanceador de carga de rede de proxy (para TLSRoute). Esse balanceador de carga serve como front-end para o aplicativo e distribui o tráfego diretamente para os pods íntegros em toda a frota, independentemente da localização.

As etapas gerais a seguir descrevem o processo de implantação de um gateway de vários clusters:

  1. Definir um gateway: em uma configuração de gateway de vários clusters, você cria um recurso de gateway que define o ponto de entrada do tráfego no cluster de configuração. O recurso Gateway especifica uma GatewayClass, que é um modelo para um tipo específico de balanceador de carga, como um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo interno regional. No GKE, as seguintes GatewayClasses implantam gateways de vários clusters:

    • gke-l7-global-external-managed-mc: provisiona um balanceador de carga de aplicativo externo global.
    • gke-l7-regional-external-managed-mc: provisiona um balanceador de carga de aplicativo externo regional ou um balanceador de carga de rede de proxy externo regional.
    • gke-l7-cross-regional-internal-managed-mc: provisiona um balanceador de carga de aplicativo interno entre regiões ou um balanceador de carga de rede de proxy interno entre regiões.
    • gke-l7-rilb-mc: provisiona um balanceador de carga de aplicativo interno regional ou um balanceador de carga de rede de proxy interno regional.
    • gke-l7-gxlb-mc: provisiona um balanceador de carga de aplicativo clássico.

    O gateway também define como o balanceador de carga detecta o tráfego de entrada, especificando quais listeners de rede (portas e protocolos) serão expostos. Para mais informações sobre as classes de gateway compatíveis com o GKE, consulte Serviços multicluster.

  2. Anexar recursos de rota ao gateway: os recursos de rota definem como o balanceador de carga roteia o tráfego de entrada para serviços de back-end específicos:

    • HTTPRoute: define como o balanceador de carga roteia o tráfego HTTP e HTTPS com base em nomes de host, caminhos, cabeçalhos e parâmetros de consulta. Oferece suporte à divisão de tráfego, ao redirecionamento de solicitações e ao espelhamento de tráfego.
    • TLSRoute: define como o balanceador de carga roteia o tráfego TLS criptografado com base no nome do host SNI usando a passagem de TLS (compatível com as GatewayClasses gke-l7-regional-external-managed-mc, gke-l7-rilb-mc e gke-l7-cross-regional-internal-managed-mc). O balanceador de carga encaminha o tráfego diretamente para as ServiceImports de back-end sem descriptografar o payload no gateway.
  3. Criar balanceador de carga: quando você implanta recursos de gateway e rota, o controlador de gateway do GKE interpreta esses objetos de API e, por sua vez, configura dinamicamente a infraestrutura de balanceamento de carga Google Cloud necessária. O balanceador de carga direciona o tráfego para os pods corretos, independentemente do cluster em que eles estão. Esse processo oferece uma maneira altamente eficiente e escalonável de rotear o tráfego.

Fluxo de tráfego

O diagrama a seguir ilustra como um gateway de vários clusters funciona como um balanceador de carga centralizado para aplicativos executados em dois clusters do GKE em regiões diferentes:

Arquitetura do gateway de vários clusters no GKE.
Figura: arquitetura do gateway de vários clusters

O comportamento do balanceador de carga é configurado com base nas regras definidas nos recursos HTTPRoute ou TLSRoute. Quando o tráfego do usuário chega ao endereço IP do balanceador de carga Google Cloud provisionado (conforme definido pelo recurso de gateway), o balanceador de carga, que é um proxy gerenciado pelo Google, roteia o tráfego. Esse proxy (um proxy do Google Front End ou um proxy regional) direciona o tráfego para o endpoint de serviço de back-end apropriado no cluster do GKE correto, com base nos seguintes critérios:

  • Verificações de integridade
  • Regras de divisão de tráfego
  • Capacidade

O tráfego flui diretamente para o pod ideal no cluster selecionado.

A seguir