Gerenciamento híbrido do Azure Arc e implantação para clusters do Kubernetes
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
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.com login.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:
- Pieter de Bruin | Gerente de Programas Sênior
Para ver perfis não públicos no LinkedIn, entre no LinkedIn.
Próximas etapas
- Documentação do Azure Arc
- Documentação do Kubernetes habilitado para Azure Arc
- Documentação do AKS
- Documentação do Azure Policy
- Documentação do Azure Monitor
- Conectar um cluster existente do Kubernetes ao Azure Arc
Recursos relacionados
Orientações híbridas relacionadas:
Arquiteturas relacionadas
- arquitetura de linha de base para AKS no Local do Azure
- Otimizar a administração de instâncias do SQL Server em ambientes locais e multinuvem usando o Azure Arc