Editar

Arquitetura de microsserviços no Azure Kubernetes Service

Azure Active Directory
Container Registry
Kubernetes Service
Balanceador de Carga
Pipelines

Esta arquitetura de referência mostra uma aplicação de microsserviços implementada no Azure Kubernetes Service (AKS). Descreve uma configuração básica do AKS que pode ser o ponto de partida para a maioria das implementações. Este artigo pressupõe conhecimentos básicos do Kubernetes. O artigo centra-se principalmente nas considerações de infraestrutura e DevOps sobre a execução de uma arquitetura de microsserviços no AKS. Para obter orientações sobre como conceber microsserviços, veja Criar microsserviços no Azure.

Logótipo do GitHub Está disponível uma implementação de referência desta arquitetura no GitHub.

Arquitetura

Diagrama que mostra a arquitetura de referência do AKS.

Transfira um ficheiro do Visio desta arquitetura.

Se preferir ver um exemplo de microsserviços mais avançado criado com base na arquitetura da Linha de Base do AKS, veja Arquitetura de microsserviços do Azure Kubernetes Service Avançado (AKS)

Fluxo de trabalho

A arquitetura é composta pelos seguintes componentes.

Azure Kubernetes Service (AKS). O AKS é um cluster do Kubernetes gerido alojado na cloud do Azure. O Azure gere o serviço API do Kubernetes e só precisa de gerir os nós do agente.

Rede virtual. Por predefinição, o AKS cria uma rede virtual na qual os nós de agente estão ligados. Pode criar primeiro a rede virtual para cenários mais avançados, o que lhe permite controlar itens como a configuração da sub-rede, a conectividade no local e o endereçamento IP. Para obter mais informações, veja Configurar redes avançadas no Azure Kubernetes Service (AKS).

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

Balanceador de Carga do Azure. Depois de criar um cluster do AKS, o cluster está pronto para utilizar o balanceador de carga. Em seguida, assim que o serviço NGINX for implementado, o balanceador de carga será configurado com um novo IP público que irá fazer frente ao controlador de entrada. Desta forma, o balanceador de carga encaminha o tráfego da Internet para a entrada.

Arquivos de dados externos. Normalmente, os microsserviços não têm estado e escrevem estados em arquivos de dados externos, como a Base de Dados SQL do Azure ou o Azure Cosmos DB.

Azure Active Directory. O AKS utiliza uma identidade do Azure Active Directory (Azure AD) para criar e gerir outros recursos do Azure, como balanceadores de carga do Azure. Azure AD também é recomendado para autenticação de utilizadores em aplicações cliente.

Azure Container Registry. Utilize o Container Registry para armazenar imagens privadas do Docker, que são implementadas no cluster. O AKS pode autenticar-se com o Container Registry com a respetiva identidade de Azure AD. O AKS não requer Azure Container Registry. Pode utilizar outros registos de contentores, como Docker Hub. Certifique-se apenas de que o registo de contentor corresponde ou excede o contrato de nível de serviço (SLA) da carga de trabalho.

Pipelines do Azure. Os Pipelines do Azure fazem parte dos Serviços do Azure DevOps e executam compilações, testes e implementações automatizadas. Também pode utilizar soluções CI/CD de terceiros, como o Jenkins.

Helm. O Helm é um gestor de pacotes do Kubernetes, uma forma de agrupar e generalizar objetos do Kubernetes numa única unidade que pode ser publicada, implementada, versada e atualizada.

Azure Monitor. O Azure Monitor recolhe e armazena métricas e registos, telemetria de aplicações e métricas de plataforma para os serviços do Azure. Utilize estes dados para monitorizar a aplicação, configurar alertas, dashboards e efetuar a análise da causa das falhas. O Azure Monitor integra-se no AKS para recolher métricas de controladores, nós e contentores.

Considerações

Design

Esta arquitetura de referência está 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 livremente acoplada e implementável independentemente. Normalmente, os microsserviços comunicam através de APIs bem definidas e são detetáveis através de alguma forma de deteção de serviços. O serviço deve estar sempre acessível mesmo quando os pods se deslocam. O objeto do Serviço Kubernetes é uma forma natural de modelar microsserviços no Kubernetes.

Gateway de API

Os gateways de API são um padrão de design de microsserviços geral. Um gateway de API situa-se entre clientes externos e microsserviços. Atua como um proxy inverso, encaminhando pedidos de clientes para microsserviços. Também pode efetuar várias tarefas transversais, como autenticação, terminação SSL e limitação de taxas. Para obter mais informações, consulte:

No Kubernetes, a funcionalidade de um gateway de API é principalmente processada por um controlador de Entrada. As considerações estão descritas na secção Entrada .

Armazenamento de dados

Numa arquitetura de microsserviços, os serviços não devem partilhar soluções de armazenamento de dados. Cada serviço deve gerir o 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 partilham os mesmos esquemas de dados subjacentes. Além disso, quando os serviços gerem os seus próprios arquivos de dados, podem utilizar o arquivo de dados certo para os seus requisitos específicos.

Para obter mais informações, veja Estruturar microsserviços: Considerações de dados.

Evite armazenar dados persistentes no armazenamento de clusters local, uma vez que estes ligam os dados ao nó. Em vez disso, utilize um serviço externo, como a Base de Dados SQL do Azure ou o Azure Cosmos DB. Outra opção é montar um volume de dados persistente numa solução com o Azure Disks ou Ficheiros do Azure.

Para obter mais informações, veja Opções de armazenamento para aplicação no Azure Kubernetes Service.

Objeto de serviço

O objeto do Serviço Kubernetes fornece um conjunto de capacidades que correspondem aos requisitos de microsserviços para a deteção do serviço:

  • Endereço IP. O objeto Serviço 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 está com balanceamento de carga para os pods.

  • Deteção de serviços. São atribuídas entradas DNS internas aos serviços DNS do Kubernetes. Isto significa que o gateway de API pode chamar um serviço de back-end com 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 espaço de nomes, pelo que, se os espaços de nomes corresponderem a contextos vinculados, o nome DNS de um serviço será mapeado naturalmente para o domínio da aplicação.

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

Diagrama a mostrar serviços e pods.

Entrada

No Kubernetes, o controlador de entrada pode implementar o padrão do gateway de API. Nesse caso, o controlador de Entrada e Entrada trabalha em conjunto para fornecer estas funcionalidades:

  • Encaminhe pedidos de cliente para os serviços de back-end certos. Este encaminhamento fornece um ponto final único para os clientes e ajuda a desassociar os clientes dos serviços.

  • Agregar vários pedidos num único pedido, para reduzir a conversação entre o cliente e o back-end.

  • Descarregue a funcionalidade dos serviços de back-end, como a terminação de SSL, a autenticação, as restrições de IP ou a limitação da taxa de cliente (limitação).

A entrada abstrai as definições de configuração de um servidor proxy. Também precisa de um controlador de Entrada, que fornece a implementação subjacente da Entrada. Existem controladores de entrada para Nginx, HAProxy, Traefik e Gateway de Aplicação do Azure, entre outros.

O recurso de Entrada pode ser cumprido por diferentes tecnologias. Para trabalharem em conjunto, têm de ser implementados como controlador de entrada dentro do cluster. Funciona como router edge ou proxy inverso. Um servidor proxy inverso é um potencial estrangulamento ou ponto único de falha, pelo que implemente sempre, pelo menos, duas réplicas para elevada disponibilidade.

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

Por outro lado, se precisar de controlo total sobre as definições, poderá querer ignorar esta abstração e configurar manualmente o servidor proxy. Para obter mais informações, veja Deploying Nginx or HAProxy to Kubernetes (Implementar Nginx ou HAProxy no Kubernetes).

Nota

Para o AKS, também pode utilizar Gateway de Aplicação do Azure, utilizando o Controlador de Entrada Gateway de Aplicação (AGIC). Gateway de Aplicação do Azure pode executar o encaminhamento de camada 7 e a terminação SSL. Também tem suporte incorporado para firewall de aplicações Web (WAF). Se o cluster do AKS estiver a utilizar redes CNI, Gateway de Aplicação pode ser implementado numa sub-rede da rede virtual do cluster ou pode ser implementado numa rede virtual diferente da rede virtual do AKS. No entanto, as duas redes virtuais têm de estar em modo de peering em conjunto. O AGIC também suporta o plug-in de rede do Kubenet. Ao utilizar o modo Kubenet, o controlador de entrada tem de gerir uma tabela de rotas na sub-rede do Gateway de Aplicação para direcionar o tráfego para os IPs do pod. Para obter mais informações, veja Como configurar a rede entre Gateway de Aplicação e o AKS.

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

Encriptação TLS/SSL

Em implementações comuns, o controlador de entrada é utilizado para a terminação SSL. Por isso, como parte da implementação do controlador de entrada, tem de criar um certificado TLS. Utilize apenas certificados autoassinados para fins de desenvolvimento/teste. Para obter mais informações, consulte Criar um controlador de entrada HTTPS e utilizar os seus próprios certificados TLS no Azure Kubernetes Service (AKS).

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

Também poderá ter de rodar os certificados de acordo com as políticas da organização. Para obter informações, veja Rodar certificados em Azure Kubernetes Service (AKS).

Espaços de nomes

Utilize espaços de nomes para organizar serviços no cluster. Cada objeto num cluster do Kubernetes pertence a um espaço de nomes. Por predefinição, quando cria um novo objeto, este entra no default espaço de nomes. No entanto, é uma boa prática criar espaços de nomes mais descritivos para ajudar a organizar os recursos no cluster.

Em primeiro lugar, os espaços de nomes ajudam a evitar colisões de nomenclatura. Quando várias equipas implementam microsserviços no mesmo cluster, possivelmente com centenas de microsserviços, torna-se difícil gerir se todos entrarem no mesmo espaço de nomes. Além disso, os espaços de nomes permitem-lhe:

  • Aplique restrições de recursos a um espaço de nomes, para que o conjunto total de pods atribuídos a esse espaço de nomes não possa exceder a quota de recursos do espaço de nomes.

  • Aplique políticas ao nível do espaço de nomes, incluindo RBAC e políticas de segurança.

Para uma arquitetura de microsserviços, considere organizar os microsserviços em contextos vinculados e criar espaços de nomes para cada contexto vinculado. Por exemplo, todos os microsserviços relacionados com o contexto vinculado "Cumprimento da Encomenda" podem entrar no mesmo espaço de nomes. Em alternativa, crie um espaço de nomes para cada equipa de desenvolvimento.

Coloque os serviços utilitários no seu próprio espaço de nomes separado. Por exemplo, pode implementar Elasticsearch ou Prometheus para monitorização de clusters ou Tiller para Helm.

Sondas do estado de funcionamento

O Kubernetes define dois tipos de sonda de estado de funcionamento que um pod pode expor:

  • Sonda de preparação: informa o Kubernetes se o pod está pronto para aceitar pedidos.

  • Sonda liveness: indica ao Kubernetes se um pod deve ser removido e uma nova instância iniciada.

Ao pensar em sondas, é útil recordar como um serviço funciona no Kubernetes. Um serviço tem um seletor de etiquetas que corresponde a um conjunto de pods (zero ou mais). A carga do Kubernetes equilibra o tráfego para os pods que correspondem ao seletor. Apenas os pods que foram iniciados com êxito e estão em bom estado de funcionamento recebem tráfego. Se um contentor falhar, o Kubernetes elimina o pod e agenda uma substituição.

Por vezes, um pod pode não estar pronto para receber tráfego, apesar de o pod ter sido iniciado com êxito. Por exemplo, podem existir tarefas de inicialização, em que a aplicação em execução no contentor carrega itens para a memória ou lê dados de configuração. Para indicar que um pod está em bom estado de funcionamento, mas não está pronto para receber tráfego, defina uma sonda de preparação.

As sondas liveness lidam com o caso em que um pod ainda está em execução, mas está em mau estado de funcionamento e deve ser reciclado. Por exemplo, suponha que um contentor está a servir pedidos HTTP, mas bloqueia por algum motivo. O contentor não falha, mas deixou de servir quaisquer pedidos. Se definir uma sonda http liveness, a sonda deixará de responder e isso informa o Kubernetes para reiniciar o pod.

Seguem-se algumas considerações ao conceber sondas:

  • Se o seu código tiver um longo tempo de arranque, existe o perigo de uma sonda de liveness comunicar falhas antes da conclusão do arranque. Para evitar esta falha de pesquisa, utilize a initialDelaySeconds definição, o que atrasa o início da pesquisa.

  • Uma sonda de liveness não ajuda, a menos que reiniciar o pod seja susceptível de restaurá-lo para um estado de bom estado de funcionamento. Pode utilizar uma sonda de liveness para mitigar fugas de memória ou impasses inesperados, mas não faz sentido reiniciar um pod que volte a falhar imediatamente.

  • Por vezes, as sondas de preparação são utilizadas para verificar os serviços dependentes. Por exemplo, se um pod tiver uma dependência numa base de dados, a sonda poderá verificar a ligação da base de dados. No entanto, esta abordagem pode criar problemas inesperados. Um serviço externo pode estar temporariamente indisponível por algum motivo. Isto fará com que a sonda de preparação falhe para todos os pods no seu serviço, fazendo com que todos sejam removidos do balanceamento de carga e, assim, crie falhas em cascata a montante. Uma melhor abordagem é implementar o processamento de repetições no seu serviço, para que o seu serviço possa 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 contentores, para que um único contentor não possa sobrecarregar os recursos do cluster (memória e CPU). Para recursos não contentores, como threads ou ligações de rede, considere utilizar o Padrão de Bulkhead para isolar recursos.

Utilize quotas de recursos para limitar o total de recursos permitidos para um espaço de nomes. Desta forma, o front-end não pode efetuar a passagem de fome dos serviços de back-end para recursos ou vice-versa.

Segurança

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

O Kubernetes e o Azure têm mecanismos para o controlo de acesso baseado em funções (RBAC):

  • 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 utilizadores, grupos ou principais de serviço. (Um principal de serviço é uma identidade de segurança utilizada pelas aplicações.)

  • 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) a um utilizador através do RBAC do Kubernetes. Para atribuir permissões do Kubernetes aos utilizadores, crie funções e enlaces de função:

    • Uma Função é um conjunto de permissões que se aplicam num espaço de nomes. As permissões são definidas como verbos (obter, atualizar, criar, eliminar) em recursos (pods, implementações, etc.).

    • Um RoleBinding atribui utilizadores ou grupos a uma Função.

    • Existe também um objeto ClusterRole, que é como uma Função, mas que se aplica a todo o cluster, em todos os espaços de nomes. Para atribuir utilizadores ou grupos a um ClusterRole, crie um ClusterRoleBinding.

O AKS integra estes dois mecanismos RBAC. Quando cria um cluster do AKS, pode configurá-lo para utilizar Azure AD para a autenticação do utilizador. Para obter detalhes sobre como configurar esta configuração, veja Integrar o Azure Active Directory com Azure Kubernetes Service.

Assim que isto estiver configurado, um utilizador que pretenda aceder à API do Kubernetes (por exemplo, através do kubectl) tem de iniciar sessão com as respetivas credenciais de Azure AD.

Por predefinição, um utilizador Azure AD não tem acesso ao cluster. Para conceder acesso, o administrador do cluster cria RoleBindings que se referem a utilizadores ou grupos Azure AD. Se um utilizador não tiver permissões para uma determinada operação, falhará.

Se os utilizadores não tiverem acesso por predefinição, como é que o administrador do cluster tem permissão para criar os enlaces de função? Um cluster do AKS tem, na verdade, dois tipos de credenciais para chamar o servidor da API do Kubernetes: o utilizador do cluster e o administrador do cluster. As credenciais de administrador do cluster concedem acesso total ao cluster. O comando az aks get-credentials --admin da CLI do Azure transfere as credenciais de administrador do cluster e guarda-as no ficheiro kubeconfig. O administrador do cluster pode utilizar este kubeconfig para criar funções e enlaces de funções.

Em vez de gerir objetos role e RoleBinding de cluster do Kubernetes nativamente no Kubernetes, é preferível utilizar o RBAC do Azure para Autorização do Kubernetes. Isto permite a gestão unificada e o controlo de acesso em recursos do Azure, AKS e Kubernetes. Estas atribuições de funções RBAC do Azure podem direcionar o cluster ou espaços de nomes dentro do cluster para um controlo de acesso mais detalhado. O RBAC do Azure suporta um conjunto limitado de permissões predefinidas e pode combiná-lo com o mecanismo nativo do Kubernetes de gestão de Funções e RoleBindings para suportar padrões de acesso avançados ou mais granulares. Quando ativado, Azure AD principais serão validados exclusivamente pelo RBAC do Azure, enquanto os utilizadores normais do Kubernetes e as contas de serviço são validados exclusivamente pelo RBAC do Kubernetes.

