Architettura di microservizi nel servizio Azure 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 può essere il punto di partenza per la maggior parte delle distribuzioni. Questo articolo presuppone conoscenze di base di Kubernetes. L'articolo si concentra principalmente sull'infrastruttura e sulle considerazioni relative a DevOps sull'esecuzione di un'architettura di microservizi nel servizio Azure Kubernetes. Per indicazioni su come progettare microservizi, vedere Creazione di microservizi in Azure.

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

Architettura

Scaricare un file di Visio di questa architettura.

Se si preferisce visualizzare un esempio di microservizi più avanzato basato sull'architettura di base del servizio Azure Kubernetes, vedere Architettura dei microservizi servizio Azure Kubernetes avanzati del servizio Azure Kubernetes

Flusso di lavoro

L'architettura è costituita dai componenti seguenti.

Servizio Azure Kubernetes. Il servizio Azure Kubernetes è un cluster Kubernetes gestito ospitato nel cloud di Azure. Azure gestisce il servizio API Kubernetes ed è sufficiente gestire i nodi dell'agente.

Rete virtuale. Per impostazione predefinita, il servizio Azure Kubernetes crea una rete virtuale in cui sono connessi i nodi dell'agente. È possibile creare prima la rete virtuale per scenari più avanzati, che consente di controllare elementi come la configurazione della subnet, la connettività locale e l'indirizzamento IP. Per altre informazioni, vedere Configurare funzionalità di rete avanzate nel servizio Azure Kubernetes (AKS).

Dati in ingresso. Un server in ingresso espone le route HTTP(S) ai servizi all'interno del cluster. Per altre informazioni, vedere la sezione API gateway di seguito.

Azure Load Balancer. Dopo aver creato un cluster del servizio Azure Kubernetes, il cluster è pronto per l'uso del servizio di bilanciamento del carico. Dopo la distribuzione del servizio NGINX, il servizio di bilanciamento del carico verrà quindi configurato con un nuovo indirizzo IP pubblico che verrà anteriore al controller di ingresso. In questo modo, il servizio di bilanciamento del carico instrada il traffico Internet verso l'ingresso.

Origine dati esterna. I microservizi sono in genere senza stato e scrivono in archivi dati esterni, ad esempio database SQL di Azure o Azure Cosmos DB.

MICROSOFT Entra ID. Il servizio Azure Kubernetes usa un'identità di Microsoft Entra per creare e gestire altre risorse di Azure, ad esempio i servizi di bilanciamento del carico di Azure. Microsoft Entra ID è consigliato anche per l'autenticazione utente nelle applicazioni client.

Registro Azure Container. Usare Registro Azure Container per archiviare le immagini Docker private, che vengono distribuite nel cluster. Il servizio Azure Kubernetes può eseguire l'autenticazione con registro contenitori usando l'identità Microsoft Entra. Il servizio Azure Kubernetes non richiede Registro Azure Container. È possibile usare altri registri di contenitori, ad esempio l'hub Docker. Assicurarsi che il registro contenitori corrisponda o superi il contratto di servizio per il carico di lavoro.

Azure Pipelines. Azure Pipelines fa parte di Azure DevOps Services ed esegue compilazioni, test e distribuzioni automatizzate. È inoltre possibile usare soluzioni CI/CD di terze parti come Jenkins.

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

Monitoraggio di Azure. Monitoraggio di Azure raccoglie e archivia metriche e log, dati di telemetria delle applicazioni e metriche della piattaforma per i servizi di Azure. Usare questi dati per monitorare l'applicazione, configurare avvisi, dashboard ed eseguire l'analisi delle cause radice degli errori. Monitoraggio di Azure si integra con il servizio Azure Kubernetes per raccogliere metriche da controller, nodi e contenitori.

Considerazioni

Progettazione

Questa architettura di riferimento è incentrata sulle architetture di microservizi, anche se molte delle procedure consigliate si applicano ad altri carichi di lavoro in esecuzione 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. Il servizio deve essere sempre raggiungibile anche quando i pod si spostano. L'oggetto Servizio Kubernetes è un modo naturale per modellare i microservizi in Kubernetes.

Gateway API

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

• Uso di gateway API nei microservizi
• Scelta di una tecnologia gateway

In Kubernetes la funzionalità di un gateway API viene gestita principalmente da un controller di ingresso. Le considerazioni sono descritte nella sezione Ingresso .

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, che possono verificarsi quando i servizi condividono gli stessi schemi di dati sottostanti. Inoltre, quando servizi gestiscono i propri archivi dati, possono usare l'archivio dati corretto per requisiti specifici.

Per altre informazioni, vedere Progettazione di microservizi: Considerazioni sui dati.

Evitare di archiviare dati persistenti nell'archiviazione cluster locale perché collega i dati al nodo. Usare invece un servizio esterno, ad esempio database SQL di Azure o Azure Cosmos DB. Un'altra opzione consiste nel montare un volume di dati permanente in una soluzione usando Dischi di Azure o File di Azure.

Per altre informazioni, vedere Archiviazione opzioni per l'applicazione in servizio Azure Kubernetes.

Oggetto assistenza

L'oggetto Servizio Kubernetes fornisce un set di funzionalità che soddisfano i requisiti dei microservizi per l'individuabilità del servizio:

• Indirizzo IP. L'oggetto service fornisce un indirizzo IP interno statico per un gruppo di pod (ReplicaSet). Quando i pod vengono creati o spostati, il servizio è sempre raggiungibile in questo indirizzo IP interno.

• Bilanciamento del carico. Il traffico inviato all'indirizzo IP del servizio è a carico bilanciato per il numero di pod.

• Individuazione dei servizi. Il servizio DNS di Kubernetes assegna ai servizi le voci DNS interne. Ciò significa che il gateway API può chiamare un servizio back-end usando il nome DNS. Lo stesso meccanismo può essere usato per la comunicazione da servizio a servizio. Le voci DNS sono organizzate per spazio dei nomi, pertanto se gli spazi dei nomi corrispondono a contesti delimitati, il nome DNS per un servizio eseguirà naturalmente il mapping al dominio dell'applicazione.

Il diagramma seguente illustra la relazione concettuale tra servizi e pod. Il mapping effettivo degli indirizzi IP e delle porte degli endpoint viene effettuata da kube-proxy, il proxy di rete Kubernetes.

Dati in ingresso

In Kubernetes il controller in ingresso potrebbe implementare il modello di gateway API. In tal caso, il controller Ingress e Ingress funziona in combinazione per fornire queste funzionalità:

• Instradare le richieste client ai servizi 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 IP o limitazione della frequenza client (limitazione).

Ingress astrae le impostazioni di configurazione per un server proxy. È necessario anche un controller di ingresso, che fornisce l'implementazione sottostante del traffico in ingresso. Sono disponibili controller di ingresso per Nginx, HAProxy, Traefik e app Azure lication Gateway, tra gli altri.

La risorsa in ingresso può essere soddisfatta da tecnologie diverse. Per collaborare, è necessario distribuirlo come controller di ingresso all'interno del cluster. Funziona come router perimetrale o proxy inverso. Il server proxy inverso è un potenziale collo di bottiglia o singolo punto di guasto nel sistema: distribuire sempre almeno due repliche per garantire disponibilità elevata.

Spesso, la configurazione del server proxy richiede file complessi, che possono essere difficili da ottimizzare se non si è esperti. Quindi, il controller in ingresso fornisce un'astrazione interessante. Il controller in ingresso ha anche accesso all'API Kubernetes, in modo da poter prendere decisioni intelligenti sul routing e sul bilanciamento del carico. Ad esempio, il controller di ingress Nginx consente di ignorare il proxy di rete di kube-proxy.

D'altra parte, se serve completare un controllo sulle impostazioni, è possibile ignorare questa astrazione e configurare manualmente il server proxy. Per altre informazioni, vedere Distribuzione di Nginx o HAProxy in Kubernetes.

Per informazioni sui servizi di bilanciamento del carico in Azure, vedere Panoramica delle opzioni di bilanciamento del carico in Azure.

Crittografia TLS/SSL

Nelle implementazioni comuni, il controller in ingresso viene usato per la terminazione SSL. Pertanto, come parte della distribuzione del controller in ingresso, è necessario creare un certificato TLS. Usare certificati autofirmato solo a scopo di sviluppo/test. Per altre informazioni, vedere Creare un controller di ingresso HTTPS e usare i propri certificati TLS in servizio Azure Kubernetes (servizio Azure Kubernetes).

Per i carichi di lavoro di produzione, ottenere i certificati firmati dalle autorità di certificazione (CA) attendibili. Per informazioni sulla generazione e la configurazione dei certificati Let's Encrypt, vedere Creare un controller di ingresso con un indirizzo IP pubblico statico in servizio Azure Kubernetes (servizio Azure Kubernetes).

Potrebbe anche essere necessario ruotare i certificati in base ai criteri dell'organizzazione. Per informazioni, vedere Ruotare i certificati in servizio Azure Kubernetes (servizio Azure Kubernetes).

Namespaces (Spazi dei nomi)

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. Per impostazione predefinita, quando si crea un nuovo oggetto, questi viene inserito all'interno dellodefault spazio dei nomi. Tuttavia è buona norma creare spazi dei nomi più descrittivi per aiutare a organizzare le risorse nel cluster.

In primo luogo, gli spazi dei nomi aiutano a 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. Inoltre, gli spazi dei nomi consentono di:

• Applicare vincoli delle risorse a uno spazio dei nomi, in modo che il set complessivo di pod assegnati allo spazio dei nomi non possa superare la quota delle risorse in spazio dei nomi.

• Applicare criteri a livello di spazio dei nomi, inclusi i criteri di Controllo degli accessi in base al ruolo e di sicurezza.

Per un'architettura di microservizi, prendere in considerazione l'organizzazione di microservizi in contesti delimitati e la creazione di spazi dei nomi per ciascun contesto delimitato. Ad esempio, tutti i microservizi correlati al contesto delimitato "Evasione degli ordini" potrebbero essere inseriti 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 Elasticsearch o Prometheus per il monitoraggio del cluster o Tiller per Helm.

Probe di integrità

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

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

• Probe di attività: indica a Kubernetes se un pod deve essere rimosso e una nuova istanza avviata.

Quando si pensa a un probe, è utile ricordare il funzionamento di un servizio in Kubernetes. Un servizio dispone di un selettore di etichetta che corrisponde a un set di pod (zero o più). Kubernetes bilancia il carico di traffico verso i pod che corrispondono al selettore. Ricevono il traffico solo i pod avviati correttamente e integri. Se si blocca un contenitore, Kubernetes termina il pod e pianifica una sostituzione.

Un pod in alcuni casi, potrebbe non essere pronto a ricevere il traffico, anche se è stato avviato correttamente. Ad esempio, ci possono essere attività di inizializzazione, in cui l'applicazione in esecuzione nel contenitore carica dati in memoria o legge dati di configurazione. Per indicare che un pod è integro ma non è pronto a ricevere il traffico, definire un probe di idoneità.

I probe attività gestiscono situazioni in cui un pod è ancora in esecuzione, ma non è integro e deve essere riciclato. Ad esempio, si supponga che un contenitore gestisca le richieste HTTP ma si blocchi per qualche motivo. Il contenitore non si arresta in modo anomalo, ma smette di gestire qualsiasi richiesta. Se si definisce un probe di attività HTTP, il probe smetterà di rispondere e comunicherà a Kubernetes di riavviare il pod.

Di seguito sono riportate alcune considerazioni in caso di progettazione di probe:

• Se il codice ha un tempo di avvio di lunga durata, vi è il rischio che un probe di attività possa segnalare l'errore prima che venga completato l'avvio. Per evitare questo errore del probe, usare l'impostazione che ritarda l'avvio initialDelaySeconds del probe.

• Un probe di attività non è utile, a meno che il riavvio del pod non sia in grado di ripristinarne lo stato di integrità. È possibile usare un probe di attività per ridurre perdite di memoria o deadlock imprevisti, tuttavia non ha senso riavviare un pod che darà nuovamente errore subito dopo.

• 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. Per qualche motivo, un servizio esterno potrebbe essere temporaneamente non disponibile. In tal modo il probe di idoneità avrà esito negativo per tutti i pod nel servizio, causandone la rimozione dal bilanciamento del carico e, pertanto, la creazione di errori a catena upstream. Un approccio migliore è quello di implementare la gestione dei tentativi all'interno del servizio, in modo che questi possa ripristinarsi correttamente dagli errori temporanei.

Vincoli delle risorse

I vincoli delle risorse possono influire sulla disponibilità di un servizio. Definire i vincoli delle risorse per i contenitori, in modo che un singolo contenitore non possa superare le risorse del cluster (memoria e CPU). Per le risorse non contenitore, come thread o connessioni di rete, è consigliabile usare il Modello a scomparti per isolare le risorse.

Usare le quote di risorse per limitare il numero di risorse totali consentite per uno spazio dei nomi. In questo modo, il front-end non può privare i servizi di backend per le risorse o viceversa.

Sicurezza

Controllo degli accessi in base al ruolo

Kubernetes e Azure dispongono di meccanismi per il controllo degli accessi in base al ruolo (RBAC):

