Architettura di microservizi nel servizio Azure Kubernetes

Microsoft Entra ID

Registro Azure Container

Servizio Azure Kubernetes (AKS)

Azure Load Balancer

Azure Pipelines

Monitoraggio di Azure

Questa architettura di riferimento mostra un'applicazione di microservizi distribuita in servizio Azure Kubernetes (servizio Azure Kubernetes). Descrive una configurazione di base del servizio Azure Kubernetes che è possibile usare come punto di partenza per la maggior parte delle distribuzioni. Questo articolo presuppone che si abbia una conoscenza di base di Kubernetes. L'articolo illustra principalmente gli aspetti dell'infrastruttura e di DevOps su come gestire i microservizi nel servizio Azure Kubernetes. Per altre informazioni su come progettare microservizi, vedere progettazione dell'architettura dei microservizi.

Un'implementazione di riferimento di questa architettura è disponibile in GitHub.

Architettura

Il diagramma mostra i microservizi nell'architettura di riferimento del servizio Azure Kubernetes. Illustra un'applicazione composta da più microservizi distribuiti nel servizio Azure Kubernetes. Il flusso di richiesta usa il sottoscrittore del server di pubblicazione, i consumer concorrenti e i modelli di progettazione cloud di routing del gateway. Il flusso inizia con l'applicazione client che invia un payload JSON tramite HTTPS al nome di dominio completo completo del servizio di bilanciamento del carico per pianificare un ritiro tramite drone. Il servizio di bilanciamento del carico indirizza la richiesta al microservizio di inserimento, che elabora e accoda le richieste di recapito in una coda del bus di servizio di Azure. Il microservizio flusso di lavoro usa quindi i messaggi dalla coda del bus di servizio e invia richieste HTTPS a più microservizi. Questi servizi includono l'utilità di pianificazione drone, il recapito e i microservizi del pacchetto. Il microservizio di recapito archivia i dati in Cache Redis di Azure e il microservizio del pacchetto archivia i dati in MongoDB. Una richiesta HTTPS GET restituisce lo stato del recapito. Passa attraverso il servizio di bilanciamento del carico al microservizio di recapito, che legge i dati da Cache Redis di Azure.

Helm è un marchio di Cloud Native Computing Foundation (CNF). Nessuna verifica dell'autenticità è implicita nell'uso di questo marchio.

Scaricare un file di Visio di questa architettura.

Se si vuole visualizzare un esempio di microservizio più avanzato basato sull'architettura di base del servizio Azure Kubernetes , vedere l'architettura dei microservizi del servizio Azure Kubernetes avanzata .

Flusso di lavoro

Questo flusso di richiesta implementa l'sottoscrittore del server di pubblicazione, consumer concorrentie gateway di routing modelli di progettazione cloud.

Il flusso di dati seguente corrisponde al diagramma precedente:

1. L'applicazione client invia un payload JSON tramite HTTPS al nome di dominio completo pubblico del servizio di bilanciamento del carico (controller di ingresso gestito) per pianificare un ritiro tramite drone.

   • Il controller di ingresso gestito indirizza la richiesta al microservizio di inserimento.

   • Il microservizio di inserimento elabora le richieste di recapito delle richieste e delle code in una coda del bus di servizio di Azure.

2. Microservizio flusso di lavoro:

   • Utilizza le informazioni sui messaggi dalla coda di messaggi bus di servizio.

   • Invia una richiesta HTTPS al microservizio di recapito, che passa i dati all'archiviazione dati esterna in Cache Redis di Azure.

   • Invia una richiesta HTTPS al microservizio dell'utilità di pianificazione drone.

   • Invia una richiesta HTTPS al microservizio del pacchetto, che passa i dati all'archiviazione dati esterna in MongoDB.

3. Una richiesta HTTPS GET restituisce lo stato del recapito. Questa richiesta passa attraverso il controller di ingresso gestito nel microservizio di recapito. Il microservizio di recapito legge quindi i dati da Cache Redis di Azure.

Per altre informazioni sull'applicazione di microservizi di esempio, vedere esempio di implementazione di riferimento dei microservizi.

Componenti

• servizio Azure Kubernetes è un cluster Kubernetes gestito ospitato nel cloud di Azure. Il servizio Azure Kubernetes riduce la complessità e il sovraccarico operativo della gestione di Kubernetes eseguendo l'offload di gran parte di tale responsabilità in Azure.

• Un server in ingresso espone le route HTTP(S) ai servizi all'interno del cluster. L'implementazione di riferimento usa un controller di ingresso basato su NGINX tramite un componente aggiuntivo di routing dell'applicazione. Il controller di ingresso implementa il modello gateway API per i microservizi.

• gli archivi dati esterni, ad esempio database SQL di Azure o di Azure Cosmos DB, vengono usati dai microservizi senza stato per scrivere i dati e altre informazioni sullo stato. L'implementazione di riferimento usa azure Cosmos DB, cache di Azure per Redis, Azure Cosmos DB per MongoDB e bus di servizio come archivi dati o posizioni in cui archiviare lo stato.

• è necessario microsoft Entra ID per il cluster del servizio Azure Kubernetes. Fornisce un'identità gestita usata per accedere a Registro Azure Container e per accedere e effettuare il provisioning di risorse di Azure come servizi di bilanciamento del carico e dischi gestiti. I carichi di lavoro distribuiti in un cluster del servizio Azure Kubernetes richiedono anche un'identità in Microsoft Entra per accedere alle risorse protette da Microsoft Entra, ad esempio Azure Key Vault e Microsoft Graph. In questa architettura di riferimento ID carico di lavoro Di Microsoft Entra si integra con Kubernetes e fornisce carichi di lavoro con identità. È anche possibile usare identità gestite o credenziali dell'applicazione per ogni carico di lavoro.

• registro Contenitori può essere usato per archiviare le immagini del contenitore privato, distribuite nel cluster. Il servizio Azure Kubernetes può eseguire l'autenticazione con registro contenitori usando l'identità Microsoft Entra. Nell'implementazione di riferimento le immagini del contenitore di microservizi vengono compilate ed eseguite il push nel Registro Container.

• di Azure Pipelines fa parte della famiglia di prodotti Azure DevOps ed esegue compilazioni, test e distribuzioni automatizzate. Un approccio di integrazione continua e distribuzione continua (CI/CD) è altamente consigliato negli ambienti di microservizi. Diversi team possono creare e distribuire in modo indipendente i microservizi nel servizio Azure Kubernetes usando Azure Pipelines.

• Helm è una gestione pacchetti per Kubernetes che fornisce un meccanismo per aggregare e standardizzare gli oggetti Kubernetes in una singola unità che può essere pubblicata, distribuita, con controllo delle versioni e aggiornata.

• Monitoraggio di Azure raccoglie e archivia metriche e log, dati di telemetria delle applicazioni e metriche della piattaforma per i servizi di Azure. Monitoraggio di Azure si integra con il servizio Azure Kubernetes per raccogliere metriche da controller, nodi e contenitori.

• Application Insights monitora i microservizi e i contenitori. Può essere usato per fornire l'osservabilità ai microservizi, che include il flusso del traffico, la latenza end-to-end e la percentuale di errore. L'integrità dei microservizi e le relazioni tra di esse possono essere visualizzate su una singola mappa dell'applicazione.

Alternative

app Azure Container offre un'esperienza Kubernetes serverless gestita. Funge da alternativa più semplice al servizio Azure Kubernetes per l'hosting di microservizi quando non è necessario l'accesso diretto a Kubernetes o alle relative API e non richiede il controllo sull'infrastruttura del cluster.

Anziché il gateway di ingresso gestito nel servizio Azure Kubernetes, è possibile usare alternative come gateway applicazione per contenitori, gateway di ingresso Istio o soluzioni non Microsoft. Per altre informazioni, vedere ingresso nel servizio Azure Kubernetes.

È possibile archiviare le immagini del contenitore in registri contenitori non Microsoft, ad esempio Docker Hub.

Per i microservizi che devono gestire le informazioni sullo stato, dapr fornisce un livello di astrazione per la gestione dello stato del microservizio.

È possibile usare GitHub Actions per compilare e distribuire microservizi oppure scegliere soluzioni CI/CD non Microsoft come Jenkins.

È possibile ottenere l'osservabilità del microservizio con strumenti alternativi come Kiali.

Dettagli dello scenario

L'esempio 'implementazione di riferimento di microservizi implementa i componenti e le procedure dell'architettura descritti in questo articolo. In questo esempio, una società fittizia denominata Fabrikam, Inc., gestisce una flotta di aerei da drone. Le aziende possono registrarsi per usare il servizio e gli utenti possono richiedere un drone per prelevare merci da consegnare. Quando un cliente pianifica un ritiro, il sistema back-end assegna un drone e invia una notifica all'utente con un tempo di consegna stimato. Quando la consegna è in corso, il cliente può tenere traccia della posizione del drone con un tempo di consegna stimato continuamente aggiornato.

Lo scenario mira a illustrare l'architettura dei microservizi e le procedure consigliate per la distribuzione nel servizio Azure Kubernetes.

Casi d'uso potenziali

Adottare le procedure consigliate seguenti dallo scenario per progettare applicazioni complesse basate su microservizi nel servizio Azure Kubernetes:

• Applicazioni Web complesse
• Logica di business sviluppata usando i principi di progettazione di microservizi

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Progettazione

Questa architettura di riferimento è incentrata sui microservizi, ma molte delle procedure consigliate si applicano ad altri carichi di lavoro eseguiti nel servizio Azure Kubernetes.

Microservizi

Un microservizio è un'unità di codice a regime di controllo libero, distribuibile in modo indipendente. I microservizi in genere comunicano tramite API ben definite e sono individuabili tramite una forma di individuazione dei servizi. L'oggetto servizio Kubernetes è un modo tipico per modellare i microservizi in Kubernetes.

Archiviazione di dati

In un'architettura di microservizi i servizi non devono condividere soluzioni di archiviazione dei dati. Ogni servizio deve gestire il proprio set di dati per evitare dipendenze nascoste tra i servizi. La separazione dei dati consente di evitare l'accoppiamento involontario tra i servizi. Questo processo può verificarsi quando i servizi condividono gli stessi schemi di dati sottostanti. Quando i servizi gestiscono i propri archivi dati, possono usare l'archivio dati corretto per i requisiti specifici. Per altre informazioni, vedere Considerazioni sui dati per i microservizi.

Evitare di archiviare dati persistenti nell'archiviazione cluster locale perché tale metodo associa i dati al nodo. Usare invece un servizio esterno, ad esempio il database SQL o Azure Cosmos DB. Un'altra opzione consiste nel montare un volume di dati permanente in una soluzione usando Archiviazione dischi di Azure o File di Azure. Per altre informazioni, vedere Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes.

Gateway API

I gateway API sono uno schema progettuale generale di microservizi. Un gateway API si trova tra client esterni e microservizi. Il gateway funge da proxy inverso e instrada le richieste dai client ai microservizi. Un gateway API può anche eseguire varie attività di taglio incrociato, ad esempio l'autenticazione, la terminazione SSL (Secure Sockets Layer) e la limitazione della frequenza. Per altre informazioni, vedere le risorse seguenti:

• Usare i gateway API nei microservizi

• Scegliere una tecnologia gateway API

In Kubernetes un controller di ingresso gestisce principalmente la funzionalità di un gateway API. Il controller in ingresso e in ingresso funziona insieme a:

• Instradare le richieste client ai microservizi back-end corretti. Questo routing fornisce un singolo endpoint per i client e consente di disaccoppiare i client dai servizi.

• Aggregare più richieste in una singola richiesta per ridurre la chattiness tra il client e il back-end.

• Funzionalità di offload dai servizi back-end, ad esempio terminazione SSL, autenticazione, restrizioni degli indirizzi IP o limitazione della frequenza client (denominata limitazione).

Sono disponibili controller di ingresso per proxy inversi, tra cui NGINX, HAProxy, Traefik e gateway applicazione di Azure. Il servizio Azure Kubernetes offre più opzioni di ingresso gestito. È possibile scegliere tra un controller di ingresso gestito basato su NGINX tramite il componente aggiuntivo di routing dell'applicazione, gateway applicazione per contenitori. In alternativa, è possibile scegliere Gateway di ingresso Istio come controller di ingresso. Per altre informazioni, vedere ingresso nel servizio Azure Kubernetes.

Le risorse di ingresso degli oggetti Kubernetes sono state sostituite dall'API del gateway Kubernetes più avanzata e versatile. Il controller di ingresso e l'API gateway sono entrambi oggetti Kubernetes usati per il routing di gestione del traffico e il bilanciamento del carico. Progettato per essere generico, espressivo, estendibile e orientato ai ruoli, l'API gateway è un set moderno di API per la definizione delle regole di routing L4 e L7 in Kubernetes.

Il controller di ingresso opera come router perimetrale o proxy inverso. Un server proxy inverso è un potenziale collo di bottiglia o un singolo punto di errore, pertanto è consigliabile distribuire almeno due repliche per garantire la disponibilità elevata.

Quando scegliere controller di ingresso o API gateway

Le risorse in ingresso sono adatte ai casi d'uso seguenti:

• I controller di ingresso sono facili da configurare e sono adatti per distribuzioni Kubernetes più piccole e meno complesse che assegnano priorità alla configurazione semplice.

• Se nel cluster Kubernetes sono attualmente configurati controller di ingresso e soddisfano in modo efficace i requisiti, potrebbe non essere necessario passare immediatamente all'API del gateway Kubernetes.

È consigliabile usare l'API gateway:

• Quando si gestiscono configurazioni di routing complesse, suddivisione del traffico e strategie avanzate di gestione del traffico. La flessibilità offerta dalle risorse route dell'API del gateway Kubernetes è essenziale.

• Se i requisiti di rete richiedono soluzioni personalizzate o l'integrazione di plug-in non Microsoft. L'approccio dell'API del gateway Kubernetes, basato sulle definizioni di risorse personalizzate, può offrire un'estendibilità avanzata.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Microservizi di partizionamento

Usare gli spazi dei nomi per organizzare i servizi all'interno del cluster. Ogni oggetto in un cluster Kubernetes appartiene a uno spazio dei nomi. È consigliabile usare gli spazi dei nomi per organizzare le risorse nel cluster.

Gli spazi dei nomi consentono di evitare conflitti di denominazione. Quando più team distribuiscono i microservizi nello stesso cluster, assieme a circa un centinaio di microservizi, diventa difficile da gestire se passano tutti nello stesso spazio dei nomi. Gli spazi dei nomi consentono anche di:

• Applicare vincoli di risorsa a uno spazio dei nomi in modo che il set totale di pod assegnati a tale spazio dei nomi non possa superare la quota di risorse dello spazio dei nomi.

• Applicare criteri a livello di spazio dei nomi, che includono il controllo degli accessi in base al ruolo e i criteri di sicurezza.

Quando più team sviluppano e distribuiscono microservizi, è possibile usare gli spazi dei nomi come un meccanismo pratico per controllare le aree in cui ogni team può eseguire la distribuzione. Ad esempio, al team di sviluppo A può essere concesso l'accesso solo allo spazio dei nomi A e al team di sviluppo B è possibile concedere l'accesso solo allo spazio dei nomi B tramite i criteri di controllo degli accessi in base al ruolo .

Per un'architettura di microservizi, è consigliabile organizzare i microservizi in contesti delimitati e creare spazi dei nomi per ogni contesto delimitato. Ad esempio, tutti i microservizi correlati al contesto delimitato "Order Fulfillment" possono entrare nello stesso spazio dei nomi. In alternativa, creare uno spazio dei nomi per ogni team di sviluppo.

Posizionare i servizi di utilità nel proprio spazio dei nomi separato. Ad esempio, è possibile distribuire strumenti di monitoraggio del cluster come Elasticsearch e Prometheus in uno spazio dei nomi di monitoraggio.

Probe di integrità

Kubernetes definisce tre tipi di probe di integrità che un pod può esporre:

• probe di idoneità: indica a Kubernetes se il pod è pronto ad accettare le richieste.

• probe di Liveness: indica a Kubernetes se rimuovere un pod e avviare una nuova istanza.

• probe di avvio: indica a Kubernetes se il pod è stato avviato.

Quando si pensa ai probe, è importante ricordare il funzionamento di un servizio in Kubernetes. Un servizio ha un selettore di etichette che corrisponde a un set di zero o più pod. Kubernetes bilancia il carico di traffico verso i pod che corrispondono al selettore. Solo i pod che vengono avviati correttamente e ricevono il traffico integro. Se un contenitore si arresta in modo anomalo, Kubernetes termina il pod e pianifica una sostituzione.

A volte un pod potrebbe non essere pronto per ricevere traffico, anche se è stato avviato correttamente. Ad esempio, potrebbero essere in corso attività di inizializzazione, ad esempio quando l'applicazione in esecuzione nel contenitore carica i dati in memoria o legge i file di configurazione. È possibile usare un probe di avvio per questi contenitori a avvio lento. Questo approccio consente di impedire a Kubernetes di terminarli prima di poter inizializzare completamente.

I probe di attività vengono usati per verificare se un pod è in esecuzione ma non funziona correttamente e deve essere riavviato. Ad esempio, se un contenitore gestisce le richieste HTTP ma smette improvvisamente di rispondere senza arrestarsi in modo anomalo, il probe di attività rileva questo evento e attiva un riavvio del pod. Se si configura un probe di attività, si nota quando un contenitore non risponde e chiede a Kubernetes di riavviare il pod se il contenitore ha ripetutamente esito negativo.

Quando si progettano probe per i microservizi, tenere presente quanto segue.

• Se il codice ha un tempo di avvio lungo, esiste un pericolo che un probe di attività segnala un errore prima del completamento dell'avvio. Per ritardare l'inizio di un probe di attività, usare il probe di avvio o usare l'impostazione initialDelaySeconds con il probe di attività.

• Un probe di attività consente solo se è probabile che il riavvio del pod venga ripristinato in uno stato integro. È possibile usare un probe di attività per ridurre le perdite di memoria o i deadlock imprevisti, ma non c'è motivo per riavviare un pod che si verificherà immediatamente un errore.

• In alcuni casi i probe di idoneità vengono usati per controllare i servizi dipendenti. Ad esempio, se un pod ha una dipendenza da un database, il probe potrebbe controllare la connessione al database. Tuttavia, questo è un approccio che può creare problemi imprevisti. Un servizio esterno potrebbe non essere temporaneamente disponibile. Questa indisponibilità causa l'esito negativo del probe di idoneità per tutti i pod nel servizio, che comporta la rimozione dal bilanciamento del carico. Questa rimozione crea errori a catena upstream.

  Un approccio migliore consiste nell'implementare la gestione dei tentativi all'interno del servizio in modo che il servizio possa eseguire correttamente il ripristino da errori temporanei. In alternativa, la gestione dei tentativi, la tolleranza di errore e gli interruttori di circuito possono essere implementati dalla mesh del servizio Istio per creare un'architettura resiliente in grado di gestire gli errori del microservizio.

Vincoli delle risorse

I vincoli delle risorse possono influire sulla disponibilità di un servizio. Definire vincoli di risorse per i contenitori in modo che un singolo contenitore non possa sovraccaricare le risorse del cluster, ad esempio memoria e CPU. Per le risorse non contenitore, ad esempio thread o connessioni di rete, è consigliabile usare il modello bulkhead per isolare le risorse.

Usare quote di risorse per limitare le risorse totali consentite per uno spazio dei nomi. Questa limitazione garantisce che il front-end non possa morire di fame i servizi back-end per le risorse o viceversa. Le quote di risorse consentono di allocare risorse all'interno dello stesso cluster a più team di sviluppo di microservizi.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.

Crittografia TLS e SSL

In molte implementazioni, il controller di ingresso viene usato per la terminazione SSL. Nell'ambito della distribuzione del controller di ingresso, è necessario creare o importare un certificato TLS (Transport Layer Security). Usare certificati autofirmato solo a scopo di sviluppo e test. Per altre informazioni, vedere Configurare un nome di dominio personalizzato e un certificato SSL con il componente aggiuntivo di routing dell'applicazione.

Per i carichi di lavoro di produzione, ottenere i certificati firmati dalle autorità di certificazione attendibili.

Potrebbe anche essere necessario ruotare i certificati in base ai criteri dell'organizzazione. È possibile usare Key Vault per ruotare i certificati usati dai microservizi. Per altre informazioni, vedere Configurare la rotazione automatica dei certificati in Key Vault.

Controllo degli accessi in base al ruolo

Quando più team sviluppano e distribuiscono contemporaneamente microservizi, i meccanismi di controllo degli accessi in base al ruolo del servizio Azure Kubernetes possono fornire un controllo granulare e un filtro delle azioni utente. È possibile usare il controllo degli accessi in base al ruolo di Kubernetes o il controllo degli accessi in base al ruolo di Azure con Microsoft Entra ID per controllare l'accesso alle risorse del cluster. Per altre informazioni, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes.

Autenticazione e autorizzazione

I microservizi possono richiedere agli utenti o ai servizi di utilizzo di autenticare e autorizzare l'accesso al microservizio usando certificati, credenziali e meccanismi di controllo degli accessi in base al ruolo. Microsoft Entra ID può essere usato per implementare token OAuth 2.0 per l'autorizzazione. Le mesh di servizi come Istio forniscono anche meccanismi di autorizzazione e autenticazione per i microservizi, tra cui la convalida dei token OAuth e il routing basato su token. L'implementazione di riferimento non riguarda gli scenari di autenticazione e autorizzazione di microservizi.

Gestione dei segreti e credenziali dell'applicazione

Le applicazioni e i servizi spesso necessitano di credenziali che consentono loro di connettersi ai servizi esterni, ad esempio archiviazione di Azure o Database SQL. La sfida consiste nel proteggere queste credenziali e far sì che non vengano perse.

Per le risorse di Azure, usare le identità gestite quando possibile. Un'identità gestita è simile a un ID univoco per un'applicazione o un servizio archiviato nell'ID Microsoft Entra. Usa questa identità per eseguire l'autenticazione con un servizio di Azure. L'applicazione o il servizio dispone di un'entità servizio creata per tale entità servizio in Microsoft Entra ID ed esegue l'autenticazione tramite token OAuth 2.0. Il codice in esecuzione all'interno del processo può ottenere in modo trasparente il token. Questo approccio consente di garantire che non sia necessario archiviare password o stringhe di connessione. Per usare le identità gestite, è possibile assegnare le identità di Microsoft Entra ai singoli pod nel servizio Azure Kubernetes usando ID carico di lavoro Di Microsoft Entra.

Anche quando si usano identità gestite, potrebbe essere comunque necessario archiviare alcune credenziali o altri segreti dell'applicazione. Questa risorsa di archiviazione è necessaria per i servizi di Azure che non supportano identità gestite, servizi non Microsoft o chiavi API. È possibile usare le opzioni seguenti per archiviare i segreti in modo più sicuro:

• Key Vault: nel servizio Azure Kubernetes, è possibile montare uno o più segreti da Key Vault come volume. Il volume legge i segreti da Key Vault. Il pod può quindi leggere i segreti come un volume normale. Per altre informazioni, vedere Usare il provider di Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes. Il pod esegue l'autenticazione usando un'identità del carico di lavoro o un'identità gestita assegnata dal sistema o un utente. Per altre informazioni, vedere Connettere il provider di identità di Azure al driver CSI dell'archivio segreti di Key Vault nel servizio Azure Kubernetes.

• HashiCorp Vault: identità gestite di Microsoft Entra consentono alle applicazioni Kubernetes di eseguire l'autenticazione con HashiCorp Vault. È possibile distribuire l'insieme di credenziali in Kubernetes. Prendere in considerazione l'esecuzione in un cluster dedicato separato dal cluster dell'applicazione.

• segreti Kubernetes: Un'altra opzione consiste nell'usare i segreti Kubernetes. Questa opzione è la più semplice da configurare ma meno sicura. I segreti vengono archiviati in etcd, ovvero un archivio chiave-valore. Il servizio Azure Kubernetes crittografa etcd inattivi. Le chiavi di crittografia sono gestite da Microsoft.

L'uso di una soluzione come Key Vault offre diversi vantaggi, tra cui:

• Controllo centralizzato dei segreti.
• Contribuire a garantire che tutti i segreti siano crittografati inattivi.
• Gestione centralizzata delle chiavi.
• Controllo dell'accesso dei segreti.
• Gestione del ciclo di vita chiave.
• Controllo.

L'implementazione di riferimento archivia le stringhe di connessione di Azure Cosmos DB e altri segreti in Key Vault. L'implementazione di riferimento usa un'identità gestita per i microservizi per l'autenticazione in Key Vault e l'accesso ai segreti.

Sicurezza di contenitori e agenti di orchestrazione

Le procedure consigliate seguenti consentono di proteggere i pod e i contenitori.

• Monitorare le minacce. Monitorare le minacce usando Microsoft Defender per contenitori o una funzionalità non Microsoft. Se si ospitano contenitori in una macchina virtuale, usare Microsoft Defender per server o una funzionalità non Microsoft. È anche possibile integrare i log dalla soluzione di monitoraggio Contenitore in Monitoraggio di Azure a microsoft Sentinel o a una soluzione SIEM (Security Information and Event Management) esistente.

• Monitorare le vulnerabilità. Monitorare continuamente le immagini e i contenitori in esecuzione per individuare vulnerabilità note usando Microsoft Defender for Cloud o una soluzione non Microsoft.

• Automatizzare l'applicazione di patch alle immagini. Usare attività di Registro Azure Container, una funzionalità di Registro Container, per automatizzare l'applicazione di patch alle immagini. Un'immagine del contenitore viene costruita a partire da livelli. I livelli di base includono l'immagine del sistema operativo e le immagini di framework dell'applicazione, ad esempio ASP.NET Core o Node. js. Le immagini di base vengono in genere create upstream dagli sviluppatori di applicazioni e altri gestori di progetti li mantengono. Quando queste immagini vengono patch a monte, è importante aggiornare, testare e ridistribuire le proprie immagini in modo che non si lascino vulnerabilità di sicurezza note. Le attività di Registro Azure Container consentono di automatizzare questo processo.

• Archiviare le immagini in un registro privato attendibile. Usare un registro privato attendibile, ad esempio Registro Contenitori o Registro attendibile Docker per archiviare le immagini. Usare un webhook di ammissione di convalida in Kubernetes per garantire che i pod possano recuperare solo immagini dal registro attendibile.

• Applicare il principio dei privilegi minimi. Non eseguire i contenitori in modalità privilegiata. La modalità privilegiata fornisce a un contenitore l'accesso a tutti i dispositivi nell'host. Quando possibile, evitare di eseguire i processi come radice all'interno di contenitori. I contenitori non forniscono l'isolamento completo dal punto di vista della sicurezza, quindi è preferibile eseguire un processo di contenitore come utente senza privilegi.

Considerazioni sull'integrazione continua/distribuzione continua

Considerare gli obiettivi seguenti di un processo CI/CD affidabile per un'architettura di microservizi:

• Ogni team può creare e distribuire i servizi di sua proprietà in modo indipendente, senza influenzare o interrompere gli altri team.

• Prima di distribuire una nuova versione di un servizio nell'ambiente di produzione, viene distribuita in ambienti di sviluppo, test e Q&A per la convalida. I controlli di qualità vengono applicati in ogni fase.

• Una nuova versione di un servizio può essere distribuita side-by-side con la versione precedente.

• Vengono applicati sufficienti criteri di controllo di accesso.

• Per i carichi di lavoro in contenitori, è possibile considerare attendibili le immagini del contenitore distribuite nell'ambiente di produzione.

Per altre informazioni sulle problematiche, vedere CI/CD per le architetture di microservizi.

L'uso di una mesh di servizi come Istio può essere utile per i processi CI/CD, ad esempio distribuzioni canary, test A/B di microservizi e implementazioni a fasi con suddivisioni del traffico in base alla percentuale.

Per altre informazioni su raccomandazioni e procedure consigliate specifiche, vedere Creare una pipeline CI/CD per microservizi in Kubernetes con Azure DevOps e Helm.

Ottimizzazione costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Usare il calcolatore dei prezzi di Azure per stimare i costi. Altre considerazioni sono descritte nella sezione Cost in Microsoft Azure Well-Architected Framework.

Considerare i punti seguenti per alcuni dei servizi usati in questa architettura.

AKS (Servizio Azure Kubernetes)

• Nel livello gratuitonon sono associati costi per il servizio Azure Kubernetes nella distribuzione, nella gestione e nelle operazioni del cluster Kubernetes. Si paga solo per le istanze della macchina virtuale, l'archiviazione e le risorse di rete usate dal cluster Kubernetes.

• È consigliabile usare 'utilità di scalabilità automatica orizzontale dei pod per ridimensionare automaticamente i microservizi in o aumentarne il numero in base al carico.

• Configurare di scalabilità automatica del cluster per ridimensionare o aumentare le istanze dei nodi in base al carico.

• È consigliabile usare nodi spot per ospitare microservizi non critici.

• Esaminare le procedure consigliate per l'ottimizzazione dei costi per il servizio Azure Kubernetes.

• Per stimare il costo delle risorse necessarie, usare il calcolatore del servizio Azure Kubernetes .

Bilanciatore di carico Azure

Vengono addebitati solo il numero di regole di bilanciamento del carico e in uscita configurate. Le regole di conversione degli indirizzi di rete in ingresso sono gratuite. Non è previsto alcun addebito orario per il Load Balancer Standard quando non sono configurate regole. Per altre informazioni, vedere prezzi di Azure Load Balancer.

Azure Pipelines

Questa architettura di riferimento usa solo Azure Pipelines. Azure fornisce la pipeline come singolo servizio. È consentito un processo ospitato gratuitamente da Microsoft con 1.800 minuti per ogni mese per CI/CD e un processo self-hosted con minuti illimitati per ogni mese. I processi aggiuntivi comportano più costi. Per altre informazioni, vedere prezzi dei servizi Azure DevOps.

Monitoraggio di Azure

Per Log Analytics di Monitoraggio di Azure, vengono addebitati costi per l'inserimento e la conservazione dei dati. Per altre informazioni, vedere Prezzi di Monitoraggio di Azure.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Questa architettura di riferimento include file Bicep per il provisioning delle risorse cloud e delle relative dipendenze. È possibile usare azure Pipelines per distribuire questi file Bicep e configurare rapidamente ambienti diversi, ad esempio la replica di scenari di produzione. Questo approccio consente di risparmiare sui costi effettuando il provisioning di ambienti di test di carico solo quando necessario.

Prendere in considerazione i criteri di isolamento del carico di lavoro per strutturare il file Bicep. Un carico di lavoro viene in genere definito come un'unità arbitraria di funzionalità. Ad esempio, è possibile avere un file Bicep separato per il cluster e quindi un altro file per i servizi dipendenti. È possibile usare Azure DevOps per eseguire CI/CD con isolamento del carico di lavoro perché ogni carico di lavoro è associato e gestito dal proprio team.

Distribuire lo scenario

Per distribuire l'implementazione di riferimento per questa architettura, seguire la procedura descritta nel repository GitHub. Per altre informazioni, vedere implementazione di riferimento microservizi del servizio Azure Kubernetes.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• Francesco Simy Nazareth | Senior Technical Specialist

Altri collaboratori:

• Paolo Salvatori | Ingegnere Principale per i Clienti
• Alessandro Vossa | Senior Technical Specialist

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

Passaggi successivi

• Usare un'entità servizio con il servizio Azure Kubernetes
• Protezione dei contenitori in Defender for Cloud
• Pianificare la distribuzione di Defender per server
• soluzione di monitoraggio dei contenitori in Monitoraggio di Azure
• microsoft Sentinel o una soluzione SIEM esistente
• Defender for Cloud o una soluzione non Microsoft disponibile tramite Azure Marketplace
• Automatizzare le compilazioni e la manutenzione delle immagini del contenitore con le attività di Registro Azure Container

Risorse correlate

• Per un esempio di microservizi più avanzati, vedere 'architettura dei microservizi del servizio Azure Kubernetes avanzata.
• CI/CD per le architetture di microservizi
• CI/CD per microservizi in Kubernetes

Questa architettura di riferimento mostra un'applicazione di microservizi distribuita in servizio Azure Kubernetes (servizio Azure Kubernetes). Descrive una configurazione di base del servizio Azure Kubernetes che è possibile usare come punto di partenza per la maggior parte delle distribuzioni. Questo articolo presuppone che si abbia una conoscenza di base di Kubernetes. L'articolo illustra principalmente gli aspetti dell'infrastruttura e di DevOps su come gestire i microservizi nel servizio Azure Kubernetes. Per altre informazioni su come progettare microservizi, vedere progettazione dell'architettura dei microservizi.

Un'implementazione di riferimento di questa architettura è disponibile in GitHub.

Architettura

Il diagramma mostra i microservizi nell'architettura di riferimento del servizio Azure Kubernetes. Illustra un'applicazione composta da più microservizi distribuiti nel servizio Azure Kubernetes. Il flusso di richiesta usa il sottoscrittore del server di pubblicazione, i consumer concorrenti e i modelli di progettazione cloud di routing del gateway. Il flusso inizia con l'applicazione client che invia un payload JSON tramite HTTPS al nome di dominio completo completo del servizio di bilanciamento del carico per pianificare un ritiro tramite drone. Il servizio di bilanciamento del carico indirizza la richiesta al microservizio di inserimento, che elabora e accoda le richieste di recapito in una coda del bus di servizio di Azure. Il microservizio flusso di lavoro usa quindi i messaggi dalla coda del bus di servizio e invia richieste HTTPS a più microservizi. Questi servizi includono l'utilità di pianificazione drone, il recapito e i microservizi del pacchetto. Il microservizio di recapito archivia i dati in Cache Redis di Azure e il microservizio del pacchetto archivia i dati in MongoDB. Una richiesta HTTPS GET restituisce lo stato del recapito. Passa attraverso il servizio di bilanciamento del carico al microservizio di recapito, che legge i dati da Cache Redis di Azure.

Helm è un marchio di Cloud Native Computing Foundation (CNF). Nessuna verifica dell'autenticità è implicita nell'uso di questo marchio.

Scaricare un file di Visio di questa architettura.

Se si vuole visualizzare un esempio di microservizio più avanzato basato sull'architettura di base del servizio Azure Kubernetes , vedere l'architettura dei microservizi del servizio Azure Kubernetes avanzata .

Flusso di lavoro

Questo flusso di richiesta implementa l'sottoscrittore del server di pubblicazione, consumer concorrentie gateway di routing modelli di progettazione cloud.

Il flusso di dati seguente corrisponde al diagramma precedente:

1. L'applicazione client invia un payload JSON tramite HTTPS al nome di dominio completo pubblico del servizio di bilanciamento del carico (controller di ingresso gestito) per pianificare un ritiro tramite drone.

   • Il controller di ingresso gestito indirizza la richiesta al microservizio di inserimento.

   • Il microservizio di inserimento elabora le richieste di recapito delle richieste e delle code in una coda del bus di servizio di Azure.

2. Microservizio flusso di lavoro:

   • Utilizza le informazioni sui messaggi dalla coda di messaggi bus di servizio.

   • Invia una richiesta HTTPS al microservizio di recapito, che passa i dati all'archiviazione dati esterna in Cache Redis di Azure.

   • Invia una richiesta HTTPS al microservizio dell'utilità di pianificazione drone.

   • Invia una richiesta HTTPS al microservizio del pacchetto, che passa i dati all'archiviazione dati esterna in MongoDB.

3. Una richiesta HTTPS GET restituisce lo stato del recapito. Questa richiesta passa attraverso il controller di ingresso gestito nel microservizio di recapito. Il microservizio di recapito legge quindi i dati da Cache Redis di Azure.

Per altre informazioni sull'applicazione di microservizi di esempio, vedere esempio di implementazione di riferimento dei microservizi.

Componenti

• servizio Azure Kubernetes è un cluster Kubernetes gestito ospitato nel cloud di Azure. Il servizio Azure Kubernetes riduce la complessità e il sovraccarico operativo della gestione di Kubernetes eseguendo l'offload di gran parte di tale responsabilità in Azure.

• Un server in ingresso espone le route HTTP(S) ai servizi all'interno del cluster. L'implementazione di riferimento usa un controller di ingresso basato su NGINX tramite un componente aggiuntivo di routing dell'applicazione. Il controller di ingresso implementa il modello gateway API per i microservizi.

• gli archivi dati esterni, ad esempio database SQL di Azure o di Azure Cosmos DB, vengono usati dai microservizi senza stato per scrivere i dati e altre informazioni sullo stato. L'implementazione di riferimento usa azure Cosmos DB, cache di Azure per Redis, Azure Cosmos DB per MongoDB e bus di servizio come archivi dati o posizioni in cui archiviare lo stato.

• è necessario microsoft Entra ID per il cluster del servizio Azure Kubernetes. Fornisce un'identità gestita usata per accedere a Registro Azure Container e per accedere e effettuare il provisioning di risorse di Azure come servizi di bilanciamento del carico e dischi gestiti. I carichi di lavoro distribuiti in un cluster del servizio Azure Kubernetes richiedono anche un'identità in Microsoft Entra per accedere alle risorse protette da Microsoft Entra, ad esempio Azure Key Vault e Microsoft Graph. In questa architettura di riferimento ID carico di lavoro Di Microsoft Entra si integra con Kubernetes e fornisce carichi di lavoro con identità. È anche possibile usare identità gestite o credenziali dell'applicazione per ogni carico di lavoro.

• registro Contenitori può essere usato per archiviare le immagini del contenitore privato, distribuite nel cluster. Il servizio Azure Kubernetes può eseguire l'autenticazione con registro contenitori usando l'identità Microsoft Entra. Nell'implementazione di riferimento le immagini del contenitore di microservizi vengono compilate ed eseguite il push nel Registro Container.

• di Azure Pipelines fa parte della famiglia di prodotti Azure DevOps ed esegue compilazioni, test e distribuzioni automatizzate. Un approccio di integrazione continua e distribuzione continua (CI/CD) è altamente consigliato negli ambienti di microservizi. Diversi team possono creare e distribuire in modo indipendente i microservizi nel servizio Azure Kubernetes usando Azure Pipelines.

• Helm è una gestione pacchetti per Kubernetes che fornisce un meccanismo per aggregare e standardizzare gli oggetti Kubernetes in una singola unità che può essere pubblicata, distribuita, con controllo delle versioni e aggiornata.

• Monitoraggio di Azure raccoglie e archivia metriche e log, dati di telemetria delle applicazioni e metriche della piattaforma per i servizi di Azure. Monitoraggio di Azure si integra con il servizio Azure Kubernetes per raccogliere metriche da controller, nodi e contenitori.

• Application Insights monitora i microservizi e i contenitori. Può essere usato per fornire l'osservabilità ai microservizi, che include il flusso del traffico, la latenza end-to-end e la percentuale di errore. L'integrità dei microservizi e le relazioni tra di esse possono essere visualizzate su una singola mappa dell'applicazione.

Alternative

app Azure Container offre un'esperienza Kubernetes serverless gestita. Funge da alternativa più semplice al servizio Azure Kubernetes per l'hosting di microservizi quando non è necessario l'accesso diretto a Kubernetes o alle relative API e non richiede il controllo sull'infrastruttura del cluster.

Anziché il gateway di ingresso gestito nel servizio Azure Kubernetes, è possibile usare alternative come gateway applicazione per contenitori, gateway di ingresso Istio o soluzioni non Microsoft. Per altre informazioni, vedere ingresso nel servizio Azure Kubernetes.

È possibile archiviare le immagini del contenitore in registri contenitori non Microsoft, ad esempio Docker Hub.

Per i microservizi che devono gestire le informazioni sullo stato, dapr fornisce un livello di astrazione per la gestione dello stato del microservizio.

È possibile usare GitHub Actions per compilare e distribuire microservizi oppure scegliere soluzioni CI/CD non Microsoft come Jenkins.

È possibile ottenere l'osservabilità del microservizio con strumenti alternativi come Kiali.

Dettagli dello scenario

L'esempio 'implementazione di riferimento di microservizi implementa i componenti e le procedure dell'architettura descritti in questo articolo. In questo esempio, una società fittizia denominata Fabrikam, Inc., gestisce una flotta di aerei da drone. Le aziende possono registrarsi per usare il servizio e gli utenti possono richiedere un drone per prelevare merci da consegnare. Quando un cliente pianifica un ritiro, il sistema back-end assegna un drone e invia una notifica all'utente con un tempo di consegna stimato. Quando la consegna è in corso, il cliente può tenere traccia della posizione del drone con un tempo di consegna stimato continuamente aggiornato.

Lo scenario mira a illustrare l'architettura dei microservizi e le procedure consigliate per la distribuzione nel servizio Azure Kubernetes.

Casi d'uso potenziali

Adottare le procedure consigliate seguenti dallo scenario per progettare applicazioni complesse basate su microservizi nel servizio Azure Kubernetes:

• Applicazioni Web complesse
• Logica di business sviluppata usando i principi di progettazione di microservizi

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Progettazione

Questa architettura di riferimento è incentrata sui microservizi, ma molte delle procedure consigliate si applicano ad altri carichi di lavoro eseguiti nel servizio Azure Kubernetes.

Microservizi

Un microservizio è un'unità di codice a regime di controllo libero, distribuibile in modo indipendente. I microservizi in genere comunicano tramite API ben definite e sono individuabili tramite una forma di individuazione dei servizi. L'oggetto servizio Kubernetes è un modo tipico per modellare i microservizi in Kubernetes.

Archiviazione di dati

In un'architettura di microservizi i servizi non devono condividere soluzioni di archiviazione dei dati. Ogni servizio deve gestire il proprio set di dati per evitare dipendenze nascoste tra i servizi. La separazione dei dati consente di evitare l'accoppiamento involontario tra i servizi. Questo processo può verificarsi quando i servizi condividono gli stessi schemi di dati sottostanti. Quando i servizi gestiscono i propri archivi dati, possono usare l'archivio dati corretto per i requisiti specifici. Per altre informazioni, vedere Considerazioni sui dati per i microservizi.

Evitare di archiviare dati persistenti nell'archiviazione cluster locale perché tale metodo associa i dati al nodo. Usare invece un servizio esterno, ad esempio il database SQL o Azure Cosmos DB. Un'altra opzione consiste nel montare un volume di dati permanente in una soluzione usando Archiviazione dischi di Azure o File di Azure. Per altre informazioni, vedere Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes.

Gateway API

I gateway API sono uno schema progettuale generale di microservizi. Un gateway API si trova tra client esterni e microservizi. Il gateway funge da proxy inverso e instrada le richieste dai client ai microservizi. Un gateway API può anche eseguire varie attività di taglio incrociato, ad esempio l'autenticazione, la terminazione SSL (Secure Sockets Layer) e la limitazione della frequenza. Per altre informazioni, vedere le risorse seguenti:

• Usare i gateway API nei microservizi

• Scegliere una tecnologia gateway API

In Kubernetes un controller di ingresso gestisce principalmente la funzionalità di un gateway API. Il controller in ingresso e in ingresso funziona insieme a:

• Instradare le richieste client ai microservizi back-end corretti. Questo routing fornisce un singolo endpoint per i client e consente di disaccoppiare i client dai servizi.

• Aggregare più richieste in una singola richiesta per ridurre la chattiness tra il client e il back-end.

• Funzionalità di offload dai servizi back-end, ad esempio terminazione SSL, autenticazione, restrizioni degli indirizzi IP o limitazione della frequenza client (denominata limitazione).

Sono disponibili controller di ingresso per proxy inversi, tra cui NGINX, HAProxy, Traefik e gateway applicazione di Azure. Il servizio Azure Kubernetes offre più opzioni di ingresso gestito. È possibile scegliere tra un controller di ingresso gestito basato su NGINX tramite il componente aggiuntivo di routing dell'applicazione, gateway applicazione per contenitori. In alternativa, è possibile scegliere Gateway di ingresso Istio come controller di ingresso. Per altre informazioni, vedere ingresso nel servizio Azure Kubernetes.

Le risorse di ingresso degli oggetti Kubernetes sono state sostituite dall'API del gateway Kubernetes più avanzata e versatile. Il controller di ingresso e l'API gateway sono entrambi oggetti Kubernetes usati per il routing di gestione del traffico e il bilanciamento del carico. Progettato per essere generico, espressivo, estendibile e orientato ai ruoli, l'API gateway è un set moderno di API per la definizione delle regole di routing L4 e L7 in Kubernetes.

Il controller di ingresso opera come router perimetrale o proxy inverso. Un server proxy inverso è un potenziale collo di bottiglia o un singolo punto di errore, pertanto è consigliabile distribuire almeno due repliche per garantire la disponibilità elevata.

Quando scegliere controller di ingresso o API gateway

Le risorse in ingresso sono adatte ai casi d'uso seguenti:

• I controller di ingresso sono facili da configurare e sono adatti per distribuzioni Kubernetes più piccole e meno complesse che assegnano priorità alla configurazione semplice.

• Se nel cluster Kubernetes sono attualmente configurati controller di ingresso e soddisfano in modo efficace i requisiti, potrebbe non essere necessario passare immediatamente all'API del gateway Kubernetes.

È consigliabile usare l'API gateway:

• Quando si gestiscono configurazioni di routing complesse, suddivisione del traffico e strategie avanzate di gestione del traffico. La flessibilità offerta dalle risorse route dell'API del gateway Kubernetes è essenziale.

• Se i requisiti di rete richiedono soluzioni personalizzate o l'integrazione di plug-in non Microsoft. L'approccio dell'API del gateway Kubernetes, basato sulle definizioni di risorse personalizzate, può offrire un'estendibilità avanzata.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Microservizi di partizionamento

Usare gli spazi dei nomi per organizzare i servizi all'interno del cluster. Ogni oggetto in un cluster Kubernetes appartiene a uno spazio dei nomi. È consigliabile usare gli spazi dei nomi per organizzare le risorse nel cluster.

Gli spazi dei nomi consentono di evitare conflitti di denominazione. Quando più team distribuiscono i microservizi nello stesso cluster, assieme a circa un centinaio di microservizi, diventa difficile da gestire se passano tutti nello stesso spazio dei nomi. Gli spazi dei nomi consentono anche di:

• Applicare vincoli di risorsa a uno spazio dei nomi in modo che il set totale di pod assegnati a tale spazio dei nomi non possa superare la quota di risorse dello spazio dei nomi.

• Applicare criteri a livello di spazio dei nomi, che includono il controllo degli accessi in base al ruolo e i criteri di sicurezza.

Quando più team sviluppano e distribuiscono microservizi, è possibile usare gli spazi dei nomi come un meccanismo pratico per controllare le aree in cui ogni team può eseguire la distribuzione. Ad esempio, al team di sviluppo A può essere concesso l'accesso solo allo spazio dei nomi A e al team di sviluppo B è possibile concedere l'accesso solo allo spazio dei nomi B tramite i criteri di controllo degli accessi in base al ruolo .

Per un'architettura di microservizi, è consigliabile organizzare i microservizi in contesti delimitati e creare spazi dei nomi per ogni contesto delimitato. Ad esempio, tutti i microservizi correlati al contesto delimitato "Order Fulfillment" possono entrare nello stesso spazio dei nomi. In alternativa, creare uno spazio dei nomi per ogni team di sviluppo.

Posizionare i servizi di utilità nel proprio spazio dei nomi separato. Ad esempio, è possibile distribuire strumenti di monitoraggio del cluster come Elasticsearch e Prometheus in uno spazio dei nomi di monitoraggio.

Probe di integrità

Kubernetes definisce tre tipi di probe di integrità che un pod può esporre:

• probe di idoneità: indica a Kubernetes se il pod è pronto ad accettare le richieste.

• probe di Liveness: indica a Kubernetes se rimuovere un pod e avviare una nuova istanza.

• probe di avvio: indica a Kubernetes se il pod è stato avviato.

Quando si pensa ai probe, è importante ricordare il funzionamento di un servizio in Kubernetes. Un servizio ha un selettore di etichette che corrisponde a un set di zero o più pod. Kubernetes bilancia il carico di traffico verso i pod che corrispondono al selettore. Solo i pod che vengono avviati correttamente e ricevono il traffico integro. Se un contenitore si arresta in modo anomalo, Kubernetes termina il pod e pianifica una sostituzione.

A volte un pod potrebbe non essere pronto per ricevere traffico, anche se è stato avviato correttamente. Ad esempio, potrebbero essere in corso attività di inizializzazione, ad esempio quando l'applicazione in esecuzione nel contenitore carica i dati in memoria o legge i file di configurazione. È possibile usare un probe di avvio per questi contenitori a avvio lento. Questo approccio consente di impedire a Kubernetes di terminarli prima di poter inizializzare completamente.

I probe di attività vengono usati per verificare se un pod è in esecuzione ma non funziona correttamente e deve essere riavviato. Ad esempio, se un contenitore gestisce le richieste HTTP ma smette improvvisamente di rispondere senza arrestarsi in modo anomalo, il probe di attività rileva questo evento e attiva un riavvio del pod. Se si configura un probe di attività, si nota quando un contenitore non risponde e chiede a Kubernetes di riavviare il pod se il contenitore ha ripetutamente esito negativo.

Quando si progettano probe per i microservizi, tenere presente quanto segue.

• Se il codice ha un tempo di avvio lungo, esiste un pericolo che un probe di attività segnala un errore prima del completamento dell'avvio. Per ritardare l'inizio di un probe di attività, usare il probe di avvio o usare l'impostazione initialDelaySeconds con il probe di attività.

• Un probe di attività consente solo se è probabile che il riavvio del pod venga ripristinato in uno stato integro. È possibile usare un probe di attività per ridurre le perdite di memoria o i deadlock imprevisti, ma non c'è motivo per riavviare un pod che si verificherà immediatamente un errore.

• In alcuni casi i probe di idoneità vengono usati per controllare i servizi dipendenti. Ad esempio, se un pod ha una dipendenza da un database, il probe potrebbe controllare la connessione al database. Tuttavia, questo è un approccio che può creare problemi imprevisti. Un servizio esterno potrebbe non essere temporaneamente disponibile. Questa indisponibilità causa l'esito negativo del probe di idoneità per tutti i pod nel servizio, che comporta la rimozione dal bilanciamento del carico. Questa rimozione crea errori a catena upstream.

  Un approccio migliore consiste nell'implementare la gestione dei tentativi all'interno del servizio in modo che il servizio possa eseguire correttamente il ripristino da errori temporanei. In alternativa, la gestione dei tentativi, la tolleranza di errore e gli interruttori di circuito possono essere implementati dalla mesh del servizio Istio per creare un'architettura resiliente in grado di gestire gli errori del microservizio.

Vincoli delle risorse

I vincoli delle risorse possono influire sulla disponibilità di un servizio. Definire vincoli di risorse per i contenitori in modo che un singolo contenitore non possa sovraccaricare le risorse del cluster, ad esempio memoria e CPU. Per le risorse non contenitore, ad esempio thread o connessioni di rete, è consigliabile usare il modello bulkhead per isolare le risorse.

Usare quote di risorse per limitare le risorse totali consentite per uno spazio dei nomi. Questa limitazione garantisce che il front-end non possa morire di fame i servizi back-end per le risorse o viceversa. Le quote di risorse consentono di allocare risorse all'interno dello stesso cluster a più team di sviluppo di microservizi.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.

Crittografia TLS e SSL

In molte implementazioni, il controller di ingresso viene usato per la terminazione SSL. Nell'ambito della distribuzione del controller di ingresso, è necessario creare o importare un certificato TLS (Transport Layer Security). Usare certificati autofirmato solo a scopo di sviluppo e test. Per altre informazioni, vedere Configurare un nome di dominio personalizzato e un certificato SSL con il componente aggiuntivo di routing dell'applicazione.

Per i carichi di lavoro di produzione, ottenere i certificati firmati dalle autorità di certificazione attendibili.

Potrebbe anche essere necessario ruotare i certificati in base ai criteri dell'organizzazione. È possibile usare Key Vault per ruotare i certificati usati dai microservizi. Per altre informazioni, vedere Configurare la rotazione automatica dei certificati in Key Vault.

Controllo degli accessi in base al ruolo

Quando più team sviluppano e distribuiscono contemporaneamente microservizi, i meccanismi di controllo degli accessi in base al ruolo del servizio Azure Kubernetes possono fornire un controllo granulare e un filtro delle azioni utente. È possibile usare il controllo degli accessi in base al ruolo di Kubernetes o il controllo degli accessi in base al ruolo di Azure con Microsoft Entra ID per controllare l'accesso alle risorse del cluster. Per altre informazioni, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes.

Autenticazione e autorizzazione

I microservizi possono richiedere agli utenti o ai servizi di utilizzo di autenticare e autorizzare l'accesso al microservizio usando certificati, credenziali e meccanismi di controllo degli accessi in base al ruolo. Microsoft Entra ID può essere usato per implementare token OAuth 2.0 per l'autorizzazione. Le mesh di servizi come Istio forniscono anche meccanismi di autorizzazione e autenticazione per i microservizi, tra cui la convalida dei token OAuth e il routing basato su token. L'implementazione di riferimento non riguarda gli scenari di autenticazione e autorizzazione di microservizi.

Gestione dei segreti e credenziali dell'applicazione

Le applicazioni e i servizi spesso necessitano di credenziali che consentono loro di connettersi ai servizi esterni, ad esempio archiviazione di Azure o Database SQL. La sfida consiste nel proteggere queste credenziali e far sì che non vengano perse.

Per le risorse di Azure, usare le identità gestite quando possibile. Un'identità gestita è simile a un ID univoco per un'applicazione o un servizio archiviato nell'ID Microsoft Entra. Usa questa identità per eseguire l'autenticazione con un servizio di Azure. L'applicazione o il servizio dispone di un'entità servizio creata per tale entità servizio in Microsoft Entra ID ed esegue l'autenticazione tramite token OAuth 2.0. Il codice in esecuzione all'interno del processo può ottenere in modo trasparente il token. Questo approccio consente di garantire che non sia necessario archiviare password o stringhe di connessione. Per usare le identità gestite, è possibile assegnare le identità di Microsoft Entra ai singoli pod nel servizio Azure Kubernetes usando ID carico di lavoro Di Microsoft Entra.

Anche quando si usano identità gestite, potrebbe essere comunque necessario archiviare alcune credenziali o altri segreti dell'applicazione. Questa risorsa di archiviazione è necessaria per i servizi di Azure che non supportano identità gestite, servizi non Microsoft o chiavi API. È possibile usare le opzioni seguenti per archiviare i segreti in modo più sicuro:

• Key Vault: nel servizio Azure Kubernetes, è possibile montare uno o più segreti da Key Vault come volume. Il volume legge i segreti da Key Vault. Il pod può quindi leggere i segreti come un volume normale. Per altre informazioni, vedere Usare il provider di Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes. Il pod esegue l'autenticazione usando un'identità del carico di lavoro o un'identità gestita assegnata dal sistema o un utente. Per altre informazioni, vedere Connettere il provider di identità di Azure al driver CSI dell'archivio segreti di Key Vault nel servizio Azure Kubernetes.

• HashiCorp Vault: identità gestite di Microsoft Entra consentono alle applicazioni Kubernetes di eseguire l'autenticazione con HashiCorp Vault. È possibile distribuire l'insieme di credenziali in Kubernetes. Prendere in considerazione l'esecuzione in un cluster dedicato separato dal cluster dell'applicazione.

• segreti Kubernetes: Un'altra opzione consiste nell'usare i segreti Kubernetes. Questa opzione è la più semplice da configurare ma meno sicura. I segreti vengono archiviati in etcd, ovvero un archivio chiave-valore. Il servizio Azure Kubernetes crittografa etcd inattivi. Le chiavi di crittografia sono gestite da Microsoft.

L'uso di una soluzione come Key Vault offre diversi vantaggi, tra cui:

• Controllo centralizzato dei segreti.
• Contribuire a garantire che tutti i segreti siano crittografati inattivi.
• Gestione centralizzata delle chiavi.
• Controllo dell'accesso dei segreti.
• Gestione del ciclo di vita chiave.
• Controllo.

L'implementazione di riferimento archivia le stringhe di connessione di Azure Cosmos DB e altri segreti in Key Vault. L'implementazione di riferimento usa un'identità gestita per i microservizi per l'autenticazione in Key Vault e l'accesso ai segreti.

Sicurezza di contenitori e agenti di orchestrazione

Le procedure consigliate seguenti consentono di proteggere i pod e i contenitori.

• Monitorare le minacce. Monitorare le minacce usando Microsoft Defender per contenitori o una funzionalità non Microsoft. Se si ospitano contenitori in una macchina virtuale, usare Microsoft Defender per server o una funzionalità non Microsoft. È anche possibile integrare i log dalla soluzione di monitoraggio Contenitore in Monitoraggio di Azure a microsoft Sentinel o a una soluzione SIEM (Security Information and Event Management) esistente.

• Monitorare le vulnerabilità. Monitorare continuamente le immagini e i contenitori in esecuzione per individuare vulnerabilità note usando Microsoft Defender for Cloud o una soluzione non Microsoft.

• Automatizzare l'applicazione di patch alle immagini. Usare attività di Registro Azure Container, una funzionalità di Registro Container, per automatizzare l'applicazione di patch alle immagini. Un'immagine del contenitore viene costruita a partire da livelli. I livelli di base includono l'immagine del sistema operativo e le immagini di framework dell'applicazione, ad esempio ASP.NET Core o Node. js. Le immagini di base vengono in genere create upstream dagli sviluppatori di applicazioni e altri gestori di progetti li mantengono. Quando queste immagini vengono patch a monte, è importante aggiornare, testare e ridistribuire le proprie immagini in modo che non si lascino vulnerabilità di sicurezza note. Le attività di Registro Azure Container consentono di automatizzare questo processo.

• Archiviare le immagini in un registro privato attendibile. Usare un registro privato attendibile, ad esempio Registro Contenitori o Registro attendibile Docker per archiviare le immagini. Usare un webhook di ammissione di convalida in Kubernetes per garantire che i pod possano recuperare solo immagini dal registro attendibile.

• Applicare il principio dei privilegi minimi. Non eseguire i contenitori in modalità privilegiata. La modalità privilegiata fornisce a un contenitore l'accesso a tutti i dispositivi nell'host. Quando possibile, evitare di eseguire i processi come radice all'interno di contenitori. I contenitori non forniscono l'isolamento completo dal punto di vista della sicurezza, quindi è preferibile eseguire un processo di contenitore come utente senza privilegi.

Considerazioni sull'integrazione continua/distribuzione continua

Considerare gli obiettivi seguenti di un processo CI/CD affidabile per un'architettura di microservizi:

• Ogni team può creare e distribuire i servizi di sua proprietà in modo indipendente, senza influenzare o interrompere gli altri team.

• Prima di distribuire una nuova versione di un servizio nell'ambiente di produzione, viene distribuita in ambienti di sviluppo, test e Q&A per la convalida. I controlli di qualità vengono applicati in ogni fase.

• Una nuova versione di un servizio può essere distribuita side-by-side con la versione precedente.

• Vengono applicati sufficienti criteri di controllo di accesso.

• Per i carichi di lavoro in contenitori, è possibile considerare attendibili le immagini del contenitore distribuite nell'ambiente di produzione.

Per altre informazioni sulle problematiche, vedere CI/CD per le architetture di microservizi.

L'uso di una mesh di servizi come Istio può essere utile per i processi CI/CD, ad esempio distribuzioni canary, test A/B di microservizi e implementazioni a fasi con suddivisioni del traffico in base alla percentuale.

Per altre informazioni su raccomandazioni e procedure consigliate specifiche, vedere Creare una pipeline CI/CD per microservizi in Kubernetes con Azure DevOps e Helm.

Ottimizzazione costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Usare il calcolatore dei prezzi di Azure per stimare i costi. Altre considerazioni sono descritte nella sezione Cost in Microsoft Azure Well-Architected Framework.

Considerare i punti seguenti per alcuni dei servizi usati in questa architettura.

AKS (Servizio Azure Kubernetes)

• Nel livello gratuitonon sono associati costi per il servizio Azure Kubernetes nella distribuzione, nella gestione e nelle operazioni del cluster Kubernetes. Si paga solo per le istanze della macchina virtuale, l'archiviazione e le risorse di rete usate dal cluster Kubernetes.

• È consigliabile usare 'utilità di scalabilità automatica orizzontale dei pod per ridimensionare automaticamente i microservizi in o aumentarne il numero in base al carico.

• Configurare di scalabilità automatica del cluster per ridimensionare o aumentare le istanze dei nodi in base al carico.

• È consigliabile usare nodi spot per ospitare microservizi non critici.

• Esaminare le procedure consigliate per l'ottimizzazione dei costi per il servizio Azure Kubernetes.

• Per stimare il costo delle risorse necessarie, usare il calcolatore del servizio Azure Kubernetes .

Bilanciatore di carico Azure

Vengono addebitati solo il numero di regole di bilanciamento del carico e in uscita configurate. Le regole di conversione degli indirizzi di rete in ingresso sono gratuite. Non è previsto alcun addebito orario per il Load Balancer Standard quando non sono configurate regole. Per altre informazioni, vedere prezzi di Azure Load Balancer.

Azure Pipelines

Questa architettura di riferimento usa solo Azure Pipelines. Azure fornisce la pipeline come singolo servizio. È consentito un processo ospitato gratuitamente da Microsoft con 1.800 minuti per ogni mese per CI/CD e un processo self-hosted con minuti illimitati per ogni mese. I processi aggiuntivi comportano più costi. Per altre informazioni, vedere prezzi dei servizi Azure DevOps.

Monitoraggio di Azure

Per Log Analytics di Monitoraggio di Azure, vengono addebitati costi per l'inserimento e la conservazione dei dati. Per altre informazioni, vedere Prezzi di Monitoraggio di Azure.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Questa architettura di riferimento include file Bicep per il provisioning delle risorse cloud e delle relative dipendenze. È possibile usare azure Pipelines per distribuire questi file Bicep e configurare rapidamente ambienti diversi, ad esempio la replica di scenari di produzione. Questo approccio consente di risparmiare sui costi effettuando il provisioning di ambienti di test di carico solo quando necessario.

Prendere in considerazione i criteri di isolamento del carico di lavoro per strutturare il file Bicep. Un carico di lavoro viene in genere definito come un'unità arbitraria di funzionalità. Ad esempio, è possibile avere un file Bicep separato per il cluster e quindi un altro file per i servizi dipendenti. È possibile usare Azure DevOps per eseguire CI/CD con isolamento del carico di lavoro perché ogni carico di lavoro è associato e gestito dal proprio team.

Distribuire lo scenario

Per distribuire l'implementazione di riferimento per questa architettura, seguire la procedura descritta nel repository GitHub. Per altre informazioni, vedere implementazione di riferimento microservizi del servizio Azure Kubernetes.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• Francesco Simy Nazareth | Senior Technical Specialist

Altri collaboratori:

• Paolo Salvatori | Ingegnere Principale per i Clienti
• Alessandro Vossa | Senior Technical Specialist

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

Passaggi successivi

• Usare un'entità servizio con il servizio Azure Kubernetes
• Protezione dei contenitori in Defender for Cloud
• Pianificare la distribuzione di Defender per server
• soluzione di monitoraggio dei contenitori in Monitoraggio di Azure
• microsoft Sentinel o una soluzione SIEM esistente
• Defender for Cloud o una soluzione non Microsoft disponibile tramite Azure Marketplace
• Automatizzare le compilazioni e la manutenzione delle immagini del contenitore con le attività di Registro Azure Container

Risorse correlate

• Per un esempio di microservizi più avanzati, vedere 'architettura dei microservizi del servizio Azure Kubernetes avanzata.
• CI/CD per le architetture di microservizi
• CI/CD per microservizi in Kubernetes