Esta arquitetura de referência descreve os benefícios de expor aplicativos externamente usando gateways do Google Kubernetes Engine (GKE) em execução em vários clusters do GKE em uma malha de serviço. Este guia é destinado a administradores de plataforma.
É possível aumentar a resiliência e a redundância dos serviços implantando aplicativos de maneira consistente em vários clusters do GKE, onde cada cluster se torna um domínio de falha adicional. Por exemplo, a infraestrutura de computação de um serviço com um objetivo de nível de serviço (SLO) de 99,9% implantado em um único cluster do GKE atinge um SLO de 99,9999% quando implantado em dois clusters do GKE (1 - (0,001)2). Você também pode fornecer aos usuários uma experiência em que as solicitações recebidas são automaticamente direcionadas para o gateway de entrada de malha menos latente e disponível.
Se você tiver interesse nos benefícios de expor aplicativos habilitados para malha de serviço executados em um único cluster, consulte Da borda à malha: exponha aplicativos de malha de serviço pelo gateway do GKE.
Arquitetura
O diagrama de arquitetura a seguir mostra como os dados fluem pela entrada de nuvem e entrada de malha:
O diagrama anterior mostra os seguintes cenários de fluxo de dados:
- do cliente que encerra no balanceador de carga do Google Cloud usando o próprio Certificado TLS gerenciado pelo Google.
- Do balanceador de carga do Google Cloud para o proxy de entrada de malha usando o próprio certificado TLS autoassinado.
- Do proxy de gateway de entrada da malha para os proxies de arquivo sidecar da carga de trabalho usando mTLS habilitada para malha de serviço.
Esta arquitetura de referência contém as duas camadas de entrada a seguir:
- Entrada de nuvem: nesta arquitetura de referência, você usa a API Kubernetes Gateway (e o GKE Gateway controller) para programar a camada externa de balanceamento de carga HTTP(S) de vários clusters. O balanceador de carga verifica os proxies de entrada de malha em vários regiões, enviando solicitações para o cluster íntegro mais próximo. Ele também implementa uma política de segurança do Google Cloud Armor.
- Entrada de malha: na malha, você realiza verificações de integridade diretamente nos back-ends a fim de executar o balanceamento de carga e o gerenciamento de tráfego localmente.
Ao usar as camadas de entrada juntas, há papéis complementares para cada camada. Para atingir os objetivos a seguir, o Google Cloud otimiza os recursos mais apropriados da camada de entrada da nuvem e da entrada de malha:
- Fornecer baixa latência.
- Aumentar a disponibilidade.
- Usar os recursos de segurança da camada de entrada na nuvem.
- Usar os recursos de segurança, autorização e observabilidade da camada de entrada de malha.
Entrada de nuvem
quando emparelhada com a entrada da malha, a camada de entrada na nuvem é melhor usada para segurança de extremidade e balanceamento de carga global. Como a camada de entrada de nuvem é integrada aos serviços a seguir, ela se sai bem executando esses serviços na borda, fora da malha:
- Proteção contra DDoS
- Firewalls de nuvem
- Autenticação e autorização
- Criptografia
A lógica de roteamento normalmente é simples na camada de entrada de nuvem. No entanto, pode ser mais complexo para ambientes de vários clusters e várias regiões.
Devido à função crucial dos balanceadores de carga voltados para a Internet, a camada de entrada de nuvem é provavelmente gerenciada por uma equipe de plataforma que tem controle exclusivo sobre como os aplicativos são expostos e protegidos na Internet. Esse controle torna essa camada menos flexível e dinâmica do que uma infraestrutura orientar por desenvolvedores. Considere estes fatores ao determinar os direitos de acesso administrativo nessa camada e como você concede esse acesso.
Entrada de malha
Quando pareada com a entrada de nuvem, a camada da entrada de malha oferece um ponto de entrada para que o tráfego entre na malha de serviço. A camada também fornece políticas de autorização de mTLS de back-end e correspondência flexível de regex.
Implantar o balanceamento de carga de aplicativo externo fora da malha com uma camada de entrada de malha oferece vantagens significativas, especialmente para o gerenciamento de tráfego da Internet. Embora a malha de serviço e os gateways de entrada do Istio forneçam roteamento e gerenciamento de tráfego avançados na malha, algumas funções são melhor veiculadas na borda da rede. Aproveitar a rede de borda da Internet por meio do balanceador de carga de aplicativo externo do Google Cloud pode oferecer benefícios significativos de desempenho, confiabilidade ou segurança em relação à entrada de malha.
Produtos e recursos usados
A lista a seguir resume todos os produtos e serviços do Google Cloud que essa arquitetura de referência usa:
- GKE Enterprise: um serviço gerenciado do Kubernetes que pode ser usado para implantar e operar aplicativos conteinerizados em larga escala usando a infraestrutura do Google. Para o propósito desta arquitetura de referência, cada um dos clusters do GKE que veicula um aplicativo precisa estar na mesma frota.
- Frotas e Gateways de vários clusters: serviços usados para criar aplicativos conteinerizados em escala empresarial usando a infraestrutura do Google e o GKE Enterprise.
- Google Cloud Armor: um serviço que ajuda a proteger seus aplicativos e sites contra negação de serviço e ataques na Web.
- Cloud Service Mesh: Uma malha de serviço totalmente gerenciada com base no Envoy e no Istio
- Balanceador de carga de aplicativo: um balanceador de carga L7 baseado em proxy que permite executar e escalonar seus serviços.
- Gerenciador de certificados: um serviço que permite adquirir e gerenciar certificados TLS para uso com o Cloud Load Balancing.
Frotas
Para gerenciar implantações de vários clusters, o GKE Enterprise e o Google Cloud usam frotas para agrupar e normalizar logicamente os clusters do Kubernetes.
O uso de uma ou mais frotas pode ajudar você a aprimorar o gerenciamento de de clusters individuais a grupos inteiros de clusters. Para reduzir o atrito no gerenciamento de clusters, use o princípio de frota de semelhança de namespace. Para cada cluster do GKE em uma frota, configure todos os gateways de entrada de malha da mesma forma.
Além disso, implante consistentemente serviços de aplicativos para que o leitor de balanceamento do serviço na conta do namespace se identifique com um serviço idêntico em cada cluster do GKE na frota. Os princípios de semelhança e confiança pressupostos em uma frota são o que permitem usar toda a gama de recursos ativados por frotas no GKE Enterprise e no Google Cloud.
As regras de roteamento leste-oeste na malha de serviço e nas políticas de tráfego são são processadas na camada da entrada de malha. A camada da entrada da malha é implantada em cada o cluster do GKE na frota. Configure cada gateway da entrada de malha na mesma maneira, aderindo ao princípio de semelhança de namespace da frota.
Embora haja um único cluster de configuração para o Gateway do GKE, sincronize as configurações do gateway do GKE em todos os clusters do GKE na frota.
Se precisar indicar um novo cluster de configuração, use ConfigSync. O ConfigSync ajuda a garantir que todas essas configurações sejam sincronizadas em todos os clusters do GKE na frota e ajuda a evitar a reconciliação com um configuração antiga.
Gateway de entrada da malha
O Istio 0.8 introduziu o gateway de entrada da malha. O gateway fornece um conjunto dedicado de proxies com portas expostas ao tráfego proveniente de fora da malha de serviço. Esses proxies de entrada de malha permitem controlar o comportamento de exposição da rede de modo separado do comportamento de roteamento de aplicativos.
Os proxies também permitem aplicar o roteamento e a política ao tráfego externo da malha antes de chegar ao sidecar de um aplicativo. A entrada da malha define o tratamento de tráfego quando ele chega a um nó da malha. Antes, no entanto, os componentes externos precisam definir como o tráfego chega à malha.
Para gerenciar o tráfego externo, você precisa de um balanceador de carga externo à malha. Para automatizar a implantação, esta arquitetura de referência usa o Cloud Load Balancing, que é provisionado pelos recursos do gateway do GKE.
Gateway do GKE e serviços de vários clusters
Há muitas maneiras de fornecer acesso ao aplicativo para clientes que estão fora do cluster. O gateway do GKE é uma implementação da API Kubernetes Gateway. O gateway do GKE evolui e melhora o recurso Ingress.
À medida que você implanta recursos do gateway do GKE no cluster do GKE, o controlador dele observa os recursos da API Gateway e reconcilia os recursos do Cloud Load Balancing para implementar o comportamento de rede especificado pelos recursos do gateway do GKE.
Ao usar o gateway do GKE, o tipo de balanceador de carga usado para expor aplicativos aos clientes depende em grande parte dos seguintes fatores:
- Se os serviços de back-end estão em um único cluster do GKE ou distribuídos em vários clusters do GKE (na mesma frota).
- O status dos clientes (externos ou internos).
- As capacidades necessárias do balanceador 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ço. As malhas de serviço podem abranger vários clusters do GKE ou podem estar contidas em um único cluster.
No gateway do GKE, esse comportamento é controlado pela especificação da
GatewayClass
apropriada.
Ao se referir a classes de gateway, elas, que podem ser usadas
em cenários de vários clusters, têm um nome de classe que termina em -mc
.
Esta arquitetura de referência discute como expor serviços de aplicativo externamente usando um balanceador de carga de aplicativo externo. No entanto, ao usar o Gateway, também é possível criar um balanceador de carga de aplicativo interno regional de vários clusters.
Para implantar serviços de aplicativo em cenários de vários clusters, defina o os componentes do balanceador de carga do Google Cloud de duas maneiras:
- Ingress de vários clusters e Recursos MultiClusterService
- Gateway de vários clusters e Serviços de vários clusters
Para mais informações sobre essas duas abordagens para implantar aplicativos de serviços, consulte Escolher a API de balanceamento de carga de vários clusters para o GKE.
O Ingress de vários clusters depende da criação de recursos
MultiClusterService
. O gateway de vários clusters depende da criação dos recursos
ServiceExport
e da referência aos recursos
ServiceImport
.
Ao usar um gateway de vários clusters, é possível ativar outras funcionalidades do balanceador de carga do Google Cloud criando Políticas. O guia de implantação associado a esta arquitetura de referência mostra como configurar uma política de segurança do Google Cloud Armor para proteger os serviços de back-end contra scripting em vários sites.
Esses recursos de política são direcionados aos serviços de back-end da frota
expostos em vários clusters. Em cenários de vários clusters, todas essas políticas
precisa referenciar o
recurso ServiceImport
e grupo de APIs.
Verificação de integridade
Uma das complexidades do uso de duas camadas do balanceamento de carga L7 é a verificação de integridade. Você precisa configurar cada balanceador de carga para verificar a integridade da camada seguinte. O gateway do GKE verifica a integridade dos proxies da entrada de malha, e a malha, em troca, verifica a integridade dos back-ends de aplicativos.
- Entrada de nuvem: nesta arquitetura de referência, você configura o balanceador de carga do Google Cloud pelo gateway do GKE para verificar a integridade dos proxies de entrada na malha nas portas de verificação de integridade expostas. Se um proxy de malha estiver inativo ou se o cluster, a malha ou a região não estiverem disponíveis, o balanceador de carga do Google Cloud detectará essa condição e não enviará tráfego ao proxy da malha. Nesse caso, o tráfego seria roteado para um proxy de malha alternativo em um cluster ou região do GKE diferente.
- Entrada da malha: no aplicativo de malha, você realiza verificações de integridade diretamente nos back-ends a fim de executar o balanceamento de carga e o gerenciamento de tráfego localmente.
Considerações sobre o design
Esta seção fornece orientações para ajudar você a usar essa arquitetura de referência para desenvolver uma arquitetura que atenda aos seus requisitos específicos de segurança e compliance, confiabilidade e custo.
segurança, privacidade e conformidade
O diagrama de arquitetura deste documento contém vários elementos de segurança. Os elementos mais importantes são como você configura a criptografia e implanta certificados. O gateway do GKE se integra ao gerenciador de certificados para esses fins de segurança.
Os clientes da Internet se autenticam nos certificados públicos e se conectam ao
balanceador de carga externo como o primeiro salto na nuvem privada virtual (VPC, na sigla em inglês). É
possível consultar um gerenciador de certificados CertificateMap
na definição do gateway.
O próximo salto ocorre entre o Google Front End (GFE, na sigla em inglês) e o proxy de entrada da malha.
Esse salto é
criptografado por padrão.
A criptografia no nível da rede entre os GFEs e respectivos back-ends é aplicada automaticamente. Se os seus requisitos de segurança ditarem que o proprietário da plataforma detenha a propriedade das chaves de criptografia, ative o HTTP/2 com a criptografia TLS entre o gateway do cluster (o GFE) e a entrada de malha (a instância do proxy envoy).
Quando você ativar o HTTP/2 com a criptografia TLS entre o gateway do cluster e a entrada da malha, será possível usar um certificado autoassinado ou público para criptografar tráfego. Você pode usar um certificado autoassinado ou público porque o GFE não fará a autenticação nele. Essa camada extra de criptografia é demonstrada no guia de implantação associado a esta arquitetura de referência.
Para evitar o mau uso de certificados, não reutilize certificados públicos. Usar certificados separados para cada balanceador de carga na malha de serviço.
Para ajudar na criação de entradas DNS externas e certificados TLS, o guia de implantação
desta arquitetura de referência usa o
Cloud Endpoints:
O uso do Cloud Endpoints permite criar um subdomínio
cloud.goog
disponível externamente. Em cenários corporativos, use um nome de domínio mais apropriado,
e crie um registro A que aponte para o endereço
IP do balanceador de carga de aplicativo global
no seu provedor de serviços de DNS.
Se a malha de serviço que você estiver usando exigir TLS, todo o tráfego entre os proxies sidecar e todo o tráfego para a entrada de malha será criptografado. O diagrama da arquitetura mostra a criptografia HTTPS do cliente ao balanceador de carga do Google Cloud, do balanceador de carga ao proxy de entrada de malha e do proxy de entrada ao proxy sidecar.
Confiabilidade e resiliência
Uma das principais vantagens do padrão de borda a malha de várias regiões e vários clusters é que ele possa usar todos os atributos da malha de serviço para balanceamento de carga de leste a oeste, como o tráfego entre serviços de aplicativos.
Esta arquitetura de referência usa um gateway do GKE de cluster para rotear o tráfego de entrada de nuvem para um cluster do GKE. O sistema seleciona um cluster do GKE com base na proximidade dele com o usuário (com base na latência), disponibilidade e integridade dele. Quando o tráfego atinge o gateway de entrada do Istio (a entrada de malha), ele é roteado para os back-ends apropriados por meio da malha de serviço.
Uma abordagem alternativa para lidar com o tráfego de leste a oeste é por meio de
serviços de vários clusters para todos os serviços de aplicativos implantados
nos clusters do GKE. Ao usar serviços de vários clusters em clusters do GKE em uma
frota, os endpoints de serviço são coletados em um
ClusterSet
.
Se um serviço precisa chamar outro serviço, então ele pode visar
qualquer endpoint íntegro para o segundo serviço. Como os endpoints são escolhidos por rotação,
o endpoint selecionado pode estar em uma zona ou região diferente.
Uma das principais vantagens de usar a malha de serviço para o tráfego de leste a oeste em vez de
de serviços de vários clusters é que a malha de serviço pode usar o balanceamento de carga de localidade.
O balanceamento de carga de localidade não é um recurso de vários clusters, mas você
pode configurá-lo por meio de uma
DestinationRule
.
Depois de configurada, a chamada de um serviço para outro primeiro tenta alcançar um endpoint de serviço na mesma zona e depois tenta na mesma região que o serviço de chamada. Por fim, a chamada só visa um endpoint em outra região se um endpoint de serviço na mesma zona ou região não estiver disponível.
Otimização de custos
Ao adotar essa arquitetura de vários clusters de forma ampla em uma empresa, o Cloud Service Mesh e o gateway de vários clusters estão incluídos na edição Enterprise do Google Kubernetes Engine (GKE). Além disso, o GKE Enterprise inclui muitos recursos que permitem gerenciar e governar clusters do GKE, aplicativos e outros processos em grande escala.
Implantação
Para implantar essa arquitetura, consulte Da borda à malha de vários clusters: implante aplicativos distribuídos globalmente com o Gateway do GKE e o Cloud Service Mesh.
A seguir
- Saiba mais sobre mais recursos oferecidos pelo Gateway do GKE que podem ser usados com sua malha de serviço.
- Saiba mais sobre os diferentes tipos de balanceamento de carga na nuvem disponíveis para o GKE.
- Saiba mais sobre os recursos e as funcionalidades oferecidas pelo Cloud Service Mesh.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autores:
- Alex Mattson | Engenheiro especialista em aplicativos
- Mark Chilvers | Engenheiro especialista em aplicativos
Outros colaboradores:
- Abdelfettah Sghiouar | Mediador de desenvolvedores de nuvem
- Arunkumar Jayaraman | Engenheiro principal
- Greg Bray | Engenheiro de clientes
- Megan Yahya | Gerente de produtos
- Paul Revello | Arquiteto de soluções de nuvem
- Valavan Rajakumar | Arquiteto corporativo fundamental
- Maridi Raju Makaraju | Líder de tecnologia de suporte