Arquitetura de microsserviços no Serviço Kubernetes do Azure

Microsoft Entra ID
Registo de Contentores do Azure
Azure Kubernetes Service (AKS)
Redis Gerido pelo Azure
Azure Pipelines
Azure Monitor

Esta arquitetura mostra uma aplicação de microserviços implementada no Azure Kubernetes Service (AKS). Ele descreve uma configuração básica do AKS que você pode usar como ponto de partida para a maioria das implantações. Este artigo pressupõe que você tenha uma compreensão básica do Kubernetes. Destaca os aspetos de infraestrutura e operações de desenvolvimento (DevOps) sobre como gerir microserviços no AKS. Para implementações em produção, esta arquitetura recomenda que utilize o Azure CNI alimentado pela Cilium como solução de rede. O Azure CNI alimentado por Cilium oferece melhor desempenho, aplicação integrada de políticas de rede e observabilidade melhorada através do seu plano de dados baseado no Extended Berkeley Packet Filter (eBPF). Para obter mais informações sobre como projetar microsserviços, consulte Microservices architecture design.

Architecture

Diagrama que mostra os microsserviços na arquitetura de referência AKS.

Helm é uma marca comercial da Cloud Native Computing Foundation (CNCF). O uso desta marca não implica qualquer endosso.

Descarregue um ficheiro Visio desta arquitetura.

Para um exemplo de um microserviço mais avançado construído sobre a arquitetura base do AKS, veja a arquitetura avançada de microserviços do AKS.

Fluxo de dados

Esse fluxo de solicitação implementa os padrões de design de nuvem Publicador-Assinante, Consumidores Concorrentes e Roteamento de Gateway .

O seguinte fluxo de dados corresponde ao diagrama anterior:

  1. A aplicação cliente envia uma carga útil JSON via HTTPS para o domínio público totalmente qualificado (FQDN) do balanceador de carga (controlador de entrada gerido) para agendar a recolha de drones.

    • O controlador de entrada gerenciado roteia a solicitação para o microsserviço de ingestão.

    • O microserviço de ingestão processa o pedido e coloca os pedidos de entrega numa fila Azure Service Bus.

  2. O microserviço de fluxo de trabalho realiza as seguintes ações:

    • Consome informação de mensagens da fila de mensagens do Service Bus

    • Envia um pedido HTTPS para o microserviço de entrega, que passa os dados para armazenamento de dados externo no Azure Managed Redis

    • Envia uma solicitação HTTPS para o microsserviço do agendador de drones

    • Envia um pedido HTTPS para o microserviço do pacote, que passa os dados para armazenamento externo no MongoDB

  3. Uma solicitação HTTPS GET retorna o status de entrega. Essa solicitação passa pelo controlador de entrada gerenciado para o microsserviço de entrega. Depois, o microserviço de entrega lê dados do Azure Managed Redis.

