Riprogettare l'applicazione Web AWS EKS per il servizio Azure Kubernetes

Ora che si ha una migliore comprensione delle differenze della piattaforma tra AWS e Azure, si esaminerà l'architettura dell'applicazione Web in AWS e le modifiche necessarie per renderla compatibile con il servizio Azure Kubernetes.

Architettura dell'applicazione Yelb

L'applicazione Web di esempio Yelb è costituita da un componente front-end denominato yelb-ui e da un componente dell'applicazione denominato yelb-appserver.

Diagramma dell'architettura dell'applicazione Web Yelb.

Il yelb-ui fornisce il codice JavaScript al browser. Questo codice viene compilato da un'applicazione Angular . Il yelb-ui componente può includere anche un nginx proxy a seconda del modello di distribuzione. yelb-appserver è un'applicazione Sinatra che interagisce con un server della cache (redis-server) e un database back-end Postgres (yelb-db). Cache Redis archivia il numero di visualizzazioni di pagina, mentre PostgreSQL mantiene i voti. Entrambi i servizi vengono distribuiti in Kubernetes senza usare alcun servizio gestito per l'archiviazione dei dati in AWS o Azure.

L'applicazione Yelb originale è autonoma e non si basa su servizi esterni, quindi è possibile eseguirne la migrazione da AWS ad Azure senza modifiche al codice. In Azure è possibile usare Redis gestito di Azure e Database di Azure per PostgreSQL come sostituzioni per i servizi Cache Redis e PostgreSQL distribuiti su AKS.

L'applicazione Yelb di esempio consente agli utenti di votare un set di alternative (ristoranti) e aggiorna dinamicamente i grafici a torta in base al numero di voti ricevuti. L'applicazione tiene inoltre traccia del numero di visualizzazioni pagina e visualizza il nome host dell'istanza yelb-appserver che gestisce la richiesta API al momento di un voto o di un aggiornamento della pagina. Questa funzionalità consente di demore l'applicazione in modo indipendente o collaborativo.

Screenshot dell'interfaccia del servizio Yelb.

Architettura in AWS

Per proteggere le applicazioni Web e le API da exploit Web comuni, AWS offre AWS Web Application Firewall (WAF) e AWS Firewall Manager.

Eseguire il mapping dei servizi AWS ai servizi di Azure

Per ricreare il carico di lavoro AWS in Azure con modifiche minime, usare un equivalente di Azure per ogni servizio AWS. La tabella seguente riepiloga i mapping dei servizi:

Mapping dei servizi	Servizio AWS	Servizio di Azure
Firewall di accesso Web	AWS Web Application Firewall (WAF)	Web application firewall di Azure (WAF)
Bilanciamento del carico dell'applicazione	Application Load Balancer (ALB)	Gateway applicazione di Azure Gateway applicazione per container
Rete per la distribuzione di contenuti	Amazon CloudFront	Azure Front Door (AFD)
Orchestrazione	Elastic Kubernetes Service (EKS)	Servizio Azure Kubernetes (AKS)
Segreti di vault	AWS Key Management Service (KMS)	Azure Key Vault
Registro dei container	Amazon Elastic Container Registry (ECR)	Registro container di Azure
Domain Name System (DNS)	Amazon Route 53	Azure DNS
Caching	Amazon ElastiCache	Redis gestito da Azure
NoSQL	Amazon DynamoDB	Database di Azure per PostgreSQL

Per un confronto completo tra i servizi di Azure e AWS, vedere Confronto tra aws e servizi di Azure.

Architettura in Azure

In questa soluzione l'applicazione Yelb viene distribuita in un cluster del servizio Azure Kubernetes ed è esposta tramite un controller di ingresso come il controller di ingresso NGINX. Il servizio controller in ingresso viene esposto tramite un load balancer interno (o privato). Per altre informazioni su come usare un servizio di bilanciamento del carico interno per limitare l'accesso alle applicazioni nel servizio Azure Kubernetes, vedere Usare un servizio di bilanciamento del carico interno con il servizio Azure Kubernetes.

Questo esempio supporta l'installazione di un controller di ingresso NGINX gestito con il componente aggiuntivo di routing dell'applicazione o un controller di ingresso NGINX non gestito usando il grafico Helm. Il componente aggiuntivo di routing dell'applicazione con il controller di ingresso NGINX offre le funzionalità seguenti:

Configurazione semplice dei controller di ingresso NGINX gestiti basati sul controller di ingresso NGINX kubernetes.
Integrazione con DNS di Azure per la gestione delle zone pubbliche e private.
Terminazione SSL con certificati archiviati in Azure Key Vault.

Per altre configurazioni, vedere gli articoli seguenti:

L'applicazione Yelb è protetta con una risorsa del Application Gateway di Azure distribuita in una subnet dedicata all'interno della stessa rete virtuale del cluster AKS o in una rete virtuale con peering. È possibile proteggere l'accesso all'applicazione Yelb usando Web application firewall (WAF) di Azure, che offre una protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni.

Progettazione dell'architettura della soluzione

Il diagramma seguente illustra l'architettura consigliata in Azure:

L'architettura della soluzione è costituita dai seguenti elementi:

Il gateway applicativo gestisce la terminazione TLS e comunica con l'applicazione di back-end attraverso HTTPS.
Il listener del gateway applicazione usa un certificato SSL ottenuto da Azure Key Vault.
La politica WAF di Azure associata al listener esegue regole OWASP e regole personalizzate contro le richieste in ingresso e blocca attacchi dannosi.
Le impostazioni HTTP del back-end del gateway dell'applicazione richiamano l'applicazione Yelb tramite HTTPS sulla porta 443.
Il pool back-end del gateway applicazione e il probe di integrità chiamano il controller NGINX in ingresso tramite il load balancer interno di AKS utilizzando HTTPS.
Il controller di ingresso NGINX utilizza il bilanciatore del carico interno di AKS.
Il cluster AKS è configurato con il provider di Azure Key Vault per il componente aggiuntivo del driver CSI dell'archivio segreti per recuperare segreti, certificati e chiavi da Azure Key Vault tramite un volume CSI.
Da Azure Key Vault, SecretProviderClass recupera lo stesso certificato utilizzato dall'Application Gateway.
Un oggetto ingress Kubernetes utilizza il controller di ingressi NGINX per esporre l'applicazione tramite HTTPS attraverso il bilanciamento del carico interno di AKS.
Il servizio Yelb è di tipo ClusterIP ed è esposto tramite il controller di ingresso NGINX.

Per istruzioni complete sulla distribuzione dell'applicazione Yelb nel servizio Azure Kubernetes usando questa architettura, vedere l'esempio complementare.

Soluzioni alternative

Azure offre diverse opzioni per distribuire un'applicazione Web in un cluster del servizio Azure Kubernetes e proteggerla con un web application firewall:

Il Application Gateway Ingress Controller (AGIC) è un'applicazione Kubernetes, quindi è possibile sfruttare il Application Gateway nativo di Azure come bilanciatore di carico L7 per esporre il software cloud a Internet per i carichi di lavoro del Azure Kubernetes Service (AKS). AGIC monitora il cluster Kubernetes su cui è ospitato e aggiorna continuamente un gateway applicazioni in modo che i servizi selezionati vengano esposti su Internet.

Il controller in ingresso viene eseguito nel proprio pod nel cluster AKS. AGIC monitora un sottoinsieme delle risorse Kubernetes per le modifiche, converte lo stato del cluster in una configurazione specifica del gateway applicativo e lo applica ad Azure Resource Manager (ARM). Per altre informazioni, vedere Che cos'è il controller Ingress di Application Gateway?.

La tabella seguente illustra i vantaggi e gli svantaggi dell'Application Gateway Ingress Controller (AGIC):

Vantaggi	Svantaggi
* Integrazione nativa: AGIC offre l'integrazione nativa con i servizi di Azure, in particolare con Azure Application Gateway, che consente un routing semplice ed efficiente del traffico ai servizi in esecuzione su AKS. * Distribuzioni semplificate: la distribuzione di AGIC come componente aggiuntivo del servizio Azure Kubernetes è semplice e semplice rispetto ad altri metodi. Consente una configurazione rapida e semplice di un gateway applicativo e di un cluster AKS con AGIC abilitato. * Servizio completamente gestito: AGIC come componente aggiuntivo è un servizio completamente gestito, offrendo vantaggi come gli aggiornamenti automatici e l'aumento del supporto di Microsoft. Garantisce che il controller di ingresso rimanga up-to-date e aggiunga un ulteriore livello di supporto.	* Approccio cloud singolo: AGIC viene adottato principalmente dai clienti che adottano un approccio a cloud singolo. Potrebbe non essere la scelta migliore se è necessaria un'architettura multicloud in cui la distribuzione in piattaforme cloud diverse è un requisito. In questo caso, si consiglia di usare un controller di ingresso cloud-agnostico, ad esempio NGINX, Traefik o HAProxy, per evitare problemi di vendor lock-in.

Vantaggi

Svantaggi

* Integrazione nativa: AGIC offre l'integrazione nativa con i servizi di Azure, in particolare con Azure Application Gateway, che consente un routing semplice ed efficiente del traffico ai servizi in esecuzione su AKS.
* Distribuzioni semplificate: la distribuzione di AGIC come componente aggiuntivo del servizio Azure Kubernetes è semplice e semplice rispetto ad altri metodi. Consente una configurazione rapida e semplice di un gateway applicativo e di un cluster AKS con AGIC abilitato.
* Servizio completamente gestito: AGIC come componente aggiuntivo è un servizio completamente gestito, offrendo vantaggi come gli aggiornamenti automatici e l'aumento del supporto di Microsoft. Garantisce che il controller di ingresso rimanga up-to-date e aggiunga un ulteriore livello di supporto.

