Gerenciamento híbrido do Azure Arc e implantação para clusters do Kubernetes

Esta arquitetura de referência demonstra como o Azure Arc estende o gerenciamento e a configuração de clusters Kubernetes em data centers de clientes, locais de borda e vários ambientes de nuvem.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

A arquitetura consiste nos seguintes componentes:

• Kubernetes habilitado para Azure Arc. Anexe e configure clusters do Kubernetes dentro ou fora do Azure usando a versão Kubernetes habilitado para o Azure Arc. Quando um cluster do Kubernetes é anexado ao Azure Arc, ele recebe uma ID do Azure Resource Manager e uma identidade gerenciada.
• Serviço de Kubernetes do Azure. Hospede clusters do Kubernetes no Azure para reduzir a complexidade e a sobrecarga operacional do gerenciamento de clusters do Kubernetes.
• Cluster Kubernetes local. Anexe clusters Kubernetes certificados pelo CNCF (Cloud Native Computing Foundation) hospedados em ambientes de nuvem locais ou de terceiros.
• Azure Policy. Implante e gerencie políticas para clusters Kubernetes habilitados para Arc.
• Azure Monitor. Observe e monitore clusters Kubernetes habilitados para Arc.

Componentes

• Azure Arc é uma ponte que amplia a plataforma do Azure, possibilitando a criação de aplicativos e serviços que podem ser executados em ambientes de datacenters, borda e multinuvem.
• O AKs (Serviço de Kubernetes do Azure) é um serviço gerenciado para implantação e dimensionamento de clusters Kubernetes.
• Azure Policy possibilita obter a conformidade da nuvem em tempo real e em escala com governança de recursos consistente.
• Azure Monitor fornece observabilidade ponta a ponta para aplicativos, infraestrutura e rede.

Detalhes do cenário

Você pode usar o Azure Arc para registrar clusters do Kubernetes hospedados fora do Microsoft Azure. Em seguida, você pode usar as ferramentas do Azure para gerenciar esses clusters junto com clusters hospedados no AKS (Serviço de Kubernetes do Azure).

Possíveis casos de uso

Alguns usos típicos dessa arquitetura:

• Gerenciamento de clusters Kubernetes locais e clusters hospedados no AKS para inventário, agrupamento e marcação.
• Usando o Azure Monitor para monitorar clusters Kubernetes em ambientes híbridos.
• Usando o Azure Policy para implantar e aplicar políticas para clusters Kubernetes em ambientes híbridos.
• Usando o Azure Policy para implantar e impor o GitOps.

Recomendações

As seções a seguir oferecem recomendações que se aplicam à maioria dos cenários. A Microsoft recomenda que você os siga, a menos que haja um requisito que os substitua.

Registro de cluster

Você pode registrar qualquer cluster Kubernetes CNCF ativo. Você precisará de um arquivo kubeconfig para acessar o cluster e uma função de administrador de cluster no cluster para implantar agentes do Kubernetes habilitados para Arc. Você usará a CLI do Azure (Interface de Linha de Comando do Azure) para executar as tarefas de registro de cluster. O usuário ou entidade de serviço que você usa para os comandos az login e az connectedk8s connect requer permissões de leitura e gravação no tipo de recurso Microsoft.Kubernetes/connectedClusters. A função Kubernetes Cluster - Azure Arc Onboarding tem essas permissões e pode ser usada para atribuições de função na entidade de usuário ou na entidade de serviço. O Helm 3 é necessário para integrar o cluster que usa a extensão connectedk8s. A CLI do Azure versão 2.3 ou posterior é necessária para instalar as extensões de interface de linha de comando do Kubernetes habilitadas para o Azure Arc.

Agentes do Azure Arc para Kubernetes

O Kubernetes habilitado para Azure Arc consiste em alguns agentes (também chamados de operadores) que são executados no cluster implantado no namespace azure-arc:

• deployment.apps/config-agent. Observa o cluster conectado para os recursos de configuração de controle do código de origem que são aplicados no cluster e atualiza o estado de conformidade.
• deployment.apps/controller-manager. Um operador de operadores que orquestra interações entre os componentes do Azure Arc.
• deployment.apps/metrics-agent. Coleta métricas de outros agentes do Arc para garantir que eles estejam apresentando um desempenho ideal.
• deployment.apps/cluster-metadata-operator. Coleta metadados do cluster, versão do cluster, contagem de nós e versão do agente do Azure Arc.
• deployment.apps/resource-sync-agent. Sincroniza os metadados de cluster mencionados anteriormente para o Azure.
• deployment.apps/clusteridentityoperator. Mantém o certificado MSI (Identidade de Serviço Gerenciado) que é usado por outros agentes para comunicação com o Azure.
• deployment.apps/flux-logs-agent. Coleta logs dos operadores de fluxo que são implantados como parte da configuração de controle do código-fonte.
• deployment.apps/extension-manager. Instala e gerencia o ciclo de vida de gráficos de extensão Helm.
• deployment.apps/kube-azure-ad-proxy. Usado para a autenticação das solicitações enviadas ao cluster usando a Conexão de Cluster.
• deployment.apps/clusterconnect-agent. Um agente de proxy reverso que habilita o recurso de conexão de cluster para fornecer acesso ao apiserver do cluster. É um componente opcional que é implantado somente se o recurso de conexão de cluster estiver habilitado no cluster.
• deployment.apps/guard. Um servidor webhook de autenticação e autorização usado para o RBAC (controle de acesso baseado em função) do Microsoft Entra. É um componente opcional que é implantado somente se o recurso azure-rbac estiver habilitado no cluster.

Para obter mais informações, consulte Conectar um cluster Kubernetes habilitado para o Azure Arc.

Monitorar clusters usando insights de Contêiner do Azure Monitor

Monitorar os contêineres é crítico. Os insights de Contêiner do Azure Monitor oferece uma experiência de monitoramento avançada para o AKS e os clusters de mecanismo do AKS. Também pode configurar insights de Contêiner do Azure Monitor para monitorar clusters do Kubernetes habilitados para Azure Arc que estão hospedados fora do Azure. Isso fornece monitoramento abrangente dos clusters do Kubernetes em ambientes de nuvem de terceiros, locais e do Azure.

Os insights de Contêiner do Azure Monitor podem fornecer visibilidade de desempenho coletando métricas de memória e processador de controladores, nós e contêineres, métricas que estão disponíveis no Kubernetes por meio da API (interface de programação de aplicativos) de métricas. Os logs do contêiner também são coletados. Após habilitar o monitoramento com base em clusters do Kubernetes, as métricas e os logs serão coletados automaticamente para você por uma versão em contêiner do agente do Log Analytics. As métricas são escritas no armazenamento de métricas e os dados de log são gravados no armazenamento de logs associado ao seu workspace do Log Analytics. Para obter mais informações sobre os insights de Contêiner do Azure Monitor, consulte Visão geral dos insights de Contêiner do Azure Monitor.

Você pode habilitar os insights de Contêiner do Azure Monitor para uma ou mais implantações do Kubernetes usando um script do PowerShell ou um script Bash.

Para habilitar o monitoramento de clusters do Kubernetes habilitados para Arc, consulte Habilitar o monitoramento do cluster do Kubernetes habilitado para Azure Arc.

Usar o Azure Policy para habilitar a implantação de aplicativos baseados em GitOps

Use o Azure Policy para impor que cada recurso Microsoft.Kubernetes/connectedclusters habilitado para GitOps ou recurso Microsoft.ContainerService/administradoClusters tenha Microsoft.KubernetesConfiguration/fluxConfigurations específico aplicado a ele. Por exemplo, você pode aplicar uma configuração de linha de base a um ou mais clusters ou implantar aplicativos específicos em vários clusters. Para usar o Azure Policy, selecione uma definição nas definições internas do Azure Policy para o Kubernetes habilitado para o Azure Arc e crie uma atribuição de política.

Ao criar a atribuição de política, defina o escopo como um grupo de recursos ou assinatura do Azure. Defina também os parâmetros para o fluxConfiguration que é criado. Quando a atribuição for criada, o mecanismo de política identificará todos os recursos connectedCluster ou managedCluster localizados no escopo e, em seguida, aplicará o fluxConfiguration a cada um.

Se você estiver usando vários repositórios de origem para cada cluster (por exemplo, um repositório para o operador central de TI/cluster e outros repositórios para equipes de aplicativos), habilite isso usando várias atribuições de política e configure cada atribuição de política para usar um repositório de origem diferente.

Para obter mais informações, consulte Implantar aplicativos consistentemente em escala usando configurações do Flux v2 e Azure Policy.

Implantar aplicativos usando o GitOps

GitOps é a prática de declarar o estado desejado da configuração do Kubernetes (implantações, namespaces e assim por diante) em um repositório de origem, como um repositório Git ou Helm, Buckets ou Armazenamento de Blobs do Azure. Isso é seguido por uma implantação baseada em sondagem e pull dessas configurações no cluster usando um operador.

A conexão entre o cluster e um ou mais repositórios de origem é habilitada implantando a extensão microsoft.flux no cluster. As propriedades de recurso fluxConfiguration representam onde e como os recursos do Kubernetes devem fluir do repositório de origem para o cluster. Os dados do fluxConfiguration são armazenados criptografados e inativos em um banco de dados Azure Cosmos DB para garantir a confidencialidade dos dados.

O agente flux-config executado no seu cluster é responsável por observar recursos de extensão fluxConfiguration novos ou atualizados no recurso Kubernetes habilitado para Azure Arc, por implantar aplicativos do repositório de origem e por propagar quaisquer atualizações feitas no fluxConfiguration. Você pode até criar vários recursos fluxConfiguration usando o escopo de namespace no mesmo cluster Kubernetes habilitado para Azure Arc para obter multilocação.

