Architettura di base per un cluster Servizio Azure Kubernetes (AKS)

Questo articolo fornisce un'architettura di infrastruttura di base consigliata per distribuire un cluster Servizio Azure Kubernetes (AKS). Segue i principi di progettazione e si allinea alle migliori pratiche architetturali di AKS secondo il framework Azure Well-Architected. L'articolo guida più distinti gruppi interdisciplinari, come i team di rete, sicurezza e identità, quando distribuiscono questa infrastruttura per utilizzo generico.

Questa architettura non si concentra 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 Azure servizi che offrono osservabilità, forniscono una topologia di rete che supporta la crescita a più aree e il traffico in cluster sicuro.

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

Kubernetes è un ampio ecosistema che si estende oltre le tecnologie Azure e Microsoft. Quando distribuisci un cluster AKS, sei responsabile di molte decisioni su come progettare e gestire il cluster. L'esecuzione di un cluster del servizio Azure Kubernetes comporta componenti di origine chiusa di vari fornitori, tra cui Microsoft, insieme ai componenti open source dell'ecosistema Kubernetes. Il panorama cambia spesso, quindi rivedere regolarmente le decisioni. Quando si adotta 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 come punto di partenza alternativo e configurarla per soddisfare le proprie esigenze.

Configurazione della rete

Topologia di rete
pianificazione degli indirizzi IP
Instradamento dell'applicazione

Calcolo del cluster

calcolo per il cluster di base
Riferimento all'immagine del container
Gestione dei criteri

Gestione delle identità

Integrate Microsoft Entra ID per il cluster
Integra Microsoft Entra ID per la gestione del carico di lavoro

Flusso di dati sicuro

protezione del flusso di rete
Aggiungi la gestione dei segreti

Continuità aziendale

Scalabilità di nodi e pod
Decisioni di continuità aziendale
Zone di disponibilitàPiù regioni

Operations

Operazioni del cluster e dei carichi di lavoro
Monitorare e raccogliere log e metriche
Gestione dei costi

Architecture

diagramma

Scaricare un file Visio di questa architettura.

Per altre informazioni, vedere topologia di rete Hub-spoke in Azure.

Topologia di rete

Questa architettura usa una topologia di rete hub-spoke. Distribuire l'hub e gli spoke in reti virtuali separate connesse tramite il virtual network peering. Questa topologia presenta diversi vantaggi:

• Abilita la gestione segregata. È possibile applicare la governance e rispettare il principio dei privilegi minimi (PoLP). Supporta inoltre il concetto di zona di destinazione Azure con una separazione dei compiti.

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

• Fornire topologie hub-spoke a livello di area. È possibile espandere le topologie di rete hub-and-spoke in futuro e fornire l'isolamento dei carichi 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 con l'Azure landing zone su scala aziendale.

Hub di rete virtuale

L'hub virtual network è il punto centrale di connettività e osservabilità. In questa architettura l'hub contiene i componenti seguenti:

• Firewall di Azure con criteri firewall globali definiti dai team IT centrali per applicare regole a livello di organizzazione

• Azure Bastion, che stabilisce un tunnel sicuro nel perimetro della rete privata in modo da poter eseguire operazioni di gestione del cluster

• 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 e non Microsoft che potrebbe esfiltrare i 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 questa rete virtuale hub tipo di architettura.

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 l'virtual network.

Subnet per ospitare Azure Bastion

Questa subnet viene usata per Azure Bastion. È possibile usare Azure Bastion per accedere in modo sicuro alle risorse Azure senza esporre le risorse a Internet. Questa architettura usa Azure Bastion per connettersi in modo sicuro al server API del cluster del servizio Azure Kubernetes per le operazioni di gestione. La subnet è solo per la gestione e le operazioni.

Rete virtuale a spoke

Il spoke virtual network contiene il cluster AKS e altre risorse correlate. Lo spoke ha le subnet seguenti.

Subnet per ospitare gateway applicazione di Azure

gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che opera al livello 7. L'implementazione di riferimento utilizza lo SKU v2 di Application Gateway che abilita Web application firewall di Azure. Web application firewall protegge il traffico in ingresso da 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, Application Gateway richiede una subnet dedicata.

Subnet per gli IP front-end del bilanciatore del carico interno

Questa subnet fornisce lo spazio di indirizzi IP per gli IP front-end del bilanciatore del carico interno. Application Gateway invia il traffico all'indirizzo IP assegnato del bilanciatore del carico interno privato. Il servizio di bilanciamento del carico distribuisce il traffico a qualsiasi nodo del cluster. kube-proxy nel nodo ricevente inoltra il pacchetto al pod proxy del gateway nel pool di nodi di sistema, aggiungendo potenzialmente un hop di rete aggiuntivo. Il proxy termina TLS e inoltra le richieste ai pod del carico di lavoro tramite HTTP. Usando una subnet dedicata per questi indirizzi IP front-end, è possibile applicare regole del gruppo di sicurezza di rete che definiscono l'ambito del traffico in ingresso al servizio di bilanciamento del carico senza influire sulla subnet del nodo. Per maggiori informazioni, vedere Usare un load balancer interno con AKS.

Subnet per ospitare i nodi del cluster

Questa architettura usa due pool di nodi, che sono gruppi separati di nodi. Il pool di nodi di sistema ospita i pod che eseguono i servizi principali del cluster, incluso il proxy gateway che instrada il traffico verso il carico di lavoro. Il pool di nodi utente esegue i carichi di lavoro.

Subnet per ospitare gli endpoint di collegamento privato di Azure

Creare connessioni collegamento privato di Azure per Registro Azure Container e Azure Key Vault in modo che gli utenti possano accedere a questi servizi tramite un endpoint private all'interno della rete virtuale spoke. Non è necessaria una subnet dedicata per gli endpoint privati. È anche possibile inserire endpoint privati nell'hub virtual network. Nell'implementazione di base, gli endpoint vengono distribuiti in una subnet dedicata all'interno del virtual network spoke. Questo approccio riduce il traffico che passa attraverso la connessione di rete peer. 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 altre informazioni, vedere collegamento privato opzioni di distribuzione.

Subnet per il server API di AKS

È possibile configurare un cluster AKS per l'uso di integrazione della rete virtuale del server API, che proietta l'endpoint del server API del cluster in una subnet delegata nella tua rete virtuale. Questa configurazione è denominata cluster privato perché garantisce che tutto il traffico tra il server API, i pool di nodi e i client connessi rimangano interamente all'interno della rete privata.

Tutte le comunicazioni tra il server API Kubernetes gestito dal servizio Azure Kubernetes e i client (client interni e esterni del cluster) sono limitate a una rete attendibile.

Con un cluster privato, è possibile utilizzare gli NSG e altri controlli di rete integrati per garantire la sicurezza dell'ambiente. Questa configurazione impedisce qualsiasi access pubblico non autorizzato tra Internet e l'ambiente. Per altre informazioni, vedere Creare un cluster AKS privato.

pianificazione degli indirizzi IP

Scaricare un file Visio di questa architettura.

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

• La rete virtuale Azure che usi per risorse come i nodi del cluster, il server API del cluster, gli endpoint privati per i servizi Azure e il gateway delle applicazioni.

• Il cluster usa Azure CNI (Container Networking Interface) Overlay, che alloca gli indirizzi IP ai pod da uno spazio indirizzi separato alla rete virtuale Azure.

Spazio indirizzi IP rete virtuale

Lo spazio degli indirizzi della rete virtuale Azure deve essere sufficientemente grande da contenere tutte le subnet. Tenere conto di tutte le entità che ricevono il traffico. Kubernetes alloca indirizzi IP alle entità dallo spazio degli indirizzi della subnet. Quando si pianificano gli indirizzi IP della rete virtuale di Azure, tenere presente quanto segue:

• Aggiornamenti: I nodi del servizio Azure Kubernetes vengono aggiornati regolarmente per assicurarsi che le macchine virtuali sottostanti siano up-to-date sulle funzionalità di sicurezza e su altre patch di sistema. Durante un processo di aggiornamento, AKS crea un nodo che ospita temporaneamente i pod, mentre il nodo di aggiornamento viene contrasegnato e scaricato. Tale nodo temporaneo riceve un indirizzo IP dalla subnet del cluster. Assicurarsi di disporre di spazio di indirizzi sufficiente per gli indirizzi IP temporanei del nodo.

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

• Scalabilità: Prendere in considerazione il numero totale di nodi di sistema e utente e i relativi limiti di scalabilità massimi. Ad esempio, se si desidera aumentare la capacità del 400%, sono necessari quattro volte tanti indirizzi per tutti i nodi scalati orizzontalmente.

  Poiché questa architettura utilizza CNI Overlay di Azure, la scalabilità dei tuoi pod non influisce sullo spazio degli indirizzi della tua rete virtuale.

• collegamento privato addresses: Tieni conto degli indirizzi necessari per la comunicazione con altri servizi Azure tramite collegamento privato. Questa architettura ha due indirizzi assegnati per i collegamenti a Registro Container e Key Vault.

• Indirizzi del server API del cluster privato: L'integrazione del server API nella rete virtuale aiuta a proiettare il server API del servizio Azure Kubernetes come un endpoint all'interno della rete virtuale. Questa funzionalità richiede una dimensione minima della subnet, quindi assicurati di soddisfare questo prerequisito durante la pianificazione della rete.

• I indirizzi IP riservati: Azure riserva indirizzi specifici 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 AKS 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. Questo isolamento comporta un numero maggiore di subnet di dimensioni inferiori. La topologia del gateway potrebbe anche ampliarsi perché ogni risorsa Gateway produce la propria distribuzione del proxy gateway e l'indirizzo IP front-end del servizio di bilanciamento del carico. Pianificare in modo appropriato lo spazio di indirizzamento della subnet.

Spazio di indirizzamento IP del pod

Azure CNI Overlay assegna gli indirizzi IP ai pod usando uno spazio indirizzi dedicato, separato dallo spazio indirizzi usato nella rete virtuale. Usare uno spazio di indirizzi IP che non si sovrapponga alla rete virtuale o alle reti virtuali in peering. Tuttavia, se si creano più cluster Azure Kubernetes Service (AKS), è possibile usare in modo sicuro lo stesso spazio di indirizzi pod in ogni cluster.

Azure CNI Overlay assegna a ogni nodo uno spazio di indirizzi /24 per i pod. È importante assicurarsi che lo spazio degli indirizzi del pod sia sufficientemente grande. Permetti quanti più blocchi /24 necessari per il numero di nodi nel tuo 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 di routing tra domini (CIDR) senza classi, 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 il materiale sussidiario sulla pianificazione degli indirizzi IP per Azure overlay CNI.

Altre considerazioni sullo spazio degli indirizzi IP

Per il set completo di considerazioni sulla rete per questa architettura, vedere topologia di rete di base AKS. Per altre informazioni su come pianificare l'indirizzamento IP per un cluster del servizio Azure Kubernetes, vedere Configurare Azure rete CNI nel servizio Azure Kubernetes.

Componenti aggiuntivi e funzionalità di anteprima

Kubernetes e AKS si evolvono continuamente, con cicli di rilascio più veloci rispetto al software per gli ambienti locali. Questa architettura di base dipende da specifiche funzionalità di anteprima del servizio Azure Kubernetes e dai componenti aggiuntivi del servizio Azure Kubernetes. Considerare le differenze seguenti tra le funzionalità di anteprima e i componenti aggiuntivi:

• Il team di AKS descrive le funzionalità di anteprima come rilasciate e in miglioramento perché molte delle funzionalità di anteprima rimangono in tale stato solo per alcuni mesi prima di passare alla fase di Disponibilità Generale (GA).

• AKS componenti aggiuntivi e estensioni offrono funzionalità aggiuntive supportate. AKS gestisce l'installazione, la configurazione e il ciclo di vita.

L'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 alcune altre funzionalità in anteprima o componenti aggiuntivi di Azure Kubernetes Service che si potrebbero valutare nei cluster di preproduzione. Queste funzionalità possono migliorare la sicurezza, la gestibilità o altri requisiti. Con componenti aggiuntivi non Microsoft, è necessario installarli e gestirli, che include il rilevamento delle versioni disponibili e l'installazione degli aggiornamenti dopo l'aggiornamento della versione kubernetes di un cluster.

Riferimento all'immagine del container

Il cluster può contenere il carico di lavoro e diverse altre immagini, ad esempio l'infrastruttura del gateway autogestito o un contenitore di utilità che sincronizza i certificati TLS da Key Vault. Alcune di queste immagini potrebbero risiedere in registri pubblici, ma è consigliabile mantenerle analizzate, controllate e archiviate in un registro privato dedicato, ad esempio Registro Azure Container. Quando si estraggono le immagini nel cluster, tenere presente quanto segue:

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

• Se utilizzi un'immagine pubblica, importa l'immagine in un registro dei contenitori allineato all'obiettivo del livello di servizio (SLO). In caso contrario, l'immagine potrebbe essere soggetta a problemi di disponibilità imprevisti. Se l'immagine non è disponibile quando necessario, possono verificarsi problemi operativi. Considerare i vantaggi seguenti dell'uso di un registro contenitori privato, ad esempio Registro Azure Container, anziché un registro pubblico:

  • È possibile bloccare le access non autorizzate alle immagini.
  • Non si hanno dipendenze rivolte al pubblico.
  • È possibile accedere ai log di pull delle immagini per monitorare le attività e risolvere i problemi di connettività.
  • È possibile sfruttare i vantaggi dell'analisi integrata dei contenitori e della conformità delle immagini.

• Scaricare le 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 di Registro Azure Container dedicata che viene distribuita con il cluster.

Configurare il calcolo per il cluster di base

Nel servizio Azure Kubernetes (AKS), ogni pool di nodi di solito corrisponde a un set di scalabilità di macchine virtuali. I nodi sono virtual machines (VM) 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 D2dv5. Tale dimensione è sufficiente per soddisfare il carico previsto dei pod di sistema. Il disco temporaneo del sistema operativo è 64 GB.

Quando si pianifica la capacità per un pool di nodi utente, prendere in considerazione le raccomandazioni seguenti:

• Scegliere dimensioni del nodo maggiori per accogliere il numero massimo di pod impostati in un nodo. I nodi di grandi dimensioni riducono al minimo il footprint dei servizi eseguiti in 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 ulteriori informazioni, consultare Dimensioni per le macchine virtuali in Azure.

• Distribuire almeno due nodi in modo che il carico di lavoro possa seguire 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 definiti dal team di progettazione. In base ai requisiti aziendali, questa architettura usa lo SKU D4dv5 per il carico di lavoro di produzione.

• Si supponga che il carico di lavoro consuma fino a 80% di ogni nodo quando si pianifica la capacità per il cluster. Il rimanente 20% è riservato ai servizi AKS.

• Impostare i pod massimi per ogni nodo in base alla pianificazione della capacità. Se si tenta di stabilire una baseline di capacità, iniziare con un valore pari a 30. Modificare tale valore in base ai requisiti del carico di lavoro, alle dimensioni del nodo e ai vincoli degli indirizzi IP.

Selezionare un sistema operativo

La maggior parte dei cluster AKS 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 rinforzata ottimizzata per Azure. È possibile scegliere un'altra distribuzione linux come Ubuntu se si preferisce o se Azure Linux non soddisfa i requisiti. Se si sceglie un sistema operativo diverso, assicurarsi che il disco del sistema operativo sia ridimensionato in modo appropriato per tale immagine. Alcune distribuzioni richiedono più spazio di Azure Linux, quindi potrebbe essere necessario aumentare le dimensioni del disco per evitare problemi di distribuzione o di runtime.

Se il carico di lavoro è composto da tecnologie miste, è possibile usare sistemi operativi diversi in pool di nodi diversi. Tuttavia, se non sono necessari sistemi operativi diversi, è consigliabile usare un singolo sistema operativo per tutti i pool di nodi del carico di lavoro per ridurre la complessità operativa.

Integrare Microsoft Entra ID per il cluster

La protezione dell'accesso da e verso il cluster è fondamentale. Utilizzare la prospettiva del cluster per comprendere la differenza tra il traffico in entrata e in uscita.

• Inside-out access: Prendere in considerazione l'accesso di AKS a componenti di Azure come l'infrastruttura di rete, il Container Registry e Key Vault. Autorizzare solo le risorse a cui il cluster deve avere accesso.

• Outside-in access: Fornire alle identità l'accesso al cluster Kubernetes. Autorizzare solo le entità esterne a cui è consentito l'accesso al server API Kubernetes e Azure Resource Manager.

Accesso di AKS ai componenti di Azure

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

Dei due metodi per gestire l'accesso di AKS ad Azure, consigliamo l'uso delle 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 automaticamente l'autenticazione e la rotazione tempestiva dei segreti.

È consigliabile abilitare e usare identità gestite in AKS affinché il cluster possa interagire con risorse Azure esterne tramite Microsoft Entra ID. Se non integri subito l'ID Microsoft Entra, è possibile aggiungerlo in un secondo momento.

Per impostazione predefinita, il cluster usa 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 il Registro dei 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, cosa che si fa concedendo AcrPull accesso all'identità gestita kubelet del cluster al registro. Se non si usa un'identità gestita, è possibile archiviare tali informazioni in un segreto Kubernetes e usarle imagePullSecrets per recuperarlo. Questo approccio non è consigliato perché introduce complessità di sicurezza, inclusa la necessità di conoscere il segreto in anticipo e archiviarlo nella pipeline DevOps. Aggiunge inoltre un sovraccarico operativo perché è necessario aggiornare il segreto.

In questa architettura, il cluster accede alle risorse Azure che sono 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 (Azure RBAC) e le autorizzazioni alle identità gestite del cluster, in base alle operazioni eseguite dal cluster. Il cluster esegue l'autenticazione a Microsoft Entra ID e quindi viene consentito o negato l'accesso in base ai ruoli assegnati. Ecco alcuni esempi di questa implementazione di riferimento in cui Azure ruoli predefiniti vengono assegnati al cluster:

• Il ruolo Collaboratore della rete gestisce la capacità del cluster di controllare la rete virtuale spoke. Con questa assegnazione di ruolo, l'identità assegnata dal sistema del cluster AKS può operare con la subnet dedicata per il bilanciatore del carico interno posto davanti al proxy del gateway e al server API privato di AKS.

• Il ruolo DNS privato Zone Contributor gestisce la capacità del cluster di collegare la zona direttamente alla rete virtuale spoke che ospita il cluster. Un cluster privato mantiene i record DNS dalla rete Internet pubblica usando una zona private DNS. Tuttavia, è comunque possibile creare un cluster del servizio Azure Kubernetes privato con un indirizzo DNS pubblico. È consigliabile impedire esplicitamente questa funzionalità impostando enablePrivateClusterPublicFQDN su false per evitare la divulgazione dell'indirizzo IP privato del piano di controllo. È consigliabile usare Criteri di Azure per applicare l'uso di cluster privati senza record DNS pubblici.

• Il ruolo Publisher Monitoraggio delle metriche gestisce la capacità del cluster di inviare metriche ad Monitoraggio di Azure.

• Il ruolo AcrPull gestisce la capacità del cluster di eseguire il pull delle immagini dalle istanze del Registro Container specificate.

Due componenti aggiuntivi del servizio Azure Kubernetes effettuano il provisioning di identità gestite aggiuntive che richiedono assegnazioni di ruolo. L'identità gestita del componente aggiuntivo Secrets Store CSI Driver recupera i certificati TLS da Key Vault. L'identità del componente aggiuntivo di instradamento dell'applicazione gestisce i record DNS e la riconciliazione del Gateway.

Concedere a queste identità l'accesso alle risorse con cui interagiscono:

• L'identità gestita del componente aggiuntivo Secrets Store CSI Driver richiede il ruolo Utente certificati di Key Vault nel tuo Key Vault affinché il driver possa recuperare i certificati TLS.

• L'identità gestita del componente aggiuntivo per il routing delle applicazioni richiede i ruoli Key Vault Secrets User e Key Vault Reader nell'istanza di Key Vault e il ruolo DNS privato Zone Contributor nella zona DNS privata di ingresso, affinché il controller possa gestire i record DNS quando riconcilia le risorse Gateway.

Accesso al cluster

Microsoft Entra integrazione semplifica anche la sicurezza per l'accesso esterno. Ad esempio, può essere necessario usare kubectl. Come passaggio iniziale, è possibile eseguire il az aks get-credentials comando per ottenere le credenziali del cluster. Microsoft Entra ID autentica l'identità rispetto ai ruoli Azure autorizzati a ottenere le credenziali del cluster. Per ulteriori informazioni, vedere autorizzazioni dei ruoli del cluster disponibili.

AKS supporta l'accesso a Kubernetes tramite Microsoft Entra ID utilizzando Microsoft Entra ID come provider di identità integrato con RBAC nativo di Kubernetes oppure utilizzando RBAC nativo di Azure per controllare l'accesso al cluster. Le sezioni seguenti descrivono in dettaglio entrambi gli approcci.

Associare RBAC di Kubernetes a Microsoft Entra ID

Kubernetes supporta il controllo degli accessi in base al ruolo tramite gli oggetti API seguenti:

• 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 svolgere le azioni. Definire le associazioni utilizzando un oggetto RoleBinding o ClusterRoleBinding.

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

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

Usare Azure RBAC per l'autorizzazione di Kubernetes

Si consiglia di utilizzare Controllo degli accessi in base al ruolo di Azure e le Assegnazioni di ruolo di Azure per applicare i controlli di autorizzazione nel cluster. Questo approccio di autorizzazione si integra con l'autenticazione Microsoft Entra. È possibile assegnare ruoli a vari ambiti, ad esempio il gruppo di gestione, la sottoscrizione o il gruppo di risorse. Tutti i cluster nell'ambito ereditano quindi un set coerente di assegnazioni di ruolo per chi ha i permessi di accesso agli oggetti nel cluster Kubernetes.

Non consigliamo di utilizzare l'RBAC nativo di Kubernetes con ClusterRoleBindings e RoleBindings.

Per ulteriori informazioni, vedere Azure RBAC per l'autorizzazione Kubernetes.

Account locali

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

In questa implementazione di riferimento, l'accesso agli account locali del cluster è esplicitamente vietato durante la distribuzione del cluster da parte del sistema.

Integrare Microsoft Entra ID per il carico di lavoro

Analogamente alla presenza di un'identità gestita assegnata dal sistema 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. Si supponga, ad esempio, che il carico di lavoro archivii i file in Archiviazione di Azure. Quando deve accedere a tali file, il pod si autentica sulla risorsa come un'identità gestita di Azure.

In questa implementazione di riferimento, ID dei carichi di lavoro di Microsoft Entra su AKS (Azure Kubernetes Service) 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 ulteriori informazioni, vedere Federazione delle identità del carico di lavoro.

Selezionare un modello di rete

AKS (Azure Kubernetes Service) fornisce plug-in CNI (Container Networking Interface) in due modelli di rete: overlay e flat. Entrambi i modelli supportano i criteri di rete per il controllo del traffico in cluster.

Con un plugin di rete flat, come la sottorete Pod di Azure CNI, ogni pod ottiene un indirizzo IP dalla sottorete della rete virtuale. Le risorse nella stessa rete o reti con peering possono accedere ai pod direttamente tramite l'indirizzo IP senza NAT (Network Address Translation). Usare un modello di rete flat quando il carico di lavoro richiede che i pod siano instradabili direttamente dalla rete virtuale.

Questa implementazione di riferimento usa Azure CNI Overlay, ovvero un plug-in di rete di sovrapposizione. Alloca gli indirizzi IP della rete virtuale solo ai nodi e assegna indirizzi IP pod da un intervallo CIDR separato. Poiché Azure overlay CNI utilizza molto meno indirizzi IP di rete virtuale rispetto ai modelli flat, è consigliabile per la maggior parte delle distribuzioni.

Per altre informazioni sui modelli, vedere Panoramica della rete CNI del servizio Azure Kubernetes e Procedure consigliate per la connettività e la sicurezza di rete nel servizio Azure Kubernetes.

Instradamento delle applicazioni

Questa architettura utilizza il componente aggiuntivo di instradamento delle applicazioni con l'API Kubernetes Gateway. Il componente aggiuntivo per il routing delle applicazioni è una configurazione del cluster AKS che specifica che il cluster deve includere un'infrastruttura gateway gestita. L'API gateway è un set di definizioni di risorse personalizzate (CRD) di Kubernetes, tra cui GatewayClass, GatewayHTTPRoute, e altre. La comunità Kubernetes ha progettato la Gateway API come successore della precedente Ingress API. Fornisce un framework standardizzato, orientato ai ruoli ed estendibile per la gestione del traffico.

I componenti vengono distribuiti in diverse fasi del ciclo di vita:

• Progettazione del cluster. Il team dell'applicazione decide quale controller gateway gestisce il traffico in ingresso e come gestire il ciclo di vita del controller. I controller del gateway in genere raggruppano i proxy del piano dati, quindi questa decisione determina anche quale proxy gestisce il percorso del traffico. Questa architettura abilita le CRD gestite della Gateway API. Configura il componente aggiuntivo per utilizzare Istio gestito come controller del gateway, abbinato a Envoy come proxy del gateway. Anche se è anche possibile usare Istio come mesh di servizi, in questa architettura Istio viene usato solo come controller del gateway e le relative funzionalità della mesh di servizi non sono abilitate.

  Se il team richiede un'implementazione diversa, può usare altri controller API del gateway, ad esempio NGINX Gateway Fabric, Envoy Gateway e Traefik. Questi controller possono essere autogestiti, il che comporta la gestione diretta dei manifest, dell’anti-affinità, del posizionamento dei nodi, delle probe, della definizione dell’ambito dell’RBAC, dei criteri di scalabilità, delle restrizioni degli IP di origine e del ciclo di vita delle versioni. In cambio, si ottengono il pieno controllo sul comportamento del proxy, il blocco della versione indipendentemente dagli aggiornamenti del cluster e una configurazione senza vincoli.

• Provisioning del cluster. Nessuna decisione di progettazione si verifica in questa fase. AKS installa i CRD dell'API Gateway, i pod di Istio (controller del gateway) nel namespace aks-istio-system e la GatewayClass approuting-istio. In questa fase non esistono pod del piano dati per il proxy del gateway.

• Inizializzazione del cluster. Il team responsabile del carico di lavoro definisce come viene esposto il proxy del gateway (bilanciatore del carico interno o esterno), quale subnet ospita l'IP frontend del bilanciatore del carico e in quale namespace viene eseguito il proxy del gateway. In questa architettura, il proxy gateway è esposto tramite un bilanciatore del carico interno, è presente una subnet dedicata agli IP del bilanciatore del carico e il proxy gateway è distribuito nel namespace del a0008 carico di lavoro.

  Una risorsa gateway che fa riferimento a approuting-istio GatewayClass esprime queste decisioni. Il controller del gateway la riconcilia come deployment di Envoy (proxy del gateway), un servizio LoadBalancer, un HorizontalPodAutoscaler e un PodDisruptionBudget nello stesso namespace della risorsa Gateway.

  Quando una zona DNS privata è collegata al componente aggiuntivo, il componente DNS del componente aggiuntivo può gestire automaticamente i record DNS A, eliminando così la necessità di mantenere i record statici nei modelli IaC. Il bootstrap distribuisce anche le risorse di sincronizzazione dei certificati TLS descritte in Accedere ai segreti del cluster.

• Distribuzione del carico di lavoro. Il team dell'applicazione definisce i nomi host, i percorsi e i back-end che ricevono il traffico. Le risorse HTTPRoute, che si associano al gateway, esprimono queste decisioni di routing. Il controller del gateway propaga il comportamento di routing dichiarato ai pod Envoy.
• Manutenzione in corso: Il componente aggiuntivo collega la versione del controller del gateway Istio alla versione del cluster del servizio Azure Kubernetes, quindi gli aggiornamenti vengono eseguiti insieme agli aggiornamenti del cluster anziché richiedere la gestione indipendente del ciclo di vita. Questo componente aggiuntivo usa Istio esclusivamente per la gestione del proxy del gateway. Non abilita l'iniezione del sidecar né la service mesh completa di Istio, che è un componente aggiuntivo separato.

Applica le risorse Gateway e HTTPRoute

Questa architettura utilizza il componente aggiuntivo di routing delle applicazioni con la Gateway API di Kubernetes per la gestione del traffico in ingresso. Questa sezione illustra le fasi di avvio automatico del cluster e distribuzione del carico di lavoro descritte in precedenza. A questo punto, il controller del gateway è già in esecuzione e attende che le risorse dell'API gateway si riconciliano.

L'API gateway è uno standard indipendente dal fornitore che esprime i criteri TLS, il routing basato sulle intestazioni e la suddivisione del traffico come campi API nativi anziché annotazioni specifiche dell'implementazione. Poiché la configurazione del routing non dipende da una particolare tecnologia proxy, è possibile modificare l'implementazione sottostante in un secondo momento senza riscriverla. Il componente aggiuntivo per il routing delle applicazioni gestisce il controller del gateway e il ciclo di vita del proxy, eliminando la necessità di gestire aggiornamenti, patch di sicurezza, configurazione della scalabilità e definizione dell’ambito dell’RBAC.

La Gateway API separa il traffico in ingresso in due ambiti che evolvono indipendentemente:

• La risorsa Gateway dichiara la superficie di rete, ovvero le porte e i protocolli da esporre, i certificati TLS e la subnet per il servizio di bilanciamento del carico interno. Questa risorsa cambia raramente e influisce su tutte le route associate.

• La risorsa HTTPRoute dichiara la logica di instradamento: quali host, percorsi e intestazioni corrispondono a quali servizi backend. Questa risorsa cambia con ogni distribuzione e ha come ambito singoli servizi.

Questa architettura riduce il rischio che una modifica del routing interrompa la configurazione di rete o viceversa, perché ogni risorsa ha una frequenza di modifica e un raggio di esplosione diversi. Rimuove anche diverse dipendenze: la configurazione del routing non è legata a una tecnologia proxy specifica, la versione del proxy è allineata a quella del cluster AKS invece di richiedere una gestione separata e ogni gateway ottiene una propria distribuzione del proxy invece di condividere un unico controller per tutte le route.

Come descritto in precedenza nelle fasi del ciclo di vita, quando si applica una risorsa Gateway che fa riferimento alla GatewayClass configurata, il controller del gateway la converte in risorse Deployment del proxy del gateway e in risorse di supporto. È possibile controllare il posizionamento della subnet tramite annotazioni dell'infrastruttura nella risorsa gateway.

Questo modello dichiarativo rimuove la necessità di gestire grafici Helm, immagini del contenitore o manifesti di distribuzione per il proxy. L'intento viene espresso tramite la configurazione delle risorse Gateway API e il controller del gateway porta il proxy allo stato desiderato.

In genere, un controller di gateway gestito effettua il provisioning del proxy del gateway con impostazioni predefinite per l'ambiente di produzione: probe di readiness e liveness, autorizzazioni RBAC, scalabilità delle repliche (minimo due repliche, con scalabilità automatica basata sulla CPU fino a cinque) e un PodDisruptionBudget che garantisce almeno un pod disponibile durante le interruzioni volontarie.

Comprendere la topologia di pianificazione dei componenti aggiuntivi

I componenti aggiuntivi di AKS collocano i componenti gestiti nei pool di nodi in base a decisioni di schedulazione che il team applicativo non controlla. Prima di dimensionare i pool di nodi utente e di sistema, individuare dove ogni componente aggiuntivo abilitato pianifica i pod. Alcuni componenti aggiuntivi tollerano i taint del pool di nodi di sistema e quindi vengono eseguiti solo nel pool di sistema. Altri si rivolgono a gruppi di utenti specifici. Questa topologia influisce direttamente sulla capacità necessaria in ogni pool.

Il gateway proxy Envoy gestito, per progettazione, viene eseguito sul pool di nodi di sistema, non su quello di nodi utente. Dimensionare il pool di sistema tenendo conto dell'impatto aggiuntivo del proxy sulle risorse. Se questa topologia predefinita non soddisfa i requisiti dell'organizzazione, ad esempio se è necessario il proxy nei pool di utenti per motivi di isolamento dei costi, segmentazione di rete o conformità, passare a un controller del gateway autogestito in cui si è proprietari delle decisioni di posizionamento dei nodi.

Anche con un controller gateway gestito, il team dell'applicazione può configurare l'anti-affinità dei pod per distribuire le repliche proxy tra i nodi. Queste impostazioni vengono configurate mediante le impostazioni di personalizzazione del gateway incluse nell'elenco degli elementi consentiti. Per altre informazioni, vedere Personalizzazione delle risorse del gateway.

Poiché il proxy del gateway viene eseguito nel pool di nodi di sistema e il carico di lavoro viene eseguito nel pool di nodi utente, l'utilità di pianificazione li considera come domini di pianificazione indipendenti. Il proxy gateway e il carico di lavoro sono servizi che comunicano frequentemente, perché ogni richiesta in ingresso passa attraverso il proxy prima di raggiungere il carico di lavoro. Nessun meccanismo predefinito correla il posizionamento della zona tra pod in pool di nodi diversi. Senza indicazioni esplicite, lo scheduler può collocare i pod del carico di lavoro in zone in cui non esiste alcuna replica del proxy, costringendo il traffico ad attraversare il confine di una zona di disponibilità e aumentando la latenza e i costi di trasferimento dati tra zone. Per ridurre questo traffico tra zone, configura l'affinità pod preferita sul tuo carico di lavoro per co-localizzarlo con le repliche del proxy a livello di zona. Questa co-localizzazione è il massimo ottenibile quando il proxy e il carico di lavoro vengono eseguiti in pool di nodi separati, perché l'affinità a livello di nodo non ha effetto tra pool diversi. Si noti che l'affinità tra i pod aggiunge un sovraccarico di elaborazione allo scheduler e potrebbe rallentare il processo di pianificazione nei cluster di grandi dimensioni.

Tenere conto dei requisiti di risorse dei componenti aggiuntivi nei criteri di governance

I componenti aggiuntivi del servizio Azure Kubernetes distribuiscono componenti gestiti i cui requisiti di risorsa sono definiti e controllati dal servizio Azure Kubernetes, non dal team dell'applicazione. Quando il cluster applica i criteri di limite delle risorse del contenitore in modalità Nega tramite Criteri di Azure e OPA Gatekeeper, questi criteri devono supportare ogni componente aggiuntivo abilitato. In caso contrario, Gatekeeper blocca silenziosamente la creazione dei pod gestiti, compromettendo funzionalità della piattaforma come ingress, sincronizzazione dei segreti o osservabilità, senza alcun errore di distribuzione evidente.

Considerare la profilatura delle risorse aggiuntive un prerequisito per la creazione delle policy. Prima di definire i vincoli di CPU, memoria, volume o contesto di sicurezza del contenitore, eseguire l'inventario di ogni componente aggiuntivo abilitato e determinarne i requisiti delle risorse di runtime. Usare i test di carico o le distribuzioni controllate in un ambiente di preproduzione per acquisire il consumo effettivo delle risorse in condizioni di traffico realistiche. Imposta quindi i limiti delle policy in modo da includere sia i componenti aggiuntivi sia i container del carico di lavoro. Questo approccio garantisce che le protezioni di governance proteggono il cluster senza interferire con l'infrastruttura gestita dalla piattaforma.

Ad esempio, il proxy gateway Envoy gestito richiede fino a 2 core di CPU e 1 GiB di memoria per replica. È probabile che questi valori siano molto maggiori di quelli necessari per un carico di lavoro di piccole o basse risorse. Imposta i limiti delle policy in modo da includere il proxy gateway insieme ai container dell'applicazione. Senza questa modifica, i pod proxy del gateway vengono bloccati da Gatekeeper e l'intera pipeline Ingress non viene creata.

Terminazione TLS del gateway nel cluster e imposizione HTTPS

Questa architettura configura il gateway con HTTPS sulla porta 443 usando un certificato TLS sincronizzato da Key Vault e un listener HTTP sulla porta 80 per il reindirizzamento. Le annotazioni dell'infrastruttura sul Gateway posizionano il bilanciatore del carico nella subnet di ingresso e lo rendono interno. Un HTTPRoute di reindirizzamento associato al listener HTTP restituisce un 301 Moved Permanently per reindirizzare tutte le richieste HTTP a HTTPS. L'applicazione HTTPRoute viene associata al listener HTTPS e instrada il traffico al servizio del carico di lavoro tramite HTTP. Poiché il proxy del gateway esegue la terminazione TLS, la comunicazione con i servizi back-end non è crittografata.

protezione del flusso di rete

In questa architettura il flusso di rete include i tipi di traffico seguenti:

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

• Traffico in uscita da un pod o un nodo nel cluster verso un servizio esterno.

• Traffico da pod a pod tra i pod. Questo traffico include la comunicazione tra il proxy del gateway 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 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 Application Gateway usando due diversi certificati TLS, come illustrato nel diagramma seguente.

Scaricare un file Visio di questa architettura.

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

2. Application Gateway ha un web application firewall integrato e negozia l'handshake TLS per bicycle.contoso.com, consentendo solo crittografie sicure. Application Gateway è un punto di terminazione TLS, importante perché web application firewall di Application Gateway deve esaminare la richiesta e la risposta in testo non crittografato. Key Vault archivia il certificato TLS. Il cluster vi accede con un'identità gestita assegnata dall'utente che si integra con Application Gateway. Per altre informazioni, vedere terminazione TLS con certificati Key Vault.

   Application Gateway processa le regole di ispezione del firewall per applicazioni web ed esegue le regole di routing che inoltrano il traffico al back end configurato.

3. Quando il traffico passa da Application Gateway al back-end, viene crittografato di nuovo con un altro certificato TLS, che è un wildcard per *.aks-ingress.contoso.com, perché esegue il forward al load balancer interno. Questa ricrittografia consente di garantire che il traffico non protetto non venga trasmesso nella subnet del cluster.

4. Il proxy del gateway riceve il traffico crittografato tramite il servizio di bilanciamento del carico. Il proxy è un altro punto di terminazione TLS per *.aks-ingress.contoso.com e inoltra il traffico ai pod del carico di lavoro su HTTP. Il certificato TLS viene archiviato in Key Vault e sincronizzato nel cluster come segreto Kubernetes a cui fa riferimento la risorsa gateway. Per altre informazioni, vedere Aggiungi gestione dei segreti.

È 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 prende la decisione di mettere in sicurezza il traffico da pod a pod. Per la maggior parte dei cluster mono-tenant, con un RBAC del control plane configurato correttamente e pratiche consolidate del ciclo di vita dello sviluppo software, è sufficiente cifrare con TLS fino al proxy gateway e proteggere con un 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 carico di lavoro e conformità determinano dove eseguire la terminazione TLS.

Flusso del traffico in uscita

In questa architettura è consigliabile che tutto il traffico in uscita dal cluster attraversi Firewall di Azure. È anche possibile usare un'appliance virtuale di rete simile. Non è consigliabile usare altre opzioni in uscita, ad esempio 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 ispezionare il traffico, inviare l'intero traffico in uscita attraverso Firewall di Azure. Implementare questa configurazione con route definite dall'utente (UDR). L'hop successivo della route è l'indirizzo IP privato di Firewall di Azure. Firewall di Azure decide se bloccare o consentire il traffico in uscita in base alle regole definite dall'utente o alle regole di intelligence sulle minacce predefinite.

Un'alternativa alla Firewall di Azure consiste nell'usare la funzionalità proxy HTTP AKS. 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 Azure Kubernetes Service (AKS).

Un'eccezione al controllo Zero Trust è quando il cluster deve comunicare con altre risorse Azure. Ad esempio, il cluster potrebbe dover scaricare un'immagine aggiornata dal registro di container o dai segreti da Key Vault. In questi scenari è consigliabile usare collegamento privato.

Il vantaggio dell'uso di collegamento privato è che le subnet specifiche raggiungono direttamente il servizio e il traffico tra il cluster e i servizi non passa attraverso 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 Azure supportano collegamento privato. Per questi casi, è consigliabile abilitare un endpoint di servizio di rete virtuale sulla subnet per accedere al servizio.

Per Container Registry nello specifico, utilizza endpoint dati dedicati. Senza di essi, i download dei livelli dell'immagine vengono reindirizzati a un endpoint *.blob.core.windows.net anziché all'endpoint privato del registro e le regole del firewall in uscita dovrebbero consentire un pericoloso carattere jolly per l'archiviazione BLOB. Questa regola consentirebbe il traffico in uscita dai nodi verso qualsiasi account di Archiviazione di Azure. Gli endpoint dati dedicati sostituiscono il carattere jolly con FQDN specifici del Registro di sistema (<registry>.<region>.data.azurecr.io) che si risolvono tramite collegamento privato all'endpoint privato, mantenendo il traffico a livello di immagine sul percorso privato e consentendo di definire l'ambito delle regole in uscita al registro del cluster.

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. Il firewall applica SNAT (Source Network Address Translation) ai flussi in uscita, sostituendo l'IP del pod con uno degli indirizzi IP pubblici collegati per flusso e la selezione non è deterministica. Aggiungere l'intero set di indirizzi IP pubblici collegati all'elenco indirizzi IP consentiti del servizio di destinazione oppure usare un prefisso di indirizzo IP pubblico per esprimere tale set come intervallo contiguo.

Uno svantaggio della connessione ai servizi di Azure tramite endpoint pubblici è che Firewall di Azure quindi richiede più regole per assicurarsi che consenta solo il traffico da una subnet specifica. Il numero di indirizzi IP pubblici collegati limita anche il pool di porte SNAT e quindi il limite di connessione in uscita simultaneo del cluster. Pianificare indirizzi IP multipli in Firewall di Azure prima di raggiungere l'esaurimento delle porte. Per i cluster che aprono un numero elevato di connessioni in uscita simultanee, attach un Gateway NAT di Azure al AzureFirewallSubnet per espandere significativamente il pool di porte SNAT mantenendo tutto il traffico in uscita sotto il controllo del firewall.

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 con attenzione i criteri oppure 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 proxy del gateway e il carico di lavoro. Poiché il proxy del gateway viene eseguito nello stesso namespace del workload, indirizzalo tramite l'etichetta del pod anziché tramite il selettore del namespace. Per ulteriori informazioni, vedere politiche di rete.

Abilitare i criteri di rete quando si configura il cluster perché non è possibile aggiungerlo in un secondo momento. Sono disponibili alcune opzioni per le tecnologie che implementano NetworkPolicy. Consigliamo il criterio di rete Azure, che richiede Azure CNI. 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 Differences between Azure network policy engines.

Traffico di gestione

Nell'ambito dell'esecuzione del cluster, il server API Kubernetes riceve traffico dalle risorse che vogliono to do operazioni di gestione nel cluster, ad esempio le richieste di creare 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 Azure Bastion e i pool di nodi stessi. Anziché accettare questo traffico di gestione da tutti gli indirizzi IP, è consigliabile configurare un cluster del servizio Azure Kubernetes privato.

Per ulteriori informazioni, consultare Definire gli intervalli IP autorizzati dal server API.

Si consiglia di distribuire il cluster AKS come cluster privato. Tutto il traffico del piano di controllo e del pool di nodi rimane nella rete privata e non è esposto alla rete Internet pubblica. Questa implementazione di riferimento configura un cluster privato usando l'integrazione del server API virtual network. Per praticità, gli ambienti di livello inferiore potrebbero valutare la possibilità di allentare questa raccomandazione per il cluster privato. I cluster di produzione di Azure Kubernetes Service (AKS) devono essere sempre distribuiti come cluster privati per una base di distribuzione sicura.

Il traffico privato diretto a un cluster privato di Azure Kubernetes Service (AKS) può originare dalla rete virtuale spoke, da reti con peering o da endpoint privati in reti remote. Anche se i nodi del servizio Azure Kubernetes si trovano naturalmente nello spoke, gli operatori che eseguono attività amministrative richiedono un percorso di rete dedicato per raggiungere privatamente il server API del servizio Azure Kubernetes. È possibile stabilire questa connettività nei modi seguenti:

• Tunneling: Usare Azure Bastion per aprire un tunnel direttamente al server API del cluster.
• Jump box: Effettuare il provisioning di una macchina virtuale jump box e usare Azure Bastion per connettersi tramite SSH o RDP. Da qui, l'operatore effettua richieste sul server API del cluster tramite il relativo indirizzo IP privato.

Questa architettura utilizza il tunneling client nativo di Azure Bastion per connettere il computer locale di un operatore al server API privato di AKS tramite i comandi di interfaccia della riga di comando di Azure. Il tunnel supporta flussi di lavoro diretti kubectl e Helm senza jump box. Questo approccio è consigliato perché mantiene privato l'endpoint API del servizio Azure Kubernetes, pur rimanendo più semplice e meno costoso da usare rispetto a un jump box. È anche meno complesso coordinare tra più operatori.

Tuttavia, è possibile scegliere di usare un jump box se si dispone di uno di questi requisiti:

• Gli operatori usano dispositivi non sicuri. Un jump box può garantire un rafforzamento della sicurezza maggiore se i dispositivi client non sono considerati attendibili.

• Gli operatori si connettono tramite reti instabile. Una jump box può fornire una connessione più stabile al cluster, in particolare per operazioni di gestione batch o a esecuzione prolungata.

• Gli operatori usano strumenti di diagnostica avanzati. Alcuni tipi di strumenti di diagnostica, ad esempio l'acquisizione di pacchetti, potrebbero non funzionare correttamente con gli approcci di tunneling.

Aggiungi la gestione dei segreti

Archiviare 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 forte e un log di verifica degli accessi. Mantiene anche i segreti fondamentali fuori dalla pipeline di distribuzione. In questa architettura viene abilitato e configurato un firewall Key Vault e collegamento privato viene usato per connettersi alle risorse Azure, ad esempio per Key Vault per accedere a segreti e certificati.

Key Vault è ben integrato con altri servizi di Azure. Usare la funzionalità integrata di tali servizi per accedere ai segreti. Per altre informazioni su come Application Gateway accede ai certificati TLS per il flusso di ingresso, vedere la sezione Ingresss traffic flow.

Il modello di autorizzazioni Azure RBAC per Key Vault consente di assegnare le identità di carico di lavoro al ruolo Utente Segreti Key Vault o al ruolo Lettore Key Vault per accedere ai segreti. Per altre informazioni, vedere Access Key Vault usando Azure controllo degli accessi in base al ruolo.

Accedi ai segreti del cluster

È necessario utilizzare identità di 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 dei segreti store. Quando il pod ha bisogno di un segreto, il driver si connette all'archivio specificato, recupera un segreto da un volume e monta tale volume nel cluster. Il pod può quindi ottenere il segreto dal file system del volume.

Il driver CSI comprende molti provider per supportare vari negozi gestiti. Questa implementazione utilizza il Key Vault con il driver CSI dell'archivio dei segreti con l'approccio di configurazione manuale di TLS. Una risorsa SecretProviderClass definisce quali certificati di Key Vault sincronizzare nel cluster come segreti di Kubernetes. Il driver CSI richiede almeno un pod che monti il volume CSI corrispondente per creare e mantenere il Secret sincronizzato. Se si eliminano tutti i pod in cui è montato, il driver rimuove automaticamente il Secret, il che comporta che il Gateway perda il certificato TLS. Per evitare questo problema, distribuire un pod dedicato e sempre in esecuzione che mantiene il volume CSI montato indipendentemente dal ciclo di vita dei pod del carico di lavoro. Questa architettura utilizza l'immagine del container busybox, che avvia un container leggero con un task fittizio. Importare l'immagine del contenitore nel Registro Azure Container prima della creazione del cluster perché Flux lo distribuisce durante il bootstrap. Abilita la rotazione dei segreti e imposta un intervallo di polling per la rotazione (ad esempio, due minuti) sul componente aggiuntivo CSI in modo che i rinnovi dei certificati vengano propagati automaticamente in Key Vault. La risorsa gateway fa riferimento al segreto TLS sincronizzato per la terminazione HTTPS. Per altre informazioni, vedere Proteggere il traffico in ingresso con l'implementazione dell'API del gateway di routing dell'applicazione.

Come indicato in precedenza, è possibile sostituire questa configurazione manuale con l'approccio TLS gestito dall'operatore. Con questo approccio, specifichi direttamente nel listener del Gateway l'URI del certificato di Key Vault e un ServiceAccount Workload Identity. L'operatore di instradamento dell'applicazione crea quindi SecretProviderClass e modifica automaticamente il riferimento al certificato del Gateway, eliminando la necessità di definire tali risorse durante l'inizializzazione del cluster e rimuovendo il pod dedicato alla sincronizzazione TLS. Entrambi gli approcci si basano sul meccanismo di rotazione del driver CSI per prelevare i rinnovi dei certificati da Key Vault.

Storage 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 ulteriori informazioni, vedere opzioni di archiviazione per le applicazioni in AKS.

Gestione dei criteri

Un modo efficace per gestire un cluster AKS è quello di applicare la governance tramite le politiche. Kubernetes implementa i criteri tramite Open Policy Agent (OPA) Gatekeeper. Per AKS, distribuire 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 AKS, è possibile usare Criteri di Azure in diversi modi:

• Impedire o limitare la distribuzione di cluster AKS in un gruppo di risorse o in una sottoscrizione. Applicare gli standard per l'organizzazione. Ad esempio, è possibile seguire una convenzione di denominazione o specificare un tag.

• Proteggi il tuo cluster AKS tramite Criteri di Azure per Kubernetes.

Un esempio comune di dove un criterio può essere utile riguarda la governance e la convalida delle immagini del contenitore. Le immagini del contenitore possono essere un'origine di vulnerabilità e alcune organizzazioni richiedono che le immagini del contenitore non attendibili vengano convalidate usando uno strumento di analisi delle immagini del contenitore e quindi approvate prima di poterle usare in un cluster di produzione. È possibile applicare questo processo usando Criteri di Azure e impedire la distribuzione delle immagini del contenitore non attendibili nel cluster. Per altre informazioni, vedere il modello Quarantine.

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

• Decidere se impostare una raccolta di criteri, nota come iniziative, o scegliere singoli criteri. Criteri di Azure offre due iniziative predefinite: di base e limitate. Ogni iniziativa è una raccolta di criteri integrati applicabili a un cluster AKS. È consigliabile selezionare un'iniziativa e scegliere altre politiche per il cluster e le risorse, ad esempio Registro dei Container, Gateway delle applicazioni o Key Vault, che interagiscono con il cluster. Scegliere i criteri in base ai requisiti dell'organizzazione.

• Decidere se si vuole 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 La modalità Nega perché può essere troppo restrittiva per il funzionamento del carico di lavoro.

• Decidere se sono presenti aree nel carico di lavoro che non devono essere conformi in base alla progettazione. Criteri di Azure può specificare namespace Kubernetes esentati dall'applicazione dei criteri. È consigliabile applicare i criteri in modalità Audit in modo che siate consapevoli di tali istanze.

• Decidere se si hanno 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.

• Decidere se ci sono requisiti per l'intera 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.

• Decidere se è necessario assegnare Azure criteri a ambiti specifici. Assicurarsi che i criteri di produzione vengano convalidati anche rispetto all'ambiente di preproduzione . In caso contrario, quando si esegue la distribuzione nell'ambiente di produzione, è possibile che si verifichino restrizioni aggiuntive impreviste che non sono state prese in considerazione nella preproduzione.

Questa implementazione di riferimento abilita Criteri di Azure quando viene creato il cluster AKS. 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à Nega . È 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 nomi gatekeeper-system e i log per i pod azure-policy e azure-policy-webhook nello spazio dei nomi kube-system.

Scalabilità di nodi e pod

Con l'aumento della domanda, Kubernetes può scalare orizzontalmente 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 l'autoscalamento del cluster AKS. 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 il pianificatore di Kubernetes fallisce. Un altro modo consiste nell’osservare i pod in sospeso nel corso del tempo. È possibile modificare il numero di nodi tramite il interfaccia della riga di comando di Azure o il portale di Azure.

È consigliabile usare l'approccio di autoscaling perché alcuni dei meccanismi manuali sono integrati nell'autoscaler.

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. Usa una combinazione delle metriche delle prestazioni e del ridimensionamento manuale per individuare le strozzature e comprendere la risposta dell'applicazione al ridimensionamento. Usare infine questi dati per impostare i parametri per la scalabilità automatica.

Scalabilità orizzontale automatica dei Pod

Il Horizontal Pod Autoscaler (HPA) è una risorsa di Kubernetes che scala 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. Solo l'utilizzo della CPU viene fornito in modo nativo. 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 sovra-allocati o sotto-allocati. Si affida all’Utilità di pianificazione Kubernetes per assegnare nuovi pod ai nodi o rimuovere pod dai nodi.

Potrebbe verificarsi una race condition, quando, ad esempio, l'HPA verifica prima del completamento di un'operazione di ridimensionamento. Pertanto, 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). Prendi in considerazione KEDA se un'origine eventi, come una coda di messaggi, influenza il tuo carico di lavoro, piuttosto che essere legato alla CPU o alla memoria. KEDA supporta molti sorgenti di eventi o scale. Usare l'elenco delle origini eventi che KEDA può ridimensionare con scaler di KEDA. L'elenco include il Monitoraggio di Azure scaler, un modo pratico per ridimensionare i carichi di lavoro KEDA in base alle metriche Monitoraggio di Azure.

Scalatore automatico del cluster

Il cluster autoscaler è un componente aggiuntivo di AKS che ridimensiona il numero di nodi in un pool di nodi. Aggiungilo 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 configura automaticamente un nuovo nodo nel pool di nodi. Viceversa, il ridimensionamento automatico del cluster controlla la capacità inutilizzata dei nodi. Se il nodo non opera secondo la capacità prevista, i pod vengono spostati su un altro nodo e il nodo non utilizzato 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.

Decisioni di continuità aziendale

Per mantenere la continuità aziendale, definire lo SLO per l'infrastruttura e l'applicazione. Per altre informazioni, vedere Recommendations per la definizione di obiettivi di affidabilità. Esaminare le condizioni dell'accordo sul livello di servizio (SLA) per AKS nell'articolo più recente SLA 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 maggiore disponibilità o capacità, espandere per aggiungere altri 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 macchie per identificare il pool di nodi e pianificare il carico di lavoro. Assicurarsi che il pool di nodi di sistema sia contrassegnato con il taint CriticalAddonsOnly taint per impedire che i pod dell'applicazione vengano pianificati nei pool di nodi di sistema.

Le normali attività di manutenzione nel cluster, come gli aggiornamenti tempestivi, sono fondamentali per l'affidabilità. È inoltre consigliabile monitorare l'integrità dei pod tramite sonde.

Disponibilità dei pod

• Specificare le risorse richieste dai pod: È consigliabile specificare le risorse richieste dai pod nei deployment. Il pianificatore può quindi pianificare in modo appropriato il pod. L'affidabilità è notevolmente ridotta se i pod non possono essere programmati.

• Impostare i budget di interruzione dei pod: Questa impostazione determina quante repliche in una distribuzione possono essere interrotte durante un evento di aggiornamento o upgrade. Per ulteriori informazioni, consultare il budget di interruzione del Pod.

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

• Impostare le quote di risorse nei namespace di carico di lavoro: La quota di risorse in un namespace aiuta a garantire che le richieste e i limiti dei pod siano impostati correttamente in una distribuzione. Per ulteriori informazioni, consultare Applicare le quote delle risorse.

  Note

  Se si impostano quote di risorse a livello di cluster, possono verificarsi problemi se si distribuiscono carichi di lavoro esterni che non hanno richieste e limiti appropriati. Quando si impostano limiti di utilizzo a livello di spazio dei nomi, si garantisce che vengano applicati solo ai componenti del carico di lavoro.

• Impostare le richieste e i limiti dei pod: Impostare richieste e limiti per consentire a Kubernetes di allocare in modo efficiente risorse di CPU e memoria ai pod. Offre una maggiore densità di contenitore 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 ottimizzare gradualmente tali valori fino a quando non si stabilisce la soglia che causa l'instabilità nel cluster.

  È possibile specificare richieste e limiti nei manifesti della distribuzione. Per altre informazioni, vedere Set di richieste e limiti dei pod.

Zone di disponibilità

Per proteggersi da alcuni tipi di interruzioni, usare availability zones se l'area li supporta. I componenti del piano di controllo e i nodi nei pool di nodi sono quindi a ridondanza di zona, il che significa che vengono distribuiti tra più zone. Se un'intera zona non è disponibile, è ancora disponibile un nodo in un'altra zona all'interno dell'area. Ogni pool di nodi corrisponde a un set di scalabilità di macchine virtuali separato, che gestisce le istanze del nodo e la capacità di scalare. Il servizio AKS gestisce le operazioni e la configurazione dei set di scalabilità. Ecco alcune considerazioni quando si abilitano più zone:

• Intera infrastruttura: Scegliere una regione che supporta le zone di disponibilità. Per altre informazioni, vedere Limitations. Per avere un SLA di disponibilità, è necessario scegliere il livello Standard o Premium. Il contratto di servizio per il tempo di attività è più elevato quando si utilizzano le zone di disponibilità.

• Cluster: È possibile impostare availability zones 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 in tutte le zone.

  La ridondanza della zona non si applica solo ai pool di nodi, ma anche al piano di controllo. Il piano di controllo di AKS si estende sulle zone richieste, come i pool di nodi. Se non si usa il supporto per le zone nel cluster, i componenti del piano di controllo non sono garantiti per la distribuzione tra le zone di disponibilità.

• Risorse dipendenti: Per ottenere il vantaggio in termini di resilienza dato dall'utilizzo delle availability zones, tutte le dipendenze dei servizi devono supportare anch'esse le zone. Se un servizio dipendente non supporta le zone, è possibile che un guasto di zona possa causare un guasto del servizio.

  Si supponga, ad esempio, che il carico di lavoro usi un database che non sia resiliente alla zona. Se si verifica un errore, il nodo del servizio Azure Kubernetes potrebbe passare a un'altra zona, ma il database non si sposta con il nodo in tale zona, in modo che il carico di lavoro venga interrotto.

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

Più aree geografiche

Quando si abilitano le zone di disponibilità, non garantisce una copertura sufficiente nel caso improbabile in cui un'intera regione si guasti. Per ottenere una maggiore disponibilità, eseguire più cluster AKS in regioni diverse.

• Preferisci aree abbinate quando sono disponibili. Un vantaggio dell'uso delle aree abbinate è l'affidabilità durante gli aggiornamenti della piattaforma. Azure assicura che venga aggiornata una sola regione della coppia 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 consegna continua (CI/CD), configurata per orchestrare il ripristino da un guasto regionale. Strumenti DevOps specifici come Flux possono semplificare le distribuzioni in più aree.

• Specificare il percorso in cui il servizio ridondante ha l'istanza secondaria se una risorsa Azure supporta la ridondanza geografica. Ad esempio, abilitando la replica geografica per Registro Contenitori, le immagini vengono replicate automaticamente nelle aree Azure selezionate. Fornisce anche accesso continuo alle immagini anche se la regione primaria riscontra un'interruzione.

• 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 nonWeb tra zone. Se è necessario distribuire il traffico tra aree, prendere in considerazione Frontdoor di Azure. Per altre opzioni, vedere Scegliere un load balancer.

Ripristino di emergenza

Idealmente, se si verifica un errore nell'area primaria, è possibile passare rapidamente a un'istanza in un'altra area. È possibile pre-creare un cluster o attendere di crearlo fino a quando non è necessario. Prendi in considerazione le seguenti raccomandazioni:

• Utilizzare più aree geografiche. Se la regione primaria ha una regione abbinata, usare quella coppia. In caso contrario, selezionare le aree in base ai requisiti di residenza e latenza dei dati.

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

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

• Configurare ogni servizio Azure usando funzionalità che supportano il ripristino di emergenza. Ad esempio, in questa architettura, il registro dei container è abilitato per la replica geografica. Se un'area geografica non è disponibile, il failover basato sullo stato di integrità di Azure Container Registry (ACR) reindirizza automaticamente le richieste di pull a una replica integra tramite l'endpoint globale, senza richiedere modifiche alla configurazione del cluster.

• Distribuire l'infrastruttura come codice, inclusi il cluster AKS 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 configurare un nuovo cluster e restituirlo allo stato operativo tramite il bootstrap del cluster basato su GitOps, 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 trasferimento dello stato delle risorse del cluster a una destinazione a scelta e del coordinamento delle snapshot su disco di volumi persistenti 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 AKS per fornire un'implementazione gestita di Velero. L'estensione di backup AKS supporta il backup di risorse Kubernetes e volumi permanenti, con pianificazioni e ambito di backup esternalizzati come configurazione del vault in Backup di Azure.

L'implementazione di riferimento non implementa il backup, che implica risorse aggiuntive Azure per gestire, monitorare, acquistare e proteggere. Queste risorse possono includere un account Archiviazione di Azure, una cassetta di sicurezza di Backup di Azure e una configurazione, e la funzionalità di trusted access. La combinazione di GitOps e l'intenzione di eseguire un carico di lavoro senza stato rappresenta la soluzione di ripristino.

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

Se è necessario supportare carichi di lavoro con stato e adottare AKS Backup, usare Criteri di Azure per imporre che il backup sia configurato nel cluster. Monitoraggio di Azure mostra lo stato di integrità dei processi di backup tramite lo stesso stack di osservabilità già presente in questa architettura. Oltre a tale governance, tenete conto delle seguenti considerazioni architetturali nella progettazione:

• Ambito del backup. Decidere se eseguire il backup dell'intero cluster o di spazi dei nomi specifici. AKS Backup archivia i dati in un contenitore BLOB e sotto forma di snapshot di dischi o di file. Definisci questo ambito fin dall'inizio, perché determina il dimensionamento dell'account di archiviazione, i criteri di conservazione e la granularità del ripristino per scenari quali il ripristino operativo, la clonazione dell'ambiente e gli aggiornamenti del cluster.
• Accesso attendibile. Il backup del servizio Azure Kubernetes richiede l'accesso attendibile tra l'insieme di credenziali di backup e il cluster del servizio Azure Kubernetes, indipendentemente dal fatto che il cluster sia pubblico, privato o con restrizioni IP.
• Autorizzazioni RBAC. L'identità gestita dell'insieme di credenziali di Backup richiede una serie di autorizzazioni nel cluster AKS per configurare ed eseguire i backup. L'estensione di backup crea anche un'identità utente con autorizzazioni per l'account di archiviazione in cui vengono archiviati i backup.
• Uscita di rete. L'estensione di backup comunica con i servizi di Backup di Azure all'interno del cluster. Tenere conto degli endpoint in uscita necessari nelle regole Firewall di Azure e NSG.
• Ingombro nel cluster. L'estensione distribuisce i pod sui tuoi nodi. Pianifica il consumo aggiuntivo di risorse di calcolo e memoria nel budget delle risorse del nodo e includi il namespace dell’estensione nella governance delle policy di rete.

SLA del server API di Kubernetes

È possibile utilizzare AKS come servizio gratuito, ma questo livello non fornisce un contratto di servizio con garanzia 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 ai cluster di preproduzione e il livello Premium solo ai carichi di lavoro cruciali per la missione. Quando si usano le zone di disponibilità di Azure, l'SLA del server API Kubernetes è superiore. I pool di nodi e le altre risorse sono coperti dai propri contratti di servizio.

Per altre informazioni sui contratti di servizio specifici per ogni servizio, vedere SLA 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, si prevede una piccola quantità di latenza di rete aggiuntiva nella comunicazione tra le zone e una latenza più significativa nella comunicazione tra aree. Misurare l'effetto di questa decisione architetturale sul carico di lavoro.

Testare 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 altre informazioni, vedere Chaos Studio.

Monitorare e raccogliere log e metriche

È consigliabile usare i servizi di monitoraggio Monitoraggio di Azure Kubernetes per monitorare le prestazioni dei carichi di lavoro dei contenitori perché è possibile visualizzare gli eventi in tempo reale. Monitoraggio di Azure 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 Monitoraggio di Azure per monitorare le prestazioni mentre i pod si espandono. Include dati di telemetria fondamentali per il monitoraggio, l'analisi e la visualizzazione dei dati raccolti.

Abilitare la raccolta di log dai pod

Lo schema del log ContainerLogV2 è progettato per acquisire i log dei contenitori dai pod Kubernetes in un approccio semplificato. Le voci di log vengono consolidate nella tabella ContainerLogV2 in un'area di lavoro Log Analytics di Azure.

In un cluster AKS, sono disponibili due metodi principali per configurare la raccolta di log dei pod. Entrambi gli approcci consentono di personalizzare le impostazioni. È possibile filtrare gli spazi dei nomi, modificare gli intervalli di raccolta, abilitare o impedire funzionalità specifiche (ad esempio ContainerLogV2 o ContainerLogV2-HighScale) e specificare i flussi di dati da raccogliere.

• Se sono necessarie configurazioni di monitoraggio centralizzate e riutilizzabili in più cluster o si preferisce che la configurazione del cluster venga esternalizzata nelle risorse native di Azure, usare regole di raccolta dati (DCR). DCR sono risorse Azure che il piano di controllo di Azure Resource Manager gestisce in modo nativo, ed è possibile includerle nei file Bicep. L'implementazione di riferimento usa DCRs.

• In alternativa, è possibile definire il monitoraggio usando ConfigMaps, che sono oggetti YAML Kubernetes non conformi configurati tramite il piano di controllo dell'API Kubernetes. L'Agente Monitoraggio di Azure, che viene eseguito nel cluster, monitora gli oggetti ConfigMap. Usa impostazioni predefinite per determinare quali dati raccogliere.

Quando entrambi i metodi sono abilitati, le impostazioni ConfigMap hanno la precedenza sui DCR. Evitare di combinare la configurazione configMap e DCR per la raccolta di log dei contenitori, perché può causare problemi di registrazione difficili da risolvere.

Avvisi e metriche di Prometheus

Le interruzioni e i malfunzionamenti rappresentano rischi significativi per le applicazioni del carico di lavoro, che rende essenziale identificare in modo proattivo i problemi correlati all'integrità e alle prestazioni dell'infrastruttura. Quando si monitora l'ambiente e si agisce su ciò che si apprende, si riducono le interruzioni e si migliora l'affidabilità della soluzione. Per prevedere potenziali condizioni di errore nel cluster, abilitare le regole di avviso Prometheus consigliate per Kubernetes.

La maggior parte dei carichi di lavoro ospitati nei pod genera metriche di Prometheus. Monitoraggio di Azure può integrarsi con Prometheus. È possibile visualizzare le metriche dell'applicazione e del carico di lavoro raccolte da contenitori, pod, nodi e cluster.

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.

Log dell'infrastruttura di Azure e del piano di controllo Kubernetes

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

• ClusterAutoscaler: Ottenere visibilità nelle operazioni di ridimensionamento tramite il logging. Per ulteriori informazioni, consultare Recuperare i registri e lo stato dell'autoscaler del cluster.

• KubeControllerManager: Acquisire 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 è necessario abilitare entrambi kube-audit e kube-audit-admin perché kube-audit è un superset che include anche operazioni nonmodifica (lettura).

• guard: Acquisisci audit di Microsoft Entra ID e Azure RBAC.

Può essere utile abilitare altre categorie di log, ad esempio KubeScheduler o kube-audit, durante lo sviluppo iniziale del ciclo di vita del cluster o del carico di lavoro. La scalabilità automatica dei cluster aggiunta, insieme al posizionamento e alla pianificazione dei pod, oltre a dati simili, possono aiutarti a 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.

Monitoraggio di Azure include un set di query di log esistenti con cui iniziare, ma è anche possibile utilizzarli come base per creare le proprie query. Man mano che la libreria cresce, è possibile salvare e riutilizzare le query di log usando uno o più pacchetti query. La libreria personalizzata di query offre una maggiore osservabilità rispetto all'integrità e alle prestazioni dei cluster AKS. Supporta il raggiungimento dei tuoi SLO.

Per ulteriori informazioni sulle migliori pratiche di monitoraggio per AKS, vedere Monitorare AKS con Monitoraggio di Azure.

Metriche di rete

Le metriche di rete di base a livello di cluster sono disponibili tramite metriche native platform e Prometheus. È possibile usare ulteriormente il servizio Azure Kubernetes node network metrics per esporre le metriche di rete a livello di nodo usando le metriche di Prometheus. La maggior parte dei cluster deve includere l'osservabilità della rete per fornire funzionalità aggiuntive per la risoluzione dei problemi di rete e per rilevare problemi o utilizzo imprevisto della rete a livello di nodo.

L'implementazione di riferimento usa Monitoraggio di Azure, che raccoglie anche alcune metriche correlate alla rete. L'implementazione di riferimento impedisce la raccolta diretta di alcune metriche di rete da Monitoraggio di Azure e raccoglie invece le metriche di osservabilità di rete usando un'area di lavoro Monitoraggio di Azure con Managed Prometheus.

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 Service (AKS) è possibile accedere a queste metriche dettagliate usando la funzionalità Servizi di rete contenitore avanzati. La maggior parte dei carichi di lavoro non richiede questa profondità di osservabilità della rete. Non è consigliabile abilitare l'osservabilità avanzata della rete, a meno che i pod non richiedano una rete altamente ottimizzata, con sensibilità al livello di pacchetto.

Ottimizzazione dei costi per il logging

L'implementazione di riferimento configura la tabella ContainerLogV2 per l'uso del piano Basic come punto di partenza. Microsoft Defender per i contenitori e gli avvisi creati per l'implementazione di riferimento non eseguono query su questa tabella, pertanto è probabile che il piano Basic sia conveniente perché riduce i costi di inserimento.

Man mano che i requisiti di volume di log e query si evolvono, selezionare il piano tabellare più conveniente per le proprie esigenze. Se la soluzione diventa a elevato utilizzo di lettura, in cui le query analizzano frequentemente i dati della tabella, il piano di analisi predefinito potrebbe essere più adatto. Il piano di analisi elimina gli addebiti per le query, ottimizzati per gli scenari in cui l'attività di query supera i costi di inserimento. Quando si monitorano i modelli di utilizzo e si modificano i piani di tabella in base alle esigenze, è possibile ottenere un equilibrio tra costi e funzionalità per la soluzione di monitoraggio.

Per altre informazioni, vedere Selezionare un piano di tabella in base all'utilizzo dei dati in un'area di lavoro Log Analytics.

Abilitare la riparazione automatica

Monitorare l'integrità dei pod impostando sonde di attività e disponibilità. Se il sistema Kubernetes rileva un pod che non risponde, riavvierà il pod. Una verifica di vitalità determina se il pod è in salute. Se il sistema Kubernetes rileva un pod che non risponde, riavvierà il pod. Una sonda di prontezza determina se il pod è pronto per ricevere richieste e traffico.

Aggiornamenti di routine per i cluster AKS

Parte delle operazioni di giorno-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:

• La versione di Kubernetes (ad esempio Kubernetes 1.32.3 a 1.32.7 o Kubernetes da 1.32.7 a 1.33.1), che potrebbe essere disponibile con le modifiche e le deprecazioni 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 degli aggiornamenti dei componenti AKS. 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 cadenza con cui ogni cluster AKS, i relativi pool di nodi o i relativi nodi vengono aggiornati (cadenza). 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 sull'aggiornamento, vedere la guida su patch e aggiornamenti di AKS nella guida operativa di secondo giorno di AKS. 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 e l'aggiornamento automatico del cluster su none. In questa configurazione, l'utente è responsabile esclusivamente di tutti gli aggiornamenti a tutti i livelli.

Quando un aggiornamento desiderato diventa disponibile, è necessario eseguire la procedura seguente:

1. Testare l'aggiornamento in un ambiente di preproduzione e valutarne la compatibilità in un nuovo cluster.

2. Distribuire un replicatore di produzione che includa la versione aggiornata di Azure Kubernetes Service (AKS) e i dischi virtuali VHD del pool di nodi.

3. Quando il nuovo cluster di produzione è pronto, svuotare il vecchio cluster e infine rimuoverlo.

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 operano i cluster AKS di Azure come infrastruttura immutabile devono aggiornare regolarmente i cluster in esecuzione per coprire tutti e tre gli strati. 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.

• Pianifica la funzionalità di manutenzione pianificata di AKS in modo da poter controllare gli aggiornamenti nel tuo 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 i pod disruption budgets 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 Azure quota di risorse 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 Azure quota e spazio indirizzi IP devono essere disponibili per i nuovi nodi. Un valore di impennata del 33% è un buon punto di partenza per la maggior parte dei carichi di lavoro.

• Testare la compatibilità con gli strumenti, come i service mesh o gli agenti di sicurezza aggiunti al cluster. Testare anche 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 VHD in ogni nodo con aggiornamenti specifici per ciascun nodo. Microsoft testa gli aggiornamenti sulla versione di AKS. Per i nodi Windows, gli aggiornamenti vengono eseguiti circa una volta al mese. Per i nodi Linux, gli aggiornamenti vengono eseguiti circa una volta alla settimana.

• Gli aggiornamenti non cambiano mai la versione di AKS o di 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 degli aggiornamenti.

• 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 il AKS release tracker.

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 considerano abbastanza importanti da rilasciare prima del successivo aggiornamento pianificato dell'immagine del nodo. Quando si usa il SecurityPatch canale, si ottengono anche gli aggiornamenti ricevuti dal NodeImage canale. L'opzione del canale SecurityPatch rispetta ancora le finestre di manutenzione, quindi assicurati che la finestra di manutenzione abbia lacune più frequenti (come ogni giorno o un giorno sì e uno no) per supportare questi aggiornamenti imprevisti della sicurezza.

La maggior parte dei cluster che esegue aggiornamenti in loco dovrebbe evitare le opzioni del canale di aggiornamento delle immagini dei nodi None e Unmanaged.

Aggiornamenti diretti del 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 (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 in loco della versione di AKS con la necessaria cautela e il rigore richiesto. Il rischio di eseguire un aggiornamento in loco della versione di Azure Kubernetes Service (AKS) può essere ridotto principalmente tramite test di preproduzione sufficienti, verifica delle quote e configurazione del Pod Disruption Budget. Tuttavia, qualsiasi aggiornamento sul posto può comportare un comportamento imprevisto. Se gli aggiornamenti sul posto sono considerati troppo rischiosi per il carico di lavoro, raccomandiamo di usare un approccio blue-green deployment dei cluster AKS anziché seguire le raccomandazioni rimanenti.

È consigliabile evitare la funzionalità di aggiornamento automatico 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 AKS negli ambienti di preproduzione prima che gli aggiornamenti raggiungano 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 aggiornati" su un approccio supporto a lungo termine.

È possibile ricevere notifiche quando è disponibile una nuova versione del servizio Azure Kubernetes per il cluster usando il sistema AKS per Griglia di eventi di Azure. L'implementazione di riferimento distribuisce questo sistema di Griglia di eventi in modo che sia possibile sottoscrivere l'evento Microsoft.ContainerService.NewKubernetesVersionAvailable dalla soluzione di notifica eventstream. Esaminare le note sulla versione di AKS 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, è raro spostarsi oltre patch. Inoltre, quando si aggiorna automaticamente la versione di AKS, controllare l'impostazione della versione di AKS nell'infrastruttura come codice (IaC) per evitare che le due versioni vadano fuori sincronizzazione. 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. Per altre informazioni, vedere le risorse seguenti:

• Microsoft Defender per contenitori identifica e corregge le raccomandazioni di Defender per il cloud relative alle immagini container.
• Defender per i contenitori analizza le immagini del contenitore per individuare vulnerabilità.
• Defender per contenitori genera anche avvisi di sicurezza in tempo reale per attività sospette.
• Concetti di sicurezza per applicazioni e cluster nel servizio Azure Kubernetes informazioni dettagliate sul modo in cui la sicurezza del contenitore 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 Principi di progettazione dell'eccellenza operativa.

Configurazione iniziale del cluster

Dopo aver configurato il cluster, si tratta di un cluster funzionante, ma potrebbero essere necessari altri passaggi to do prima di poter distribuire i carichi di lavoro. Il processo di preparazione del cluster è denominato bootstrap. Il processo di bootstrapping è spesso costituito dalla distribuzione delle immagini prerequisite nei nodi del cluster, dalla creazione di namespace e dall'esecuzione di altre attività che soddisfano i requisiti del caso d'uso della tua organizzazione.

Per velocizzare la transizione da un cluster appena configurato a uno configurato correttamente, è necessario definire il processo di bootstrap univoco e preparare in anticipo gli asset pertinenti. Ad esempio, se si usa una mesh di servizi come Linkerd o Consul Connect, in genere si distribuisce la mesh prima che i carichi di lavoro dell'applicazione possano essere pianificati. Prima di configurare il cluster, è necessario verificare che le immagini della mesh di servizi esistano in un registro contenitori creato in precedenza. Questa convalida consente di evitare ritardi o errori di distribuzione.

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

• estensione cluster GitOps Flux v2
• Pipelines
• Autoconfigurazione con Flux o Argo CD, ad esempio

Uno dei vantaggi principali dell'uso dell'estensione del cluster GitOps Flux v2 per Azure Kubernetes Service (AKS) è che non c'è effettivamente alcun divario tra un cluster provisionato e un cluster bootstrap. Configura l'ambiente con una solida base di gestione per il futuro e supporta anche l'inclusione del bootstrapping come modelli di risorse per allinearsi alla strategia di IaC.

Quando i manifesti di avvio automatico richiedono valori noti solo in fase di distribuzione, ad esempio un URL del registro contenitori, un nome di Key Vault o un ID client di identità, usare la sostituzione delle variabili di Flux nella configurazione di kustomization. Una kustomization definisce il percorso nel repository Git da riconciliare e quali sostituzioni di variabili post-compilazione applicare. Le kustomization vengono configurate come parte della distribuzione dell'estensione Flux nel modello IaC, dove si definiscono le variabili di sostituzione in modo che i valori vengano risolti a partire dalle risorse distribuite in fase di creazione del cluster. Questo approccio elimina i problemi di intervallo che si verificano quando un oggetto ConfigMap deve esistere prima della prima riconciliazione ed evita di richiedere agli utenti di creare una copia tramite fork del repository esclusivamente per personalizzare i valori specifici dell'ambiente. L'agente di estensione Flux converte questa configurazione IaC in risorse personalizzate Kubernetes riconciliate dal controller Flux Kustomize, applicando le sostituzioni delle variabili durante l'elaborazione di ogni percorso.

Infine, quando si usa l'estensione cluster GitOps Flux v2, kubectl non è necessario per nessuna parte del processo di bootstrap. È possibile riservare l'accesso basato su kubectl per situazioni di emergenza per risolvere problemi rapidi. Tra i modelli per le definizioni di risorse di Azure e il bootstrapping dei manifesti tramite l'estensione GitOps, è possibile eseguire tutte le attività di configurazione standard 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 svilupparlo ulteriormente. Un'attività iniziale consiste nel configurare la rete. Configurare reti virtuali per hub e spoke e configurare anche le subnet all'interno di tali reti. Ad esempio, uno spoke ha subnet separate per i pool di nodi di sistema e utente, le risorse d'ingresso e il server API privato di AKS. 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

Preferisci un metodo dichiarativo idempotente rispetto a 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à. L'implementazione di riferimento usa Bicep, ma è possibile scegliere di usare Terraform o Azure Resource Manager modelli (modelli ARM).

Assicurarsi di configurare le 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 il interfaccia della riga di comando di Azure. Questi comandi coprono una gamma di servizi Azure ed è possibile automatizzarli tramite scripting. Windows e Linux supportano la interfaccia della riga di comando di Azure. 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 costruire e distribuire le applicazioni continuamente. 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 delle immagini dei container di workload al cluster.

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

Sistema di CI/CD del cluster

Scaricare un file 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 nell'inizializzazione 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 le attività seguenti:

• Monitora tutti i repository configurati
• Rileva le nuove modifiche di configurazione
• Avvia distribuzioni
• Aggiorna la configurazione in esecuzione desiderata in base a tali modifiche

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

Il diagramma di esempio seguente illustra come automatizzare la configurazione del cluster con GitOps e Flux.

Scaricare un file 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 garantire 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 access 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.

È consigliabile utilizzare l'estensione del cluster GitOps con Flux v2 per AKS, sebbene sia possibile configurare GitOps e Flux manualmente.

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. Questo processo simula la modifica e potrebbe identificare i problemi prima della distribuzione nell'ambiente di produzione.

Eseguire test e convalide in ogni fase prima di continuare con la fase 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 analogo a quello di produzione, utilizzando 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 nel Well-Architected Framework for AKS. Per indicazioni generali sul carico di lavoro, vedere l'elenco di controllo della revisione del progetto per l'ottimizzazione dei costi.

È possibile trovare una stima dei costi per i componenti usati in questa architettura di base nel calcolatore prezzi Azure. Modificare la stima in modo da includere i componenti necessari per il caso d'uso. Questa stima copre le risorse a livello spoke direttamente associate al cluster. L'infrastruttura hub condiviso, ad esempio Firewall di Azure, le reti virtuali hub e le zone di Azure DNS privato, non è inclusa perché queste risorse sono in genere di proprietà e gestite da un team centrale della piattaforma.

Prendere in considerazione l'uso di analisi dei costi AKS per un'allocazione granulare dei costi dell'infrastruttura del cluster mediante costrutti specifici di Kubernetes.

Provision

• Comprendere da dove provengono i costi. Esistono costi minimi associati ad AKS nella distribuzione, gestione e operazioni del cluster stesso. Ciò che influisce sul costo sono le istanze della macchina virtuale, le storage, 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 Ddv5 è un tipo di macchina virtuale tipico per il pool di nodi di sistema e l'implementazione di riferimento usa lo SKU Standard_D2d_v5.

• Non usare 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 SLA 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, l'SLO potrebbe essere sufficiente. Inoltre, se il carico di lavoro lo supporta, è consigliabile usare pool di nodi spot dedicati che eseguono spot vm.

  Per i carichi di lavoro non di produzione che includono database SQL di Azure o Servizio app di Azure come parte dell'architettura del carico di lavoro di AKS, valuta se sei idoneo a utilizzare le sottoscrizioni Dev/Test di Azure e ricevere sconti sui servizi.

• 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 la capacità completa dei nodi.

• Considera che l'abilitazione della diagnostica sul cluster può comportare un aumento dei costi.

• Impegnarsi a uno o tre anni con le istanze di macchine virtuali riservate di Azure per ridurre i costi del nodo se il carico di lavoro deve essere presente per un lungo periodo. Per altre informazioni, vedere Salvare i costi con istanze di macchina virtuale riservate 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. Se il cluster viene condiviso tra i team, crea report di chargeback per ogni consumatore per identificare i costi calcolati 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 Bandwidth pricing.

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

Monitor

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

• Azure Advisor
• Gestione costi

Monitorare i costi in tempo reale o in base a una pianificazione regolare in modo da poter intervenire prima della fine del mese, quando i costi sono già calcolati. Monitorare le tendenze mensili nel tempo per rimanere entro il 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 Monitoraggio di Azure.

Optimize

Seguire le indicazioni Azure Advisor. Esplorare altri modi per ottimizzare:

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

  Important

  Apportare modifiche rapide o frequenti alle impostazioni di scalabilità automatica del cluster, ad esempio il numero minimo e massimo di nodi per un pool di nodi, per controllare i costi potrebbe causare risultati imprevisti o controproducenti. Ad esempio, se scale-down-unneeded-time è impostato su 10 minuti e le impostazioni minime e massime dei nodi vengono modificate ogni 5 minuti in base alle caratteristiche del carico di lavoro, il numero di nodi non viene mai ridotto. Il calcolo del tempo non necessario per ogni nodo viene reimpostato quando vengono aggiornate le impostazioni del ridimensionamento automatico 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 a scoppio, ottimizzare il cluster analizzando le metriche delle prestazioni nel tempo.

• Se il carico di lavoro lo supporta, ridimensiona i pool di nodi utente a zero nodi quando non si prevede di eseguirli. Se non sono stati eseguiti 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, inclusi il pool di nodi di sistema e il piano di controllo del servizio Azure Kubernetes.

Per altre informazioni, vedere AKS pricing.

Passaggi successivi

• Roadmap di AKS su GitHub

" output is necessary.)

• architettura avanzata dei microservizi AKS
• architettura microservices su AKS
• Usare Firewall di Azure per aiutare a proteggere un cluster AKS
• GitOps per AKS
• Data streaming tramite l'uso di AKS