Editar

Compartilhar via

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

Microsoft Entra ID
Registro de Contêiner do Azure
AKS (Serviço de Kubernetes do Azure)
Azure Load Balancer
Azure Pipelines
Azure Monitor

Essa arquitetura de referência mostra um aplicativo de microsserviços implantado no AKS (Serviço de Kubernetes do Azure). 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 aspectos de infraestrutura e DevOps de como gerenciar microsserviços no AKS. Para obter mais informações sobre como criar microsserviços, consulte de design de arquitetura de microsserviços.

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

Arquitetura

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

Helm é uma marca registrada da CNCF (Cloud Native Computing Foundation). Nenhum endosso é implícito pelo uso dessa marca.

Baixe um Arquivo Visio dessa arquitetura.

Se você quiser ver um exemplo de um microsserviço mais avançado baseado no de arquitetura de linha de base do AKS, consulte a arquitetura de microsserviços do AKS avançada.

Workflow

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

O fluxo de dados a seguir corresponde ao diagrama anterior:

  1. O aplicativo cliente envia uma carga JSON sobre HTTPS para o nome de domínio totalmente qualificado público do balanceador de carga (controlador de entrada gerenciado) para agendar uma retirada 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 as solicitações e as solicitações de entrega de filas em uma fila do Barramento de Serviço do Azure.

  2. O microsserviço de fluxo de trabalho:

    • Consome informações de mensagem da fila de mensagens do Barramento de Serviço.

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

  • do AKS é um cluster kubernetes gerenciado hospedado na nuvem do Azure. O AKS reduz a complexidade e a sobrecarga operacional de gerenciar o Kubernetes passando 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 de de gateway de API para microsserviços.

  • Armazenamentos de dados externos, como 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 Redis, Azure Cosmos DB para MongoDB e Barramento de Serviço como armazenamentos de dados ou locais para armazenar o estado.

  • de ID do Microsoft Entra é necessário para o cluster do AKS. Ele fornece uma identidade gerenciada usada para acessar o Registro de Contêiner do Azure e acessar e provisionar recursos do Azure, como balanceadores de carga e discos gerenciados. As cargas de trabalho implantadas em um cluster do 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. Nesta arquitetura de referência, a ID de Carga de Trabalho do Microsoft Entra 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.

  • registro de contêiner podem ser usados para armazenar imagens de contêiner privadas, que são implantadas no cluster. O AKS pode se autenticar com o Registro de Contêiner usando sua identidade do 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.

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

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

  • a do 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 ao AKS para coletar métricas de controladores, nós e contêineres.

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

Alternativas

aplicativos de contêiner do Azure fornece uma experiência de Kubernetes sem servidor gerenciada. 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 Gateway de Aplicativo para Contêineres, o gateway de entrada istio ou soluções que não são da Microsoft. Para obter mais informações, consulte Entrada no AKS.

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

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 o GitHub Actions 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 obtida 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. Empresas se registram no serviço e os usuários podem solicitar que um drone colete mercadorias para entrega. Quando um cliente agenda uma retirada, o sistema de back-end atribui um drone e notifica o usuário com um tempo de entrega estimado. Quando a entrega está em andamento, o cliente pode acompanhar a localização do drone com um tempo de entrega estimado continuamente atualizado.

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

Possíveis casos de uso

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

  • Aplicativos Web complexos
  • Lógica de negócios desenvolvida usando princípios de design de microsserviço

Considerações

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

Criar

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 flexível, com implantação independente do código. Os microsserviços normalmente se comunicam por meio de APIs bem definidas e podem ser descobertos por alguma forma de descoberta de serviços. O objeto de serviço 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 os serviços. A separação de dados ajuda a evitar o acoplamento não intencional entre os 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 seus requisitos específicos. 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 associa 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 de Disco do Azure ou arquivos do Azure. Para obter mais informações, confira Opções de armazenamento para aplicativos no AKS.

Gateway de API

Gateways de API são um padrão de design de microsserviços geral. 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 de corte cruzado, 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 manipula principalmente a funcionalidade de um gateway de API. O controlador de entrada e entrada trabalha em conjunto para:

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

  • Agregar 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 Gateway de Aplicativo do Azure. O AKS fornece várias opções de entrada gerenciada. Você pode escolher entre um controlador de entrada baseado em NGINX gerenciado por meio do complemento de roteamento de aplicativos, o Gateway de Aplicativo para Contêineres. Ou você pode escolher o gateway de entrada do Istio como o controlador de entrada. Para obter mais informações, consulte Entrada no AKS.

Os recursos de entrada dos objetos kubernetes foram substituídos pela API de Gateway do Kubernetes mais avançada e versátil. 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ção, a API de Gateway é um conjunto moderno de APIs para definir regras de roteamento L4 e L7 no Kubernetes.

O controlador de entrada opera como o roteador de borda ou proxy reverso. Um servidor proxy reverso é um possível 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 entrada 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 menores e menos complexas do Kubernetes que priorizam a configuração fácil.

  • Se atualmente você tiver controladores de entrada configurados em seu cluster kubernetes e eles atenderem aos seus requisitos efetivamente, 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 complexas de roteamento, divisão de tráfego e estratégias avançadas de gerenciamento de tráfego. A flexibilidade fornecida pelos recursos de Rota da API de Gateway do Kubernetes é 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 de Gateway do Kubernetes, com base em definições de recursos personalizadas, pode fornecer extensibilidade aprimorada.

Fiabilidade

A confiabilidade garante 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 parade confiabilidade.

Particionando microsserviços

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

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 administrar se todos vão para o mesmo namespace. Os namespaces também permitem:

  • Aplique restrições de recurso 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 só pode ter acesso ao namespace B por meio do Kubernetes políticas 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 limitado "Cumprimento da Ordem" podem entrar no mesmo namespace. Outra alternativa é criar um namespace para cada equipe de desenvolvimento.

Posicione os serviços essenciais 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.

Investigações de integridade

O Kubernetes define três tipos de investigações de integridade que um pod pode expor:

  • investigação Preparação: informa ao Kubernetes se o pod está pronto para aceitar solicitações.

  • investigação Liveness: informa ao Kubernetes se um pod deve ser removido e uma nova instância iniciada.

  • investigação de inicialização: informa ao Kubernetes se o pod foi iniciado.

Quando você pensa em investigações, é 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. O Kubernetes balanceia a carga de tráfego para os pods que correspondem ao seletor. Somente os pods que iniciam com êxito e são íntegros recebem tráfego. Se um contêiner falhar, o Kubernetes encerrará o pod e agenda uma substituição.

Às vezes, um pod pode não estar pronto para receber tráfego, mesmo que tenha sido iniciado com êxito. 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 investigação de inicialização para esses contêineres de início lento. Essa abordagem ajuda a impedir que o Kubernetes os encerre antes que eles tenham a chance de inicializar totalmente.

As investigações de atividade 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 tratando solicitações HTTP, mas de repente parar de responder sem falhar, a investigação de atividade detectará esse evento e disparará uma reinicialização do pod. Se você configurar uma investigação de atividade, ela observará quando um contêiner não está respondendo e solicitará ao Kubernetes que reinicie o pod se o contêiner falhar repetidamente na investigação.

Considere os pontos a seguir ao projetar investigações para microsserviços.

  • Se o código tiver um longo tempo de inicialização, haverá um perigo de uma investigação de vida relatar falha antes da conclusão da inicialização. Para atrasar o início de uma investigação de atividade, use a investigação de inicialização ou use a configuração initialDelaySeconds com a investigação de vida.

  • Uma investigação de vida útil só ajuda se a reinicialização do pod provavelmente o restaurar para um estado íntegro. Você pode usar uma investigação de atividade para atenuar vazamentos de memória ou deadlocks inesperados, mas não há razão para reiniciar um pod que falhará imediatamente novamente.

  • Às vezes, as investigações de preparação são usadas para verificar serviços dependentes. Por exemplo, se um pod tem uma dependência em um banco de dados, a investigação pode verificar a conexão de banco de dados. No entanto, essa abordagem pode criar problemas inesperados. Um serviço externo pode estar temporariamente indisponível. Essa indisponibilidade faz com que a investigação de preparação falhe para todos os pods em seu serviço, o que resulta na remoção deles do balanceamento de carga. Essa remoção cria falhas em cascata upstream.

    Uma abordagem melhor é implementar o tratamento de repetição em seu serviço para que seu serviço possa se recuperar corretamente de falhas transitórias. Como alternativa, o tratamento de repetição, a tolerância a erros e os disjuntores podem ser implementados pela 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 recurso para contêineres para que um único contêiner não possa sobrecarregar os recursos do cluster, como memória e CPU. Para recursos não contêineres, 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 passar fome pelos serviços de back-end para recursos ou vice-versa. As cotas de recursos podem ajudar a alocar recursos no 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.

Talvez você também precise girar seus certificados dependendo das políticas da organização. Você pode usar o Key Vault para girar certificados que os microsserviços usam. Para obter mais informações, consulte Configurar a rotação automática de certificado no Key Vault.

RBAC

Quando várias equipes desenvolvem e implantam microsserviços ao mesmo tempo, os mecanismos RBAC do AKS podem fornecer controle granular e filtragem de 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, confira Opções de acesso e identidade do AKS.

Autenticação e autorização

Os microsserviços podem exigir que os serviços de consumo ou os usuários autentiquem e autorizem o acesso ao microsserviço usando certificados, credenciais e mecanismos RBAC. A ID do Microsoft Entra pode ser usada para implementar tokens OAuth 2.0 parade 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ço.

Credenciais de aplicativo e gerenciamento de segredos

Aplicativos e serviços geralmente precisam de credenciais que permitam a eles 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 divulgá-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 na ID do Microsoft Entra. 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 na ID do Microsoft Entra e autentica usando tokens OAuth 2.0. O código em execução no 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 seja necessário armazenar algumas credenciais ou outros segredos do aplicativo. Esse armazenamento é necessário para serviços do Azure que não dão suporte a identidades gerenciadas, serviços não Microsoft ou chaves de API. Você pode usar as seguintes opções para ajudar a armazenar segredos com mais segurança:

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

  • Controle centralizado de segredos.
  • Ajudando a garantir que todos os segredos sejam criptografados em repouso.
  • Gerenciamento centralizado de chaves.
  • Controle de acesso de segredos.
  • Gerenciamento de ciclo de vida de chave.
  • Auditoria.

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

Segurança de contêiner e orquestrador

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

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

  • Monitorar vulnerabilidades. Monitore continuamente imagens e executando contêineres para vulnerabilidades conhecidas usando Microsoft Defender para Cloud ou uma solução que não seja da Microsoft.

  • Automatizar a aplicação de patch de imagem. Use tarefas do Registro de Contêiner do Azure, um recurso do Registro de Contêiner, para automatizar a aplicação de patch de imagem. Uma imagem de contêiner baseia-se em camadas. As camadas de base incluem a imagem do sistema operacional e as imagens da estrutura de aplicativo, como ASP.NET Core ou Node.js. As imagens base normalmente são criadas upstream dos desenvolvedores de aplicativos e outros mantenedores de 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 Registro de Contêiner ou o Registro Confiável do Docker 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 concede acesso ao contêiner para todos os dispositivos no host. Quando possível, evite executar processos como raiz dentro de contêineres. Os contêineres não fornecem isolamento completo do ponto de vista de segurança, portanto, é melhor executar um processo de contêiner como um usuário sem privilégios.

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

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

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

  • Antes que uma nova versão de um serviço seja implantada em produção, ela é implantada em ambientes de desenvolvimento, teste e Q&A para validação. Há restrições de qualidade impostas em cada estágio.

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

  • Há políticas de controle de acesso suficientes em vigor.

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

Para saber mais sobre os desafios, confira 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 etapas 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 maneiras 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 design parade Otimização de Custos.

Use a Calculadora de Preços do Azure para estimar os custos. Outras considerações são descritas na seção de Custo no do Microsoft Azure Well-Architected Framework.

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

AKS

  • No camada gratuita, 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 o cluster kubernetes consome.

  • Considere usar dimensionador automático de pod horizontal para dimensionar automaticamente microsserviços ou dimensioná-los dependendo da carga.

  • Configure de dimensionamento automático de cluster para dimensionar ou dimensioná-los dependendo da carga.

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

  • Examine as práticas recomendadas de otimização de custo parado AKS.

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

Azure Load Balancer (Balanceador de Carga do Azure)

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

Azure Pipelines

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 hospedado pela Microsoft gratuito com 1.800 minutos para cada mês para CI/CD e um trabalho auto-hospedado com minutos ilimitados para cada mês. Trabalhos extras incorrem em mais custos. Para obter mais informações, consulte de preços dos serviços do Azure DevOps.

Azure Monitor

No Log Analytics do Azure Monitor, você é cobrado pela ingestão e pela 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 de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design parade Excelência Operacional.

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 a replicação de cenários de produção. Essa abordagem ajuda você 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 o 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 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.

Implantar este cenário

Para a implantação de referência para esta arquitetura, siga as etapas em Reposição do GitHub. Para obter mais informações, consulte implementação de referência de microsserviços do AKS.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

Outros colaboradores:

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.

Próximas etapas