Eseguire la migrazione di App Azure Spring a servizio Azure Kubernetes
Nota
I piani Basic, Standard ed Enterprise saranno deprecati a partire dalla metà di marzo 2025, con un periodo di ritiro di 3 anni. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere l'annuncio di ritiro di Azure Spring Apps.
Il piano Standard a consumo e dedicato sarà deprecato a partire dal 30 settembre 2024, con un arresto completo dopo sei mesi. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere Eseguire la migrazione del consumo di Azure Spring Apps Standard e del piano dedicato alle app Azure Container.
Questo articolo si applica a:✅ Basic/Standard ✅ Enterprise
Questo articolo offre una panoramica della migrazione da Azure Spring Apps a servizio Azure Kubernetes (servizio Azure Kubernetes).
Azure Spring Apps è una soluzione PaaS (Platform-as-a-Service) progettata specificamente per le applicazioni Spring Boot. Semplifica la distribuzione, l'esecuzione e la gestione di queste applicazioni. Azure Spring Apps si occupa dell'infrastruttura, del ridimensionamento e del monitoraggio, in modo che gli sviluppatori possano concentrarsi sul codice.
Il servizio Azure Kubernetes è un'offerta IaaS (Infrastructure-as-a-Service) che offre un ambiente Kubernetes completamente gestito. Il servizio Azure Kubernetes offre un maggiore controllo sulla modalità di distribuzione e gestione delle applicazioni. Supporta un'ampia gamma di applicazioni in contenitori e consente la personalizzazione per soddisfare esigenze specifiche.
La migrazione di applicazioni da Azure Spring Apps al servizio Azure Kubernetes significa passare da un ambiente gestito a uno che offre maggiore flessibilità. Questo processo richiede l'adozione di nuovi strumenti e procedure per ottenere gli stessi risultati del servizio Azure Kubernetes di Azure Spring Apps.
Mapping dei concetti
Poiché Le app Azure Spring e il servizio Azure Kubernetes sono diversi tipi di offerte di servizi cloud, non è completamente accurato eseguire il mapping dei concetti di Azure Spring Apps direttamente al servizio Azure Kubernetes. Inoltre, Azure Spring Apps dipende da molti componenti interni quando vengono usati negli ambienti di produzione, che non sono elencati qui. Il diagramma e la tabella seguenti forniscono un semplice mapping dei concetti di Azure Spring Apps al servizio Azure Kubernetes per comprendere le nozioni di base. In un ambiente di produzione reale è consigliabile prendere in considerazione soluzioni più sicure e affidabili.
| Servizio Azure Spring Apps | Servizio Azure Kubernetes |
|---|---|
| Un'istanza del servizio ospita e protegge un limite per le app e altre risorse e supporta una rete virtuale personalizzata. | Un cluster è l'unità di base della distribuzione. All'interno di un cluster, uno spazio dei nomi è una suddivisione virtuale usata per organizzare e isolare le risorse. Condivide la stessa infrastruttura di rete sottostante definita dalla rete virtuale del cluster. La scelta tra un cluster dedicato o un cluster condiviso con spazi dei nomi dipende dalle esigenze aziendali. |
| Un'app è un'app aziendale che funge da risorsa figlio all'interno di un'istanza del servizio. | Un'app aziendale è un concetto virtuale in Azure Spring Apps ed è costituito da più risorse nel servizio Azure Kubernetes. L'ingresso controlla l'accesso esterno ai servizi e imposta le regole per il routing del traffico a servizi diversi. Un servizio astrae l'accesso a un set di pod. È possibile eseguire un commutatore di distribuzione blu-verde aggiornando un servizio in modo che punti a una versione diversa di una distribuzione usando le etichette. |
| Una distribuzione è la versione di un'app. Un'app può avere una distribuzione di produzione e una distribuzione di staging. | Una distribuzione gestisce l'implementazione e il ciclo di vita di un'applicazione o di un servizio specifico. Consente inoltre di eseguire aggiornamenti in sequenza e rollback, abilitando modifiche alle applicazioni controllate e senza tempi di inattività. |
| Un'istanza dell'applicazione è l'unità di runtime minima gestita dal servizio. | Un pod rappresenta uno o più contenitori strettamente associati e ospita una singola istanza di un'applicazione o di un carico di lavoro in esecuzione. |
Considerazioni per la rete
Prima di effettuare il provisioning di un cluster del servizio Azure Kubernetes, è importante considerare attentamente le impostazioni di rete. Queste decisioni possono influire significativamente sulle prestazioni, la scalabilità e la sicurezza delle applicazioni.
Il servizio Azure Kubernetes si basa sui plug-in CNI (Container Networking Interface) per gestire la rete all'interno dei cluster. Questi plug-in gestiscono attività critiche, ad esempio l'assegnazione di indirizzi IP ai pod, il routing del traffico tra di essi e l'abilitazione della comunicazione tramite i servizi Kubernetes. Il servizio Azure Kubernetes supporta più plug-in CNI personalizzati in base alle diverse esigenze di rete, offrendo flessibilità nella progettazione del cluster.
Il servizio Azure Kubernetes offre due modelli di rete principali: reti sovrapposte e reti flat. Le reti sovrapposte assegnano indirizzi IP privati ai pod, separati dalla subnet di Azure Rete virtuale dei nodi del servizio Azure Kubernetes. Questo modello è scalabile e conserva gli indirizzi IP della rete virtuale, ma usa Network Address Translation (NAT) per il traffico che esce dal cluster. Al contrario, le reti flat assegnano indirizzi IP pod direttamente dalla stessa subnet di Azure Rete virtuale dei nodi, consentendo ai servizi esterni di accedere ai pod senza NAT. Sebbene le reti flat consentano la comunicazione diretta dei pod, richiedono uno spazio di indirizzi IP della rete virtuale più ampio.
La pianificazione ip corretta è essenziale per un'operazione del servizio Azure Kubernetes senza problemi. È importante assicurarsi che le subnet dispongano di indirizzi IP sufficienti per tutte le risorse, evitare intervalli sovrapposti e lasciare spazio per la crescita futura per evitare problemi di connettività e interruzioni. Per altre informazioni, vedere servizio Azure Kubernetes panoramica della rete CNI.
Per gestire il traffico in ingresso nel servizio Azure Kubernetes, è possibile usare i servizi di bilanciamento del carico o i controller di ingresso. I servizi di bilanciamento del carico operano al livello 4, distribuendo il traffico basato su protocolli e porte, mentre i controller di ingresso funzionano al livello 7, offrendo funzionalità avanzate come il routing basato su URL e la terminazione TLS/SSL. I controller di ingresso riducono la necessità di più indirizzi IP pubblici gestendo il traffico verso più applicazioni tramite un singolo IP. Per le applicazioni Web, i controller di ingresso sono preferiti in quanto offrono una migliore gestione e integrazione del traffico con le risorse Kubernetes. Per altre informazioni, vedere Ingresso NGINX gestito con il componente aggiuntivo di routing dell'applicazione.
Per proteggere il traffico di rete nel servizio Azure Kubernetes, usare web application firewall (WAF) come app Azure lication Gateway per proteggersi da attacchi come scripting tra siti e avvelenamento da cookie, durante la gestione del routing del traffico e la terminazione TLS/SSL. Implementare inoltre criteri di rete per controllare la comunicazione da pod a pod definendo regole nei manifesti YAML, in base a etichette, spazi dei nomi o porte. Questi criteri, disponibili solo per i nodi basati su Linux, garantiscono un migliore controllo del traffico e sicurezza all'interno del cluster. Per altre informazioni, vedere proteggere il traffico tra i pod usando criteri di rete in AKS.
Provisioning
Per effettuare il provisioning di un cluster del servizio Azure Kubernetes, è possibile usare il portale di Azure, l'interfaccia della riga di comando di Azure o i modelli di Resource Manager. Il processo prevede in genere la selezione dell'area desiderata, la definizione delle dimensioni e del tipo del pool di nodi e la scelta del modello di rete, ovvero Azure CNI o Kubenet. È inoltre necessario configurare le opzioni di autenticazione, ad esempio l'integrazione di Microsoft Entra ID per il controllo di accesso utente. Per il monitoraggio e il ridimensionamento, è possibile abilitare Monitoraggio di Azure e configurare la scalabilità automatica in base all'utilizzo delle risorse. Dopo il provisioning, è possibile gestire il cluster usando kubectl o l'interfaccia della riga di comando di Azure. Per istruzioni dettagliate sul provisioning del servizio Azure Kubernetes, vedere Creare un cluster del servizio Azure Kubernetes.
Accesso e identità
Il servizio Azure Kubernetes offre diversi modi per gestire l'autenticazione, l'autorizzazione e il controllo di accesso per i cluster Kubernetes. È possibile usare il controllo degli accessi in base al ruolo di Kubernetes per concedere agli utenti, ai gruppi e agli account del servizio l'accesso solo alle risorse necessarie. Per altre informazioni, vedere Uso di autorizzazioni del controllo degli accessi in base al ruolo. Il servizio Azure Kubernetes supporta anche Microsoft Entra ID e Controllo degli accessi in base al ruolo di Azure per migliorare la sicurezza e il controllo, consentendo di assegnare e gestire le autorizzazioni in modo più semplificato.
Per una maggiore sicurezza, è consigliabile integrare il servizio Azure Kubernetes con Microsoft Entra ID. Questa integrazione usa protocolli OpenID Connect e OAuth 2.0 per l'autenticazione. Gli utenti eseguono l'autenticazione usando le credenziali di Microsoft Entra durante l'interazione con il cluster del servizio Azure Kubernetes, con le autorizzazioni di accesso regolate dall'amministratore del cluster. Per altre informazioni, vedere Abilitare l'autenticazione dell'identità gestita di Azure per i cluster Kubernetes con kubelogin
ID dei carichi di lavoro di Microsoft Entra integra le funzionalità native di Kubernetes con provider di identità esterni tramite la federazione OIDC (OpenID Connect). Usa la proiezione del volume del token dell'account del servizio per assegnare identità Kubernetes ai pod tramite account del servizio con annotazioni. Con questi token, le applicazioni Kubernetes possono autenticare e accedere alle risorse di Azure in modo sicuro usando Microsoft Entra ID. Questa configurazione funziona perfettamente con librerie come librerie client di Identità di Azure (Azure.Identity) o Microsoft Authentication Library (MSAL) per semplificare l'autenticazione per i carichi di lavoro. Per informazioni su come configurare un cluster e configurare il pod dell'applicazione con carichi di lavoro identificati, vedere Distribuire e configurare l'identità del carico di lavoro.
Containerizzare le applicazioni
L'inserimento di applicazioni in immagini contenitore è essenziale per la distribuzione nel servizio Azure Kubernetes. Garantisce che le distribuzioni siano coerenti, portabili e scalabili. L'uso delle immagini del contenitore offre flessibilità nella gestione di versioni diverse delle applicazioni. Semplifica gli aggiornamenti e i rollback e migliora l'efficienza delle risorse consentendo l'esecuzione di più contenitori in un singolo host.
Azure Spring Apps consente agli utenti di creare immagini del contenitore e distribuire applicazioni in modi diversi. È possibile eseguire la distribuzione dal codice sorgente, da artefatti compilati come file JAR o WAR o direttamente da un'immagine del contenitore. Per informazioni su come eseguire la distribuzione da un file JAR o WAR, vedere Creare un'immagine del contenitore da un file JAR o WAR. Per informazioni su come eseguire la distribuzione dal codice sorgente, vedere Containerize an application by using Paketo Buildpacks .To learn how to deploy from source code, see Containerize an application by using Paketo Buildpacks.
Per monitorare le prestazioni delle applicazioni distribuite nel servizio Azure Kubernetes, è possibile integrare l'agente application Monitor prestazioni ing (APM) durante il processo di containerizzazione. Per altre informazioni, vedere Integrare il monitoraggio delle prestazioni delle applicazioni nelle immagini del contenitore.
Distribuire applicazioni e componenti Spring Cloud
Per distribuire applicazioni nel servizio Azure Kubernetes, è possibile usare distribuzioni, usate da Azure Spring Apps o StatefulSets, a seconda delle esigenze dell'applicazione. Per le applicazioni senza stato, ad esempio i microservizi, in genere si usa una distribuzione, che gestisce le repliche dell'applicazione e garantisce che vengano eseguite senza problemi. Questo tipo viene usato da Azure Spring Apps. D'altra parte, statefulSets sono ideali per le applicazioni che richiedono l'archiviazione permanente o le identità stabili, ad esempio database o servizi con esigenze con stato.
Oltre alla distribuzione dell'applicazione, è anche necessario definire un servizio per esporre i pod back-end. Un servizio è un'astrazione che consente di definire un set logico di pod e di consentire l'accesso alla rete. Questa funzionalità è fondamentale per il bilanciamento del carico e la comunicazione tra pod.
Quando si distribuiscono componenti Spring Cloud, ad esempio Spring Cloud Config o Spring Cloud Gateway, in genere si usano distribuzioni per i servizi senza stato. Per i servizi back-end che richiedono un'archiviazione o uno stato stabili, è possibile scegliere Set con stato.
I collegamenti seguenti forniscono esempi di riferimento di immagini contenitore e file manifesto per Spring Cloud Components:
Monitoraggio
Il monitoraggio è una parte fondamentale della gestione delle applicazioni distribuite nel servizio Azure Kubernetes. Il servizio Azure Kubernetes offre una gamma di strumenti per tenere traccia e analizzare lo stato del cluster e dei carichi di lavoro, tra cui soluzioni integrate come Monitoraggio di Azure, Azure Log Analytics e Prometheus. Per altre informazioni, vedere gli articoli seguenti:
- Prometheus gestito per la raccolta di metriche.
- Informazioni dettagliate contenitore per la raccolta di log
- Grafana gestita di Azure per la visualizzazione.
Oltre a Monitoraggio di Azure e Prometheus, è anche possibile usare altre soluzioni di monitoraggio come Datadog, New Relic o Elastic Stack (ELK). È possibile integrare questi strumenti nel servizio Azure Kubernetes per raccogliere log, metriche e tracce, offrendo varie informazioni dettagliate sulle prestazioni del cluster.
Esercitazione
Viene fornito un'esercitazione per illustrare l'esperienza end-to-end dell'esecuzione dell'applicazione ACME Fitness Store nel servizio Azure Kubernetes. Per altre informazioni, vedere acme-fitness-store/azure-kubernetes-service. Questa esercitazione fornisce indicazioni pratiche ed è destinata a riferimento. Il servizio Azure Kubernetes è altamente flessibile, quindi è necessario scegliere configurazioni e personalizzazioni in base ai requisiti specifici.