Creare un cluster Kubernetes a disponibilità elevata nell'hub di Azure Stack

Questo articolo descrive come progettare e gestire un'infrastruttura basata su Kubernetes a disponibilità elevata usando il motore servizio Azure Kubernetes (AKS) nell'hub di Azure Stack. La soluzione si basa su uno scenario con un set rigoroso di vincoli. L'applicazione deve essere eseguita in locale e i dati personali non devono raggiungere i servizi cloud pubblici. I dati di monitoraggio e altre informazioni non personali possono essere inviati ad Azure per l'elaborazione. È possibile accedere a servizi esterni come un registro contenitori pubblico, ma potrebbe essere filtrato tramite un firewall o un server proxy.

Helm e Let's Encrypt sono marchi delle rispettive società. Nessuna verifica dell'autenticità è implicita nell'uso di questi marchi.

Architettura

Scaricare un file di Visio di tutti i diagrammi in questo articolo.

Workflow

Il diagramma precedente illustra l'architettura dell'applicazione di esempio in esecuzione in Kubernetes nell'hub di Azure Stack. L'app è costituita da questi componenti:

1. Un cluster Kubernetes basato sul motore del servizio Azure Kubernetes nell'hub di Azure Stack.
2. cert-manager, che offre una suite di strumenti per la gestione dei certificati in Kubernetes. Viene usato per richiedere automaticamente i certificati da Let's Encrypt.
3. Spazio dei nomi Kubernetes che contiene i componenti dell'applicazione per:
   1. front-end (ratings-web)
   2. API (ratings-api)
   3. database (ratings-mongodb)
4. Controller di ingresso che instrada il traffico HTTP/HTTPS agli endpoint all'interno del cluster Kubernetes.

L'applicazione di esempio viene usata per illustrare questa architettura. Tutti i componenti sono esempi. L'architettura contiene solo la distribuzione di una singola applicazione. Per ottenere la disponibilità elevata, la distribuzione viene eseguita almeno due volte in due istanze dell'hub di Azure Stack. Possono essere eseguiti in un'unica posizione o in due o più siti:

I servizi come Registro Azure Container e Monitoraggio di Azure sono ospitati all'esterno dell'hub di Azure Stack in Azure o in locale. Questa progettazione ibrida protegge la soluzione dall'interruzione di una singola istanza dell'hub di Azure Stack.

Componenti

• L'hub di Azure Stack è un'estensione di Azure che consente di eseguire i carichi di lavoro in un ambiente locale fornendo i servizi di Azure nel data center.
• Il motore del servizio Azure Kubernetes per Azure Stack offre uno strumento da riga di comando che consente di effettuare il provisioning di un cluster Kubernetes autogestito nell'hub di Azure Stack. Usa Azure Resource Manager per creare, eliminare e gestire i cluster di cui è stato effettuato il provisioning con risorse IaaS di base nell'hub di Azure Stack.
• Rete virtuale fornisce l'infrastruttura di rete in ogni istanza dell'hub di Azure Stack per le macchine virtuali che ospitano l'infrastruttura del cluster Kubernetes.
• Azure Load Balancer viene usato per l'endpoint dell'API Kubernetes e il controller di ingresso Nginx. Il servizio di bilanciamento del carico instrada il traffico esterno ,ad esempio Internet, a nodi e macchine virtuali che forniscono un servizio specifico.
• Registro Container viene usato per archiviare immagini Docker private e grafici Helm, che vengono distribuiti nel cluster. Il motore del servizio Azure Kubernetes può eseguire l'autenticazione con il registro contenitori usando un'identità di Microsoft Entra. Kubernetes non richiede registro contenitori. È possibile usare altri registri contenitori, ad esempio Docker Hub.
• Azure Repos è un set di strumenti di controllo della versione che è possibile usare per gestire il codice. È anche possibile usare GitHub o altri repository basati su Git.
• Azure Pipelines fa parte di Azure DevOps Services. Esegue compilazioni, test e distribuzioni automatizzate. È anche possibile usare soluzioni CI/CD di terze parti come Jenkins.
• Monitoraggio di Azure raccoglie e archivia log e metriche, tra cui le metriche della piattaforma per i servizi di Azure nella soluzione e i dati di telemetria dell'applicazione. Usare questi dati per monitorare l'applicazione, configurare avvisi e dashboard ed eseguire l'analisi delle cause principali di errore. Monitoraggio di Azure si integra con Kubernetes per raccogliere metriche da controller, nodi, contenitori, log dei contenitori e log dei nodi del piano di controllo.
• Gestione traffico di Azure è un servizio di bilanciamento del carico del traffico basato su DNS che è possibile usare per distribuire il traffico in modo ottimale ai servizi in diverse aree di Azure o nelle distribuzioni dell'hub di Azure Stack. Gestione traffico offre anche disponibilità elevata e tempi di risposta rapidi. Gli endpoint dell'applicazione devono essere accessibili dall'esterno per essere aggiunti come endpoint a Gestione traffico di Azure.
• Un controller di ingresso Kubernetes espone le route HTTP(S) ai servizi in un cluster Kubernetes. È possibile usare NGINX o qualsiasi controller di ingresso appropriato.
• Helm è una gestione pacchetti per la distribuzione di Kubernetes. Offre un modo per aggregare diversi oggetti Kubernetes, ad esempio Deployments, Servicese Secrets, in un singolo "grafico". È possibile pubblicare, distribuire, versione e aggiornare un oggetto grafico. È possibile usare Registro Container come repository per archiviare grafici Helm in pacchetto.

Alternative

Gestione traffico di Azure è una delle opzioni disponibili per distribuire il traffico tra due endpoint raggiungibili da Internet. È anche possibile usare altre soluzioni di bilanciamento del carico per distribuire il traffico tra istanze dell'hub di Azure Stack. Possono verificarsi scenari in cui gli endpoint dell'applicazione ospitati nell'hub di Azure Stack devono essere limitati solo all'interno della rete privata. I servizi di bilanciamento del carico di terze parti possono essere usati in questi scenari per bilanciare il carico del traffico tra istanze dell'hub di Azure Stack all'interno della rete, indipendentemente dal fatto che si trovino nello stesso data center o distribuite in più data center.

Dettagli dello scenario

L'applicazione di esempio illustrata di seguito è progettata per usare soluzioni native kubernetes anziché servizi nativi della piattaforma quando possibile. Questa progettazione evita il blocco del fornitore. Ad esempio, l'applicazione usa un back-end di database MongoDB self-hosted anziché un servizio PaaS o un servizio di database esterno. Per altre informazioni, vedere il percorso di apprendimento Introduzione a Kubernetes in Azure .

Potenziali casi d'uso

Molte organizzazioni sviluppano soluzioni native del cloud che sfruttano servizi e tecnologie all'avanguardia come Kubernetes. Anche se Azure offre data center nella maggior parte delle aree del mondo, a volte le applicazioni critiche per l'azienda devono essere eseguite in una posizione specifica. I potenziali problemi includono:

• Riservatezza della posizione.
• Latenza tra l'applicazione e i sistemi locali.
• Conservazione della larghezza di banda.
• Connettività.
• Requisiti normativi o normativi.

Azure, in combinazione con l'hub di Azure Stack, risolve la maggior parte di questi aspetti. Questo articolo offre un'ampia gamma di opzioni, decisioni e considerazioni che consentono di progettare correttamente soluzioni Kubernetes basate su disponibilità elevata nell'hub di Azure Stack.

Lo scenario descritto di seguito è comune per le organizzazioni con carichi di lavoro critici in ambienti altamente limitati e regolamentati. È applicabile in domini come finanza, difesa e governo.

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.

Progettazione

Questa soluzione incorpora alcuni consigli generali illustrati in modo più dettagliato nelle sezioni successive di questo articolo:

• Per evitare il blocco del fornitore, l'applicazione usa soluzioni native di Kubernetes.
• L'applicazione usa un'architettura di microservizi.
• L'hub di Azure Stack non richiede la connettività Internet in ingresso. Consente la connettività Internet in uscita.

Queste procedure consigliate si applicano anche a carichi di lavoro e scenari reali.

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à.

La scalabilità consente di fornire accesso coerente, affidabile e con prestazioni buone all'applicazione.

Lo scenario di esempio implementa la scalabilità in tre livelli dello stack di applicazioni. Ecco una panoramica generale dei livelli:

Livello dell'architettura	Impatto	Come?
Applicazione	Applicazione	Scalabilità orizzontale in base al numero di pod/repliche/istanze del contenitore.*
Cluster	Cluster Kubernetes	Numero di nodi (compreso tra 1 e 50), dimensioni dello SKU della macchina virtuale e, tramite il comando manuale del motore del servizio Azure Kubernetes scale , i pool di nodi.
Infrastruttura	Hub di Azure Stack	Numero di nodi, capacità e unità di scala all'interno di una distribuzione dell'hub di Azure Stack.

* Tramite HorizontalPodAutoscaler di Kubernetes, che fornisce scalabilità automatica basata sulle metriche o ridimensionamento verticale ridimensionando le istanze del contenitore (CPU o memoria).

Hub di Azure Stack (livello dell'infrastruttura)

Poiché l'hub di Azure Stack viene eseguito su hardware fisico in un data center, l'infrastruttura dell'hub di Azure Stack è la base di questa implementazione. Quando si sceglie l'hardware dell'hub, è necessario scegliere la CPU, la densità di memoria, la configurazione di archiviazione e il numero di server. Per altre informazioni sulla scalabilità dell'hub di Azure Stack, vedere queste risorse:

• Panoramica della pianificazione della capacità per l'hub di Azure Stack
• Aggiungere nodi unità di scala nell'hub di Azure Stack

Cluster Kubernetes (livello del cluster)

Il cluster Kubernetes è costituito da e si basa su componenti IaaS dell'hub di Azure e di Azure Stack, tra cui risorse di calcolo, archiviazione e rete. Le soluzioni Kubernetes sono costituite da nodi del piano di controllo e nodi di lavoro, distribuiti come macchine virtuali in Azure e nell'hub di Azure Stack.

• I nodi del piano di controllo forniscono i servizi Kubernetes di base e l'orchestrazione dei carichi di lavoro dell'applicazione.
• I nodi di lavoro eseguono i carichi di lavoro dell'applicazione.

Quando si scelgono le dimensioni delle macchine virtuali per la distribuzione iniziale, prendere in considerazione quanto segue:

• Costo. Quando si pianificano i nodi di lavoro, prendere in considerazione il costo complessivo per macchina virtuale. Ad esempio, se i carichi di lavoro dell'applicazione richiedono risorse limitate, è consigliabile pianificare la distribuzione di macchine virtuali più piccole. L'hub di Azure Stack, come Azure, viene in genere fatturato a consumo, quindi per ottimizzare i costi a consumo, è fondamentale dimensionare in modo appropriato le VM per i ruoli di Kubernetes.

• Scalabilità. Per ottenere la scalabilità del cluster, è possibile aumentare e aumentare il numero di nodi del piano di controllo e del ruolo di lavoro oppure aggiungendo pool di nodi. Non è attualmente possibile aggiungere pool di nodi nell'hub di Azure Stack. È possibile ridimensionare il cluster in base ai dati sulle prestazioni raccolti con Informazioni dettagliate sui contenitori (Monitoraggio di Azure e Log Analytics).

  Se l'applicazione richiede più o meno risorse, è possibile ridimensionare il numero di nodi in uscita o in orizzontale, tra 1 e 50 nodi. Se sono necessari più di 50 nodi, è possibile creare un altro cluster in una sottoscrizione separata. Non è possibile scalare verticalmente le VM effettive passando ad altre dimensioni di VM senza ridistribuire il cluster.

  Implementare il ridimensionamento manualmente usando la macchina virtuale helper del motore del servizio Azure Kubernetes usata per distribuire il cluster Kubernetes. Per altre informazioni, vedere Ridimensionamento dei cluster Kubernetes.

• Quote. Prendere in considerazione le quote configurate quando si pianifica una distribuzione del servizio Azure Kubernetes nell'hub di Azure Stack. Assicurarsi che ogni sottoscrizione disponga dei piani e delle quote appropriati configurati. La sottoscrizione dovrà soddisfare la quantità di risorse di calcolo, archiviazione e altri servizi necessari per i cluster man mano che aumentano il numero di istanze.

• Carichi di lavoro dell'applicazione. Vedere i concetti relativi a cluster e carichi di lavoro nell'articolo concetti di base di Kubernetes per servizio Azure Kubernetes. Questo articolo consente di definire l'ambito delle dimensioni della macchina virtuale in base alle esigenze di calcolo e memoria dell'applicazione.

Applicazione (livello dell'applicazione)

Nel livello dell'applicazione la soluzione usa HorizontalPodAutoscaler di Kubernetes. HorizontalPodAutoscaler può aumentare o diminuire il numero di repliche (pod/istanze del contenitore) nella distribuzione in base a varie metriche, ad esempio l'utilizzo della CPU.

Un'altra opzione consiste nel dimensionare le istanze di contenitori verticalmente. È possibile eseguire questo tipo di ridimensionamento modificando la quantità di CPU e memoria richiesta e disponibile per una distribuzione specifica. Per altre informazioni, vedere Gestione delle risorse per i contenitori.

Rete e connettività

Le funzionalità di rete e connettività influiscono anche sui tre livelli illustrati in precedenza. La tabella seguente illustra i livelli e i servizi che contengono.

Livello	Impatto	Cosa?
Applicazione	Applicazione	Modalità di accesso all'applicazione. Indica se è esposto a Internet.
Cluster	Cluster Kubernetes	API Kubernetes, macchina virtuale del motore del servizio Azure Kubernetes, pull di immagini del contenitore (in uscita), invio di dati di monitoraggio e telemetria (uscita).
Infrastruttura	Hub di Azure Stack	Accessibilità degli endpoint di gestione dell'hub di Azure Stack, ad esempio il portale e gli endpoint di Azure Resource Manager.

Applicazione

Sul livello dell'applicazione, la considerazione più importante è se l'applicazione è esposta a Internet e può essere accessibile da Internet. Dal punto di vista di Kubernetes, l'accesso a Internet richiede l'esposizione di una distribuzione o di un pod usando un servizio Kubernetes o un controller di ingresso.

Un'applicazione può essere esposta con un indirizzo IP pubblico tramite un servizio di bilanciamento del carico o un controller di ingresso senza essere accessibile tramite Internet. L'hub di Azure Stack può avere un indirizzo IP pubblico visibile solo nella intranet locale. Non tutti gli INDIRIZZI IP pubblici sono realmente con connessione Internet.

Oltre al traffico in ingresso verso l'applicazione, è anche necessario prendere in considerazione il traffico in uscita o in uscita. Ecco alcuni casi d'uso che richiedono il traffico in uscita:

• Pull di immagini del contenitore archiviate nell'hub Docker o nel Registro Contenitori
• Recupero di grafici Helm
• Creazione di dati di Application Insights o di altri dati di monitoraggio
• Connessione alle applicazioni esterne

Alcuni ambienti aziendali potrebbero richiedere l'uso di server proxy trasparenti o non trasparenti. Questi server richiedono una configurazione specifica in vari componenti del cluster. La documentazione del motore del servizio Azure Kubernetes contiene informazioni dettagliate su come supportare i proxy di rete. Per altre informazioni, vedere Motore del servizio Azure Kubernetes e server proxy.

Infine, il traffico tra cluster deve fluire tra le istanze dell'hub di Azure Stack. La soluzione descritta di seguito è costituita da singoli cluster Kubernetes eseguiti in singole istanze dell'hub di Azure Stack. Il traffico tra di essi, ad esempio il traffico di replica tra due database, viene considerato traffico esterno. Il traffico esterno deve essere instradato tramite una VPN da sito a sito o indirizzi IP pubblici dell'hub di Azure Stack. La VPN da sito a sito offre maggiore sicurezza per i trasferimenti di dati ed è preferibile.

Cluster

Il cluster Kubernetes non deve necessariamente essere accessibile tramite Internet. La parte pertinente è l'API Kubernetes usata per gestire un cluster, ad esempio tramite kubectl. Tutti gli utenti che gestiscono il cluster o distribuiscono applicazioni e servizi devono essere in grado di accedere all'endpoint DELL'API Kubernetes. Questo argomento è trattato in modo più dettagliato dal punto di vista di DevOps nella sezione Distribuzione (CI/CD) di questo articolo.

A livello di cluster, esistono anche alcune considerazioni per il traffico in uscita:

• Aggiornamenti dei nodi (per Ubuntu)
• Dati di monitoraggio (inviati a Log Analytics)
• Altri agenti che richiedono il traffico in uscita (specifico per ogni ambiente di distribuzione)

Prima di distribuire il cluster Kubernetes usando il motore del servizio Azure Kubernetes, pianificare la progettazione finale della rete. Potrebbe essere più efficiente distribuire un cluster in una rete esistente anziché creare una rete virtuale dedicata. Ad esempio, è possibile usare una connessione VPN da sito a sito già configurata nell'ambiente dell'hub di Azure Stack.

Infrastruttura

L'infrastruttura si riferisce all'accesso agli endpoint di gestione dell'hub di Azure Stack. Gli endpoint includono i portali tenant e di amministrazione e gli endpoint di amministratore e tenant di Resource Manager. Questi endpoint sono necessari per il funzionamento dell'hub di Azure Stack e dei relativi servizi di base.

Dati e risorse di archiviazione

Due istanze dell'applicazione vengono distribuite in due singoli cluster Kubernetes in due istanze dell'hub di Azure Stack. Per questa progettazione, è necessario considerare come replicare e sincronizzare i dati tra le istanze.

Azure offre la funzionalità predefinita per replicare l'archiviazione tra più aree e zone all'interno del cloud. Attualmente, non esiste un modo nativo per replicare l'archiviazione tra due istanze dell'hub di Azure Stack. Formano due cloud indipendenti e non esiste un modo generale per gestirli come set. Quando si pianifica la resilienza delle applicazioni eseguite nell'hub di Azure Stack, prendere in considerazione questa indipendenza nella progettazione e nelle distribuzioni dell'applicazione.

Nella maggior parte dei casi, la replica di archiviazione non è necessaria per un'applicazione resiliente e a disponibilità elevata distribuita nel servizio Azure Kubernetes. Tuttavia, è necessario considerare l'archiviazione indipendente per ogni istanza dell'hub di Azure Stack nella progettazione dell'applicazione. Se questa progettazione è un problema, prendere in considerazione le soluzioni di allegato di archiviazione offerte dai partner Microsoft. Archiviazione allegati forniscono una soluzione di replica di archiviazione tra più istanze dell'hub di Azure Stack e Azure. Per altre informazioni, vedere la sezione Soluzioni per i partner di questo articolo.

Questa architettura prende in considerazione questi elementi:

Impostazione

Questa categoria include la configurazione dell'hub di Azure Stack, del motore del servizio Azure Kubernetes e del cluster Kubernetes stesso. È consigliabile automatizzare la configurazione il più possibile e archiviarla come infrastruttura come codice in un sistema di controllo della versione basato su Git, ad esempio Azure DevOps o GitHub. Non è possibile sincronizzare facilmente queste impostazioni tra più distribuzioni. È consigliabile archiviare e applicare la configurazione dall'esterno e usare la pipeline DevOps.

Applicazione

È consigliabile archiviare l'applicazione in un repository basato su Git. In caso affermativo, ogni volta che è presente una nuova distribuzione, le modifiche apportate all'applicazione o il ripristino di emergenza, è possibile distribuire facilmente l'applicazione usando Azure Pipelines.

Dati

I dati rappresentano il fattore più importante da considerare nella progettazione di applicazioni. I dati devono rimanere sincronizzati tra le diverse istanze dell'applicazione. È necessaria anche una strategia di backup e ripristino di emergenza per i dati in caso di interruzione.

Se si usano dati in più posizioni, l'implementazione di una soluzione a disponibilità elevata e resiliente è ancora più complessa. Tenere in considerazione:

• Latenza e connettività di rete tra istanze dell'hub di Azure Stack.
• Disponibilità delle identità per servizi e autorizzazioni. Ogni istanza dell'hub di Azure Stack integra una directory esterna. Durante la distribuzione, si sceglie di usare Microsoft Entra ID o Active Directory Federation Services (AD FS). È quindi possibile usare una singola identità che può interagire con più istanze indipendenti dell'hub di Azure Stack.

Continuità aziendale e ripristino di emergenza

La continuità aziendale e il ripristino di emergenza (BCDR) sono una considerazione importante sia per l'hub di Azure Stack che per Azure. La differenza principale è che, per l'hub di Azure Stack, l'operatore deve gestire l'intero processo BCDR. Per Azure, le parti di BCDR vengono gestite automaticamente da Microsoft.

BCDR influisce sulle stesse aree descritte nella sezione precedente:

• Infrastruttura e configurazione
• Disponibilità dell'applicazione
• Dati dell'applicazione

Queste aree sono responsabilità dell'operatore hub di Azure Stack. I dettagli possono variare, a seconda dell'organizzazione. Pianificare la continuità aziendale e il ripristino di emergenza in base agli strumenti e ai processi disponibili.

Infrastruttura e configurazione

Questa sezione descrive l'infrastruttura fisica e logica e la configurazione dell'hub di Azure Stack. Vengono illustrate le azioni negli spazi di amministrazione e tenant.

L'operatore o l'amministratore dell'hub di Azure Stack è responsabile della manutenzione delle istanze dell'hub di Azure Stack. Questa manutenzione include la rete, l'archiviazione, l'identità e altri elementi esterni all'ambito di questo articolo. Per altre informazioni sulle specifiche delle operazioni dell'hub di Azure Stack, vedere queste risorse:

• Recuperare i dati nell'hub di Azure Stack con il servizio Backup infrastruttura
• Abilitare il backup per l'hub di Azure Stack nel portale dell'amministratore
• Eseguire il ripristino da una grave perdita di dati
• Procedure consigliate per il servizio Backup infrastruttura

L'hub di Azure Stack è la piattaforma e l'infrastruttura in cui vengono distribuite le applicazioni Kubernetes. Il proprietario dell'applicazione Kubernetes è un utente dell'hub di Azure Stack che ha accesso per distribuire l'infrastruttura dell'applicazione necessaria per la soluzione. L'infrastruttura dell'applicazione, in questo caso, è il cluster Kubernetes, distribuito tramite il motore del servizio Azure Kubernetes e i servizi circostanti.

Questi componenti vengono distribuiti nell'hub di Azure Stack. I componenti sono vincolati dall'offerta dell'hub di Azure Stack. Assicurarsi che l'offerta accettata dal proprietario dell'applicazione Kubernetes disponga di capacità sufficiente, espressa nelle quote dell'hub di Azure Stack, per distribuire l'intera soluzione. Come consigliato nella sezione precedente, è consigliabile automatizzare la distribuzione dell'applicazione usando pipeline di distribuzione come codice e infrastruttura come Azure Pipelines.

Per altre informazioni sulle offerte e sulle quote dell'hub di Azure Stack, vedere Panoramica dei servizi, dei piani, delle offerte e delle sottoscrizioni dell'hub di Azure Stack.

È importante salvare e archiviare in modo sicuro la configurazione del motore del servizio Azure Kubernetes, inclusi gli output. Questi file contengono informazioni riservate usate per accedere al cluster Kubernetes, quindi devono essere protette dall'esposizione a utenti non amministratori.

Disponibilità dell'applicazione

L'applicazione non deve basarsi sui backup di un'istanza distribuita. Come procedura standard, ridistribuire completamente l'applicazione, seguendo i modelli di infrastruttura come codice. Ad esempio, ridistribuire usando Azure Pipelines. La procedura BCDR deve comportare la ridistribuzione dell'applicazione nello stesso cluster Kubernetes o in un altro cluster.

Dati dell'applicazione

I dati dell'applicazione sono il componente critico di BCDR. Le sezioni precedenti descrivono le tecniche per la replica e la sincronizzazione dei dati tra due o più istanze di un'applicazione. A seconda dell'infrastruttura di database (ad esempio MySQL, MongoDB o SQL Server) usata per archiviare i dati, sono disponibili diverse tecniche di disponibilità e backup del database.

Per ottenere l'integrità, è consigliabile usare una delle soluzioni seguenti:

• Una soluzione di backup nativa per il database specifico.
• Soluzione di backup che supporta il backup e il ripristino del tipo di database usato dall'applicazione.

Disponibilità

Kubernetes nell'hub di Azure Stack, quando distribuito tramite il motore del servizio Azure Kubernetes, non è un servizio gestito. Si tratta di una distribuzione e una configurazione automatizzata di un cluster Kubernetes che usa l'infrastruttura distribuita come servizio (IaaS) di Azure. Fornisce quindi la stessa disponibilità dell'infrastruttura sottostante.

L'infrastruttura dell'hub di Azure Stack è già resiliente agli errori e offre funzionalità come i set di disponibilità per distribuire i componenti tra più domini di errore e di aggiornamento. Tuttavia, la tecnologia sottostante (clustering di failover) comporta ancora tempi di inattività per le macchine virtuali in un server fisico interessato, in caso di errore hardware.

È consigliabile distribuire il cluster Kubernetes di produzione e anche il carico di lavoro in due o più cluster. Questi cluster devono essere ospitati in posizioni o data center diversi e usare tecnologie come Gestione traffico per instradare gli utenti in base al tempo di risposta del cluster o all'area geografica.

I clienti con un singolo cluster Kubernetes in genere si connettono all'indirizzo IP del servizio o al nome DNS di una determinata applicazione. Nelle distribuzioni con più cluster, i clienti dovrebbero connettersi a un nome DNS di Gestione traffico che punta ai servizi/in ingresso in ogni cluster Kubernetes.

Il cluster Kubernetes stesso, distribuito tramite il motore del servizio Azure Kubernetes, deve essere costituito da almeno tre nodi del piano di controllo e due nodi di lavoro.

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.

La sicurezza e l'identità sono particolarmente importanti quando la soluzione si estende su istanze indipendenti dell'hub di Azure Stack. Kubernetes e Azure, incluso l'hub di Azure Stack, hanno meccanismi distinti per il controllo degli accessi in base al ruolo:

• Il controllo degli accessi in base al ruolo di Azure controlla l'accesso ad Azure e all'hub di Azure Stack, inclusa la possibilità di creare nuove risorse di Azure. Questi ruoli possono essere assegnati a utenti, gruppi o entità servizio Un'entità servizio è un'identità di sicurezza usata dalle applicazioni.
• I controlli degli accessi in base al ruolo di Kubernetes consentoni di controllare le autorizzazioni per l'API di Kubernetes. Ad esempio, la creazione di pod e l'elenco dei pod sono azioni che possono essere concesse o negate a un utente tramite il controllo degli accessi in base al ruolo. Per assegnare le autorizzazioni di Kubernetes agli utenti, creare ruoli e binding di ruoli.

Identità dell'hub di Azure Stack e controllo degli accessi in base al ruolo

L'hub di Azure Stack prevede due opzioni per il provider di identità. Il provider usato dipende dall'ambiente e dall'esecuzione in un ambiente connesso o disconnesso:

• Microsoft Entra ID può essere usato solo in un ambiente connesso.
• AD FS a una foresta Active Directory tradizionale può essere usata in un ambiente connesso o disconnesso.

Il provider di identità gestisce utenti e gruppi, tra cui l'autenticazione e l'autorizzazione per l'accesso alle risorse. È possibile concedere l'accesso alle risorse dell'hub di Azure Stack, ad esempio sottoscrizioni, gruppi di risorse e singole risorse, ad esempio macchine virtuali e servizi di bilanciamento del carico. Per coerenza, è consigliabile usare gli stessi gruppi, diretti o annidati, per tutte le istanze dell'hub di Azure Stack. Ecco una configurazione di esempio:

Questo esempio contiene un gruppo dedicato (usando l'ID Microsoft Entra o AD FS) per uno scopo specifico, ad esempio per fornire autorizzazioni di collaboratore per il gruppo di risorse che contiene l'infrastruttura del cluster Kubernetes in un'istanza specifica dell'hub di Azure Stack (qui "Collaboratore cluster Seattle K8s"). Questi gruppi vengono quindi annidati in un gruppo complessivo che contiene i sottogruppi per ogni istanza dell'hub di Azure Stack.

L'utente di esempio ha ora autorizzazioni di collaboratore per entrambi i gruppi di risorse che contengono l'intero set di risorse dell'infrastruttura Kubernetes. L'utente ha accesso alle risorse in entrambe le istanze dell'hub di Azure Stack perché le istanze condividono lo stesso provider di identità.

Identità di Kubernetes e controllo dell'accesso in base al ruolo

Per impostazione predefinita, un cluster Kubernetes non usa lo stesso provider di identità dell'istanza dell'hub di Azure Stack sottostante. Le macchine virtuali che ospitano il cluster Kubernetes, il piano di controllo e i nodi di lavoro usano la chiave SSH specificata quando viene distribuito il cluster. Questa chiave SSH è necessaria per la connessione a questi nodi tramite SSH.

L'API Kubernetes (accessibile, ad esempio, tramite kubectl) è protetta anche dagli account del servizio, incluso un account del servizio di amministrazione del cluster predefinito. Le credenziali per questo account del servizio vengono inizialmente archiviate nel file con estensione kube/config nei nodi del piano di controllo Kubernetes.

Gestione dei segreti e credenziali dell'applicazione

Sono disponibili diverse opzioni per l'archiviazione di segreti come le stringa di connessione e le credenziali del database, tra cui:

• Azure Key Vault
• Segreti di Kubernetes
• Soluzioni di terze parti come HashiCorp Vault (in esecuzione in Kubernetes)

Non archiviare segreti o credenziali in testo normale nei file di configurazione, nel codice dell'applicazione o negli script. E non archiviarli in un sistema di controllo della versione. L'automazione della distribuzione dovrebbe recuperare i segreti se necessario.

Patch e aggiornamento

Il processo di aggiornamento e patch nel servizio Azure Kubernetes è parzialmente automatizzato. Gli aggiornamenti delle versioni di Kubernetes vengono attivati manualmente e gli aggiornamenti della sicurezza vengono applicati automaticamente. Questi aggiornamenti possono includere correzioni di sicurezza del sistema operativo o aggiornamenti del kernel. Il servizio Azure Kubernetes non riavvia automaticamente i nodi Linux per completare il processo di aggiornamento.

Il processo di aggiornamento e patch per un cluster Kubernetes distribuito tramite il motore del servizio Azure Kubernetes nell'hub di Azure Stack non è gestito. È responsabilità dell'operatore del cluster.

Il motore del servizio Azure Kubernetes supporta le due attività più importanti:

• Aggiornamento a una nuova versione di Kubernetes e dell'immagine del sistema operativo di base
• Aggiornamento della sola immagine del sistema operativo di base

Le nuove immagini del sistema operativo di base contengono gli ultimi aggiornamenti di sicurezza e del kernel.

L'utilità di aggiornamento automatico installa automaticamente gli aggiornamenti della sicurezza rilasciati prima che sia disponibile una nuova versione dell'immagine del sistema operativo di base in Azure Stack Hub Marketplace. L'aggiornamento automatico è abilitato per impostazione predefinita e installa automaticamente gli aggiornamenti della sicurezza, ma non riavvia i nodi del cluster Kubernetes. È possibile automatizzare il riavvio del nodo usando il daemon di riavvio di Kubernetes (kured) open source. Il daemon kured controlla i nodi Linux che richiedono un riavvio e quindi gestisce automaticamente la riprogrammazione dei pod in esecuzione e il processo di riavvio del nodo.

Distribuzione (CI/CD)

Azure e l'hub di Azure Stack espongono le stesse API REST di Resource Manager. Queste API vengono affrontate come in qualsiasi altra piattaforma cloud di Azure (Azure, Azure Cina 21Vianet, Azure per enti pubblici). Le varie piattaforme cloud possono usare versioni diverse dell'API e l'hub di Azure Stack fornisce solo un subset di servizi. L'URI dell'endpoint di gestione è diverso anche per ogni piattaforma cloud e per ogni istanza dell'hub di Azure Stack.

Oltre alle sottili differenze indicate, le API REST di Resource Manager offrono un modo coerente per interagire con Azure e l'hub di Azure Stack. È possibile usare lo stesso set di strumenti qui come si farebbe con qualsiasi altra piattaforma cloud di Azure. È possibile usare Azure DevOps, strumenti come Jenkins o PowerShell per distribuire e orchestrare i servizi nell'hub di Azure Stack.

Considerazioni

Una delle principali differenze per le distribuzioni dell'hub di Azure Stack è l'implementazione dell'accessibilità Internet. L'accessibilità a Internet determina se selezionare un agente di compilazione ospitato da Microsoft o self-hosted per i processi CI/CD.

Un agente self-hosted può essere eseguito nell'hub di Azure Stack (come VM IaaS) o in una subnet di rete che può accedere all'hub di Azure Stack. Per altre informazioni sulle differenze, vedere Agenti di Azure Pipelines.

Il grafico di flusso seguente consente di decidere se è necessario un agente di compilazione self-hosted o microsoft:

• È possibile accedere agli endpoint di gestione dell'hub di Azure Stack tramite Internet?
  • Sì: è possibile usare Azure Pipelines con agenti ospitati da Microsoft per connettersi all'hub di Azure Stack.
  • No: sono necessari agenti self-hosted che possono connettersi agli endpoint di gestione dell'hub di Azure Stack.
• È possibile accedere al cluster Kubernetes tramite Internet?
  • Sì: è possibile usare Azure Pipelines con agenti ospitati da Microsoft per interagire direttamente con l'endpoint dell'API Kubernetes.
  • No: sono necessari agenti self-hosted che possono connettersi all'endpoint dell'API del cluster Kubernetes.

Se è possibile accedere agli endpoint di gestione dell'hub di Azure Stack e all'API Kubernetes tramite Internet, la distribuzione può usare un agente ospitato da Microsoft. Questa distribuzione comporta l'architettura dell'applicazione seguente:

Se gli endpoint di Resource Manager, l'API Kubernetes o entrambi non sono accessibili direttamente tramite Internet, è possibile usare un agente di compilazione self-hosted per eseguire i passaggi della pipeline. Questa progettazione richiede meno connettività. Può essere distribuito solo con connettività di rete locale agli endpoint di Resource Manager e all'API Kubernetes:

La soluzione può usare un cluster Kubernetes, distribuito e orchestrato con il motore del servizio Azure Kubernetes, in ogni istanza dell'hub di Azure Stack. Include un'applicazione costituita da un front-end, da un livello intermedio, da servizi back-end (ad esempio MongoDB) e da un controller di ingresso basato su NGINX. Anziché usare un database ospitato nel cluster Kubernetes, è possibile usare archivi dati esterni. Le opzioni di database includono MySQL, SQL Server o qualsiasi tipo di database ospitato all'esterno dell'hub di Azure Stack o in IaaS. Queste configurazioni non rientrano nell'ambito di questo articolo.

Soluzioni partner

È possibile usare le soluzioni partner Microsoft per estendere le funzionalità dell'hub di Azure Stack. Queste soluzioni possono essere utili nelle distribuzioni di applicazioni eseguite nei cluster Kubernetes.

Soluzioni di archiviazione e dati

Come indicato in precedenza, a differenza di Azure, l'hub di Azure Stack non ha attualmente una soluzione nativa per la replica dell'archiviazione tra più istanze. Nell'hub di Azure Stack ogni istanza corrisponde a uno specifico cloud distinto. È tuttavia possibile ottenere soluzioni da partner Microsoft che abilitano la replica di archiviazione tra Hub di Azure Stack e Azure:

• Scality offre l'archiviazione su scala Web. L'archiviazione software-defined di Scality RING trasforma i server x86 in un pool di archiviazione illimitato per qualsiasi tipo di dati, su scala petabyte.
• Cloudian offre un'archiviazione scalabile illimitata che consolida set di dati di grandi dimensioni in un singolo ambiente.

Passaggi successivi

• Panoramica dell'hub di Azure Stack
• Panoramica di Azure Repos
• Panoramica di Azure Pipelines
• Panoramica di Monitoraggio di Azure
• Scalabilità tra cloud nell'hub di Azure Stack
• Modelli di app con distribuzione geografica nell'hub di Azure Stack
• Training: Azure Stack Hub

Risorse correlate

• Architettura di microservizi nel servizio Azure Kubernetes
• Guida alla distribuzione del cluster Kubernetes a disponibilità elevata