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

Azure Active Directory
Registro de Contêiner
Serviço de Kubernetes
Load Balancer
Pipelines

Essa arquitetura de referência mostra um aplicativo de microserviços implantado no AKS (serviço kubernetes do Azure). Ele descreve uma configuração básica de 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 orientação sobre como criar microserviços, consulte criando microserviços no Azure.

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

Arquitetura de referência do AKS

Baixe um Arquivo Visio dessa arquitetura.

Se você preferir ver um exemplo mais avançado de microserviços criado com base na arquitetura de linha de base do AKS, consulte arquitetura avançada de microserviços do AKS (serviço kubernetes do Azure)

Componentes

A arquitetura consiste nos componentes a seguir.

AKs ( serviço kubernetes do Azure ). AKS é um cluster kubernetes gerenciado hospedado na nuvem do Azure. Ao usar o AKS, 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 de agente estão conectados. Você pode criar a rede virtual primeiro para cenários mais avançados, o que permite controlar itens como configuração de sub-rede, conectividade local e endereçamento IP. Para obter mais informações, consulte Configurar rede avançada no AKS (Serviço de Kubernetes do Azure).

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

Azure Load Balancer. Depois de criar um cluster AKS, o cluster estará pronto para usar o balanceador de carga. Em seguida, depois que o serviço NGINX for implantado, o balanceador de carga será configurado com um novo IP público que fará o seu controlador de entrada front-end. Dessa forma, o balanceador de carga roteia o tráfego da Internet para a entrada.

Armazenamentos de dados externos. Microsserviços são normalmente sem estado e gravam o estado em armazenamentos de dados externos, como o Banco de Dados SQL do Azure ou o 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. Observe que o AKS não exige o Registro de Contêiner do Azure. Você pode usar outros registros de contêiner, como o Hub do Docker.

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

Helm. Helm é um Gerenciador de pacotes para kubernetes, uma maneira de agrupar e generalizar objetos kubernetes em uma única unidade que pode ser publicada, implantada, com controle de versão e atualizada.

Azure Monitor. 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 da causa raiz de falhas. O Azure Monitor integra-se com o AKS para coletar métricas de controladores, nós e contêineres.

Considerações sobre o design

Essa arquitetura de referência se concentra em arquiteturas de microserviç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 flexível, com implantação independente do código. Os microserviços normalmente se comunicam por meio de APIs bem definidas e são detectáveis por meio de alguma forma de descoberta de serviço. O serviço sempre deve estar acessível mesmo quando o pods se movimentar. O objeto de serviço kubernetes é uma maneira natural de modelar os microserviços no kubernetes.

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 microserviç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 abrangentes, como autenticação, terminação de SSL e limitação de taxa. Para obter mais informações, consulte:

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

Armazenamento de dados

Em uma arquitetura de microserviç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, o 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 adequado para suas necessidades específicas.

Para obter mais informações, consulte projetando microservices: considerações de dados.

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

para obter mais informações, consulte opções de Armazenamento para o aplicativo no serviço Kubernetes do Azure.

Objeto de serviço

O objeto de serviço kubernetes fornece um conjunto de recursos que correspondem aos requisitos de microserviços para descoberta de serviço:

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

Serviços e pods

Entrada

No kubernetes, o controlador de entrada pode implementar o padrão de gateway de API. Nesse caso, o controlador de entrada e de entrada funciona em conjunto para fornecer estes recursos:

  • Encaminhe solicitações de cliente para os serviços de back-end corretos. Isso cria um ponto de extremidade único para os clientes e ajuda a separar clientes de serviços.

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

  • Descarregue a funcionalidade 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).

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 da entrada. Há controladores de entrada para Nginx, HAProxy, Traefik e gateway de Aplicativo Azure, entre outros.

O recurso de entrada pode ser atendido por diferentes tecnologias. Para trabalhar juntos, eles precisam ser implantados como controlador de entrada dentro do cluster. Ele funciona como o roteador de borda ou o 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.

Geralmente, a configuração do 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 boa abstração. O controlador de entrada também tem acesso à API 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 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, consulte implantando Nginx ou HAProxy em kubernetes.

Para AKS, você também pode usar Aplicativo Azure gateway, usando o controlador de entrada do gateway de aplicativo. Essa opção requer que a rede CNI seja habilitada quando você configura o cluster AKs, pois o gateway de aplicativo é implantado em uma sub-rede da rede virtual AKs. Aplicativo Azure gateway pode executar roteamento de camada 7 e terminação SSL. Ele também tem suporte interno para WAF (firewall do aplicativo Web).

Para obter informações sobre os serviços de balanceamento de carga no Azure, consulte 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. Assim, como parte da implantação do controlador de entrada, você precisa criar um certificado TLS. Use somente 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 de kubernetes do Azure (AKs).

Para cargas de trabalho de produção, obtenha certificados assinados de autoridades de certificação confiáveis (CA). Para obter informações sobre como gerar e configurar os certificados criptografados , consulte criar um controlador de entrada com um endereço IP público estático no serviço de kubernetes do Azure (AKs).

Talvez você também precise girar seus certificados de acordo com as políticas da organização. Para obter informações, consulte Rotate Certificates in Azure kubernetes Service (AKs).

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 kubernetes se o Pod está pronto para aceitar solicitações.

  • Investigação de tempo de vida: informa ao kubernetes se um pod deve ser removido e uma nova instância foi 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 isso, use a configuração initialDelaySeconds, que atrasa o início 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 tiver uma dependência em um banco de dados, a investigação poderá verificar a conexão do 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.

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 de pods e listagem de pods são ações que podem ser autorizadas (ou negadas) a um usuário por meio de RBAC kubernetes. Para atribuir permissões kubernetes a 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.

    • Também há um objeto ClusterRole, que é como 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 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 AKS realmente tem dois tipos de credenciais para chamar o servidor de API kubernetes: usuário de cluster e administrador de cluster. As credenciais de administrador do cluster concedem acesso completo 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.

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 permissões específicas em recursos de 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, convém saber quais permissões o cluster do AKS tem para criar e gerenciar recursos do Azure, como armazenamento, rede ou balanceadores de carga. 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 processo de execução chama um endereço do localhost para obter o token. Dessa forma, você não precisa armazenar senhas ou cadeias de conexão. Você pode usar identidades gerenciadas no AKS atribuindo identidades a pods individuais, usando o projeto aad-pod-identity.

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, consulte o projeto segredos-Store-CSI-driver-Provider-Azure no github.

    O pod se autentica usando uma identidade de pod (descrita acima) ou usando uma entidade de serviço do Azure AD, juntamente com um segredo do cliente. O uso de identidades de pod é recomendado porque o segredo do cliente não é necessário nesse caso.

  • 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 cofre em kubernetes, considere executá-lo em um cluster dedicado separado de seu cluster de aplicativos.

  • 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 de contêiner e Orchestrator

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

  • Monitoramento de ameaças: Monitore ameaças usando o Microsoft defender para registros de contêiner e o Microsoft defender para kubernetes (ou recursos de terceiros). Se você estiver hospedando contêineres em uma VM, use o Microsoft defender para servidores ou um recurso de terceiros. Além disso, você pode integrar logs da solução de monitoramento de contêineres no Azure monitor para o Microsoft Sentinel ou uma solução Siem existente.

  • Monitoramento de vulnerabilidade: Monitore continuamente imagens e execute contêineres 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 de imagem usando tarefas 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 registro de contêiner do Azure ou 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 princípio de 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.

Considerações de DevOps

Essa arquitetura de referência fornece um [modelo de Azure Resource Manager] [ARM-Template] para provisionar os recursos de nuvem e suas dependências. com o uso de [modelos de Azure Resource Manager] [arm-template], você pode usar [Azure DevOps Services] [az-DevOps] 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 de carga de trabalho para estruturar seu modelo de ARM, uma carga de trabalho normalmente é definida como uma unidade arbitrária de funcionalidade; Você poderia, por exemplo, ter um modelo separado para o cluster e, em seguida, outros para os serviços dependentes. o isolamento de carga de trabalho permite que DevOps execute a integração contínua e a entrega contínua (CI/CD), já 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 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 microserviços.

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

Considerações de custo

Use a Calculadora de Preços do Azure para estimar os custos. outras considerações são descritas na seção de custo no 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 para AKS em implantação, gerenciamento e operações do cluster 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, consulte a calculadora de serviços de contêiner.

Azure Load Balancer

Você é cobrado apenas pelo número de regras de balanceamento de carga e de saída configuradas. As regras de NAT de entrada são gratuitas. Não há cobrança por hora para o Standard Load Balancer quando nenhuma regra é configurada.

confira Azure Load Balancer preços para obter mais informações.

Azure Pipelines

Essa arquitetura de referência usa apenas 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 1 trabalho auto-hospedado com minutos ilimitados por mês, trabalhos extras têm encargos. para obter mais informações, consulte preços de Azure DevOps Services.

Azure Monitor

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

Implantar a solução

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

Próximas etapas