Questo articolo è destinato a essere considerato come un'estensione per l'architettura baseline del servizio Azure Kubernetes, che fornisce una revisione approfondita delle configurazioni consigliate per distribuire un cluster del servizio Azure Kubernetes in un ambiente di produzione. L'obiettivo di questo articolo è fornire indicazioni relative alla distribuzione di contenitori Windows nel servizio Azure Kubernetes. Di conseguenza, questo articolo è incentrato su queste configurazioni specifiche per la distribuzione di Windows nel servizio Azure Kubernetes ed è necessario fare riferimento alla documentazione della baseline del servizio Azure Kubernetes per le configurazioni già descritte.
Fare riferimento al progetto GitHub di base di Windows del servizio Azure Kubernetes per esaminare l'implementazione di riferimento associata a questa architettura di riferimento, incluso il codice di distribuzione di esempio.
Progettazione della rete
La progettazione di rete usata in questa architettura è basata sulla progettazione usata nell'architettura baseline del servizio Azure Kubernetes e quindi condivide tutti i componenti principali con tale progettazione, ad eccezione delle modifiche seguenti.
- I controller di dominio di Active Directory sono stati aggiunti per supportare i carichi di lavoro basati su Windows.
- La soluzione in ingresso in questa architettura usa Frontdoor di Azure (AFD) e il proxy dell'applicazione Microsoft Entra anziché app Azure Gateway, usato nell'architettura baseline del servizio Azure Kubernetes.
Nota
La migrazione di carichi di lavoro Windows nel servizio Azure Kubernetes in genere non include attività di refactoring importanti e, di conseguenza, i carichi di lavoro potrebbero usare funzionalità relativamente facili da implementare in locale, ma rappresentano una sfida in Azure. Un esempio è un'applicazione che usa l'autenticazione gMSA e Kerberos. Si tratta di un caso d'uso comune e, di conseguenza, questa architettura conduce con componenti che rispondono alle esigenze di tali carichi di lavoro. In particolare, usando il proxy dell'applicazione front-end da AFD come parte del percorso di ingresso. Se il carico di lavoro non necessita di questo supporto, è possibile seguire le stesse indicazioni della baseline del servizio Azure Kubernetes per l'ingresso.
Progettazione in ingresso
Componenti:
- Frontdoor di Azure con WAF: AFD è il punto di ingresso pubblico per le app ospitate nel cluster del servizio Azure Kubernetes. AFD Premium viene usato in questa progettazione perché consente l'uso di collegamento privato, che blocca il traffico interno delle app verso la rete privata, fornendo il massimo livello di sicurezza. Web Application Firewall (WAF) protegge da exploit e vulnerabilità comuni di applicazioni Web.
- Proxy dell'applicazione Microsoft Entra: questo componente funge da secondo punto di ingresso davanti al servizio di bilanciamento del carico interno gestito dal servizio Azure Kubernetes. Dispone di Microsoft Entra ID abilitato per la preautenticazione degli utenti e usa un criterio di accesso condizionale per impedire intervalli IP non autorizzati (il proxy dell'applicazione vede l'IP client di origine, che confronta con i criteri di accesso condizionale) e gli utenti dall'accesso al sito. Questo è l'unico modo per instradare le richieste di autenticazione Kerberos durante l'uso di un servizio di Azure che supporta WAF. Per una descrizione dettagliata dell'accesso Single Sign-On alle app protette da Application Proxy, vedere Delega vincolata Kerberos per l'accesso Single Sign-On (SSO) alle app con Application Proxy
- Servizio di bilanciamento del carico interno: gestito dal servizio Azure Kubernetes. Questo servizio di bilanciamento del carico espone il controller di ingresso tramite un indirizzo IP statico privato. Funge da singolo punto di contatto che riceve richieste HTTP in ingresso.
- In questa architettura non vengono usati controller in ingresso (ad esempio Nginx).
Per implementare questa progettazione, afd deve essere configurato per usare l'URL del proxy di applicazione creato quando l'app viene pubblicata in tale servizio. Questa configurazione indirizza il traffico in ingresso al proxy e consente la preautenticazione.
Nota
La conservazione ip di origine client non è supportata, quindi gli architetti dell'applicazione devono pianificare misure alternative per esternalizzare tale logica all'esterno del cluster per le app che dipendono dall'indirizzo IP di origine.
Topologia di rete
Il diagramma seguente illustra la progettazione della rete hub-spoke usata in questa architettura.
Scaricare un file di Visio di questa architettura.
Topologia del pool di nodi
Questa architettura usa tre pool di nodi: un pool di nodi di sistema che esegue Linux, un pool di nodi utente che esegue Linux e un pool di nodi utente che esegue Windows. I pool di nodi utente Windows e Linux vengono usati per i carichi di lavoro mentre il pool di nodi di sistema viene usato per tutte le configurazioni a livello di sistema, ad esempio CoreDNS.
Flusso del traffico in ingresso
- Il client invia una richiesta HTTPS al nome di dominio:
bicycle.contoso.com. Tale nome è associato al record DNS A per l'indirizzo IP pubblico di Frontdoor di Azure. Questo traffico viene crittografato per assicurarsi che il traffico tra il browser client e il gateway non possa essere controllato o modificato. - Frontdoor di Azure ha un web application firewall integrato (WAF) e negozia l'handshake TLS per
bicycle.contoso.com, consentendo solo crittografie sicure. Il gateway Frontdoor di Azure è un punto di terminazione TLS, perché è necessario elaborare le regole di ispezione WAF ed eseguire regole di routing che inoltrano il traffico al back-end configurato. Il certificato TLS viene archiviato in Azure Key Vault. - AfD instrada la richiesta dell'utente al proxy di app Azure lication. AFD è configurato per consentire solo il traffico HTTPS. L'utente deve eseguire l'autenticazione con Microsoft Entra ID se è abilitata la pre-autenticazione.
- Il proxy dell'app indirizza l'utente al contenitore di app back-end tramite il servizio di bilanciamento del carico del servizio Azure Kubernetes.
Nota
È possibile applicare il traffico TLS end-to-end a ogni hop nel flusso, ma valutare la misurazione delle prestazioni, della latenza e dell'impatto operativo quando si decide di proteggere il traffico da pod a pod. Per la maggior parte dei cluster a tenant singolo, con il controllo degli accessi in base al ruolo appropriato e le procedure avanzate del ciclo di vita dello sviluppo software, è sufficiente forzare la crittografia fino al controller in ingresso e proteggere il back-end con un Web Application Firewall (WAF). Questa configurazione ridurrà al minimo il sovraccarico nella gestione del carico di lavoro e negli effetti sulle prestazioni di rete. I requisiti di conformità e carico di lavoro determinano dove si esegue la terminazione TLS.
Flusso del traffico in uscita
Tutte le indicazioni disponibili nell'articolo Baseline del servizio Azure Kubernetes si applicano qui con una raccomandazione aggiuntiva per i carichi di lavoro di Windows: per sfruttare i vantaggi degli aggiornamenti automatici di Windows Server, non è necessario bloccare i nomi di dominio completi necessari nel set di regole di Firewall di Azure.
Nota
L'uso di pool di nodi separati per carichi di lavoro basati su Linux e Windows richiede l'uso di un selettore di nodo per assicurarsi che quando si distribuisce un determinato carico di lavoro, venga distribuito nel pool di nodi appropriato in base al tipo di carico di lavoro.
Pianificazione degli indirizzi IP
A differenza dei cluster del servizio Azure Kubernetes con pool di nodi Linux, i cluster del servizio Azure Kubernetes con pool di nodi Windows richiedono Azure CNI. L'uso di Azure CNI consente di assegnare a un pod un indirizzo IP da un Rete virtuale di Azure. Il pod può quindi comunicare tramite Azure Rete virtuale proprio come qualsiasi altro dispositivo. Può connettersi ad altri pod, a reti con peering o reti locali usando ExpressRoute o una VPN o ad altri servizi di Azure usando il collegamento privato.
Tutte le indicazioni relative alla pianificazione degli indirizzi IP forniti nell'articolo Architettura di base del servizio Azure Kubernetes si applicano qui, con una raccomandazione aggiuntiva: prendere in considerazione il provisioning di una subnet dedicata per i controller di dominio. Per quanto riguarda il pool di nodi di Windows, è consigliabile separare logicamente i pool di nodi dagli altri pool di nodi tramite subnet separate.
Aggiornamento del pool di nodi
Il processo per l'aggiornamento dei nodi Windows è invariato rispetto alle indicazioni fornite nella documentazione relativa all'aggiornamento delle immagini del nodo del servizio Azure Kubernetes (servizio Azure Kubernetes), ma è consigliabile prendere in considerazione le differenze di pianificazione seguenti per pianificare la frequenza di aggiornamento.
Microsoft fornisce nuove immagini di Windows Server, incluse le patch aggiornate, per i nodi mensili e non esegue alcuna applicazione automatica di patch o aggiornamenti. Di conseguenza, è necessario aggiornare manualmente o a livello di codice i nodi in base a questa pianificazione. L'uso di GitHub Actions per creare un processo cron eseguito in base a una pianificazione consente di pianificare a livello di codice gli aggiornamenti mensili. Le indicazioni fornite nella documentazione collegata in precedenza riflettono i processi dei nodi Linux, ma è possibile aggiornare il file YAML per impostare la pianificazione cron per l'esecuzione mensile anziché biweekly. Dovrai anche modificare il parametro "runs-on" nel file YAML in "windows-latest" per assicurarti di eseguire l'aggiornamento all'immagine di Windows Server più recente.
Per altre indicazioni, vedere la guida dell'operatore del servizio Azure Kubernetes sull'applicazione di patch e l'aggiornamento dei nodi di lavoro.
Nota
È necessario aggiornare i cluster prima di eseguire aggiornamenti del pool di nodi e nodi. Per eseguire l'aggiornamento, seguire le indicazioni relative agli aggiornamenti del cluster.
Considerazioni sulle risorse di calcolo
Le dimensioni delle immagini più grandi associate alle immagini basate su server Windows richiedono la distribuzione di dischi del sistema operativo di dimensioni appropriate nel pool di nodi. L'uso di dischi temporanei del sistema operativo è comunque consigliato per tutti i nodi, tra cui Windows, quindi assicurarsi di comprendere i requisiti di dimensione che è necessario rispettare durante la pianificazione della distribuzione.
Gestione delle identità
I contenitori di Windows non possono essere aggiunti a un dominio, quindi se è necessaria l'autenticazione e l'autorizzazione di Active Directory, è possibile usare account del servizio gestito del gruppo . Per usare l'account del servizio gestito del gruppo, è necessario abilitare il profilo del servizio gestito del gruppo nel cluster del servizio Azure Kubernetes che esegue nodi Windows. Per una revisione completa dell'architettura e una guida sull'abilitazione del profilo, vedere la documentazione del servizio Azure Kubernetes gMSA.
Ridimensionamento di nodi e pod
Le linee guida per il ridimensionamento automatico del cluster sono invariate per i contenitori di Windows. Per indicazioni, vedere la documentazione relativa al ridimensionamento automatico del cluster.
La documentazione del cluster di base descrive gli approcci manuali e di scalabilità automatica disponibili per il ridimensionamento dei pod. Entrambi gli approcci sono disponibili per i cluster che eseguono contenitori Windows e le indicazioni fornite in questo articolo si applicano anche qui.
Ciò che differisce tra i contenitori Linux e Windows rispetto alle operazioni di ridimensionamento dei pod è la dimensione dell'immagine nella maggior parte dei casi. Le dimensioni maggiori delle immagini dei contenitori di Windows aumentano probabilmente la quantità di tempo per il completamento delle operazioni di ridimensionamento e pertanto è consigliabile prendere alcune considerazioni sull'approccio di ridimensionamento. Questo scenario è comune alle applicazioni .NET legacy a causa delle dimensioni del runtime .NET. Per ridurre i ritardi nel pull dell'immagine durante i tempi di ridimensionamento, è possibile usare un DaemonSet per eseguire il pull dell'immagine da Registro Azure Container alla cache in ogni nodo di Windows e quindi attivare i pod con l'immagine precaricata. A questo punto, i pod devono essere eseguiti solo tramite i processi di configurazione delle app definiti per il carico di lavoro prima di essere portati online.
Gli esercizi di benchmarking devono essere eseguiti per comprendere l'impatto temporale delle operazioni di ridimensionamento e questi dati devono essere ponderati rispetto ai requisiti aziendali. Se il carico di lavoro deve essere ridimensionato più velocemente di quanto sia possibile tramite la scalabilità automatica, è consigliabile prendere in considerazione la soluzione alternativa "hot spare" seguente:
È prima necessario eseguire test di base per identificare il numero di pod che è necessario eseguire nei periodi di carico di picco e nei tempi di caricamento non di punta. Con questa baseline stabilita, è possibile pianificare il conteggio dei nodi per tenere conto del numero totale di nodi che sarà necessario avere a disposizione in qualsiasi momento. Questa soluzione prevede l'uso del ridimensionamento manuale per il cluster e l'impostazione del numero iniziale di nodi sul numero massimo di nodi necessari. Quando si avvicina un periodo di tempo di picco, è necessario ridimensionare in modo preliminare il numero di tempo di caricamento massimo dei nodi. Con il passare del tempo, è necessario ristabilire regolarmente la baseline per tenere conto della modifica dell'utilizzo delle app o di altri requisiti aziendali.
Monitoraggio
I contenitori che eseguono Windows possono essere monitorati con Monitoraggio di Azure e Informazioni dettagliate sui contenitori, in modo analogo ai contenitori Linux. Di conseguenza, le indicazioni disponibili nell'articolo Baseline del servizio Azure Kubernetes si applicano anche qui per la maggior parte. Tuttavia, il monitoraggio di Container Insights per un cluster Windows Server presenta le limitazioni seguenti:
- Windows non dispone di una metrica RSS memoria. Di conseguenza, non è disponibile per nodi e contenitori di Windows. La metrica Working Set è disponibile
- Le informazioni sulla capacità di archiviazione su disco non sono disponibili per i nodi Windows.
È anche possibile aggiungere complimenti a Container Insights usando le regole di raccolta dati per raccogliere gli eventi e i contatori delle prestazioni dai sistemi Windows Server.
Nota
Informazioni dettagliate sui contenitori per il sistema operativo Windows Server 2022 è disponibile in anteprima pubblica.
Gestione dei criteri
Tutte le indicazioni sui criteri disponibili nell'articolo di base del servizio Azure Kubernetes si applicano ai carichi di lavoro Windows. Altri criteri specifici di Windows disponibili nelle definizioni predefinite di Criteri di Azure per servizio Azure Kubernetes articolo di riferimento da considerare sono:
- I contenitori Di Windows del cluster Kubernetes non devono sovracommettere CPU e memoria
- I contenitori windows del cluster Kubernetes non devono essere eseguiti come ContainerAdministrator
- I contenitori windows del cluster Kubernetes devono essere eseguiti solo con utenti approvati e gruppo di utenti di dominio
Bootstrap del cluster
Come per il bootstrap del cluster fornito nell'articolo Baseline del servizio Azure Kubernetes, gli operatori del cluster devono considerare anche l'approccio di bootstrap per i carichi di lavoro basati su Windows. Le stesse indicazioni fornite nell'articolo Baseline del servizio Azure Kubernetes si applicano anche qui.
Gestione costi
Tutte le linee guida per l'ottimizzazione dei costi disponibili nell'articolo Baseline del servizio Azure Kubernetes si applicano ai carichi di lavoro Windows. Altre considerazioni relative ai costi da tenere in considerazione sono:
- I costi di licenza per Windows Server aumentano il costo dei nodi per il cluster del servizio Azure Kubernetes. Le raccomandazioni per l'ottimizzazione dei costi per questo fattore includono la prenotazione della capacità o l'uso di licenze esistenti se sono già disponibili per altri usi aziendali.
- Vedere la documentazione Vantaggio Azure Hybrid per Windows Server (AHUB) per informazioni sugli sconti per le licenze di Windows Server applicabili a Software Assurance (SA).
- Vedere le domande frequenti sui contenitori di Windows Server per istruzioni sull'applicazione del vantaggio ai cluster nuovi ed esistenti.
- Le dimensioni delle immagini del contenitore di Windows possono comportare costi aggiuntivi Registro Azure Container (ACR) a causa della quantità di spazio di archiviazione necessaria per più immagini, il numero di nodi simultanei che eseguono il pull dai requisiti di Registro Azure Container e replica geografica.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Isabelle Bersano | Cloud Solution Architect
- Akshay Nimbalkar | Principal Cloud Solution Architect
- Clayton Siemens | Sviluppatore di contenuti principale
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Altre informazioni sui contenitori di Windows
Risorse correlate
- Informazioni su come distribuire pool di nodi Windows in un cluster del servizio Azure Kubernetes