Considerazioni generali sull'architettura per la scelta di un servizio Contenitore di Azure

  • Articolo

Questo articolo illustra il processo di scelta di un servizio contenitore di Azure. Offre una panoramica delle considerazioni a livello di funzionalità comuni e critiche per alcuni carichi di lavoro. Consente di prendere decisioni per garantire che il carico di lavoro soddisfi i requisiti di affidabilità, sicurezza, ottimizzazione dei costi, eccellenza operativa ed efficienza delle prestazioni.

Nota

Questo articolo è la seconda parte di una serie che inizia con Scegliere un servizio contenitore di Azure. È consigliabile leggere prima l'articolo di panoramica per ottenere un contesto per queste considerazioni sull'architettura.

Panoramica

Le considerazioni contenute in questo articolo sono suddivise in quattro categorie:

Considerazioni sull'architettura e sulla rete

  • Supporto dei sistemi operativi
  • Spazi indirizzi di rete
  • Informazioni sul flusso del traffico
  • Pianificazione delle subnet
  • Numero di indirizzi IP in ingresso disponibili
  • Route definite dall'utente e supporto del gateway NAT
  • Integrazione della rete privata
  • Copertura del protocollo
  • Bilanciamento del carico
  • Individuazione dei servizi
  • Domini personalizzati e TLS gestito
  • TLS reciproco
  • Concetti di rete per servizi di Azure specifici

Considerazioni relative alla sicurezza

  • Sicurezza per il traffico all'interno del cluster tramite criteri di rete
  • Gruppi di sicurezza di rete
  • Integrazione di Azure Key Vault
  • Supporto delle identità gestite
  • Valutazione della protezione dalle minacce e delle vulnerabilità con Defender per contenitori
  • Baseline di sicurezza
  • Framework ben progettato di Azure per la sicurezza

Considerazioni operative

  • Aggiornamenti e patch
  • Aggiornamenti delle immagini del contenitore
  • Scalabilità verticale dell'infrastruttura
  • Scalabilità orizzontale dell'infrastruttura
  • Scalabilità delle applicazioni
  • Osservabilità
  • Framework ben progettato per l'eccellenza operativa

Considerazioni sull'affidabilità

  • Contratti di servizio
  • Ridondanza tramite zone di disponibilità
  • Controlli di integrità e riparazione automatica
  • Distribuzioni di applicazioni senza tempi di inattività
  • Limiti delle risorse
  • Framework ben progettato per l'affidabilità

Si noti che questo articolo è incentrato su un subset di servizi contenitore di Azure che offrono un set di funzionalità maturo per applicazioni Web e API, rete, osservabilità, strumenti di sviluppo e operazioni: servizio Azure Kubernetes (AKS), App Contenitore di Azure e App Web per contenitori. Per un elenco completo di tutti i servizi contenitore di Azure, vedere la pagina della categoria di prodotti servizi contenitore.

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ù componenti, ad esempio API e archivi dati, che interagiscono per offrire funzionalità end-to-end specifiche.

Considerazioni sull'architettura

In questa sezione vengono descritte le decisioni architetturali difficili da invertire o correggere senza richiedere tempi di inattività o ri-distribuzione significativi. È particolarmente necessario tenere presente questa considerazione per i componenti fondamentali, ad esempio la rete e la sicurezza.

Queste considerazioni non sono specifiche dei pilastri del framework ben progettato. Tuttavia, meritano un esame aggiuntivo e una valutazione rispetto ai requisiti aziendali quando si sceglie un servizio contenitore di Azure.

Supporto dei sistemi operativi

La maggior parte delle applicazioni in contenitori in contenitori Linux, supportate da tutti i servizi contenitore di Azure. Le opzioni disponibili sono più limitate per i componenti del carico di lavoro che richiedono contenitori windows.

App contenitore servizio Azure Kubernetes App Web per contenitori
Supporto di Linux ✅ ✅ ✅
Supporto di Windows ❌ ✅ ✅
Supporto del sistema operativo misto ❌ ✅ ❌*

*Il supporto misto del sistema operativo per app Web per contenitori richiede piani di servizio app Azure separati per Windows e Linux.

Considerazioni sulla rete

È importante comprendere la progettazione della rete nelle fasi iniziali dei processi di pianificazione a causa dei vincoli di sicurezza e conformità e delle linee guida imposte. In generale, le principali differenze tra i servizi di Azure trattati in questa guida dipendono dalle preferenze:

  • App contenitore è un'offerta PaaS che offre molte funzionalità di rete gestite da Azure, ad esempio l'individuazione dei servizi e i domini gestiti interni. I team del carico di lavoro che necessitano di una maggiore configurabilità possono usare profili di carico di lavoro/dedicati prima di prendere in considerazione alternative per ottimizzare le opzioni di rete.
  • Il servizio Azure Kubernetes è il più configurabile dei tre servizi e offre il maggior controllo sul flusso di rete. Ad esempio, fornisce controller di ingresso personalizzati e il controllo del traffico all'interno del cluster tramite i criteri di rete kubernetes. I team del carico di lavoro possono sfruttare diversi componenti aggiuntivi di rete gestita di Azure, nonché installare e gestire tutti i componenti aggiuntivi dell'ecosistema Kubernetes più ampio.
  • App Web per contenitori è una funzionalità di servizio app. Pertanto, i concetti di rete, in particolare l'integrazione di rete privata, sono molto specifici per servizio app. Questo servizio avrà familiarità con i team del carico di lavoro che usano già servizio app. I team che non hanno esperienza con servizio app e che vogliono un'integrazione della rete virtuale di Azure più familiare sono invitati a prendere in considerazione le app contenitore.

Tenere presente che la rete è un livello di infrastruttura di base. Spesso è difficile apportare modifiche alla progettazione senza ridribuire il carico di lavoro, che può causare tempi di inattività. Pertanto, se il carico di lavoro ha requisiti di rete specifici, esaminare attentamente questa sezione prima di limitare la selezione del servizio Azure Container.

Spazi indirizzi di rete

Quando si integrano applicazioni in reti virtuali, è necessario eseguire alcune operazioni di pianificazione degli indirizzi IP per assicurarsi che siano disponibili indirizzi IP sufficienti per le istanze del contenitore. Durante questo processo, pianificare indirizzi aggiuntivi per aggiornamenti, distribuzioni blu/verde e situazioni simili in cui vengono distribuite istanze aggiuntive, che utilizza indirizzi IP aggiuntivi.

App contenitore servizio Azure Kubernetes App Web per contenitori
Subnet dedicate Piano a consumo: facoltativo
Piano dedicato: obbligatorio		 Obbligatorio Facoltativo
Requisiti degli indirizzi IP Piano a consumo: vedere Ambiente di sola utilizzo.
Piano dedicato: vedere Ambiente dei profili del carico di lavoro.		 Vedere Reti virtuali di Azure per il servizio Azure Kubernetes. Vedere servizio app requisiti della subnet.

Si noti che i requisiti del servizio Azure Kubernetes dipendono dal plug-in di rete scelto. Alcuni plug-in di rete per il servizio Azure Kubernetes richiedono prenotazioni IP più ampie. I dettagli non rientrano nell'ambito di questo articolo. Per altre informazioni, vedere Concetti di rete per il servizio Azure Kubernetes.

Informazioni sul flusso del traffico

I tipi di flusso di traffico necessari per una soluzione possono influire sulla progettazione della rete.

Nelle sezioni seguenti vengono fornite informazioni sui vari vincoli di rete. Questi vincoli influiscono sulla necessità di distribuire subnet aggiuntive, a seconda che sia necessario:

  • Più carichi di lavoro con percorso condiviso.
  • Ingresso privato e/o pubblico.
  • Flusso controllato dall'accesso del traffico east-west in un cluster (per app contenitore e servizio Azure Kubernetes) o all'interno di una rete virtuale (per tutti i servizi contenitore di Azure).

Pianificazione della subnet

Assicurarsi di avere una subnet sufficientemente grande da includere istanze dell'applicazione per il carico di lavoro non è l'unico fattore che determina il footprint di rete in cui vengono distribuite queste applicazioni.

App contenitore servizio Azure Kubernetes App Web per contenitori
Supporto per carichi di lavoro con condivisione all'interno di una subnet* ❌* ✅ N/D*

*Questo descrive una procedura consigliata, non una limitazione tecnica.

Per App contenitore, l'integrazione della subnet si applica solo a un singolo ambiente app contenitore. Ogni ambiente di App contenitore è vincolato a un singolo indirizzo IP in ingresso, pubblico o privato.

Ogni ambiente di App contenitore è destinato solo a un singolo carico di lavoro in cui le applicazioni dipendenti sono collegate in modo condiviso. Pertanto, è necessario introdurre altre appliance di rete di Azure per il bilanciamento del carico in ingresso se è necessario sia l'ingresso pubblico che quello privato. Gli esempi includono app Azure lication Gateway e Frontdoor di Azure. Inoltre, se sono presenti più carichi di lavoro che devono essere separati, sono necessari altri ambienti di app contenitore, quindi è necessario allocare una subnet aggiuntiva per ogni ambiente.

Il servizio Azure Kubernetes offre un controllo granulare del flusso di rete east-west all'interno del cluster sotto forma di criteri di rete Kubernetes. Questo controllo del flusso consente di segmentare più carichi di lavoro con limiti di sicurezza di rete diversi all'interno dello stesso cluster.

Per l'app Web per contenitori, non esistono vincoli sul numero di app che è possibile integrare con una singola subnet, purché la subnet sia sufficientemente grande. Non esistono procedure consigliate per il controllo di accesso tra app Web nella stessa rete virtuale. Ogni app Web gestisce in modo indipendente il controllo di accesso per il traffico rispettivamente est-ovest o nord-sud dalla rete virtuale o da Internet.

Nota

Non è possibile ridimensionare le subnet con risorse distribuite. Prestare particolare attenzione quando si pianifica la rete per evitare la necessità di ridistribuire interi componenti del carico di lavoro, che possono causare tempi di inattività.

Numero di indirizzi IP in ingresso disponibili

La tabella seguente prende in considerazione la sezione di pianificazione della subnet precedente per definire il numero di indirizzi IP che possono essere esposti per un numero arbitrario di applicazioni ospitate in una singola distribuzione di un servizio contenitore di Azure.

App contenitore servizio Azure Kubernetes App Web per contenitori
Numero di indirizzi IP in ingresso 1 Molti ambiente del servizio app: uno
Nessun ambiente del servizio app: molti

App contenitore consente un indirizzo IP per ambiente, pubblico o privato. Il servizio Azure Kubernetes consente un numero qualsiasi di indirizzi IP, pubblici o privati. L'app Web per contenitori, all'esterno di un ambiente del servizio app, consente un indirizzo IP pubblico per tutte le app all'interno di un piano servizio app e più indirizzi IP privati diversi che usano endpoint privati di Azure.

È importante notare che le app Web integrate in un ambiente del servizio app ricevono traffico solo attraverso l'indirizzo IP in ingresso singolo associato al ambiente del servizio app, sia pubblico che privato.

Route definite dall'utente e supporto del gateway NAT

Se un carico di lavoro richiede route definite dall'utente e funzionalità del gateway NAT per il controllo granulare della rete, App contenitore richiede l'uso dei profili di carico di lavoro. La compatibilità del gateway NAT e della route definita dall'utente non è disponibile nel piano di sola utilizzo per ACA.

Il servizio Azure Kubernetes e l'app Web per contenitori implementano queste due funzionalità di rete tramite la funzionalità di rete virtuale standard o l'integrazione della rete virtuale, rispettivamente. Per elaborare, i pool di nodi del servizio Azure Kubernetes e l'app Web per contenitori in un ambiente del servizio app sono già risorse di rete virtuale dirette. App Web per contenitori che non si trovano in un ambiente del servizio app supportano le route definite dall'utente e il gateway NAT tramite l'integrazione della rete virtuale. Con l'integrazione della rete virtuale, la risorsa tecnicamente non risiede direttamente nella rete virtuale, ma tutti i flussi di accesso in uscita attraverso la rete virtuale e le regole associate alla rete influiscono sul traffico come previsto.

App contenitore servizio Azure Kubernetes App Web per contenitori
Supporto UDR Piano di sola utilizzo: ❌
Piano del profilo del carico di lavoro: ✅		 ✅ ✅
Supporto del gateway NAT Piano di sola utilizzo: ❌
Piano del profilo del carico di lavoro: ✅		 ✅ ✅

Integrazione della rete privata

Per i carichi di lavoro che richiedono una rete privata di livello 4 rigorosa sia per il traffico in ingresso che per l'uscita, è consigliabile prendere in considerazione app contenitore, servizio Azure Kubernetes e SKU ambiente del servizio app a tenant singolo, in cui i carichi di lavoro vengono distribuiti in una rete virtuale autogestito, fornendo i controlli di rete privati granulari personalizzati.

App contenitore servizio Azure Kubernetes App Web per contenitori
Ingresso privato in una rete virtuale ✅ ✅ Tramite endpoint privato
Uscita privata da una rete virtuale ✅ ✅ Tramite l'integrazione della rete virtuale
Endpoint pubblico completamente eliminato ✅ ✅ solo ambiente del servizio app
Rete privata con app Web per contenitori

App Web per contenitori offre funzionalità di rete aggiuntive che non vengono visualizzate nello stesso modo dagli altri servizi di Azure descritti in questo articolo. Per implementare requisiti di rete privati rigorosi, i team del carico di lavoro devono acquisire familiarità con questi concetti di rete. Esaminare attentamente queste funzionalità di rete:

Se si vuole una soluzione PaaS e si preferisce concetti di rete condivisi tra più soluzioni di Azure, è consigliabile prendere in considerazione App contenitore.

Copertura del protocollo

Una considerazione importante per la piattaforma di hosting è costituito dai protocolli di rete supportati per le richieste di applicazioni in ingresso (ingresso). App Web per contenitori è l'opzione più rigorosa, che supporta solo HTTP e HTTPS. App contenitore consente inoltre connessioni TCP in ingresso. Il servizio Azure Kubernetes è il più flessibile e supporta l'uso non vincolato di TCP e UDP sulle porte auto-selezionate.

App contenitore servizio Azure Kubernetes App Web per contenitori
Supporto di protocolli e porte HTTP (porta 80)*
HTTPS (porta 443)*
TCP (porte 1-65535, ad eccezione di 80 e 443)		 TCP (qualsiasi porta)
UDP (qualsiasi porta)		 HTTP (porta 80)
HTTPS (porta 443)
Supporto di WebSocket ✅ ✅ ✅
Supporto HTTP/2 ✅ ✅ ✅

*Nell'ambiente App contenitore, HTTP/S può essere esposto su qualsiasi porta per la comunicazione all'interno del cluster. In questo scenario, le funzionalità HTTP predefinite di App contenitore come CORS e l'affinità di sessione non si applicano.

Sia app contenitore che app Web per contenitori supportano TLS 1.2 per il relativo ingresso HTTPS predefinito.

Bilanciamento del carico

Con App contenitore e app Web per contenitori, Azure astrae completamente i servizi di bilanciamento del carico di livello 4 e 7.

Al contrario, il servizio Azure Kubernetes usa un modello di responsabilità condivisa in cui Azure gestisce l'infrastruttura di Azure sottostante configurata dal team del carico di lavoro interfacciandosi con l'API Kubernetes. Per il bilanciamento del carico di livello 7 nel servizio Azure Kubernetes, è possibile scegliere opzioni gestite da Azure, ad esempio il componente aggiuntivo di routing dell'applicazione gestita del servizio Azure Kubernetes o il gateway applicazione per i contenitori oppure distribuire e gestire in autonomia un controller di ingresso di propria scelta.

App contenitore servizio Azure Kubernetes App Web per contenitori
Servizio di bilanciamento del carico di livello 4 Gestito da Azure Responsabilità condivisa Gestito da Azure
Servizio di bilanciamento del carico di livello 7 Gestito da Azure Condivisi o autogestito Gestito da Azure

Individuazione dei servizi

Nelle architetture cloud i runtime possono essere rimossi e ricreati in qualsiasi momento per ribilanciare le risorse, quindi gli indirizzi IP dell'istanza cambiano regolarmente. Queste architetture usano nomi di dominio completi (FQDN) per comunicazioni affidabili e coerenti.

App contenitore servizio Azure Kubernetes App Web per contenitori
Individuazione dei servizi FQDN gestito da Azure Kubernetes configurabile FQDN gestito da Azure

App Web per contenitori fornisce FQDN in ingresso pubblico (comunicazione nord-sud) predefiniti. Non è necessaria alcuna configurazione DNS aggiuntiva. Tuttavia, non esiste alcun meccanismo predefinito per facilitare o limitare il traffico tra altre app (comunicazione east-west).

App contenitore fornisce anche FQDN in ingresso pubblici. Tuttavia, Le app contenitore vanno oltre consentendo l'esposizione e la limitazione del traffico solo all'interno dell'ambiente. Questa funzionalità semplifica la gestione della comunicazione east-west e l'abilitazione di componenti come Dapr.

Le distribuzioni kubernetes non sono inizialmente individuabili all'interno o dall'esterno del cluster. È necessario creare servizi Kubernetes come definito dall'API Kubernetes, che espongono quindi le applicazioni alla rete in modo indirizzabile.

Importante

Solo le app contenitore e il servizio Azure Kubernetes forniscono l'individuazione dei servizi tramite schemi DNS interni all'interno dei rispettivi ambienti. Questa funzionalità può semplificare le configurazioni DNS in ambienti di sviluppo/test e produzione. Ad esempio, è possibile creare questi ambienti con nomi di servizio arbitrari che devono essere univoci solo all'interno dell'ambiente o del cluster, in modo che possano essere uguali in fase di sviluppo/test e produzione. Con l'app Web per contenitori, i nomi dei servizi devono essere univoci in ambienti diversi per evitare conflitti con DNS di Azure.

Domini personalizzati e TLS gestito

App contenitore e app Web per contenitori offrono soluzioni predefinite per domini personalizzati e gestione dei certificati.

App contenitore servizio Azure Kubernetes App Web per contenitori
Configurare domini personalizzati Out-of-box BYO Out-of-box
TLS gestito per FQDN di Azure Out-of-box N/D Out-of-box
TLS gestito per domini personalizzati In anteprima BYO Predefinita o BYO

Gli utenti del servizio Azure Kubernetes sono responsabili della gestione di DNS, configurazioni del cluster e certificati TLS per i domini personalizzati. Anche se il servizio Azure Kubernetes non offre TLS gestito, i clienti possono sfruttare il software dell'ecosistema Kubernetes, ad esempio il noto gestore di certificati per gestire i certificati TLS.

TLS reciproco

Un'altra alternativa per limitare il traffico in ingresso è tls reciproco (mTLS). Tls reciproco è un protocollo di sicurezza che garantisce che sia il client che il server nella comunicazione siano autenticati. Per eseguire l'autenticazione, entrambe le parti scambiano e verificano i certificati prima della trasmissione dei dati.

L'app Web per contenitori include il supporto MTLS predefinito per le connessioni client in ingresso. Tuttavia, l'applicazione deve convalidare il certificato accedendo all'intestazione X-ARR-ClientCert HTTP inoltrata dalla piattaforma servizio app.

App contenitore include anche il supporto predefinito per mTLS. Inoltra il certificato client all'applicazione nell'intestazione HTTP X-Forwarded-Client-Cert. È anche possibile abilitare facilmente mTLS automatico per la comunicazione interna tra app in un singolo ambiente.

Il protocollo TLS reciproco nel servizio Azure Kubernetes può essere implementato tramite la mesh di servizi basata su Istio come componente aggiuntivo gestito, che include funzionalità mTLS per le connessioni client in ingresso e la comunicazione tra i servizi all'interno del cluster. I team del carico di lavoro possono anche scegliere di installare e gestire un'altra offerta di mesh di servizi dall'ecosistema Kubernetes. Queste opzioni rendono l'implementazione mTLS in Kubernetes la più flessibile.

Concetti di rete specifici del servizio

Le sezioni precedenti descrivono alcune delle considerazioni più comuni da tenere in considerazione. Per altre informazioni e per altre informazioni sulle funzionalità di rete specifiche dei singoli servizi contenitore di Azure, vedere gli articoli seguenti:

Le sezioni precedenti sono incentrate sulla progettazione della rete. Continuare con la sezione successiva per altre informazioni sulla sicurezza di rete e sulla protezione del traffico di rete.

Considerazioni sulla sicurezza

L'impossibilità di affrontare i rischi per la sicurezza può causare accessi non autorizzati, violazioni dei dati o perdite di informazioni riservate. I contenitori offrono un ambiente incapsulato per l'applicazione. I sistemi di hosting e le sovrimpressioni di rete sottostanti, tuttavia, richiedono protezioni aggiuntive. La scelta del servizio Azure Container deve supportare i requisiti specifici per proteggere ogni applicazione singolarmente e fornire misure di sicurezza appropriate per impedire l'accesso non autorizzato e ridurre il rischio di attacchi.

Panoramica del confronto della sicurezza

La maggior parte dei servizi di Azure, tra cui App contenitore, servizio Azure Kubernetes e App Web per contenitori, si integra con le principali offerte di sicurezza, tra cui Key Vault e identità gestite.

Dei servizi in questa guida, il servizio Azure Kubernetes offre la massima configurabilità ed estendibilità in parte visualizzando i componenti sottostanti, che spesso possono essere protetti tramite opzioni di configurazione. Ad esempio, i clienti possono disabilitare gli account locali nel server API Kubernetes o attivare gli aggiornamenti automatici ai nodi sottostanti tramite le opzioni di configurazione.

Per un confronto dettagliato, esaminare attentamente le considerazioni seguenti per assicurarsi che i requisiti di sicurezza del carico di lavoro possano essere soddisfatti.

Sicurezza del piano di controllo kubernetes

Il servizio Azure Kubernetes offre la massima flessibilità delle tre opzioni prese in considerazione in questo articolo, offrendo l'accesso completo all'API Kubernetes in modo da poter personalizzare l'orchestrazione dei contenitori. Questo accesso all'API Kubernetes, tuttavia, rappresenta anche una superficie di attacco significativa ed è necessario proteggerlo.

Importante

Si noti che questa sezione non è rilevante per l'app Web per contenitori, che usa l'API di Azure Resource Manager come piano di controllo.

Sicurezza basata sull'identità

I clienti sono responsabili della protezione dell'accesso basato sulle identità all'API. Kubernetes offre un proprio sistema di gestione delle autorizzazioni e autenticazione, che deve anche essere protetto con i controlli di accesso.

Per sfruttare i vantaggi di un singolo piano di vetro per la gestione delle identità e degli accessi in Azure, è consigliabile disabilitare gli account locali specifici di Kubernetes e implementare invece l'integrazione di Microsoft Entra gestita dal servizio Azure Kubernetes insieme al controllo degli accessi in base al ruolo di Azure per Kubernetes. Se si implementa questa procedura consigliata, gli amministratori non devono eseguire la gestione delle identità e degli accessi su più piattaforme.

App contenitore servizio Azure Kubernetes
Controlli di accesso all'API Kubernetes Nessun accesso Accesso completo

I clienti che usano App contenitore non hanno accesso all'API Kubernetes. Microsoft fornisce sicurezza per questa API.

Sicurezza basata sulla rete

Se si vuole limitare l'accesso di rete al piano di controllo Kubernetes, è necessario usare il servizio Azure Kubernetes, che offre due opzioni. La prima opzione consiste nell'usare cluster del servizio Azure Kubernetes privati, che usano collegamento privato di Azure tra la rete privata del server API e la rete privata del cluster del servizio Azure Kubernetes. La seconda opzione è l'integrazione rete virtuale del server API (anteprima) in cui il server API è integrato in una subnet delegata. Per altre informazioni, vedere la documentazione.

L'implementazione dell'accesso con restrizioni di rete all'API Kubernetes comporta conseguenze. In particolare, la gestione può essere eseguita solo dall'interno della rete privata. In genere questo significa che è necessario distribuire agenti self-hosted per Azure DevOps o GitHub Actions. Per altre informazioni sulle altre limitazioni, vedere la documentazione specifica del prodotto.

App contenitore servizio Azure Kubernetes
Sicurezza di rete dell'API Kubernetes Non configurabile in PaaS Configurabile: IP pubblico o IP privato

Queste considerazioni non si applicano alle app contenitore. Poiché si tratta di PaaS, Microsoft astrae l'infrastruttura sottostante.

Sicurezza di rete del piano dati

Le funzionalità di rete seguenti possono essere usate per controllare l'accesso a, da e all'interno di un carico di lavoro.

Uso dei criteri di rete per garantire la sicurezza per il traffico all'interno del cluster

Alcune posizioni di sicurezza richiedono la separazione del traffico di rete all'interno di un ambiente, ad esempio quando si usano ambienti multi-tenant per ospitare più applicazioni a più livelli o multilivello. In questi scenari è consigliabile scegliere il servizio Azure Kubernetes e implementare criteri di rete, una tecnologia nativa del cloud che consente una configurazione granulare della rete di livello 4 all'interno dei cluster Kubernetes.

App contenitore servizio Azure Kubernetes App Web per contenitori
Criteri di rete Piano a consumo: ❌
Piano dedicato: ❌		 ✅ ❌

Tra i tre servizi di Azure descritti in questo articolo, il servizio Azure Kubernetes è l'unico che supporta un ulteriore isolamento del carico di lavoro all'interno del cluster. I criteri di rete non sono supportati in App contenitore o app Web per contenitori.

Gruppi di sicurezza di rete

In tutti gli scenari, è possibile regolare la comunicazione di rete all'interno della rete virtuale più ampia usando i gruppi di sicurezza di rete, che consente di usare regole di traffico di livello 4 che regolano l'ingresso e l'uscita a livello di rete virtuale.

App contenitore servizio Azure Kubernetes App Web per contenitori
Gruppi di sicurezza di rete Piano a consumo: ✅
Piano dedicato: ✅		 ✅ ✅ App integrate nella rete virtuale: solo in uscita

Restrizioni IP per l'ingresso

In genere, le restrizioni del traffico di rete vengono applicate tramite le regole di livello 4 descritte in precedenza. Negli scenari PaaS delle applicazioni senza l'integrazione della rete virtuale, tuttavia, può essere utile limitare il traffico a livello di applicazione.

App contenitore e app Web per contenitori forniscono restrizioni IP di origine predefinite per il traffico in ingresso su singole applicazioni.

App contenitore servizio Azure Kubernetes App Web per contenitori
Restrizioni IP in ingresso a livello di applicazione Out-of-box Autogestito o tramite componente aggiuntivo gestito Out-of-box
Consumo di risorse - Utilizza le risorse del cluster -

Per i carichi di lavoro del servizio Azure Kubernetes, l'implementazione dipende dal controller di ingresso scelto. Sia il componente aggiuntivo di routing delle applicazioni gestite da Azure che il componente aggiuntivo di routing delle applicazioni gestite di Azure usano le risorse del cluster.

Sicurezza a livello di applicazione

È necessario proteggere i carichi di lavoro non solo a livello di rete e infrastruttura, ma anche a livello di carico di lavoro e applicazione. Le soluzioni contenitore di Azure si integrano con le offerte di sicurezza di Azure per standardizzare l'implementazione e i controlli della sicurezza per le applicazioni.

Integrazione di Key Vault

È consigliabile archiviare e gestire segreti, chiavi e certificati in una soluzione di gestione delle chiavi come Key Vault, che offre una sicurezza avanzata per questi componenti. Anziché archiviare e configurare segreti nel codice o in un servizio di calcolo di Azure, tutte le applicazioni devono integrarsi con Key Vault.

L'integrazione di Key Vault consente agli sviluppatori di applicazioni di concentrarsi sul codice dell'applicazione. Tutti e tre i servizi contenitore di Azure descritti in questo articolo possono sincronizzare automaticamente i segreti dal servizio Key Vault e fornirli all'applicazione, in genere come variabili di ambiente o file montati.

App contenitore servizio Azure Kubernetes App Web per contenitori
Integrazione di Key Vault ✅ ✅ ✅

Per altre informazioni, vedi:

Supporto delle identità gestite

Le applicazioni con identità gestite assegnate possono accedere alle risorse di Azure senza password. Tutti i servizi contenitore indicati in questa guida supportano le identità gestite.

App contenitore servizio Azure Kubernetes App Web per contenitori
Supporto delle identità gestite ✅ ✅ ✅

Per altre informazioni, vedi:

Valutazione della protezione dalle minacce e delle vulnerabilità con Defender per contenitori

Anche la protezione dalle minacce contro le vulnerabilità è importante. È consigliabile usare Defender per contenitori. Le valutazioni delle vulnerabilità sono supportate nei registri contenitori di Azure, quindi possono essere usate da qualsiasi servizio contenitore di Azure, non solo da quelli descritti in questo articolo. La protezione del runtime di Defender per contenitori, tuttavia, è disponibile solo per il servizio Azure Kubernetes.

Poiché il servizio Azure Kubernetes espone l'API Kubernetes nativa, la sicurezza del cluster può essere valutata anche con strumenti di sicurezza specifici di Kubernetes dall'ecosistema Kubernetes.

App contenitore servizio Azure Kubernetes App Web per contenitori
Protezione dalle minacce di runtime ❌ ✅ ❌

Per altre informazioni, vedere Matrice di supporto dei contenitori in Defender per il cloud.

Si noti che le valutazioni delle vulnerabilità dell'immagine del contenitore non sono analisi in tempo reale. Il Registro Azure Container viene analizzato a intervalli regolari.

Baseline di sicurezza

In generale, la maggior parte dei servizi contenitore di Azure integra le offerte di sicurezza di Azure. Nel complesso, tenere presente che un set di funzionalità di sicurezza è solo una piccola parte dell'implementazione della sicurezza cloud. Per altre informazioni sull'implementazione della sicurezza per i servizi contenitore, vedere le baseline di sicurezza specifiche del servizio seguenti:

Le baseline di sicurezza riguardano altre integrazioni di Azure, tra cui crittografia hardware e registrazione, che non rientrano nell'ambito di questo articolo.

Framework ben progettato per la sicurezza

Questo articolo è incentrato sulle principali differenze tra le funzionalità dei servizi contenitore descritte qui.

Per indicazioni sulla sicurezza più complete sul servizio Azure Kubernetes, vedere La revisione di Well-Architected Framework - servizio Azure Kubernetes.

Considerazioni operative

Per eseguire correttamente un carico di lavoro nell'ambiente di produzione, i team devono implementare procedure di eccellenza operativa, tra cui registrazione centralizzata, monitoraggio, scalabilità, aggiornamenti regolari e applicazione di patch e gestione delle immagini.

Aggiornamenti e patch

È importante che il sistema operativo sottostante di un'applicazione venga aggiornato e regolarmente sottoposto a patch. Tenere presente, tuttavia, che con ogni aggiornamento esiste un rischio di errore. Questa sezione e quella successiva descrivono le considerazioni principali per i tre servizi contenitore in relazione alla responsabilità condivisa tra il cliente e la piattaforma.

Come servizio Kubernetes gestito, il servizio Azure Kubernetes fornirà le immagini aggiornate per i componenti del sistema operativo del nodo e del piano di controllo. I team del carico di lavoro, tuttavia, sono responsabili dell'applicazione degli aggiornamenti ai cluster. È possibile attivare manualmente gli aggiornamenti o sfruttare la funzionalità dei canali di aggiornamento automatico del cluster per assicurarsi che i cluster siano aggiornati. Per informazioni sull'applicazione di patch e sull'aggiornamento dei cluster del servizio Azure Kubernetes, vedere la Guida alle operazioni giornaliere del servizio Azure Kubernetes.

App contenitore e app Web per contenitori sono soluzioni PaaS. Azure è responsabile della gestione degli aggiornamenti e delle patch, in modo che i clienti possano evitare la complessità della gestione degli aggiornamenti del servizio Azure Kubernetes.

App contenitore servizio Azure Kubernetes App Web per contenitori
Aggiornamenti del piano di controllo Piattaforma Cliente Piattaforma
Aggiornamenti e patch dell'host Piattaforma Cliente Piattaforma
Aggiornamenti e patch delle immagini del contenitore Cliente Cliente Cliente

Aggiornamenti delle immagini del contenitore

Indipendentemente dalla soluzione contenitore di Azure, i clienti sono sempre responsabili delle proprie immagini del contenitore. Se sono presenti patch di sicurezza per le immagini di base dei contenitori, è responsabilità dell'utente ricompilare le immagini. Per ottenere avvisi su queste vulnerabilità, usare Defender per contenitori per contenitori ospitati in Registro Container.

Scalabilità

Il ridimensionamento viene usato per regolare la capacità delle risorse in base alle esigenze, aggiungendo una maggiore capacità per garantire prestazioni e rimuovendo la capacità inutilizzata per risparmiare denaro. Quando si sceglie una soluzione contenitore, è necessario prendere in considerazione i vincoli dell'infrastruttura e le strategie di ridimensionamento.

Scalabilità verticale dell'infrastruttura

Il ridimensionamento verticale si riferisce alla possibilità di aumentare o ridurre l'infrastruttura esistente, ovvero la CPU e la memoria di calcolo. Carichi di lavoro diversi richiedono quantità diverse di risorse di calcolo. Quando si sceglie una soluzione contenitore di Azure, è necessario conoscere le offerte di SKU hardware disponibili per un particolare servizio di Azure. Variano e possono imporre vincoli aggiuntivi.

Per il servizio Azure Kubernetes, esaminare le dimensioni per le macchine virtuali nella documentazione di Azure e le restrizioni del servizio Azure Kubernetes per area.

Questi articoli forniscono informazioni dettagliate sulle offerte di SKU per gli altri due servizi:

Scalabilità orizzontale dell'infrastruttura

Il ridimensionamento orizzontale si riferisce alla possibilità di aumentare o ridurre la capacità tramite una nuova infrastruttura, ad esempio i nodi della macchina virtuale. Durante l'aumento o la riduzione del ridimensionamento, il livello di consumo di App contenitore astrae le macchine virtuali sottostanti. Per i servizi contenitore di Azure rimanenti, è possibile gestire la strategia di scalabilità orizzontale usando l'API standard di Azure Resource Manager.

Si noti che il ridimensionamento orizzontale e in include il bilanciamento delle istanze, quindi crea anche un rischio di tempo di inattività. Il rischio è inferiore al rischio corrispondente con la scalabilità verticale. Tuttavia, i team del carico di lavoro sono sempre responsabili di garantire che le applicazioni possano gestire gli errori e implementare le startup e gli arresti normale delle applicazioni per evitare tempi di inattività.

App contenitore servizio Azure Kubernetes App Web per contenitori
Scalabilità orizzontale e aumento dell'infrastruttura Piano a consumo: N/A
Piano dedicato: configurabile		 Configurabile Configurabile
Provisioning hardware flessibile Piano a consumo: N/A
Piano dedicato: astratto con i profili del carico di lavoro		 Qualsiasi SKU di macchina virtuale Astratto. Vedere servizio app piano.

Importante

Le opzioni di provisioning hardware disponibili tramite il piano dedicato app contenitore (profili di carico di lavoro) e l'app Web per contenitori (piani servizio app) non sono flessibili come il servizio Azure Kubernetes. È necessario acquisire familiarità con gli SKU disponibili in ogni servizio per assicurarsi che le esigenze siano soddisfatte.

Scalabilità delle applicazioni

La misura tipica su cui attivare il ridimensionamento dell'infrastruttura e delle applicazioni è il consumo di risorse: CPU e memoria. Alcune soluzioni contenitore possono ridimensionare il numero di istanze del contenitore in base alle metriche con contesto specifico dell'applicazione, ad esempio le richieste HTTP. Ad esempio, il servizio Azure Kubernetes e le app contenitore possono ridimensionare le istanze del contenitore in base alle code di messaggi tramite KEDA e molte altre metriche tramite i relativi scaler. Queste funzionalità offrono flessibilità quando si sceglie la strategia di scalabilità per l'applicazione. L'app Web per contenitori si basa sulle opzioni di scalabilità fornite da Azure. Vedere la tabella seguente. App Web per contenitori non supporta configurazioni di scaler personalizzate come KEDA.

App contenitore servizio Azure Kubernetes App Web per contenitori
Aumento del numero di istanze dei contenitori HTTP, TCP o basato sulle metriche (CPU, memoria, guidata dagli eventi). Basato su metriche (CPU, memoria o personalizzata). Manuale, basato sulle metriche o automatico (anteprima).
Scalabilità basata su eventi Sì. Nativo del cloud. Sì. Nativo del cloud. Configurazione aggiuntiva necessaria. Sì. Specifica della risorsa di Azure.

Osservabilità

Strumentazione del carico di lavoro

La raccolta di metriche per applicazioni complesse o multilivello può risultare complessa. Per ottenere le metriche, è possibile integrare i carichi di lavoro in contenitori con Monitoraggio di Azure in due modi:

  • Strumentazione automatica. Non è necessaria alcuna modifica nel codice.
  • Strumentazione manuale. Modifiche minime del codice necessarie per integrare e configurare l'SDK e/o il client.
App contenitore servizio Azure Kubernetes App Web per contenitori
Strumentazione automatica tramite piattaforma ❌ ❌ Supporto parziale*
Strumentazione automatica tramite agente ❌ Supporto parziale* N/D
Strumentazione manuale Tramite SDK o OpenTelemetry Tramite SDK o OpenTelemetry Tramite SDK o OpenTelemetry

*Servizio Azure Kubernetes e App Web per contenitori supportano la strumentazione automatica per determinate configurazioni di carichi di lavoro Linux e Windows, a seconda del linguaggio dell'applicazione. Vedi questi articoli per ulteriori informazioni:

La strumentazione all'interno del codice dell'applicazione è responsabilità degli sviluppatori di applicazioni, quindi è indipendente da qualsiasi soluzione contenitore di Azure. Il carico di lavoro può usare soluzioni come:

Registri

Tutti i servizi contenitore di Azure offrono funzionalità di log dell'applicazione e della piattaforma. I log dell'applicazione sono log della console generati dal carico di lavoro. I log della piattaforma acquisiscono gli eventi che si verificano a livello di piattaforma, all'esterno dell'ambito dell'applicazione, ad esempio la scalabilità e le distribuzioni.

Le differenze principali tra le funzionalità di registrazione per i servizi contenitore riguardano la registrazione della piattaforma: cosa viene registrato e come i log vengono organizzati internamente. Monitoraggio di Azure è il servizio di registrazione principale in Azure che si integra con questi servizi. Il monitoraggio usa i log delle risorse per separare i log provenienti da origini diverse in categorie. Un modo per determinare quali log sono disponibili da ogni servizio di Azure consiste nell'esaminare le categorie di log delle risorse disponibili per ognuno dei servizi.

App contenitore servizio Azure Kubernetes App Web per contenitori
Supporto per lo streaming dei log (streaming in tempo reale) ✅ ✅ ✅
Supporto per Monitoraggio di Azure ✅ ✅ ✅
Log delle risorse di Monitoraggio di Azure Console e sistema Server API Kubernetes, Controllo, Utilità di pianificazione, Scalabilità automatica cluster e altro ancora ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs e altro ancora

Per una descrizione dettagliata di ogni log delle risorse nella tabella, selezionare i collegamenti nella tabella.

Ecco un breve riepilogo delle funzionalità di registrazione dei servizi contenitore:

  • App contenitore astrae tutti i log interni di Kubernetes in due categorie. Uno, denominato Log della console , contiene i log del contenitore del carico di lavoro. Una seconda categoria di sistema contiene tutti i log correlati alla piattaforma.
  • Il servizio Azure Kubernetes fornisce tutti i log correlati a Kubernetes e il controllo granulare sugli elementi che è possibile registrare. Mantiene anche la compatibilità completa con gli strumenti client Kubernetes per lo streaming di log, ad esempio kubectl.
  • App Web per contenitori fornisce molte categorie di log delle risorse perché la piattaforma (servizio app) non è esclusivamente per i carichi di lavoro dei contenitori. Per le operazioni specifiche del contenitore che gestiscono la piattaforma Docker interna, fornisce la categoria di log AppServicePlatformLogs. Un'altra categoria importante è AppServiceEnvironmentPlatformLogs, che registra eventi come il ridimensionamento e le modifiche alla configurazione.

Framework ben progettato per l'eccellenza operativa

Questo articolo è incentrato sulle principali differenze tra le funzionalità dei servizi contenitore descritte qui. Vedere questi articoli per esaminare le linee guida complete per l'eccellenza operativa per i servizi seguenti:

Affidabilità

L'affidabilità si riferisce alla capacità di un sistema di reagire agli errori e di rimanere completamente funzionante. A livello di software dell'applicazione, i carichi di lavoro devono implementare procedure consigliate come la memorizzazione nella cache, i tentativi, i modelli di interruttore e i controlli di integrità. A livello di infrastruttura, Azure è responsabile della gestione degli errori fisici, ad esempio errori hardware e interruzioni dell'alimentazione, nei data center. Gli errori possono comunque verificarsi. I team del carico di lavoro devono selezionare il livello di servizio di Azure appropriato e applicare le configurazioni minime dell'istanza necessarie per implementare i failover automatici tra le zone di disponibilità.

Per scegliere il livello di servizio appropriato, è necessario comprendere il funzionamento dei contratti di servizio e delle zone di disponibilità.

Contratti di servizio

L'affidabilità viene comunemente misurata dalle metriche basate sull'azienda, ad esempio contratti di servizio o metriche di ripristino, come gli obiettivi del tempo di ripristino (RTO).

Azure offre molti contratti di servizio per servizi specifici. Non esiste un livello di servizio del 100%, perché gli errori possono verificarsi sempre nel software e nell'hardware e nella natura, ad esempio tempeste e terremoti. Un contratto di servizio non è una garanzia, ma piuttosto un contratto di disponibilità del servizio supportato finanziariamente.

Per i contratti di servizio e i dettagli più recenti, scaricare il documento più recente del contratto di servizio per Microsoft Online Services dal sito Web delle licenze Microsoft.

Livelli gratuiti e a pagamento

In genere, i livelli gratuiti dei servizi di Azure non offrono un contratto di servizio, che li rende scelte convenienti per ambienti non di produzione. Per gli ambienti di produzione, tuttavia, è consigliabile scegliere un livello a pagamento con contratto di servizio.

Fattori aggiuntivi per il servizio Azure Kubernetes

Il servizio Azure Kubernetes ha contratti di servizio diversi per componenti e configurazioni diversi:

  • Piano di controllo. Il server API Kubernetes ha un contratto di servizio separato.
  • Piano dati. I pool di nodi usano i contratti di servizio dello SKU della macchina virtuale sottostanti.
  • Zone di disponibilità. Esistono contratti di servizio diversi per i due piani, a seconda che il cluster del servizio Azure Kubernetes sia abilitato e che esegua più istanze tra le zone di disponibilità.

Si noti che quando si usano più servizi di Azure, i contratti di servizio compositi possono differire da e essere inferiori ai singoli contratti di servizio.

Ridondanza con zone di disponibilità

Le zone di disponibilità sono data center distinti con potenza elettrica, raffreddamento e così via indipendenti all'interno di una singola area. La ridondanza risultante aumenta la tolleranza degli errori senza richiedere l'implementazione di architetture in più aree.

Azure dispone di zone di disponibilità in ogni paese/area geografica in cui Azure gestisce un'area del data center. Per consentire a più istanze di contenitori di attraversare le zone di disponibilità, assicurarsi di selezionare SKU, livelli di servizio e aree che forniscono il supporto per la zona di disponibilità.

Funzionalità App contenitore servizio Azure Kubernetes App Web per contenitori
Supporto della zona di disponibilità Completo Completo Completo

Ad esempio, un'applicazione o un'infrastruttura configurata per l'esecuzione di una singola istanza diventa non disponibile se si verifica un problema nella zona di disponibilità in cui è ospitato l'hardware. Per usare completamente il supporto della zona di disponibilità, è necessario distribuire i carichi di lavoro con una configurazione minima di tre istanze del contenitore, distribuite tra zone.

Controlli di integrità e riparazione automatica

Gli endpoint di controllo dell'integrità sono fondamentali per un carico di lavoro affidabile. Tuttavia, la compilazione di questi endpoint è solo la metà della soluzione. L'altra metà controlla le operazioni eseguite dalla piattaforma di hosting e come, in caso di errori.

Per distinguere meglio i tipi di probe di integrità, esaminare i tipi predefiniti di probe di Kubernetes:

  • Avvio. Verifica se l'applicazione è stata avviata correttamente.
  • Idoneità. Verifica se l'applicazione è pronta per gestire le richieste in ingresso.
  • Vivacità. Verifica se l'applicazione è ancora in esecuzione e reattiva.

Un'altra considerazione importante è la frequenza con cui vengono richiesti i controlli di integrità dall'applicazione (granularità interna). Se si ha un intervallo lungo tra queste richieste, è possibile continuare a gestire il traffico fino a quando l'istanza non viene considerata non integra.

La maggior parte delle applicazioni supporta i controlli di integrità tramite il protocollo HTTP(S). Tuttavia, alcuni potrebbero richiedere altri protocolli, ad esempio TCP o gRPC, per eseguire tali controlli. Tenere presente questo aspetto quando si progetta il sistema di controllo integrità.

App contenitore servizio Azure Kubernetes App Web per contenitori
Probe di avvio ✅ ✅ Supporto parziale
Probe di idoneità ✅ ✅ ❌
Probe di attività ✅ ✅ ✅
Granularità intervallo Secondi Secondi 1 minuto
Supporto dei protocolli HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

I controlli di integrità sono più semplici da implementare nell'app Web per contenitori. Esistono alcune considerazioni importanti:

  • I probe di avvio sono incorporati e non possono essere modificati. Invia una richiesta HTTP alla porta iniziale del contenitore. Qualsiasi risposta dell'applicazione viene considerata un inizio riuscito.
  • Non supporta i probe di idoneità. Se il probe di avvio ha esito positivo, l'istanza del contenitore viene aggiunta al pool di istanze integre.
  • Invia il controllo integrità a intervalli di un minuto. Non è possibile modificare l'intervallo.
  • La soglia minima che è possibile impostare per rimuovere un'istanza non integra dal meccanismo di bilanciamento del carico interno è di due minuti. L'istanza non integra ottiene il traffico per almeno due minuti dopo che ha esito negativo un controllo integrità. Il valore predefinito per questa impostazione è 10 minuti.

Le app contenitore e il servizio Azure Kubernetes, d'altra parte, sono molto più flessibili e offrono opzioni simili. In termini di differenze specifiche, il servizio Azure Kubernetes offre le opzioni seguenti per l'esecuzione dei controlli di integrità, che non sono disponibili nelle app contenitore:

riparazione automatica

Per identificare un'istanza del contenitore non valida e interrompere l'invio del traffico a tale istanza è un avvio. Il passaggio successivo consiste nell'implementare la correzione automatica. La correzione automatica è il processo di riavvio dell'applicazione in un tentativo di ripristino da uno stato non integro. Ecco come confrontare i tre servizi contenitore:

  • In App Web per contenitori non è possibile riavviare un'istanza del contenitore immediatamente dopo un controllo di integrità non riuscito. Se l'istanza continua a non riuscire per un'ora, viene sostituita da una nuova istanza. Esiste un'altra funzionalità, denominata correzione automatica, che monitora e riavvia le istanze. Non è direttamente correlato ai controlli di integrità. Usa varie metriche dell'applicazione, ad esempio limiti di memoria, durata della richiesta HTTP e codici di stato.
  • App contenitore e servizio Azure Kubernetes tentano automaticamente di riavviare un'istanza del contenitore se il probe di attività raggiunge la soglia di errore definita.

Distribuzioni di applicazioni senza tempi di inattività

La possibilità di distribuire e sostituire le applicazioni senza causare tempi di inattività per gli utenti è fondamentale per un carico di lavoro affidabile. Tutti e tre i servizi contenitore descritti in questo articolo supportano distribuzioni senza tempi di inattività, ma in modi diversi.

App contenitore servizio Azure Kubernetes App Web per contenitori
Strategia di tempo di inattività zero Aggiornamento in sequenza Aggiornamento in sequenza, oltre a tutte le altre strategie di Kubernetes Slot di distribuzione

Si noti che anche le architetture dell'applicazione devono supportare la distribuzione senza tempi di inattività. Per indicazioni, vedere Framework ben progettato di Azure.

Limiti delle risorse

Un altro componente importante di un ambiente condiviso affidabile è il controllo sull'utilizzo delle risorse (ad esempio CPU o memoria) dei contenitori. È necessario evitare scenari in cui una singola applicazione occupa tutte le risorse e lascia le altre applicazioni in uno stato non valido.

App contenitore servizio Azure Kubernetes App Web per contenitori
Limiti delle risorse (CPU o memoria) Per app/contenitore Per app/contenitore
Per spazio dei nomi		 Piano per servizio app
  • App Web per contenitori: è possibile ospitare più applicazioni (contenitori) in un singolo piano di servizio app. Ad esempio, è possibile allocare un piano con due core CPU e 4 GiB di RAM in cui è possibile eseguire più app Web in contenitori. Non è tuttavia possibile limitare una delle app a una determinata quantità di CPU o memoria. Tutti competono per le stesse risorse del piano di servizio app. Se si vogliono isolare le risorse dell'applicazione, è necessario creare piani di servizio app aggiuntivi.
  • App contenitore: è possibile impostare limiti di CPU e memoria per ogni applicazione nell'ambiente. Tuttavia, si è limitati a un set di combinazioni consentite di CPU e memoria. Ad esempio, non è possibile configurare una vCPU e 1 GiB di memoria, ma è possibile configurare una vCPU e 2 GiB di memoria. Un ambiente app contenitore è analogo a uno spazio dei nomi Kubernetes.
  • Servizio Azure Kubernetes: è possibile scegliere qualsiasi combinazione di vCPU e memoria, purché i nodi dispongano dell'hardware per supportarlo. È anche possibile limitare le risorse a livello di spazio dei nomi se si vuole segmentare il cluster in questo modo.

Framework ben progettato per l'affidabilità

Questo articolo è incentrato sulle principali differenze tra le funzionalità dei servizi contenitore in Azure. Per esaminare le linee guida complete sull'affidabilità per un servizio specifico, vedere gli articoli seguenti:

Conclusione

Le soluzioni ben architettate impostano le basi per i carichi di lavoro riusciti. Anche se le architetture possono essere modificate man mano che un carico di lavoro cresce e i team avanzano nei percorsi cloud, alcune decisioni, soprattutto per quanto riguarda la rete, sono difficili da invertire senza tempi di inattività o ri-distribuzione significativi.

In generale, quando si confrontano i servizi contenitore di Azure, emerge un tema: il servizio Azure Kubernetes presenta l'infrastruttura più sottostante, offrendo così la massima configurabilità ed estendibilità. La quantità di overhead operativo e complessità è altamente variabile per i carichi di lavoro del servizio Azure Kubernetes. Alcuni team possono ridurre notevolmente il sovraccarico operativo usando i componenti aggiuntivi e le estensioni gestiti da Microsoft, nonché le funzionalità di aggiornamento automatico. Altri clienti possono preferire il controllo completo del cluster per sfruttare l'estendibilità completa di Kubernetes e l'ecosistema CNF. Ad esempio, anche se Microsoft offre Flux come estensione GitOps gestita, molti team scelgono invece di configurare e gestire ArgoCD autonomamente.

I team del carico di lavoro che, ad esempio, non richiedono applicazioni SAAF, hanno meno esperienza operativa o preferiscono concentrarsi sulle funzionalità dell'applicazione potrebbero preferire un'offerta PaaS. È consigliabile prima prendere in considerazione le app contenitore.

Anche se le app contenitore e l'app Web per contenitori sono entrambe offerte PaaS che offrono livelli simili di infrastruttura gestita da Microsoft, una differenza fondamentale è che le app contenitore sono più vicine a Kubernetes e offrono funzionalità native del cloud aggiuntive per l'individuazione dei servizi, la scalabilità automatica guidata dagli eventi, l'integrazione dapr e altro ancora. Tuttavia, i team che non necessitano di queste funzionalità e hanno familiarità con servizio app modelli di rete e distribuzione potrebbero preferire App Web per contenitori.

Le generalizzazioni consentono di restringere l'elenco dei servizi contenitore di Azure da considerare. Tenere tuttavia presente che è anche necessario verificare la scelta esaminando in dettaglio i singoli requisiti e associandoli a set di funzionalità specifici del servizio.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi