Archivi categoria: Azure Kubernetes

Realizzare architetture IT moderne per il Machine Learning

Per la maggior parte delle realtà aziendali, la capacità di fornire e di integrare continuamente soluzioni di intelligenza artificiale all’interno delle proprie applicazioni e nei workflow aziendali, viene considerata un’evoluzione particolarmente complessa. Nel panorama dell’intelligenza artificiale in rapida evoluzione il machine learning (ML) ricopre un ruolo fondamentale insieme alla “data science”. Pertanto, per aumentare i successi di determinati progetti di intelligenza artificiale, le organizzazioni devono disporre di architetture IT moderne ed efficienti per il machine learning. In questo articolo viene descritto come è possibile realizzare ovunque queste architetture grazie all’integrazione tra Kubernetes, Azure Arc ed Azure Machine Learning.

Azure Machine Learning

Azure Machine Learning (AzureML) è un servizio cloud che è possibile utilizzare per accelerare e gestire il ciclo di vita dei progetti di machine learning, portando i modelli di ML in un ambiente di produzione sicuro ed affidabile.

Kubernetes come destinazione di calcolo per Azure Machine Learning

Azure Machine Learning ha recentemente introdotto la possibilità di attivare una nuova destinazione per il calcolo computazionale: AzureML Kubernetes compute. Infatti, risulta possibile utilizzare un cluster Azure Kubernetes Service (AKS) esistente oppure un cluster Kubernetes abilitato per Azure Arc come destinazione di calcolo per Azure Machine Learning e utilizzarlo per validare e per distribuire modelli di ML.

Figura 1 – Panoramica su come portare Azure ML ovunque grazie a K8s ed Azure Arc

AzureML Kubernetes compute supporta due tipi di cluster Kubernetes:

Cluster AKS (in ambiente Azure). Utilizzando un cluster gestito Azure Kubernetes Service (AKS), è possibile ottenere un ambiente flessibile, sicuro ed in grado di soddisfare i requisiti di conformità per i workload di ML.
Cluster Kubernetes Arc-enabled (in ambienti differenti da Azure). Grazie ad Azure Arc-enabled Kubernetes risulta possibile gestire da Azure cluster Kubernetes in esecuzione in ambienti differenti (on-premises o su altri cloud) e utilizzarli per distribuire modelli di ML.

Per abilitare e utilizzare un cluster Kubernetes per eseguire workload AzureML è necessario seguire i seguenti passaggi:

Attivare e configurare un cluster AKS oppure un cluster Kubernetes Arc-enabled. A questo proposito si ricorda anche la possibilità di attivare AKS in ambiente Azure Stack HCI.
Distribuire l’estensione AzureML sul cluster.
Collegare il cluster Kubernetes al workspace di Azure ML.
Utilizzare la destinazione di calcolo Kubernetes da CLI v2, SDK v2 e la Studio UI.

Figura 2 – Step per abilitare e per utilizzare un cluster K8s per workload AzureML

La gestione dell’infrastruttura per i workload di ML può risultare complessa e Microsoft consiglia che venga eseguita dal team IT-operations, in modo che il team di data science possa concentrarsi sull’efficienza dei modelli di ML. Alla luce di questa considerazione, la suddivisione dei ruoli può essere la seguente:

Il Team IT-operation è responsabile dei primi 3 passaggi riportati in precedenza. Inoltre, solitamente svolge le seguenti attività per il team di data science:
- Effettua le configurazioni degli aspetti legati al networking ed alla sicurezza
- Crea e gestisce le tipologie di istanze per i diversi scenari di carico di lavoro di ML al fine di ottenere un utilizzo efficiente delle risorse di calcolo.
- Si occupa della risoluzione dei problemi relativi al carico di lavoro dei cluster Kubernetes.
Il Team di data science, concluse le attività di attivazione in carico al Team IT-operation, può individuare un elenco di destinazioni di calcolo e di tipologie di istanza disponibili nel workspace di AzureML. Queste risorse di calcolo possono essere usate per i workload di training oppure di inferenza. La destinazione di calcolo viene scelta dal team utilizzando gli strumenti specifici come AzureML CLI v2, Python SDK v2 oppure Studio UI.

