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 si riferisce 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 utilizzare 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 del carico di lavoro esaminando l'articolo sulle considerazioni condivise relative a rete, sicurezza, operazioni e 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:
App Azure Container è una piattaforma applicativa basata su Kubernetes completamente gestita che consente di distribuire app HTTP e non HTTP da codice o contenitori senza orchestrare l'infrastruttura. Per altre informazioni, vedere la documentazione di App contenitore di Azure.
servizio Azure Kubernetes (servizio Azure Kubernetes) è un servizio Kubernetes gestito per l'esecuzione di applicazioni in contenitori. Con il servizio Azure Kubernetes è possibile sfruttare i vantaggi dei componenti aggiuntivi gestiti e delle estensioni per funzionalità aggiuntive mantenendo al tempo stesso il livello di configurabilità più ampio. Per altre informazioni, vedere la documentazione del servizio Azure Kubernetes.
L'app Web per contenitori è una funzionalità del servizio app Azure, un servizio completamente gestito per l'hosting di app Web basate su HTTP con la manutenzione predefinita dell'infrastruttura, l'applicazione di patch di sicurezza, il ridimensionamento e gli strumenti di diagnostica. Per altre informazioni, vedere servizio app documentazione.
Per un elenco completo di tutti i servizi contenitore di Azure, vedere la pagina della categoria di prodotti 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
Come ibrido di IaaS e PaaS, il servizio Azure Kubernetes assegna priorità al controllo sulla semplicità. Anche se il servizio Azure Kubernetes semplifica la gestione dell'infrastruttura principale sottostante, questa piattaforma basata su vm è ancora esposta alle applicazioni e richiede protezioni e processi appropriati, ad esempio 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.
Il servizio Azure Kubernetes fornisce anche l'accesso al server API Kubernetes, che consente di personalizzare l'orchestrazione dei contenitori e quindi di distribuire progetti dalla Cloud Native Computing Foundation (CNF). 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 potrebbe essere un deterrente. Le soluzioni PaaS seguenti offrono una barriera inferiore all'ingresso. È possibile passare a Kubernetes quando i requisiti determinano lo spostamento.
App contenitore di Azure
App contenitore, un'offerta PaaS, bilancia il controllo con semplicità. Offre opzioni di calcolo serverless e dedicate, che astraggono la necessità di applicare patch al sistema operativo o creare protezioni per le applicazioni, rispetto al sistema operativo. App contenitore elimina completamente l'API di orchestrazione dei contenitori e fornisce un subset delle funzionalità principali tramite le API di Azure con cui il team potrebbe già avere familiarità. Inoltre, i livelli 7 di ingresso, la suddivisione del traffico, i test A/B e la gestione del ciclo di vita delle applicazioni sono tutti completamente disponibili.
App Web per contenitori
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 viene comunemente usato per ospitare più carichi di lavoro o componenti di carico di lavoro diversi. È 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 componenti aggiuntivi e le funzionalità gestite di Azure, ad esempio l'aggiornamento automatico del cluster, per ridurre il sovraccarico operativo.
Le app contenitore devono essere usate per ospitare un singolo carico di lavoro con un limite di sicurezza condiviso. App contenitore ha un singolo limite logico di primo livello denominato ambiente app contenitore, 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, distribuire più ambienti di app contenitore o prendere in considerazione il servizio Azure Kubernetes.
App Web per contenitori è una funzionalità di servizio app. 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 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, app contenitore e app Web per contenitori sono più adatti per un componente a carico di lavoro singolo o più componenti del carico di lavoro altamente correlati che condividono un ciclo di vita simile, in cui un singolo team è proprietario ed esegue le applicazioni.
Se è necessario ospitare componenti o carichi di lavoro dell'applicazione diversi, potenzialmente non correlati in un host, prendere in considerazione il servizio Azure Kubernetes.
Compromesso tra controllo e facilità d'uso
Il servizio Azure Kubernetes offre la massima configurabilità, ma questa configurabilità comporta un aumento del sovraccarico 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 maggiormente sullo sviluppo di funzionalità e meno sull'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 un sovraccarico operativo inferiore, 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à. Il servizio Azure Kubernetes è altamente configurabile, offrendo un controllo completo sul flusso di rete, ma richiede un maggiore impegno operativo. App contenitore offre funzionalità di rete gestite da Azure. Si tratta di un mezzo tra il servizio Azure Kubernetes e l'app Web per contenitori, che è personalizzato per i clienti che hanno familiarità con servizio app. In primo piano, le decisioni di progettazione della rete possono avere conseguenze a lungo termine a causa delle sfide della modifica senza ridostribuirli. 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 relative alla 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. Il servizio Azure Kubernetes offre funzionalità aggiuntive, ad esempio la protezione dalle minacce di runtime 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 | Anche se il servizio Azure Kubernetes offre la maggior parte della personalizzazione, richiede un input operativo maggiore. 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 offre opzioni hardware flessibili, mentre app contenitore e app Web per contenitori forniscono configurazioni impostate. La scalabilità delle applicazioni nel servizio Azure Kubernetes è l'unica responsabilità del cliente. App contenitore e app Web per contenitori offrono approcci più semplificati. |
Considerazioni sull'affidabilità | Le configurazioni del probe di integrità dell'app Web per contenitori e app contenitore sono più semplici rispetto a quelle del servizio Azure Kubernetes, dato che usano l'API di Azure Resource Manager familiare. Il servizio Azure Kubernetes 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 sovraccarico aggiuntivo per il servizio Azure Kubernetes. Inoltre, i contratti di servizio per app contenitore e app Web per contenitori sono più semplici di quelli del servizio Azure Kubernetes, per cui il piano di controllo e i pool di nodi hanno i propri contratti di servizio e devono essere composti di conseguenza. Tutti i servizi offrono ridondanza della zona nei data center che lo offrono. |
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 App contenitore, ma scegliere servizio Azure Kubernetes perché il team di sicurezza richiede controlli di rete negati per impostazione predefinita tra i componenti del carico di lavoro con colocating, ovvero una funzionalità solo servizio Azure Kubernetes che usa i criteri di rete 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.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Andre Dewes | Senior Customer Engineer
- Marcos Martinez | Senior Service Engineer
- Julie Ng | Senior Engineer
Altri contributori:
- Mick Alberts | Writer tecnico
- Martin Gjoševski | Senior Customer Engineer
- Don High | Principal Customer Engineer
- Nelly Kiboi | Tecnico del servizio
- Xuhong Liu | Senior Service Engineer
- Faisal Mustafa | Senior Customer Engineer
- Walter Myers | Principal Customer Engineering Manager
- Sonalika Roy | Senior Customer Engineer
- Paolo Salvatori | Principal Customer Engineer
- Victor Santana | Principal Customer Engineer
Passaggio successivo
Altre informazioni sulle considerazioni sull'architettura condivisa per i servizi indicati in questo articolo.