Uma vez que as credenciais de administrador do cluster são tão poderosas, utilize o RBAC do Azure para restringir o acesso às mesmas:

  • A "Função de Administração de Cluster Azure Kubernetes Service" tem permissão para transferir as credenciais de administrador do cluster. Apenas os administradores do cluster devem ser atribuídos a esta função.

  • A "Azure Kubernetes Service Função de Utilizador do Cluster" tem permissão para transferir as credenciais de utilizador do cluster. Os utilizadores não administradores podem ser atribuídos a esta função. Esta função não dá permissões específicas aos recursos do Kubernetes dentro do cluster, apenas permite que um utilizador se ligue ao servidor de API.

Quando definir as políticas RBAC (kubernetes e Azure), pense nas funções na sua organização:

  • Quem pode criar ou eliminar um cluster do AKS e transferir as credenciais de administrador?
  • Quem pode administrar um cluster?
  • Quem pode criar ou atualizar recursos num espaço de nomes?

É uma boa prática definir o âmbito das permissões RBAC do Kubernetes por espaço de nomes, através de Funções e RoleBindings, em vez de ClusterRoles e ClusterRoleBindings.

Por fim, existe a questão das permissões que o cluster do AKS tem para criar e gerir recursos do Azure, como balanceadores de carga, redes ou armazenamento. Para se autenticar com as APIs do Azure, o cluster utiliza um principal de serviço Azure AD. Se não especificar um principal de serviço quando cria o cluster, um é criado automaticamente. No entanto, é uma boa prática de segurança criar primeiro o principal de serviço e atribuir-lhe as permissões RBAC mínimas. Para obter mais informações, veja Principais de serviço com Azure Kubernetes Service.

Gestão de segredos e credenciais da aplicação

Muitas vezes, as aplicações e os serviços precisam de credenciais que lhes permitam ligar a serviços externos, como o Armazenamento do Azure ou Base de Dados SQL. O desafio é manter estas credenciais seguras e não as divulgar.

Para os recursos do Azure, uma opção é utilizar identidades geridas. A ideia de uma identidade gerida é que uma aplicação ou serviço tem uma identidade armazenada no Azure AD e utiliza esta identidade para autenticar com um serviço do Azure. A aplicação ou serviço tem um Principal de Serviço criado para o mesmo no Azure AD e autentica com tokens OAuth 2.0. O código do processo de execução pode fazer com que o token seja utilizado de forma transparente. Dessa forma, não precisa de armazenar palavras-passe ou cadeias de ligação. Pode utilizar identidades geridas no AKS ao atribuir identidades Azure AD a pods individuais, utilizando Azure AD identidades de cargas de trabalho (pré-visualização).

Atualmente, nem todos os serviços do Azure suportam a autenticação com identidades geridas. Para obter uma lista, veja Serviços do Azure que suportam Azure AD autenticação.

Mesmo com identidades geridas, provavelmente terá de armazenar algumas credenciais ou outros segredos da aplicação, seja para serviços do Azure que não suportam identidades geridas, serviços de terceiros, chaves de API, etc. Eis algumas opções para armazenar segredos de forma segura:

A utilização de um sistema como o HashiCorp Vault ou o Azure Key Vault proporciona várias vantagens, tais como:

  • Controlo centralizado dos segredos.
  • Garantir que todos os segredos são encriptados inativos.
  • Gestão de chaves centralizada.
  • Controlo de acesso de segredos.
  • Auditoria

Segurança do Contentor e do Orchestrator

Estas são práticas recomendadas para proteger os seus pods e contentores:

  • Monitorização de ameaças: Monitorize ameaças com Microsoft Defender para Contentores (ou capacidades de terceiros). Se estiver a alojar contentores numa VM, utilize Microsoft Defender para servidores ou uma capacidade de terceiros. Além disso, pode integrar registos da solução de Monitorização de Contentores no Azure Monitor para o Microsoft Sentinel ou uma solução SIEM existente.

  • Monitorização de vulnerabilidades: Monitorize continuamente imagens e contentores em execução para vulnerabilidades conhecidas com Microsoft Defender para a Cloud ou uma solução de terceiros disponível através do Azure Marketplace.

  • Automatize a aplicação de patches de imagens com o ACR Tasks, uma funcionalidade do Azure Container Registry. Uma imagem de contentor é criada a partir de camadas. As camadas base incluem a imagem do SO e as imagens da arquitetura da aplicação, como ASP.NET Core ou Node.js. Normalmente, as imagens de base são criadas a montante a partir dos programadores de aplicações e são mantidas por outros responsáveis pela manutenção de projetos. Quando estas imagens são corrigidas a montante, é importante atualizar, testar e reimplementar as suas próprias imagens, para que não deixe quaisquer vulnerabilidades de segurança conhecidas. O ACR Tasks pode ajudar a automatizar este processo.

  • Armazene imagens num registo privado fidedigno, como o Azure Container Registry ou o Registo Fidedigno do Docker. Utilize um webhook de admissão de validação no Kubernetes para garantir que os pods só conseguem extrair imagens do registo fidedigno.

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

    • Não execute contentores no modo privilegiado. O modo privilegiado dá a um contentor acesso a todos os dispositivos no anfitrião.
    • Sempre que possível, evite executar processos como raiz dentro de contentores. Os contentores não fornecem isolamento completo do ponto de vista de segurança, pelo que é melhor executar um processo de contentor como um utilizador sem privilégios.

DevOps

Esta arquitetura de referência fornece um modelo de Resource Manager do Azure para aprovisionar os recursos da cloud e as respetivas dependências. Com a utilização de [modelos do Azure Resource Manager][arm-template] pode utilizar os Serviços de DevOps do Azure para aprovisionar diferentes ambientes em minutos, por exemplo, para replicar cenários de produção. Isto permite-lhe poupar custos e aprovisionar o ambiente de teste de carga apenas quando necessário.

Considere seguir os critérios de isolamento da carga de trabalho para estruturar o modelo do ARM. Normalmente, uma carga de trabalho é definida como uma unidade arbitrária de funcionalidade; poderia, 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 realize a integração contínua e a entrega contínua (CI/CD), uma vez que cada carga de trabalho é associada e gerida pela equipa de DevOps correspondente.

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

Eis alguns objetivos de um processo de CI/CD robusto para uma arquitetura de microsserviços:

  • Cada equipa pode criar e implementar os serviços que possui de forma independente, sem afetar ou perturbar outras equipas.
  • Antes de uma nova versão de um serviço ser implementada na produção, é implementada em ambientes de desenvolvimento/teste/QA para validação. As portas de qualidade são impostas em cada fase.
  • Uma nova versão de um serviço pode ser implementada lado a lado com a versão anterior.
  • Existem políticas de controlo de acesso suficientes.
  • Para cargas de trabalho em contentores, pode confiar nas imagens de contentor que são implementadas na produção.

Para saber mais sobre os desafios, veja CI/CD para arquiteturas de microsserviços.

Para obter recomendações e melhores práticas específicas, veja 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 secção Custo no Microsoft Azure Well-Architected Framework.

Seguem-se alguns pontos a considerar para alguns dos serviços utilizados nesta arquitetura.

Azure Kubernetes Service (AKS)

Não existem custos associados ao AKS na implementação, gestão e operações do cluster do Kubernetes. Só paga pelas instâncias de máquina virtual, armazenamento e recursos de rede consumidos pelo seu cluster do Kubernetes.

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

Balanceador de carga do Azure

Só lhe é cobrado o número de regras de balanceamento de carga e saída configuradas. As regras NAT de entrada são gratuitas. A Balanceador de Carga Standard não tem custos por hora quando não existem regras configuradas.

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

Pipelines do Azure

Esta arquitetura de referência utiliza apenas os Pipelines do Azure. O Azure oferece o Pipeline do Azure como um Serviço individual. É-lhe permitido um trabalho gratuito alojado na Microsoft com 1800 minutos por mês para CI/CD e um trabalho autoalojado com minutos ilimitados por mês. As tarefas adicionais têm custos. Para obter mais informações, veja Preços dos Serviços do Azure DevOps.

Azure Monitor

Para o Log Analytics do Azure Monitor, é-lhe cobrada a ingestão e a retenção de dados. Para obter mais informações, veja Preços do Azure Monitor.

Implementar este cenário

Para implementar a implementação de referência para esta arquitetura, siga os passos no repositório do GitHub.

Implementação de Referência de Microsserviços do AKS

Passos seguintes