Da periferia à malha de vários clusters: aplicações distribuídas globalmente expostas através do GKE Gateway e da Cloud Service Mesh

Last reviewed 2024-06-30 UTC

Esta arquitetura de referência descreve as vantagens de expor aplicações externamente através de gateways do Google Kubernetes Engine (GKE) executados em vários clusters do GKE numa malha de serviços. Este guia destina-se a administradores da plataforma.

Pode aumentar a capacidade de recuperação e a redundância dos seus serviços implementando aplicações de forma consistente em vários clusters do GKE, em que cada cluster se torna um domínio de falha adicional. Por exemplo, uma infraestrutura de computação de um serviço com um objetivo de nível de serviço (SLO) de 99,9% quando implementada num único cluster do GKE atinge um SLO de 99,9999% quando implementada em dois clusters do GKE (1 - (0,001)2). Também pode oferecer aos utilizadores uma experiência em que os pedidos recebidos são automaticamente direcionados para o gateway de entrada da malha com menor latência e disponível.

Se tiver interesse nas vantagens de expor aplicações ativadas para a malha de serviços que são executadas num único cluster, consulte o artigo Da extremidade à malha: exponha aplicações de malha de serviços através do GKE Gateway.

Arquitetura

O diagrama de arquitetura seguinte mostra como os dados fluem através da entrada na nuvem e da entrada na malha:

Encriptação TLS do cliente, de um balanceador de carga e da malha.

O diagrama anterior mostra os seguintes cenários de fluxo de dados:

  • Do cliente que termina no Google Cloud balanceador de carga com o seu próprio certificado TLS gerido pela Google.
  • Do Google Cloud equilibrador de carga ao proxy de entrada da malha usando o seu próprio certificado TLS autoassinado.
  • Do proxy de gateway de entrada da malha para os proxies sidecar da carga de trabalho usando o mTLS ativado na malha de serviços.

Esta arquitetura de referência contém as seguintes duas camadas de entrada:

  • Entrada na nuvem: nesta arquitetura de referência, usa a API Kubernetes Gateway (e o controlador GKE Gateway) para programar a camada de balanceamento de carga de HTTP(S) externo de vários clusters. O balanceador de carga verifica os proxies de entrada da malha em várias regiões, enviando pedidos para o cluster em bom estado mais próximo. Também implementa uma política de segurança do Google Cloud Armor.
  • Entrada de malha: na malha, faz verificações de funcionamento nos back-ends diretamente para poder executar o equilíbrio de carga e a gestão de tráfego localmente.

Quando usa as camadas de entrada em conjunto, existem funções complementares para cada camada. Para alcançar os seguintes objetivos, Google Cloud otimiza as funcionalidades mais adequadas da camada de entrada na nuvem e da camada de entrada na malha:

  • Oferecer baixa latência.
  • Aumentar a disponibilidade.
  • Use as funcionalidades de segurança da camada de entrada na nuvem.
  • Use as funcionalidades de segurança, autorização e observabilidade da camada de entrada da malha.

Entrada na nuvem

Quando associada à entrada de malha, a camada de entrada na nuvem é mais bem usada para segurança de limite e balanceamento de carga global. Uma vez que a camada de entrada na nuvem está integrada com os seguintes serviços, destaca-se na execução desses serviços no limite, fora da malha:

  • Proteção da DDoS
  • Firewalls na nuvem
  • Autenticação e autorização
  • Encriptação

Normalmente, a lógica de encaminhamento é simples na camada de entrada na nuvem. No entanto, pode ser mais complexo para ambientes de 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 plataforma que tenha controlo exclusivo sobre a forma como as aplicações são expostas e protegidas na Internet. Este controlo torna esta camada menos flexível e dinâmica do que uma infraestrutura orientada por programadores. Tenha em conta estes fatores ao determinar os direitos de acesso administrativo a esta camada e como fornece esse acesso.

Entrada de malha

Quando associada à entrada na nuvem, a camada de entrada da malha fornece um ponto de entrada para o tráfego entrar na malha de serviço. A camada também fornece mTLS de back-end, políticas de autorização e correspondência de regex flexível.

A implementação do balanceamento de carga de aplicações externas fora da malha com uma camada de entrada da malha oferece vantagens significativas, especialmente para a gestão do tráfego da Internet. Embora a malha de serviços 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 do Google Cloud pode oferecer vantagens significativas relacionadas com o desempenho, a fiabilidade ou a segurança em relação à entrada baseada em malha.Google Cloud

Produtos e funcionalidades usados

A lista seguinte resume todos os Google Cloud produtos e funcionalidades que esta arquitetura de referência usa:

  • GKE Enterprise: Um serviço Kubernetes gerido que pode usar para implementar e operar aplicações em contentores em grande escala através da infraestrutura da Google. Para efeitos desta arquitetura de referência, cada um dos clusters do GKE que publicam uma aplicação tem de estar na mesma frota.
  • Frotas e Gateways de vários clusters: serviços usados para criar aplicações em contentores à escala empresarial usando a infraestrutura da Google e o GKE Enterprise.
  • Google Cloud Armor: Um serviço que ajuda a proteger as suas aplicações e Websites contra negação de serviço e ataques Web.
  • Cloud Service Mesh: Uma malha de serviços totalmente gerida baseada no Envoy e no Istio
  • Balanceador de carga de aplicações: Um balanceador de carga de nível 7 baseado em proxy que lhe permite executar e dimensionar os seus serviços.
  • Gestor de certificados: Um serviço que lhe permite adquirir e gerir certificados TLS para utilização com o Cloud Load Balancing.

Fleets

Para gerir implementações de vários clusters, o GKE Enterprise e Google Cloud usa frotas para agrupar e normalizar logicamente os clusters do Kubernetes.

A utilização de uma ou mais frotas pode ajudar a melhorar a gestão de clusters individuais para grupos inteiros de clusters. Para reduzir a fricção na gestão de clusters, use o princípio de frota da igualdade do espaço de nomes. Para cada cluster do GKE numa frota, certifique-se de que configura todas as gateways de entrada da malha da mesma forma.

Além disso, implemente consistentemente serviços de aplicações para que o leitor de saldo no espaço de nomes da conta esteja relacionado com um serviço idêntico em cada cluster do GKE na frota. Os princípios de igualdade e confiança que são assumidos numa frota são o que lhe permite usar a gama completa de funcionalidades ativadas para frotas no GKE Enterprise e Google Cloud.

As regras de encaminhamento leste-oeste na malha de serviços e as políticas de tráfego são processadas na camada de entrada da malha. A camada de entrada da malha é implementada em todos os clusters do GKE na frota. Configure cada gateway de entrada de malha da mesma forma, seguindo o princípio de igualdade do espaço de nomes da frota.

Embora exista um único cluster de configuração para o GKE Gateway, deve sincronizar as configurações do GKE Gateway em todos os clusters do GKE na frota.

Se precisar de indicar um novo cluster de configuração, use o ConfigSync. O ConfigSync ajuda a garantir que todas essas configurações são sincronizadas em todos os clusters do GKE na frota e ajuda a evitar a conciliação com uma configuração não atual.

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 de malha define o tratamento do tráfego quando atinge um nó na malha, mas os componentes externos têm de definir como o tráfego chega primeiro à malha.

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

GKE Gateway e serviços em vários clusters

Existem várias formas de conceder acesso à aplicação a clientes que estão fora do cluster. O GKE Gateway é uma implementação da API Kubernetes Gateway. O GKE Gateway evolui e melhora o recurso Ingress.

À medida que implementa recursos do GKE Gateway no seu cluster do GKE, o controlador do Gateway monitoriza os recursos da API Gateway. O controlador reconcilia os recursos do Cloud Load Balancing para implementar o comportamento de rede especificado pelos recursos de 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:

  • Se os serviços de back-end estão num único cluster do GKE ou distribuídos por vários clusters do GKE (na mesma frota).
  • 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 Cloud Armor.
  • Os requisitos de abrangência da malha de serviços. As malhas de serviços podem abranger vários clusters do GKE ou podem estar contidas num único cluster.

No Gateway, este comportamento é controlado especificando a GatewayClass adequada. Quando se refere a classes de gateway, as classes que podem ser usadas em cenários com vários clusters têm um nome de classe que termina em -mc.

Esta arquitetura de referência aborda como expor serviços de aplicações externamente através de um Application Load Balancer externo. No entanto, quando usa o Gateway, também pode criar um Application Load Balancer interno regional com vários clusters.

Para implementar serviços de aplicações em cenários com vários clusters, pode definir os Google Cloud componentes do balanceador de carga das seguintes duas formas:

Para mais informações sobre estas duas abordagens à implementação de serviços de aplicações, consulte o artigo Escolha a API de balanceamento de carga de vários clusters para o GKE.

A entrada em vários clusters baseia-se na criação de recursos MultiClusterService. O Multi-cluster Gateway baseia-se na criação de recursos ServiceExport e na referência a recursos ServiceImport.

Quando usa um gateway de vários clusters, pode ativar as capacidades adicionais do equilibrador de carga subjacente criando políticas. Google Cloud O guia de implementação associado a esta arquitetura de referência mostra como configurar uma política de segurança do Google Cloud Armor para ajudar a proteger os serviços de back-end contra scripts entre sites.

Estes recursos de políticas destinam-se aos serviços de back-end na frota que estão expostos em vários clusters. Em cenários com vários clusters, todas essas políticas têm de fazer referência ao recurso ServiceImport e ao grupo de APIs.

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 balanceador de carga para verificar o estado da camada seguinte. O GKE Gateway verifica o estado dos proxies de entrada da malha e, por sua vez, a malha verifica o estado dos back-ends da aplicação.

  • Entrada na nuvem: nesta arquitetura de referência, configura o Google Cloud balanceador de carga através do GKE 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 balanceador de carga deteta esta condição e não envia tráfego para o proxy de malha. Google Cloud Neste caso, o tráfego seria encaminhado para um proxy de malha alternativo num cluster ou numa região do GKE diferente.
  • Entrada de malha: na aplicação de malha, faz verificações de funcionamento nos back-ends diretamente para poder executar o equilíbrio de carga e a gestão de tráfego localmente.

Considerações de design

Esta secção fornece orientações para ajudar a usar esta arquitetura de referência para desenvolver uma arquitetura que cumpra os seus requisitos específicos de segurança e conformidade, fiabilidade e custo.

Segurança, privacidade e conformidade

O diagrama de arquitetura neste documento contém vários elementos de segurança. Os elementos mais importantes são a forma como configura a encriptação e implementa certificados. O GKE Gateway integra-se com o Certificate Manager para estes fins de segurança.

Os clientes da Internet autenticam-se com certificados públicos e ligam-se ao balanceador de carga externo como o primeiro salto na nuvem virtual privada (VPC). Pode consultar um gestor de certificados CertificateMap na definição do gateway. O próximo salto está entre o front-end da Google (GFE) e o proxy de entrada da malha. Esse salto está encriptado por predefinição.

A encriptação ao nível da rede entre os GFEs e os respetivos back-ends é aplicada automaticamente. 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 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 entre o gateway do cluster e a entrada do mesh, pode usar um certificado público ou autoassinado para encriptar o tráfego. Pode usar um certificado público ou autoassinado, uma vez que o GFE não faz a autenticação junto do mesmo. Esta camada adicional de encriptação é demonstrada no guia de implementação associado a esta arquitetura de referência.

Para ajudar a evitar o manuseamento incorreto de certificados, não reutilize certificados públicos. Use certificados separados para cada equilibrador de carga na malha de serviço.

Para ajudar a criar entradas DNS externas e certificados TLS, o guia de implementação desta arquitetura de referência usa o Cloud Endpoints. A utilização dos Cloud Endpoints permite-lhe criar um cloud.googsubdomínio disponível externamente. Em cenários ao nível empresarial, use um nome de domínio mais adequado e crie um registo A que aponte para o endereço IP do Application Load Balancer global no seu fornecedor de serviços DNS.

Se a malha de serviços que está a usar exigir TLS, todo o tráfego entre os proxies sidecar e todo o tráfego para a entrada da malha é encriptado. O diagrama de arquitetura mostra 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.

Fiabilidade e resiliência

Uma vantagem fundamental do padrão de vários clusters e várias regiões de edge-to-mesh é que pode usar todas as funcionalidades da malha de serviços para o equilíbrio de carga de este a oeste, como o tráfego entre serviços de aplicações.

Esta arquitetura de referência usa um GKE de vários clusters Gateway para encaminhar o tráfego de entrada na nuvem para um cluster do GKE. O sistema seleciona um cluster do GKE com base na respetiva proximidade ao utilizador (com base na latência), bem como na disponibilidade e no estado. Quando o tráfego atinge o gateway de entrada do Istio (a entrada da malha), é encaminhado para os back-ends adequados através da malha de serviços.

Uma abordagem alternativa para processar o tráfego leste-oeste é através de serviços de vários clusters para todos os serviços de aplicações implementados em clusters do GKE. Quando usa serviços de vários clusters em clusters do GKE numa frota, os pontos finais de serviço são recolhidos num ClusterSet. Se um serviço precisar de chamar outro serviço, pode segmentar qualquer ponto final em bom estado de funcionamento para o segundo serviço. Uma vez que os pontos finais são escolhidos de forma rotativa, o ponto final selecionado pode estar numa zona ou numa região diferente.

Uma vantagem fundamental da utilização da malha de serviços para o tráfego leste-oeste em vez da utilização de serviços de vários clusters é que a malha de serviços pode usar o equilíbrio de carga de localidade. O equilíbrio de carga de localidade não é uma funcionalidade dos serviços de vários clusters, mas pode configurá-lo através de um DestinationRule.

Depois de configurada, uma chamada de um serviço para outro tenta primeiro alcançar um ponto final do serviço na mesma zona e, em seguida, tenta na mesma região que o serviço de chamadas. Por último, a chamada apenas segmenta um ponto final noutra região se um ponto final de serviço na mesma zona ou na mesma região estiver indisponível.

Otimização de custos

Quando adota esta arquitetura de vários clusters de forma abrangente numa empresa, o Cloud Service Mesh e o gateway de vários clusters estão incluídos na edição Google Kubernetes Engine (GKE) Enterprise. Além disso, o GKE Enterprise inclui muitas funcionalidades que lhe permitem gerir e governar clusters do GKE, aplicações e outros processos em grande escala.

Implementação

Para implementar esta arquitetura, consulte o artigo Do limite à malha de vários clusters: implemente aplicações distribuídas globalmente através do GKE Gateway e da Cloud Service Mesh.

O que se segue?

Colaboradores

Autores:

Outros colaboradores: