Partilhar via

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

Microsoft Entra ID
Registo de Contentores do Azure
Azure Kubernetes Service (AKS)
Balanceador de Carga do Azure
Azure Pipelines
Azure Monitor

Esta arquitetura de referência mostra um aplicativo de microsserviços implantado no Serviço Kubernetes do Azure (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. O artigo destaca principalmente os aspetos de infraestrutura e DevOps de como gerenciar microsserviços no AKS. Para obter mais informações sobre como projetar microsserviços, consulte Microservices architecture design.

logotipo do GitHub. Uma implementação de referência dessa arquitetura está disponível em GitHub.

Arquitetura

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.

Transfira um ficheiro do Visio desta arquitetura.

Se você quiser ver um exemplo de um microsserviço mais avançado que é construído na arquitetura de linha de base do AKS , consulte a arquitetura de microsserviços AKS avançada.

Fluxo de Trabalho

Esse fluxo de solicitação implementa o editor-assinante, consumidores concorrentese roteamento de gateway padrões de design de nuvem.

O seguinte fluxo de dados corresponde ao diagrama anterior:

  1. O aplicativo cliente envia uma carga JSON por HTTPS para o nome de domínio público totalmente qualificado do balanceador de carga (controlador de entrada gerenciado) para agendar uma coleta de drone.

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

    • O microsserviço de ingestão processa a solicitação e enfileira as solicitações de entrega em uma fila do Barramento de Serviço do Azure.

  2. O microsserviço de fluxo de trabalho:

    • Consome informações de mensagens da fila de mensagens do Service Bus.

    • Envia uma solicitação HTTPS para o microsserviço de entrega, que passa dados para o armazenamento de dados externo no Cache do Azure para Redis.

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

    • Envia uma solicitação HTTPS para o microsserviço do pacote, que passa dados para o armazenamento de dados 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. Em seguida, o microsserviço de entrega lê dados do Cache do Azure para Redis.

Para obter mais informações sobre o aplicativo de microsserviços de exemplo, consulte Exemplo de implementação de referência de microsserviços.

Componentes

  • AKS é um cluster Kubernetes gerenciado hospedado na nuvem do Azure. O AKS reduz a complexidade e a sobrecarga operacional do gerenciamento do Kubernetes transferindo grande parte dessa responsabilidade para o Azure.

  • Um servidor de entrada expõe rotas HTTP(S) para serviços dentro do cluster. A implementação de referência usa um controlador de entrada baseado em NGINX gerenciado por meio de um complemento de roteamento de aplicativo. O controlador de entrada implementa o padrão gateway de API para microsserviços.

  • Armazenamentos de dados externos, como do Banco de Dados SQL do Azure ou do Azure Cosmos DB, são usados por microsserviços sem estado para gravar seus dados e outras informações de estado. A implementação de referência usa do Azure Cosmos DB, Cache do Azure para RedisAzure Cosmos DB para MongoDB e Service Bus como armazenamentos de dados ou locais para armazenar o estado.

  • de ID do Microsoft Entra é necessária para o cluster AKS. Ele fornece um de identidade gerenciado que é usado para acessar o Registro de Contêiner do Azure e para acessar e provisionar recursos do Azure, como balanceadores de carga e discos gerenciados. As cargas de trabalho implantadas em um cluster AKS também exigem uma identidade no Microsoft Entra para acessar recursos protegidos pelo Microsoft Entra, como o Azure Key Vault e o Microsoft Graph. Nessa arquitetura de referência, Microsoft Entra Workload ID integra-se ao Kubernetes e fornece cargas de trabalho com identidades. Você também pode usar identidades gerenciadas ou credenciais de aplicativo para cada carga de trabalho.

  • de Registro de Contêiner pode ser usado para armazenar imagens de contêiner privado, que são implantadas no cluster. O AKS pode autenticar-se com o Registo de Contentores utilizando a sua identidade Microsoft Entra. Na implementação de referência, as imagens de contêiner de microsserviço são criadas e enviadas por push para o Registro de Contêiner.

  • do Azure Pipelines faz parte do pacote Azure DevOps e executa compilações, testes e implantações automatizados. Uma abordagem de integração contínua e implantação contínua (CI/CD) é altamente incentivada em ambientes de microsserviços. Várias equipes podem criar e implantar microsserviços de forma independente no AKS usando o Azure Pipelines.

  • Helm é um gerenciador de pacotes para Kubernetes que fornece um mecanismo para agrupar e padronizar objetos do Kubernetes em uma única unidade que pode ser publicada, implantada, versionada e atualizada.

  • Azure Monitor coleta e armazena métricas e logs, telemetria de aplicativos e métricas de plataforma para serviços do Azure. O Azure Monitor integra-se com o AKS para recolher métricas de controladores, nós e contentores.

  • Application Insights monitora microsserviços e contêineres. Ele pode ser usado para fornecer observabilidade a microsserviços, o que inclui fluxo de tráfego, latência de ponta a ponta e porcentagem de erro. A integridade dos microsserviços e as relações entre eles podem ser exibidas em um único mapa de aplicativo.

Alternativas

de Aplicativos de Contêiner do Azure fornece uma experiência Kubernetes gerenciada sem servidor. 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 do gateway de entrada gerenciado no AKS, você pode usar alternativas como o Application Gateway for Containers, o gateway de ingresso Istio ou soluções que não sejam da Microsoft. Para obter mais informações, consulte Ingress no AKS.

Você pode armazenar imagens de contêiner em registros de contêiner que não sejam da Microsoft, como o Docker Hub.

Para microsserviços que precisam manter informações de estado, Dapr fornece uma camada de abstração para gerenciar o estado do microsserviço.

Você pode usar as Ações do GitHub para criar e implantar microsserviços ou escolher soluções de CI/CD que não sejam da Microsoft, como o Jenkins.

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

Detalhes do cenário

O exemplo implementação de referência de microsserviço implementa os componentes e práticas de arquitetura descritos neste artigo. Neste exemplo, 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.

O cenário visa demonstrar a arquitetura de microsserviços e as melhores práticas de implantação no AKS.

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

Considerações

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

Estruturar

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.

Microsserviços

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 de cluster local porque esse método vincula os dados ao nó. Em vez disso, use um serviço externo, como o Banco de Dados SQL ou o Azure Cosmos DB. Outra opção é montar um volume de dados persistente em uma solução usando o Armazenamento em Disco do Azure ou os Arquivos do Azure. Para obter mais informações, consulte Opções de armazenamento para aplicativos 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 de API também pode executar várias tarefas transversais, como autenticação, terminação SSL (Secure Sockets Layer) 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 controlador de entrada e ingresso trabalham em conjunto com:

  • Encaminhe as solicitações do cliente para os microsserviços de back-end corretos. Esse roteamento fornece um único ponto de extremidade para clientes e ajuda a separar clientes de serviços.

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

  • Funcionalidade de descarregamento dos serviços de back-end, como terminação SSL, autenticação, restrições de endereço IP ou limitação de taxa de cliente (chamada limitação).

Há controladores de entrada para proxies reversos, que incluem NGINX, HAProxy, Traefik e Azure Application Gateway. O AKS oferece várias opções de entrada gerenciadas. Você pode escolher entre um controlador de entrada baseado em NGINX gerenciado por meio do complemento de roteamento de aplicativos, Application Gateway for Containers. Ou você pode escolher o gateway de entrada Istio como o controlador de entrada. Para obter mais informações, consulte Ingress no AKS.

Os recursos de entrada dos objetos do Kubernetes foram substituídos pela API mais avançada e versátil do Kubernetes Gateway. O controlador de entrada e a API de gateway são objetos Kubernetes usados para roteamento de gerenciamento de tráfego e balanceamento de carga. Projetada para ser genérica, expressiva, extensível e orientada a funções, a API do Gateway é um conjunto moderno de APIs para definir regras de roteamento L4 e L7 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 API de 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 você tiver controladores de entrada configurados em seu cluster Kubernetes e eles atenderem aos seus requisitos de forma eficaz, talvez não haja uma necessidade imediata de fazer a transição para a API do Gateway do Kubernetes.

Você deve usar a API do Gateway:

  • Quando você lida com configurações de roteamento complexas, divisão de tráfego e estratégias avançadas de gerenciamento de tráfego. A flexibilidade fornecida pelos recursos de rota da API do Kubernetes Gateway é essencial.

  • Se os requisitos de rede precisarem de soluções personalizadas ou da integração de plug-ins que não sejam da Microsoft. A abordagem da API do Kubernetes Gateway, baseada em definições de recursos personalizadas, pode fornecer extensibilidade aprimorada.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Particionamento de microsserviços

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 equipes implantam microsserviços no mesmo cluster, com possivelmente centenas de microsserviços, fica difícil gerenciar se todos eles entrarem no mesmo namespace. Os namespaces também permitem:

  • 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 equipes desenvolvem e implantam microsserviços, você pode usar namespaces como um mecanismo conveniente para controlar áreas nas quais cada equipe pode implantar. Por exemplo, a equipe de desenvolvimento A pode ter acesso somente ao namespace A, e a equipe de desenvolvimento B pode ter acesso somente ao namespace B por meio das políticas do Kubernetes RBAC.

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 microsserviços relacionados ao contexto delimitado "Atendimento de pedidos" podem entrar no 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, você pode implantar ferramentas de monitoramento de cluster como Elasticsearch e Prometheus em um namespace de monitoramento.

Sondas do estado de funcionamento

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.

Quando você pensa em sondas, é importante lembrar como um serviço funciona no Kubernetes. Um serviço tem um seletor de rótulo que corresponde a um conjunto de zero ou mais pods. A carga do Kubernetes equilibra o 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.

Às vezes, um pod pode não estar pronto para receber tráfego, mesmo que tenha sido iniciado com sucesso. Por exemplo, pode haver tarefas de inicialização em andamento, como quando o aplicativo em execução no contêiner carrega dados na memória ou lê arquivos 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 são usadas para verificar se um pod está em execução, mas não está funcionando corretamente e precisa ser reiniciado. Por exemplo, se um contêiner estiver lidando com solicitações HTTP, mas de repente parar de responder sem falhar, a sonda de vivacidade detetará esse evento e dispara uma reinicialização 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 projetar testes para microsserviços.

  • Se o seu código tiver um longo tempo de inicialização, há o perigo de que uma sonda de vivacidade relate uma falha antes que a inicialização seja concluída. 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 é suscetível de restaurá-lo a um estado saudável. Você pode usar uma sonda de vivacidade para mitigar vazamentos de memória ou bloqueios inesperados, mas não há razão para reiniciar um pod que vai falhar imediatamente novamente.

  • Às vezes, as sondas de prontidão são usadas para verificar 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. No entanto, 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, o manuseio de novas tentativas, a tolerância a erros e os disjuntores podem ser implementados pelo de malha de serviço Istio para criar uma arquitetura resiliente que possa lidar com falhas de microsserviç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 sejam de contêiner, como threads ou conexõ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. Essa limitação garante que o front-end não possa privar os serviços de back-end de recursos ou vice-versa. 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 parade segurança .

Criptografia TLS e SSL

Em muitas implementações, o controlador de entrada é usado para terminação SSL. Como parte da implantação do controlador de entrada, você precisa criar ou importar um certificado TLS (Transport Layer Security). 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.

Também pode ser necessário alternar seus certificados dependendo das políticas da organização. Você pode usar o Cofre da Chave para girar certificados que os microsserviços usam. Para obter mais informações, consulte Configurar a rotação automática de certificados no Cofre da Chave.

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. Você pode usar o RBAC do Kubernetes ou o RBAC do Azure com a ID do Microsoft Entra 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. Microsoft Entra ID pode ser usado para implementar tokens OAuth 2.0 para autorização. Malhas de serviço como Istio também fornecem mecanismos de autorização e autenticação para microsserviços, que incluem validação de token OAuth e roteamento baseado em token. A implementação de referência não abrange cenários de autenticação e autorização de microsserviços.

Gerenciamento de segredos e credenciais de aplicativos

Os aplicativos e serviços geralmente precisam de credenciais que lhes permitam se conectar a serviços externos, como o Armazenamento do Azure ou o Banco de Dados SQL. O desafio é manter essas credenciais seguras e não vazá-las.

Para recursos do Azure, use identidades gerenciadas quando possível. Uma identidade gerenciada é como uma ID exclusiva para um aplicativo ou serviço armazenado no Microsoft Entra ID. Ele usa essa identidade para autenticar com um serviço do Azure. O aplicativo ou serviço tem uma entidade de serviço criada para ele no Microsoft Entra ID e autentica usando tokens OAuth 2.0. O código em execução 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 gerenciadas, você pode atribuir identidades do Microsoft Entra a pods individuais no AKS usando ID de Carga de Trabalho do Microsoft Entra.

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

Usar uma solução como o Key Vault oferece várias vantagens, incluindo:

  • Controle centralizado de segredos.
  • Ajudando a garantir que todos os segredos são encriptados em repouso.
  • Gestão centralizada de chaves.
  • Controle de acesso de segredos.
  • Gestão do ciclo de vida das chaves.
  • Auditoria.

A implementação de referência armazena cadeias de conexão do Azure Cosmos DB e outros segredos no Cofre da Chave. A implementação de referência usa uma identidade gerenciada para microsserviços para autenticar no Cofre da Chave e acessar segredos.

Segurança de contentores e orquestradores

As práticas recomendadas a seguir podem ajudar a proteger seus pods e contêineres.

  • Monitore ameaças. Monitore ameaças usando Microsoft Defender for Containers ou um recurso que não seja da Microsoft. Se você hospedar contêineres em uma máquina virtual (VM), use Microsoft Defender for Servers ou um recurso que não seja da Microsoft. Além disso, você pode integrar logs de solução de monitoramento de contêiner no Azure Monitor a Microsoft Sentinel ou uma solução de gerenciamento de eventos e informações de segurança (SIEM) existente.

  • Monitore vulnerabilidades. Monitore continuamente imagens e contêineres em busca de vulnerabilidades conhecidas usando Microsoft Defender for Cloud ou uma solução que não seja da Microsoft.

  • Automatize a aplicação de patches de imagem. Use tarefas do Registro de Contêiner do Azure, um recurso do Registro de Contêiner, para automatizar a aplicação de patches de imagem. Uma imagem de contêiner é construída a partir de camadas. As camadas base incluem a imagem do SO e imagens da estrutura da aplicação, como ASP.NET Core ou Node.js. As imagens base são normalmente criadas a montante a partir dos desenvolvedores de aplicativos, e outros mantenedores do projeto as mantêm. Quando essas imagens são corrigidas upstream, é importante atualizar, testar e reimplantar suas próprias imagens para que você não deixe nenhuma vulnerabilidade de segurança conhecida. As tarefas do Registro de Contêiner do Azure podem ajudar a automatizar esse processo.

  • Armazene imagens em um registro privado confiável. Use um registro privado confiável, 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 contêineres não fornecem isolamento completo do ponto de vista da segurança, por isso é melhor executar um processo de contêiner como um usuário sem privilégios.

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 saber mais sobre os desafios, consulte CI/CD para arquiteturas de microsserviç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 obter mais informações sobre recomendações específicas e práticas recomendadas, consulte Criar um pipeline de CI/CD para microsserviços no Kubernetes com o Azure DevOps e o 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.

Utilize a calculadora de preços do Azure para prever os custos. Outras considerações são descritas na seção de custo em Microsoft Azure Well-Architected Framework.

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

Azure Kubernetes Service (AKS)

  • No de nível gratuito, não há custos associados ao AKS na implantação, gerenciamento e operações do cluster Kubernetes. Você paga apenas pelas instâncias de VM, armazenamento e recursos de rede que seu cluster Kubernetes consome.

  • Considere o uso de de autodimensionamento de pod horizontal para dimensionar ou expandir automaticamente os microsserviços, dependendo da carga.

  • Configure de dimensionamento automático de cluster para dimensionar os nós ou expandi-los dependendo da carga.

  • Considere o uso de nós spot para hospedar microsserviços não críticos.

  • Analise as melhores práticas de otimização de custos para o AKS.

  • Para estimar o custo dos recursos necessários, use a calculadora AKS.

Azure Load Balancer - equilibrador de carga

Você será cobrado apenas pelo número de regras de balanceamento de carga e saída configuradas. As regras de conversão de endereços de rede de entrada são gratuitas. Não há cobrança por hora para o Balanceador de Carga Padrão quando nenhuma regra está configurada. Para obter mais informações, consulte preços do Azure Load Balancer.

Azure Pipelines (Pipelines do Azure)

Essa arquitetura de referência usa apenas o Azure Pipelines. O Azure fornece o pipeline como um serviço individual. Você tem permissão para um trabalho gratuito hospedado pela Microsoft com 1.800 minutos por mês para CI/CD e um trabalho auto-hospedado com minutos ilimitados para cada mês. Empregos extras implicam mais custos. Para obter mais informações, consulte preços dos serviços de DevOps do Azure.

Azure Monitor

Para o Azure Monitor Log Analytics, você é cobrado pela ingestão e retenção de dados. Para obter mais informações, consulte Preços do Azure Monitor.

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 projeto para o Operational Excellence.

Essa arquitetura de referência inclui arquivos Bicep para provisionar recursos de nuvem e suas dependências. Você pode usar do Azure Pipelines para implantar esses arquivos 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 da carga de trabalho para estruturar seu arquivo Bicep. Uma carga de trabalho é normalmente definida como uma unidade arbitrária de funcionalidade. Por exemplo, você pode ter um arquivo Bicep separado para o cluster e, em seguida, outro arquivo para os serviços dependentes. Você pode usar o Azure DevOps para executar CI/CD com isolamento de carga de trabalho porque cada carga de trabalho é associada e gerenciada por sua própria equipe.

Implementar este cenário

Para implantar a implementação de referência para essa arquitetura, siga as etapas no repositório GitHub. Para obter mais informações, consulte implementação de referência de microsserviços AKS.

Contribuidores

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

Autor principal:

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos