Gestão e implementação híbridas do Azure Arc para clusters Kubernetes

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

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

A arquitetura consiste nos seguintes aspetos:

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

Componentes

• O Azure Arc é uma ponte que estende a plataforma Azure, tornando possível criar aplicativos e serviços que podem ser executados em datacenters, na borda e em ambientes multicloud.
• O Serviço Kubernetes do Azure (AKS) é um serviço gerenciado para implantar e dimensionar clusters Kubernetes.
• A Política do Azure torna possível alcançar a conformidade da nuvem em tempo real em escala com governança de recursos consistente.
• O Azure Monitor fornece observabilidade de ponta a ponta para seus aplicativos, infraestrutura e rede.

Detalhes do cenário

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

Potenciais casos de utilização

Utilizações típicas desta 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 a Política do Azure para implantar e aplicar políticas para clusters Kubernetes em ambientes híbridos.
• Usando a Política do Azure 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 tenha um requisito que os substitua.

Registo de cluster

Você pode registrar qualquer cluster Kubernetes CNCF ativo. Você precisa de um arquivo kubeconfig para acessar o cluster e uma função de administrador de cluster no cluster para implantar agentes Kubernetes habilitados para Arc. Você usa a interface de linha de comando (CLI) do Azure para executar tarefas de registro de cluster. A entidade de usuário ou 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 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 em busca de recursos de configuração de controle do código-fonte aplicados no cluster e atualiza o estado de conformidade.
• deployment.apps/controller-manager. Um operador de operadores que orquestra interações entre componentes do Azure Arc.
• deployment.apps/metrics-agent. Coleta métricas de outros agentes Arc para garantir que esses agentes estejam exibindo um desempenho ideal.
• deployment.apps/cluster-metadata-operator. Reúne metadados de cluster, versão de 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 com o Azure.
• Deployment.apps/ClusterIdentityOperator. Mantém o certificado MSI (Managed Service Identity) usado por outros agentes para se comunicar 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 dos gráficos Helm de extensão.
• deployment.apps/kube-azure-ad-proxy. Usado para a autenticação das solicitações enviadas ao cluster usando o Cluster Connect.
• deployment.apps/clusterconnect-agent. Um agente de proxy reverso que permite que o recurso de conexão de cluster forneça 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 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 Azure Arc.

Monitorar clusters usando o Azure Monitor Container insights

Monitorar seus contêineres é fundamental. As informações do Contêiner do Azure Monitor fornecem uma experiência de monitoramento avançada para os clusters de mecanismo AKS e AKS. Você também pode configurar o Azure Monitor Container insights para monitorar clusters Kubernetes habilitados para Azure Arc hospedados fora do Azure. Isso fornece monitoramento abrangente de seus clusters Kubernetes em ambientes de nuvem do Azure, locais e de terceiros.

As informações do 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 interface de programação de aplicativo (API) do Metrics. Os registos do contentor também são recolhidos. Depois de habilitar o monitoramento de clusters Kubernetes, as métricas e os logs são coletados automaticamente por uma versão em contêiner do agente do Log Analytics. As métricas são gravadas no repositório de métricas e os dados de log são gravados no repositório de logs associado ao seu espaço de trabalho do Log Analytics. Para obter mais informações sobre os insights do Contêiner do Azure Monitor, consulte Visão geral dos insights do Contêiner do Azure Monitor.

Você pode habilitar as informações do 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 Kubernetes habilitados para Arc, consulte Habilitar o monitoramento de cluster Kubernetes habilitado para ArcGIS do Azure

Usar a Política do Azure para habilitar a implantação de aplicativos baseados em GitOps

Use a Política do Azure para impor que cada recurso Microsoft.Kubernetes/connectedclusters habilitado para GitOps ou recurso Microsoft.ContainerService/managedClusters tenha Microsoft.KubernetesConfiguration/fluxConfigurations específicos aplicados nele. 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 a Política do Azure, selecione uma definição nas definições internas da Política do Azure para o Kubernetes habilitado para 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. Também defina os parâmetros para o fluxConfiguration que é criado. Quando a atribuição é 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), ative 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 as configurações do Flux v2 e a Política do Azure.

Implantar aplicativos usando 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 Blob 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 do recurso fluxConfiguration representam onde e como os recursos do Kubernetes devem fluir do repositório de origem para o cluster. Os dados fluxConfiguration são armazenados criptografados em repouso em um banco de dados do Azure Cosmos DB para garantir a confidencialidade dos dados.

O agente flux-config executado em seu cluster é responsável por observar recursos de extensão fluxConfiguration novos ou atualizados no recurso Kubernetes habilitado para ArcGIS do Azure, implantar aplicativos do repositório de origem e propagar quaisquer atualizações feitas no fluxConfiguration. Você pode até mesmo criar vários recursos fluxConfiguration usando o escopo do 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, Deployments 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 RBAC (controle de acesso à base de função) comuns, 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 define a configuração de linha de base para sua organização e, em seguida, aplicá-la a vários clusters 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

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte 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. O restante dos dados é armazenado na geografia do Azure que contém a região que você especificar, 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 sua máquina está conectada, 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, é melhor, se você tiver vários locais que fornecem um serviço geograficamente redundante, conectar as máquinas 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 referenciados na seção Arquitetura tenham suporte na região onde o Azure Arc é implantado.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte 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 no Azure e em ambientes locais que usam identidades do Microsoft Entra. Para obter mais informações, 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 Kubernetes ao Azure Arc. Essa prática é útil em pipelines de CI/CD, como Azure Pipelines e GitHub Actions. Para obter mais informações, consulte 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, consulte Usar identidades gerenciadas no Serviço Kubernetes do Azure.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

As 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 operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.

• Antes de configurar seus clusters Kubernetes habilitados para Azure Arc, revise 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 Kubernetes. Semelhante aos gerenciadores de pacotes do Linux, como APT e Yum, você usa o Helm para gerenciar gráficos do Kubernetes, que são pacotes de recursos do Kubernetes pré-configurados.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Pieter de Bruin - Brasil | Gerente de Programa Sênior

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

Próximos passos

• Documentação do Azure Arc
• Documentação do Kubernetes habilitado para Azure Arc
• Documentação do Serviço 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:

• Design de arquitetura híbrida
• Opções híbridas do Azure
• Considerações de design de aplicativo híbrido

Arquiteturas relacionadas:

• Arquitetura de linha de base para AKS no Azure Stack HCI
• Arquitetura de rede para AKS no Azure Stack HCI
• Otimize a administração de instâncias do SQL Server em ambientes locais e multicloud usando o Azure Arc
• Monitorização empresarial com o Azure Monitor