Components

  • O AKS é um serviço Kubernetes gerido que aloja e orquestra os contentores de microserviços. Nesta arquitetura, o AKS fornece a plataforma de execução para implementar, escalar e gerir os microserviços da aplicação de entrega de drones.

  • Azure CNI alimentado por Cilium é a solução de rede recomendada para se ligar diretamente a uma rede virtual Azure. Nesta arquitetura, atribui endereços IP da rede virtual a pods e fornece capacidades integradas de políticas de rede e visibilidade de tráfego.

  • Um servidor de entrada expõe rotas HTTP e HTTPS a serviços dentro de um cluster. Nesta arquitetura, a implementação da API de Gateway de encaminhamento de aplicações é usada como controlador de entrada. O controlador de entrada implementa o padrão gateway de API para microsserviços.

  • Armazenamentos de dados externos, como Base de Dados SQL do Azure ou Azure Cosmos DB, são usados por microserviços sem estado para escrever os seus dados e outras informações de estado. Nesta arquitetura, Azure Cosmos DB, Azure Redis, Azure DocumentDB e Service Bus servem como repositórios de dados ou locais para armazenar estados.

  • Microsoft Entra ID é um serviço de gestão de identidade e acessos baseado na cloud que fornece capacidades de autenticação e autorização para o cluster AKS e cargas de trabalho implementadas. O AKS requer a integração com a Microsoft Entra ID para fornecer uma identidade gerida que permita aceder ao Azure Container Registry e provisionar recursos do Azure, como balanceadores de carga e discos geridos. Cada carga de trabalho implementada no cluster AKS requer uma identidade para aceder a recursos protegidos pela Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. Esta arquitetura utiliza ID de carga de trabalho Microsoft Entra para se integrar com o Kubernetes e fornecer identidades seguras para cargas de trabalho. Em alternativa, pode usar identidades geridas ou credenciais de aplicação para autenticação da carga de trabalho.

  • O Container Registry é um serviço gerido que pode armazenar imagens privadas de contentores, que são implementadas num cluster. A AKS pode autenticar-se com o Container Registry utilizando a sua identidade Microsoft Entra. As imagens de contentores de microsserviços são criadas e carregadas para o Registro de Contentores. Nesta arquitetura, o Registo de Contentores armazena as imagens privadas dos contentores dos microserviços que são implementados no cluster AKS.

  • Azure Pipelines faz parte da suíte Azure DevOps e executa compilações, testes e implantações automatizadas. Uma abordagem de integração contínua e implementação contínua (CI/CD) é altamente recomendada em ambientes de microserviços. Várias equipas podem construir e implementar microserviços de forma independente no AKS utilizando o Azure Pipelines. Nesta arquitetura, o Azure Pipelines constrói e implementa os microserviços de entrega de drones para o AKS.

  • O Helm é um gestor de pacotes para Kubernetes que fornece um mecanismo para agrupar e padronizar objetos Kubernetes numa única unidade que pode publicar, implementar, versionar e atualizar. Nesta arquitetura, a Helm empacota os microserviços de entrega de drones para implementação no AKS.

  • Azure Monitor é uma plataforma de monitorização que recolhe e armazena métricas e registos, telemetria de aplicações e métricas de plataforma para serviços Azure. Nesta arquitetura, o Azure Monitor integra-se com o AKS para recolher métricas de controladores, nós e contentores.

  • Application Insights é uma ferramenta de monitorização de desempenho que monitoriza microserviços e contentores. Pode fornecer observabilidade em microsserviços, incluindo fluxo de tráfego, latência de ponta a ponta e percentagem de erro. Pode mostrar a saúde dos microserviços e as relações entre eles num único mapa de aplicação. Nesta arquitetura, o Application Insights monitoriza a saúde e o desempenho dos microserviços de entrega por drones e mostra as suas relações num mapa de aplicação.

Alternatives

Azure Container Apps é uma plataforma serverless gerida que oferece uma experiência baseada em Kubernetes sem necessidade de gestão de infraestrutura. Ele serve como uma alternativa mais simples ao AKS para hospedar microsserviços quando você não precisa de acesso direto ao Kubernetes ou suas APIs e não requer controle sobre a infraestrutura do cluster.

Em vez da implementação da Gateway API para encaminhamento de aplicações no AKS, pode utilizar alternativas como o Application Gateway for Containers, o suplemento da malha de serviço Istio ou soluções que não são da Microsoft. Para obter mais informações, consulte Ingress no AKS.

Podes armazenar imagens de contentores em registos de contentores que não sejam da Microsoft, como o Docker Hub.

Para redes, embora esta arquitetura recomende Azure CNI alimentado por Cilium pelo seu desempenho e aplicação de políticas integradas, pode usar soluções alternativas de rede como Azure CNI Overlay para cenários específicos.

Importante

Se precisar de nós Windows na sua arquitetura de microserviços, reveja a limitação atual do Cilium apenas para Linux e planeie adequadamente para ambientes mistos de sistemas operativos. Para mais informações, consulte Azure CNI alimentado por limitações de Cilium.

Para microserviços que devem manter informação de estado, o Dapr fornece uma camada de abstração para gerir o estado do microserviço.

Pode usar o GitHub Actions para construir e implementar microsserviços, ou escolher soluções CI/CD que não sejam da Microsoft, como a Jenkins.

A observabilidade de microsserviços pode ser alcançada com ferramentas alternativas como Kiali.

Detalhes do cenário

Uma empresa fictícia chamada Fabrikam, Inc., gerencia uma frota de aeronaves drones. As empresas registam-se no serviço e os utilizadores podem solicitar um drone para recolher as mercadorias para entrega. Quando um cliente agenda uma recolha, o sistema de back-end atribui um drone e notifica o utilizador com um tempo de entrega estimado. Quando a entrega está em andamento, o cliente pode rastrear a localização do drone com um tempo de entrega estimado continuamente atualizado.

Casos de uso potenciais

Adote as seguintes práticas recomendadas do cenário para arquitetar aplicativos complexos baseados em microsserviços no AKS:

  • Aplicações Web complexas
  • Lógica de negócios desenvolvida usando princípios de design de microsserviços

Considerations

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que pode usar para melhorar a qualidade de uma carga de trabalho. Para mais informações, consulte Microsoft Azure Well-Architected Framework.

Design

Essa arquitetura de referência é focada em microsserviços, mas muitas das práticas recomendadas se aplicam a outras cargas de trabalho executadas no AKS.

Microservices

Um microsserviço é uma unidade de código de acoplamento flexível e implantável independentemente. Os microsserviços normalmente se comunicam por meio de APIs bem definidas e podem ser descobertos por meio de alguma forma de descoberta de serviço. O objeto de serviço do Kubernetes é uma maneira típica de modelar microsserviços no Kubernetes.

Armazenamento de dados

Em uma arquitetura de microsserviços, os serviços não devem compartilhar soluções de armazenamento de dados. Cada serviço deve gerenciar seu próprio conjunto de dados para evitar dependências ocultas entre serviços. A separação de dados ajuda a evitar o acoplamento não intencional entre serviços. Esse processo pode acontecer quando os serviços compartilham os mesmos esquemas de dados subjacentes. Quando os serviços gerenciam seus próprios armazenamentos de dados, eles podem usar o armazenamento de dados correto para suas necessidades específicas. Para obter mais informações, consulte Considerações sobre dados para microsserviços.

Evite armazenar dados persistentes no armazenamento local do cluster, pois esse método vincula os dados ao nó. Em vez disso, use um serviço externo como SQL Database ou Azure Cosmos DB. Outra opção é montar um volume de dados persistente numa solução usando Armazenamento de Discos do Azure ou Ficheiros do Azure. Para obter mais informações, consulte Opções de armazenamento para aplicativos no AKS.

Rede e política de rede

Para implementações de microserviços em produção no AKS, utilize Azure CNI com tecnologia Cilium como solução de networking. Esta abordagem oferece vários benefícios para arquiteturas de microserviços:

  • Desempenho e escalabilidade: O plano de dados baseado em eBPF melhora o desempenho do encaminhamento de serviços e suporta clusters maiores com menor latência em comparação com soluções de rede tradicionais.

  • Aplicação de políticas de rede: A Cilium aplica os recursos Kubernetes NetworkPolicy sem exigir um motor de políticas de rede separado como Azure Network Policy Manager ou Calico. Esta integração simplifica a configuração do cluster e reduz a sobrecarga operacional.

  • Observabilidade: O plano de dados eBPF fornece visibilidade do tráfego de rede, incluindo consultas ao Sistema de Nomes de Domínio (DNS), fluxos pod-a-pod e comunicação entre serviços. Esta visibilidade ajuda a resolver interações com microserviços e a identificar gargalos de desempenho.

  • Gestão flexível de endereços IP: Azure CNI alimentado pela Cilium suporta tanto modelos de atribuição de endereços IP em rede virtual como de atribuição de endereços pod sobrepostos, com base nos requisitos da arquitetura de rede da sua carga de trabalho.

Quando implementa políticas de rede para microserviços, siga o princípio da arquitetura Confiança Zero definindo explicitamente quais os serviços que podem comunicar entre si. Comece com políticas de negação total e permita seletivamente apenas o tráfego necessário entre microserviços. Para mais informações, consulte Melhores práticas para políticas de rede no AKS.

gateway de API

Os gateways de API são um padrão geral de design de microsserviços. Um gateway de API fica entre clientes externos e os microsserviços. O gateway serve como um proxy reverso e roteia solicitações de clientes para microsserviços. Um gateway API pode também realizar várias tarefas transversais como autenticação, terminação da Secure Sockets Layer (SSL) e limitação de taxa. Para obter mais informações, consulte os seguintes recursos:

No Kubernetes, um controlador de entrada lida principalmente com a funcionalidade de um gateway de API. O ingress e o controlador de ingress trabalham em conjunto para realizar as seguintes ações:

  • Encaminhe as solicitações do cliente para os microsserviços de back-end corretos. Este encaminhamento fornece um único ponto final para os clientes e ajuda a desacoplar os clientes dos serviços.

  • Agregue várias solicitações em uma única solicitação para reduzir a conversa entre o cliente e o back-end.

  • Descarregar funcionalidades dos serviços de back-end, como terminação SSL, autenticação, restrições de endereços IP ou limitação de taxa do cliente (conhecida como throttling).

Existem controladores de entrada para proxies reversos. O AKS oferece várias opções de entrada gerenciadas. Pode escolher entre a API do Kubernetes Gateway através do complemento de roteamento de aplicações ou do Application Gateway for Containers. Ou pode escolher um suplemento de malha de serviços baseado em Istio como controlador de ingresso. Para obter mais informações, consulte Ingress no AKS.

O Kubernetes substituiu os recursos de entrada pela API Gateway, mais avançada e versátil. Os controladores de entrada e a API do Gateway são objetos Kubernetes que gerem o encaminhamento do tráfego e o balanceamento de carga. Concebida para ser genérica, expressiva, extensível e orientada para papéis, a API Gateway é um conjunto moderno de APIs para definir regras de roteamento de nível 4 e nível 7 no Kubernetes.

O controlador de entrada opera como roteador de borda ou proxy reverso. Um servidor proxy reverso é um potencial gargalo ou ponto único de falha, portanto, recomendamos que você implante pelo menos duas réplicas para ajudar a garantir a alta disponibilidade.

Quando escolher controladores de entrada ou a API do Gateway

Os recursos de ingresso são adequados para os seguintes casos de uso:

  • Os controladores de entrada são fáceis de configurar e são adequados para implantações Kubernetes menores e menos complexas que priorizam a configuração fácil.

  • Se atualmente tem controladores de entrada configurados no seu cluster Kubernetes e cumprem eficazmente os seus requisitos, não precisa de transitar imediatamente para a API do Kubernetes Gateway.

Use a API do Gateway quando se aplicarem os seguintes fatores:

  • Quando você lida com configurações de roteamento complexas, divisão de tráfego e estratégias avançadas de gerenciamento de tráfego. Os recursos de roteamento da API do Kubernetes Gateway oferecem a flexibilidade necessária nestes casos.

  • Se os requisitos de rede precisam de soluções personalizadas ou da integração de plug-ins não Microsoft. A abordagem da API Kubernetes Gateway, baseada em definições personalizadas de recursos, pode proporcionar uma extensibilidade melhorada.

Reliability

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Microserviços de partição

Use namespaces para organizar serviços dentro do cluster. Cada objeto em um cluster Kubernetes pertence a um namespace. É uma boa prática usar namespaces para organizar os recursos no cluster.

