Compartilhar via


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

Azure Arc
AKS (Serviço de Kubernetes do Azure)
Azure Monitor
Azure Policy
Controle de acesso baseado em função do Azure

Essa arquitetura de referência descreve como o Azure Arc estende o gerenciamento e a configuração de cluster do Kubernetes entre datacenters do cliente, locais de borda e vários ambientes de nuvem.

Arquitetura

Diagrama que mostra uma topologia do Azure Arc para Kubernetes.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

O fluxo de dados a seguir corresponde ao diagrama anterior:

  • Kubernetes habilitado para Azure Arc: Anexe e configure clusters do Kubernetes dentro ou fora do Azure usando o Kubernetes habilitado para Azure Arc. Quando um cluster do Kubernetes é anexado ao Azure Arc, ele recebe uma ID do Azure Resource Manager e uma identidade gerenciada.

  • AKS (Serviço de Kubernetes do Azure): Hospede clusters do Kubernetes no Azure para reduzir a complexidade e a sobrecarga operacional do gerenciamento de cluster do Kubernetes.

  • Cluster do Kubernetes local: Anexe clusters kubernetes certificados pelo CNCF (Cloud Native Computing Foundation) hospedados em ambientes de nuvem locais ou não da Microsoft.

  • Azure Policy: Implantar e gerenciar políticas para clusters do Kubernetes habilitados para Azure Arc.

  • Azure Monitor: Observe e monitore os clusters do Kubernetes habilitados para Azure Arc.

Componentes

  • O Azure Arc estende a plataforma do Azure, o que possibilita a criação de aplicativos e serviços que podem ser executados entre datacenters, na borda e em ambientes multinuvem.

  • O AKS é um serviço gerenciado para implantar e dimensionar clusters do 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 e clusters hospedados pelo AKS.

Possíveis casos de uso

Alguns usos típicos dessa arquitetura:

  • Gerenciamento de inventário, agrupamento e marcação para clusters kubernetes locais e clusters hospedados pelo AKS.

  • Usando o Azure Monitor para monitorar clusters Kubernetes em ambientes híbridos.

  • Usar o Azure Policy para ajudar a implantar e impor políticas para clusters kubernetes em ambientes híbridos.

  • Usando o Azure Policy para ajudar a implantar e impor o GitOps.

  • Maximizando o investimento da GPU (unidade de processamento de elementos gráficos) local, treinando e implantando fluxos de trabalho do Azure Machine Learning.

  • Usando o serviço gerenciado do Azure Monitor para Prometheus e Grafana Gerenciado para monitorar e visualizar cargas de trabalho do Kubernetes.

Recomendações

Você pode aplicar as recomendações a seguir à maioria dos cenários. Siga estas recomendações, a menos que você tenha um requisito específico que as substitua.

Registro de cluster

Você pode registrar qualquer cluster Kubernetes CNCF ativo. Você precisa de um kubeconfig arquivo para acessar o cluster e uma função de administrador de cluster no cluster para implantar agentes do Kubernetes habilitados para Azure Arc. Use a CLI do Azure para executar tarefas de registro de cluster. O usuário ou a entidade de serviço que você usa para os az login comandos e az connectedk8s connect exige permissões de leitura e gravação no Microsoft.Kubernetes/connectedClusters tipo de recurso. 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 connectedk8s extensão. A CLI do Azure versão 2.3 ou posterior é necessária para instalar as extensões da CLI do Kubernetes habilitada para Azure Arc.

Agentes do Azure Arc para Kubernetes

