Architettura di base per un cluster del servizio Azure Kubernetes (AKS)

Questo articolo fornisce un'architettura dell'infrastruttura di base consigliata per distribuire un cluster del servizio Azure Kubernetes. Usa i principi di progettazione e si basa sulle procedure consigliate per l'architettura del servizio Azure Kubernetes di Azure Well-Architected Framework. Questo articolo illustra più gruppi multidisciplinari distinti, ad esempio team di rete, sicurezza e identità, quando distribuiscono questa infrastruttura per utilizzo generico.

Questa architettura non è incentrata su un carico di lavoro. Si concentra sul cluster del servizio Azure Kubernetes stesso. Queste informazioni sono la baseline minima consigliata per la maggior parte dei cluster del servizio Azure Kubernetes. Si integra con i servizi di Azure che offrono osservabilità, forniscono una topologia di rete che supporta la crescita a più aree e proteggono il traffico all'interno del cluster.

I requisiti aziendali influenzano l'architettura di destinazione e possono variare tra i diversi contesti applicativi. Considera l'architettura come punto di partenza per le fasi di pre-produzione e produzione.

Kubernetes è un potente ecosistema che si estende oltre le tecnologie Di Azure e Microsoft. Quando si distribuisce un cluster del servizio Azure Kubernetes, si prende la responsabilità di numerose decisioni su come progettare e gestire il cluster. L'esecuzione di un cluster del servizio Azure Kubernetes comporta una combinazione di componenti di origine chiusa di diversi fornitori, tra cui Microsoft; e componenti open source dell'ecosistema Kubernetes. Il panorama cambia frequentemente e potrebbe essere necessario rivedere regolarmente le decisioni. Adottando Kubernetes, si riconosce che il carico di lavoro necessita delle sue funzionalità e che il team del carico di lavoro è pronto a investire in modo continuativo.

È possibile usare un'implementazione di questa architettura in GitHub: implementazione di riferimento della baseline del servizio Azure Kubernetes. Usarlo come punto di partenza alternativo e configurare l'architettura di riferimento in base alle esigenze.

Configurazione della rete

Topologia di rete
pianificazione degli indirizzi IP
distribuzione di risorse in ingresso

Elaborazione del cluster

calcolo per il cluster di base
Informazioni di riferimento sull'immagine del contenitore
Gestione dei criteri

Gestione delle identità

Integrare l'ID Microsoft Entra per il cluster
Integrare l'ID Microsoft Entra per il carico di lavoro

Flusso di dati sicuro

protezione del flusso di rete
Aggiungi la gestione dei segreti

Continuità aziendale

Scalabilità
Disponibilità di cluster e nodi
Disponibilità e supporto in più aree

Operazioni

Pipeline CI/CD per cluster e carichi di lavoro
integrità e metriche dei cluster
Gestione dei costi e generazione di report

Topologia di rete

Questa architettura utilizza una topologia di rete hub-and-spoke. Distribuire l'hub e gli spoke in reti virtuali separate connesse tramite peering di rete virtuale. Questa topologia offre diversi vantaggi. Usare questa topologia per:

• Abilita la gestione segregata. È possibile applicare la governance e aderire al principio del privilegio minimo. Supporta anche il concetto di una zona di destinazione di Azure con una separazione dei compiti.

• Ridurre al minimo l'esposizione diretta delle risorse di Azure alla rete Internet pubblica.

• Fornire topologie hub e spoke a livello di area. In futuro è possibile espandere le topologie di rete hub e spoke e fornire l'isolamento del carico di lavoro.

• Usare un servizio web application firewall per controllare il flusso del traffico HTTP per tutte le applicazioni Web.

• Fornire supporto per i carichi di lavoro che si estendono su più sottoscrizioni.

• Rendere estensibile l'architettura. Per supportare nuove funzionalità o carichi di lavoro, è possibile aggiungere nuovi spoke anziché riprogettare la topologia di rete.

• Supportare la condivisione di risorse, ad esempio un firewall e zone DNS (Domain Name System), tra reti.

• Allinearsi alla zona di destinazione su scala aziendale di Azure.

Scaricare un file di Visio di questa architettura.

Per altre informazioni, vedere Topologia di rete hub-spoke in Azure.

Per altre informazioni sulle modifiche alla progettazione di rete incluse nei contenitori di Windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere Contenitori di Windows nel servizio Azure Kubernetes.

Rete virtuale hub

La rete virtuale hub è il punto centrale di connettività e osservabilità. In questa architettura l'hub contiene:

• Firewall di Azure con criteri firewall globali, definiti dai team IT centrali per applicare i criteri firewall a livello di tutta l'organizzazione.
• Azure Bastion per l'accesso remoto alle macchine virtuali (VM).
• Una subnet del gateway per la connettività VPN.
• Monitoraggio di Azure per l'osservabilità della rete.

All'interno della rete, l'architettura ha tre subnet.

Subnet per ospitare Firewall di Azure

Firewall di Azure è un servizio firewall gestito. L'istanza di Firewall di Azure protegge il traffico di rete in uscita. Senza questo livello di sicurezza, il traffico potrebbe comunicare con un servizio dannoso non Microsoft che potrebbe esfiltrare dati sensibili del carico di lavoro. Usare Gestione firewall di Azure per distribuire e configurare centralmente più istanze di Firewall di Azure e gestire i criteri di Firewall di Azure per questo tipo di architettura di rete virtuale hub.

Subnet per ospitare un gateway

Questa subnet è un segnaposto per un gateway VPN o un gateway Azure ExpressRoute. Il gateway fornisce la connettività tra i router nella rete locale e la rete virtuale.

Subnet per ospitare Azure Bastion

Questa subnet è un segnaposto per Azure Bastion. È possibile usare Azure Bastion per accedere in modo sicuro alle risorse di Azure senza esporre le risorse a Internet. Questa subnet è solo per la gestione e le operazioni.

Rete virtuale spoke

La rete virtuale spoke contiene il cluster del servizio Azure Kubernetes e altre risorse correlate. Lo spoke ha le subnet seguenti.

Subnet per ospitare il gateway applicazione di Azure

Il gateway applicazione è un servizio di bilanciamento del carico del traffico Web che opera al livello 7. L'implementazione di riferimento usa lo SKU del gateway applicazione v2 che abilita Web application firewall di Azure. Web Application Firewall protegge il traffico in entrata dagli attacchi comuni al traffico Web, inclusi i bot. L'istanza dispone di una configurazione IP front-end pubblica che riceve le richieste degli utenti. Per impostazione predefinita, il gateway applicazione richiede una subnet dedicata.

Subnet per ospitare le risorse di ingresso

Per instradare e distribuire il traffico, Traefik è il controller di ingresso che soddisfa le risorse di ingresso Kubernetes. I servizi di bilanciamento del carico interno di Azure sono presenti in questa subnet. Per altre informazioni, vedere Utilizzare un bilanciatore di carico interno con AKS.

Subnet per ospitare i nodi del cluster

Il servizio Azure Kubernetes gestisce due pool di nodi, ovvero gruppi separati di nodi. Il pool di nodi di sistema ospita i pod che eseguono i servizi cluster di base. Il pool di nodi utente esegue il carico di lavoro e il controller di ingresso per abilitare la comunicazione in ingresso al carico di lavoro.

Subnet per ospitare gli endpoint di collegamento privato di Azure

Creare connessioni di collegamento privato per Registro Azure Container e Azure Key Vault in modo che gli utenti possano accedere a questi servizi tramite un endpoint privato all'interno della rete virtuale spoke. Non è necessaria una subnet dedicata per gli endpoint privati. È anche possibile inserire endpoint privati nella rete virtuale hub. Nell'implementazione di base, gli endpoint vengono distribuiti in una subnet dedicata all'interno della rete virtuale spoke. Questo approccio riduce il traffico che passa attraverso la connessione di rete con peering. Mantiene le risorse che appartengono al cluster nella stessa rete virtuale. È anche possibile applicare regole di sicurezza granulari a livello di subnet usando i gruppi di sicurezza di rete.

Per ulteriori informazioni, vedere Opzioni di distribuzione del link privato

pianificazione degli indirizzi IP

Scaricare un file di Visio di questa architettura.

Questa architettura di riferimento usa più approcci di rete, ognuno dei quali richiede uno spazio indirizzi IP:

• La rete virtuale di Azure, usata per risorse come nodi del cluster, endpoint privati e gateway applicazione.
• Il cluster usa la sovrimpressione CNI di Azure, che alloca gli indirizzi IP ai pod da uno spazio indirizzi separato alla rete virtuale di Azure.

Spazio indirizzi IP della rete virtuale

Lo spazio degli indirizzi della rete virtuale di Azure deve essere sufficientemente grande da contenere tutte le subnet. Tenere conto di tutte le entità che ricevono il traffico. Kubernetes alloca gli indirizzi IP per tali entità dallo spazio degli indirizzi della subnet. Prendere in considerazione questi punti quando si pianificano gli indirizzi IP della rete virtuale di Azure.

• Aggiornamenti: il servizio Azure Kubernetes aggiorna regolarmente i nodi per assicurarsi che le macchine virtuali sottostanti siano aggiornate sulle funzionalità di sicurezza e su altre patch di sistema. Durante un processo di aggiornamento, il servizio Azure Kubernetes crea un nodo che ospita temporaneamente i pod, mentre il nodo di aggiornamento viene isolato e svuotato. A tale nodo temporaneo viene assegnato un indirizzo IP dalla subnet del cluster. Assicurarsi di disporre di spazio di indirizzi sufficiente per questi indirizzi IP del nodo temporaneo.

  In questa architettura, i pod vengono allocati indirizzi IP dall'interno dello spazio di indirizzi del pod overlay CNI di Azure, incluso durante gli aggiornamenti in sequenza. Questo approccio riduce il numero complessivo di indirizzi IP usati dalla rete virtuale di Azure rispetto ad altri approcci di rete Kubernetes.

• Scalabilità: Prendi in considerazione il numero di nodi di tutti i nodi di sistema e utente e il loro limite massimo di scalabilità. Si supponga di voler aumentare il numero di istanze del 400%. È necessario quattro volte il numero di indirizzi per tutti i nodi con scalabilità orizzontale.

  Poiché questa architettura usa la sovrimpressione CNI di Azure, la scalabilità dei pod non influisce sullo spazio indirizzi della rete virtuale.

• Indirizzi di collegamento privato: tenere conto degli indirizzi necessari per la comunicazione con altri servizi di Azure tramite collegamento privato. A questa architettura sono assegnati due indirizzi per i collegamenti a Registro contenitori e Key Vault.

• Indirizzi IP riservati: Azure riserva determinati indirizzi per i relativi usi. Non possono essere assegnate.

L'elenco precedente non è esaustivo. Se la progettazione include altre risorse che influiscono sul numero di indirizzi IP disponibili, supportare tali indirizzi.

Questa architettura è progettata per un singolo carico di lavoro. In un cluster del servizio Azure Kubernetes di produzione separare sempre il pool di nodi di sistema dal pool di nodi utente. Quando si eseguono più carichi di lavoro nel cluster, è possibile isolare i pool di nodi utente l'uno dall'altro. Quando si esegue questa operazione, si ottengono più subnet di dimensioni inferiori. Inoltre, la risorsa di ingresso potrebbe essere più complessa e, di conseguenza, potrebbero essere necessari più controller di ingresso che richiedono indirizzi IP aggiuntivi.

Spazio di indirizzamento IP del pod

La sovrimpressione CNI di Azure assegna gli indirizzi IP ai pod usando uno spazio indirizzi dedicato, separato dallo spazio indirizzi usato nella rete virtuale. Usare uno spazio indirizzi IP che non si sovrappone alla rete virtuale o alle reti virtuali con peering. Tuttavia, se si creano più cluster del servizio Azure Kubernetes, è possibile usare in modo sicuro lo stesso spazio indirizzi del pod in ogni cluster.

A ogni nodo viene assegnato uno spazio indirizzi /24 per i pod, quindi è importante assicurarsi che lo spazio degli indirizzi del pod sia sufficientemente grande per consentire il numero di blocchi /24 necessari per il numero di nodi nel cluster. Ricordarsi di includere tutti i nodi temporanei creati durante gli aggiornamenti o le operazioni di scalabilità orizzontale. Ad esempio, se si usa uno spazio indirizzi /16 per l'intervallo CIDR, il cluster può raggiungere un massimo di circa 250 nodi.

Ogni nodo supporta fino a 250 pod e questo limite include tutti i pod creati temporaneamente durante gli aggiornamenti.

Per altre informazioni, vedere le indicazioni sulla pianificazione degli indirizzi IP per la sovrimpressione CNI di Azure

Altre considerazioni sullo spazio degli indirizzi IP

Per il set completo di considerazioni sulla rete per questa architettura, vedere Topologia di rete di base del servizio Azure Kubernetes. Per informazioni relative alla pianificazione dell'indirizzamento IP per un cluster del servizio Azure Kubernetes, vedere Pianificare l'indirizzamento IP per il cluster.

Per altre informazioni sulle considerazioni sulla pianificazione degli indirizzi IP incluse nei contenitori di Windows nell'architettura di riferimento della baseline del servizio Azure Kubernetes, vedere Contenitori di Windows nel servizio Azure Kubernetes.

Componenti aggiuntivi e funzionalità di anteprima

Kubernetes e servizio Azure Kubernetes si evolvono continuamente, con cicli di rilascio più veloci rispetto al software per gli ambienti locali. Questa architettura di base dipende dalle funzionalità di anteprima del servizio Azure Kubernetes e dai componenti aggiuntivi del servizio Azure Kubernetes. Ecco la differenza tra le due estensioni:

• Il team del servizio Azure Kubernetes descrive le funzionalità di anteprima fornite e migliorate perché molte delle funzionalità di anteprima rimangono in tale stato solo per alcuni mesi prima di passare alla fase di disponibilità generale .

• I componenti aggiuntivi e le estensioni del servizio Azure Kubernetes offrono funzionalità aggiuntive supportate. Il servizio Azure Kubernetes gestisce l'installazione, la configurazione e il ciclo di vita.

Questa architettura di base non include tutte le funzionalità di anteprima o i componenti aggiuntivi. Include invece solo quelli che aggiungono valore significativo a un cluster per utilizzo generico. Poiché queste funzionalità escono dall'anteprima, questa architettura di base viene modificata di conseguenza. Esistono altre funzionalità di anteprima o componenti aggiuntivi del servizio Azure Kubernetes che è possibile valutare nei cluster di preproduzione. Queste funzionalità possono migliorare la sicurezza, la gestibilità o altri requisiti. Con i componenti aggiuntivi non Microsoft, è necessario installarli e gestirli, inclusi il rilevamento delle versioni disponibili e l'installazione degli aggiornamenti dopo l'aggiornamento della versione kubernetes di un cluster.

Informazioni di riferimento sull'immagine del contenitore

Oltre al carico di lavoro, il cluster potrebbe contenere diverse altre immagini, ad esempio il controller di ingresso. Alcune di queste immagini potrebbero risiedere nei registri pubblici. Prendere in considerazione questi punti quando si esegue il pull delle immagini nel cluster.

• Autenticare il cluster per eseguire il pull dell'immagine.

• Importare un'immagine pubblica nel registro contenitori allineata all'obiettivo del livello di servizio (SLO), se si usa un'immagine pubblica. In caso contrario, l'immagine potrebbe essere soggetta a problemi di disponibilità imprevisti. Se l'immagine non è disponibile quando necessario, ciò può causare problemi operativi. Ecco alcuni vantaggi dell'uso di un registro contenitori privato, ad esempio Registro Azure Container, anziché un registro pubblico:

  • È possibile bloccare l'accesso non autorizzato alle immagini.
  • Non si hanno dipendenze pubbliche.
  • È possibile accedere ai log pull delle immagini per monitorare le attività e valutare i problemi di connettività.
  • È possibile sfruttare i vantaggi dell'analisi integrata dei contenitori e della conformità delle immagini.

• Eseguire il pull delle immagini dai registri autorizzati. È possibile applicare questa restrizione tramite Criteri di Azure. In questa implementazione di riferimento, il cluster esegue solo il pull delle immagini dall'istanza del Registro Container che viene distribuita.

Configurare il calcolo per il cluster di base

Nel servizio Azure Kubernetes ogni pool di nodi viene mappato a un set di scalabilità di macchine virtuali. I nodi sono le macchine virtuali in ogni pool di nodi. Prendere in considerazione l'uso di una dimensione di macchina virtuale inferiore per il pool di nodi di sistema per ridurre al minimo i costi. Questa implementazione di riferimento distribuisce il pool di nodi di sistema con tre nodi DS2_v2. Tale dimensione è sufficiente per soddisfare il carico previsto dei pod di sistema. Il disco del sistema operativo è di 512 GB.

Ecco alcune considerazioni per il pool di nodi utente:

• Scegliere dimensioni del nodo maggiori per accogliere il numero massimo di pod impostati in un nodo. I nodi di grandi dimensioni riducono al minimo l'ingombro dei servizi eseguiti su tutti i nodi, ad esempio il monitoraggio e la registrazione.

• Selezionare il tipo di macchina virtuale appropriato se si hanno requisiti specifici per il carico di lavoro. Ad esempio, potrebbe essere necessario un prodotto ottimizzato per la memoria per alcuni carichi di lavoro o un prodotto con accelerazione GPU per altri. Per altre informazioni, vedere Dimensioni delle macchine virtuali in Azure.

• Distribuire almeno due nodi. In questo modo, il carico di lavoro ha un modello di disponibilità elevata con due repliche. Con il servizio Azure Kubernetes è possibile modificare il numero di nodi senza ricreare il cluster.

• Pianificare le dimensioni effettive dei nodi per il carico di lavoro in base ai requisiti determinati dal team di progettazione. In base ai requisiti aziendali, questa architettura usa DS4_v2 per il carico di lavoro di produzione. Per ridurre i costi, puoi ridurre le dimensioni a DS3_v2, che è la raccomandazione minima.

• Si supponga che il carico di lavoro utilizzi fino all'80% di ogni nodo durante la pianificazione della capacità per il cluster. Il rimanente 20% è riservato ai servizi del servizio Azure Kubernetes.

• Impostare il numero massimo di pod per nodo in base alla pianificazione della capacità. Se si sta tentando di stabilire una linea di base della capacità, iniziare con un valore di 30. Regolare tale valore in base ai requisiti del carico di lavoro, alle dimensioni del nodo e ai vincoli IP.

Selezionare un sistema operativo

La maggior parte dei cluster del servizio Azure Kubernetes usa Linux come sistema operativo per i pool di nodi. In questa implementazione di riferimento si usa Azure Linux, una distribuzione Linux leggera e con protezione avanzata ottimizzata per Azure. È possibile scegliere di usare un'altra distribuzione Linux, ad esempio Ubuntu, se si preferisce o se si hanno requisiti che Azure Linux non può soddisfare.

Il servizio Azure Kubernetes supporta anche i pool di nodi che eseguono il sistema operativo Windows Server. Esistono requisiti speciali per alcuni aspetti di un cluster che esegue Windows. Per altre informazioni sull'architettura del pool di nodi Windows, vedere Esecuzione di contenitori Windows nel servizio Azure Kubernetes.

Se si dispone di un carico di lavoro composto da una combinazione di tecnologie, è possibile usare sistemi operativi diversi in pool di nodi diversi. Tuttavia, se non sono necessari sistemi operativi diversi per il carico di lavoro, è consigliabile usare un unico sistema operativo per tutti i pool di nodi del carico di lavoro.

Integrare Microsoft Entra ID per il cluster

La protezione dell'accesso da e verso il cluster è fondamentale. Pensalo dal punto di vista del cluster quando fai scelte di sicurezza:

• Accesso dall'interno all'esterno. Prendere in considerazione l'accesso del servizio Azure Kubernetes ai componenti di Azure, ad esempio l'infrastruttura di rete, il registro contenitori e l'insieme di credenziali delle chiavi. Autorizzare solo le risorse a cui il cluster deve essere autorizzato ad accedere.
• Accesso dall'esterno all'interno. Fornire l'accesso alle identità al cluster Kubernetes. Autorizzare solo le entità esterne a cui è consentito l'accesso al server API Kubernetes e ad Azure Resource Manager.

Accesso del servizio Azure Kubernetes ad Azure

Esistono due modi per gestire l'accesso del servizio Azure Kubernetes ad Azure tramite Microsoft Entra ID: entità servizio o identità gestite per le risorse di Azure.

Dei due metodi per gestire l'accesso al servizio Azure Kubernetes ad Azure, è consigliabile usare le identità gestite. Con le entità servizio, è necessario gestire e ruotare i segreti, manualmente o a livello di codice. Con le identità gestite, Microsoft Entra ID gestisce ed esegue l'autenticazione e la rotazione tempestiva dei segreti.

È consigliabile abilitare e usare le identità gestite in modo che il cluster possa interagire con le risorse esterne di Azure tramite l'ID Microsoft Entra. Anche se non si usa immediatamente l'integrazione dell'ID Microsoft Entra, è possibile incorporarla in un secondo momento.

Per impostazione predefinita, il cluster utilizza due identità primarie : l'identità del cluster e l'identità kubelet . I componenti del piano di controllo del servizio Azure Kubernetes usano l'identità del cluster per gestire le risorse del cluster, inclusi i servizi di bilanciamento del carico in ingresso e gli indirizzi IP pubblici gestiti dal servizio Azure Kubernetes. L'identità kubelet esegue l'autenticazione con Registro Contenitori. Alcuni componenti aggiuntivi supportano anche l'autenticazione tramite un'identità gestita.

È consigliabile usare le identità gestite quando il cluster deve eseguire il pull delle immagini da un registro contenitori. Questa azione richiede al cluster di ottenere le credenziali del registro. Se non si usa un'identità gestita, è possibile archiviare tali informazioni sotto forma di oggetto segreto Kubernetes e usare imagePullSecrets per recuperare il segreto. Non è consigliabile questo approccio a causa delle complessità della sicurezza. Non solo è necessaria una conoscenza preliminare del segreto, ma è anche necessario archiviare tale segreto all'interno della pipeline DevOps. Un altro motivo per cui non consigliamo questo approccio è il sovraccarico operativo della gestione della rotazione del segreto. Concedere AcrPull invece l'accesso all'identità gestita kubelet del cluster al registro. Questo approccio affronta le preoccupazioni.

In questa architettura, il cluster accede alle risorse di Azure protette da Microsoft Entra ID e il cluster esegue operazioni che supportano le identità gestite. Assegnare il controllo degli accessi in base al ruolo di Azure e le autorizzazioni alle identità gestite del cluster, a seconda delle operazioni eseguite dal cluster. Il cluster esegue l'autenticazione nell'ID Microsoft Entra e quindi gli viene consentito o negato l'accesso in base ai ruoli assegnati. Di seguito sono riportati alcuni esempi di questa implementazione di riferimento in cui i ruoli predefiniti di Azure vengono assegnati al cluster:

• Ruolo di Collaboratore Rete Gestisce la capacità del cluster di controllare la rete virtuale spoke. Con questa assegnazione di ruolo, l'identità assegnata dal sistema del cluster del servizio Azure Kubernetes può funzionare con la subnet dedicata per il servizio controller di ingresso interno.

• Autore delle metriche di monitoraggio Gestisce la capacità del cluster di inviare metriche a Monitoraggio di Azure.

• Ruolo AcrPull. Gestisce la capacità del cluster di eseguire il pull delle immagini dalle istanze di Registro Azure Container specificate.

Accesso al cluster

L'integrazione con Microsoft Entra semplifica anche la sicurezza per l'accesso dall'esterno all'interno. Ad esempio, può essere necessario usare kubectl. Come passaggio iniziale, è possibile eseguire il az aks get-credentials comando per ottenere le credenziali del cluster. L'ID Microsoft Entra autentica l'identità in base ai ruoli di Azure autorizzati a ottenere le credenziali del cluster. Per altre informazioni, vedere Autorizzazioni disponibili per i ruoli del cluster.

Il servizio Azure Kubernetes supporta l'accesso a Kubernetes usando l'ID Microsoft Entra in due modi. Il primo consiste nell'usare l'ID Microsoft Entra come provider di identità integrato con il sistema nativo di controllo degli accessi in base al ruolo di Kubernetes. L'altro metodo usa il controllo degli accessi in base al ruolo di Azure nativo per controllare l'accesso al cluster. Le sezioni seguenti descrivono in dettaglio entrambi gli approcci.

Associare il controllo degli accessi in base al ruolo di Kubernetes con l'ID Microsoft Entra

Kubernetes supporta il controllo degli accessi in base al ruolo tramite:

• Set di autorizzazioni definite usando un Role oggetto o ClusterRole per le autorizzazioni a livello di cluster.

• Associazioni che assegnano utenti e gruppi autorizzati a eseguire le azioni. Definire le associazioni utilizzando un RoleBinding oggetto o ClusterRoleBinding .

Kubernetes include alcuni ruoli predefiniti, ad esempio cluster-admin, modifica e visualizzazione. Associare tali ruoli a utenti e gruppi di Microsoft Entra per usare la directory aziendale per gestire l'accesso. Per altre informazioni, vedere Usare il controllo degli accessi in base al ruolo di Kubernetes con l'integrazione di Microsoft Entra.

Assicurarsi di includere i gruppi di Microsoft Entra per l'accesso al cluster e allo spazio dei nomi nelle verifiche di accesso di Microsoft Entra.

Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione con Kubernetes

Anziché usare il controllo degli accessi in base al ruolo nativo ClusterRoleBindings di Kubernetes e RoleBindings per l'autorizzazione con l'autenticazione integrata di Microsoft Entra, è consigliabile usare il controllo degli accessi in base al ruolo di Azure e le assegnazioni di ruolo di Azure. Questo approccio applica i controlli di autorizzazione nel cluster. È anche possibile assegnare questi ruoli negli ambiti del gruppo di gestione, della sottoscrizione o del gruppo di risorse. Tutti i cluster nell'ambito ereditano quindi un set coerente di assegnazioni di ruolo rispetto a chi ha le autorizzazioni per accedere agli oggetti nel cluster Kubernetes.

Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes.

Account locali

Il servizio Azure Kubernetes supporta l'autenticazione utente nativa di Kubernetes. Non è consigliabile usare questo metodo per fornire agli utenti l'accesso ai cluster. Questo metodo è basato su certificati ed eseguito esternamente al provider di identità primario, che rende difficile il controllo e la governance centralizzati degli accessi utente. Gestire sempre l'accesso al cluster usando Microsoft Entra ID e configurare il cluster per disabilitare in modo esplicito l'accesso all'account locale.

In questa implementazione di riferimento, l'accesso degli account cluster locali viene disabilitato in modo esplicito quando il sistema distribuisce il cluster.

Integrare l'ID Microsoft Entra per il carico di lavoro

Analogamente alla presenza di un'identità gestita assegnata dal sistema di Azure per l'intero cluster, è possibile assegnare identità gestite a livello di pod. Un'identità del carico di lavoro consente al carico di lavoro ospitato di accedere alle risorse tramite Microsoft Entra ID. Ad esempio, il carico di lavoro archivia i file in Archiviazione di Azure. Quando deve accedere a tali file, il pod si autentica sulla risorsa come identità gestita di Azure.

In questa implementazione di riferimento, ID dei carichi di lavoro di Microsoft Entra nel servizio Azure Kubernetes fornisce le identità gestite per i pod. Questo approccio si integra con le funzionalità native di Kubernetes per la federazione con provider di identità esterni. Per altre informazioni sulla federazione ID dei carichi di lavoro di Microsoft Entra, vedere Federazione delle identità del carico di lavoro.

Selezionare un modello di rete

Il servizio Azure Kubernetes supporta più modelli di rete, tra cui kubenet, CNI e Azure CNI Overlay. I modelli CNI sono i modelli più avanzati e sono altamente efficienti. Quando si comunica tra pod, le prestazioni di CNI sono simili alle prestazioni delle macchine virtuali in una rete virtuale. CNI offre anche un controllo di sicurezza avanzato perché consente l'uso dei criteri di rete di Azure. È consigliabile un modello di rete basato su CNI.

Nel modello CNI non sovrapposto ogni pod ottiene un indirizzo IP dallo spazio indirizzi della subnet. Le risorse all'interno della stessa rete (o risorse con peering) possono accedere ai pod direttamente tramite il relativo indirizzo IP. Nat (Network Address Translation) non è necessario per il routing del traffico.

In questa implementazione di riferimento viene usata la sovrimpressione CNI di Azure, che alloca solo gli indirizzi IP della subnet del pool di nodi per i nodi e usa un livello di sovrimpressione altamente ottimizzato per gli indirizzi IP dei pod. Poiché la sovrimpressione CNI di Azure usa meno indirizzi IP di rete virtuale rispetto a molti altri approcci, è consigliabile per le distribuzioni con vincoli di indirizzi IP.

Per informazioni sui modelli, vedere Scegliere un modello di rete dell'interfaccia di rete del contenitore da usare e Confrontare i modelli di rete kubenet e Azure Container Networking Interface.

distribuzione di risorse in ingresso

Le risorse in ingresso kubernetes gestiscono il routing e la distribuzione per il traffico in ingresso al cluster. Esistono due parti delle risorse di ingresso:

• Servizio di bilanciamento del carico interno, gestito dal servizio Azure Kubernetes. Il servizio di bilanciamento del carico espone il controller di ingresso tramite un indirizzo IP statico privato. Funge da singolo punto di contatto che riceve flussi in ingresso.

  Questa architettura usa Azure Load Balancer. Load Balancer si trova all'esterno del cluster in una subnet dedicata per le risorse in ingresso. Riceve il traffico da gateway applicazione e tale comunicazione è tramite tls (Transport Layer Security). Per altre informazioni sulla crittografia TLS per il traffico in ingresso, vedere Flusso del traffico in ingresso.

• Controller di ingressoò. In questo esempio viene usato Traefik. Viene eseguito nel pool di nodi utente nel cluster. Riceve il traffico dal servizio di bilanciamento del carico interno, termina TLS e lo inoltra ai pod del carico di lavoro tramite HTTP.

Il controller di ingresso è un componente critico del cluster. Quando si configura questo componente, tenere presente quanto segue.

• Vincolare il controller di ingresso a un ambito specifico di operazioni come parte delle decisioni di progettazione. Ad esempio, è possibile consentire al controller di interagire solo con i pod che eseguono un carico di lavoro specifico.

• Evitare di posizionare le repliche nello stesso nodo per distribuire il carico e garantire la continuità aziendale in caso di errore di un nodo. Usare podAntiAffinity a questo scopo.

• Vincolare i pod per essere pianificati solo nel pool di nodi utente tramite nodeSelectors. Questa impostazione isola i pod di sistema e del carico di lavoro.

• Aprire porte e protocolli che consentono a entità specifiche di inviare traffico al controller di ingresso. In questa architettura Traefik riceve solo il traffico da gateway applicazione.

• Configurare readinessProbe e livenessProbe le impostazioni che monitorano l'integrità dei pod in base all'intervallo specificato. Il controller di ingresso deve inviare segnali che indicano l'integrità dei pod.

• È consigliabile limitare l'accesso del controller in ingresso a risorse specifiche e la possibilità di eseguire determinate azioni. È possibile implementare tale restrizione tramite le autorizzazioni di controllo degli accessi in base al ruolo di Kubernetes. In questa architettura, ad esempio, a Traefik vengono concesse le autorizzazioni per controllare, ottenere ed elencare i servizi e gli endpoint usando regole nell'oggetto Kubernetes ClusterRole .

Per altre informazioni sulla progettazione in ingresso per i contenitori windows nel servizio Azure Kubernetes nell'architettura di riferimento di base, vedere Contenitori di Windows nel servizio Azure Kubernetes.

Impostazioni router

Il controller di ingresso usa route per determinare dove inviare il traffico. Le route specificano la porta di origine in cui viene ricevuto il traffico e le informazioni sulle porte e i protocolli di destinazione.

Ecco un esempio di questa architettura:

Traefik usa il provider Kubernetes per configurare le route. Le annotationsopzioni , tlse entrypoints indicano che le route vengono gestite tramite HTTPS. L'opzione middlewares specifica che è consentito solo il traffico proveniente dalla subnet gateway applicazione. Le risposte usano la codifica gzip se il client accetta. Poiché Traefik esegue la terminazione TLS, la comunicazione con i servizi back-end è tramite HTTP.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

protezione del flusso di rete

In questa architettura il flusso di rete include:

• Traffico in ingresso dal client al carico di lavoro in esecuzione nel cluster.

• Traffico in uscita da un pod o da un nodo del cluster a un servizio esterno.

• Traffico da pod a pod tra pod. Questo traffico include la comunicazione tra il controller di ingresso e il carico di lavoro. Se il carico di lavoro è composto da più applicazioni distribuite nel cluster, anche la comunicazione tra tali applicazioni rientra in questa categoria.

• Traffico di gestione tra il client e il server API Kubernetes.

Scaricare un file di Visio di questa architettura.

Questa architettura offre diversi livelli di sicurezza per proteggere tutti i tipi di traffico.

Flusso del traffico in ingresso

L'architettura accetta dal client solo richieste crittografate TLS. TLS v1.2 è la versione minima consentita con un set limitato di crittografie. La corrispondenza rigorosa SNI (Server Name Indication) è abilitata. TLS end-to-end viene configurato tramite gateway applicazione usando due certificati TLS diversi, come illustrato nel diagramma seguente.

Scaricare un file di Visio di questa architettura.

1. Il client invia una richiesta HTTPS al nome di dominio: bicycle.contoso.com. Tale nome è associato a un record A DNS all'indirizzo IP pubblico del gateway applicazione. Questo traffico viene crittografato per garantire che il traffico tra il browser client e il gateway non possa essere ispezionato o modificato.

2. Il gateway applicazione dispone di un firewall per applicazioni Web integrato e negozia l'handshake TLS bicycle.contoso.com, consentendo solo crittografie sicure. gateway applicazione è un punto di terminazione TLS, importante perché il web application firewall di gateway applicazione deve esaminare la risposta in testo non crittografato. Certificato TLS nell'insieme di credenziali delle chiavi. Il cluster vi accede con un'identità gestita assegnata dall'utente integrata con il gateway applicazione. Per altre informazioni, vedere Terminazione TLS con certificati di Key Vault.

   gateway applicazione elabora le regole di ispezione del web application firewall ed esegue regole di routing che inoltrano il traffico al back-end configurato.

3. Quando il traffico si sposta dal gateway applicazione al back-end, viene crittografato di nuovo con un altro certificato TLS, che è un carattere *.aks-ingress.contoso.com jolly, poiché viene inoltrato al servizio di bilanciamento del carico interno. Questa ricrittografia consente di garantire che il traffico non protetto non venga trasmesso nella subnet del cluster.

4. Il controller di ingresso riceve il traffico crittografato tramite il servizio di bilanciamento del carico. Il controller è un altro punto di terminazione TLS e *.aks-ingress.contoso.com inoltra il traffico ai pod del carico di lavoro tramite HTTP. I certificati vengono archiviati in Key Vault e il driver CSI (Container Storage Interface) li monta nel cluster. Per altre informazioni, vedere Aggiungere un segreto di gestione.

È possibile implementare il traffico TLS end-to-end a ogni hop attraverso il pod del carico di lavoro. Assicurarsi di misurare le prestazioni, la latenza e gli effetti operativi quando si decide di proteggere il traffico da pod a pod. Per la maggior parte dei cluster a tenant singolo, con il controllo degli accessi in base al ruolo appropriato e procedure mature per il ciclo di vita dello sviluppo software, è sufficiente crittografare TLS fino al controller di ingresso e proteggere con Web Application Firewall. Questo approccio riduce al minimo il sovraccarico nella gestione e nell'overhead del carico di lavoro a causa di prestazioni di rete scarse. I requisiti di conformità e carico di lavoro determinano dove si esegue la terminazione TLS.

Flusso del traffico in uscita

In questa architettura è consigliabile che tutto il traffico in uscita dal cluster comunichi tramite Firewall di Azure. In alternativa, è possibile usare un'appliance virtuale di rete simile. Non è consigliabile usare altre opzioni di uscita, ad esempio il gateway NAT di Azure o un proxy HTTP perché non forniscono l'ispezione del traffico di rete. Per il controllo Zero Trust e la possibilità di controllare il traffico, tutto il traffico in uscita dal cluster passa attraverso il firewall. È possibile implementare questa configurazione con route definite dall'utente . NextHopIpAddress: specifica l'indirizzo IP dell'hop successivo della route valida. Firewall di Azure decide se bloccare o consentire il traffico in uscita. Tale decisione si basa sulle regole specifiche definite in Firewall di Azure o sulle regole di intelligence sulle minacce predefinite.

Un'alternativa a Firewall di Azure consiste nell'usare la funzionalità proxy HTTP del servizio Azure Kubernetes. Tutto il traffico che lascia il cluster passa all'indirizzo IP del proxy HTTP, che inoltra il traffico o lo elimina.

Per entrambi i metodi, esaminare le regole di traffico di rete in uscita necessarie per il servizio Azure Kubernetes.

Un'eccezione al controllo Zero Trust è quando il cluster deve comunicare con altre risorse di Azure. Ad esempio, il cluster potrebbe dover eseguire il pull di un'immagine aggiornata dal registro contenitori o dai segreti di Key Vault. In questi scenari è consigliabile usare collegamento privato. Il vantaggio è che le subnet specifiche raggiungono direttamente il servizio e il traffico tra il cluster e i servizi non passa tramite Internet. Uno svantaggio è che collegamento privato richiede una configurazione aggiuntiva anziché usare il servizio di destinazione sull'endpoint pubblico. Inoltre, non tutti i servizi o i prodotti di Azure supportano collegamento privato. Per questi casi, è consigliabile abilitare un endpoint servizio di rete virtuale nella subnet per accedere al servizio.

Se collegamento privato o gli endpoint di servizio non sono un'opzione, è possibile raggiungere altri servizi tramite gli endpoint pubblici e controllare l'accesso tramite le regole di Firewall di Azure e il firewall integrato nel servizio di destinazione. Poiché questo traffico passa attraverso gli indirizzi IP statici del firewall, è possibile aggiungere tali indirizzi all'elenco indirizzi IP consentiti del servizio. Uno svantaggio è che Firewall di Azure quindi richiede più regole per assicurarsi che consenta solo il traffico da una subnet specifica. Tenere conto di questi indirizzi quando si pianificano più indirizzi IP per il traffico in uscita con Firewall di Azure. In caso contrario, è possibile raggiungere l'esaurimento delle porte. Per altre informazioni sulla pianificazione di più indirizzi IP, vedere Creare un Firewall di Azure con più indirizzi IP.

Per informazioni sulle considerazioni sull'uscita specifiche di Windows nei contenitori Windows nell'architettura di riferimento di base del servizio Azure Kubernetes, vedere Contenitori di Windows nel servizio Azure Kubernetes.

Traffico da pod a pod

Per impostazione predefinita, un pod può accettare il traffico da qualsiasi altro pod nel cluster. Usare Kubernetes NetworkPolicy per limitare il traffico di rete tra pod. Applicare i criteri in modo succoso o si potrebbe avere una situazione in cui un flusso di rete critico è bloccato. Consentire solo percorsi di comunicazione specifici, in base alle esigenze, ad esempio il traffico tra il controller di ingresso e il carico di lavoro. Per altre informazioni, vedere Criteri di rete.

Abilitare i criteri di rete quando si effettua il provisioning del cluster perché non è possibile aggiungerlo in un secondo momento. Sono disponibili alcune opzioni per le tecnologie che implementano NetworkPolicy. È consigliabile usare i criteri di rete di Azure, che richiedono l'interfaccia di rete di Azure Container. Per altre informazioni, vedere le note seguenti. Altre opzioni includono i criteri di rete Calico, un'opzione open source nota. Prendere in considerazione Calico se è necessario gestire i criteri di rete a livello di cluster. Calico non è coperto da supporto tecnico di Azure standard.

Per altre informazioni, vedere Differenze tra i motori dei criteri di rete di Azure.

Gestione del traffico

Nell'ambito dell'esecuzione del cluster, il server API Kubernetes riceve traffico dalle risorse che vogliono eseguire operazioni di gestione nel cluster, ad esempio le richieste di creazione di risorse per ridimensionare il cluster. Esempi di queste risorse includono il pool di agenti di compilazione in una pipeline DevOps, un'istanza di Azure Bastion all'interno della subnet di Azure Bastion e i pool di nodi stessi. Anziché accettare questo traffico di gestione da tutti gli indirizzi IP, usare la funzionalità intervalli IP autorizzati dal servizio Azure Kubernetes per consentire solo il traffico dagli intervalli IP autorizzati al server API

Per altre informazioni, vedere Definire intervalli IP autorizzati dal server API.

Per un altro livello di controllo, a costo di complessità aggiuntiva, è possibile effettuare il provisioning di un cluster del servizio Azure Kubernetes privato. Utilizzando un cluster privato, puoi garantire che il traffico di rete tra il tuo server API e i tuoi pool di nodi rimanga esclusivamente sulla rete privata e non sia mai esposto a Internet. Per altre informazioni, vedere Costruttori privati AKS.

Aggiungi la gestione dei segreti

Archiviare i segreti in un archivio chiavi gestito, ad esempio Key Vault. Il vantaggio è che un archivio chiavi gestito gestisce la rotazione dei segreti. Fornisce una crittografia avanzata e un log di controllo di accesso. Mantiene anche i segreti principali dalla pipeline di distribuzione. In questa architettura viene abilitato e configurato un firewall di Key Vault e collegamento privato viene usato per la connessione da risorse in Azure che devono accedere a segreti e certificati.

Key Vault è ben integrato con altri servizi di Azure. Usare la funzionalità predefinita di tali servizi per accedere ai segreti. Per altre informazioni su come gateway applicazione accede ai certificati TLS per il flusso di ingresso, vedere la sezione Flusso del traffico in ingresso.

Il modello di autorizzazione controllo degli accessi in base al ruolo di Azure per Key Vault consente di assegnare le identità del carico di lavoro all'utente dei segreti dell'insieme di credenziali delle chiavi o all'assegnazione del ruolo lettore dell'insieme di credenziali delle chiavi e di accedere ai segreti. Per altre informazioni, vedere Accedere a Key Vault tramite RBAC.

Accedere ai segreti del cluster

È necessario usare le identità del carico di lavoro per consentire a un pod di accedere ai segreti da un archivio specifico. Per facilitare il processo di recupero, usare un driver CSI dell'archivio segreti. Quando il pod richiede un segreto, il driver si connette all'archivio specificato, recupera un segreto in un volume e monta tale volume nel cluster. Il pod può quindi ottenere il segreto dal file system del volume.

Il driver CSI include molti provider per supportare vari archivi gestiti. Questa implementazione usa Key Vault con il driver CSI dell'archivio segreti. Il componente aggiuntivo recupera il certificato TLS da Key Vault e carica il driver nel pod che esegue il controller di ingresso. Questa operazione si verifica durante la creazione del pod e il volume archivia sia le chiavi pubbliche che le chiavi private.

Archiviazione del carico di lavoro

Il carico di lavoro in questa architettura è senza stato. Se è necessario archiviare lo stato, è consigliabile salvarlo in modo permanente all'esterno del cluster. Le linee guida per lo stato del carico di lavoro non rientrano nell'ambito di questo articolo.

Per altre informazioni, vedere Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes.

Gestione dei criteri

Un modo efficace per gestire un cluster del servizio Azure Kubernetes consiste nell'applicare la governance tramite i criteri. Kubernetes implementa i criteri tramite Open Policy Agent (OPA) Gatekeeper. Per il servizio Azure Kubernetes, distribuire i criteri tramite Criteri di Azure. Ogni criterio si applica a tutti i cluster nel relativo ambito. OPA Gatekeeper gestisce l'applicazione dei criteri nel cluster e registra tutti i controlli dei criteri. Le modifiche ai criteri non vengono immediatamente riflesse nel cluster, quindi si aspettano alcuni ritardi.

Per gestire i cluster del servizio Azure Kubernetes, è possibile usare Criteri di Azure per:

• Impedire o limitare la distribuzione dei cluster del servizio Azure Kubernetes in un gruppo di risorse o una sottoscrizione. Applicare gli standard per l'organizzazione. Ad esempio, è possibile seguire una convenzione di denominazione o specificare un tag.
• Proteggere il cluster del servizio Azure Kubernetes tramite Criteri di Azure per Kubernetes.

Quando si impostano i criteri, applicarli in base ai requisiti del carico di lavoro. Tenere presente questi fattori:

• Si vuole impostare una raccolta di criteri, denominata anche iniziative o scegliere singoli criteri? Criteri di Azure offre due iniziative predefinite: di base e limitate. Ogni iniziativa è una raccolta di criteri predefiniti applicabili a un cluster del servizio Azure Kubernetes. È consigliabile selezionare un'iniziativa e scegliere altri criteri per il cluster e le risorse, ad esempio Registro Contenitori, gateway applicazione o Key Vault, che interagiscono con il cluster. Scegliere i criteri in base ai requisiti dell'organizzazione.

• Controllare o negare l'azione? In modalità di controllo l'azione è consentita ma contrassegnata come non conforme. Disporre di processi per controllare gli stati non conformi a una frequenza regolare e intraprendere le azioni necessarie. In modalità Nega l'azione viene bloccata perché viola i criteri. Prestare attenzione quando si sceglie questa modalità, perché può essere troppo restrittiva per il funzionamento del carico di lavoro.

• Sono presenti aree nel carico di lavoro che non devono essere conformi in base alla progettazione? Criteri di Azure ha la possibilità di specificare spazi dei nomi Kubernetes esentati dall'imposizione dei criteri. È consigliabile applicare i criteri in modalità di controllo in modo che siano a conoscenza di tali istanze.

• Sono previsti requisiti non coperti dai criteri predefiniti? È possibile creare una definizione di Criteri di Azure personalizzata che applica i criteri personalizzati di OPA Gatekeeper. Non applicare criteri personalizzati direttamente al cluster. Per altre informazioni, vedere Creare e assegnare definizioni di criteri personalizzate.

• Sono previsti requisiti a livello di organizzazione? In tal caso, aggiungere tali criteri a livello di gruppo di gestione. Il cluster deve anche assegnare criteri specifici del carico di lavoro, anche se l'organizzazione dispone di criteri generici.

• Si assegnano criteri di Azure a ambiti specifici? Assicurarsi che i criteri di produzione vengano convalidati anche nell'ambiente di preproduzione . In caso contrario, quando si esegue la distribuzione nell'ambiente di produzione, è possibile che si verifichino restrizioni aggiuntive impreviste che non si tiene conto della preproduzione.

Questa implementazione di riferimento abilita Criteri di Azure quando viene creato il cluster del servizio Azure Kubernetes. L'iniziativa restrittiva viene assegnata in modalità di controllo per ottenere visibilità sulla non conformità.

L'implementazione imposta anche criteri aggiuntivi che non fanno parte di alcuna iniziativa predefinita. Questi criteri vengono impostati in modalità Deny. È ad esempio disponibile un criterio per assicurarsi che le immagini vengano estratte solo dall'istanza distribuita del Registro Container. Prendere in considerazione la creazione di iniziative personalizzate. Combinare i criteri applicabili per il carico di lavoro in una singola assegnazione.

Per osservare come Criteri di Azure funzioni dall'interno del cluster, è possibile accedere ai log dei pod per tutti i pod nello spazio dei gatekeeper-system nomi e i log per i azure-policy pod e azure-policy-webhook nello spazio dei kube-system nomi .

Per altre informazioni sulle considerazioni sulle Criteri di Azure specifiche di Windows, vedere l'articolo Sulla gestione dei criteri del servizio Azure Kubernetes.

Scalabilità di nodi e pod

Con l'aumento della domanda, Kubernetes può aumentare il numero di istanze aggiungendo più pod ai nodi esistenti, tramite la scalabilità automatica orizzontale dei pod. Quando Kubernetes non è più in grado di pianificare più pod, il numero di nodi deve essere aumentato tramite la scalabilità automatica del cluster del servizio Azure Kubernetes. Una soluzione di scalabilità completa deve avere la possibilità di ridimensionare sia le repliche dei pod che il numero di nodi del cluster.

Esistono due approcci: il ridimensionamento automatico o il ridimensionamento manuale.

Sia la scalabilità automatica che l'approccio manuale richiedono di monitorare e impostare avvisi sull'utilizzo della CPU o sulle metriche personalizzate. Per il ridimensionamento dei pod, l'operatore dell'applicazione può aumentare o diminuire il numero di repliche dei pod regolando le ReplicaSet API di Kubernetes. Per il ridimensionamento del cluster, un metodo consiste nel ricevere una notifica quando l'utilità di pianificazione di Kubernetes non riesce. Un altro modo consiste nell’osservare i pod in sospeso nel tempo. È possibile modificare il numero di nodi tramite l'interfaccia della riga di comando di Azure o il portale di Azure.

È consigliabile l'approccio di scalabilità automatica perché alcuni di questi meccanismi manuali sono incorporati nel ridimensionamento automatico.

Come metodo generale, iniziare dai test delle prestazioni con un numero minimo di pod e nodi. Usare questi valori per stabilire le aspettative di base. Usare quindi una combinazione di metriche delle prestazioni e ridimensionamento manuale per individuare colli di bottiglia e comprendere la risposta dell'applicazione al ridimensionamento. Usare infine questi dati per impostare i parametri per la scalabilità automatica. Per altre informazioni su uno scenario di ottimizzazione delle prestazioni con il servizio Azure Kubernetes, vedere Scenario di ottimizzazione delle prestazioni: transazioni aziendali distribuite.

Utilità di scalabilità automatica orizzontale dei pod

L'Horizontal Pod Autoscaler (HPA) è una risorsa Kubernetes che ridimensiona il numero di pod.

Nella risorsa HPA è consigliabile impostare il numero minimo e massimo di repliche. I valori vincolano i limiti di scalabilità automatica.

L'HPA può essere ridimensionato in base all'utilizzo della CPU, all'utilizzo della memoria e alle metriche personalizzate. Viene fornito solo l'utilizzo della CPU. La HorizontalPodAutoscaler definizione specifica i valori di destinazione per le metriche. Ad esempio, la specifica imposta l'utilizzo della CPU di destinazione. Durante l'esecuzione dei pod, il controller HPA utilizza l'API Kubernetes Metrics per controllare l'utilizzo della CPU di ogni pod. Confronta tale valore con l'utilizzo di destinazione e calcola un rapporto. Usa quindi il rapporto per determinare se i pod sono sovrassegnati o sottoallocati. Si affida all’Utilità di pianificazione Kubernetes per assegnare nuovi pod ai nodi o rimuovere pod dai nodi.

Potrebbe verificarsi una race condition in cui HPA controlla prima del completamento di un'operazione di ridimensionamento. Il risultato potrebbe essere un calcolo del rapporto non corretto. Per altre informazioni, vedere Cooldown degli eventi di ridimensionamento.

Se il carico di lavoro è basato su eventi, un'opzione open source comune è la scalabilità automatica guidata dagli eventi di Kubernetes (KEDA). Prendere in considerazione KEDA se un'origine evento, ad esempio una coda di messaggi, determina il carico di lavoro anziché il carico di lavoro associato alla CPU o al limite di memoria. KEDA supporta molte origini eventi o scaler. Usare l'elenco delle origini eventi che KEDA può ridimensionare con i scaler KEDA. L'elenco include il scaler di Monitoraggio di Azure, che è un modo pratico per ridimensionare i carichi di lavoro KEDA in base alle metriche di Monitoraggio di Azure.

Ridimensionamento automatico del cluster

Il componente di scalabilità automatica del cluster è un componente aggiuntivo del servizio Azure Kubernetes che ridimensiona il numero di nodi in un pool di nodi. Aggiungerlo durante il provisioning del cluster. È necessario un componente di scalabilità automatica del cluster separato per ogni pool di nodi utente.

L'utilità di pianificazione Kubernetes attiva il ridimensionamento automatico del cluster. Quando l’Utilità di pianificazione Kubernetes non riesce a pianificare un pod a causa di vincoli di risorse, il ridimensionamento automatico effettua automaticamente il provisioning di un nuovo nodo nel pool di nodi. Viceversa, il ridimensionamento automatico del cluster controlla la capacità inutilizzata dei nodi. Se il nodo non è in esecuzione alla capacità prevista, i pod vengono spostati in un altro nodo e il nodo inutilizzato viene rimosso.

Quando si abilita il ridimensionamento automatico, impostare il numero massimo e minimo di nodi. I valori consigliati dipendono dalle prestazioni attese dal carico di lavoro, dalla crescita del cluster e dalle implicazioni economiche. Il numero minimo è la capacità riservata per tale pool di nodi. In questa implementazione di riferimento, il valore minimo è impostato su due a causa della semplicità del carico di lavoro.

Per il pool di nodi di sistema, il valore minimo consigliato è tre.

Per informazioni sulle considerazioni sulla scalabilità specifiche di Windows incluse in questa architettura di riferimento di base, vedere l'articolo Contenitori di Windows nel servizio Azure Kubernetes .

Decisioni di continuità aziendale

Per mantenere la continuità aziendale, definire lo SLO per l'infrastruttura e l'applicazione. Per altre informazioni, vedere Consigli per la definizione degli obiettivi di affidabilità. Esaminare le condizioni del contratto di servizio per il servizio Azure Kubernetes nell'articolo più recente relativo al contratto di servizio per Servizi online.

Nodi del cluster

Per soddisfare il livello minimo di disponibilità per i carichi di lavoro, sono necessari più nodi in un pool di nodi. Se un nodo ha esito negativo, un altro nodo nello stesso pool di nodi e il cluster possono continuare a eseguire l'applicazione. Per garantire l'affidabilità, è consigliabile usare tre nodi per il pool di nodi di sistema. Per il pool di nodi utente, iniziare con almeno due nodi. Se è necessaria una disponibilità più elevata, configurare più nodi.

Isolare l'applicazione dai servizi di sistema inserendola in un pool di nodi separato, denominato pool di nodi utente. In questo modo, i servizi Kubernetes vengono eseguiti in nodi dedicati e non sono in competizione con il carico di lavoro. È consigliabile usare tag, etichette e contaminazioni per identificare il pool di nodi e pianificare il carico di lavoro. Assicurarsi che il pool di nodi di sistema sia tainted con il CriticalAddonsOnly taint.

La manutenzione regolare del cluster, ad esempio gli aggiornamenti tempestivi, è fondamentale per l'affidabilità. È inoltre consigliabile monitorare l'integrità dei pod tramite probe.

Disponibilità di pod

Specificare i requisiti delle risorse dei pod: è consigliabile specificare i requisiti delle risorse dei pod nelle distribuzioni. L'utilità di pianificazione può quindi pianificare in modo appropriato il pod. L'affidabilità è notevolmente ridotta se i pod non possono essere pianificati.

Imposta budget di interruzione dei pod: questa impostazione determina il numero di repliche in una distribuzione che possono essere disattivate durante un evento di aggiornamento o aggiornamento. Per altre informazioni, vedere Budget di interruzione dei pod.

Configurare più repliche nella distribuzione per gestire le interruzioni, ad esempio gli errori hardware. Per gli eventi pianificati, come gli aggiornamenti, un budget per le interruzioni può garantire che esista il numero necessario di repliche di pod per gestire il carico previsto dell'applicazione.

Impostare le quote di risorse negli spazi dei nomi del carico di lavoro: la quota di risorse in uno spazio dei nomi consente di garantire che le richieste e i limiti dei pod siano impostati correttamente in una distribuzione. Per altre informazioni, vedere Applicare le quote di risorse.

Impostare le richieste e i limiti dei pod: l'impostazione di richieste e limiti consente a Kubernetes di allocare in modo efficiente le risorse di CPU e memoria ai pod e di avere una densità di contenitore superiore in un nodo. Le richieste e i limiti possono anche aumentare l'affidabilità riducendo i costi a causa di un utilizzo migliore dell'hardware.

Per stimare i limiti per un carico di lavoro, testare e stabilire una linea di base. Iniziare con valori uguali per le richieste e i limiti. Quindi, regolare gradualmente tali valori fino a quando non viene stabilita una soglia che può causare instabilità nel cluster.

È possibile specificare richieste e limiti nei manifesti della distribuzione. Per altre informazioni, vedere Definire le richieste e i limiti delle risorse pod.

Zone di disponibilità e supporto in più aree

Per proteggersi da alcuni tipi di interruzioni, usare le zone di disponibilità se l'area le supporta. I componenti del piano di controllo e i nodi nei pool di nodi possono quindi essere distribuiti tra le zone. Se un'intera zona non è disponibile, è ancora disponibile un nodo in un'altra zona all'interno dell'area. Ogni pool di nodi esegue il mapping a un set di scalabilità di macchine virtuali separato, che gestisce le istanze del nodo e la scalabilità. Il servizio Servizio Azure Kubernetes gestisce le operazioni e la configurazione dei set di scalabilità. Ecco alcune considerazioni quando si abilitano più zone:

• Intera infrastruttura: scegliere un'area che supporti le zone di disponibilità. Per altre informazioni, vedere: Limitazioni. Per avere un contratto di servizio con tempo di attività, è necessario scegliere il livello Standard o Premium. Il contratto di servizio per il tempo di attività è maggiore quando si usano le zone di disponibilità.

• Cluster: è possibile impostare le zone di disponibilità solo quando si crea il pool di nodi. In seguito non potranno essere modificate. Le dimensioni del nodo devono essere supportate in tutte le zone in modo che sia possibile eseguire la distribuzione prevista. Il set di scalabilità di macchine virtuali sottostante fornisce la stessa configurazione hardware tra le zone.

  Il supporto di più zone non si applica solo ai pool di nodi, ma anche al piano di controllo. Il piano di controllo del servizio Azure Kubernetes si estende sulle zone richieste, ad esempio i pool di nodi. Se non si usa il supporto della zona nel cluster, i componenti del piano di controllo non sono garantiti per la distribuzione tra le zone di disponibilità.

• Dependent resources: per un completo vantaggio zonale, tutte le dipendenze del servizio devono supportare anche le zone Se un servizio dipendente non supporta le zone, è possibile che un errore di zona possa causare un errore del servizio.

  Ad esempio, un disco gestito è disponibile nella zona in cui è stato effettuato il provisioning. Se si verifica un errore, il nodo potrebbe spostarsi in un'altra zona, ma il disco gestito non viene spostato con il nodo in tale zona.

Per semplicità in questa architettura, il servizio Azure Kubernetes viene distribuito in una singola area con pool di nodi che si estendono su zone di disponibilità uno, due e tre. Anche altre risorse dell'infrastruttura, ad esempio Firewall di Azure e gateway applicazione, vengono distribuite nella stessa area con supporto per più zone. La replica geografica è abilitata per Registro Container.

Più aree geografiche

Quando si abilitano le zone di disponibilità, non è sufficiente copertura nel caso improbabile che un'intera area abbia esito negativo. Per ottenere una maggiore disponibilità, eseguire più cluster del servizio Azure Kubernetes in aree diverse.

• Preferisce le aree abbinate quando sono disponibili. Un vantaggio dell'uso delle aree abbinate è l'affidabilità durante gli aggiornamenti della piattaforma. Azure assicura che solo un'area nella coppia venga aggiornata alla volta. Alcune aree non hanno coppie. Se l'area non è abbinata, è comunque possibile distribuire una soluzione in più aree selezionando altre aree da usare. Prendere in considerazione l'uso di una pipeline di integrazione continua e recapito continuo (CI/CD), configurata per orchestrare il ripristino da un errore di area. Alcuni strumenti DevOps, ad esempio Flux, possono semplificare le distribuzioni in più aree.

• Specificare la posizione in cui il servizio ridondante ha la sua istanza secondaria se una risorsa di Azure supporta la ridondanza geografica. Ad esempio, abilitando la replica geografica per Registro Container, le immagini vengono replicate automaticamente nelle aree di Azure selezionate. Fornisce inoltre accesso continuo alle immagini anche se si verifica un'interruzione dell'area primaria.

• Scegliere un router per il traffico in grado di distribuire il traffico tra zone o aree, a seconda delle esigenze. Questa architettura distribuisce Load Balancer perché può distribuire il traffico non Web tra le zone. Se è necessario distribuire il traffico tra aree, è consigliabile usare il servizio Frontdoor di Azure. Per altre opzioni, vedere Scegliere un servizio di bilanciamento del carico.

Ripristino di emergenza

Se si verifica un errore nell'area primaria, idealmente, è possibile creare rapidamente una nuova istanza in un'altra area. Di seguito sono elencati alcuni suggerimenti:

• Utilizzare più aree geografiche. Se l'area primaria ha un'area abbinata, usare tale coppia. In caso contrario, selezionare le aree in base ai requisiti di residenza e latenza dei dati.

• Usare un carico di lavoro non con stato che è possibile replicare in modo efficiente. Se è necessario archiviare lo stato nel cluster, cosa non consigliabile, assicurarsi di eseguire frequentemente il backup dei dati in un'altra area.

• Integrare la strategia di ripristino, ad esempio la replica in un'altra area, come parte della pipeline DevOps per soddisfare lo SLO.

• Effettuare il provisioning di ogni servizio di Azure usando funzionalità che supportano il ripristino di emergenza. In questa architettura, ad esempio, abilitare Registro Azure Container per la replica geografica. Se un'area diventa non disponibile, è comunque possibile eseguire il pull delle immagini dall'area replicata.

• Distribuire l'infrastruttura come codice, incluso il cluster del servizio Azure Kubernetes e tutti gli altri componenti necessari. Se è necessario eseguire la distribuzione in un'altra area, è possibile riutilizzare gli script o i modelli per creare un'istanza identica.

Backup del cluster

Per molte architetture, è possibile effettuare il provisioning di un nuovo cluster e restituirlo allo stato operativo tramite il bootstrap del cluster basato sulle operazioni Git, seguito dalla distribuzione dell'applicazione. Tuttavia, se è presente uno stato critico delle risorse, ad esempio mappe di configurazione, processi e segreti che non possono essere acquisiti all'interno del processo di bootstrap, prendere in considerazione la strategia di ripristino. È consigliabile eseguire carichi di lavoro senza stato in Kubernetes. Se l'architettura prevede lo stato basato su disco, è necessario prendere in considerazione anche la strategia di ripristino per tale contenuto.

Quando il backup del cluster deve far parte della strategia di ripristino, è necessario installare una soluzione che soddisfi i requisiti aziendali all'interno del cluster. Questo agente è responsabile del push dello stato delle risorse del cluster in una destinazione scelta e del coordinamento degli snapshot del volume permanente basati su disco di Azure.

VMware Velero è un esempio di una soluzione di backup kubernetes comune che è possibile installare e gestire direttamente. In alternativa, è possibile usare l'estensione di backup del servizio Azure Kubernetes per fornire un'implementazione gestita di Velero. L'estensione di backup del servizio Azure Kubernetes supporta il backup di risorse Kubernetes e volumi permanenti, con pianificazioni e ambito di backup esternizzati come configurazione dell'insieme di credenziali in Backup di Azure.

L'implementazione di riferimento non implementa il backup, che implica risorse di Azure aggiuntive per gestire, monitorare, acquistare e proteggere. Queste risorse possono includere un account Archiviazione di Azure, un insieme di credenziali e una configurazione Backup di Azure e la funzionalità di accesso attendibile. Le operazioni Git combinate con la finalità di eseguire un carico di lavoro senza stato sono invece la soluzione di ripristino.

Scegliere e convalidare una soluzione di backup che soddisfi l'obiettivo aziendale, incluso l'obiettivo del punto di ripristino definito e l'obiettivo del tempo di ripristino. Definire il processo di ripristino in un runbook del team e praticarlo per tutti i carichi di lavoro critici per l'azienda.

Server API Kubernetes SLA

Il servizio Azure Kubernetes può essere usato come servizio gratuito, ma tale livello non offre un contratto di servizio con copertura finanziaria. Per ottenere un contratto di servizio, è necessario scegliere il livello Standard. È consigliabile che tutti i cluster di produzione usino il livello Standard. Riservare il livello Gratuito per i cluster di preproduzione e il livello Premium solo per carichi di lavoro cruciali . Quando si usano le zone di disponibilità di Azure, il contratto di servizio del server API Kubernetes è superiore. I pool di nodi e altre risorse sono coperti dal proprio contratto di SLA. Per altre informazioni sui contratti di servizio specifici per ogni servizio, vedere Contratto di servizio per Servizi online.

Compromesso

Esiste un compromesso tra costi e disponibilità per la distribuzione dell'architettura tra zone e soprattutto aree. Alcune funzionalità di replica, ad esempio la replica geografica nel Registro Container, sono disponibili in SKU Premium, che è più costoso. Per le distribuzioni in più aree, il costo aumenta anche perché i costi di larghezza di banda si applicano quando il traffico si sposta tra aree.

Inoltre, prevedere una latenza di rete aggiuntiva nella comunicazione tra zone o aree. Misurare l'effetto di questa decisione architetturale sul carico di lavoro.

Eseguire test con simulazioni e failover forzati

Testare l'affidabilità della soluzione tramite test di failover forzato con interruzioni simulate. Le simulazioni possono includere l'arresto di un nodo, l'arresto di tutte le risorse del servizio Azure Kubernetes in una determinata zona per simulare un errore di zona o la chiamata di un errore di dipendenza esterna. È anche possibile usare Azure Chaos Studio per simulare vari tipi di interruzioni in Azure e nel cluster.

Per ulteriori informazioni, vedere Chaos Studio.

Monitorare e raccogliere le metriche

È consigliabile ottenere informazioni dettagliate sui contenitori di Monitoraggio di Azure per monitorare le prestazioni dei carichi di lavoro dei contenitori perché è possibile visualizzare gli eventi in tempo reale. Acquisisce i log dei contenitori dai pod in esecuzione e li aggrega per la visualizzazione. Raccoglie anche informazioni dall'API delle metriche sull'utilizzo della memoria e della CPU per monitorare l'integrità delle risorse e dei carichi di lavoro in esecuzione. È anche possibile usare informazioni dettagliate sui contenitori per monitorare le prestazioni durante la scalabilità dei pod. Include dati di telemetria fondamentali per il monitoraggio, l'analisi e la visualizzazione dei dati raccolti. Informazioni dettagliate sui contenitori identifica le tendenze e consente di configurare l'invio di avvisi per ricevere notifiche proattive sui problemi critici.

La maggior parte dei carichi di lavoro ospitati nei pod genera metriche prometheus. Le informazioni dettagliate sui contenitori possono essere integrate con Prometheus. È possibile visualizzare le metriche dell'applicazione e del carico di lavoro raccolte dai nodi e da Kubernetes.

Alcune soluzioni non Microsoft si integrano con Kubernetes, ad esempio Datadog, Grafana o New Relic. Pertanto, se l'organizzazione usa già queste soluzioni, è possibile sfruttarle.

Con il servizio Azure Kubernetes, Azure gestisce alcuni dei servizi Kubernetes di base. Azure implementa i log per i componenti del piano di controllo del servizio Azure Kubernetes come log delle risorse. È consigliabile abilitare le opzioni seguenti nella maggior parte dei cluster. Le opzioni consentono di risolvere i problemi del cluster e hanno una densità di log relativamente bassa.

• ClusterAutoscaler: ottenere l'osservabilità nelle operazioni di ridimensionamento con la registrazione. Per altre informazioni, vedere Recuperare i log e lo stato del ridimensionamento automatico del cluster.
• KubeControllerManager: ottenere l'osservabilità nell'interazione tra Kubernetes e il piano di controllo di Azure.
• kube-audit-admin: ottenere l'osservabilità nelle attività che modificano il cluster. Non c'è motivo di avere entrambi kube-audit e kube-audit-admin abilitati. kube-audit è un superset di kube-audit-admin che include anche operazioni nonmodifica (lettura).
• guard: acquisire l'ID Microsoft Entra e i controlli RBAC di Azure.

Può essere utile abilitare altre categorie di log, ad esempio KubeScheduler o kube-audit, durante lo sviluppo iniziale del cluster o del ciclo di vita del carico di lavoro. La scalabilità automatica del cluster aggiunta, il posizionamento e la pianificazione dei pod e dati simili consentono di risolvere i problemi relativi alle operazioni del cluster o del carico di lavoro. Tuttavia, se si mantengono i log di risoluzione dei problemi estesi a tempo pieno dopo la fine delle esigenze di risoluzione dei problemi, è possibile che si verifichino costi non necessari per l'inserimento e l'archiviazione dei dati in Monitoraggio di Azure.

Anche se Monitoraggio di Azure include un set di query di log esistenti da iniziare, è anche possibile usarle come base per creare query personalizzate. Man mano che la libreria cresce, è possibile salvare e riutilizzare le query di log usando uno o più Query Pack. La libreria personalizzata di query offre maggiore osservabilità nell'integrità e nelle prestazioni dei cluster del servizio Azure Kubernetes. Supporta il raggiungimento dei contratti di servizio.

Per altre informazioni sulle procedure consigliate di monitoraggio per il servizio Azure Kubernetes, vedere Monitorare il servizio Azure Kubernetes con Monitoraggio di Azure.

Per altre informazioni sulle considerazioni sul monitoraggio specifico di Windows, vedere Contenitori di Windows nel servizio Azure Kubernetes.

Metriche di rete

Le metriche di rete di base a livello di cluster sono disponibili tramite metriche della piattaforma nativa e Prometheus. È anche possibile usare il componente aggiuntivo Network Observability per esporre le metriche di rete a livello di nodo. La maggior parte dei cluster deve usare il componente aggiuntivo Network Observability per fornire funzionalità aggiuntive per la risoluzione dei problemi di rete e per rilevare problemi o utilizzo imprevisto della rete a livello di nodo.

Per i carichi di lavoro altamente sensibili alla perdita di pacchetti TCP (Transmission Control Protocol) o UDP (User Datagram Protocol), alla latenza o alla pressione DNS, le metriche di rete a livello di pod sono importanti. Nel servizio Azure Kubernetes è possibile trovare tale livello di dettaglio con la funzionalità Advanced Network Observability . La maggior parte dei carichi di lavoro non richiede questa profondità di osservabilità della rete. Non è consigliabile installare il componente aggiuntivo Advanced Network Observability a meno che i pod non richiedano una rete altamente ottimizzata, con sensibilità fino al livello di pacchetto.

Abilitare la riparazione automatica

Monitorare l'integrità dei pod impostando probe di attività e conformità. Se Kubernetes rileva un pod che non risponde, riavvia il pod. Un probe di attività determina se il pod è integro. Se Kubernetes rileva un pod che non risponde, riavvia il pod. Un probe di idoneità determina se il pod è pronto per ricevere richieste e traffico.

Aggiornamenti di routine per i cluster del servizio Azure Kubernetes

Parte delle operazioni quotidiane 2 per i cluster Kubernetes consiste nell'eseguire aggiornamenti della piattaforma e del sistema operativo di routine. Esistono tre livelli di aggiornamenti da gestire in ogni cluster del servizio Azure Kubernetes:

• Versione di Kubernetes (ad esempio, Da Kubernetes 1.30.3 a 1.30.7 o Kubernetes da 1.30.7 a 1.31.1), che potrebbe essere disponibile con modifiche e deprecazione dell'API Kubernetes. Le modifiche della versione a questo livello influiscono sull'intero cluster.
• Immagine del disco rigido virtuale (VHD) in ogni nodo, che combina gli aggiornamenti del sistema operativo e gli aggiornamenti dei componenti del servizio Azure Kubernetes. Questi aggiornamenti vengono testati sulla versione kubernetes del cluster. Le modifiche alla versione a questo livello vengono applicate a livello di pool di nodi e non influiscono sulla versione di Kubernetes.
• Processo di aggiornamento nativo del sistema operativo, ad esempio Windows Update o apt. Il fornitore del sistema operativo fornisce questi aggiornamenti direttamente e non vengono testati sulla versione kubernetes del cluster. Le modifiche alla versione a questo livello influiscono su un singolo nodo e non influiscono sulla versione di Kubernetes.

Ognuno di questi livelli è controllato in modo indipendente. Si decide come viene gestito ogni livello per i cluster del carico di lavoro. Scegliere la frequenza con cui ogni cluster del servizio Azure Kubernetes, i relativi pool di nodi o i relativi nodi vengono aggiornati (frequenza). Selezionare anche i giorni o gli orari per applicare gli aggiornamenti (finestra di manutenzione). Scegliere se gli aggiornamenti vengono installati manualmente o automaticamente o meno. Analogamente al carico di lavoro eseguito nel cluster, è necessaria una procedura di distribuzione sicura, quindi eseguire gli aggiornamenti ai cluster.

Per una prospettiva completa sull'applicazione di patch e l'aggiornamento, vedere Le linee guida per l'aggiornamento e le patch del servizio Azure Kubernetes nella guida operativa del servizio Azure Kubernetes day-2. Usare le informazioni seguenti per le raccomandazioni di base correlate a questa architettura.

Infrastruttura non modificabile

I carichi di lavoro che gestiscono i cluster del servizio Azure Kubernetes come infrastruttura non modificabile non aggiornano automaticamente o manualmente i cluster. Impostare l'aggiornamento dell'immagine del nodo su none e l'aggiornamento automatico del cluster su none. In questa configurazione, l'utente è responsabile esclusivamente di tutti gli aggiornamenti a tutti i livelli. Quando diventa disponibile un aggiornamento, è necessario testare l'aggiornamento in un ambiente di preproduzione e valutarne la compatibilità in un nuovo cluster. Successivamente, distribuire un timbro di replica di produzione che include la versione aggiornata del servizio Azure Kubernetes e i dischi rigidi virtuali del pool di nodi. Quando il nuovo cluster di produzione è pronto, il vecchio cluster viene svuotato e alla fine viene rimosso.

L'infrastruttura non modificabile con distribuzioni regolari di nuova infrastruttura è l'unica situazione in cui a un cluster di produzione non deve essere applicata una strategia di aggiornamento sul posto. Tutti gli altri cluster devono avere una strategia di aggiornamento sul posto.

Aggiornamenti sul posto

I carichi di lavoro che non gestiscono cluster del servizio Azure Kubernetes come infrastruttura non modificabile, devono aggiornare regolarmente i cluster in esecuzione per gestire tutti e tre i livelli. Allineare il processo di aggiornamento ai requisiti del carico di lavoro. Usare i suggerimenti seguenti come punto di partenza per progettare il processo di aggiornamento di routine.

• Pianificare la funzionalità di manutenzione pianificata del servizio Azure Kubernetes in modo da poter controllare gli aggiornamenti nel cluster. Questa funzionalità consente di eseguire gli aggiornamenti, un'operazione intrinsecamente rischiosa, in un momento controllato per ridurre l'effetto di un errore imprevisto.
• Configurare budget di interruzione dei pod in modo che l'applicazione rimanga stabile durante gli aggiornamenti in sequenza. Ma non configurare i budget in modo che siano così aggressivi che blocchino l'esecuzione degli aggiornamenti dei nodi, perché la maggior parte degli aggiornamenti richiede un processo di blocco e svuotamento in ogni nodo.
• Verificare la quota delle risorse di Azure e la disponibilità delle risorse. Gli aggiornamenti sul posto distribuiscono nuove istanze di nodi, noti come nodi di picco, prima che i nodi precedenti vengano rimossi. Ciò significa che la quota di Azure e lo spazio indirizzi IP devono essere disponibili per i nuovi nodi. Un valore di aumento del 33% è un buon punto di partenza per la maggior parte dei carichi di lavoro.
• Testare la compatibilità con gli strumenti, ad esempio mesh di servizi o agenti di sicurezza aggiunti al cluster. Testare i componenti del carico di lavoro, ad esempio controller in ingresso, mesh di servizi e pod del carico di lavoro. Eseguire test in un ambiente di preproduzione.

Aggiornamenti sul posto per i nodi

Usare il NodeImage canale di aggiornamento automatico per gli aggiornamenti delle immagini del sistema operativo del nodo. Questo canale configura il cluster per aggiornare il disco rigido virtuale in ogni nodo con gli aggiornamenti a livello di nodo. Microsoft testa gli aggiornamenti rispetto alla versione del servizio Azure Kubernetes. Per i nodi Windows, gli aggiornamenti vengono eseguiti una volta al mese. Per i nodi Linux, questi aggiornamenti vengono eseguiti circa una volta alla settimana.

• Gli aggiornamenti non modificano mai la versione del servizio Azure Kubernetes o Kubernetes, quindi la compatibilità dell'API Kubernetes non è un problema.
• Quando si usa NodeImage come canale di aggiornamento, rispetta la finestra di manutenzione pianificata, che è necessario impostare per almeno una volta alla settimana. Impostarlo indipendentemente dal sistema operativo immagine del nodo usato per garantire un'applicazione tempestiva.
• Questi aggiornamenti includono la sicurezza a livello di sistema operativo, la compatibilità e gli aggiornamenti funzionali, le impostazioni di configurazione del sistema operativo e gli aggiornamenti dei componenti del servizio Azure Kubernetes.
• Le versioni delle immagini e i relativi numeri di versione dei componenti inclusi vengono rilevati usando lo strumento di rilevamento delle versioni del servizio Azure Kubernetes.

Se i requisiti di sicurezza per il cluster richiedono una frequenza di applicazione di patch più aggressiva e il cluster può tollerare le potenziali interruzioni, usare invece il SecurityPatch canale di aggiornamento. Microsoft testa anche questi aggiornamenti. Gli aggiornamenti vengono pubblicati solo se sono presenti aggiornamenti della sicurezza che Microsoft considera sufficientemente importanti da rilasciare prima dell'aggiornamento successivo dell'immagine del nodo pianificata. Quando si usa il SecurityPatch canale, si ottengono anche gli aggiornamenti ricevuti dal NodeImage canale. L'opzione SecurityPatch canale rispetta ancora le finestre di manutenzione, quindi assicurati che la finestra di manutenzione abbia lacune più frequenti (ad esempio ogni giorno o ogni altro giorno) per supportare questi aggiornamenti imprevisti della sicurezza.

La maggior parte dei cluster che eseguono aggiornamenti sul posto deve evitare le opzioni del canale di aggiornamento delle None immagini del nodo e Unmanaged .

Aggiornamenti sul posto al cluster

Kubernetes è una piattaforma in rapida evoluzione e gli aggiornamenti regolari portano importanti correzioni di sicurezza e nuove funzionalità. È importante rimanere aggiornati con gli aggiornamenti di Kubernetes. È consigliabile rimanere entro le due versioni più recenti o N-2. È fondamentale eseguire l'aggiornamento alla versione più recente di Kubernetes perché le nuove versioni vengono rilasciate di frequente.

La maggior parte dei cluster dovrebbe essere in grado di eseguire aggiornamenti delle versioni del servizio Azure Kubernetes sul posto con sufficiente cautela e rigore. Il rischio di eseguire un aggiornamento della versione del servizio Azure Kubernetes sul posto può essere ridotto principalmente tramite test di preproduzione sufficienti, convalida delle quote e configurazione del budget di interruzione dei pod. Tuttavia, qualsiasi aggiornamento sul posto può comportare un comportamento imprevisto. Se gli aggiornamenti sul posto sono considerati troppo rischiosi per il carico di lavoro, è consigliabile usare un approccio di distribuzione blu-verde dei cluster del servizio Azure Kubernetes anziché seguire le raccomandazioni rimanenti .

È consigliabile evitare la funzionalità di aggiornamento automatico del cluster quando si distribuisce per la prima volta un cluster Kubernetes. Usare un approccio manuale, che offre il tempo necessario per testare una nuova versione del cluster del servizio Azure Kubernetes negli ambienti di preproduzione prima che gli aggiornamenti riscontrino l'ambiente di produzione. Questo approccio consente inoltre di ottenere il massimo livello di prevedibilità e controllo. Tuttavia, è necessario essere diligenti sul monitoraggio per i nuovi aggiornamenti alla piattaforma Kubernetes e adottare rapidamente nuove versioni man mano che vengono rilasciate. È preferibile adottare una mentalità "rimanere aggiornata" su un approccio di supporto a lungo termine.

È possibile ricevere notifiche quando è disponibile una nuova versione del servizio Azure Kubernetes per il cluster usando l'argomento del sistema del servizio Azure Kubernetes per Griglia di eventi di Azure. L'implementazione di riferimento distribuisce questo argomento di sistema di Griglia di eventi in modo che sia possibile sottoscrivere l'evento dalla soluzione di notifica del Microsoft.ContainerService.NewKubernetesVersionAvailable flusso di eventi. Esaminare le note sulla versione del servizio Azure Kubernetes per problemi di compatibilità specifici, modifiche del comportamento o deprecazione delle funzionalità.

Alla fine si potrebbe raggiungere il punto di confidenza con le versioni di Kubernetes, le versioni del servizio Azure Kubernetes, il cluster, i relativi componenti a livello di cluster e il carico di lavoro, per esplorare la funzionalità di aggiornamento automatico. Per i sistemi di produzione, sarebbe raro andare oltre patch. Inoltre, quando si aggiorna automaticamente la versione del servizio Azure Kubernetes, controllare anche l'infrastruttura come impostazione della versione del servizio Azure Kubernetes (IaC) per il cluster in modo che non vengano sincronizzate. Configurare la finestra di manutenzione pianificata per supportare l'operazione di aggiornamento automatico.

Monitoraggio della sicurezza

Monitorare l'infrastruttura contenitore sia per le minacce attive che per i potenziali rischi per la sicurezza. Ecco alcune risorse:

• Microsoft Defender per contenitori per identificare e correggere Defender per il cloud raccomandazioni per le immagini del contenitore.
• Defender per contenitori analizza regolarmente le immagini del contenitore alla ricerca di vulnerabilità.
• Defender per contenitori genera anche avvisi di sicurezza in tempo reale per attività sospette.
• Concetti di sicurezza del servizio Azure Kubernetes per applicazioni e cluster informazioni dettagliate sul modo in cui la sicurezza dei contenitori protegge l'intera pipeline end-to-end dalla compilazione ai carichi di lavoro dell'applicazione in esecuzione nel servizio Azure Kubernetes.

Operazioni del cluster e del carico di lavoro

Per considerazioni sulle operazioni su cluster e carichi di lavoro (DevOps), vedere il pilastro dei principi di progettazione dell'eccellenza operativa.

Bootstrapping del cluster

Dopo aver eseguito il provisioning, è disponibile un cluster funzionante, ma potrebbero essere necessari alcuni passaggi prima di poter distribuire i carichi di lavoro. Il processo di preparazione del cluster è denominato bootstrap. Il bootstrap può consistere nella distribuzione di immagini dei prerequisiti nei nodi del cluster, nella creazione di spazi dei nomi e nell'esecuzione di altre attività che soddisfano i requisiti del caso d'uso dell'organizzazione.

Per ridurre il divario tra un cluster con provisioning e uno configurato correttamente, gli operatori del cluster devono considerare l'aspetto del processo di bootstrapping univoco. Devono preparare in anticipo gli asset pertinenti. Ad esempio, se kured è in esecuzione in ogni nodo prima della distribuzione dei carichi di lavoro dell'applicazione è importante, l'operatore del cluster deve verificare che un'istanza del Registro Contenitori contenente l'immagine Kured di destinazione esista già prima di effettuare il provisioning del cluster.

È possibile configurare il processo di bootstrapping utilizzando uno dei seguenti metodi:

• Estensione del cluster GitOps Flux v2
• Pipeline
• Autoconfigurazione con Flux o Argo CD, ad esempio

Uno dei vantaggi principali dell'uso dell'estensione del cluster GitOps Flux v2 per il servizio Azure Kubernetes è che non esiste un divario tra un cluster con provisioning e un cluster con bootstrap. Configura l'ambiente con una solida base di gestione in futuro e supporta anche il bootstrap come modelli di risorse per allinearsi alla strategia IaC.

Infine, quando si usa l'estensione, kubectl non è necessario per nessuna parte del processo di bootstrap. È possibile riservare l'accesso basato su kubectl per situazioni di correzione di emergenza. Tra i modelli per le definizioni di risorse di Azure e il bootstrap dei manifesti tramite l'estensione GitOps, è possibile eseguire tutte le normali attività di configurazione senza la necessità di usare kubectl.

Isolare le responsabilità del carico di lavoro

Dividere il carico di lavoro per team e tipi di risorse per gestire singolarmente ogni parte.

Iniziare con un carico di lavoro di base che contiene i componenti fondamentali e compilarlo. Un'attività iniziale consiste nel configurare la rete. Effettuare il provisioning di reti virtuali per hub e spoke e anche subnet all'interno di tali reti. Ad esempio, uno spoke ha subnet separate per i pool di nodi di sistema e utente e le risorse di ingresso. Distribuire una subnet per Firewall di Azure nell'hub.

Un'altra attività consiste nell'integrare il carico di lavoro di base con Microsoft Entra ID.

Usare IaC

Scegliere un metodo dichiarativo idempotente su un approccio imperativo, laddove possibile. Anziché scrivere una sequenza di comandi che specificano le opzioni di configurazione, usare la sintassi dichiarativa che descrive le risorse e le relative proprietà. È possibile usare Bicep, i modelli di Azure Resource Manager (modelli di Resource Manager) o Terraform.

Assicurarsi di effettuare il provisioning delle risorse in base ai criteri di governance. Ad esempio, quando si selezionano le dimensioni delle macchine virtuali, rimanere entro i vincoli di costo e le opzioni della zona di disponibilità per soddisfare i requisiti dell'applicazione. È anche possibile usare Criteri di Azure per applicare i criteri dell'organizzazione per queste decisioni.

Se è necessario scrivere una sequenza di comandi, usare l'interfaccia della riga di comando di Azure. Questi comandi coprono una gamma di servizi di Azure ed è possibile automatizzarli tramite scripting. Windows e Linux supportano Azure CLI. Un'altra opzione multipiattaforma è Azure PowerShell. La scelta dipende dal set di competenze preferito.

Archiviare e versione gli script e i file modello nel sistema di controllo del codice sorgente.

CI/CD del carico di lavoro

Le pipeline per il flusso di lavoro e la distribuzione devono essere in grado di compilare e distribuire le applicazioni in modo continuo. Gli aggiornamenti devono essere distribuiti in modo sicuro e rapido ed eseguire il rollback in caso di problemi.

La strategia di distribuzione deve includere una pipeline di recapito continuo affidabile e automatizzata. Distribuire automaticamente le modifiche nelle immagini del contenitore del carico di lavoro nel cluster.

In questa architettura GitHub Actions gestisce il flusso di lavoro e la distribuzione. Altre opzioni comuni includono Azure DevOps e Jenkins.

Integrazione continua/distribuzione continua del cluster

Scaricare un file di Visio di questa architettura.

Anziché usare un approccio imperativo come kubectl, usare strumenti che sincronizzano automaticamente le modifiche del cluster e del repository. Per gestire il flusso di lavoro, ad esempio il rilascio di una nuova versione e la convalida in tale versione prima della distribuzione nell'ambiente di produzione, prendere in considerazione un flusso GitOps.

Una parte essenziale del flusso CI/CD consiste nel bootstrap di un cluster appena sottoposto a provisioning. Un approccio GitOps è utile perché consente agli operatori di definire in modo dichiarativo il processo di bootstrapping come parte della strategia IaC e vedere la configurazione riflessa automaticamente nel cluster.

Quando si usa GitOps, un agente viene distribuito nel cluster per assicurarsi che lo stato del cluster sia coordinato con la configurazione archiviata nel repository Git privato. Uno di questi agenti è flux, che usa uno o più operatori nel cluster per attivare le distribuzioni all'interno di Kubernetes. Flux esegue queste attività:

• Esegue il monitoraggio di tutti i repository configurati.
• Rileva le nuove modifiche di configurazione.
• Attivare le distribuzioni.
• Aggiorna la configurazione in esecuzione desiderata in base a tali modifiche.

È anche possibile impostare criteri che regolano la modalità di distribuzione delle modifiche.

Ecco un esempio che illustra come automatizzare la configurazione del cluster con GitOps e Flux:

Scaricare un file di Visio di questa architettura.

1. Uno sviluppatore esegue il commit delle modifiche apportate al codice sorgente, ad esempio i file YAML di configurazione, archiviati in un repository Git. Le modifiche vengono quindi inoltrate a un server Git.

2. Flux viene eseguito in un pod insieme al carico di lavoro. Flux ha accesso in sola lettura al repository Git per assicurarsi che Flux applichi solo le modifiche richieste dagli sviluppatori.

3. Flux riconosce le modifiche nella configurazione e applica tali modifiche usando i comandi kubectl.

4. Gli sviluppatori non hanno accesso diretto all'API Kubernetes tramite kubectl.

È possibile disporre di criteri di ramo nel server Git in modo che più sviluppatori possano quindi approvare le modifiche tramite una richiesta pull prima che la modifica venga applicata all'ambiente di produzione.

Sebbene sia possibile configurare GitOps e Flux manualmente, è consigliabile usare l'estensione del cluster GitOps con Flux v2 per il servizio Azure Kubernetes .

Strategie di distribuzione del carico di lavoro e del cluster

Distribuire qualsiasi modifica, ad esempio componenti dell'architettura, carico di lavoro e configurazione del cluster in almeno un cluster del servizio Azure Kubernetes di preproduzione. In questo modo viene simulata la modifica e potrebbero identificare i problemi prima di essere distribuiti nell'ambiente di produzione.

Esegui test e convalide in ogni fase prima di passare a quella successiva. In questo modo è possibile eseguire il push degli aggiornamenti nell'ambiente di produzione in modo altamente controllato e ridurre al minimo le interruzioni dovute a problemi di distribuzione imprevisti. La distribuzione deve seguire un modello simile a quello di produzione, usando la stessa pipeline di GitHub Actions o gli operatori Flux.

Le tecniche di distribuzione avanzate, ad esempio la distribuzione blu-verde, i test A/B e le versioni canary, richiedono processi aggiuntivi e strumenti potenzialmente aggiuntivi. Flagger è una soluzione open source comune che consente di risolvere scenari di distribuzione avanzati.

Gestione costi

Per iniziare, esaminare l'elenco di controllo per la progettazione dell'ottimizzazione dei costi e l'elenco delle raccomandazioni descritte in Well-Architected Framework for AKS (Framework ben progettato per il servizio Azure Kubernetes). Usare il calcolatore dei prezzi di Azure per stimare il costo dei servizi usati nell'architettura. Per altre procedure consigliate, vedere Ottimizzazione dei costi.

Valutare la possibilità di abilitare l'analisi dei costi di AKS per l'allocazione granulare dei costi dell'infrastruttura del cluster da costrutti specifici di Kubernetes.

Per informazioni sulle considerazioni sulla gestione dei costi specifiche di Windows, vedere Contenitori di Windows nel servizio Azure Kubernetes.

Provisioning

• Comprendere da dove provengono i costi. Esistono costi minimi associati al servizio Azure Kubernetes nella distribuzione, nella gestione e nelle operazioni del cluster Kubernetes stesso. Ciò che influisce sul costo sono le istanze della macchina virtuale, l'archiviazione, i dati di log e le risorse di rete utilizzate dal cluster. Valutare la possibilità di scegliere macchine virtuali più economiche per i pool di nodi di sistema. La serie DS2_v2 è un tipo di macchina virtuale tipico per il pool di nodi di sistema.

• Non avere la stessa configurazione per ambienti di sviluppo/test e produzione. I carichi di lavoro di produzione hanno requisiti aggiuntivi per la disponibilità elevata e sono in genere più costosi. Questa configurazione non è necessaria nell'ambiente di sviluppo/test.

• Aggiungere un contratto di servizio per il tempo di attività per i carichi di lavoro di produzione. Esistono tuttavia risparmi per i cluster progettati per carichi di lavoro di sviluppo/test o sperimentali in cui la disponibilità non è necessaria per essere garantita. Ad esempio, lo SLO è sufficiente. Inoltre, se il carico di lavoro lo supporta, è consigliabile usare pool di nodi spot dedicati che eseguono macchine virtuali spot.

  Per i carichi di lavoro non di produzione che includono database SQL di Azure o app Azure Servizio come parte dell'architettura del carico di lavoro del servizio Azure Kubernetes, valutare se si è idonei a usare le sottoscrizioni di Sviluppo/test di Azure per ricevere sconti sul servizio.

• Effettuare il provisioning di un cluster con il numero minimo di nodi e abilitare il ridimensionamento automatico del cluster per monitorare e prendere decisioni di dimensionamento anziché iniziare con un cluster sovradimensionato per soddisfare le esigenze di ridimensionamento.

• Impostare le richieste e i limiti dei pod per consentire a Kubernetes di allocare le risorse del nodo con densità più elevata in modo da usare l'hardware per la capacità.

• Si consideri che quando si abilita la diagnostica nel cluster, può aumentare il costo.

• Eseguire il commit a istanze di macchine virtuali riservate di Azure di un anno o tre anni per ridurre i costi del nodo se il carico di lavoro deve esistere per un lungo periodo di tempo. Per altre informazioni, vedere Risparmiare sui costi con le istanze di macchina virtuale riservate di Azure.

• Usare i tag quando si creano pool di nodi. I tag consentono di creare report personalizzati per tenere traccia dei costi sostenuti. È possibile usare i tag per tenere traccia delle spese totali ed eseguire il mapping di qualsiasi costo a una risorsa o a un team specifico. Inoltre, se il cluster è condiviso tra team, creare report di chargeback per consumatore per identificare i costi misurati per i servizi cloud condivisi. Per altre informazioni, vedere Specificare un taint, un'etichetta o un tag per un pool di nodi.

• Prevedere costi di larghezza di banda aggiuntivi se il carico di lavoro è in più aree e si replicano i dati tra aree. Per altre informazioni, vedere Dettagli sui prezzi per la larghezza di banda.

• Creare budget per rimanere entro i vincoli di costo identificati dall'organizzazione. È possibile creare budget tramite Gestione costi Microsoft. È anche possibile creare avvisi per ricevere notifiche quando vengono superate determinate soglie. Per ulteriori informazioni, vedere Creare un budget utilizzando un modello.

Monitoraggio

È possibile monitorare l'intero cluster e il costo di calcolo, archiviazione, larghezza di banda, log e firewall. Azure offre opzioni per monitorare e analizzare i costi:

• Azure Advisor

• Gestione dei costi Microsoft

Idealmente, monitorare i costi in tempo reale o almeno una cadenza regolare. È quindi possibile intervenire prima della fine del mese quando i costi sono già calcolati. Inoltre, monitorare le tendenze mensili nel tempo per rimanere nel budget.

Per prendere decisioni basate sui dati, individuare quale risorsa, a livello granulare, comporta il costo più elevato. Inoltre, avere una buona conoscenza dei contatori che calcolano l'utilizzo delle risorse. Ad esempio, analizzando le metriche, è possibile determinare se la piattaforma è sovradimensionata. È possibile visualizzare i contatori di utilizzo nelle metriche di Monitoraggio di Azure.

Ottimizzazione

Azure Advisor offre raccomandazioni per: Ci sono altri modi per ottimizzare:

• Abilitare il ridimensionamento automatico del cluster per rilevare e rimuovere nodi sottoutilati nel pool di nodi.

  Importante

  La modifica aggressiva delle impostazioni del ridimensionamento automatico del cluster, ad esempio le impostazioni minime e massime dei nodi per un pool di nodi, per influire sui costi potrebbe avere risultati controproducenti. Ad esempio, se scale-down-unneeded-time è impostato su 10 minuti e le impostazioni minime e massime dei nodi vengono modificate ogni cinque minuti in base alle caratteristiche del carico di lavoro, il numero di nodi non verrà mai ridotto. Ciò è dovuto al fatto che il calcolo del tempo non necessario per ogni nodo viene reimpostato a causa dell'aggiornamento delle impostazioni di scalabilità automatica del cluster.

• Scegliere uno SKU inferiore per i pool di nodi, se il carico di lavoro lo supporta.

• Se l'applicazione non richiede il ridimensionamento burst, valutare la possibilità di ridimensionare il cluster in base alle dimensioni corrette analizzando le metriche delle prestazioni nel tempo.

• Se il carico di lavoro lo supporta, ridimensionare i pool di nodi utente a 0 nodi quando non è previsto che siano in esecuzione. Inoltre, se non sono stati pianificati carichi di lavoro pianificati per l'esecuzione nel cluster, è consigliabile usare la funzionalità di avvio/arresto del servizio Azure Kubernetes per arrestare tutte le risorse di calcolo, che includono il pool di nodi di sistema e il piano di controllo del servizio Azure Kubernetes.

Per altre informazioni sui costi, vedere Prezzi del servizio Azure Kubernetes.

Passaggi successivi

• Architettura avanzata dei microservizi AKS
• Baseline di AKS per cluster multiarea
• Cluster regolamentato del servizio Azure Kubernetes per PCI-DSS 3.2.1
• Architettura di riferimento per i contenitori Windows nel servizio Azure Kubernetes

Risorse correlate

• Roadmap del servizio Azure Kubernetes in GitHub
• Introduzione a Kubernetes
• Sviluppare e distribuire applicazioni in Kubernetes
• Revisione di WellArchitected Framework per il servizio Azure Kubernetes
• Acceleratore della zona di destinazione
• Guida alle operazioni del secondo giorno servizio Azure Kubernetes
• Architettura di microservizi nel servizio Azure Kubernetes
• Usare Firewall di Azure per proteggere un cluster del servizio Azure Kubernetes
• Operazioni Git per il servizio Azure Kubernetes
• Streaming dei dati con il servizio Azure Kubernetes