• Azure RBAC controlla l'accesso alle risorse in Azure, inclusa la possibilità di creare nuove risorse di Azure. Questi ruoli possono essere assegnati a utenti, gruppi o entità servizio (un'entità servizio è un'identità di sicurezza usata dalle applicazioni).

• I controlli degli accessi in base al ruolo di Kubernetes consentoni di controllare le autorizzazioni per l'API di Kubernetes. Ad esempio, la creazione di pod e l'elenco dei pod sono azioni che possono essere autorizzate (o negate) a un utente tramite il controllo degli accessi in base al ruolo di Kubernetes. Per assegnare le autorizzazioni di Kubernetes agli utenti, creare ruoli e associazioni di ruolo:

  • Un ruolo è un set di autorizzazioni che si applica all'interno di uno spazio dei nomi. Le autorizzazioni sono definite come verbi (ottenere, aggiornare, creare ed eliminare) sulle risorse (pod, distribuzioni e così via).

  • Un RoleBinding assegna gli utenti o i gruppi a un ruolo.

  • È disponibile anche un oggetto ClusterRole, che è simile a un ruolo, ma si applica all'intero cluster, in tutti gli spazi dei nomi. Per assegnare utenti o gruppi a un ClusterRole, creare un ClusterRoleBinding.

Il servizio Azure Kubernetes integra questi due meccanismi RBAC. Quando si crea un cluster del servizio Azure Kubernetes, è possibile configurarlo per l'uso dell'ID Entra Di Microsoft per l'autenticazione utente. Per informazioni dettagliate su come configurare questa impostazione, vedere Integrare Microsoft Entra ID con servizio Azure Kubernetes.

Dopo la configurazione, un utente che vuole accedere all'API Kubernetes (ad esempio tramite kubectl) deve accedere usando le credenziali di Microsoft Entra.

Per impostazione predefinita, un utente di Microsoft Entra non ha accesso al cluster. Per concedere l'accesso, l'amministratore del cluster crea RoleBindings che fanno riferimento a utenti o gruppi di Microsoft Entra. Se un utente non dispone delle autorizzazioni per una determinata operazione, questa avrà esito negativo.

Se gli utenti non hanno accesso per impostazione predefinita, come fa l'amministratore del cluster ad avere il permesso di creare le associazioni di ruolo in primo luogo? Un cluster del servizio Azure Kubernetes ha effettivamente due tipi di credenziali per chiamare il server API Kubernetes: l'utente del cluster e l'amministratore del cluster. Le credenziali di amministratore del cluster concedono l'accesso completo al cluster. Il comando dell'interfaccia della riga di comando di Azure az aks get-credentials --admin scarica le credenziali di amministratore cluster e li salva nel file kubeconfig. L'amministratore del cluster può usare questo file kubeconfig per creare i ruoli e le associazioni di ruolo.

Anziché gestire gli oggetti Role e RoleBinding del cluster Kubernetes in modo nativo in Kubernetes, è preferibile usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione kubernetes. Ciò consente la gestione unificata e il controllo di accesso tra risorse di Azure, servizio Azure Kubernetes e risorse Kubernetes. Queste assegnazioni di ruolo controllo degli accessi in base al ruolo di Azure possono essere destinate al cluster o agli spazi dei nomi all'interno del cluster per un controllo di accesso più granulare. Il controllo degli accessi in base al ruolo di Azure supporta un set limitato di autorizzazioni predefinite ed è possibile combinarlo con il meccanismo kubernetes nativo di gestione di ruoli e roleBinding per supportare modelli di accesso avanzati o più granulari. Se abilitata, le entità Di sicurezza di Microsoft Entra verranno convalidate esclusivamente dal controllo degli accessi in base al ruolo di Azure, mentre gli utenti e gli account del servizio Kubernetes normali vengono convalidati esclusivamente dal controllo degli accessi in base al ruolo di Kubernetes.

Poiché le credenziali di amministratore del cluster sono così avanzate, usare il controllo degli accessi in base al ruolo di Azure per limitare l'accesso ad essi:

• Il "ruolo Admin del cluster servizio Azure Kubernetes" dispone dell'autorizzazione per scaricare le credenziali di amministratore cluster. Solo gli amministratori del cluster devono essere assegnati a questo ruolo.

• Il "ruolo Utente del cluster Servizio Azure Kubernetes" dispone dell'autorizzazione per scaricare le credenziali di utente cluster. Gli utenti senza privilegi di amministratore possono essere assegnati a questo ruolo. Questo ruolo non concede autorizzazioni specifiche per le risorse Kubernetes all'interno del cluster, ma consente solo a un utente di connettersi al server API.

Quando si definiscono i criteri di controllo degli accessi in base al ruolo (Kubernetes e Azure), considerare i ruoli all'interno della propria organizzazione:

• Chi può creare o eliminare un cluster del servizio Azure Kubernetes e scaricare le credenziali amministratore?
• Chi ha l'autorizzazione ad amministrare un cluster?
• Chi può creare o aggiornare le risorse all'interno di uno spazio dei nomi?

È buona norma esaminare i permessi del controllo degli accessi in base al ruolo di Kubernetes tramite spazio dei nomi, usando ruoli e RoleBindings, anziché ClusterRoles e ClusterRoleBindings.

Infine, c'è la questione delle autorizzazioni che il cluster del servizio Azure Kubernetes deve creare e gestire le risorse di Azure, ad esempio servizi di bilanciamento del carico, rete o archiviazione. Per eseguire l'autenticazione con le API di Azure, il cluster usa un'entità servizio Microsoft Entra. Se non si specifica un'entità servizio quando si crea il cluster, ne viene creato uno automaticamente. Tuttavia è buona norma creare innanzitutto l'entità servizio, a cui assegnare le autorizzazioni minime per il controllo degli accessi in base al ruolo. Per altre informazioni, vedere Entità servizio con il servizio Azure Kubernetes.

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, una possibilità è quella di usare le identità gestite. L'idea di un'identità gestita è che un'applicazione o un servizio ha un'identità archiviata nell'ID Microsoft Entra e usa questa identità per l'autenticazione con un servizio di Azure. Per l'applicazione o il servizio è stata creata un'entità servizio in Microsoft Entra ID e viene autenticata usando i token OAuth 2.0. Il codice del processo in esecuzione può ottenere in modo trasparente il token da usare. In questo modo, non è necessario archiviare le password o le stringhe di connessione. È possibile usare le identità gestite nel servizio Azure Kubernetes assegnando identità di Microsoft Entra a singoli pod, usando ID dei carichi di lavoro di Microsoft Entra (anteprima).

Attualmente, non tutti i servizi di Azure supportano l'autenticazione con identità gestite. Per un elenco, vedere Servizi di Azure che supportano l'autenticazione di Microsoft Entra.

Anche con le identità gestite, sarà probabilmente necessario memorizzare alcune credenziali o altri segreti dell'applicazione, ad esempio per servizi di Azure che non supportano l'identità gestite, servizi di terze parti, le chiavi API e così via. Ecco alcune opzioni per l'archiviazione sicura di segreti:

• Azure 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 Azure 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 dall'utente o dal sistema. Per altre considerazioni, vedere Fornire un'identità per accedere al provider di Azure Key Vault per il driver CSI dell'archivio segreti.

• Insieme di credenziali HashiCorp. Le applicazioni Kubernetes possono eseguire l'autenticazione con HashiCorp Vault usando le identità gestite di Microsoft Entra. Vedere HashiCorp Vault parla l'ID Microsoft Entra. È possibile distribuire l'insieme di credenziali stesso in Kubernetes, valutarne l'esecuzione in un cluster dedicato separato dal cluster dell'applicazione.

• Segreti di Kubernetes. Un'altra opzione consiste semplicemente nell'usare segreti Kubernetes. Questa opzione è più semplice da configurare ma presenta alcuni problemi. 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.

Usare un sistema come HashiCorp Vault o Azure Key Vault offre diversi vantaggi, ad esempio:

• Controllo centralizzato dei segreti.
• Verifica che tutti i segreti vengano crittografati quando inattivi.
• Gestione centralizzata delle chiavi.
• Controllo dell'accesso dei segreti.
• Controllo

Sicurezza di Container e Orchestrator

Queste sono le procedure consigliate per proteggere i pod e i contenitori:

• Monitoraggio delle minacce: monitorare le minacce usando Microsoft Defender per contenitori (o funzionalità di terze parti). Se si ospitano contenitori in una macchina virtuale, usare Microsoft Defender per server o una funzionalità di terze parti. È anche possibile integrare i log dalla soluzione Monitoraggio contenitori in Monitoraggio di Azure a Microsoft Sentinel o a una soluzione SIEM esistente.

• Monitoraggio delle vulnerabilità: monitorare continuamente le immagini e l'esecuzione di contenitori per individuare vulnerabilità note usando Microsoft Defender per il cloud o una soluzione di terze parti disponibile tramite Azure Marketplace.

• Automatizzare l'applicazione di patch alle immagini usando Attività del Registro Azure Container, una funzionalità di Registro Azure Container. 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 delle applicazioni e gestite da altri gestori di progetti. Quando a queste immagini vengono applicate patch upstream, è importante aggiornare, testare e ridistribuire le proprie immagini, in modo da non lasciare alcuna vulnerabilità di sicurezza nota. Le Attività del Registro Azure Container sono in grado di automatizzare questo processo.

• Archiviare immagini in un registro privato attendibile, ad esempio Registro Azure Container o docker Trusted Registry. Usare un webhook di ammissione e di convalida in Kubernetes per garantire che i pod possano eseguire il pull delle immagini solamente dal registro di sistema 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 isolamento completo dal punto di vista della sicurezza, di conseguenza è preferibile eseguire un processo del contenitore come utente senza privilegi.

DevOps

Questa architettura di riferimento fornisce un modello di Azure Resource Manager per il provisioning delle risorse cloud e le relative dipendenze. Con l'uso di [modelli di Azure Resource Manager][arm-template] è possibile usare Azure DevOps Services per effettuare il provisioning di ambienti diversi in pochi minuti, ad esempio per replicare gli scenari di produzione. In questo modo è possibile risparmiare costi ed eseguire il provisioning dell'ambiente di test di carico solo quando necessario.

Prendere in considerazione i criteri di isolamento del carico di lavoro per strutturare il modello di Resource Manager, un carico di lavoro viene in genere definito come un'unità arbitraria di funzionalità; Ad esempio, è possibile avere un modello separato per il cluster e quindi un altro per i servizi dipendenti. L'isolamento del carico di lavoro consente a DevOps di eseguire l'integrazione continua e il recapito continuo (CI/CD), poiché ogni carico di lavoro è associato e gestito dal team DevOps corrispondente.

Considerazioni sulla distribuzione (CI/CD)

Di seguito alcuni obiettivi relativi a un processo di 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 che una nuova versione di un servizio venga distribuita all'ambiente di produzione, viene distribuita agli ambienti di sviluppo/test/controllo qualità 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.

Per raccomandazioni e procedure consigliate specifiche, vedere CI/CD per i microservizi in Kubernetes.

Ottimizzazione dei costi

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

Ecco alcuni punti da considerare per alcuni dei servizi usati in questa architettura.

Servizio Azure Kubernetes (AKS)

Non sono previsti costi associati per il servizio Azure Kubernetes nella distribuzione, nella gestione e nelle operazioni del cluster Kubernetes. Si pagano solo le istanze delle macchine virtuali, l'archiviazione e le risorse di rete utilizzate dal cluster Kubernetes.

Per stimare i costi delle risorse necessarie, vedi il calcolatore dei servizi contenitore.

Azure Load Balancer

Vengono addebitati solo il numero di regole di bilanciamento del carico e in uscita configurate. Le regole NAT 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 offre Azure Pipeline come singolo servizio. È consentito un processo ospitato gratuitamente da Microsoft con 1.800 minuti al mese per CI/CD e un processo self-hosted con minuti illimitati al mese, i processi aggiuntivi hanno addebiti. Per altre informazioni, vedere Prezzi di Azure DevOps Services.

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.

Distribuire lo scenario

Per distribuire l'implementazione di riferimento per questa architettura, seguire la procedura descritta nel repository GitHub.

Passaggi successivi

• Entità servizio con servizio Azure Kubernetes
• Microsoft Defender per contenitori
• Microsoft Defender per server
• Soluzione di monitoraggio dei contenitori in Monitoraggio di Azure
• Microsoft Sentinel o una soluzione SIEM esistente.
• Microsoft Defender per il cloud o una soluzione di terze parti disponibile tramite Azure Marketplace.
• Attività del Registro Azure Container

Risorse correlate

• Per eseguire un esempio di microservizi più avanzati, vedere Architettura dei microservizi servizio Azure Kubernetes (AKS) avanzata
• Per informazioni sul monitoraggio di questa architettura, vedere Monitoraggio di un'architettura di microservizi in servizio Azure Kubernetes (servizio Azure Kubernetes).
• Per informazioni su come misurare le prestazioni di questa applicazione, vedere Scenario di ottimizzazione delle prestazioni: Transazioni aziendali distribuite.
• CI/CD per le architetture di microservizi
• CI/CD per microservizi in Kubernetes