Archivi categoria: Azure Kubernetes

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?

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, mediante:

  • 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.