* Approccio cloud singolo: AGIC viene adottato principalmente dai clienti che adottano un approccio a cloud singolo. Potrebbe non essere la scelta migliore se è necessaria un'architettura multicloud in cui la distribuzione in piattaforme cloud diverse è un requisito. In questo caso, si consiglia di usare un controller di ingresso cloud-agnostico, ad esempio NGINX, Traefik o HAProxy, per evitare problemi di vendor lock-in.

Per ulteriori informazioni, vedi le seguenti risorse:

Azure Application Gateway per contenitori offre il bilanciamento del carico e la gestione dinamica del traffico per le applicazioni all'interno di cluster Kubernetes.

Funzionalità principali

Il gateway applicazione di Azure per contenitori si basa sulle funzionalità del Controller in ingresso del gateway applicazione e consente di usare il bilanciatore del carico nativo del gateway applicazione di Azure. Le funzionalità principali includono:

Bilanciamento del carico: distribuisce in modo efficiente il traffico in ingresso tra più contenitori per ottenere prestazioni e scalabilità ottimali.
Implementazione dell'API gateway: supporta l'API gateway, consentendo di definire regole e criteri di routing in modo nativo di Kubernetes.
Probe di integrità personalizzate: definire probe di integrità personalizzate per monitorare l'integrità del container e inoltrare automaticamente il traffico da istanze non integrate.
Affinità di sessione: fornisce affinità di sessione, instradando le richieste successive dallo stesso client allo stesso contenitore per un'esperienza utente coerente.
Criteri TLS: supporta la terminazione TLS, consentendo l'offload della crittografia SSL/TLS al gateway.
Riscrittura dell'intestazione: riscrivere le intestazioni HTTP delle richieste client e delle risposte dalle destinazioni back-end usando la definizione di IngressExtension risorsa personalizzata. Per altre informazioni, vedere API in ingresso e API gateway.
Riscrittura URL: modificare l'URL delle richieste client, incluso il nome host e/o il percorso, e includere l'URL appena riscritto quando si avviano le richieste alle destinazioni back-end. Per altre informazioni, vedere API in ingresso e API gateway.

Limitazioni

Attualmente, il gateway applicazione di Azure per contenitori non supporta le funzionalità seguenti:

Per ulteriori informazioni, vedere Distribuzione di un cluster Azure Kubernetes Service (AKS) con Application Gateway per contenitori.

Frontdoor di Azure è un bilanciatore di carico globale di livello 7 che espone e protegge in modo sicuro i carichi di lavoro in esecuzione in AKS utilizzando il firewall per le applicazioni Web di Azure e un servizio di Collegamento privato di Azure.

Questa soluzione usa Azure Front Door Premium, crittografia TLS end-to-end, Azure Web Application Firewall e un servizio Private Link per esporre e proteggere in modo sicuro un carico di lavoro eseguito in AKS.

Funzionalità di offload TLS e SSL (Secure Sockets Layer) di frontdoor di Azure per terminare le connessioni TLS e decrittografare il traffico in ingresso nella frontdoor. Azure Front Door ricrittografa il traffico in ingresso prima di inoltrarlo all'applicazione web ospitata su AKS. Questa procedura applica la crittografia TLS end-to-end per l'intero processo di richiesta, dal client all'origine. Per altre informazioni, vedere Secure your origin with Private Link in Azure Front Door Premium.

Il controller di ingresso NGINX espone l'applicazione web ospitata su AKS di Azure. È configurato per usare un indirizzo IP privato come configurazione IP front-end del servizio di bilanciamento del kubernetes-internal carico interno e usa HTTPS come protocollo di trasporto per esporre l'applicazione Web. Per altre informazioni, vedere Creare un controller di ingresso usando un indirizzo IP interno.

È consigliabile usare questa soluzione per scenari in cui si distribuisce la stessa applicazione Web in più cluster del servizio Azure Kubernetes a livello di area per la continuità aziendale e il ripristino di emergenza o anche in più piattaforme cloud o in installazioni locali. In questo caso, Frontdoor può inoltrare le chiamate in ingresso a uno dei back-end (note anche come origini) usando uno dei metodi di routing seguenti:

Latenza: il routing basato sulla latenza garantisce che le richieste vengano inviate alle origini di latenza più basse accettabili all'interno di un intervallo di riservatezza. In altre parole, le richieste vengono inviate al set di origini più vicino rispetto alla latenza di rete.
Priorità: è possibile impostare le priorità sulle origini quando si vuole configurare un'origine primaria per il servizio di tutto il traffico. L'origine secondaria può essere un backup nel caso in cui l'origine primaria non sia più disponibile.
Ponderato: È possibile assegnare un peso alle origini per distribuire il traffico uniformemente su un insieme di origini o in base ai coefficienti di peso. Il traffico viene distribuito in base al valore di peso se le latenze delle origini si trovano all'interno dell'intervallo di sensibilità alla latenza accettabile nel gruppo di origini.
Affinità di sessione: è possibile configurare l'affinità di sessione per gli host front-end o i domini per garantire che le richieste provenienti dallo stesso utente finale vengano inviate alla stessa origine.

Per altre informazioni, vedere Usare Azure Front Door per proteggere i carichi di lavoro AKS.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-04-01