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

APLICA-SE A: Todas as camadas de gerenciamento de API

Os microsserviços são perfeitos para criar APIs. Você pode usar o Serviço Kubernetes do Azure (AKS) 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 AKS como APIs. Ele pressupõe um conhecimento básico de Kubernetes, Gerenciamento de API e rede do Azure.

Fundo

Quando você publica microsserviços como APIs para consumo, pode ser um desafio gerenciar a comunicação entre os microsserviços e os clientes que os consomem. As preocupações transversais incluem autenticação, autorização, limitação, armazenamento em cache, transformação e monitoramento. Estas preocupações aplicam-se independentemente de os microsserviços estarem expostos a clientes internos ou externos.

O padrão API Gateway aborda essas preocupações. Um gateway de API serve como uma porta de entrada para os microsserviços, separa os clientes de seus microsserviços, adiciona outra camada de segurança e diminui a complexidade de seus microsserviços, removendo a carga de lidar com preocupações transversais.

O Gerenciamento de API é uma solução pronta para uso 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 do ciclo de vida da 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 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 mudar 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, balanceamento de carga e descoberta de serviço para esses Pods.

Quando estiver pronto para publicar seus microsserviços como APIs usando o Gerenciamento de API, você precisa pensar em como mapear seus Serviços no Kubernetes para APIs no Gerenciamento de API. Não há regras definidas para esse mapeamento. Depende de como você projetou e particionou seus recursos de negócios ou domínios em 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. (Veja o diagrama a seguir.)

Os mapeamentos também podem evoluir. Como o Gerenciamento de API cria uma fachada na frente dos microsserviços, ele permite que você refatore e dimensione corretamente seus microsserviços ao longo do tempo.

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

Implante o Gerenciamento de API na frente do AKS

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

Um cluster AKS é sempre implantado em uma rede virtual, mas uma instância de Gerenciamento de API não é necessariamente implantada em uma rede virtual. Quando a Gestão de API não reside na rede virtual do cluster, o cluster AKS precisa publicar pontos de extremidade públicos para que a Gestão de API possa conectar-se a eles. 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 possa ser acessado somente 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 AKS usando os tipos de Serviço NodePort, LoadBalancer ou ExternalName. Quando o faz, os Serviços são acessíveis diretamente a partir 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 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 uma arquitetura para publicar serviços diretamente.

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á estiverem expostos publicamente e a lógica de autenticação já existir em microsserviços

Contras:

  • Cria risco potencial de segurança devido à visibilidade pública dos pontos finais
  • Não cria um único ponto de entrada para o tráfego de entrada do cluster
  • Complica microsserviços com 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 AKS.

A autenticação TLS mútua é suportada nativamente pelo Gerenciamento de API. Você pode habilitá-lo no Kubernetes instalando um controlador de entrada. (Veja o diagrama a seguir.) Como resultado, a autenticação é realizada no controlador de entrada, o que simplifica os microsserviços. Além disso, em camadas de serviço que oferecem 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 apenas o Gerenciamento de API tenha acesso ao cluster.

Diagrama que mostra uma arquitetura para publicação através de um controlador de entrada.

Prós:

  • Permite uma 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 é suportado nativamente
  • Centraliza a proteção para o tráfego de cluster de entrada na camada do controlador de ingresso
  • Reduz o risco de segurança, minimizando os endpoints de cluster, publicamente visíveis.

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 se utilize o nível API Management Standard v2 ou o escalão Premium.

Quando você publica APIs por meio do Gerenciamento de APIs, é fácil e comum 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 quando fizerem chamadas para essas APIs. Caso contrário, as chamadas serão rejeitadas imediatamente pelo gateway de Gerenciamento de API. Eles não são encaminhados para os serviços de back-end.

Para obter uma chave de assinatura para acessar APIs, os desenvolvedores precisam de uma assinatura. Uma assinatura é essencialmente um contêiner nomeado para um par de chaves de assinatura. Os desenvolvedores que precisam consumir as APIs publicadas podem obter assinaturas. Eles não precisam da aprovação dos editores de API. Os editores de API também podem criar assinaturas diretamente para consumidores de 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 rigorosos podem achar as Opções 1 e 2 inviáveis devido aos pontos de extremidade expostos publicamente. Em outros, o cluster 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 da API permanece na rede virtual. Nesses cenários, você pode implantar o Gerenciamento de API na rede virtual do cluster. As camadas API Management Developer, Premium e Premium v2 (visualização) suportam a injeção na rede virtual do cluster.

Há dois modos de implantação do Gerenciamento de API em uma rede virtual: externa e interna. 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. (Veja o diagrama a seguir.) Nesse modo, o gateway de Gerenciamento de API é injetado na rede virtual do cluster, mas acessível a partir da Internet pública por meio de um balanceador de carga externo. Essa arquitetura ajuda a ocultar completamente o cluster e, ao mesmo tempo, permite que clientes externos consumam os microsserviços. Além disso, você pode usar os 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 externa.

Se todos os consumidores de API residirem na rede virtual do cluster, você poderá usar o modo interno. (Veja 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 AKS a partir da Internet pública.

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

O cluster 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 seus 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 AKS não tem ponto de extremidade público
  • Simplifica a configuração do cluster porque não há 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 NSG

Contras:

  • Aumenta a complexidade da implantação e configuração do Gerenciamento de API para trabalhar dentro da rede virtual

Conteúdo relacionado

  • Last updated on