Os namespaces ajudam a evitar colisões de nomenclatura. Quando várias equipas implementam microserviços no mesmo cluster, com possivelmente centenas de microserviços, gerir esses microserviços num único namespace torna-se difícil. Os namespaces também permitem realizar as seguintes ações:

  • Aplique restrições de recursos a um namespace para que o conjunto total de pods atribuídos a esse namespace não possa exceder a cota de recursos do namespace.

  • Aplique políticas no nível do namespace, que incluem RBAC (controle de acesso baseado em função) e políticas de segurança.

Quando várias equipas desenvolvem e implementam microserviços, os namespaces fornecem um mecanismo conveniente para controlar as áreas onde cada equipa pode implementar. Por exemplo, as políticas RBAC do Kubernetes concedem à equipa de desenvolvimento A acesso apenas ao espaço de nomes A, e à equipa de desenvolvimento B acesso apenas ao espaço de nomes B.

Para uma arquitetura de microsserviços, considere organizar os microsserviços em contextos limitados e criar namespaces para cada contexto limitado. Por exemplo, todos os microserviços relacionados com o contexto limitado de Cumprimento de Encomendas podem ir para o mesmo namespace. Como alternativa, crie um namespace para cada equipe de desenvolvimento.

Coloque os serviços utilitários em seu próprio namespace separado. Por exemplo, pode implementar ferramentas de monitorização de clusters como Elasticsearch e Prometheus para um namespace de monitorização.

Sondas de saúde

O Kubernetes define três tipos de sondas de saúde que um pod pode expor:

  • Sonda de prontidão: Informa ao Kubernetes se o pod está pronto para aceitar solicitações.

  • Sonda Liveness: Informa ao Kubernetes se um pod deve ser removido e uma nova instância iniciada.

  • Sonda de inicialização: Informa ao Kubernetes se o pod foi iniciado.

Para perceberes as sondas, primeiro analisa como um serviço funciona no Kubernetes. Um serviço tem um selector de etiquetas que corresponde a um conjunto de zero ou mais pods. O Kubernetes faz o balanceamento de carga do tráfego para os pods que correspondem ao seletor. Apenas os pods que iniciam com sucesso e são saudáveis recebem tráfego. Se um contêiner falhar, o Kubernetes encerrará o pod e agendará uma substituição.

Por vezes, um pod não está pronto para receber tráfego, mesmo que comece com sucesso. Por exemplo, pode haver tarefas de inicialização em curso, como quando a aplicação que corre no contentor carrega dados na memória ou lê ficheiros de configuração. Você pode usar uma sonda de inicialização para esses contêineres de inicialização lenta. Essa abordagem ajuda a evitar que o Kubernetes os encerre antes que eles tenham a chance de inicializar totalmente.

As sondas Liveness verificam se um pod está a funcionar mas não funciona corretamente e precisa de ser reiniciado. Por exemplo, se um contentor processa pedidos HTTP mas de repente deixa de responder sem crashar, a sonda de liveness deteta este evento e desencadeia o reinício do pod. Se você configurar uma sonda de vivacidade, ela perceberá quando um contêiner não está respondendo e solicitará que o Kubernetes reinicie o pod se o contêiner falhar repetidamente na sonda.

Considere os seguintes pontos ao desenhar sondas para microserviços:

  • Se o seu código tiver um tempo de arranque longo, um liveness probe pode reportar uma falha antes do arranque terminar. Para atrasar o início de uma sonda de vivacidade, use a sonda de inicialização ou use a configuração de initialDelaySeconds com a sonda de vivacidade.

  • Uma sonda de vivacidade só ajuda se reiniciar o pod pode restaurá-lo a um estado saudável. Pode usar uma sonda de liveness para mitigar fugas de memória ou bloqueios inesperados, mas não reinicie um pod que espere que falhe novamente imediatamente.

  • Por vezes, as sondas de prontidão verificam os serviços dependentes. Por exemplo, se um pod tiver uma dependência de um banco de dados, a sonda poderá verificar a conexão do banco de dados. Mas esta abordagem pode criar problemas inesperados. Um serviço externo pode estar temporariamente indisponível. Essa indisponibilidade faz com que o teste de prontidão falhe para todos os pods em seu serviço, o que resulta em sua remoção do balanceamento de carga. Esta remoção cria falhas em cascata a montante.

    Uma abordagem melhor é implementar o tratamento de novas tentativas dentro do seu serviço para que ele possa se recuperar corretamente de falhas transitórias. Como alternativa, a malha de serviço Istio pode implementar a gestão de retentativas, a tolerância a erros e os interruptores de circuito. Esta abordagem cria uma arquitetura resiliente capaz de lidar com falhas de microserviços.

Para resolver problemas de saúde dos microserviços, utilize as funcionalidades de observabilidade de rede nos Serviços Avançados de Rede de Contentores. O plano de dados eBPF captura informação detalhada do fluxo de rede entre microserviços, o que ajuda a identificar problemas de conectividade, problemas de resolução DNS ou configurações incorretas de políticas de rede que possam afetar a saúde do serviço.

Restrições de recursos

A contenção de recursos pode afetar a disponibilidade de um serviço. Defina restrições de recursos para contêineres para que um único contêiner não possa sobrecarregar os recursos do cluster, como memória e CPU. Para recursos que não são contentores, como threads ou ligações de rede, considere usar o padrão Bulkhead para isolar recursos.

Use cotas de recursos para limitar o total de recursos permitidos para um namespace. Esta limitação garante que os serviços front-end não consomem recursos que os serviços back-end necessitam, e que os serviços back-end não consomem recursos que os serviços front-end necessitam. As cotas de recursos podem ajudar a alocar recursos dentro do mesmo cluster para várias equipes de desenvolvimento de microsserviços.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Criptografia TLS e SSL

Em muitas implementações, o controlador de entrada é usado para terminação SSL. Como parte da implementação do controlador de entrada, deve criar ou importar um certificado de Segurança da Camada de Transporte (TLS). Use apenas certificados autoassinados para fins de desenvolvimento e teste. Para obter mais informações, consulte Configurar um nome de domínio personalizado e um certificado SSL com o complemento de roteamento de aplicativo.

Para cargas de trabalho de produção, obtenha certificados assinados de autoridades de certificação confiáveis.

Poderá também precisar de renovar os seus certificados de acordo com as políticas da sua organização. Pode usar o Key Vault para rodar certificados que os microserviços utilizam. Para mais informações, consulte Configurar rotação automática de certificados em Key Vault.

Segmentação da rede e políticas

Implementar segmentação de rede entre microserviços utilizando recursos Kubernetes NetworkPolicy. Quando usa Azure CNI alimentado por Cilium, o plano de dados eBPF aplica as políticas de rede.

Siga estas melhores práticas para políticas de rede em arquiteturas de microserviços:

  • Aplique os princípios do Confiança Zero. Comece com políticas de rede de negação total ao nível do namespace e permita explicitamente apenas o tráfego necessário entre microserviços.

  • Segmentar por contexto delimitado. Crie namespaces para cada contexto limitado na sua arquitetura de microserviços e aplique políticas de rede para controlar o tráfego entre esses contextos.

  • Controle o tráfego de saída. Use políticas de rede para restringir o tráfego de saída dos microserviços apenas para serviços externos aprovados e terminais.

  • Monitorizar a eficácia das políticas. Utilize as funcionalidades de observabilidade do plano de dados Cilium eBPF para monitorizar a aplicação das políticas de rede e identificar tráfego bloqueado que possa indicar configurações incorretas ou problemas de segurança.

RBAC

Quando várias equipes desenvolvem e implantam microsserviços ao mesmo tempo, os mecanismos RBAC do AKS podem fornecer controle granular e filtragem das ações do usuário. Pode usar Kubernetes RBAC ou Azure RBAC com Microsoft Entra ID para controlar o acesso aos recursos do cluster. Para obter mais informações, consulte Opções de acesso e identidade para o AKS.

Autenticação e autorização

Os microsserviços podem exigir que os serviços ou usuários consumidores autentiquem e autorizem o acesso ao microsserviço usando certificados, credenciais e mecanismos RBAC. Pode usar o Microsoft Entra ID para implementar tokens OAuth 2.0 para autorização. Malhas de serviço como a malha de serviço Istio também fornecem mecanismos de autorização e autenticação para microserviços, que incluem validação OAuth de tokens e encaminhamento baseado em tokens.

Gerenciamento de segredos e credenciais de aplicativos

Aplicações e serviços muitas vezes precisam de credenciais que lhes permitam ligar-se a serviços externos como o Armazenamento do Azure ou o SQL Database. O desafio é manter estas credenciais seguras e evitar fugas de informação.

Para recursos do Azure, use identidades geridas sempre que possível. Uma identidade gerida é como um ID único para uma aplicação ou serviço armazenado no Microsoft Entra ID. Utiliza esta identidade para autenticar com um serviço Azure. A aplicação ou serviço tem um princípio de serviço criado para si no Microsoft Entra ID e autentica-se usando tokens OAuth 2.0. O código que corre dentro do processo pode obter o token de forma transparente. Essa abordagem ajuda a garantir que você não precise armazenar senhas ou cadeias de conexão. Para usar identidades geridas, pode atribuir identidades do Microsoft Entra a pods individuais no AKS usando ID de carga de trabalho Microsoft Entra.

Mesmo quando você usa identidades gerenciadas, talvez ainda precise armazenar algumas credenciais ou outros segredos do aplicativo. Este armazenamento é necessário para serviços do Azure que não suportam identidades geridas, serviços não Microsoft ou chaves API. Você pode usar as seguintes opções para ajudar a armazenar segredos com mais segurança:

Use uma solução como a Key Vault para obter as seguintes vantagens:

  • Controle centralizado de segredos
  • Encriptação de segredos em repouso
  • Gerenciamento centralizado de chaves
  • Controlo de acesso a informações confidenciais
  • Gestão chave do ciclo de vida
  • Auditing

Esta arquitetura utiliza uma identidade gerida para microserviços autenticarem o Key Vault e aceder a segredos.

Segurança de contentores e orquestradores

As seguintes práticas recomendadas podem ajudar a proteger os seus pods e recipientes:

  • Monitore ameaças. Monitorize ameaças usando Microsoft Defender para Containers ou uma funcionalidade que não seja Microsoft. Se alojar containers numa máquina virtual (VM), use Microsoft Defender para servidores ou uma capacidade que não seja da Microsoft. Também pode integrar logs da solução de monitorização de contentores do Azure Monitor com Microsoft Sentinel ou uma solução existente de gestão da informação e eventos de segurança (SIEM).

  • Monitorizar vulnerabilidades. Monitorizar continuamente imagens e contêineres em execução para vulnerabilidades conhecidas usando Microsoft Defender para Containers ou uma solução que não seja Microsoft.

  • Automatize a aplicação de patches de imagem. Use tarefas do registo de contentores para automatizar a atualização de imagens. Uma imagem de contêiner é construída a partir de camadas. As camadas base incluem a imagem do sistema operativo e as imagens do framework da aplicação, como ASP.NET Core ou Node.js. As imagens base são normalmente criadas a montante dos desenvolvedores de aplicações, e outros responsáveis pelo projeto as mantêm. Quando estas imagens são corrigidas, deve atualizar, testar e implementar novamente as suas próprias imagens para não deixar vulnerabilidades de segurança conhecidas. As tarefas do Registo de Contentores podem ajudar a automatizar este processo.

  • Armazene imagens em um registro privado confiável. Use um registo privado de confiança como o Container Registry ou o Docker Trusted Registry para armazenar imagens. Use um webhook de admissão de validação no Kubernetes para ajudar a garantir que os pods só possam recuperar imagens do registro confiável.

  • Aplique o princípio do menor privilégio. Não execute contêineres no modo privilegiado. O modo privilegiado dá a um contêiner acesso a todos os dispositivos no host. Quando possível, evite executar processos como root dentro de contêineres. Os contentores não oferecem isolamento total do ponto de vista da segurança, por isso é melhor executar um processo container como utilizador não privilegiado.

Considerações sobre CI/CD de implantação

Considere os seguintes objetivos de um processo robusto de CI/CD para uma arquitetura de microsserviços:

  • Cada equipe pode criar e implantar os serviços que possui de forma independente, sem afetar ou interromper outras equipes.

  • Antes de uma nova versão de um serviço ser implantada na produção, ela é implantada em ambientes de desenvolvimento, teste e Q&A para validação. Os portões de qualidade são aplicados em cada etapa.

  • Uma nova versão de um serviço pode ser implantada lado a lado com a versão anterior.

  • Estão em vigor políticas de controlo de acesso suficientes.

  • Para cargas de trabalho em contêineres, você pode confiar nas imagens de contêiner que são implantadas na produção.

Para mais informações sobre os desafios, consulte CI/CD para arquiteturas de microserviços.

O uso de uma malha de serviço como o Istio pode ajudar com processos de CI/CD, como implantações canárias, testes A/B de microsserviços e distribuições em estágios com divisões de tráfego baseadas em porcentagem.

Para mais informações sobre recomendações específicas e melhores práticas, consulte Construa um pipeline CI/CD para microserviços no Kubernetes com Azure DevOps e Helm.

Otimização de Custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

Para estimar o custo dos recursos nesta arquitetura, utilize esta estimativa pré-configurada na calculadora de preços do Azure. Ajuste os valores para ver como o custo muda consoante as suas necessidades específicas.

Considere os seguintes pontos para alguns dos serviços usados nessa arquitetura.

AKS

Balanceador de Carga do Azure

  • Você será cobrado apenas pelo número de regras de balanceamento de carga e saída configuradas. As regras de NAT de entrada são gratuitas. Não há cobrança horária no Balanceador de Carga quando não há regras configuradas.

Azure Pipelines

  • Esta arquitetura de referência utiliza Azure Pipelines para tarefas CI/CD. Tem direito a um trabalho gratuito hospedado pela Microsoft com 1.800 minutos por mês e um trabalho auto-hospedado com minutos ilimitados. Empregos extras implicam mais custos.

Azure Monitor

  • É cobrado pela ingestão e retenção de dados. A estimativa pré-configurada inclui Log Analytics, métricas Prometheus e Application Insights.

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.

Esta arquitetura de referência inclui ficheiros Bicep para provisionamento de recursos cloud e suas dependências. Pode usar Azure Pipelines para implementar estes ficheiros Bicep e configurar rapidamente diferentes ambientes, como replicar cenários de produção. Essa abordagem ajuda a economizar custos provisionando ambientes de teste de carga somente quando necessário.

Considere seguir os critérios de isolamento de carga de trabalho para estruturar o seu ficheiro Bicep. Uma carga de trabalho é normalmente definida como uma unidade arbitrária de funcionalidade. Por exemplo, pode ter um ficheiro Bicep separado para o cluster e depois outro ficheiro para os serviços dependentes. Pode usar o Azure DevOps para realizar CI/CD com isolamento de carga de trabalho porque cada carga de trabalho está associada e gerida pela sua própria equipa.

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

Outros contribuidores:

Para ver perfis de LinkedIn não públicos, inicie sessão no LinkedIn.

Próximos passos