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

Essa arquitetura de referência mostra um aplicativo de microsserviços implantado no AKS (Serviço de Kubernetes do Azure). Ela mostra uma configuração básica do AKS que pode ser o ponto de partida para a maioria das implantações. Este artigo pressupõe conhecimentos básicos de Kubernetes. O artigo se concentra principalmente na infraestrutura e nas considerações de DevOps na execução de uma arquitetura de microsserviços no AKS. Para obter diretrizes sobre como criar microsserviços, confira Como criar microsserviços no Azure.

Uma implementação de referência para essa arquitetura está disponível no GitHub.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Se você preferir ver um exemplo de microsserviços mais avançado baseado na arquitetura de linha de base do AKS, confira Arquitetura de microsserviços do AKS (Serviço de Kubernetes do Azure)

Fluxo de trabalho

A arquitetura consiste nos componentes a seguir.

AKS (Serviço de Kubernetes do Azure). O AKS é um cluster de Kubernetes gerenciado hospedado na nuvem do Azure. O Azure gerencia o serviço de API do Kubernetes e você só precisa gerenciar os nós do agente.

Rede virtual. Por padrão, o AKS cria uma rede virtual na qual os nós do agente estão conectados. Você pode criar a rede virtual primeiro para cenários mais avançados, o que permite controlar, por exemplo, como as sub-redes são configuradas, a conectividade local e o endereçamento IP. Para obter mais informações, consulte Configurar rede avançada no AKS (Serviço de Kubernetes do Azure).

Entrada. Uma entrada expõe as rotas de HTTP(S) para serviços dentro do cluster. Para obter mais informações, consulte a seção Gateway de API abaixo.

Azure Load Balancer. Após criar um cluster do AKS, o cluster está pronto para usar o balanceador de carga. Depois que o serviço NGINX for implantado, o balanceador de carga será configurado com um novo IP público que fará frente ao controlador de entrada. Dessa forma, o balanceador de carga roteia o tráfego da Internet para a entrada.

Armazenamentos de dados externos. Os microsserviços normalmente são sem estado e gravam o estado em armazenamentos de dados externos, como o Banco de Dados SQL do Azure ou o Azure Cosmos DB.

Active Directory do Azure. O AKS usa uma identidade do Azure AD (Azure Active Directory) para criar e gerenciar outros recursos do Azure, como os balanceadores de carga do Azure. O Azure AD também é recomendado para autenticação de usuário em aplicativos cliente.

Registro de Contêiner do Azure. Use o Registro de Contêiner para armazenar imagens privadas do Docker, que são implantadas no cluster. O AKS pode fazer a autenticação com o Registro de Contêiner usando sua identidade do Azure AD. O AKS não requer Registro de Contêiner do Azure. Você pode usar outros registros de contêiner, como o Hub do Docker. Basta garantir que o registro de contêiner corresponda ou exceda o SLA (contrato de nível de serviço) para sua carga de trabalho.

Azure Pipelines. O Azure Pipelines faz parte do Azure DevOps Services e executa builds, implantações e testes automatizados. Você também pode usar soluções de CI/CD de terceiros, como o Jenkins.

Helm. O Helm é um gerenciador de pacotes para Kubernetes, uma forma de agrupar e generalizar objetos Kubernetes em uma única unidade que pode ser publicada, implantada, versionada e atualizada.

Azure Monitor. O Azure Monitor coleta e armazena métricas e logs, telemetria de aplicativos e métricas de plataforma para os serviços do Azure. Use esses dados para monitorar o aplicativo, configurar alertas e painéis e executar a análise da causa raiz de falhas. O Azure Monitor integra-se ao AKS para coletar métricas de controladores, nós e contêineres.

Considerações

Design

Essa arquitetura de referência se concentra em arquiteturas de microsserviços, embora muitas das práticas recomendadas serão aplicáveis a outras cargas de trabalho em execução 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 serviço sempre deve ser acessível mesmo quando os pods se movem. O objeto Kubernetes Service é uma maneira natural de modelar microsserviços no Kubernetes.

Gateway de API

Gateways de API são um padrão de design de microsserviços geral. Um gateway de API se posiciona entre os clientes externos e os microsserviços. Ele atua como um proxy reverso, encaminhando as solicitações de clientes para os microsserviços. Ele também pode executar várias tarefas detalhadas, como autenticação, terminação de SSL e a limitação de taxa. Para obter mais informações, consulte:

• Usar Gateways de API em microsserviços
• Escolhendo uma tecnologia de gateway

No Kubernetes, a funcionalidade de um gateway de API é tratada principalmente por um controlador de entrada. As considerações são descritas na seção Entrada.

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 serviços, o que poderá ocorrer se os serviços compartilharem os mesmos esquemas de dados subjacentes. Além disso, quando os serviços gerenciam seus próprios armazenamentos de dados, eles podem usar o armazenamento de dados adequado para suas necessidades específicas.

Para obter mais informações, confira Criar microsserviços:considerações sobre dados.

Evite armazenar dados persistentes no armazenamento de cluster local, pois isso vincula os dados ao nó. Em vez disso, use um serviço externo, como o Banco de Dados SQL do Azure ou o Azure Cosmos DB. Outra opção é montar um volume de dados persistente em uma solução usando discos do Azure ou Arquivos do Azure.

Para obter mais informações, confira Opções de armazenamento para aplicativos no Serviço de Kubernetes do Azure.

Objeto de serviço

O objeto Kubernetes Servicefornece um conjunto de recursos que correspondem a estes requisitos para serviços de detectabilidade:

• Endereço IP. O objeto Service fornece um endereço IP interno estático para um grupo de pods (ReplicaSet). À medida que os pods são criados ou movidos, o serviço fica sempre acessível nesse endereço IP interno.

• Balanceamento de carga. A carga do tráfego enviado para o endereço IP do serviço é balanceada nos pods.

• Descoberta de serviço. Os serviços recebem entradas DNS internas do serviço DNS do Kubernetes. Isso significa que o gateway de API pode chamar um serviço de back-end usando o nome DNS. O mesmo mecanismo pode ser usado para comunicação entre serviços. As entradas DNS são organizadas por namespace e, portanto, se seus namespaces correspondem aos contextos limitados, o nome DNS para um serviço será mapeado naturalmente para o domínio do aplicativo.

O diagrama a seguir mostra a relação conceitual entre serviços e pods. O mapeamento real para portas e endereços IP do ponto de extremidade é feito pelo kube-proxy, o proxy de rede do Kubernetes.

Entrada

No Kubernetes, o controlador de entrada pode implementar o padrão de gateway de API. Nesse caso, o Ingress e o Controlador de entrada trabalham em conjunto para fornecer esses recursos:

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

• Agregação de várias solicitações em uma única solicitação, para reduzir conversas entre o cliente e o back-end.

• Funcionalidades de serviços de back-end, como terminação SSL, autenticação, lista de permissões de IP ou limitação de taxa do cliente (limitação).

A entrada abstrai as definições de configuração para um servidor proxy. Você também precisa de um controlador de entrada, que fornece a implementação subjacente do Ingress. Há controladores de entrada para Nginx, HAProxy, Traefik e Gateway de Aplicativo do Azure (versão prévia), entre outros.

O recurso de entrada pode ser atendido por diferentes tecnologias. Para trabalhar em conjunto, eles precisam ser implantados como o controlador de entrada dentro do cluster. Ele opera como o roteador de borda ou proxy reverso. Um servidor proxy reverso é um possível gargalo ou um ponto único de falha, portanto, sempre implante pelo menos duas réplicas para alta disponibilidade.

Muitas vezes, configurar o servidor proxy requer arquivos complexos, o que pode ser difícil de ajustar se você não for um especialista. Portanto, o Controlador de Entrada fornece uma abstração agradável. O Controlador de Entrada também tem acesso à API do Kubernetes e pode tomar decisões inteligentes sobre o roteamento e o balanceamento de carga. Por exemplo, o controlador de entrada Nginx ignora o proxy de rede do kube-proxy.

Por outro lado, se você precisa de controle total sobre as configurações, talvez queira ignorar essa abstração e configurar o servidor proxy manualmente. Para obter mais informações, confira Como implantar Nginx ou HAProxy no Kubernetes.

Para obter informações sobre serviços de balanceamento de carga no Azure, confira Visão geral das opções de balanceamento de carga no Azure.

Criptografia TLS/SSL

Em implementações comuns, o controlador de Entrada é usado para terminação SSL. Portanto, como parte da implantação do controlador de entrada, você precisa criar um certificado TLS. Use apenas certificados autoassinados para fins de desenvolvimento/teste. Para mais informações confiraCriar um controlador de entrada HTTPS e usar seus próprios certificados TLS no AKS (Serviço de Kubernetes do Azure).

Para cargas de trabalho de produção, obtenha certificados assinados de AC (autoridades de certificação) confiáveis. Para obter informações sobre como gerar e configurar certificados Let's Encrypt, confira Criar um controlador de entrada com um endereço IP público estático no AKS (Serviço de Kubernetes do Azure).

Talvez você também precise girar seus certificados de acordo com as políticas da organização. Para informações, confira, Girar certificados no AKS (Serviço de Kubernetes do Azure).

Namespaces

Use namespaces para organizar os serviços dentro do cluster. Todos os objetos em um cluster do Kubernetes pertencem a um namespace. Por padrão, quando você cria um novo objeto, ele vai para o namespace default. Porém, é uma boa prática criar namespaces que sejam mais descritivos para ajudar a organizar os recursos no cluster.

Primeiro, os namespaces ajudam a evitar conflitos 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. Além disso, os namespaces permitem a você:

• Aplicar restrições de recursos a um namespace, para que o conjunto total de pods atribuído ao namespace não ultrapasse a cota de recursos do namespace.

• Aplicar políticas no nível do namespace, incluindo políticas de RBAC e segurança.

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 relativos ao contexto limitado "Preenchimento de pedidos" poderiam ir para o 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 Elasticsearch ou Prometheus para monitoramento de cluster, ou Tiller para o Helm.

Investigações de integridade

O Kubernetes define dois tipos de investigação de integridade que um pod pode expor:

• Investigação de preparação: informa ao Kubernetes se o pod está pronto para aceitar solicitações.

• Investigação de atividade: informa ao Kubernetes se um pod precisa ser removido e uma nova instância precisa ser iniciada.

Ao pensar sobre os testes, é útil se lembrar de como funciona um serviço no Kubernetes. Um serviço tem um seletor de rótulo que corresponde a um conjunto de pods (zero ou mais). O Kubernetes balanceia a carga de tráfego para os pods que correspondem ao seletor. Somente os pods que foram iniciados com êxito e estão íntegros recebem tráfego. Em caso de falha de um contêiner, o Kubernetes elimina 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 que o aplicativo em execução no contêiner carregue coisas na memória ou leia dados de configuração. Para indicar que um pod está íntegro, mas não está pronto para receber tráfego, defina uma investigação de preparação.

As investigações de atividade lidam com pods ainda em execução, mas que não estão íntegros e devem ser reciclados. Por exemplo, suponha que um contêiner esteja atendendo a solicitações HTTP, mas pare de responder por algum motivo. O contêiner não falha, mas ele para de atender às solicitações. Se você definir uma investigação de atividade de HTTP, a investigação vai parar de responder e informa ao Kubernetes para reiniciar o pod.

Aqui estão algumas considerações para a criação de testes:

• Se o código tem um longo tempo de inicialização, há o risco de uma investigação de atividade relatar falha antes da conclusão da inicialização. Para evitar essa falha de investigação, use a initialDelaySeconds configuração , que atrasa a inicialização da investigação.

• A investigação de atividade só ajuda se a reinicialização do pod tiver chance de restaurá-lo para um estado íntegro. Você pode usar uma investigação de atividade para reduzir vazamentos de memória ou deadlocks inesperados, mas não há nenhuma razão para reiniciar um pod que vai falhar novamente de imediato.

• À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 por algum motivo. Isso fará com que a investigação de preparação falhe em todos os pods do serviço, fazendo com que todos sejam removidos do balanceamento de carga e criando falhas em cascata upstream. Uma abordagem melhor é implementar o tratamento de repetição no serviço, para que seu serviço possa se recuperar corretamente de falhas transitórias.

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 mesmo contêiner não possa sobrecarregar os recursos de cluster (memória e CPU). Para recursos que não são de contêiner, como threads ou conexões de rede, considere o uso do Padrão de Bulkhead para isolar recursos.

Use cotas de recursos para limitar o total de recursos permitido para um namespace. Dessa forma, o front-end não pode enfraquecer os serviços de back-end por causa de recursos ou vice-versa.

Segurança

RBAC (Controle de Acesso Baseado em Função)

