Da extremidade à malha: exponha aplicações de malha de serviços através do GKE Gateway

Last reviewed 2023-10-24 UTC

Esta arquitetura de referência mostra como combinar o Cloud Service Mesh com o Cloud Load Balancing para expor aplicações numa malha de serviços a clientes da Internet.

O Cloud Service Mesh é uma malha de serviços gerida, baseada no Istio, que fornece uma camada de comunicação observável, padronizada e com segurança melhorada para aplicações. Uma malha de serviço oferece uma plataforma de comunicações holística para clientes que estão a comunicar na malha. No entanto, continua a existir um desafio na forma de ligar clientes que estão fora da malha a aplicações alojadas dentro da malha.

Pode expor uma aplicação aos clientes de várias formas, consoante a localização do cliente. Esta arquitetura de referência destina-se a profissionais avançados que executam o Cloud Service Mesh, mas também funciona para o Istio no Google Kubernetes Engine (GKE).

Gateway de entrada de malha

O Istio 0.8 introduziu a gateway de entrada da malha. O gateway fornece um conjunto dedicado de proxies cujas portas estão expostas ao tráfego proveniente de fora da malha de serviço. Estes proxies de entrada de malha permitem-lhe controlar o comportamento de exposição da rede separadamente do comportamento de encaminhamento da aplicação.

Os proxies também permitem aplicar o encaminhamento e a política ao tráfego externo à malha antes de chegar a um sidecar da aplicação. A entrada da malha define o tratamento do tráfego quando este atinge um nó na malha, mas os componentes externos têm de definir como o tráfego chega primeiro à malha.

Para gerir este tráfego externo, precisa de um balanceador de carga externo à malha. Esta arquitetura de referência usa o Google Cloud Load Balancing aprovisionado através de recursos do GKE Gateway para automatizar a implementação.

Para Google Cloud, o exemplo canónico desta configuração é um serviço de balanceamento de carga externo que implementa um balanceador de carga de rede público (L4). Esse balanceador de carga aponta para as NodePorts de um cluster do GKE. Estes NodePorts expõem os pods do gateway de entrada do Istio, que encaminham o tráfego para proxies sidecar de malha a jusante.

Arquitetura

O diagrama seguinte ilustra esta topologia. O balanceamento de carga para tráfego privado interno é semelhante a esta arquitetura, exceto que implementa um balanceador de carga de rede de passagem interno.

Um balanceador de carga externo encaminha clientes externos para a malha através de proxies de gateway de entrada.

O diagrama anterior mostra que a utilização do equilíbrio de carga transparente de nível 4 com um gateway de entrada de malha oferece as seguintes vantagens:

  • A configuração simplifica a implementação do balanceador de carga.
  • O balanceador de carga fornece um endereço IP virtual (VIP) estável, verificações de estado e distribuição de tráfego fiável quando ocorrem alterações ao cluster, falhas de nós ou falhas de processos.
  • Todas as regras de encaminhamento, a terminação de TLS e a política de tráfego são processadas numa localização única no gateway de entrada da malha.

GKE Gateway e serviços

Pode fornecer acesso a aplicações para clientes que estão fora do cluster de várias formas. O GKE Gateway é uma implementação da API Kubernetes Gateway. O GKE Gateway evolui o recurso Ingress e melhora-o.

À medida que implementa recursos do GKE Gateway no seu cluster do GKE, o controlador do Gateway monitoriza os recursos da API Gateway e reconcilia os recursos do Cloud Load Balancing para implementar o comportamento de rede especificado pelos recursos do GKE Gateway.

Quando usa o GKE Gateway, o tipo de equilibrador de carga que usa para expor aplicações a clientes depende em grande parte dos seguintes fatores:

  • O estado dos clientes (externos ou internos).
  • As capacidades necessárias do equilibrador de carga, incluindo a capacidade de integração com as políticas de segurança do Google Cloud Armor.
  • Os requisitos de abrangência da malha de serviços. As malhas de serviço podem abranger vários clusters do GKE ou podem estar contidas num único cluster.

No GKE Gateway, este comportamento é controlado especificando a GatewayClass adequada.

Embora o balanceador de carga predefinido para o Cloud Service Mesh seja o Network Load Balancer, esta arquitetura de referência foca-se no Application Load Balancer externo (L7). O Application Load Balancer externo oferece integração com serviços de limite, como o Identity-Aware Proxy e o Google Cloud Armor, redirecionamentos e reescritas de URLs, bem como uma rede distribuída globalmente de proxies de limite. A secção seguinte descreve a arquitetura e as vantagens de usar duas camadas de equilíbrio de carga HTTP.

Entrada na nuvem e entrada na malha

A implementação do balanceamento de carga L7 externo fora da malha, juntamente com uma camada de entrada da malha, oferece vantagens significativas, especialmente para o tráfego da Internet. Embora a malha de serviços na nuvem e os gateways de entrada do Istio ofereçam encaminhamento e gestão de tráfego avançados na malha, algumas funções são melhor servidas no limite da rede. Tirar partido da rede de limite da Internet através do Application Load Balancer externo doGoogle Cloudpode oferecer vantagens significativas relacionadas com o desempenho, a fiabilidade ou a segurança em relação à entrada baseada em malha. Estas vantagens incluem o seguinte:

Esta camada externa de balanceamento de carga de nível 7 é denominada entrada na nuvem porque é criada em balanceadores de carga geridos na nuvem, em vez dos proxies alojados por si que são usados pela entrada na malha. A combinação da entrada na nuvem e da entrada na malha usa capacidades complementares da Google Cloud infraestrutura Google Cloud e da malha. O diagrama seguinte ilustra como pode combinar a entrada na nuvem (através do gateway do GKE) e a entrada na malha para servir como duas camadas de equilíbrio de carga para o tráfego da Internet.

A entrada na nuvem funciona como a entrada para o tráfego externo na malha através da rede da VPC.

Na topologia do diagrama anterior, a camada de entrada na nuvem origina tráfego de fora da malha de serviço e direciona esse tráfego para a camada de entrada na malha. Em seguida, a camada de entrada da malha direciona o tráfego para os back-ends da aplicação alojada na malha.

Topologia de entrada de nuvem e malha

Esta secção descreve as funções complementares que cada camada de entrada cumpre quando as usa em conjunto. Estes papéis não são regras concretas, mas sim diretrizes que usam as vantagens de cada camada. É provável que existam variações deste padrão, consoante o seu exemplo de utilização.

  • Entrada na nuvem: quando associada à entrada na malha, a camada de entrada na nuvem é mais adequada para a segurança de limite e o balanceamento de carga global. Uma vez que a camada de entrada na nuvem está integrada com a proteção contra DDoS, as firewalls na nuvem, a autenticação e os produtos de encriptação na extremidade, esta camada destaca-se na execução destes serviços fora da malha. A lógica de encaminhamento é normalmente simples nesta camada, mas pode ser mais complexa para ambientes com vários clusters e várias regiões. Devido à função crítica dos equilibradores de carga virados para a Internet, é provável que a camada de entrada na nuvem seja gerida por uma equipa de infraestrutura que tenha controlo exclusivo sobre a forma como as aplicações são expostas e protegidas na Internet. Este controlo também torna esta camada menos flexível e dinâmica do que uma infraestrutura orientada pelo programador, uma consideração que pode afetar quem e como fornece acesso administrativo a esta camada.
  • Entrada de malha: quando sincronizada com a entrada na nuvem, a camada de entrada de malha oferece um encaminhamento flexível próximo da aplicação. Devido a esta flexibilidade, a entrada de rede é melhor do que a entrada na nuvem para uma lógica de encaminhamento complexa e visibilidade ao nível da aplicação. A separação entre as camadas de entrada também facilita o controlo direto desta camada por parte dos proprietários das aplicações sem afetar outras equipas. Para ajudar a proteger as aplicações, quando expõe aplicações de malha de serviços através de um equilibrador de carga L4 em vez de um equilibrador de carga L7, deve terminar o TLS do cliente na camada de entrada da malha no interior da malha.

Verificação de funcionamento

Uma das complexidades da utilização de duas camadas de balanceamento de carga da camada 7 é a verificação de funcionamento. Tem de configurar cada equilibrador de carga para verificar o estado da camada seguinte para garantir que pode receber tráfego. A topologia no diagrama seguinte mostra como a entrada na nuvem verifica o estado dos proxies de entrada da malha e, por sua vez, a malha verifica o estado dos back-ends da aplicação.

A entrada na nuvem verifica o estado de funcionamento da entrada na malha e a entrada na malha verifica o estado de funcionamento dos back-ends da aplicação.

A topologia anterior tem as seguintes considerações:

  • Entrada na nuvem: nesta arquitetura de referência, configura o Google Cloud balanceador de carga através do gateway para verificar o estado dos proxies de entrada da malha nas respetivas portas de verificação de funcionamento expostas. Se um proxy de malha estiver inativo ou se o cluster, a malha ou a região estiverem indisponíveis, o Google Cloudequilibrador de carga deteta esta condição e não envia tráfego para o proxy de malha.
  • Entrada de malha: na aplicação de malha, executa verificações de funcionamento nos back-ends diretamente para poder executar o equilíbrio de carga e a gestão de tráfego localmente.

Segurança

A topologia anterior também envolve vários elementos de segurança. Um dos elementos mais críticos é a forma como configura a encriptação e implementa os certificados. O GKE Gateway integra-se com os certificados geridos pela Google. Pode consultar um Gestor de certificados CertificateMap na definição da gateway. Os clientes da Internet autenticam-se com os certificados públicos e ligam-se ao balanceador de carga externo como o primeiro salto na nuvem virtual privada (VPC).

O próximo salto, que se encontra entre o front-end da Google (GFE) e o proxy de entrada de malha, é encriptado por predefinição. A encriptação ao nível da rede entre os GFEs e os respetivos back-ends é aplicada automaticamente. No entanto, se os seus requisitos de segurança ditarem que o proprietário da plataforma mantém a propriedade das chaves de encriptação, pode ativar o HTTP/2 com a encriptação TLS entre o gateway do cluster (o GFE) e a entrada de malha (a instância do proxy do Envoy). Quando ativa o HTTP/2 com a encriptação TLS para este caminho, pode usar um certificado autoassinado ou público para encriptar o tráfego porque o GFE não faz a autenticação em relação ao mesmo. Esta camada adicional de encriptação é demonstrada no guia de implementação associado. Para ajudar a evitar o manuseamento incorreto de certificados, não use o certificado público para o equilibrador de carga público noutro local. Em alternativa, recomendamos que use certificados separados na malha de serviços.

Se a malha de serviços exigir o TLS, todo o tráfego é encriptado entre os proxies sidecar e a entrada da malha. O diagrama seguinte ilustra a encriptação HTTPS do cliente para o Google Cloud balanceador de carga, do balanceador de carga para o proxy de entrada da malha e do proxy de entrada para o proxy sidecar.

A segurança é implementada através de certificados geridos fora da malha e certificados internos dentro da malha.

Otimização de custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

Implementação

Para implementar esta arquitetura, consulte o artigo Do limite à malha: implemente aplicações de malha de serviços através do GKE Gateway.

O que se segue?