Modifica

Gestione e distribuzione ibride di Azure Arc per i cluster Kubernetes

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

Questa architettura di riferimento illustra 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 dell'architettura che mostra una topologia di Azure Arc per Kubernetes.

Scaricare un file di Visio di questa architettura.

Workflow

L'architettura è costituita dagli aspetti seguenti:

  • 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 di terze parti.
  • Criteri di Azure. Distribuire e gestire i criteri per i cluster Kubernetes abilitati per Arc.
  • Monitoraggio di Azure. Osservare e monitorare i cluster Kubernetes abilitati per Arc.

Componenti

  • Azure Arc è un bridge che estende la piattaforma Azure, consentendo di creare applicazioni e servizi che possono essere eseguiti tra data center, perimetrali e ambienti multicloud.
  • servizio Azure Kubernetes (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 insieme ai cluster ospitati in servizio Azure Kubernetes (servizio Azure Kubernetes).

Potenziali casi d'uso

Tra gli usi tipici di questa architettura sono inclusi:

  • Gestione di cluster e cluster Kubernetes locali ospitati nel servizio Azure Kubernetes per inventario, raggruppamento e assegnazione di tag.
  • 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.

Consigli

Le sezioni seguenti offrono raccomandazioni applicabili alla maggior parte degli scenari. Microsoft consiglia di seguirli, a meno che non si disponga di un requisito che li sostituisce.

Registrazione del cluster

È possibile registrare qualsiasi cluster KUBernetes KUBernetes attivo. È necessario un file kubeconfig per accedere al cluster e a un ruolo di amministratore del cluster nel cluster per distribuire gli agenti Kubernetes abilitati per Arc. Usare il interfaccia della riga di comando di Azure (interfaccia della riga di comando di Azure) per eseguire attività di registrazione del cluster. L'utente o l'entità servizio usata per i comandi az login e az connectedk8s connect richiedono autorizzazioni di lettura e scrittura per il tipo di risorsa Microsoft.Kubernetes/connectedClusters. 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 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 (detti anche operatori) eseguiti nel cluster distribuito nello spazio dei nomi azure-arc :

  • deployment.apps/config-agent. Controlla 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. Operatore di operatori che orchestra le interazioni tra i componenti di Azure Arc.
  • deployment.apps/metrics-agent. Raccoglie le metriche da altri agenti Arc per garantire che questi agenti presentino prestazioni ottimali.
  • deployment.apps/cluster-metadata-operator. Raccoglie i metadati del cluster, 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 indicati in precedenza in Azure.
  • deployment.apps/clusteridentityoperator. Gestisce il certificato dell'identità del servizio gestito usato da altri agenti per comunicare con Azure.
  • deployment.apps/flux-logs-agent. Raccoglie i log dagli operatori di flusso distribuiti come parte della configurazione del controllo del codice sorgente.
  • deployment.apps/extension-manager. Installa e gestisce il ciclo di vita dei grafici Helm dell'estensione.
  • deployment.apps/kube-azure-ad-proxy. Usato per l'autenticazione delle richieste inviate al cluster tramite Cluster Connessione.
  • deployment.apps/clusterconnect-agent. 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 la funzionalità azure-rbac è abilitata nel cluster.

Per altre informazioni, vedere Connessione un cluster Kubernetes abilitato per 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 un'esperienza di monitoraggio completa per i cluster del motore del servizio Azure Kubernetes e del servizio Azure Kubernetes. È anche possibile configurare informazioni dettagliate sul contenitore di Monitoraggio di Azure per monitorare i cluster Kubernetes abilitati per Azure Arc ospitati all'esterno di Azure. In questo modo viene fornito un monitoraggio completo dei cluster Kubernetes in azure, in ambienti cloud locali e di terze parti.

Le informazioni dettagliate sui contenitori di Monitoraggio di Azure possono offrire visibilità sulle prestazioni raccogliendo metriche di memoria e processore da controller, nodi e contenitori, metriche disponibili in Kubernetes tramite l'API (Metrics Application Programming Interface). Vengono raccolti anche i log dei contenitori. Dopo aver abilitato il monitoraggio dai cluster Kubernetes, le metriche e i log vengono raccolti automaticamente da una versione in contenitori dell'agente di Log Analytics. 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 sulle informazioni dettagliate sui contenitori di Monitoraggio di Azure, vedere Panoramica di Informazioni dettagliate sui contenitori di Monitoraggio di Azure.

È 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 abilitare il monitoraggio per i cluster Kubernetes abilitati per Arc, vedere Abilitare il monitoraggio del cluster Kubernetes abilitato per Azure Arc

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

Usare Criteri di Azure per imporre che a ogni risorsa Microsoft.Kubernetes/connectedclusters abilitata per GitOps o microsoft.ContainerService/managedClusters siano applicate specifiche risorse Microsoft.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, selezionare una definizione dalle definizioni predefinite 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 fluxConfiguration creato. Quando viene creata l'assegnazione, il motore criteri identificherà tutte le risorse connectedCluster o managedCluster che si trovano all'interno dell'ambito e quindi applicheranno fluxConfiguration a ognuna.

Se si usano più repository di origine per ogni cluster (ad esempio, un repository per l'operatore IT/cluster centrale e altri repository per i team delle applicazioni), attivarlo 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 con GitOps

GitOps è la procedura per dichiarare lo stato desiderato della configurazione di Kubernetes (distribuzioni, spazi dei nomi e così via) in un repository di origine, ad esempio un repository Git o Helm, bucket o Archiviazione BLOB di Azure. Questo è 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 risorse fluxConfiguration rappresentano dove e come le risorse Kubernetes devono passare dal repository di origine al cluster. I dati di fluxConfiguration vengono archiviati crittografati inattivi in un database di Azure Cosmos DB per garantire la riservatezza dei dati.

L'agente flux-config eseguito nel cluster è responsabile della ricerca delle risorse dell'estensione fluxConfiguration nuove o aggiornate nella risorsa Kubernetes abilitata per Azure Arc, per la distribuzione di applicazioni dal repository di origine e per la propagazione di eventuali aggiornamenti apportati a fluxConfiguration. È anche possibile creare più risorse fluxConfiguration usando l'ambito dello spazio dei nomi 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, Config Mappe, 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 di controllo degli accessi in base al ruolo comuni, 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 applicarlo a più cluster Kubernetes contemporaneamente. È anche possibile distribuire applicazioni in un cluster da più repository di origine.

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

Topologia, rete e routing

Per funzionare, gli agenti di Azure Arc richiedono i protocolli/porte/URL in uscita seguenti:

Endpoint (DNS) Descrizione
https://management.azure.com:443 Obbligatorio 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 Necessario 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à a qualsiasi endpoint Git specificato.
https://login.microsoftonline.com:443 Obbligatorio per recuperare e aggiornare i token di Azure Resource Manager.
https://azurearcfork8s.azurecr.io:443 Necessario per eseguire 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 set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

  • Nella maggior parte dei casi, il percorso selezionato 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, un fatto che potrebbe 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. Per la resilienza quando si verifica un'interruzione a livello di area, è consigliabile, se si dispone di più posizioni che forniscono un servizio con ridondanza geografica, per connettere i computer in ogni località a un'area di Azure diversa. Per le aree disponibili, vedere Aree supportate per Kubernetes con abilitazione di Azure Arc.
  • È necessario assicurarsi che i servizi a cui viene fatto riferimento nella sezione Architettura siano supportati nell'area in cui viene distribuito Azure Arc.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

  • È 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 nelle pipeline CI/CD, 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 e i cluster esistenti (inclusi Azure e i cluster locali) non possono essere migrati alle identità gestite. Per altre informazioni, vedere Usare le identità gestite nel servizio Azure Kubernetes.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Le considerazioni generali sui costi sono descritte nella sezione Principi di ottimizzazione dei costi in Microsoft Azure Well-Architected Framework.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'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, lo strumento per la creazione di pacchetti open source, per installare e gestire i cicli di vita dell'applicazione Kubernetes. Analogamente agli strumenti di gestione pacchetti Linux, ad esempio APT e Yum, si usa Helm per gestire i grafici Kubernetes, ovvero pacchetti di risorse Kubernetes preconfigurate.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

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

Passaggi successivi

Indicazioni ibride correlate:

Architetture correlate: