Scegliere un servizio contenitore di Azure
Azure offre una gamma di servizi di hosting di contenitori progettati per soddisfare diversi carichi di lavoro, architetture e requisiti aziendali. Questa guida alla selezione del servizio contenitori consente di comprendere quale servizio contenitore di Azure è più adatto per gli scenari e i requisiti del carico di lavoro.
Nota
In questa guida il termine carico di lavoro fa riferimento a una raccolta di risorse dell'applicazione che supportano un obiettivo aziendale o l'esecuzione di un processo aziendale. Un carico di lavoro usa più servizi, ad esempio API e archivi dati, che interagiscono per offrire funzionalità end-to-end specifiche.
Come usare questa guida
Questa guida include due articoli: questo articolo introduttivo e un altro articolo sulle considerazioni condivise in tutti i tipi di carico di lavoro.
Nota
Se non si è ancora eseguito il commit per la containerizzazione, vedere Scegliere un servizio di calcolo di Azure per informazioni su altre opzioni di calcolo che è possibile usare per ospitare il carico di lavoro.
Questo articolo introduttivo descrive i servizi contenitore di Azure inclusi nell'ambito di questa guida e il modo in cui i modelli di servizio confrontano in termini di compromessi tra configurabilità e soluzioni con opinioni, ad esempio approcci gestiti dal cliente rispetto a quelli gestiti da Microsoft. Dopo aver identificato i servizi candidati in base alle preferenze del modello di servizio, il passaggio successivo consiste nel valutare le opzioni in base ai requisiti relativi al carico di lavoro consultando l'articolo considerazioni comuni per il networking, la sicurezza, le operazioni e l'affidabilità.
Questa guida prende in considerazione i compromessi che potrebbero essere necessari, in base ai requisiti tecnici, alle dimensioni e alla complessità del carico di lavoro e alle competenze del team del carico di lavoro.
Servizi contenitore di Azure nell'ambito di questa guida
Questa guida è incentrata su un subset dei servizi contenitore attualmente offerti da Azure. Questo subset fornisce un set di funzionalità maturo per applicazioni Web e API, rete, osservabilità, strumenti di sviluppo e operazioni. Questi servizi contenitore vengono confrontati:
Azure Container Apps è una piattaforma completamente gestita che consente di eseguire applicazioni containerizzate senza preoccuparsi dell'orchestrazione o dell'infrastruttura. Per altre informazioni, vedere documentazione di App Azure Container.
Azure Kubernetes Service (AKS) è un servizio Kubernetes gestito per eseguire applicazioni containerizzate. Con Azure Kubernetes Service (AKS), puoi sfruttare i vantaggi dei componenti aggiuntivi e delle estensioni gestite per funzionalità aggiuntive, mantenendo al tempo stesso il livello di configurabilità più ampio. Per altre informazioni, vedere documentazione del servizio Azure Kubernetes.
'app Web per contenitori è una funzionalità del servizio app di Azure, un servizio completamente gestito per l'hosting di app Web basate su HTTP con manutenzione predefinita dell'infrastruttura, applicazione di patch di sicurezza, ridimensionamento e strumenti di diagnostica. Per ulteriori informazioni, consultare la documentazione del App Service.
Per un elenco completo di tutti i servizi contenitore di Azure, vedere la pagina della categoria di prodotti dei servizi contenitore.
Considerazioni sul modello di servizio
Il modello di servizio offre le informazioni più ampie sul livello di flessibilità e controllo fornito da qualsiasi servizio contenitore di Azure, in cambio della semplicità e della facilità d'uso complessive.
Per un'introduzione generale alla terminologia e ai concetti relativi ai modelli di servizio, tra cui infrastruttura distribuita come servizio (IaaS) e piattaforma distribuita come servizio (PaaS), vedere Responsabilità condivisa nel cloud.
Confronto tra i modelli di servizio delle soluzioni contenitore di Azure
Servizio Azure Kubernetes (AKS)
Come ibrido tra IaaS e PaaS, AKS dà priorità al controllo rispetto alla semplicità, sfruttando lo standard de facto per l'orchestrazione dei container: Kubernetes. Sebbene il servizio Azure Kubernetes semplifichi la gestione dell'infrastruttura principale sottostante, questa piattaforma basata su VM è ancora esposta alle tue applicazioni e richiede misure di protezione e processi appropriati, come l'applicazione di patch, per garantire la sicurezza e la continuità aziendale. L'infrastruttura di calcolo è supportata da risorse di Azure aggiuntive ospitate direttamente nella sottoscrizione, ad esempio i servizi di bilanciamento del carico di Azure.
AKS fornisce anche l'accesso al server API Kubernetes, che consente di personalizzare l'orchestrazione dei contenitori e quindi di implementare progetti dalla Cloud Native Computing Foundation (CNCF). Di conseguenza, esiste una curva di apprendimento significativa per i team del carico di lavoro che non hanno familiarità con Kubernetes. Se non si ha familiarità con le soluzioni in contenitori, questa curva di apprendimento deve essere presa in considerazione. Le soluzioni PaaS seguenti offrono una barriera inferiore all'ingresso. È possibile passare a Kubernetes quando i requisiti determinano lo spostamento.
AKS Automatico
AKS Automatic semplifica l'adozione di Kubernetes automatizzando attività di gestione di cluster complessi, riducendo la necessità di competenze approfondite di Kubernetes. Offre un'esperienza più semplificata e simile a PaaS, mantenendo al tempo stesso la flessibilità e l'estendibilità di Kubernetes. Azure gestisce la configurazione del cluster, il provisioning dei nodi, il ridimensionamento, l'applicazione di patch alla sicurezza e applica alcune configurazioni consigliate per impostazione predefinita. In questo modo si riduce il lavoro operativo, ma viene fornito con un set limitato di opzioni di topologia disponibili.
Nota
Questa guida distinguerà tra il servizio Azure Kubernetes Standard e il servizio Azure Kubernetes Automatico, se applicabile. In caso contrario, si può presumere che la funzionalità descritta abbia parità tra le offerte Standard e Automatic.
App container di Azure
App Azure Container è un livello di astrazione sopra Kubernetes che consente alle app di eseguire e ridimensionare senza dover gestire direttamente l'infrastruttura sottostante. "Container Apps offre entrambe le opzioni di calcolo: serverless e dedicate, dandoti pieno controllo sul tipo e sulla quantità di risorse di calcolo disponibili per le tue applicazioni." Quando si astraggono le API di orchestrazione dei contenitori, le App per container offrono comunque accesso immediato a funzionalità chiave come l'ingresso di livello 7, la suddivisione del traffico, i test A/B e la gestione del ciclo di vita delle applicazioni.
Applicazione web per container
L'app Web per contenitori è anche un'offerta PaaS, ma offre maggiore semplicità e meno controllo rispetto alle app contenitore. Estrae l'orchestrazione dei contenitori, ma fornisce comunque scalabilità appropriata, gestione del ciclo di vita delle applicazioni, suddivisione del traffico, integrazione di rete e osservabilità.
Considerazioni sul modello di hosting
È possibile usare le risorse di Azure, ad esempio i cluster del servizio Azure Kubernetes, per ospitare più carichi di lavoro. In questo modo è possibile semplificare le operazioni e quindi ridurre i costi complessivi. Se si sceglie questo percorso, ecco alcune considerazioni importanti:
Il servizio Azure Kubernetes AKS è comunemente usato per ospitare più carichi di lavoro o componenti di carichi di lavoro distinti. È possibile isolare questi carichi di lavoro e componenti usando la funzionalità nativa di Kubernetes, ad esempio spazi dei nomi, controlli di accesso e controlli di rete, per soddisfare i requisiti di sicurezza.
È anche possibile usare il servizio Azure Kubernetes in scenari a carico di lavoro singolo se è necessaria la funzionalità aggiuntiva fornita dall'API Kubernetes e il team del carico di lavoro ha un'esperienza sufficiente per gestire un cluster Kubernetes. I team con meno esperienza Kubernetes possono comunque gestire correttamente i propri cluster sfruttando i vantaggi dei componenti aggiuntivi gestiti di Azure e funzionalità, ad esempio cluster di aggiornamento automatico, per ridurre il lavoro operativo.
Le Container App devono essere utilizzate per ospitare un singolo carico di lavoro con un confine di sicurezza condiviso. Container Apps ha un unico limite logico di primo livello denominato ambiente Container Apps, che funge anche da limite di sicurezza avanzato. Non esistono meccanismi per un controllo di accesso granulare aggiuntivo. Ad esempio, la comunicazione all'interno dell'ambiente è senza restrizioni e tutte le applicazioni condividono una singola area di lavoro Log Analytics.
Se il carico di lavoro ha più componenti e più limiti di sicurezza, distribuisce più ambienti di Container Apps oppure prenda in considerazione AKS.
App Web per Contenitori è una funzionalità del Servizio App. Il servizio app raggruppa le applicazioni in un limite di fatturazione denominato piano di servizio app . Poiché è possibile definire l'ambito del controllo degli accessi in base al ruolo a livello di applicazione, potrebbe essere difficile ospitare più carichi di lavoro in un singolo piano. È tuttavia consigliabile ospitare un singolo carico di lavoro per piano per evitare il problema Noisy Neighbor. Tutte le app in un singolo piano di servizio app condividono le stesse risorse di calcolo, memoria e archiviazione allocate.
Quando si considera l'isolamento hardware, è necessario tenere presente che i piani di servizio app vengono in genere eseguiti nell'infrastruttura condivisa con altri clienti di Azure. È possibile scegliere Livelli dedicati per macchine virtuali dedicate o livelli isolati per macchine virtuali dedicate in una rete virtuale dedicata.
In generale, tutti i servizi contenitore di Azure possono ospitare più applicazioni con più componenti. Tuttavia, le App Contenitore e le App Web per Contenitori sono più adatte per un componente di carico di lavoro unico o per più componenti di carico di lavoro strettamente correlati che condividono un ciclo di vita simile, in cui un singolo team gestisce ed esegue le applicazioni.
Se devi ospitare componenti o carichi di lavoro dell'applicazione disparati, potenzialmente non correlati, su un unico host, prendi in considerazione AKS (Azure Kubernetes Service).
Compromesso tra controllo e facilità d'uso
AKS offre la massima configurabilità, ma questa richiede più sforzo operativo rispetto agli altri servizi. Anche se app contenitore e app Web per contenitori sono entrambi servizi PaaS con livelli simili di funzionalità gestite da Microsoft, l'app Web per contenitori sottolinea la semplicità di soddisfare i destinatari: clienti PaaS di Azure esistenti, che trovano familiare l'interfaccia.
Regola generale
In genere, i servizi che offrono maggiore semplicità tendono a soddisfare i clienti che preferiscono concentrarsi sullo sviluppo di funzionalità anziché sulla gestione dell'infrastruttura. I servizi che offrono un maggiore controllo tendono a soddisfare i clienti che necessitano di maggiore configurabilità e hanno le competenze, le risorse e la giustificazione aziendale necessarie per gestire la propria infrastruttura.
Considerazioni condivise in tutti i carichi di lavoro
Anche se un team del carico di lavoro potrebbe preferire un modello di servizio specifico, tale modello potrebbe non soddisfare i requisiti dell'organizzazione nel suo complesso. Ad esempio, gli sviluppatori potrebbero preferire meno lavoro operativo, ma i team di sicurezza potrebbero considerare questo tipo di overhead necessario per soddisfare i requisiti di conformità. I team devono collaborare per ottenere i compromessi appropriati.
Tenere presente che le considerazioni condivise sono ampie. Solo un subset potrebbe essere rilevante per l'utente, a seconda del tipo di carico di lavoro, ma anche del ruolo all'interno dell'organizzazione.
La tabella seguente offre una panoramica generale delle considerazioni, inclusi i confronti delle funzionalità del servizio. Esaminare le considerazioni in ogni categoria e confrontarle con i requisiti del carico di lavoro.
Categoria | Panoramica |
---|---|
considerazioni sulla rete | La rete nei servizi contenitore di Azure varia a seconda della preferenza per semplicità e configurabilità. AKS è altamente configurabile, offrendo un controllo completo sul flusso di rete, ma richiede un maggiore impegno operativo. Le Container Apps offrono le funzionalità di rete gestite da Azure. Si tratta di un punto intermedio tra AKS e l'app Web per contenitori, che è personalizzato per i clienti che hanno familiarità con App Service. Crucialmente, le decisioni di progettazione della rete possono avere conseguenze a lungo termine a causa delle difficoltà nel modificarle senza dover ridistribuire i carichi di lavoro. Diversi fattori, ad esempio la pianificazione degli indirizzi IP, le responsabilità di bilanciamento del carico, i metodi di individuazione dei servizi e le funzionalità di rete privata, differiscono in questi servizi. È consigliabile esaminare attentamente il modo in cui i servizi soddisfano requisiti di rete specifici. |
considerazioni sulla sicurezza | App contenitore, servizio Azure Kubernetes e app Web per contenitori offrono l'integrazione con le principali offerte di sicurezza di Azure, ad esempio Azure Key Vault e identità gestite. AKS offre funzionalità aggiuntive, come la protezione dalle minacce durante l'esecuzione e i criteri di rete. Anche se potrebbe sembrare che i servizi PaaS come App contenitore offrono un minor numero di funzionalità di sicurezza, ciò è in parte dovuto al fatto che più componenti dell'infrastruttura sottostanti vengono gestiti da Azure e non esposti ai clienti, riducendo così il rischio. |
considerazioni operative | AKS (Azure Kubernetes Service) offre la maggiore personalizzazione, ma richiede un maggiore input operativo. Al contrario, soluzioni PaaS come App contenitore e App Web per contenitori consentono ad Azure di gestire attività come gli aggiornamenti del sistema operativo. La scalabilità e la flessibilità degli SKU hardware sono fondamentali. Il servizio Azure Kubernetes (AKS) offre opzioni hardware flessibili, mentre Container Apps e Web App for Containers offrono un minor numero di opzioni. La scalabilità delle applicazioni nel servizio Azure Kubernetes è responsabilità del cliente, il che significa che è possibile applicare qualsiasi soluzione compatibile con Kubernetes. AKS Automatic, le Container Apps e le Web App per i Contenitori si concentrano su approcci più semplici. |
considerazioni sull'affidabilità | Le configurazioni dei probe di integrità per Web App per Contenitori e Container Apps sono limitate rispetto ad Azure Kubernetes Service (AKS), ma più semplici da configurare, dato che usano l'API familiare di Azure Resource Manager. AKS richiede l'uso dell'API Kubernetes. È anche necessario assumersi la responsabilità aggiuntiva di gestire la scalabilità e la disponibilità del pool di nodi Kubernetes per pianificare correttamente le istanze dell'applicazione. Questi requisiti comportano un impegno operativo aggiuntivo per AKS (Azure Kubernetes Service). Inoltre, gli SLA per le Container Apps e il Web App for Containers sono più semplici da calcolare rispetto a quelli di AKS, per i quali il piano di controllo e i pool di nodi hanno ciascuno i propri SLA e devono essere combinati di conseguenza. Tutti i servizi offrono ridondanza della zona nei data center che la prevedono. |
Dopo aver esaminato le considerazioni precedenti, è comunque possibile che non si sia trovato l'adattamento perfetto. È perfettamente normale.
Valutazione dei compromessi
La scelta di un servizio cloud non è un esercizio semplice. Data la complessità del cloud computing, la collaborazione tra molti team e vincoli di risorse che coinvolgono persone, budget e tempo, ogni soluzione presenta compromessi.
Tenere presente che, per un determinato carico di lavoro, alcuni requisiti potrebbero essere più critici di altri. Ad esempio, un team di applicazioni potrebbe preferire una soluzione PaaS come Container Apps, ma scegliere AKS perché il team di sicurezza richiede controlli di rete deny-by-default tra i componenti del carico di lavoro colocati, che è una funzionalità esclusiva di AKS che utilizza i criteri di rete di Kubernetes.
Si noti infine che le considerazioni condivise precedenti includono i requisiti più comuni, ma non sono completi. È responsabilità del team del carico di lavoro analizzare ogni requisito rispetto al set di funzionalità del servizio preferito prima di confermare una decisione.
Conclusione
Questa guida descrive le considerazioni più comuni affrontate quando si sceglie un servizio Azure Container. È progettato per guidare i team del carico di lavoro nel prendere decisioni informate. Il processo inizia con la scelta di un modello di servizio cloud, che implica la determinazione del livello di controllo desiderato. Il controllo è a scapito della semplicità. In altre parole, si tratta di un processo di ricerca del giusto equilibrio tra un'infrastruttura autogestito e una gestita da Microsoft.
Molti team del carico di lavoro possono scegliere un servizio contenitore di Azure esclusivamente in base al modello di servizio preferito: PaaS e IaaS. Altri team devono esaminare ulteriormente per determinare in che modo le funzionalità specifiche del servizio rispondono ai requisiti del carico di lavoro o dell'organizzazione.
Tutti i team del carico di lavoro devono usare questa guida oltre a incorporare due diligence per evitare decisioni difficili da invertire. Tenere presente, tuttavia, che la decisione non viene confermata fino a quando gli sviluppatori non provano il servizio e decidono in base all'esperienza anziché alla teoria.
Contributori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai collaboratori seguenti.
Autori principali:
- Andre Dewes | Senior Customer Engineer
- Marcos Martinez | Ingegnere Senior dei Servizi
- Julie Ng | Ingegnere Senior
Altri collaboratori:
- Mick Alberts | Redattore tecnico
- Martin Gjoššski | Senior Customer Engineer
- Don High | Ingegnere Principale del Cliente
- Nelly Kiboi | Tecnico del servizio
- Xuhong Liu | Ingegnere Senior dei Servizi
- Faisal Mustafa | Ingegnere Capo del Servizio Clienti
- Walter Myers | Responsabile Principale dell'Ingegneria Clienti
- Sonalika Roy | Ingegnere Senior del Servizio Clienti
- Paolo Salvatori | Ingegnere Principale per i Clienti
- Victor Santana | Ingegnere Principale del Cliente
Passaggio successivo
Altre informazioni sulle considerazioni sull'architettura condivisa per i servizi indicati in questo articolo.