Condividi tramite


Gestione e distribuzione ibride di Azure Arc per i cluster Kubernetes

Azure Arc
Servizio Azure Kubernetes (AKS)
Monitoraggio di Azure
Criteri di Azure
Controllo degli accessi in base al ruolo di Azure

Questa architettura di riferimento descrive in che modo Azure Arc estende la gestione e la configurazione dei cluster Kubernetes nei data center dei clienti, nelle posizioni perimetrali e in più ambienti cloud.

Architettura

Diagramma che mostra una topologia di Azure Arc per Kubernetes.

Scaricare un file di Visio di questa architettura.

Workflow

Il flusso di lavoro seguente corrisponde al diagramma precedente:

  • Kubernetes abilitato per Azure Arc: Collegare e configurare cluster Kubernetes all'interno o all'esterno di Azure usando Kubernetes abilitato per Azure Arc. Quando un cluster Kubernetes è collegato ad Azure Arc, viene assegnato un ID di Azure Resource Manager e un'identità gestita.

  • Servizio Azure Kubernetes: Ospitare cluster Kubernetes in Azure per ridurre la complessità e il sovraccarico operativo della gestione dei cluster Kubernetes.

  • Cluster Kubernetes locale: Collegare cluster Kubernetes certificati CLOUD Native Computing Foundation (CNF) ospitati in ambienti cloud locali o non Microsoft.

  • Criteri di Azure: Distribuire e gestire i criteri per i cluster Kubernetes abilitati per Azure Arc.

  • Monitoraggio di Azure: Osservare e monitorare i cluster Kubernetes abilitati per Azure Arc.

Componenti

  • Azure Arc estende la piattaforma Azure, che consente di creare applicazioni e servizi che possono essere eseguiti tra data center, perimetrali e ambienti multicloud.

  • Il servizio Azure Kubernetes è un servizio gestito per la distribuzione e il ridimensionamento dei cluster Kubernetes.

  • Criteri di Azure consente di ottenere la conformità del cloud in tempo reale su larga scala con una governance coerente delle risorse.

  • Monitoraggio di Azure offre un'osservabilità end-to-end per le applicazioni, l'infrastruttura e la rete.

Dettagli dello scenario

È possibile usare Azure Arc per registrare cluster Kubernetes ospitati all'esterno di Microsoft Azure. È quindi possibile usare gli strumenti di Azure per gestire questi cluster e cluster ospitati dal servizio Azure Kubernetes.

Potenziali casi d'uso

Tra gli usi tipici di questa architettura sono inclusi:

  • Gestione dell'inventario, del raggruppamento e dell'assegnazione di tag per cluster Kubernetes locali e cluster ospitati dal servizio Azure Kubernetes.

  • Uso di Monitoraggio di Azure per monitorare i cluster Kubernetes in ambienti ibridi.

  • Uso di Criteri di Azure per distribuire e applicare criteri per i cluster Kubernetes in ambienti ibridi.

  • Uso di Criteri di Azure per distribuire e applicare GitOps.

  • Ottimizzare l'investimento dell'unità di elaborazione grafica locale (GPU) eseguendo il training e la distribuzione di flussi di lavoro di Azure Machine Learning.

  • Uso del servizio gestito di Monitoraggio di Azure per Prometheus e Managed Grafana per monitorare e visualizzare i carichi di lavoro Kubernetes.

Consigli

È possibile applicare le raccomandazioni seguenti alla maggior parte degli scenari. Seguire queste indicazioni, a meno che non si disponga di un requisito specifico che le escluda.

Registrazione del cluster

È possibile registrare qualsiasi cluster KUBernetes KUBernetes attivo. È necessario un kubeconfig file per accedere al cluster e a un ruolo di amministratore del cluster nel cluster per distribuire gli agenti Kubernetes abilitati per Azure Arc. Usare l'interfaccia della riga di comando di Azure per eseguire attività di registrazione del cluster. L'utente o l'entità servizio usata per i az login comandi e az connectedk8s connect richiedono autorizzazioni lettura e scrittura per il Microsoft.Kubernetes/connectedClusters tipo di risorsa. Il ruolo Cluster Kubernetes - Onboarding di Azure Arc ha queste autorizzazioni e può essere usato per le assegnazioni di ruolo nell'entità utente o nell'entità servizio. Helm 3 è necessario per eseguire l'onboarding del cluster che usa l'estensione connectedk8s . L'interfaccia della riga di comando di Azure versione 2.3 o successiva è necessaria per installare le estensioni dell'interfaccia della riga di comando di Kubernetes abilitate per Azure Arc.

Agenti Azure Arc per Kubernetes

Kubernetes abilitato per Azure Arc è costituito da alcuni agenti (o operatori) eseguiti nel cluster distribuito nello spazio dei azure-arc nomi:

  • Controlla deployment.apps/config-agent il cluster connesso per le risorse di configurazione del controllo del codice sorgente applicate al cluster e aggiorna lo stato di conformità.

  • deployment.apps/controller-manager è un operatore di operatori che orchestra le interazioni tra i componenti di Azure Arc.

  • deployment.apps/metrics-agent Raccoglie le metriche da altri agenti di Azure Arc per garantire che questi agenti funzionino in modo ottimale.

  • deployment.apps/cluster-metadata-operator Raccoglie i metadati del cluster, tra cui la versione del cluster, il numero di nodi e la versione dell'agente Di Azure Arc.

  • deployment.apps/resource-sync-agent Sincronizza i metadati del cluster menzionati in precedenza in Azure.

  • mantiene deployment.apps/clusteridentityoperator il certificato di identità del servizio gestito usato da altri agenti per comunicare con Azure.

  • deployment.apps/flux-logs-agent Raccoglie i log dagli operatori flusso distribuiti come parte della configurazione del controllo del codice sorgente.

  • Installa deployment.apps/extension-manager e gestisce il ciclo di vita dei grafici Helm dell'estensione.

  • deployment.apps/kube-aad-proxy Gestisce l'autenticazione per le richieste inviate al cluster tramite la funzionalità di connessione del cluster del servizio Azure Kubernetes.

  • deployment.apps/clusterconnect-agent è un agente proxy inverso che consente alla funzionalità di connessione del cluster di fornire l'accesso al server API del cluster. Si tratta di un componente facoltativo distribuito solo se la funzionalità di connessione del cluster è abilitata nel cluster.

  • deployment.apps/guard è un server webhook di autenticazione e autorizzazione usato per il controllo degli accessi in base al ruolo di Microsoft Entra. Si tratta di un componente facoltativo distribuito solo se il controllo degli accessi in base al ruolo di Azure è abilitato nel cluster.

  • deployment.apps/extension-events-collector Raccoglie i log correlati alla gestione del ciclo di vita delle estensioni. Aggrega questi log in eventi che corrispondono a ogni operazione, ad esempio Create, Upgrade e Delete.  

  • deployment.apps/logcollector Raccoglie i dati di telemetria della piattaforma per garantire l'integrità operativa della piattaforma.

Per altre informazioni, vedere Connettere un cluster Kubernetes esistente ad Azure Arc.

Monitorare i cluster usando informazioni dettagliate sui contenitori di Monitoraggio di Azure

Il monitoraggio dei contenitori è fondamentale. Informazioni dettagliate sui contenitori di Monitoraggio di Azure offre funzionalità di monitoraggio affidabili per i cluster del motore del servizio Azure Kubernetes e del servizio Azure Kubernetes. È anche possibile configurare informazioni dettagliate sui contenitori di Monitoraggio di Azure per monitorare i cluster Kubernetes abilitati per Azure Arc ospitati all'esterno di Azure. Questa configurazione offre un monitoraggio completo dei cluster Kubernetes in Azure, in locale e in ambienti cloud non Microsoft.

Le informazioni dettagliate sui contenitori di Monitoraggio di Azure offrono visibilità sulle prestazioni raccogliendo metriche di memoria e processore da controller, nodi e contenitori. Queste metriche sono disponibili in Kubernetes tramite l'API Metriche. Vengono raccolti anche i log dei contenitori. Dopo aver abilitato il monitoraggio dai cluster Kubernetes, una versione in contenitori dell'agente di Log Analytics raccoglie automaticamente metriche e log. Le metriche vengono scritte nell'archivio delle metriche e i dati di log vengono scritti nell'archivio dei log associato all'area di lavoro Log Analytics. Per altre informazioni, vedere Funzionalità di Monitoraggio di Azure per il monitoraggio di Kubernetes.

È possibile abilitare informazioni dettagliate sui contenitori di Monitoraggio di Azure per una o più distribuzioni di Kubernetes usando uno script di PowerShell o uno script Bash.