Scenari d’uso

La possibilità di utilizzare Kubernetes come destinazione di calcolo per Azure Machine Learning, unita alle potenzialità di Azure Arc, consente di creare, sperimentare e distribuire modelli di ML in qualsiasi infrastruttura on-premises oppure su differenti cloud.

Questa possibilità attiva differenti nuovi scenari di utilizzo, precedentemente impensabili utilizzando solo l’ambiente cloud. La tabella seguente fornisce un riepilogo degli scenari d’uso resi possibili da Azure ML Kubernetes compute, specificando la posizione in cui risiedono i dati, la motivazione che guida ogni modello di utilizzo e come viene realizzato a livello di infrastruttura e di Azure ML.

Tabella 1 – Nuovi scenari d’uso resi possibili da Azure ML Kubernetes compute

Conclusioni

Gartner prevede che entro il 2025, a causa di una rapida diffusione di iniziative in ambito dell’IA, il 70% delle organizzazioni avrà reso operative architetture IT per l’intelligenza artificiale. Microsoft, grazie all’integrazione tra differenti soluzioni offre una serie di possibilità per attivare architetture flessibili e all’avanguardia per il Machine Learning, parte integrante dell’intelligenza artificiale.

Come accelerare il processo di application modernization grazie ad Azure

Diverse sono le realtà aziendali che intraprendono un processo di trasformazione digitale incentrato sul cloud pubblico con l’obiettivo di aumentare l’innovazione, l’agilità e l’efficienza operativa. Nell’ambito di questo percorso, la modernizzazione delle applicazioni sta diventando rapidamente una pietra miliare che consente di ottenere importanti benefici. In questo articolo viene approfondito come è possibile intraprendere ed accelerare il processo di modernizzazione delle applicazioni con le soluzioni disponibili in Microsoft Azure e quali opportunità è possibile cogliere.

Microsoft Azure offre la flessibilità di scegliere tra un’ampia gamma di opzioni per ospitare le proprie applicazioni, coprendo lo spettro di Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Container-as-a-Service (CaaS) e serverless.

La tendenza a sviluppare applicazioni moderne, che necessitano di architetture basate su microservizi, rendono i container la soluzione ideale per eseguire il deployment del software in modo efficiente ed operare su larga scala. Oltra alla possibilità di effettuare deployment consistenti, affidabili e ripetibili in tutti gli ambienti si può ottenere un migliore utilizzo dell’infrastruttura ed una standardizzazione delle pratiche di gestione.

Inoltre, i clienti possono utilizzare sempre più i container anche per le applicazioni non appositamente progettate per utilizzare architetture basate su microservizi. In questi casi è possibile attuare una strategia di migrazione delle applicazioni esistenti che prevede solo modifiche minimali del codice dell’applicazione oppure modifiche alle configurazioni. Si tratta di modifiche strettamente necessarie per ottimizzare l’applicazione al fine di essere ospitata su soluzioni PaaS e CaaS.

Questa tecnica di migrazione viene solitamente utilizzata quando:

Si vuole sfruttare una base di codice esistente
La portabilità del codice è importante
L’applicazione può essere facilmente pacchettizzata per essere eseguita in ambiente Azure
L’applicazione deve essere più scalabile e deve esserci la possibilità di essere distribuita più velocemente
Si vuole promuovere l’agilità aziendale mediante un’innovazione continua adottando tecniche DevOps

Application repackage con Azure Migrate: App Containerization

Per facilitare questo processo di migrazione è possibile utilizzare la soluzione Azure Migrate che include molti strumenti e funzionalità, tra i quali il tool App Containerization. Tale strumento offre un approccio definito “point-and-containerize” per effettuare il “repackage” delle applicazioni utilizzando i container e apportando, solo se necessario, delle modifiche minimali al codice. Lo strumento attualmente supporta la containerizzazione di applicazioni ASP.NET e applicazioni Web Java in esecuzione su Apache Tomcat.

Figura 1 – Funzionalità di modernizzazione delle applicazioni adottando Azure Migrate: App Containerization

Lo strumento App Containerization consente di effettuare le seguenti attività:

Connettersi remotamente agli application server per rilevare le applicazioni e le relative configurazioni.
Parametrizzare le configurazioni e le dipendenze applicative, come ad esempio le stringhe di connessione ai database, per consentire di effettuare deployment consistenti e ripetibili.
Esternalizzare eventuali contenuti statici e gli stati archiviati sul file system, spostandoli su storage persistente.
Creare e pubblicare le immagini dei container usando Azure Container Registry.
Personalizzare e riutilizzare gli artefatti generati dagli strumenti come Dockerfile, le immagini dei container e i file di definizione delle risorse Kubernetes. Questo permette di integrali direttamente nella pipeline di continuous integration e continuous delivery (CI/CD).

Inoltre, in Azure Migrate: App Containerization è previsto l’utilizzo di Azure Key Vault per gestire i secret e l’integrazione automatica per effettuare il monitor delle applicazioni Java con Azure Application Insights.

Azure App Service vs Azure Kubernetes Service (AKS): quale scegliere?

App Containerization consente di migrare le applicazioni in container utilizzando Azure App Service oppure Azure Kubernetes Service (AKS). Nei paragrafi seguenti vengono riportate alcune considerazioni per valutare quale servizio è più idoneo per ospitare le proprie applicazioni.

Azure App Service: Azure Web App for Containers

Per carichi di lavoro web-based esiste la possibilità di far eseguire i container dagli Azure App Service, la piattaforma Azure di web hosting, utilizzando il servizio Azure Web App for Containers, con il vantaggio di poter sfruttare le metodologie di distribuzione, scalabilità e monitor intrinseche nella soluzione.

I task di automazione e gestione di un numero elevato di container e le modalità con le quali questi interagiscono applicativamente tra di loro è noto come orchestrazione. Nel caso quindi ci sia la necessità di orchestrare più containers è necessario adottare soluzioni più sofisticate come Azure Kubernetes Service (AKS).

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) è il servizio Azure completamente gestito che permette l’attivazione di un cluster Kubernetes.

Kubernetes, conosciuto anche come “k8s”, provvede all’orchestrazione automatizzata dei container, migliorandone l’affidabilità e riducendo il tempo e le risorse necessarie in ambito DevOps. Kubernetes tende a semplificare i deployment, permettendo di eseguire automaticamente le implementazioni ed i rollback. Inoltre, permette di migliorare la gestione delle applicazioni e di monitorare lo stato dei servizi per evitare errori in fase di implementazione. Tra le varie funzionalità sono previsti controlli di integrità dei servizi, con la possibilità di riavviare i container che non sono in esecuzione oppure che risultano bloccati, permettendo di annunciare ai client solo i servizi correttamente avviati. Kubernetes permette inoltre di scalare automaticamente in base all’utilizzo ed esattamente come i container, permette di gestire in maniera dichiarativa l’ambiente cluster, consentendo una configurazione controllata a livello di versione e facilmente replicabile.

Figura 2 – Esempio di architettura a microservizi basata su Azure Kubernetes Service (AKS)

Passaggio successivo: innovare utilizzando soluzioni moderne per le applicazioni

La tecnica di migrazione descritta nei paragrafi precedenti spesso risulta anche il primo passo per intraprendere un’ulteriore modernizzazione dell’applicazione che comporta una riprogettazione. Infatti, lo step successivo consiste nel modificare oppure estendere l’architettura e la base di codice dell’applicazione esistente, andandola ad ottimizzare per la piattaforma cloud. Quando si integrano le moderne piattaforme applicative nella strategia di adozione del cloud, l’innovazione non si limita ai container. Questa integrazione offre una importante innovazione che comporta anche l’adozione di strategie ibride e multicloud.

Figura 3 – Innovazione data dalle piatteforme applicative moderne

Conclusioni

Esiste una tendenza chiara e in continua crescita che vede una modernizzazione degli applicativi rivolta a garantire una maggiore flessibilità, una riduzione del footprint dell’infrastruttura e la possibilità di beneficiare dell’innovazione data dal cloud. Questa modernizzazione non necessariamente deve passare fin da subito da una strategia di rebuild dell’applicazione da zero prevedendo l’utilizzo di tecnologie cloud-native, ma può avvenire in modo graduale. Grazie allo strumento App Containerization di Azure Migrate è possibile intraprendere il percorso di modernizzazione con un approccio semplice che consente di beneficare rapidamente delle potenzialità offerte dalle soluzioni cloud. Inoltre, la consapevolezza che Azure mette a disposizione diverse soluzioni di infrastruttura per ospitare le applicazioni moderne facilita il viaggio di modernizzazione degli applicativi.

Azure Kubernetes Service in ambiente Azure Stack HCI

La soluzione hyper-converged Azure Stack HCI permette di attivare in ambiente on-premises l’orchestratore Azure Kubernetes Service (AKS) per l’esecuzione di applicazioni containerizzate su larga scala. In questo articolo viene approfondito come Azure Kubernetes in ambiente Azure Stack HCI offre la possibilità di ospitare nel proprio datacenter container Linux e Windows, andando ad esplorare i principali benefici di questa soluzione.

Prima di entrare nello specifico di AKS in ambiente Azure Stack si riporta un riepilogo delle soluzioni coinvolte.

Che cos’è Kubernetes?

Deployment tendenzialmente più semplici che permettono di eseguire implementazioni e rollback in modo automatico.
Migliore gestione delle applicazioni con la possibilità di monitorare lo stato dei servizi per evitare errori in fase di implementazione. Infatti, tra le varie funzionalità sono previsti controlli di integrità dei servizi, con la possibilità di riavviare i container che non sono in esecuzione oppure che risultano bloccati, permettendo di annunciare ai client solo i servizi correttamente avviati.
Possibilità di scalare automaticamente in base all’utilizzo e, esattamente come per i container, gestire in maniera dichiarativa l’ambiente cluster, consentendo una configurazione controllata a livello di versione e facilmente replicabile.

Figura 1 – Cluster Kubernetes con i relativi componenti dell’architettura

Che cos’è Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) è il servizio Azure completamente gestito che permette l’attivazione di un cluster Kubernetes, ideale per semplificare il deployment e la gestione di architetture basate su microservizi. Grazie alle funzionalità offerte da AKS è possibile scalare automaticamente in base all’utilizzo, utilizzare controlli per garantire l’integrità dei servizi, implementare politiche di bilanciamento del carico e gestire i secret. L’utilizzo di questo servizio gestito viene integrato con le pipeline di sviluppo e di deployment dei container.

Figura 2 – Esempio di architettura di Azure Kubernetes Service (AKS)

Che cos’è Azure Stack HCI?

Azure Stack HCI è la soluzione che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione di workloads in ambiente on-premises e che prevede una connessione strategica ai servizi di Azure. Si tratta di una infrastruttura hyper-converged (HCI), dove vengono rimossi diversi componenti hardware, sostituti dal software, in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione. In questo modo si ha un passaggio da una tradizionale infrastruttura “three tier”, composta da switch di rete, appliance, sistemi fisici con a bordo hypervisor, storage fabric e SAN, verso infrastrutture hyper-converged (HCI).

Figura 3 – “Three Tier” Infrastructure vs Hyper-Converged Infrastructure (HCI)

Che cos’è AKS in Azure Stack HCI?

AKS in ambiente Azure Stack HCI è un’implementazione Microsoft di AKS, che consente di automatizzare la distribuzione e la gestione delle applicazioni containerizzate.

Microsoft, dopo aver introdotto AKS come servizio in Azure, ha esteso la sua disponibilità anche agli ambienti on-premises. Tuttavia, ci sono alcune importanti differenze:

In Azure, Microsoft gestisce il control plane di ogni cluster AKS. Inoltre, i nodi del cluster (management node e worker node) vengono eseguiti su macchine virtuali Azure oppure su virtual machine scale set di Azure.
In ambiente on-premises, il cliente gestisce l’intero ambiente, dove i nodi del cluster AKS sono in esecuzione su macchine virtuali ospitate sull’infrastruttura hyper-converged.

Architettura di AKS su Azure Stack HCI

L’implementazione di AKS in Azure Stack HCI è costituita da due tipologie di cluster:

Un cluster di management di AKS. Questo cluster funge da control plane dedicato per la gestione dei cluster Kubernetes in esecuzione sulla piattaforma hyper-converged. Tale cluster è costituito da macchine virtuali Linux, che ospitano componenti di sistema Kubernetes come API server e load balancer.
Uno o più cluster Kubernetes. Questi cluster sono costituiti dai control node e dai worker node. I control node sono implementati come macchine virtuali Linux, con API server e load balancer che soddisfano le richieste degli utenti di Azure Stack HCI. I workload sono distribuiti sui worker node basati su sistema operativo Linux oppure Windows.

Figura 4 – Architettura di AKS su Azure Stack HCI

Ogni cluster Kubernetes viene eseguito sul proprio set dedicato di macchine virtuali, protette dall’isolamento basato su Hypervisor, consentendo di condividere in modo sicuro la stessa infrastruttura fisica anche in scenari che richiedono l’isolamento dei workload.

AKS in Azure Stack HCI supporta sia i container basati su Linux sia i container basati su Windows. Quando si crea un cluster Kubernetes si deve semplicemente specificare la tipologia di container che si intende eseguire e sulla piattaforma hyper-converged viene avviata automaticamente la procedura di installazione del sistema operativo richiesto sui nodi del cluster Kubernetes.

Vantaggi di AKS su Azure Stack HCI

AKS semplifica la distribuzione dei cluster Kubernetes fornendo un livello di astrazione in grado di mascherare alcuni dei dettagli di implementazione più impegnativi.

Tra i principali benefici di AKS in ambiente Azure Stack HCI troviamo:

Deployment semplificati di app containerizzate in ambiente cluster. Mediante l’utilizzo di Windows Admin Center si ha un processo guidato di installazione del cluster di management di AKS. Windows Admin Center facilita inoltre l’installazione di singoli cluster Kubernetes che contengono i worker node, mediante un processo di installazione automatico di tutti i componenti software rilevanti, inclusi gli strumenti di gestione come kubectl.
Possibilità di scalare orizzontalmente per gestire le risorse computazionali, aggiungendo o rimuovendo nodi del cluster Kubernetes.
Gestione semplificata dello storage e delle configurazioni di rete delle risorse cluster.
Aggiornamenti automatici dei nodi del cluster all’ultima versione di Kubernetes disponibile. Microsoft gestisce le immagini Windows Server e Linux per i nodi del cluster e le aggiorna mensilmente.
Connessione strategica, mediante Azure Arc, ai servizi Azure come: Microsoft Azure Monitor, Azure Policy, e Azure Role-Based Access Control (RBAC).
Gestione centralizzata dei cluster Kubernetes e dei relativi carichi di lavoro tramite il portale Azure, grazie all’adozione di Azure Arc for Kubernetes. La gestione basata sul portale di Azure integra anche gli strumenti e le interfacce di amministrazione Kubernetes tradizionali, come l’utility da riga di comando kubectl e le dashboard Kubernetes.
Gestione del failover automatico delle macchine virtuali che fungono da nodi del cluster Kubernetes se si verifica un errore localizzato dei componenti fisici sottostanti. Ciò integra l’elevata disponibilità intrinseca in Kubernetes, in grado di riavviare automaticamente i conteiner in stato failed.

Conclusioni

Grazie ad Azure Stack HCI l’adozione di architetture applicative basate su container possono essere ospitate direttamente presso il proprio datacenter, adottando la stessa esperienza di gestione di Kubernetes che si ha con il servizio gestito presente nel cloud pubblico di Azure. Anche il processo di deployment risulta molta semplificato ed intuitivo. Inoltre, Azure Stack HCI permette di migliorare ulteriormente l’agilità e la resilienza delle distribuzioni Kubernetes in ambiente on-premises.

Progettazione di architetture di rete sicure per Azure Kubernetes Service (AKS)

La tendenza nell’adottare applicativi basati su microservizi impone l’utilizzo di soluzioni all’avanguardia in grado di gestire un numero elevato di container e le modalità con le quali questi interagiscono applicativamente tra di loro, come Azure Kubernetes Service (AKS). Nell’ambito della progettazione delle architetture Azure Kubernetes Service (AKS) diversi sono gli elementi che devono essere valutati per ottenere una topologia di rete appropriata in grado di garantire la massima efficienza e sicurezza. In questo articolo vengono riportati i principali aspetti da prendere in considerazione, accompagnati da alcune proposte, per effettuare delle scelte consapevoli nella progettazione delle architetture di rete per AKS.

Che cos’è Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) è il servizio Azure completamente gestito che permette l’attivazione di un cluster Kubernetes, ideale per semplificare il deployment e la gestione di architetture basate su microservizi. Grazie alle funzionalità offerte da AKS è possibile scalare automaticamente in base all’utilizzo, utilizzare controlli per garantire l’integrità dei servizi, implementare politiche di bilanciamento del carico e gestire i secret. In architetture basate su microservizi è frequente anche l’adozione del componente Azure Container Registry che consente di creare, archiviare e gestire le immagini dei container e gli artifacts in un registry privato. L’utilizzo di questo servizio gestito viene integrato con le pipeline di sviluppo e di deployment dei container.

Figura 1 – Esempio di architettura di Azure Kubernetes Service (AKS)

La topologia di rete

Nell’architettura di rete di tipologia Hub and Spoke, l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises. Tale connettività può avvenire tramite VPN Site to site oppure tramite ExpressRoute. Gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro.

Figura 2 – Topologia di rete Hub and Spoke

Questa topologia di rete è consigliata anche per le architetture AKS in quanto è in grado di offrire diversi vantaggi, tra i quali:

Segregazione dell’ambiente per applicare più agevolmente politiche di governance ed ottenere un maggiore controllo. Questa topologia supporta anche il concetto di “landing zone” contemplando la separazione dei compiti.
Riduzione al minimo dell’esposizione diretta delle risorse di Azure alla rete pubblica (Internet).
Possibilità di contemplare workload attestati su differenti subscription Azure, diventando di fatto una scelta naturale in questi scenari.
Possibilità di estendere facilmente l’architettura per accogliere nuove funzionalità oppure nuovi workload, semplicemente aggiungendo ulteriori virtual network di spoke.
Possibilità di centralizzare in un’unica posizione i servizi Azure condivisi da più workload (attestati su VNet differenti), come ad esempio i server DNS ed eventuali appliance virtuali di rete. Si riducono inoltre i VPN Gateway necessari per fornire connettività verso l’ambiente on-premises, con un conseguente risparmio sui costi Azure ed una semplificazione dell’architettura.

Figura 3 – Topologia di rete Hub and Spoke per AKS

Hub Virtual Network

Nella rete di Hub è possibile valutare l’adozione dei seguenti servizi:

Gateway VPN oppure ExpressRoute: necessario per fornire connettività verso l’ambiente on-premises.
Soluzioni Firewall, necessarie nel caso si voglia controllare il traffico dal proprio ambiente AKS, come pod oppure nodi del cluster, in uscita verso servizi esterni. In questo ambito la scelta può ricadere tra:
- Azure Firewall, la soluzione di firewall-as-a-service (FWaaS) che consente di mettere in sicurezza le risorse presenti nelle Virtual Network e di governare i relativi flussi di rete.
- Network Virtual Appliances (NVAs) fornite da vendor di terze parti. Tali soluzioni sono numerose e possono offrire funzionalità avanzate, ma tipicamente la configurazione di queste soluzioni è più articolata e il costo è tendenzialmente più elevato rispetto alla soluzione fornita dalla piattaforma Azure. Una comparativa tra il nuovo Azure Firewall e le virtual appliance di terze parti è possibile consultarla in questo articolo.

Azure Bastion, il servizio PaaS che offre un accesso RDP ed SSH sicuro e affidabile alle macchine virtuali, direttamente tramite il portale di Azure.

Spoke Virtual Network

Nella rete di Spoke viene posizionato il cluster AKS insieme ad altre risorse strettamente correlate al suo funzionamento. La VNet di Spoke viene suddivisa in differenti subnet per ospitare i seguenti componenti:

I due gruppi di nodi (node pools) di AKS:

- AKS System Node pool: il pool di nodi di sistema che ospitano i pod necessari per l’esecuzione dei servizi core del cluster.
- AKS User Node pool: il pool di nodi user che eseguono i workload applicativi e l’ingress controller.

Per ambienti applicativi multi-tenant o per workload con esigenze avanzate potrebbe essere necessario implementare meccanismi di isolamento dei node pools che richiedono la presenza di differenti subnet.

AKS Internal Load Balancer: il servizio di bilanciamento per instradare e distribuire il traffico in ingresso per le risorse Kubernetes. In questo caso viene utilizzato il componente Azure Load Balancer, che consente il bilanciamento del carico Layer-4 per tutti i protocolli TCP e UDP, garantendo alte prestazioni e bassissime latenze.

Azure Application Gateway: si tratta di un servizio gestito dalla piattaforma Azure, con funzionalità intrinseche di alta disponibilità e scalabilità. L’Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, che consente di governare il traffico HTTP e HTTPS delle applicazioni (URL path, host based, round robin, session affinity, redirection). L’Application Gateway è in grado di gestire in modo centralizzato i certificati per la pubblicazione applicativa, tramite policy SSL ed effettuando SSL offload quando necessario. L’Application Gateway può avere assegnato un indirizzo IP Privato oppure un indirizzo IP Pubblico, se la ripubblicazione applicativa deve avvenire verso Internet. In particolare in quest’ultimo caso, è consigliato attivare la funzionalità di Web Application Firewall (WAF), che consente di ottenere una protezione applicativa, basandosi su regole OWASP core rule sets. Il WAF protegge l’applicativo da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection.

Grazie all’adozione degli Azure Private Link è possibile portare i servizi Azure in una Virtual Network e mapparli con un endpoint privato. In questo modo tutto il traffico viene istradato tramite l’endpoint privato, mantenendolo sulla rete globale di Microsoft. Il dato non transita mai su Internet, questo riduce l’esposizione a minacce e aiuta a rispettare gli standard di compliance.

Figura 4 – Panoramica di Azure Private Link

Negli ambienti AKS gli Azure Private Link vengono solitamente creati nelle subnet della rete virtuale di Spoke per Azure Container Registry ed Azure KeyVault.

Si riporta uno schema con i flussi di rete in ingresso ed in uscita per un ambiente AKS, che prevede anche la presenza di Azure Firewall per controllare il traffico in uscita.

Figura 5 – Esempio dei flussi di rete in una tipica architettura AKS

Traffico di Management

Per poter consentire la gestione dell’ambiente, come la creazione di nuove risorse oppure per svolgere le attività per scalare l’ambiente cluster, è opportuno prevedere un accesso alle API Kubernetes. Buona norma è applicare dei filtri di rete per autorizzare in modo puntuale questo accesso.

Cluster AKS privato

Nel caso si voglia implementare un ambiente AKS totalmente privato, dove non viene esposto nessun servizio in Internet, è possibile adottare un cluster AKS in modalità “private”.

Conclusioni

La sempre più frequente richiesta di architetture applicative basate su microservizi che utilizzano Azure Kubernetes Service (AKS) richiede di individuare e realizzare architetture di rete progettate per essere sicure, flessibili e con un elevato livello di integrazione. Il tutto deve avvenire tramite un approccio moderno in grado di sfruttare a pieno le potenzialità offerte in ambito networking da Azure.