Architettura di riferimento di Servizio Azure Kubernetes (AKS) per AKS in Azure Locale

Servizio Azure Kubernetes (AKS)
Azure Locale
Azure Arc

Questo scenario illustra come progettare e implementare un'architettura di base per il servizio Microsoft Azure Kubernetes in esecuzione in Locale di Azure.

Questo articolo include raccomandazioni per la rete, la sicurezza, l'identità, la gestione e il monitoraggio del cluster in base ai requisiti aziendali di un'organizzazione.

Importante

Le informazioni contenute in questo articolo si applicano ad AKS in Azure Locale e ad AKS in Windows Server. La versione più recente di AKS viene eseguita sul sistema operativo Azure Stack HCI, versione 23H2. Per ulteriori informazioni sull'ultima versione, vedi AKS on Azure Locale.

Architettura

Diagramma che mostra un'architettura di base per il servizio Azure Kubernetes in Locale di Azure.

Scaricare un file di Visio di questa architettura.

Componenti

  • I componenti seguenti vengono installati nel perimetro o in locale:

    • Azure Locale è una soluzione cluster HCI (Hyperconverged Infrastructure) che ospita carichi di lavoro Linux e Windows virtualizzati e la relativa archiviazione in un ambiente locale ibrido. Un'istanza locale di Azure è costituita da un cluster che può variare da 1 a 16 nodi. In questa architettura, Azure Locale fornisce l'infrastruttura fisica per eseguire cluster AKS, consentendo capacità di calcolo e archiviazione locali con integrazione con Azure.

    • Il bridge di risorse di Azure Arc è una macchina virtuale a disponibilità elevata in esecuzione in Locale di Azure. In questa architettura, gestisce e distribuisce più cluster AKS su Azure Locale. Funge da piano di controllo per le operazioni ibride di Kubernetes.

    • AKS on Azure Locale è un'implementazione on-premises di AKS che automatizza l'esecuzione su larga scala di applicazioni containerizzate. In questa architettura, ogni cluster AKS in Azure Locale include nodi del piano di controllo a disponibilità elevata e nodi di lavoro. Le applicazioni containerizzate vengono eseguite sui nodi worker nel cluster AKS. Per ottenere l'isolamento applicativo, è possibile distribuire fino a 32 cluster AKS. Il cluster AKS è costituito dai seguenti componenti:

      • Il piano di controllo viene eseguito in Linux di Azure e include i componenti del server API che interagiscono con l'API Kubernetes. Usa anche etcd, ovvero un archivio chiave-valore distribuito, per archiviare tutti i dati e la configurazione del cluster.

      • I nodi di lavoro vengono eseguiti nel sistema operativo Linux di Azure o nel sistema operativo Windows Server. Ospitano applicazioni containerizzate nei pod. I pod rappresentano una singola istanza dell'applicazione e in genere eseguono il mapping uno-a-uno con un contenitore. Tuttavia, alcuni pod includono più contenitori. Le distribuzioni sono costituite da uno o più pod identici. I pod e le distribuzioni sono raggruppati logicamente in uno spazio dei nomi, che definisce l'accesso alla gestione di queste risorse.

  • I componenti seguenti vengono installati in Azure:

    • Azure Arc è un servizio basato sul cloud che estende il modello di gestione basato su Azure Resource Manager alle risorse non di Azure, incluse macchine virtuali non di Azure, cluster Kubernetes e database in contenitori. Questa architettura consente la governance centralizzata, il monitoraggio e l'applicazione dei criteri per i cluster AKS in esecuzione in Azure Locale.

    • Automazione di Azure è un servizio di automazione e configurazione basato sul cloud. Questa architettura supporta una gestione coerente dei cluster AKS e dei carichi di lavoro negli ambienti ibridi tramite flussi di lavoro automatizzati.

    • Monitoraggio di Azure è un servizio basato sul cloud che ottimizza la disponibilità e le prestazioni delle applicazioni e dei servizi offrendo una soluzione completa per la raccolta, l'analisi e l'esecuzione dei dati di telemetria dagli ambienti cloud e locali. In questa architettura, monitora l'integrità e le prestazioni dei cluster AKS e dei carichi di lavoro dei contenitori eseguiti su Azure Locale.

    • Criteri di Azure è un servizio basato sul cloud che consente di applicare gli standard dell'organizzazione e valutare la conformità su larga scala valutando Azure, incluse le risorse abilitate da Azure Arc, alle proprietà di tali risorse alle regole business. In questa architettura Criteri di Azure per Kubernetes applica i criteri ai cluster del servizio Azure Kubernetes e ai carichi di lavoro Kubernetes per garantire procedure di configurazione e sicurezza coerenti.

    • Defender per il cloud è un sistema unificato di gestione della sicurezza dell'infrastruttura che rafforza il comportamento di sicurezza dei data center e fornisce protezione avanzata dalle minacce nei carichi di lavoro ibridi nel cloud e in locale. In questa architettura Defender per il cloud protegge i cluster e i carichi di lavoro del servizio Azure Kubernetes in Locale di Azure monitorando le minacce e applicando le procedure consigliate per la sicurezza.

Dettagli dello scenario

Potenziali casi d'uso

  • Implementa carichi di lavoro ad alta disponibilità basati su container in un'implementazione locale di Kubernetes di AKS.

  • Automatizzare l'esecuzione di applicazioni in contenitori su larga scala.

  • Ridurre il costo totale di proprietà (TCO) usando soluzioni certificate Microsoft, automazione basata sul cloud, gestione centralizzata e monitoraggio centralizzato.

Hardware certificato

Usare l'hardware certificato locale di Azure, che fornisce impostazioni UEFI (Secure Boot, United Extensible Firmware Interface) e Trusted Platform Module (TPM) predefinite. I requisiti di calcolo dipendono dall'applicazione e dal numero totale di nodi del piano di controllo e di lavoro in tutti i cluster AKS eseguiti in Azure Locale. Usare più nodi fisici per la distribuzione di Azure Locale per ottenere una disponibilità elevata. Tutti i server devono essere dello stesso produttore e modello e usare processori di livello Intel Nehalem a 64 bit, AMD EPYC o versioni successive compatibili che supportano la conversione degli indirizzi di secondo livello.

Requisiti di rete

Kubernetes fornisce un livello di astrazione alla rete connettendo i nodi Kubernetes alla rete di sovrapposizione virtuale. Fornisce anche connettività in ingresso e in uscita per i pod tramite il componente kube-proxy .

Questa architettura usa una rete di sovrapposizione virtuale che alloca gli indirizzi IP usando la rete di indirizzi IP statici. Questa architettura usa Calico come provider di interfacce di rete del contenitore. La rete di indirizzi IP statici richiede pool di indirizzi predefiniti per tutti gli oggetti nella distribuzione. Offre vantaggi aggiuntivi e garantisce che il carico di lavoro e l'applicazione siano sempre raggiungibili. Viene usato un pool di indirizzi IP separato per allocare indirizzi IP ai servizi Kubernetes.

Le specifiche di rete sono definite come reti logiche in Locale di Azure. Prima di creare le reti logiche in Locale di Azure, vedere Requisiti di rete e pianificazione degli indirizzi IP.

Requisiti di archiviazione

Per ogni server nel cluster, usare gli stessi tipi di unità con le stesse dimensioni e modello. Azure Locale funziona con l'allegato di tecnologia avanzata seriale collegata direttamente, l'interfaccia di sistema di computer di piccole dimensioni associata seriale, l'express di memoria non volatile o le unità di memoria persistenti collegate fisicamente a un server ciascuno. Per i volumi cluster, HCI usa una tecnologia di archiviazione definita dal software come Spazi di archiviazione diretta per combinare le unità fisiche nel pool di archiviazione al fine di garantire tolleranza agli errori, scalabilità e prestazioni. Le applicazioni eseguite in AKS su Azure Locale spesso richiedono la disponibilità delle seguenti opzioni di archiviazione:

  • I volumi rappresentano un modo per archiviare, recuperare e rendere persistenti i dati tra i pod e il ciclo di vita dell'applicazione.

  • I volumi permanenti sono una risorsa di archiviazione creata e gestita dall'API Kubernetes. Possono esistere oltre il ciclo di vita di un singolo pod.

Valutare la possibilità di definire classi di archiviazione per livelli e posizioni diversi per ottimizzare i costi e le prestazioni. Le classi di archiviazione supportano il provisioning dinamico dei volumi permanenti e definiscono il metodo reclaimPolicy per specificare l'azione della risorsa di archiviazione sottostante per la gestione dei volumi permanenti quando il pod viene eliminato.

Creare e gestire AKS su Azure Locale

È consigliato creare e gestire AKS in Azure Locale come qualsiasi altra risorsa di Azure che gestisci. È possibile usare il portale di Azure, interfaccia della riga di comando di Azure, i template di Azure Resource Manager (template ARM) o Bicep.

Il servizio Kubernetes con Azure Arc abilitato fornisce la rappresentazione di Resource Manager di AKS in un'istanza di Azure Locale. Quando si crea un cluster AKS su Azure Locale, gli agenti di Azure Arc vengono distribuiti automaticamente in un namespace Kubernetes per raccogliere log e metriche e acquisire i metadati del cluster, la versione di Kubernetes e il numero di nodi.

Le raccomandazioni seguenti sono valide per la maggior parte degli scenari. Seguite le raccomandazioni, a meno che non abbiate un requisito specifico che abbia la precedenza su di esse. I seguenti servizi di Azure devono essere distribuiti nella stessa area geografica di Azure del cluster AKS:

  • Usa l'estensione MetalLB per distribuire un bilanciatore del carico MetalLB nel cluster AKS per il bilanciamento del carico L2.

  • Abilitare Monitoraggio di Azure Container Insights per monitorare le prestazioni dei carichi di lavoro dei contenitori eseguiti in pool di nodi Linux e Windows. Raccoglie metriche di memoria e processore da controller, nodi e contenitori tramite l'API Metrica. Usando Container Insights, è possibile identificare l'utilizzo della memoria e del processore, rilevare le prestazioni complessive del cluster Kubernetes, comprendere il comportamento del cluster e configurare gli avvisi per il monitoraggio proattivo.

  • Usare le funzionalità di automazione disponibili per la gestione end-to-end. AKS offre un'ampia gamma di funzionalità di automazione, tra cui aggiornamenti del sistema operativo e aggiornamenti completi dello stack, ad esempio firmware e driver forniti da partner e fornitori di Azure Locale. È possibile eseguire Windows PowerShell in locale da uno dei computer locali di Azure o in remoto da un computer di gestione. L'integrazione con Automazione di Azure e Azure Arc supporta diversi scenari di automazione per carichi di lavoro virtualizzati e in contenitori .

  • Applicare la governance con Criteri di Azure per applicare i controlli delle risorse su larga scala. Criteri di Azure estende le funzionalità di Gatekeeper v3, un webhook di controller di ammissione per Open Policy Agent, per applicare centralmente protezioni ai componenti di AKS, come pod, container e namespace.

  • Distribuisci le applicazioni in modo coerente usando le configurazioni di Flux v2 e Criteri di Azure per Kubernetes per ottenere distribuzioni scalabili governate dai criteri. È possibile selezionare una definizione di criteri predefinita e creare assegnazioni di criteri con parametri specifici per la configurazione di Flux. Per supportare la separazione delle problematiche, creare più assegnazioni con configurazioni Flux diverse che puntano a origini separate, ad esempio un repository Git per gli amministratori del cluster e un altro repository per i team delle applicazioni.

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 Well-Architected Framework.

Affidabilità

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

  • Implementare tre a cinque nodi del piano di controllo e più nodi di lavoro nel cluster Kubernetes per soddisfare i requisiti di disponibilità minimi per le applicazioni.

  • Esaminare i requisiti per il clustering di failover. Le distribuzioni di AKS usano il clustering di failover e la migrazione in tempo reale per l'alta disponibilità e la tolleranza ai guasti. La migrazione in tempo reale è una funzionalità di Hyper-V che consente di spostare in modo trasparente le macchine virtuali in esecuzione da un host Hyper-V a un altro host senza tempi di inattività percepiti.

  • Configurare le distribuzioni per l'uso delle funzionalità di Kubernetes, ad esempio distribuzioni, mapping di affinità e ReplicaSet, per assicurarsi che i pod siano resilienti negli scenari di interruzione.

  • Limitare l’utilizzo di immagini di contenitori pubbliche e scaricare solo dai registri di contenitori per i quali si ha il controllo dell’accordo sul livello di servizio (SLA), ad esempio Registro Azure Container.

Sicurezza

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

Concentrarsi sull'intero stack proteggendo sia l'host che i relativi contenitori.

Sicurezza dell'infrastruttura

  • Usare l'hardware certificato locale di Azure che fornisce impostazioni predefinite di avvio protetto, UEFI e TPM. Queste tecnologie, combinate con la sicurezza basata sulla virtualizzazione, consentono di proteggere i carichi di lavoro sensibili alla sicurezza. Per altre informazioni sulle soluzioni convalidate, vedere Soluzioni locali di Azure.

  • Usare l'avvio protetto per assicurarsi che il server avvii solo il software attendibile da un produttore di apparecchiature originale.

  • Usare UEFI per controllare il processo di avvio del server.

  • Usare TPM per archiviare le chiavi crittografiche e isolare tutte le funzioni correlate alla sicurezza basate su hardware.

  • Usare crittografia unità BitLocker per crittografare i volumi inattivi di Spazi di archiviazione diretta.

  • Usare Defender per il cloud per gestire le impostazioni di sicurezza per server e cluster. Fornisce la protezione dalle minacce per i cluster Kubernetes abilitati per Azure Arc. L'estensione Microsoft Defender per contenitori raccoglie i dati dai nodi del cluster e li invia al back-end Defender per contenitori nel cloud per un'ulteriore analisi.

  • Usare il controllo degli accessi in base al ruolo di Azure (Azure RBAC) per le assegnazioni di ruolo e per gestire l'accesso al cluster AKS.

  • Usare l'identità del carico di lavoro per proteggere e gestire le identità per accedere alle risorse di Azure dai pod del carico di lavoro.

  • AKS include la crittografia dei segreti di etcd tramite un plug-in del servizio di gestione delle chiavi (KMS). Tutti i cluster AKS dispongono di un plug-in KMS integrato abilitato per impostazione predefinita. Questo plug-in genera la chiave di crittografia e la ruota automaticamente ogni 30 giorni.

Sicurezza delle applicazioni

  • Usa l'estensione del provider di Azure Key Vault Secrets nella tua istanza di AKS on Azure Locale per proteggere ulteriormente i secrets usati da diverse applicazioni archiviandoli in Key Vault.

  • Usa Criteri di Azure per Kubernetes per imporre criteri di sicurezza del cluster, ad esempio il divieto di pod con privilegi.

  • Usa un'istanza di registro di container con scansione delle vulnerabilità nel relativo repository di container.

Sicurezza dei contenitori

  • Rafforzare la protezione avanzata dell'ambiente host e del daemon rimuovendo i servizi non necessari.

  • Mantenere i segreti fuori dalle immagini e montarli solo tramite il motore di orchestrazione dei contenitori.

  • Proteggi le immagini in un'istanza di un Container Registry che supporta la scansione delle vulnerabilità e Azure RBAC.

  • Usare l'isolamento dei container ed evitare di eseguire i container in modalità privilegiata per impedire agli attaccanti di ottenere privilegi più elevati se un container viene compromesso.

Ottimizzazione dei 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.

Eccellenza operativa

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

  • Infrastruttura come codice: Usare modelli arm, Bicep o Terraform per automatizzare la distribuzione del cluster su larga scala. Usare il portale di Azure per esplorare le opzioni disponibili e supportate per la creazione del cluster ed esportare le selezioni come modello. Esaminare i moduli verificati di Azure per un'opzione di distribuzione scalabile. Per altre informazioni, vedere il modulo del servizio contenitore ibrido in GitHub.

  • Azure Arc: Eseguire l'integrazione con Azure Arc o i servizi di Azure, ad esempio Monitoraggio di Azure e Log Analytics, che offrono funzionalità di gestione, manutenzione e resilienza aggiuntive.

  • GitOps: Anziché configurare manualmente i componenti Kubernetes, usare strumenti automatizzati per applicare configurazioni a un cluster Kubernetes perché queste configurazioni vengono archiviate in un repository di origine. Questo processo è spesso noto come GitOps. Le soluzioni GitOps comuni per Kubernetes includono Flux e Argo CD. In questa architettura è consigliabile usare l'estensione GitOps fornita da Microsoft, basata su Flux.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

  • Usare l'hardware certificato locale di Azure per migliorare il tempo di attività e le prestazioni delle applicazioni, la gestione e le operazioni semplificate e ridurre il costo totale di proprietà dell'applicazione.

  • Comprendere i limiti di AKS in Azure Locale. Microsoft supporta AKS nelle distribuzioni Azure Locale che hanno un massimo di 16 server fisici per cluster, 32 cluster Kubernetes e 200 macchine virtuali.

  • Determinare i requisiti di AKS in Azure Locale in base al numero di nodi del piano di controllo, nodi di lavoro e cluster AKS. Per dimensionare correttamente l'hardware, stimare il numero di pod, container e nodi worker necessari per ciascun cluster AKS. Riservare almeno 15% di capacità locale di Azure per gestire gli errori pianificati e non pianificati.

    Per garantire l'efficienza delle prestazioni, usare le risorse di calcolo in modo da soddisfare i requisiti di sistema mantenendo tale efficienza man mano che la domanda cambia e le tecnologie si evolvono. Come regola generale, se un nodo passa offline, sia a causa della manutenzione che di un errore imprevisto, i nodi rimanenti devono avere una capacità sufficiente per gestire il carico aumentato.

  • Esaminare la logica di posizionamento dei nodi di AKS. AKS su Azure Locale distribuisce i nodi di lavoro per ogni pool di nodi in un cluster AKS usando la logica di posizionamento di Azure Locale tramite set di disponibilità.

  • Pianifica le prenotazioni degli indirizzi IP per configurare i cluster AKS e i servizi Kubernetes.

  • Implementare l'ottimizzazione delle prestazioni di rete per l'allocazione della larghezza di banda del traffico.

  • Usare l'accelerazione dell'unità di elaborazione grafica per carichi di lavoro estesi.

Collaboratori

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

Autori principali:

Altro collaboratore:

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

Passo successivo