Nel mese di maggio sono state annunciate da parte di Microsoft diverse novità riguardanti gli Azure Container Services. Il rilascio di questo riepilogo, che avviene con frequenza mensile, vuole fornire una panoramica complessiva delle principali novità del mese, in modo da rimanere aggiornati su questi argomenti ed avere i riferimenti necessari per condurre ulteriori approfondimenti.
Le applicazioni moderne sono sempre più frequentemente basate su microservizi ed i container costituiscono un elemento importante per la creazione di architetture applicative agili, scalabili ed efficienti. Microsoft è uno dei principali provider che consente l’esecuzione di container a livello enterprise nel cloud pubblico. La seguente tabella mostra le diverse tecnologie container, che sono contemplate in questa serie di articoli ed i loro principali casi d’uso:
| Container Service | Principali casi d’uso |
| Azure Kubernetes Service (AKS) | Distribuisce e ridimensiona i container su un cluster Kubernetes gestito |
| Azure Red Hat OpenShift (ARO) | Distribuisce e ridimensiona i container su un cluster Red Hat OpenShift gestito |
| Azure Container Apps | Crea e distribuisce app e microservizi utilizzando container serverless |
| Azure Functions | Esegui codice serverless basato su eventi con un’esperienza di sviluppo end-to-end |
| Web App for Containers | Esegui app Web containerizzate su Windows e Linux |
| Azure Container Instances | Avvia container con isolamento dell’hypervisor |
| Azure Service Fabric | Distribuisce e gestisce app sempre attive, scalabili e distribuite |
| Azure Container Registry | Crea, archivia, protegge e replica immagini e artefatti dei container |
Azure Kubernetes Service (AKS)
Supporto di Azure Linux per i nodi AKS
E’ finalmente possibile utilizzare nodi basati su sistema operativo Azure Linux per AKS.
Il sistema operativo è un sistema rodato, infatti sistemi basati su Azure Linux ospitano già da più di 1 anno servizi di produzioni quali Xbox, PlayFab, Minecraft e oltre 100 altri servizi.
Fra i vantaggi principali ci sono prestazioni migliori ed un aumento della posture di security. L’immagine di Azure Linux è stata appositamente ottimizzata per questo scenario e grazie alla dimensione inferiore consente un miglioramento di base nelle prestazioni ed una superficie di attacco inferiore. La generazione dell’immagine prevede il passaggio in pipeline di security che ne testano la resilienza, inoltre tutti i package sono firmati direttamente da Microsoft.
Azure CNI powered by Cilium è ora disponibile in GA
Azure CNI powered by Cilium è una soluzione di rete completa che combina il control plane di Azure CNI con le funzionalità del dataplane di Cilium. Con il routing dei servizi più rapido, le opzioni di sicurezza avanzate, la tecnologia eBPF e la compatibilità con la modalità di Overlay e la modalità di subnet del pod, offre ai cluster AKS prestazioni migliorate, maggiore sicurezza e migliori informazioni sul flusso di traffico all’interno del cluster.
Fra le funzionalità principali ci sono:
- maggiore velocità nel routing;
- gestione più efficiente dell’enforce delle policy network;
- migliore osservabilità del traffico del cluster;
- supporto per cluster più grandi (più nodi/pod/servizi).
La funzionalità può essere deployata in due modalità:
- assegnando gli indirizzi IP partendo da una virtual network (in modo similare a Azure CNI);
- assegnando gli indirizzi IP tramite una rete di overlay (in modo similare ad Azure CNI Overlay mode).
La domanda che sorge spontanea è quindi quando scegliere una o l’altra? La risposta è dipende :-).
Overlay:
- pochi IP a disposizione all’interno di una vnet;
- le comunicazioni sono principalmente intra-pod all’interno del medesimo cluster;
- non servono funzionalità avanzate come i nodi virtuali.
Traditional VNet:
- si dispone di un address space “adeguato”;
- la maggior parte della comunicazione è verso risorse all’esterno del cluster (cioè ci si aspetta di esporre molteplici servizi o che i pod all’interno debbano poter comunicare con servizi all’esterno del cluster);
- le risorse all’esterno del cluster devono poter accedere direttamente ai Pod (anche se sconsigliato è comunque un caso d’uso che ci vincola a questa scelta);
- servono funzionalità avanzate di AKS come ad esempio i nodi virtuali.
Ci sono poi molteplici fattori per la scelta della tipologia di networking, per una guida più completa vi rimando alla documentazione ufficiale.
Azure Monitor Prometheus managed service
Prometheus è diventato da tempo uno standard de-facto per il monitor di Kubernetes, chi segue le news di questa rubrica saprà che Microsoft sta già migrando da tempo gran parte dei controlli e della raccolta di metriche di Azure Monitor Container Insights dal vecchio sistema basato su di una soluzione custom ad una soluzione basata su Prometheus.
Ora il servizio è disponibile in modalità standalone, è anche possibile integrarlo con cluster Kubernetes basati su Arc (funzionalità ancora in preview) fra i principali punti di forza sicuramente:
- sfrutta la piattaforma Azure già utilizzata per le metriche per raccogliere in formato nativo, consentendo quindi integrazioni orizzontali con altri servizi di piattaforma;
- 18 mesi di retention dei dati inclusi nel servizio;
- si integra nativamente con il servizio managed di Grafana;
- supporta la creazione di Azure Monitor Rules (basate sul gruppo di risorse Prometheus).
Kubernetes Marketplace
E’ ora disponibile in GA (general availability) il marketplace di Kubernetes. La funzionalità permette di installare sui cluster Kubernetes (AKS e/o Arc enabled) soluzioni di partner Microsoft da un ricco catalogo di soluzioni che sfruttano l’Azure Cost management per gestire i costi, tenerne traccia e avere stime sui consumi futuri. L’applicazione viene esaminata e approvata per le vulnerabilità e per consentire di distribuirla su ambienti di produzione.
Azure Container Instances (ACI)
Container riservati per ACI
E’ ora possibile eseguire i container all’interno di un environment sicuro TEE (Trusted Execution Environment). La funzionalità prevede l’utilizzo di una nuova SKU in grado di fornire le seguenti migliorie su workload con dati sensibili:
- lift&shift di workload in un environment riservati senza alcuna dipendenza da librerie riservate;
- crittografia in memoria dei dati con una chiave dedicata basata su hardware (per gruppo di container) che aiuta a proteggersi dagli attacchi di un sistema operativo dannoso o componenti dell’hypervisor;
- supporto per consentire a una relying party di verificare che un servizio sia in esecuzione in un TEE prima di elaborare dati sensibili. Nell’ambito dei container riservati su ACI personale dedicato convaliderà l’autenticità dei componenti hardware e applicativi che possono essere verificati tramite un servizio di attestazione remoto; prima che qualsiasi dato sensibile venga rilasciato al TEE.
Azure Container Registry (ACR)
Versione 1.1.0 delle librerie ACR
Sono ora disponibili le librerie aggiornate per la gestione di ACR. Le librerie, aggiornate alla versione 1.1.0 sono .NET, Java, JavaScript/TypeScript, e Python mentre una libreria GO è attualmente in preview.
Valutazione di Azure
Per testare e valutare in modo gratuito i servizi offerti da Azure è possibile accedere a questa pagina.