Partilhar via


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

Azure Arc
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Policy
Controlo de acesso baseado em funções do Azure

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

Arquitetura

Diagrama que mostra uma topologia do Azure Arc for Kubernetes.

Transfira um ficheiro do Visio desta arquitetura.

Workflow

O fluxo de trabalho a seguir corresponde ao diagrama anterior:

  • 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 (AKS): 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 não Microsoft.

  • Política do Azure: Implante e gerencie políticas para clusters Kubernetes habilitados para Azure Arc.

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

Componentes

  • O Azure Arc estende a plataforma Azure, o que torna possível criar aplicativos e serviços que podem ser executados em datacenters, na borda e em ambientes multicloud.

  • O 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 e clusters hospedados pelo AKS.

Potenciais casos de utilização

Utilizações típicas desta 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.

  • Usando a Política do Azure para ajudar a implantar e aplicar políticas para clusters Kubernetes em ambientes híbridos.

  • Usando a Política do Azure para ajudar a implantar e aplicar o GitOps.

  • Maximizando seu investimento em GPU (unidade de processamento gráfico) local treinando e implantando fluxos de trabalho do Azure Machine Learning.

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

Recomendações

Você pode aplicar as seguintes recomendações à maioria dos cenários. Siga-as, a não ser que tenha requisitos específicos que as anulem.

Registo 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 Kubernetes habilitados para Azure Arc. Use a CLI do Azure para executar tarefas de registro de cluster. O usuário ou entidade de serviço que você usa para os az login comandos e az connectedk8s connect requer permissões de Microsoft.Kubernetes/connectedClusters Leitura e Gravação no 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 leme 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 habilitadas para Azure Arc.

Agentes do Azure Arc para Kubernetes

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

  • O deployment.apps/config-agent monitora o cluster conectado em busca de recursos de configuração de controle do código-fonte que são aplicados no cluster e atualiza o estado de conformidade.

  • O deployment.apps/controller-manager é um operador de operadores que orquestra interações entre componentes do Azure Arc.

  • O deployment.apps/metrics-agent coleta métricas de outros agentes do Azure Arc para garantir que esses agentes tenham um desempenho ideal.

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

  • O deployment.apps/resource-sync-agent sincroniza os metadados de cluster mencionados anteriormente com o Azure.

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

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

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

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

  • O deployment.apps/clusterconnect-agent é um agente de 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.

  • O 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 RBAC do Azure estiver habilitado no cluster.

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

  • O deployment.apps/logcollector coleta a telemetria da plataforma 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 o Azure Monitor informações de contêiner

A monitorização dos seus contentores é crucial. As informações de contêiner do Azure Monitor fornecem recursos de monitoramento robustos para clusters de mecanismo AKS e AKS. Você também pode configurar as informações de contêiner do Azure Monitor para monitorar clusters Kubernetes habilitados para Azure Arc hospedados fora do Azure. Essa configuração fornece monitoramento abrangente de seus clusters Kubernetes no Azure, no local e em ambientes de nuvem que não sejam da Microsoft.

As informações 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 registos do contentor também são recolhidos. Depois de habilitar o monitoramento de clusters Kubernetes, uma versão em contêiner do agente do Log Analytics coleta automaticamente métricas e logs. 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, consulte Recursos do Azure Monitor para monitoramento do Kubernetes.

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

Para mais informações, consulte Ativar monitorização para clusters Kubernetes.

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

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

Se você usar vários repositórios de origem para cada cluster, como um repositório para a TI central ou operador de 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 as configurações do Flux v2 e a Política do Azure.

Implantar aplicativos usando GitOps

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 Blob do Azure. Esse processo é 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 microsoft.flux extensão no 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 ArcGIS do Azure, 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 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 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, aplicar essa configuração 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.

Executar o 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. Esse recurso permite que você treine ou implante modelos de aprendizado de máquina em sua própria infraestrutura auto-hospedada (ou multicloud). Essa abordagem permite que você combine seus investimentos locais em GPUs com a facilidade de gerenciamento que o Machine Learning oferece na nuvem.

Monitore 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 populares de monitoramento 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 explorador 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 final (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 o status e buscar informações de configuração, onde [region] representa a região do Azure que hospeda a instância AKS.
https://docker.io:443 Necessário para extrair imagens de contêiner.
https://github.com:443, git://github.com:9418 Exemplos de repositórios GitOps sã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.com, login.windows.net É necessário obter e atualizar os tokens do Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com:443 Necessário para extrair 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, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

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

  • Na maioria dos cenários, o local escolhido 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 especificada. Esse detalhe 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. Se você tiver vários locais que fornecem um serviço geograficamente redundante, conecte as máquinas 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 com suporte para Kubernetes habilitado para Azure Arc.

  • Você deve garantir que os serviços em sua solução tenham suporte na região onde o Azure Arc está 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 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 integração contínua e entrega contínua, como Pipelines do Azure e Ações do GitHub. 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 clusters do Azure e locais, não podem ser migrados para identidades gerenciadas. Para obter mais informações, consulte Usar uma identidade gerenciada no AKS.

Otimização de Custos

A Otimização de Custos concentra-se em formas 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 projeto para Otimização de custos.

Para obter considerações gerais sobre custos, consulte Princípios de projeto de otimização de custos.

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 Lista de verificação de revisão de projeto para o Operational Excellence.

  • 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, que é uma 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, use o Helm para gerenciar gráficos do Kubernetes, que são pacotes de recursos do Kubernetes pré-configurados.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

Orientações híbridas relacionadas:

Arquiteturas relacionadas: