Usar o Gerenciamento de API do Azure com microsserviços implantados no Serviço de Kubernetes do Azure

APLICA-SE A: todas as camadas do Gerenciamento de API

Os microsserviços são perfeitos para a criação de APIs. Você pode usar o AKS (Serviço de Kubernetes do Azure) para implantar e operar rapidamente uma arquitetura baseada em microsserviços na nuvem. Em seguida, você pode usar o Gerenciamento de API do Azure para publicar seus microsserviços como APIs para consumo interno e externo. Este artigo descreve as opções para usar o Gerenciamento de API para publicar arquiteturas baseadas em microsserviços do AKS como APIs. Ele pressupõe um conhecimento básico do Kubernetes, do Gerenciamento de API e da rede do Azure.

Tela de fundo

Quando você publica microsserviços como APIs para consumo, pode ser desafiador gerenciar a comunicação entre os microsserviços e os clientes que os consomem. As questões transversais incluem autenticação, autorização, controle de limite, cache, transformação e monitoramento. Essas preocupações se aplicam independentemente de os microsserviços serem expostos a clientes internos ou externos.

O padrão de gateway de API resolve essas preocupações. Um gateway de API serve como uma porta de entrada para os microserviços, desacopla clientes de seus microserviços, adiciona outra camada de segurança e diminui a complexidade de seus microserviços aliviando a responsabilidade de gerenciar preocupações transversais.

O Gerenciamento de API é uma solução turnkey para resolver suas necessidades de gateway de API. Você pode criar rapidamente um gateway consistente e moderno para seus microsserviços e publicá-los como APIs. Como uma solução de gerenciamento de API de ciclo de vida completo, ela também fornece recursos adicionais, incluindo um portal de desenvolvedor de autoatendimento para descoberta de API, gerenciamento de ciclo de vida de API e análise de API.

Quando usados juntos, o AKS e o Gerenciamento de API fornecem uma plataforma para implantar, publicar, proteger, monitorar e gerenciar suas APIs baseadas em microsserviços. Este artigo descreve algumas opções para implantar o AKS em conjunto com o Gerenciamento de API.

Serviços e APIs do Kubernetes

Em um cluster do Kubernetes, os contêineres são implantados em pods, que são efêmeros e têm um ciclo de vida. Quando um nó de trabalho falha, os pods em execução no nó são perdidos. Portanto, o endereço IP de um Pod pode ser alterado a qualquer momento. Você não pode confiar nele para se comunicar com o pod.

Para resolver esse problema, o Kubernetes introduziu o conceito de Serviços. Um Serviço Kubernetes é uma camada de abstração que define um grupo lógico de Pods e permite a exposição de tráfego externo, o balanceamento de carga e a descoberta de serviço para esses Pods.

Quando estiver pronto para publicar seus microsserviços como APIs usando o Gerenciamento de API, você precisará pensar em como mapear seus serviços no Kubernetes para APIs no Gerenciamento de API. Não há regras definidas para esse mapeamento. Isso dependerá de como você criou e particionou as funcionalidades de negócios ou os domínios nos microsserviços no início. Por exemplo, se os Pods por trás de um Serviço forem responsáveis por todas as operações em um determinado recurso (por exemplo, Cliente), você poderá mapear o Serviço para uma API. Se as operações em um recurso forem particionadas em vários microsserviços (por exemplo, GetOrder e PlaceOrder), você poderá agregar vários Serviços em uma única API no Gerenciamento de API. (Consulte o diagrama a seguir.)

Os mapeamentos também podem evoluir. Como o Gerenciamento de API cria uma fachada diante dos microsserviços, ele permite refatorar e dimensionar seus microsserviços ao longo do tempo.

Diagrama que mostra diferentes mapeamentos de serviços para APIs.

Implantar o Gerenciamento de API na frente do AKS

Há algumas opções para implantar o Gerenciamento de API na frente de um cluster do AKS.

Um cluster do AKS sempre é implantado em uma rede virtual, mas uma instância de Gerenciamento de API não é necessariamente implantada em uma rede virtual. Quando o Gerenciamento de API não reside na rede virtual do cluster, o cluster do AKS precisa publicar endpoints públicos para permitir a conexão do Gerenciamento de API. Nesse caso, você precisa proteger a conexão entre o Gerenciamento de API e o AKS. Em outras palavras, você precisa garantir que o cluster só possa ser acessado por meio do Gerenciamento de API. As seções a seguir descrevem as opções para implantar o Gerenciamento de API na frente do AKS.

Opção 1: expor os serviços publicamente

Você pode expor publicamente os Serviços em um cluster do AKS usando os tipos NodePort, LoadBalancer ou ExternalName Service. Quando você faz isso, os serviços são acessíveis diretamente da Internet pública. Depois de implantar o Gerenciamento de API na frente do cluster, você precisa garantir que todo o tráfego de entrada passe pelo Gerenciamento de API aplicando a autenticação nos microsserviços. Por exemplo, o Gerenciamento de API pode incluir um token de acesso em cada solicitação feita ao cluster. Cada microsserviço deve validar o token antes de processar a solicitação.

Essa opção pode fornecer a maneira mais fácil de implantar o Gerenciamento de API na frente do AKS, especialmente se você já tiver a lógica de autenticação implementada em seus microsserviços.

Diagrama que mostra diretamente uma arquitetura para os serviços de publicação.

Prós:

  • Configuração fácil no lado do Gerenciamento de API porque o Gerenciamento de API não precisa ser injetado na rede virtual do cluster
  • Nenhuma alteração no lado do AKS se os serviços já estão expostos publicamente e se a lógica de autenticação já existe nos microsserviços

Contras:

  • Cria um risco potencial de segurança devido à visibilidade pública dos endpoints.
  • Não cria um único ponto de entrada para o tráfego de entrada do cluster
  • Complica os microsserviços com uma lógica de autenticação duplicada

Opção 2: instalar um controlador de entrada

Embora a opção 1 possa ser mais fácil, ela tem desvantagens notáveis, como observado anteriormente. Se uma instância de Gerenciamento de API não residir na rede virtual do cluster, a autenticação TLS mútua (mTLS) será uma maneira robusta de garantir que o tráfego seja seguro e confiável em ambas as direções entre uma instância de Gerenciamento de API e um cluster do AKS.

A autenticação de TLS mútua tem suporte nativo do Gerenciamento de API. Você pode habilitá-lo no Kubernetes instalando um controlador de entrada. (Consulte o diagrama a seguir.) Como resultado, a autenticação é executada no controlador de entrada, o que simplifica os microsserviços. Além disso, em camadas de serviço que dão suporte a endereços IP dedicados, você pode adicionar os endereços IP do Gerenciamento de API à lista de permissões de entrada para garantir que somente o Gerenciamento de API tenha acesso ao cluster.

Diagrama que mostra uma arquitetura para publicação por meio de um controlador de entrada.

Prós:

  • Habilita a configuração fácil no lado do Gerenciamento de API porque o Gerenciamento de API não precisa ser injetado na rede virtual do cluster e o mTLS tem suporte nativo
  • Centraliza a proteção para o tráfego de cluster de entrada na camada do controlador de entrada
  • Reduz o risco de segurança minimizando os pontos de extremidade de cluster visíveis publicamente

Contras:

  • Aumenta a complexidade da configuração do cluster porque você precisa instalar, configurar e manter o controlador de entrada e gerenciar certificados usados para mTLS
  • Adiciona risco de segurança devido à visibilidade pública dos pontos de extremidade do controlador de entrada, a menos que você use a camada Standard v2 ou Premium de Gerenciamento de API

Quando você publica APIs por meio do Gerenciamento de API, é fácil e típico proteger o acesso a essas APIs usando chaves de assinatura. Os desenvolvedores que precisam consumir as APIs publicadas devem incluir uma chave de assinatura válida em solicitações HTTP ao fazer chamadas para essas APIs. Caso contrário, as chamadas serão imediatamente rejeitadas pelo gateway de Gerenciamento de API. Elas não são encaminhadas para os serviços de back-end.

Para obter uma chave de assinatura para acessar APIs, os desenvolvedores precisam de uma assinatura. A assinatura é essencialmente um contêiner nomeado para um par de chaves de assinatura. Os desenvolvedores que precisam consumir as APIs publicadas podem obter as assinaturas. Eles não precisam de aprovação dos editores de API. Os editores de API também podem criar assinaturas diretamente para os consumidores da API.

Opção 3: Implantar o Gerenciamento de API dentro da rede virtual do cluster

Em alguns casos, os clientes que têm restrições regulatórias ou requisitos de segurança estritos podem achar as Opções 1 e 2 inviáveis devido aos pontos de extremidade expostos publicamente. Em outros, o cluster do AKS e os aplicativos que consomem os microsserviços podem residir na mesma rede virtual, portanto, não há razão para expor o cluster publicamente porque todo o tráfego de API permanece dentro da rede virtual. Nesses cenários, você pode implantar o Gerenciamento de API na rede virtual do cluster. As camadas de Desenvolvedor, Premium e Premium v2 de Gerenciamento de API (versão prévia) dão suporte à injeção na rede virtual do cluster.

Há dois modos de implantação do Gerenciamento de API em uma rede virtual: externo e interno. Atualmente, o modo externo só está disponível nas camadas clássicas do Gerenciamento de API.

Se os consumidores de API não residirem na rede virtual do cluster, você deverá usar o modo externo. (Consulte o diagrama a seguir.) Nesse modo, o gateway de Gerenciamento de API é injetado na rede virtual do cluster, mas acessível pela Internet pública por meio de um balanceador de carga externo. Essa arquitetura ajuda a ocultar completamente o cluster enquanto ainda permite que clientes externos consumam os microsserviços. Além disso, você pode usar recursos de rede do Azure, como NSG (Grupos de Segurança de Rede) para restringir o tráfego de rede.

Diagrama que mostra uma arquitetura que usa o modo de rede virtual externo.

Se todos os consumidores de API residirem na rede virtual do cluster, você poderá usar o modo interno. (Consulte o diagrama a seguir.) Nesse modo, o gateway de Gerenciamento de API é injetado na rede virtual do cluster e acessível somente de dentro dessa rede virtual por meio de um balanceador de carga interno. Não há como acessar o gateway de Gerenciamento de API ou o cluster do AKS da Internet pública.

Diagrama que mostra uma arquitetura que usa o modo de rede virtual interno.

O cluster do AKS não é publicamente visível em ambos os casos. Ao contrário da Opção 2, o controlador de entrada pode não ser necessário. Dependendo do cenário e da configuração, a autenticação ainda pode ser necessária entre o Gerenciamento de API e os microsserviços. Por exemplo, se você usar uma malha de serviço, sempre precisará de autenticação TLS mútua.

Prós:

  • Fornece a opção mais segura porque o cluster do AKS não tem nenhum ponto de extremidade público
  • Simplifica a configuração do cluster porque não há nenhum ponto de extremidade público
  • Fornece a capacidade de ocultar o Gerenciamento de API e o AKS dentro da rede virtual usando o modo interno
  • Fornece a capacidade de controlar o tráfego de rede usando recursos de rede do Azure, como o NSG

Contras:

  • Aumenta a complexidade de implantar e configurar o Gerenciamento de API para funcionar dentro da rede virtual

Conteúdo relacionado

  • Last updated on