O Kubernetes habilitado para Azure Arc consiste em alguns agentes (ou operadores) executados no cluster implantado no azure-arc namespace:

  • O deployment.apps/config-agent observa o cluster conectado para recursos de configuração de controle do código-fonte 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 componentes do Azure Arc.

  • A deployment.apps/metrics-agent coleta de métricas de outros agentes do Azure Arc para garantir que esses agentes sejam executados de forma ideal.

  • Os deployment.apps/cluster-metadata-operator metadados do cluster coletam, incluindo a versão do cluster, a contagem de nós e a versão do agente do Azure Arc.

  • A deployment.apps/resource-sync-agent sincronização dos metadados de cluster mencionados anteriormente para o Azure.

  • O deployment.apps/clusteridentityoperator mantém o certificado de Identidade de Serviço Gerenciado usado por outros agentes para se comunicar com o Azure.

  • Coleta deployment.apps/flux-logs-agent logs dos operadores de fluxo implantados como parte da configuração de controle do código-fonte.

  • O deployment.apps/extension-manager helm instala e gerencia o ciclo de vida dos gráficos do Helm de extensão.

  • A deployment.apps/kube-aad-proxy autenticação manipula as solicitações enviadas ao cluster por meio do recurso de conexão de cluster do AKS.

  • É deployment.apps/clusterconnect-agent um agente proxy reverso que permite que o recurso de conexão de cluster forneça acesso ao servidor de API 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 de webhook de autenticação e autorização usado para o RBAC (controle de acesso baseado em função) do Microsoft Entra. É um componente opcional implantado somente se o RBAC do Azure estiver habilitado no cluster.

  • Os deployment.apps/extension-events-collector logs de coleta relacionados ao gerenciamento do ciclo de vida de extensões. Ele agrega esses logs em eventos que correspondem a cada operação, como Criar, Atualizar e Excluir.  

  • A deployment.apps/logcollector telemetria da plataforma coleta para ajudar a garantir a integridade operacional da plataforma.

Para obter mais informações, consulte Conectar um cluster kubernetes existente ao Azure Arc.

Monitorar clusters usando insights de contêiner do Azure Monitor

Monitorar seus contêineres é crucial. Os insights de contêiner do Azure Monitor fornecem recursos de monitoramento robustos para clusters de mecanismos AKS e AKS. Você também pode configurar insights de contêiner do Azure Monitor para monitorar clusters kubernetes habilitados para Azure Arc hospedados fora do Azure. Essa configuração fornece monitoramento abrangente dos clusters do Kubernetes no Azure, no local e em ambientes de nuvem que não são da Microsoft.

Os insights de contêiner do Azure Monitor fornecem visibilidade de desempenho coletando métricas de memória e processador de controladores, nós e contêineres. Essas métricas estão disponíveis no Kubernetes por meio da API de Métricas. Os logs do contêiner também são coletados. Depois de habilitar o monitoramento de clusters do Kubernetes, uma versão em contêineres do agente do Log Analytics coleta automaticamente métricas e logs. 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, consulte os recursos do Azure Monitor para monitoramento do Kubernetes.

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 obter mais informações, confira Habilitar o monitoramento para clusters do Kubernetes.

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

Use o Azure Policy para garantir que cada recurso ou Microsoft.ContainerService/managedClusters recurso habilitado Microsoft.Kubernetes/connectedclusters para GitOps tenha um recurso específico Microsoft.KubernetesConfiguration/fluxConfigurations 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, escolha uma definição nas definições internas do Azure Policy 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. Defina também os parâmetros para o fluxConfiguration que é criado. Quando a atribuição é criada, o mecanismo do Azure Policy identifica todos connectedCluster ou managedCluster recursos que estão no escopo e aplica-o fluxConfiguration a cada recurso.

Se você usar vários repositórios de origem para cada cluster, como um repositório para o operador central de TI ou cluster e outros repositórios para equipes de aplicativos, ative esse recurso 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 do Azure Policy.

Implantar aplicativos usando o GitOps

O GitOps é a prática de definir o estado desejado das configurações do Kubernetes, como implantações e namespaces, em um repositório de origem. Esse repositório pode ser um repositório Git ou Helm, Buckets ou Armazenamento de Blobs do Azure. Esse processo é seguido por uma sondagem e implantação baseada em 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 microsoft.flux extensão em seu cluster. As fluxConfiguration propriedades do recurso representam onde e como os recursos do Kubernetes devem fluir do repositório de origem para o cluster. Os fluxConfiguration dados são armazenados criptografados em repouso em um banco de dados do Azure Cosmos DB para ajudar a garantir a confidencialidade dos dados.

O flux-config agente executado em seu cluster monitora recursos de extensão novos ou atualizados fluxConfiguration no recurso kubernetes habilitado para Azure Arc, implanta aplicativos do repositório de origem e propaga todas as atualizações feitas no fluxConfiguration. Você pode criar vários fluxConfiguration recursos usando o namespace escopo no mesmo cluster kubernetes habilitado para Azure Arc para obter vários locatários.

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 do 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 do RBAC, 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, aplicar essa configuração 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 o GitOps com o Flux v2.

Executar Machine Learning

No Machine Learning, você pode escolher um cluster aks (ou Kubernetes habilitado para Azure Arc) como um destino de computação para seus processos de aprendizado de máquina. Essa funcionalidade permite que você treine ou implante modelos de machine learning em sua própria infraestrutura auto-hospedada (ou multinuvem). Essa abordagem permite combinar seus investimentos locais em GPUs com a facilidade de gerenciamento que o Machine Learning fornece na nuvem.

Monitorar cargas de trabalho do Kubernetes com Prometheus e Grafana gerenciados

O Azure Monitor fornece um serviço gerenciado para implantações do Prometheus e do Grafana, para que você possa aproveitar essas ferramentas de monitoramento populares do Kubernetes. Esse serviço gerenciado permite que você use essas ferramentas sem a necessidade de gerenciar e atualizar as implantações por conta própria. Para analisar as métricas do Prometheus, use o gerenciador de métricas com o PromQL.

Topologia, rede e roteamento

Os agentes do Azure Arc exigem os seguintes protocolos, portas e URLs de saída para funcionar.

Ponto de extremidade (DNS) Descrição
https://management.azure.com:443 Necessário para que o agente se conecte ao Azure e registre o cluster.
https://[region].dp.kubernetesconfiguration.azure.com:443 Ponto de extremidade do plano de dados para o agente enviar por push informações de status e configuração, onde [region] representa a região do Azure que hospeda a instância AKS.
https://docker.io:443 Necessário para efetuar pull de imagens de contêiner.
https://github.com:443, git://github.com:9418 Os exemplos de repositórios GitOps estão hospedados no GitHub. O agente de configuração requer conectividade com o ponto de extremidade git que você especificar.
https://login.microsoftonline.com:443, , https://<region>.login.microsoft.comlogin.windows.net Necessário para buscar e atualizar tokens do Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com:443 Necessário para efetuar pull de imagens de contêiner para agentes do Azure Arc.

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​, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design parade confiabilidade.

  • Na maioria dos cenários, o local escolhido ao criar o script de instalação deve ser a região do Azure que está geograficamente mais próxima dos recursos locais. O restante dos dados é armazenado na geografia do Azure que contém a região especificada. Esse detalhe poderá 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. Se você tiver vários locais que fornecem um serviço com redundância geográfica, conecte os computadores em cada local a uma região diferente do Azure. Essa prática melhora a resiliência se ocorrer uma interrupção regional. Para obter mais informações, consulte regiões compatíveis com o Kubernetes habilitado para Azure Arc.

  • Você deve garantir que os serviços em sua solução têm suporte na região em que o Azure Arc é implantado.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade 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 integração contínua e entrega contínua, como o Azure Pipelines e o 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. Os clusters existentes, que incluem o Azure e clusters locais, não podem ser migrados para identidades gerenciadas. Para obter mais informações, confira Usar uma identidade gerenciada no AKS.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design parade Otimização de Custos.

Para considerações gerais sobre o custo, consulte os princípios de design da Otimização de Custos.

Excelência Operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design parade Excelência Operacional.

  • Antes de configurar os clusters do Kubernetes habilitados para Azure Arc, examine os limites de assinatura e os limites de grupo de recursos do Azure Resource Manager para planejar o número de clusters.

  • Use o Helm, que é uma ferramenta de empacotamento de software livre, para instalar e gerenciar os ciclos de vida do aplicativo Kubernetes. Semelhante aos gerenciadores de pacotes do Linux, como APT e Yum, use o Helm para gerenciar gráficos do Kubernetes, que são pacotes de recursos do Kubernetes pré-configurados.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

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

Próximas etapas

Orientações híbridas relacionadas:

Arquiteturas relacionadas