O Kubernetes e o Azure têm mecanismos de RBAC (controle de acesso baseado em função):

• O RBAC do Azure controla o acesso aos recursos no Azure, incluindo a capacidade de criar novos recursos do Azure. As permissões podem ser atribuídas a usuários, grupos ou entidades de serviço. (Uma entidade de serviço é uma identidade de segurança usada pelos aplicativos.)

• O RBAC do Kubernetes controla permissões para a API do Kubernetes. Por exemplo, a criação e a listagem de pods são ações que podem ser autorizadas (ou negadas) a um usuário por meio do RBAC do Kubernetes. Para atribuir permissões de Kubernetes aos usuários, você cria funções e associações de função:

  • Role é um conjunto de permissões que se aplicam dentro de um namespace. As permissões são definidas como verbos (obter, atualizar, criar, excluir) em recursos (pods, implantações, etc.).

  • Um RoleBinding atribui usuários ou grupos a um Role.

  • Há também um objeto ClusterRole, que é como uma Função, mas se aplica a todo o cluster, em todos os namespaces. Para atribuir usuários ou grupos a um ClusterRole, crie um ClusterRoleBinding.

O AKS integra esses dois mecanismos de RBAC. Quando você cria um cluster do AKS, é possível configurá-lo para usar o Azure AD na autenticação de usuários. Para obter detalhes sobre como configurar isso, confira Integrar o Azure Active Directory com o Serviço de Kubernetes do Azure.

Depois que isso é configurado, um usuário que deseja acessar a API do Kubernetes (por exemplo, por kubectl) deve entrar usando suas credenciais do Azure AD.

Por padrão, um usuário do Azure AD não tem acesso ao cluster. Para conceder acesso, o administrador de cluster cria RoleBindings que se referem a grupos ou usuários do Azure AD. Se um usuário não tiver permissões para determinada operação, ela falhará.

Se os usuários não têm acesso por padrão, como o administrador de cluster tem permissão para criar as associações de função, para começar? Um cluster do AKS tem dois tipos de credenciais para chamar o servidor de API do Kubernetes: usuário de cluster e administrador de cluster. As credenciais de administrador do cluster concedem acesso total ao cluster. O comando da CLI do Azure az aks get-credentials --admin baixa as credenciais de administrador de cluster e as salva em seu arquivo kubeconfig. O administrador de cluster pode usar esse kubeconfig para criar funções e associações de função.

Em vez de gerenciar objetos Role e RoleBinding de cluster do Kubernetes nativamente no Kubernetes, é preferível usar o RBAC do Azure para autorização do Kubernetes. Isso permite o gerenciamento unificado e o controle de acesso entre recursos do Azure, AKS e Kubernetes. Essas atribuições de função RBAC do Azure podem direcionar o cluster ou namespaces dentro do cluster para um controle de acesso mais refinado. O RBAC do Azure dá suporte a um conjunto limitado de permissões padrão e você pode combiná-lo com o mecanismo nativo do Kubernetes de gerenciamento de Função e RoleBindings para dar suporte a padrões de acesso avançados ou mais granulares. Quando habilitada, as entidades de segurança do Azure AD serão validadas exclusivamente pelo RBAC do Azure, enquanto usuários e contas de serviço regulares do Kubernetes são validados exclusivamente pelo RBAC do Kubernetes.

Como as credenciais de administrador de cluster têm muito poder, use o RBAC do Azure para restringir o acesso a elas:

• A "Função de administrador de cluster do Serviço de Kubernetes do Azure" tem permissão para baixar as credenciais de administrador de cluster. Somente os administradores de cluster devem receber essa função.

• A "Função de usuário de cluster do Serviço de Kubernetes do Azure" tem permissão para baixar as credenciais de usuário de cluster. Os usuários não administradores não podem receber essa função. Essa função não fornece nenhuma permissão específica em recursos do Kubernetes dentro do cluster, apenas permite que um usuário se conecte ao servidor de API.

Quando você definir as políticas de RBAC (Kubernetes e Azure), pense sobre as funções em sua organização:

• Quem pode criar ou excluir um cluster do AKS e baixar as credenciais de administrador?
• Quem pode administrar um cluster?
• Quem pode criar ou atualizar recursos dentro de um namespace?

É uma boa prática criar o escopo das permissões de RBAC do Kubernetes por namespace, usando Roles e RoleBindings em vez de ClusterRoles e ClusterRoleBindings.

Por fim, há a questão de quais permissões o cluster do AKS tem para criar e gerenciar recursos do Azure, como balanceadores de carga, rede ou armazenamento. Para se autenticar com as APIs do Azure, o cluster usa uma entidade de serviço do Azure AD. Se você não especificar uma entidade de serviço ao criar o cluster, uma será criada automaticamente. No entanto, é uma boa prática de segurança primeiro criar a entidade de serviço e atribuir as permissões mínimas de RBAC a ela. Para obter mais informações, confira Entidades de serviço com o Serviço de Kubernetes do Azure.

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, uma opção é usar identidades gerenciadas. A ideia de uma identidade gerenciada é que um aplicativo ou serviço tenha uma identidade armazenada no Azure AD e use essa identidade para se autenticar em um serviço do Azure. O aplicativo ou serviço tem uma entidade de serviço criada para ele no Azure AD e é autenticado usando tokens OAuth 2.0. O código do processo em execução pode obter de forma transparente o token a ser usado. Dessa forma, você não precisa armazenar senhas ou cadeias de conexão. Você pode usar identidades gerenciadas no AKS atribuindo identidades Azure AD a pods individuais, usando Azure AD identidades de carga de trabalho (versão prévia).

Atualmente, nem todos os serviços do Azure dão suporte à autenticação usando identidades gerenciadas. Para obter uma lista, consulte Serviços do Azure que dão suporte à autenticação do Azure AD.

Mesmo com identidades gerenciadas, você provavelmente precisará armazenar algumas credenciais ou outros segredos do aplicativo, seja para serviços do Azure que não dão suporte a identidades gerenciadas, serviços de terceiros, chaves de API ou outros. Aqui estão algumas opções para armazenar segredos com segurança:

• Azure Key Vault. No AKS, você pode montar um ou mais segredos do Key Vault como um volume. O volume lê os segredos do Key Vault. O pod, em seguida, pode ler os segredos como um volume normal. Para obter mais informações, confira Usar o Provedor de Key Vault do Azure para Driver CSI do Repositório de Segredos em um cluster do AKS.

  O pod se autentica usando uma identidade de carga de trabalho ou usando uma identidade gerenciada atribuída pelo usuário ou pelo sistema. Confira Fornecer uma identidade para acessar o Provedor de Key Vault do Azure para Driver CSI do Repositório de Segredos para obter mais considerações.

• HashiCorp Vault. Os aplicativos do Kubernetes podem se autenticar com o HashiCorp Vault usando identidades gerenciadas do Azure AD. Confira O HashiCorp Vault é compatível com o Azure Active Directory. Você pode implantar o Vault em si no Kubernetes, mas considere executá-lo em um cluster dedicado separado de seu aplicativo cluster.

• segredos do Kubernetes. Outra opção é simplesmente usar segredos do Kubernetes. Essa opção é a mais fácil de configurar, mas tem alguns desafios. Os segredos são armazenados em etcd, que é um armazenamento de chave-valor distribuído. O AKS criptografa etcd em repouso. A Microsoft gerencia as chaves de criptografia.

Usar um sistema como HashiCorp Vault ou o Azure Key Vault oferece várias vantagens, como:

• Controle centralizado de segredos.
• Garantia de que todos os segredos sejam criptografados em repouso.
• Gerenciamento centralizado de chaves.
• Controle de acesso de segredos.
• Auditoria

Segurança do Contêiner e do Orchestrator

Estas são práticas recomendadas para a proteção de seus pods e contêineres:

• Monitoramento de ameaças: Monitore ameaças usando o Microsoft Defender para Contêineres (ou recursos de terceiros). Se você estiver hospedando contêineres em uma VM, use Microsoft Defender para servidores ou uma funcionalidade de terceiros. Além disso, você pode integrar logs da solução de Monitoramento de Contêiner no Azure Monitor ao Microsoft Sentinel ou a uma solução SIEM existente.

• Monitoramento de vulnerabilidades: Monitore continuamente imagens e contêineres em execução para vulnerabilidades conhecidas usando o Microsoft Defender para Nuvem ou uma solução de terceiros disponível por meio do Azure Marketplace.

• Automatize a aplicação de patch em imagens usando Tarefas do ACR, um recurso do Registro de Contêiner do Azure. 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 de base são normalmente criadas upstream a partir dos desenvolvedores de aplicativos e são mantidas por outros mantenedores do projeto. Quando essas imagens são corrigidas upstream, é importante atualizar, testar e reimplantar suas próprias imagens, para que você não deixe passar nenhuma vulnerabilidade de segurança conhecida. As Tarefas do ACR podem ajudar a automatizar esse processo.

• Armazene imagens em um registro privado confiável como o Registro de Contêiner do Azure ou o Registro Confiável do Docker. Use um webhook de admissão de validação no Kubernetes para fazer com que os pods possam efetuar pull somente de imagens do registro confiável.

• Aplicar o princípio privilégio mínimo

  • 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 e, portanto, é melhor executar um processo de contêiner como um usuário sem privilégios.

DevOps

Essa arquitetura de referência fornece um modelo de Resource Manager do Azure para provisionar os recursos de nuvem e suas dependências. Com o uso de [modelos de Resource Manager do Azure][arm-template] você pode usar Azure DevOps Services para provisionar ambientes diferentes em minutos, por exemplo, para replicar cenários de produção. Isso permite que você economize custos e provisione o ambiente de teste de carga somente quando necessário.

Considere seguir os critérios de isolamento da carga de trabalho para estruturar o modelo do ARM, uma carga de trabalho normalmente é definida como uma unidade arbitrária de funcionalidade; você pode, por exemplo, ter um modelo separado para o cluster e, em seguida, outro para os serviços dependentes. O isolamento da carga de trabalho permite que o DevOps execute ci/CD (integração contínua e entrega contínua), uma vez que cada carga de trabalho é associada e gerenciada por sua equipe de DevOps correspondente.

Considerações de implantação (CI/CD)

Aqui estão algumas 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 de uma nova versão de um serviço ser implantada na produção, ela é implantada em ambientes de desenvolvimento/teste/garantia de qualidade 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.

Para obter recomendações específicas e melhores práticas, confira CI/CD para microsserviços no Kubernetes.

Otimização de custo

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

Aqui estão alguns pontos a serem considerados para alguns dos serviços usados nesta arquitetura.

AKS (Serviço de Kubernetes do Azure)

Não há custos associados ao AKS na implantação, gerenciamento e operações do cluster do Kubernetes. Você paga apenas por instâncias de máquinas virtuais, armazenamento e recursos de rede consumidos pelo cluster do Kubernetes.

Para estimar o custo dos recursos necessários, confira a Calculadora dos Serviços de Contêiner.

Azure Load Balancer

Você é cobrado apenas pelo número de regras de saída e balanceamento de carga configuradas. As regras NAT 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 Preços Azure Load Balancer.

Azure Pipelines

Essa arquitetura de referência usa apenas o Azure Pipelines. O Azure oferece o Azure Pipelines como um Serviço individual. Você tem permissão para um trabalho hospedado pela Microsoft gratuito com 1.800 minutos por mês para CI/CD e um trabalho auto-hospedado com minutos ilimitados por mês, trabalhos extras têm encargos. Para obter mais informações, confira Preço do Azure DevOps Services.

Azure Monitor

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

Implantar este cenário

Para a implantação de referência para esta arquitetura, siga as etapas em Reposição do GitHub.

Próximas etapas

• Entidades de serviço com Serviço de Kubernetes do Azure
• Microsoft Defender para Contêineres
• Microsoft Defender para servidores
• Solução de monitoramento de contêiner no Azure Monitor
• Microsoft Sentinel ou uma solução SIEM existente.
• Microsoft Defender para Nuvem ou uma solução de terceiros disponível por meio do Azure Marketplace.
• Tarefas do ACR

Recursos relacionados

• Para trabalhar com um exemplo de microsserviços mais avançados, confira a Arquitetura de microsserviços avançada do AKS (Serviço de Kubernetes do Azure)
• Para saber mais sobre como monitorar essa arquitetura, confira Monitoramento de uma arquitetura de microsserviços no AKS (Serviço de Kubernetes do Azure).
• Para saber como medimos o desempenho desse aplicativo, confira o Cenário de ajuste de desempenho: transações comerciais distribuídas.
• CI/CD para arquiteturas de microsserviços
• CI/CD para microsserviços em Kubernetes