O repositório de origem pode conter quaisquer recursos válidos do Kubernetes, incluindo Namespaces, ConfigMaps, Implantações e DaemonSets. Ele também pode conter gráficos Helm para implantar aplicativos. Os cenários comuns de repositório de origem incluem a definição de uma configuração de linha de base para sua organização que pode incluir funções e associações comuns de RBAC (controle de acesso baseado em função), agentes de monitoramento, agentes de log e serviços em todo o cluster.

Você também pode gerenciar uma coleção maior de clusters que são implantados em ambientes heterogêneos. Por exemplo, você pode ter um repositório que defina a configuração de linha de base para sua organização e, em seguida, aplicá-lo a vários clusters do Kubernetes simultaneamente. Você também pode implantar aplicativos em um cluster a partir de vários repositórios de origem.

Para obter mais informações, consulte Implantar aplicativos usando GitOps com o Flux v2.

Topologia, rede e roteamento

Os agentes do Azure Arc exigem os seguintes protocolos/portas/URLs de saída para funcionar:

Para obter uma lista completa de URLs nos serviços do Azure Arc, consulte Requisitos de rede do Azure Arc.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

• Na maioria dos casos, o local selecionado ao criar o script de instalação deve ser a região do Azure geograficamente mais próxima de seus recursos locais. Os dados restantes são armazenados na geografia do Azure que contém a região especificada, um fato que pode afetar sua escolha de região se você tiver requisitos de residência de dados. Se uma interrupção afetar a região do Azure à qual seus computador está conectado, a interrupção não afetará a máquina conectada, mas as operações de gerenciamento que usam o Azure podem não ser concluídas. Para resiliência quando há uma interrupção regional, se você tiver vários locais que fornecem um serviço geograficamente redundante, será melhor conectar os computadores em cada local a uma região diferente do Azure. Para regiões disponíveis, consulte Regiões com suporte para Kubernetes habilitado para Azure Arc.
• Você deve garantir que os serviços que são referenciados na seção Arquitetura têm suporte na região onde o Azure Arc é implantado.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

• Você pode usar o RBAC do Azure para gerenciar o acesso ao Kubernetes habilitado para Azure Arc em ambientes locais e do Azure usando identidades do Microsoft Entra. Para saber mais, consulte Usar o RBAC do Azure para autorização do Kubernetes.
• A Microsoft recomenda que você use uma entidade de serviço que tenha privilégios limitados para integrar clusters do Kubernetes ao Azure Arc. Essa prática é útil em pipelines de CI/CD, como Azure Pipelines e GitHub Actions. Para obter mais informações, confira Criar uma entidade de serviço de integração habilitada para Azure Arc.
• Para simplificar o gerenciamento da entidade de serviço, você pode usar identidades gerenciadas no AKS. No entanto, os clusters devem ser criados usando a identidade gerenciada e os clusters existentes (incluindo clusters do Azure e locais) não podem ser migrados para identidades gerenciadas. Para obter mais informações, confira Usar identidades gerenciadas no Serviço de Kubernetes do Azure.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Considerações gerais de custo são descritas na seção Princípios de otimização de custos no Microsoft Azure Well-Architected Framework.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

• Antes de configurar seus clusters do Kubernetes habilitados para o Azure Arc, examine os Limites de assinatura do Azure Resource Manager e os Limites do grupo de recursos para planejar o número de clusters.
• Use o Helm, a ferramenta de empacotamento de código aberto, para instalar e gerenciar os ciclos de vida do aplicativo de Kubernetes. Semelhante aos gerenciadores de pacotes Linux, como APT e Yum, você usa o Helm para gerenciar gráficos do Kubernetes, que são pacotes de recursos pré-configurados do Kubernetes.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Pieter de Bruin | Gerente de Programas Sênior

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

Próximas etapas

• Documentação do Azure Arc
• Documentação do Kubernetes habilitado para Azure Arc
• Documentação do Serviço de Kubernetes do Azure
• Documentação do Azure Policy
• Documentação do Azure Monitor
• Conectar um cluster do Kubernetes habilitado para Azure Arc

Recursos relacionados

Orientações híbridas relacionadas:

• Projeto de arquitetura híbrida
• Opções híbridas do Azure
• Considerações de design de aplicativo híbrido
• Implantar um aplicativo híbrido com dados locais que escalam entre nuvens

Arquiteturas relacionadas

• Arquitetura de linha de base para o Serviço de Kubernetes do Azure no Azure Stack HCI
• Arquitetura de rede para o Serviço de Kubernetes do Azure no Azure Stack HCI
• Otimizar a administração de instâncias do SQL Server em ambientes locais e multinuvem usando o Azure Arc
• Monitoramento empresarial com o Azure Monitor