Da borda à malha: expor aplicativos de malha de serviço pelo gateway do GKE

Last reviewed 2023-10-24 UTC

Nesta arquitetura de referência, você verá como combinar o Cloud Service Mesh com o Cloud Load Balancing para expor aplicativos em uma malha de serviço a clientes da Internet.

O Cloud Service Mesh é uma malha de serviço gerenciado e baseado no Istio. Ele oferece uma camada de comunicação padronizada, observável e de segurança aumentada para aplicativos. Uma malha de serviço oferece uma plataforma de comunicação holística para os clientes que se comunicam na malha. No entanto, o desafio permanece em como conectar clientes que estão fora da malha aos aplicativos hospedados na malha.

É possível expor um aplicativo aos clientes de várias maneiras, dependendo de onde o cliente estiver. Essa arquitetura de referência é destinada a profissionais avançados que executam o Cloud Service Mesh, mas também funciona com o Istio no Google Kubernetes Engine (GKE).

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 da 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 esse tráfego externo, você precisa de um balanceador de carga externo para a malha. Essa arquitetura de referência usa o Google Cloud Load Balancing provisionado usando recursos do gateway do GKE para automatizar a implantação.

No Google Cloud, o exemplo canônico dessa configuração é um serviço de balanceamento de carga externo que implanta um balanceador de carga de rede pública (L4). Esse balanceador de carga aponta para os NodePorts de um cluster do GKE. Esses NodePorts expõem os pods de gateway de entrada do Istio, que roteiam o tráfego para proxies sidecar de malha downstream.

Arquitetura

O diagrama a seguir ilustra essa topologia. O balanceamento de carga do tráfego particular interno é semelhante a esta arquitetura, exceto pelo fato de que você implanta um balanceador de carga de rede de passagem interno.

Um balanceador de carga externo encaminha os clientes externos para a malha por meio de proxies de gateway de entrada.

O diagrama anterior mostra que o uso do balanceamento de carga transparente L4 com um gateway de entrada da malha oferece as seguintes vantagens:

  • A configuração simplifica a implantação do balanceador de carga.
  • O balanceador de carga fornece um endereço IP virtual (VIP, na sigla em inglês) estável, uma verificação de integridade e uma distribuição de tráfego confiável quando ocorrem alterações no cluster, interrupções de nó ou de processo.
  • Todas as regras de roteamento, término de TLS e política de tráfego são processadas em um único local no gateway de entrada da malha.

Gateway e Serviços do GKE

Há várias maneiras de fornecer acesso a aplicativos àqueles clientes que estão fora do cluster. O gateway do GKE é uma implementação da API Kubernetes Gateway. O gateway do GKE evolui o recurso de Ingress e o melhora.

À 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:

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

Embora o balanceador de carga padrão do Cloud Service Mesh seja o balanceador de carga de rede, esta arquitetura de referência se concentra no balanceador de carga de aplicativo externo (L7). O balanceador de carga de aplicativo externo fornece integração com serviços de borda, como Identity-Aware Proxy e Google Cloud Armor, redirecionamentos e substituições de URL, bem como uma rede de proxies de borda distribuída globalmente. Na próxima seção, descrevemos a arquitetura e as vantagens do uso de duas camadas de balanceamento de carga HTTP.

Entrada na nuvem e entrada da malha

A implantação do balanceamento de carga L7 externo fora da malha com uma camada de entrada da malha oferece vantagens significativas, especialmente para o tráfego da Internet. Mesmo que os gateways de entrada do Cloud Service Mesh e do Istio forneçam roteamento avançado e gerenciamento de tráfego na malha, algumas funções são melhor veiculadas na extremidade da rede. Aproveitar a rede na extremidade 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 da malha. Esses benefícios incluem:

Essa camada externa de balanceamento de carga L7 é chamada de entrada na nuvem porque ela é criada em balanceadores de carga gerenciados na nuvem, em vez de proxies auto-hospedados usados pela entrada da malha. A combinação de entrada na nuvem e entrada na malha usa recursos complementares da infraestrutura do Google Cloud e da malha. O diagrama a seguir ilustra como combinar a entrada na nuvem (pelo gateway do GKE) e a entrada na malha para que sirva como duas camadas de balanceamento de carga do tráfego da Internet.

A entrada do Cloud age como o gateway do tráfego externo para a malha por meio da rede VPC.

Na topologia do diagrama anterior, a camada de entrada na nuvem origina o 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 de aplicativos hospedados na malha.

Topologia de entrada na nuvem e da malha

Nesta seção, descrevemos os papéis complementares que cada camada de entrada ocupa quando são usados em conjunto. Esses papéis não são regras concretas, mas diretrizes que usam as vantagens de cada camada. É provável que as variações desse padrão sejam baseadas no seu caso de uso.

  • Cloud Ingress: 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. A camada de entrada na nuvem é integrada à proteção contra DDoS, firewalls de nuvem, autenticação e produtos de criptografia na extremidade. Por isso, essa camada se destaca em executar esses serviços fora da malha. A lógica de roteamento costuma ser objetiva nessa camada, mas ela pode ser mais complexa para ambientes multirregionais e com vários clusters. Devido à função crucial dos balanceadores de carga voltados para a Internet, a camada de entrada na nuvem é provavelmente gerenciada por uma equipe de infraestrutura que tem controle exclusivo sobre como os aplicativos são expostos e protegidos na Internet. Esse controle também torna essa camada menos flexível e dinâmica do que uma infraestrutura orientada por desenvolvedores, uma consideração que pode afetar a quem e como você fornece acesso administrativo a essa camada.
  • Mesh Ingress: quando pareada com a entrada na nuvem, a camada de entrada da malha fornece um roteamento flexível parecido com o do aplicativo. Devido a essa flexibilidade, a entrada da malha é melhor que a entrada na nuvem, seguindo a lógica de roteamento complexa e a visibilidade no nível do aplicativo. A separação entre camadas de entrada também facilita aos proprietários de aplicativos na hora de controlar diretamente essa camada sem afetar outras equipes. Para ajudar a proteger os aplicativos ao expor aplicativos da malha de serviço usando um balanceador de carga L4 no lugar de L7, encerre o TLS do cliente na camada de entrada dentro da malha.

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 próxima camada a fim de garantir que ela possa receber tráfego. A topologia do diagrama a seguir mostra como a entrada na nuvem verifica a integridade dos proxies de entrada da malha. Em contrapartida, a malha verifica a integridade dos back-ends do aplicativo.

A entrada do Cloud verifica a integridade da entrada da malha. Por sua vez, a entrada da malha verifica a integridade dos back-ends do aplicativo.

A topologia anterior tem as seguintes considerações:

  • Entrada na nuvem: nesta arquitetura de referência, você configura o balanceador de carga do Google Cloud pelo gateway 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.
  • 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.

Segurança

A topologia anterior também envolve vários elementos de segurança. Um dos elementos mais importantes é a forma de configurar a criptografia e implantar certificados. O gateway do GKE é integrado aos certificados gerenciados pelo Google. É possível consultar um gerenciador de certificados CertificateMap na definição do gateway. 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).

O próximo salto, que fica entre o Google Front End (GFE) e o proxy de entrada da malha, é criptografado por padrão. A criptografia no nível da rede entre os GFEs e respectivos back-ends é aplicada automaticamente. No entanto, 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 criptografia TLS entre o gateway do cluster (o GFE) e a entrada na malha (a instância do proxy envoy). Quando você ativa o HTTP/2 com criptografia TLS para esse caminho, é possível usar um certificado autoassinado ou público para criptografar o tráfego porque o GFE não faz a autenticação nele. Essa camada extra de criptografia é demonstrada no guia de implantação associado. Para ajudar a evitar o mau uso de certificados, não use o certificado público do balanceador de carga público em outro lugar. Em vez disso, recomendamos usar certificados diferentes na malha de serviço.

Se a malha de serviço exigir TLS, todo o tráfego será criptografado entre proxies sidecar e a entrada da malha. O diagrama a seguir ilustra a criptografia HTTPS do cliente ao balanceador de carga do Google Cloud, do balanceador de carga ao proxy de entrada na malha e do proxy de entrada ao proxy sidecar.

A segurança é implementada usando certificados gerenciados fora da malha e certificados internos dentro da malha.

Otimização de custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Implantação

Para implantar essa arquitetura, consulte Da borda à malha: implantar aplicativos da malha de serviço pelo gateway do GKE.

A seguir