Per altre informazioni, vedere Abilitare il monitoraggio dei cluster di Kubernetes.

Usare Criteri di Azure per abilitare la distribuzione di applicazioni basate su GitOps

Usare Criteri di Azure per assicurarsi che a ogni risorsa o Microsoft.ContainerService/managedClusters risorsa abilitata per Microsoft.Kubernetes/connectedclusters GitOps sia applicata una risorsa specificaMicrosoft.KubernetesConfiguration/fluxConfigurations. Ad esempio, è possibile applicare una configurazione di base a uno o più cluster o distribuire applicazioni specifiche in più cluster. Per usare Criteri di Azure, scegliere una definizione dalle definizioni predefinite di Criteri di Azure per Kubernetes con abilitazione di Azure Arc e quindi creare un'assegnazione di criteri. Quando si crea l'assegnazione di criteri, impostare l'ambito su un gruppo di risorse o una sottoscrizione di Azure. Impostare anche i parametri per l'oggetto fluxConfiguration creato. Quando viene creata l'assegnazione, il motore di Criteri di Azure identifica tutte le connectedCluster risorse o managedCluster che si trovano nell'ambito e quindi applica a fluxConfiguration ogni risorsa.

Se si usano più repository di origine per ogni cluster, ad esempio un repository per l'operatore IT centrale o cluster e altri repository per i team delle applicazioni, attivare questa funzionalità usando più assegnazioni di criteri e configurare ogni assegnazione di criteri per l'uso di un repository di origine diverso.

Per altre informazioni, vedere Distribuire le applicazioni su larga scala usando configurazioni Flux v2 e Criteri di Azure.

Distribuire applicazioni usando GitOps

GitOps è la pratica di definire lo stato desiderato delle configurazioni kubernetes, ad esempio distribuzioni e spazi dei nomi, in un repository di origine. Questo repository può essere un repository Git o Helm, bucket o archiviazione BLOB di Azure. Questo processo è seguito da una distribuzione basata su polling e pull di queste configurazioni nel cluster usando un operatore .

La connessione tra il cluster e uno o più repository di origine è abilitata distribuendo l'estensione microsoft.flux nel cluster. Le proprietà delle fluxConfiguration risorse rappresentano dove e come le risorse Kubernetes devono passare dal repository di origine al cluster. I fluxConfiguration dati vengono archiviati crittografati inattivi in un database di Azure Cosmos DB per garantire la riservatezza dei dati.

L'agente flux-config in esecuzione nel cluster monitora le risorse di estensione nuove o aggiornate fluxConfiguration nella risorsa Kubernetes abilitata per Azure Arc, distribuisce le applicazioni dal repository di origine e propaga tutti gli aggiornamenti eseguiti in fluxConfiguration. È possibile creare più fluxConfiguration risorse usando l'ambito namespace nello stesso cluster Kubernetes abilitato per Azure Arc per ottenere la multi-tenancy.

Il repository di origine può contenere qualsiasi risorsa Kubernetes valida, inclusi Spazi dei nomi, ConfigMaps, Distribuzioni e DaemonSet. Può anche contenere grafici Helm per la distribuzione di applicazioni. Gli scenari comuni del repository di origine includono la definizione di una configurazione di base per l'organizzazione che può includere ruoli e associazioni comuni di controllo degli accessi in base al ruolo, agenti di monitoraggio, agenti di registrazione e servizi a livello di cluster.

È anche possibile gestire una raccolta più ampia di cluster distribuiti in ambienti eterogenei. Ad esempio, è possibile avere un repository che definisce la configurazione di base per l'organizzazione e quindi applicare tale configurazione a più cluster Kubernetes contemporaneamente. È anche possibile distribuire applicazioni in un cluster da più repository di origine.

Per altre informazioni, vedere Distribuire applicazioni usando GitOps con Flux v2.

Eseguire Machine Learning

In Machine Learning è possibile scegliere un cluster Del servizio Azure Kubernetes (o Kubernetes abilitato per Azure Arc) come destinazione di calcolo per i processi di Machine Learning. Questa funzionalità consente di eseguire il training o la distribuzione di modelli di Machine Learning nell'infrastruttura self-hosted (o multicloud). Questo approccio consente di combinare gli investimenti locali nelle GPU con la facilità di gestione fornita da Machine Learning nel cloud.

Monitorare i carichi di lavoro Kubernetes con Prometheus gestito e Grafana

Monitoraggio di Azure offre un servizio gestito per le distribuzioni di Prometheus e Grafana, in modo da poter sfruttare questi strumenti di monitoraggio kubernetes più diffusi. Questo servizio gestito consente di usare questi strumenti senza la necessità di gestire e aggiornare manualmente le distribuzioni. Per analizzare le metriche di Prometheus, usare Esplora metriche con PromQL.

Topologia, rete e routing

Per il funzionamento degli agenti di Azure Arc sono necessari i protocolli, le porte e gli URL in uscita seguenti.

Endpoint del DNS Descrizione
https://management.azure.com:443 Necessario per consentire all'agente di connettersi ad Azure e registrare il cluster.
https://[region].dp.kubernetesconfiguration.azure.com:443 Endpoint del piano dati per l'agente per eseguire il push dello stato e recuperare le informazioni di configurazione, dove [area] rappresenta l'area di Azure che ospita l'istanza del servizio Azure Kubernetes.
https://docker.io:443 Obbligatorio per eseguire il pull delle immagini del contenitore.
https://github.com:443, git://github.com:9418 Esempi di repository GitOps sono ospitati in GitHub. L'agente di configurazione richiede la connettività all'endpoint Git specificato.
https://login.microsoftonline.com:443, https://<region>.login.microsoft.com, login.windows.net Obbligatorio per recuperare e aggiornare i token di Azure Resource Manager.
https://mcr.microsoft.com:443 https://*.data.mcr.microsoft.com:443 Obbligatorio per il pull delle immagini del contenitore per gli agenti di Azure Arc

Per un elenco completo degli URL nei servizi Azure Arc, vedere Requisiti di rete di Azure Arc.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

  • Nella maggior parte degli scenari, il percorso scelto quando si crea lo script di installazione deve essere l'area di Azure geograficamente più vicina alle risorse locali. Il resto dei dati viene archiviato all'interno dell'area geografica di Azure che contiene l'area specificata. Questo dettaglio può influire sulla scelta dell'area in caso di requisiti di residenza dei dati. Se un'interruzione influisce sull'area di Azure a cui è connesso il computer, l'interruzione non influisce sul computer connesso, ma le operazioni di gestione che usano Azure potrebbero non essere completate. Se si dispone di più località che forniscono un servizio con ridondanza geografica, connettere i computer in ogni località a un'area di Azure diversa. Questa procedura migliora la resilienza se si verifica un'interruzione a livello di area. Per altre informazioni, vedere Aree supportate per Kubernetes con abilitazione di Azure Arc.

  • È necessario assicurarsi che i servizi nella soluzione siano supportati nell'area in cui è distribuito Azure Arc.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.

  • È possibile usare il controllo degli accessi in base al ruolo di Azure per gestire l'accesso a Kubernetes abilitato per Azure Arc in ambienti Azure e locali che usano le identità di Microsoft Entra. Per altre informazioni, vedere Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione kubernetes.

  • Microsoft consiglia di usare un'entità servizio con privilegi limitati per eseguire l'onboarding dei cluster Kubernetes in Azure Arc. Questa procedura è utile per l'integrazione continua e le pipeline di recapito continuo, ad esempio Azure Pipelines e GitHub Actions. Per altre informazioni, vedere Creare un'entità servizio di onboarding abilitata per Azure Arc.

  • Per semplificare la gestione delle entità servizio, è possibile usare le identità gestite nel servizio Azure Kubernetes. Tuttavia, i cluster devono essere creati usando l'identità gestita. Non è possibile eseguire la migrazione dei cluster esistenti, che includono Azure e cluster locali, alle identità gestite. Per ulteriori informazioni, vedere Utilizzare un'identità gestita in AKS.

Ottimizzazione costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Per considerazioni generali sul costo, vedere Principi di progettazione di Ottimizzazione costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

  • Prima di configurare i cluster Kubernetes abilitati per Azure Arc, esaminare i limiti delle sottoscrizioni di Azure Resource Manager e i limiti del gruppo di risorse per pianificare il numero di cluster.

  • Usare Helm, uno strumento per la creazione di pacchetti open source, per installare e gestire i cicli di vita delle applicazioni Kubernetes. Analogamente agli strumenti di gestione pacchetti Linux, ad esempio APT e Yum, usare Helm per gestire i grafici Kubernetes, che sono pacchetti di risorse Kubernetes preconfigurate.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Indicazioni ibride correlate:

Architetture correlate: