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

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.

Panoramica

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

considerazioni sull'architettura e sulla rete

• Supporto del sistema operativo
• Spazi indirizzi di rete
• Informazioni sul flusso del traffico
• Pianificazione delle subnet
• Numero di indirizzi IP in ingresso disponibili
• Instradamenti definiti dall'utente e supporto per il 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 sulla 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
• Standard di sicurezza
• Azure Well-Architected Framework 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à
• Well-Architected Framework per l'eccellenza operativa

considerazioni sull'affidabilità

• Contratti di servizio
• Ridondanza tramite zone di disponibilità
• Controlli di integrità e riparazione automatica
• Distribuzione di applicazioni senza interruzioni
• Limiti delle risorse
• Well-Architected Framework 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, Servizio Azure Kubernetes, Servizio Azure Kubernetes automatico, App Azure Container e App Web per contenitori. Per un elenco completo di tutti i servizi contenitore di Azure, vedere la pagina della categoria di prodotti dei servizi contenitore.

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 ai pilastri del framework Well-Architected. Tuttavia, meritano un esame aggiuntivo e una valutazione rispetto ai requisiti aziendali quando si sceglie un servizio contenitore di Azure.

Supporto del sistema operativo

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

	App contenitore	AKS (Servizio Azure Kubernetes)	AKS Automatico	Applicazione Web per container
Step 2: supporto per Linux	✅	✅	✅	✅
supporto di Windows	❌	✅	❌	✅
Supporto per sistemi operativi misti	❌	✅	❌	❌*

*Il supporto misto del sistema operativo per app Web per contenitori richiede piani di servizio app di 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:

• Container Apps è un'offerta PaaS che fornisce molte funzionalità di rete gestite da Azure, come l'individuazione dei servizi, i domini gestiti internamente e i controlli della rete virtuale.
• AKS è il servizio Azure Kubernetes 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 gestiti 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 del servizio app. Questo servizio sarà familiare per i team di lavoro che già usano App Service. I team che non hanno esperienza con il servizio app e che vogliono un'integrazione di 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 IP aggiuntivi per gli aggiornamenti, distribuzioni blu/verde e situazioni simili in cui vengono distribuite istanze aggiuntive, che utilizzano indirizzi IP aggiuntivi.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
subnet dedicate	Piano a consumo: facoltativo Piano dedicato: obbligatorio	Obbligatorio	Opzionale
requisiti degli indirizzi IP	Piano di consumo: vedere ambiente esclusivamente a consumo. Piano dedicato: vedere Ambiente profili di lavoro.	Consultare reti virtuali di Azure per AKS.	Consultare i requisiti della subnet di App Service.

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

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:

• Carichi di lavoro multipli in co-locazione.
• Ingresso privato e/o pubblico.
• Flusso di traffico controllato dagli accessi east-west in un cluster (per App per contenitori e Azure Kubernetes Service) o all'interno di una rete virtuale (per tutti i servizi di contenitori di Azure).

Pianificazione della sottorete

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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
supporto per carichi di lavoro collocati all'interno di una subnet*	❌*	✅	N/A*

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

Per le 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 Container Apps è destinato solo a un singolo carico di lavoro in cui le applicazioni dipendenti sono co-locate. 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 Azure Application Gateway e Azure Front Door. 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.

AKS fornisce un controllo granulare dei flussi 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.

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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Numero di indirizzi IP in ingresso	Uno	Molti	Ambiente del servizio app: uno Nessun ambiente del servizio app: molti

App per container consentono un indirizzo IP per ambiente, sia pubblico che privato. Il servizio Azure Kubernetes consente un numero qualsiasi di indirizzi IP, pubblici o privati. 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 di 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 tramite l'indirizzo IP in ingresso singolo associato all'ambiente del servizio app, sia pubblico che privato.

Instradamenti definiti dall'utente e supporto per il gateway NAT

Se un carico di lavoro richiede route definite dall'utente (UDRs) e funzionalità del gateway NAT per il controllo granulare della rete, Container Apps richiede l'uso di profili di carico di lavoro . La compatibilità della route definita dall'utente e del gateway NAT non è disponibile nel piano a consumo 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 spiegare meglio, i pool di nodi di Azure Kubernetes Service e l'App Web per contenitori in un App Service Environment sono già risorse di rete virtuale dirette. Web App per Container che non si trovano in un Ambiente del Servizio App supportano le UDR e il gateway NAT tramite l'integrazione nella 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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
supporto UDR	Piano di solo consumo: ❌ Piano del profilo del carico di lavoro: ✅	✅	✅
supporto del gateway NAT	Piano di solo consumo: ❌ 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 l'ingresso che per l'uscita, è consigliabile prendere in considerazione Azure Container Apps, Azure Kubernetes Service e lo SKU dell'Ambiente di Servizio App a tenant singolo, in cui i carichi di lavoro vengono distribuiti in una rete virtuale autogestita, fornendo i consueti controlli di rete privata granulari.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
ingresso privato in una rete virtuale	✅	✅	Attraverso endpoint privato
uscita privata da una rete virtuale	✅	✅	Integrazione della rete virtuale tramite
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:

• endpoint privato
• 'integrazione della rete virtuale

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 importante considerazione per la piattaforma di hosting è rappresentata dai protocolli di rete supportati per le richieste delle applicazioni in ingresso. App Web per contenitori è l'opzione più rigorosa, che supporta solo HTTP e HTTPS. App container consentono inoltre connessioni TCP in ingresso. AKS è il più flessibile e supporta l'uso non vincolato di TCP e UDP su porte auto-selezionate.

	App contenitore	AKS (Servizio Azure Kubernetes)	App Web per contenitori
protocollo e supporto delle 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 webSocket	✅	✅	✅
supporto HTTP/2	✅	✅	✅

Nell'ambiente delle applicazioni container, HTTP/S può essere esposto su qualsiasi porta per la comunicazione intra-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 Container Apps e Web App per Contenitori, Azure astrae completamente i bilanciatori di carico di livello 4 e 7.

Al contrario, Azure Kubernetes Service 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 di 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 gestito dal servizio Azure Kubernetes o il gateway applicazione per contenitorioppure distribuire e gestire in autonomia un controller di ingresso di propria scelta.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
bilanciatore di carico livello 4	Gestito da Azure	Responsabilità condivisa	Gestito da Azure
bilanciatore di 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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
individuazione del servizio	FQDN gestito da Azure	Kubernetes configurabile	FQDN gestito da Azure

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

Container Apps fornisce anche FQDN di ingresso pubblici. Tuttavia, Container Apps va oltre consentendo di esporre il nome di dominio completo (FQDN) dell'app e di limitare il 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.

Domini personalizzati e TLS gestito

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

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Configurare domini personalizzati	Pronto all'uso	BYO	Pronto all'uso
TLS gestito per i FQDN di Azure	Pronto all'uso	N/D	Pronto all'uso
TLS gestito per i domini personalizzati	In anteprima	BYO	Predefinita o BYO

Gli utenti di AKS sono responsabili della gestione di DNS, delle configurazioni del cluster e dei certificati TLS per i loro domini personalizzati. Anche se il servizio Azure Kubernetes non offre TLS gestito, i clienti possono sfruttare il software dell'ecosistema Kubernetes, ad esempio il popolare cert-manager 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 integrato per le connessioni client in ingresso. Tuttavia, l'applicazione deve convalidare il certificato tramite l'accesso all'intestazione HTTP X-ARR-ClientCert inoltrata dalla piattaforma del servizio app.

Anche le app contenitore includono 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.

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:

• rete nelle app contenitore
• Concetti relativi alla rete di per il servizio Azure Kubernetes
• funzionalità di rete del servizio app

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, AKS offre la massima configurabilità ed estendibilità in parte rendendo visibili i componenti fondamentali, 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.

I cluster automatici AKS sono dotati di una configurazione predefinita avanzata, con molte impostazioni di sicurezza di cluster, applicazioni e rete abilitate di default. Queste configurazioni iniziali non riducono solo il tempo di distribuzione, ma offrono anche agli utenti una configurazione standardizzata pre-convalidata e quindi offre agli utenti una solida base per le responsabilità operative del giorno 2. Questa base consente di abbreviare la curva di apprendimento della gestione dei cluster a lungo termine per i team che non hanno familiarità con la tecnologia.

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.

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 a 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	AKS (Servizio Azure Kubernetes)
controlli di accesso dell'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 AKS privati, che utilizzano il Collegamento privato di Azure fra la rete privata del server API e la rete privata del cluster AKS. La seconda opzione è '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	AKS (Servizio Azure Kubernetes)
Sicurezza della rete dell'API di Kubernetes	Non configurabile in PaaS	Configurabile: IP pubblico o IP privato

Queste considerazioni non si applicano a Container Apps. Poiché si tratta di PaaS, Microsoft astrae l'infrastruttura sottostante.

Sicurezza della rete a livello 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 politiche di sicurezza richiedono la separazione del traffico di rete all'interno di un ambiente, ad esempio quando si utilizzano ambienti multi-tenant per ospitare applicazioni a più livelli o multilivello. In questi scenari, è consigliabile scegliere AKS e implementare criteri di rete, una tecnologia cloud-native che consente una configurazione granulare del networking di livello 4 all'interno dei cluster Kubernetes.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
criteri di rete	Piano a consumo: ❌ Piano dedicato: ❌	✅	❌

Tra i tre servizi di Azure descritti in questo articolo, AKS è l'unico che supporta un ulteriore isolamento del carico di lavoro all'interno del cluster. Le politiche di rete non sono supportate nelle App per i container o nelle App Web per i container.

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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
gruppi di sicurezza di rete	Piano a consumo: ✅ Piano dedicato: ✅	✅	✅ Applicazioni integrate nella VNet: solo uscita

Restrizioni IP predefinite per l'ingresso

App contenitore e app Web per contenitori forniscono restrizioni IP di origine predefinite per il traffico in ingresso per le singole applicazioni. AKS può ottenere la stessa funzionalità, ma richiede la funzionalità nativa di Kubernetes tramite la risorsa API del servizio Kubernetes , dove è possibile impostare i valori per loadBalancerSourceRanges.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
restrizioni IP in ingresso integrate	✅	❌*	✅
consumo di risorse	-	Utilizza 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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Integrazione di Key Vault	✅	✅	✅

Per altre informazioni, vedere:

• Gestire i segreti in Azure Container Apps
• Integrare Key Vault con AKS
• Usare i riferimenti a Key Vault come impostazioni dell'app nel servizio app di Azure

Supporto delle identità gestite

L'identità gestita può essere usata dalle applicazioni per eseguire l'autenticazione ai servizi protetti con ID Entra Di Microsoft senza dover usare chiavi o segreti. App per container e app Web per container offrono supporto nativo di Azure predefinito per l'identità gestita a livello applicativo. Il supporto dell'identità gestita a livello applicativo per AKS viene eseguito tramite ID carico di lavoro Entra. AKS richiede anche un'identità gestita relativa all'infrastruttura per consentire le operazioni del cluster per il Kubelet, il piano di controllo e vari componenti aggiuntivi di AKS.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Supporto all'identità gestita dell'infrastruttura	N/D	✅	N/D
supporto per l'identità gestita nelle operazioni di pull dei container	✅	✅	✅
supporto dell'identità gestita dell'applicazione	✅	✅	✅

Per altre informazioni, vedere:

• Usare un'identità gestita in AKS
• ID del carico di lavoro di Microsoft Entra con AKS
• Identità gestite in Azure Container Apps
• Come usare le identità gestite per il servizio app

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 AKS.

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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Protezione dalle minacce in fase di esecuzione	❌	✅	❌

Per ulteriori informazioni, vedere la matrice di supporto dei contenitori in Defender for 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.

Standard 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:

• Linea di base di sicurezza di Azure per le app per container
• baseline di sicurezza di Azure per il servizio Azure Kubernetes
• Baseline di sicurezza per Azure per Servizio app

Well-Architected Framework per la sicurezza

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

Per linee guida sulla sicurezza più complete per AKS, vedere Well-Architected Framework review - AKS.

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, AKS fornirà le immagini aggiornate per i componenti del sistema operativo del nodo e del piano di gestione. I team del carico di lavoro, tuttavia, sono responsabili dell'applicazione degli aggiornamenti ai cluster. Puoi attivare manualmente gli aggiornamenti o sfruttare la funzionalità dei canali di aggiornamento automatico del cluster per assicurarti che i cluster siano aggiornati. Per informazioni sull'applicazione di patch e l'aggiornamento dei cluster del servizio Azure Kubernetes (AKS) , vedere la Guida operativa day-2 di AKS.

App contenitore e app Web per contenitori sono soluzioni PaaS. Azure è responsabile della gestione degli aggiornamenti e delle patch, così i clienti possono evitare la complessità della gestione degli aggiornamenti di AKS.

	App contenitore	AKS (Servizio Azure Kubernetes)	AKS Automatico	Applicazione Web per container
aggiornamenti del piano di controllo	Piattaforma	Cliente	Piattaforma	Piattaforma
Gli aggiornamenti e le patch dell'host	Piattaforma	Cliente	Piattaforma	Piattaforma
aggiornamenti e patch delle immagini del container	Cliente	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 i contenitori ospitati nel 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

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 di 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:

• Profili di carico di lavoro in App per contenitori
• prezzi del servizio app

Scalabilità orizzontale dell'infrastruttura

ridimensionamento orizzontale si riferisce alla possibilità di aumentare o ridurre la capacità tramite una nuova infrastruttura, ad esempio i nodi della macchina virtuale. Durante gli aumenti o le riduzioni del ridimensionamento, il livello di consumo delle Container Apps 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 verso l'esterno e verso l'interno 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 di lavoro sono sempre responsabili di garantire che le loro applicazioni possano gestire gli errori e implementare avvii e arresti graduali delle applicazioni per evitare interruzioni.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Scalabilità dell'infrastruttura verso l'interno e verso l'esterno	Piano a consumo: Non applicabile Piano dedicato: configurabile	Configurabile	Configurabile
Flessibile fornitura di hardware	Piano a consumo: Non applicabile Piano dedicato: astratto con i profili del carico di lavoro	Qualsiasi SKU di macchina virtuale	Astratto. Vedere piano di servizio app.

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, AKS e Container Apps possono ridimensionare le istanze di container in base alle code di messaggi tramite KEDA e molte altre metriche tramite i suoi scalers . 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. La App Web per Contenitori non supporta le configurazioni di scaler personalizzate, come KEDA.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Scalabilità orizzontale dei container	HTTP, TCP o basato su metriche (CPU, memoria, guidata dagli eventi).	basato su metriche (CPU, memoria o personalizzata).	Manuale, basato su metriche, o automatico (anteprima).
scalabilità basata su eventi	Sì. Cloud nativo	Sì. Cloud nativo Configurazione aggiuntiva necessaria.	Sì. Specifica per risorse Azure.

AKS Automatic abilita la scalabilità automatica orizzontale dei pod, la scalabilità automatica basata su eventi Kubernetes (KEDA) e la scalabilità automatica verticale dei pod (VPA) per impostazione predefinita.

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 sono necessarie modifiche al codice.
• Strumentazione manuale. Modifiche minime del codice necessarie per integrare e configurare l'SDK e/o il client.

	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
strumentazione automatica tramite piattaforma	❌	❌	Supporto parziale*
Strumentazione automatica mediante un agente	❌	Supporto parziale*	N/D
strumentazione manuale	Tramite SDK o OpenTelemetry	Tramite SDK o OpenTelemetry	Tramite SDK o OpenTelemetry

"Azure Kubernetes Service" e "Web App for Containers" supportano l'instrumentazione automatica per determinate configurazioni di carichi di lavoro Linux e Windows, a seconda del linguaggio dell'applicazione. Per altre informazioni, vedere questi articoli:

• Ambienti, linguaggi e provider di risorse supportati dalla strumentazione automatica
• Monitoraggio delle applicazioni senza strumentazione per Kubernetes

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

• SDK di Application Insights
• Le distribuzioni di OpenTelemetry

Log e metriche

Tutti i servizi contenitore di Azure offrono funzionalità di log e metriche delle applicazioni e della piattaforma. I log delle applicazioni 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 metriche sono valori numerici che descrivono alcuni aspetti di un sistema in un momento specifico, consentendo di monitorare e avvisare le prestazioni e l'integrità del sistema.

Azure Monitor è il servizio principale di registrazione e metriche in Azure che si integra con questi servizi. Azure Monitor usa i log delle risorse per suddividere i log provenienti da origini diverse in categorie e raccoglie le metriche allo scopo di fornire informazioni dettagliate sulle prestazioni delle risorse. Un modo per determinare quali log e metriche sono disponibili da ogni servizio di Azure consiste nell'esaminare le categorie di log delle risorse e le metriche disponibili per ognuno dei servizi.

	App contenitore	AKS (Servizio Azure Kubernetes)	AKS Automatico	Applicazione Web per container
supporto per lo streaming di log	✅	✅	✅	✅
supporto per monitoraggio di Azure	✅	✅	✅	✅
Log delle risorse di Azure Monitor	Console e Sistema	API server di Kubernetes, Audit, Scheduler, Cluster Autoscaler e altro	Stesso di AKS (Azure Kubernetes Service)	ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs e altri
raccolta e monitoraggio delle metriche	Metriche tramite Azure Monitor; metriche personalizzate tramite Dapr metrics	Metriche tramite Monitoraggio di Azure; metriche personalizzate tramite Prometheus (richiede l'installazione manuale)	Prometheus gestito preconfigurato per la raccolta di metriche e Grafana gestito per la visualizzazione; metriche tramite Azure Monitor	Metriche tramite Monitoraggio di Azure
Prometheus e Grafana preconfigurati	❌	Richiede l'installazione manuale	✅ Managed Prometheus e Managed Grafana sono preconfigurati per impostazione predefinita.	❌

App per container astrae tutti i log interni di Kubernetes in due categorie: i log della console, che includono i log dei container di lavoro, e i log di sistema, che contengono tutti i log correlati alla piattaforma. Per le metriche, Container Apps si integra con Azure Monitor per raccogliere metriche standard e supporta metriche personalizzate attraverso l'integrazione con Dapr per scenari avanzati.

AKS fornisce log correlati a Kubernetes e un controllo granulare di ciò che viene registrato. AKS mantiene la compatibilità completa con gli strumenti client Kubernetes per lo streaming di log, ad esempio kubectl. Per le metriche, AKS si integra con Azure Monitor per raccogliere le metriche del cluster e dei nodi. La raccolta di metriche personalizzate che usano Prometheus e la visualizzazione con Grafana sono possibili, ma richiedono la configurazione e la configurazione manuali.

AKS Automatic è preconfigurato con strumenti di monitoraggio specifici. Usa Managed Prometheus per la raccolta di metriche e Managed Grafana per la visualizzazione. Le metriche del cluster e dell'applicazione vengono raccolte automaticamente e possono essere visualizzate. AKS Automatica si integra anche con Azure Monitor per la raccolta di log e metriche.

'app Web per contenitori fornisce diverse 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. Le metriche vengono raccolte tramite Monitoraggio di Azure, consentendo di monitorare le prestazioni dell'applicazione e l'utilizzo delle risorse.

Well-Architected Framework 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:

• Azure Kubernetes Service
• App Web per contenitori

Affidabilità

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 da metriche basate sull'azienda come 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 di 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 gli SLA e i dettagli più recenti, scaricare il documento SLA più recente 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 AKS

AKS ha contratti di servizio diversi per componenti e configurazioni differenti.

• 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 livelli, a seconda che il cluster AKS abbia le zone di disponibilità abilitate e che eseguono più istanze tra le zone di disponibilità.

Nota che quando si utilizzano più servizi Azure, gli SLO compositi possono differire ed essere inferiori rispetto agli SLA dei singoli servizi.

Ridondanza con zone di disponibilità

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à.

Caratteristica	App contenitore	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
Il Supporto delle Zone di Disponibilità	Pieno	Pieno	Pieno

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 della salute 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 da Kubernetes:

• Avvio. Verifica se l'applicazione è stata avviata correttamente.
• Prontezza. Verifica se l'applicazione è pronta per gestire le richieste in ingresso.
• vitalità. 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, puoi continuare a gestire il traffico fino a quando l'istanza non viene considerata non sana.

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. Tenete presente questo aspetto quando si progetta il sistema di controllo della salute.

	App contenitore	AKS (Servizio Azure Kubernetes)	App Web per contenitori
probe di avvio	✅	✅	Supporto parziale
sonde di prontezza	✅	✅	❌
Sonde di attività	✅	✅	✅
intervallo di granularità	Secondi	Secondi	1 minuto
Supporto del protocollo	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 prontezza. Se la sonda di avvio ha esito positivo, l'istanza di contenitore viene aggiunta al pool di istanze integre.
• Invia la verifica dello stato di salute a intervalli di un minuto. Non è possibile modificare l'intervallo.
• La soglia minima che è possibile impostare per rimuovere un'istanza non funzionante dal sistema di bilanciamento del carico interno è di due minuti. L'istanza malfunzionante riceve traffico per almeno due minuti dopo un esito negativo a un controllo di 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, AKS offre le seguenti opzioni per eseguire controlli di integrità, che non sono disponibili in Container Apps.

• supporto gRPC
• porte denominate
• Exec comandi

Autoguarigione

Per identificare un'istanza del contenitore difettosa e interrompere l'invio del traffico a essa è un buon inizio. 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 che un controllo di integrità ha esito negativo. 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 container e AKS tentano automaticamente di riavviare un'istanza del contenitore se il probe di liveness raggiunge la soglia di errore definita.

Distribuzione di applicazioni senza interruzioni

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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
strategia zero-downtime	aggiornamento progressivo	Aggiornamento progressivo, insieme a tutte le altre strategie di Kubernetes	slot di implementazione

È importante notare che anche le architetture dell'applicazione devono supportare la distribuzione senza tempi di inattività. Per indicazioni, vedere Azure Well-Architected Framework.

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	AKS (Servizio Azure Kubernetes)	Applicazione Web per container
limiti delle risorse (CPU o memoria)	Per app/contenitore	Per app/contenitore Per spazio dei nomi	Per piano del servizio App

• App Web per contenitori: è possibile ospitare più applicazioni (contenitori) in un singolo piano App Service. 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. Per isolare le risorse dell'applicazione, è necessario creare piani di servizio app aggiuntivi.
• App di Contenitore: È possibile impostare limiti di CPU e memoria per ciascuna applicazione nell'ambiente. Tuttavia, siete 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 di Container Apps è paragonabile a uno spazio dei nomi Kubernetes.
• AKS: puoi scegliere qualsiasi combinazione di vCPU e memoria, purché i nodi abbiano l'hardware necessario per supportarla. È anche possibile limitare le risorse a livello di spazio dei nomi se si vuole segmentare il cluster in questo modo.

Well-Architected Framework 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:

• revisione di Well-Architected Framework per il servizio Azure Kubernetes
• Affidabilità nelle app container
• Servizio App di Azure e affidabilità

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ì il massimo controllo e configurabilità, mentre il servizio Azure Kubernetes Automatico offre un equilibrio tra controllo e semplicità automatizzando molte attività operative.

La quantità di overhead operativo e complessità è altamente variabile per i carichi di lavoro di AKS. 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. Si consiglia di considerare prima le Container Apps.

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 di Dapr e altro ancora. Tuttavia, i team che non necessitano di queste funzionalità e hanno familiarità con il networking e i modelli di distribuzione di App Service potrebbero preferire Web App per i container.

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.

Contributori

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

Autori principali:

• Andre Dewes | Ingegnere Senior del Cliente
• Xuhong Liu | Ingegnere Senior dei Servizi
• Marcos Martinez | Ingegnere di Servizio Senior
• Julie Ng | Ingegnere Senior

Altri collaboratori:

• Mick Alberts | Redattore tecnico
• Martin Gjoššski | Senior Customer Engineer
• Don High | Ingegnere Principale per i Clienti
• Nelly Kiboi | Tecnico del servizio
• Faisal Mustafa | Ingegnere Senior per i Clienti
• Walter Myers | Responsabile Principale dell'Ingegneria Clienti
• Sonalika Roy | Ingegnere Capo del Servizio Clienti
• Paolo Salvatori | Ingegnere Capo Clienti
• Victor Santana | Ingegnere Principale per i Clienti

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

Passaggi successivi

• documentazione di Azure Kubernetes Service (AKS)
• documentazione di App contenitore
• documentazione del servizio applicativo

Risorse correlate

• AKS di Azure Kubernetes Service - Pianifica il tuo design e le operazioni
• Distribuire microservizi con App Azure Container
• Trasferire in modalità lift-and-shift ai contenitori con il servizio app di Azure