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

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 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 nas considerações de infraestrutura e DevOps da execução de uma arquitetura de microsserviços no AKS. Para obter orientação sobre como projetar microsserviços, consulte Criando microsserviços no Azure.

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

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

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

Fluxo de trabalho

A arquitetura é composta pelos seguintes componentes.

Serviço Kubernetes do Azure (AKS). O AKS é um cluster 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 coisas como configuração de sub-rede, conectividade local e endereçamento IP. Para obter mais informações, consulte Configurar rede avançada no Serviço Kubernetes do Azure (AKS).

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

Balanceador de Carga do Azure. Depois de criar um cluster AKS, o cluster está pronto para usar o balanceador de carga. Em seguida, uma vez implantado o serviço NGINX, o balanceador de carga será configurado com um novo IP público que fará frente ao seu controlador de entrada. Desta forma, o balanceador de carga encaminha o tráfego da Internet para a entrada.

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

ID do Microsoft Entra. O AKS usa uma identidade do Microsoft Entra para criar e gerenciar outros recursos do Azure, como balanceadores de carga do Azure. O Microsoft Entra ID também é recomendado para autenticação de usuário em aplicativos cliente.

Azure Container Registry. Use o Registro de Contêiner para armazenar imagens privadas do Docker, que são implantadas no cluster. O AKS pode autenticar-se com o Registo de Contentores utilizando a sua identidade Microsoft Entra. O AKS não requer o Azure Container Registry. Você pode usar outros registros de contêiner, como o Docker Hub. Apenas certifique-se de que seu registro de contêiner corresponda ou exceda o contrato de nível de serviço (SLA) para sua carga de trabalho.

Azure Pipelines. Os Pipelines do Azure fazem parte dos Serviços de DevOps do Azure e executam compilações, testes e implantações automatizados. Você também pode usar soluções de CI/CD de terceiros, como Jenkins.

Leme. O Helm é um gerenciador de pacotes para o Kubernetes, uma maneira de agrupar e generalizar objetos do 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, painéis e executar a análise de causa raiz de falhas. O Azure Monitor integra-se com o AKS para recolher métricas de controladores, nós e contentores.

Considerações

Design

Essa arquitetura de referência é focada em arquiteturas de microsserviços, embora muitas das práticas recomendadas se apliquem a outras cargas de trabalho em execução no AKS.

Microsserviços

Um microsserviço é uma unidade de código implantável de forma flexível e independente. 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 serviço deve estar sempre acessível, mesmo quando os pods se movem. O objeto Serviço do Kubernetes é uma maneira natural de modelar microsserviços no Kubernetes.

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. Ele atua como um proxy reverso, roteando solicitações de clientes para microsserviços. Ele também pode executar várias tarefas transversais, como autenticação, terminação SSL e limitação de taxa. Para obter mais informações, consulte:

• Usando gateways de API em microsserviços
• Escolhendo uma tecnologia de gateway

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

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, que pode acontecer quando os serviços compartilham 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 certo para suas necessidades específicas.

Para obter mais informações, consulte Projetando microsserviços: considerações sobre dados.

Evite armazenar dados persistentes no armazenamento de cluster local porque 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, consulte Opções de armazenamento para aplicativo no Serviço Kubernetes do Azure.

Objeto de serviço

O objeto Kubernetes Service fornece um conjunto de recursos que correspondem aos requisitos de microsserviços para a descoberta de serviços:

• 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 é sempre acessível neste endereço IP interno.

• Balanceamento de carga. O tráfego enviado para o endereço IP do serviço é balanceado para os pods.

• Descoberta de serviços. Os serviços recebem entradas DNS internas pelo 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 utilizado para a comunicação serviço-a-serviço. As entradas DNS são organizadas por namespace, portanto, se seus namespaces corresponderem a contextos limitados, o nome DNS de 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 endereços IP e portas de ponto de extremidade é feito pelo kube-proxy, o proxy de rede do Kubernetes.

Entrada

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

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

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

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

Ingress abstrai as definições de configuração para um servidor proxy. Você também precisa de um controlador Ingress, que fornece a implementação subjacente do Ingress. Existem controladores Ingress para Nginx, HAProxy, Traefik e Azure Application Gateway, entre outros.

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

Muitas vezes, a configuração do servidor proxy requer arquivos complexos, que podem ser difíceis de ajustar se você não for um especialista. Assim, o controlador Ingress fornece uma boa abstração. O controlador Ingress também tem acesso à API do Kubernetes, para que possa tomar decisões inteligentes sobre roteamento e balanceamento de carga. Por exemplo, o controlador de entrada Nginx ignora o proxy de rede kube-proxy.

Por outro lado, se você precisar de controle total sobre as configurações, convém ignorar essa abstração e configurar o servidor proxy manualmente. Para obter mais informações, consulte Implantando Nginx ou HAProxy no Kubernetes.

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

Encriptação TLS/SSL

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

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

Também pode ser necessário alternar seus certificados de acordo com as políticas da organização. Para obter informações, consulte Girar certificados no Serviço Kubernetes do Azure (AKS).

Namespaces (Espaços de nomes)

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

Primeiro, 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. Além disso, os namespaces 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, incluindo RBAC e políticas de 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 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 o Elasticsearch ou o Prometheus para monitoramento de cluster ou o Tiller para Helm.

Sondas do estado de funcionamento

O Kubernetes define dois tipos de sonda de integridade 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.

Ao pensar em sondas, é útil 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 começaram com sucesso e estão saudáveis recebem tráfego. Se um contêiner falhar, o Kubernetes mata o pod e agenda uma substituição.

Às vezes, um pod pode não estar pronto para receber tráfego, mesmo que o pod tenha sido iniciado com êxito. Por exemplo, pode haver tarefas de inicialização, em que o aplicativo em execução no contêiner carrega coisas na memória ou lê dados de configuração. Para indicar que um pod está íntegro, mas não está pronto para receber tráfego, defina uma sonda de prontidão.

As sondas Liveness lidam com o caso em que um pod ainda está funcionando, mas não é saudável e deve ser reciclado. Por exemplo, suponha que um contêiner esteja servindo solicitações HTTP, mas trave por algum motivo. O contêiner não trava, mas parou de atender a todas as solicitações. Se você definir uma sonda de vivacidade HTTP, a sonda deixará de responder e informará o Kubernetes para reiniciar o pod.

Aqui estão algumas considerações ao projetar sondas:

• Se o seu código tiver um longo tempo de inicialização, há o perigo de que uma sonda de vivacidade reporte uma falha antes que a inicialização seja concluída. Para evitar essa falha de sonda, use a configuração, que atrasa o initialDelaySeconds início da sonda.

• Uma sonda de vivacidade não ajuda, a menos que reiniciar o pod provavelmente o restaure a um estado saudável. Você pode usar uma sonda de vivacidade para mitigar vazamentos de memória ou bloqueios inesperados, mas não adianta 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 por algum motivo. Isso fará com que a sonda de prontidão falhe para todos os pods em seu serviço, fazendo com que todos eles sejam removidos do balanceamento de carga e, assim, criando falhas em cascata a montante. Uma abordagem melhor é implementar o tratamento de novas tentativas dentro do seu serviço, para que o 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, de modo que um único contêiner não possa sobrecarregar os recursos do cluster (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 de Antepara para isolar recursos.

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

Segurança

Controlo de acesso baseado em funções (RBAC)

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

• O RBAC do Azure controla o acesso a 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 por aplicativos.)

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

  • Uma Função é 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 uma Função.

  • Há também um objeto ClusterRole, que é como um Role, 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 estes dois mecanismos RBAC. Ao criar um cluster AKS, você pode configurá-lo para usar o ID do Microsoft Entra para autenticação do usuário. Para obter detalhes sobre como configurar isso, consulte Integrar o Microsoft Entra ID ao Serviço Kubernetes do Azure.

Depois que isso estiver configurado, um usuário que deseja acessar a API do Kubernetes (por exemplo, por meio do kubectl) deve entrar usando suas credenciais do Microsoft Entra.

Por padrão, um usuário do Microsoft Entra não tem acesso ao cluster. Para conceder acesso, o administrador do cluster cria RoleBindings que se referem a usuários ou grupos do Microsoft Entra. Se um usuário não tiver permissões para uma operação específica, ela falhará.

Se os usuários não tiverem acesso por padrão, como o administrador do cluster terá permissão para criar as associações de função em primeiro lugar? Na verdade, um cluster AKS tem dois tipos de credenciais para chamar o servidor de API do Kubernetes: usuário do cluster e administrador do cluster. As credenciais de administrador do cluster concedem acesso total ao cluster. O comando az aks get-credentials --admin CLI do Azure baixa as credenciais de administrador do 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 os objetos Função de cluster e RoleBinding 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 os Recursos do Azure, AKS e recursos do 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 Role e RoleBindings para dar suporte a padrões de acesso avançados ou mais granulares. Quando habilitados, os principais do Microsoft Entra serão validados exclusivamente pelo RBAC do Azure, enquanto os usuários regulares do Kubernetes e as contas de serviço serão validados exclusivamente pelo RBAC do Kubernetes.

Como as credenciais de administrador do cluster são muito poderosas, use o RBAC do Azure para restringir o acesso a elas:

• A "Função de Administrador do Cluster de Serviço do Kubernetes do Azure" tem permissão para baixar as credenciais de administrador do cluster. Somente os administradores de cluster devem ser atribuídos a essa função.

• A "Função de Usuário do Cluster de Serviço Kubernetes do Azure" tem permissão para baixar as credenciais de usuário do cluster. Usuários não administradores podem ser atribuídos a essa função. Essa função não dá permissões específicas sobre os recursos do Kubernetes dentro do cluster — apenas permite que um usuário se conecte ao servidor de API.

Ao definir suas políticas RBAC (Kubernetes e Azure), pense nas funções em sua organização:

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

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

Finalmente, há a questão de quais permissões o cluster AKS tem para criar e gerenciar recursos do Azure, como balanceadores de carga, rede ou armazenamento. Para autenticar-se com APIs do Azure, o cluster usa uma entidade de serviço Microsoft Entra. 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 criar a entidade de serviço primeiro e atribuir as permissões RBAC mínimas a ela. Para obter mais informações, consulte Entidades de serviço com o Serviço Kubernetes do Azure.

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, uma opção é usar identidades gerenciadas. A ideia de uma identidade gerenciada é que um aplicativo ou serviço tenha uma identidade armazenada na ID do Microsoft Entra e use 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 do processo de execução pode fazer com que o token seja usado de forma transparente. Dessa forma, você não precisa armazenar senhas ou cadeias de conexão. Você pode usar identidades gerenciadas no AKS atribuindo identidades do Microsoft Entra a pods individuais, usando o ID de carga de trabalho do Microsoft Entra (visualização).

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

Mesmo com identidades gerenciadas, você provavelmente precisará armazenar algumas credenciais ou outros segredos de aplicativo, seja para serviços do Azure que não oferecem suporte a identidades gerenciadas, serviços de terceiros, chaves de API e assim por diante. 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 Cofre da Chave como um volume. O volume lê os segredos do Cofre da Chave. O pod pode então ler os segredos como um volume normal. Para obter mais informações, consulte Usar o Provedor do Cofre de Chaves do Azure para o Driver CSI do Repositório de Segredos em um cluster AKS.

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

• Cofre HashiCorp. Os aplicativos Kubernetes podem se autenticar com o HashiCorp Vault usando identidades gerenciadas do Microsoft Entra. Consulte HashiCorp Vault fala Microsoft Entra ID. Você pode implantar o próprio Vault no Kubernetes, considere executá-lo em um cluster dedicado separado do cluster de aplicativos.

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

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

• Controle centralizado de segredos.
• Garantir que todos os segredos são encriptados em repouso.
• Gestão centralizada de chaves.
• Controle de acesso de segredos.
• Auditoria

Segurança de contêineres e orquestradores

Estas são práticas recomendadas para proteger seus pods e contêineres:

• Monitoramento de ameaças: monitore ameaças usando o Microsoft Defender for Containers (ou recursos de terceiros 3rd). Se você estiver hospedando contêineres em uma VM, use o Microsoft Defender para servidores ou um recurso de terceiros 3rd. 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 for Cloud ou uma solução de terceiros disponível no Azure Marketplace.

• Automatize a aplicação de patches de imagem usando as Tarefas ACR, um recurso do Registro de Contêiner do Azure. Uma imagem de contêiner é construída a partir de camadas. As camadas base incluem a imagem do sistema operacional e imagens da estrutura do aplicativo, como ASP.NET Core ou Node.js. As imagens base são normalmente criadas a montante 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 nenhuma vulnerabilidade de segurança conhecida. As tarefas 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 garantir que os pods só possam extrair imagens do registro confiável.

• Aplicar o princípio do Privilégio Mínimo

  • Não execute contêineres no modo privilegiado. O modo privilegiado dá a um contêiner acesso a todos os dispositivos no host.
  • Sempre que 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.

DevOps

Essa arquitetura de referência fornece um modelo do Azure Resource Manager para provisionar os recursos de nuvem e suas dependências. Com o uso de [modelos do Azure Resource Manager][arm-template], você pode usar os Serviços de DevOps do Azure 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 seu modelo 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 integração contínua e entrega contínua (CI/CD), uma vez que cada carga de trabalho é associada e gerenciada por sua equipe de DevOps correspondente.

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

Aqui estão alguns 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/controle de qualidade 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.

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

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 Custo em Microsoft Azure Well-Architected Framework.

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

Azure Kubernetes Service (AKS)

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

Para calcular o custo dos recursos necessários, veja a calculadora de Serviços de Contentores.

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 por hora para o Balanceador de Carga Padrão quando nenhuma regra está configurada.

Para obter mais informações, consulte Preços do Balanceador de Carga do Azure.

Pipelines do Azure

Essa arquitetura de referência usa apenas o Azure Pipelines. O Azure oferece o Pipeline do Azure 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 por mês, trabalhos extras têm cobranças. 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.

Implementar este cenário

Para implantar a implementação de referência para essa arquitetura, siga as etapas no repositório GitHub.

Próximos passos

• Entidades de serviço com o Serviço 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 for Cloud ou uma solução de terceiros 3rd disponível através do Azure Marketplace.
• Tarefas ACR

Recursos relacionados

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