Distribuzione blu-verde dei cluster del servizio Azure Kubernetes

Servizio Azure Kubernetes

Gateway applicazione di Azure

Registro Azure Container

Frontdoor di Azure

DNS di Azure

Questo articolo fornisce indicazioni sull'implementazione di una strategia di distribuzione blu-verde per testare una nuova versione di un cluster servizio Azure Kubernetes (servizio Azure Kubernetes) continuando a eseguire la versione corrente. Una volta convalidata la nuova versione, una modifica di routing passa il traffico dell'utente. La distribuzione in questo modo aumenta la disponibilità quando si apportano modifiche, inclusi gli aggiornamenti, ai cluster del servizio Azure Kubernetes. Questo articolo descrive la progettazione e l'implementazione di una distribuzione blu-verde del servizio Azure Kubernetes che usa i servizi gestiti di Azure e le funzionalità native di Kubernetes.

Architettura

Questa sezione descrive le architetture per la distribuzione blu-verde dei cluster del servizio Azure Kubernetes. I casi possibili sono due:

Le applicazioni e le API sono rivolte al pubblico.
Le applicazioni e le API sono private.

C'è anche un caso ibrido, non discusso qui, in cui è presente una combinazione di applicazioni e API pubbliche e private nel cluster.

Il diagramma seguente illustra l'architettura per il caso pubblico:

Scaricare un file di Visio di questa architettura.

Frontdoor di Azure e DNS di Azure forniscono il meccanismo di routing che commuta il traffico tra i cluster blu e verde. Per altre informazioni, vedere Distribuzione blu-verde con Frontdoor di Azure. Usando Frontdoor di Azure, è possibile implementare un commutatore completo o un commutatore più controllato basato sui pesi. Questa tecnica è la più affidabile ed efficiente in un ambiente Azure. Se si vuole usare il proprio DNS e il servizio di bilanciamento del carico, è necessario assicurarsi che siano configurati per fornire un commutatore sicuro e affidabile.

app Azure lication Gateway fornisce i front-end dedicati agli endpoint pubblici.

Questo diagramma è relativo al caso privato:

Scaricare un file di Visio di questa architettura.

In questo caso, una singola istanza DNS di Azure implementa il passaggio del traffico tra i cluster blu e verde. Questa operazione viene eseguita usando A i record e CNAME . Per informazioni dettagliate, vedere la sezione T3: Passare il traffico al cluster verde.

gateway applicazione fornisce i front-end, dedicati agli endpoint privati.

Workflow

In una distribuzione blu-verde sono disponibili cinque fasi per aggiornare la versione corrente del cluster alla nuova versione. Nella descrizione il cluster blu è la versione corrente e il cluster verde è quello nuovo.

Le fasi sono:

T0: il cluster blu è attivo.
T1: Distribuire il cluster verde.
T2: sincronizzare lo stato di Kubernetes tra i cluster blu e verde.
T3: passare al cluster verde.
T4: Distruggere il cluster blu.

Quando la nuova versione è attiva, diventa il cluster blu per qualsiasi modifica o aggiornamento successivo.

I cluster blu e verde vengono eseguiti contemporaneamente, ma solo per un periodo di tempo limitato, che ottimizza i costi e le attività operative.

Trigger di transizione

I trigger per la transizione dalla fase alla fase possono essere automatizzati. Fino a quando non viene raggiunto, alcuni o tutti sono manuali. I trigger sono correlati a:

Metriche specifiche del carico di lavoro, obiettivi del livello di servizio e contratti di servizio: vengono usati principalmente nella fase T3 per convalidare lo stato complessivo del cluster del servizio Azure Kubernetes prima di passare al traffico.
Metriche della piattaforma Azure: vengono usate per valutare lo stato e l'integrità dei carichi di lavoro e del cluster del servizio Azure Kubernetes. Vengono usati in tutte le transizioni.

Individuabilità di rete dei cluster

È possibile fornire l'individuabilità di rete per i cluster nei modi seguenti:

Disporre di record DNS che puntano ai cluster. Ad esempio:
- aks-blue.contoso.com punta all'indirizzo IP privato o pubblico del cluster blu.
- aks-green.contoso.com punta all'indirizzo IP privato o pubblico del cluster verde.
È quindi possibile usare questi nomi host direttamente o nella configurazione del pool back-end del gateway applicazione che si trova davanti a ogni cluster.
Disporre di record DNS che puntano ai gateway applicazione. Ad esempio:
- aks-blue.contoso.com punta all'indirizzo IP privato o pubblico del gateway applicazione, che ha come pool back-end l'indirizzo IP privato o pubblico del cluster blu.
- aks-green.contoso.com punta all'indirizzo IP privato o pubblico del gateway applicazione, che ha come pool back-end l'indirizzo IP privato o pubblico del cluster verde.

T0: Il cluster blu è attivo

La fase iniziale, T0, è che il cluster blu è attivo. Questa fase prepara la nuova versione del cluster per la distribuzione.

La condizione di trigger per la fase T1 è la versione di una nuova versione del cluster, il cluster verde.

T1: Distribuire il cluster verde

Questa fase inizia la distribuzione del nuovo cluster verde. Il cluster blu rimane attivo e il traffico in tempo reale viene ancora instradato.

Il trigger da spostare nella fase T2 è la convalida del cluster del servizio Azure Kubernetes verde a livello di piattaforma. La convalida usa le metriche di Monitoraggio di Azure e i comandi dell'interfaccia della riga di comando per controllare l'integrità della distribuzione. Per altre informazioni, vedere Monitoraggio servizio Azure Kubernetes (AKS) con informazioni di riferimento sui dati del servizio Azure Kubernetes di monitoraggio e monitoraggio.

Il monitoraggio del servizio Azure Kubernetes può essere suddiviso in livelli diversi, come illustrato nel diagramma seguente:

L'integrità del cluster viene valutata ai livelli 1 e 2 e a un certo livello 3. Per il livello 1, è possibile usare la visualizzazione multi-cluster nativa da Monitoraggio per convalidare l'integrità, come illustrato di seguito:

Al livello 2 assicurarsi che il server API Kubernetes e Kubelet funzionino correttamente. È possibile usare la cartella di lavoro di Kubelet in Monitoraggio, in particolare, le due griglie della cartella di lavoro che mostrano le statistiche operative chiave dei nodi:

La panoramica in base alla griglia dei nodi riepiloga l'operazione totale, gli errori totali e le operazioni riuscite per percentuale e tendenza per ogni nodo.
La panoramica in base alla griglia del tipo di operazione fornisce, per ogni tipo di operazione, il numero di operazioni, errori e operazioni riuscite per percentuale e tendenza.

Il livello 3 è dedicato agli oggetti e alle applicazioni Kubernetes distribuiti per impostazione predefinita nel servizio Azure Kubernetes, ad esempio omsagent, kube-proxy e così via. Per questo controllo, è possibile usare la visualizzazione Informazioni dettagliate di Monitoraggio per controllare lo stato delle distribuzioni del servizio Azure Kubernetes:

In alternativa, è possibile usare la cartella di lavoro dedicata documentata in Metriche di distribuzione e HPA con Informazioni dettagliate sui contenitori. Ecco un esempio:

Al termine della convalida, è possibile passare alla fase T2.

T2: Sincronizzare lo stato di Kubernetes tra i cluster blu e verde

In questa fase, le applicazioni, gli operatori e le risorse Kubernetes non sono ancora distribuite nel cluster verde o almeno non tutte sono applicabili e distribuite quando viene effettuato il provisioning del cluster del servizio Azure Kubernetes. L'obiettivo finale di questa fase è che, alla fine della sincronizzazione, il cluster verde è compatibile con quello blu. In tal caso, è possibile convalidare lo stato del nuovo cluster prima di passare al cluster verde.

Esistono diversi modi per sincronizzare lo stato di Kubernetes tra cluster:

Ridistribuzione tramite integrazione continua e recapito continuo (CI/CD). In genere è sufficiente usare le stesse pipeline CI/CD usate per la normale distribuzione delle app. Gli strumenti comuni per eseguire questa operazione sono: GitHub Actions, Azure DevOps e Jenkins.
GitOps, con soluzioni promosse nel sito Web CLOUD Native Computing Foundation (CNF), ad esempio Flux e ArgoCD.
Soluzione personalizzata che archivia le configurazioni e le risorse kubernetes in un archivio dati. In genere, queste soluzioni si basano su generatori di manifesti Kubernetes che iniziano dalle definizioni dei metadati e quindi archiviano i manifesti Kubernetes generati in un archivio dati come Azure Cosmos DB. Si tratta in genere di soluzioni personalizzate basate sul framework di descrizione dell'applicazione in uso.

Il diagramma seguente illustra il processo di sincronizzazione dello stato di Kubernetes:

In genere, durante la sincronizzazione, la distribuzione di nuove versioni delle applicazioni non è consentita nel cluster live. Questo periodo di tempo inizia con la sincronizzazione e termina al completamento del passaggio al cluster verde. Il modo per disabilitare le distribuzioni in Kubernetes può variare. Due possibili soluzioni sono:

Disabilitare le pipeline di distribuzione.
Disabilitare l'account del servizio Kubernetes che esegue le distribuzioni.

È possibile automatizzare la disabilitazione dell'account del servizio usando Open Policy Agent (OPA). Non è ancora possibile usare le funzionalità native del servizio Azure Kubernetes perché sono ancora in anteprima.

Il periodo di sincronizzazione può essere evitato usando meccanismi avanzati che gestiscono lo stato di Kubernetes in più cluster.

Al termine della sincronizzazione, è necessaria la convalida del cluster e delle applicazioni. Valuta gli ambiti seguenti:

Controllo delle piattaforme di monitoraggio e registrazione per convalidare l'integrità del cluster. È possibile prendere in considerazione le operazioni eseguite nella fase T1: Distribuire il cluster verde.
Test funzionali dell'applicazione in base alla toolchain attualmente in uso.

È consigliabile eseguire anche una sessione di test di carico per confrontare le prestazioni delle applicazioni cluster verdi con una baseline di prestazioni. È possibile usare lo strumento preferito o Il test di carico di Azure.

In genere, il cluster verde viene esposto nel gateway applicazione o nel servizio di bilanciamento del carico esterno con un URL interno che non è visibile agli utenti esterni.

Quando il nuovo cluster viene convalidato, è possibile passare alla fase successiva per passare al nuovo cluster.

T3: Passare il traffico al cluster verde

Dopo aver completato la sincronizzazione e aver convalidato il cluster verde a livello di piattaforma e applicazione, è pronto per essere alzato di livello come cluster primario e iniziare a ricevere il traffico live. Il commutatore viene eseguito a livello di rete. Spesso i carichi di lavoro sono senza stato. Tuttavia, se i carichi di lavoro sono con stato, è necessario implementare una soluzione aggiuntiva per mantenere lo stato e la memorizzazione nella cache durante l'opzione.

Ecco un diagramma che mostra lo stato di destinazione dopo l'applicazione dell'opzione:

Le tecniche descritte in questo articolo implementano opzioni complete: il 100% del traffico viene instradato al nuovo cluster. Questo perché il routing viene applicato a livello DNS con un'assegnazione A di record o CNAME aggiornata in modo che punti al cluster verde e che sia presente un gateway applicazione per ogni cluster.

Ecco un esempio di configurazione per il cambio di endpoint privati. La soluzione proposta usa i A record per effettuare l'opzione. Dal punto di vista del mapping DNS e IP, la situazione è la seguente prima dell'opzione:

A il record aks.priv.contoso.com punta all'INDIRIZZO IP privato del gateway applicazione blu.
A il record aks-blue.priv.contoso.com punta all'INDIRIZZO IP privato del gateway applicazione blu.
A il record aks-green.priv.contoso.com punta all'INDIRIZZO IP privato del gateway applicazione verde.

L'opzione riconfigura le opzioni seguenti:

A il record aks.priv.contoso.com punta all'INDIRIZZO IP privato del gateway applicazione verde.
A il record aks-blue.priv.contoso.com punta all'INDIRIZZO IP privato del gateway applicazione blu.
A il record aks-green.priv.contoso.com punta all'INDIRIZZO IP privato del gateway applicazione verde.

Gli utenti dei cluster vedranno l'opzione dopo la durata (TTL) e la propagazione DNS dei record.

Per gli endpoint pubblici, l'approccio consigliato usa Frontdoor di Azure e DNS di Azure. Ecco la configurazione prima dell'opzione:

CNAME il record official-aks.contoso.com punta a un record del dominio Frontdoor di Azure generato automaticamente. Per altre informazioni, vedere Esercitazione: Aggiungere un dominio personalizzato alla frontdoor.
A il record aks.contoso.com punta all'indirizzo IP pubblico del gateway applicazione blu.
La configurazione dell'origine frontdoor di Azure punta al aks.contoso.com nome host. Per altre informazioni sulla configurazione dei pool back-end, vedere Origini e gruppi di origine in Frontdoor di Azure.
- A il record aks-blue.contoso.com punta all'indirizzo IP pubblico del gateway applicazione blu.
- A il record aks-green.contoso.com punta all'indirizzo IP pubblico del gateway applicazione verde.

L'opzione riconfigura le opzioni seguenti:

CNAME il record official-aks.contoso.com punta a un record del dominio Frontdoor di Azure generato automaticamente.
A record aks.contoso.com punta all'indirizzo IP pubblico del gateway applicazione verde.
La configurazione dell'origine frontdoor di Azure punta al aks.contoso.com nome host.
- A record aks-blue.contoso.com punta all'indirizzo IP pubblico del gateway applicazione blu.
- A record aks-green.contoso.com punta all'indirizzo IP pubblico del gateway applicazione verde.

Le tecniche alternative di cambio, ad esempio i commutatori parziali per le versioni canary, sono possibili con servizi di Azure aggiuntivi come Frontdoor di Azure o Gestione traffico. Per un'implementazione di un commutatore di traffico blu-verde a livello di Frontdoor di Azure, vedere Distribuzione blu-verde con Frontdoor di Azure.

Come descritto nell'esempio, dal punto di vista della rete questa tecnica si basa sulla definizione di quattro nomi host:

Nome host pubblico ufficiale: nome host pubblico ufficiale usato da utenti finali e consumer.
Nome host del cluster: nome host ufficiale usato dai consumer dei carichi di lavoro ospitati nei cluster.
Nome host cluster blu: nome host dedicato per il cluster blu.
Nome host cluster verde: nome host dedicato per il cluster verde.

Il nome host del cluster è quello configurato a livello di gateway applicazione per gestire il traffico in ingresso. Il nome host fa anche parte della configurazione in ingresso del servizio Azure Kubernetes per gestire correttamente Transport Layer Security (TLS). Questo host viene usato solo per le transazioni e le richieste in tempo reale.

Se anche Frontdoor di Azure fa parte della distribuzione, non è interessato dal commutatore, perché gestisce solo il nome host del cluster ufficiale. Fornisce l'astrazione corretta per gli utenti dell'applicazione. Non sono interessati dal commutatore, perché il record DNS CNAME punta sempre a Frontdoor di Azure.

I nomi host del cluster blu e verde vengono usati principalmente per testare e convalidare i cluster. A questo scopo, i nomi host vengono esposti a livello di gateway applicazione con endpoint dedicati e anche a livello di controller in ingresso del servizio Azure Kubernetes per gestire correttamente TLS.

In questa fase, la convalida si basa sulle metriche di monitoraggio dell'infrastruttura e delle app e sul contratto di servizio ufficiale, se disponibile. Se la convalida ha esito positivo, passare alla fase finale per eliminare definitivamente il cluster blu.

T4: Distruggere il cluster blu

Se si passa correttamente al traffico, si passa alla fase finale, in cui è ancora in corso la convalida e il monitoraggio per assicurarsi che il cluster verde funzioni come previsto con il traffico in tempo reale. La convalida e il monitoraggio coprono sia la piattaforma che il livello dell'applicazione.

Al termine della convalida, il cluster blu può essere eliminato definitivamente. La distruzione è un passaggio fortemente consigliato per ridurre i costi e usare correttamente l'elasticità fornita da Azure, in particolare il servizio Azure Kubernetes.

Ecco la situazione dopo che il cluster blu è stato eliminato:

Componenti

gateway applicazione è un servizio di bilanciamento del carico del traffico Web (OSI livello 7) che consente di gestire il traffico verso le applicazioni Web. In questa soluzione viene usato come gateway per il traffico HTTP per accedere ai cluster del servizio Azure Kubernetes.
servizio Azure Kubernetes è un servizio Kubernetes gestito che è possibile usare per distribuire e gestire applicazioni in contenitori. Questa piattaforma dell'applicazione è il componente principale di questo modello.
Registro Azure Container è un servizio gestito usato per archiviare e gestire immagini del contenitore e artefatti correlati. In questa soluzione viene usato per archiviare e distribuire immagini e artefatti del contenitore, ad esempio grafici Helm, nei cluster del servizio Azure Kubernetes.
Monitoraggio di Azure è una soluzione di monitoraggio per la raccolta, l'analisi e la risposta ai dati di monitoraggio dagli ambienti cloud e locali. Fornisce le funzionalità di monitoraggio di base necessarie per eseguire la distribuzione blu verde. Viene usato in questa architettura grazie all'integrazione con il servizio Azure Kubernetes e alla possibilità di fornire funzionalità di registrazione, monitoraggio e avviso che possono essere usate per gestire le transizioni di fase.
Azure Key Vault consente di risolvere i problemi seguenti: Gestione dei segreti, Gestione delle chiavi e Gestione certificati. Viene usato per archiviare e gestire i segreti e i certificati necessari a livello di platfomr e applicazione per questa soluzione.
Frontdoor di Azure è un servizio di bilanciamento del carico globale e un sistema di gestione degli endpoint dell'applicazione. Viene usato in questa soluzione come endpoint pubblico per le applicazioni HTTP ospitate nel servizio Azure Kubernetes. In questa soluzione ha la responsabilità critica di gestire il passaggio del traffico tra i gateway applicazione blu e verde.
DNS di Azure è un servizio di hosting per i domini DNS che offre la risoluzione dei nomi usando l'infrastruttura di Microsoft Azure. Gestisce i nomi host usati nella soluzione per i cluster blu e verde e svolge un ruolo importante nei commutatori di traffico, in particolare per gli endpoint privati.

Alternative

Esistono tecniche alternative per implementare i commutatori di traffico che possono fornire un maggiore controllo. Ad esempio, è possibile eseguire un cambio parziale usando regole di traffico basate su una o più delle opzioni seguenti:
- Percentuale di traffico in ingresso
- Intestazioni HTTP
- Cookie
Un'altra alternativa che offre maggiore protezione dai problemi causati dalle modifiche consiste nell'avere distribuzioni basate su circuito. Anziché solo cluster blu e verde, è possibile avere più cluster, chiamati anelli. Ogni anello è sufficientemente grande per il numero di utenti che hanno accesso alla nuova versione del servizio Azure Kubernetes. Per quanto riguarda la distribuzione blu-verde descritta qui, gli anelli possono essere rimossi per avere l'ottimizzazione e il controllo dei costi appropriati.
Le possibili alternative a gateway applicazione sono NGINX e HAProxy.
Un'alternativa possibile a Registro Container è Harbor.
In alcune circostanze è possibile usare diversi servizi di bilanciamento del carico e DNS per eseguire i commutatori di traffico, anziché Frontdoor di Azure e DNS di Azure.
Questa soluzione si basa sulle API Kubernetes standard del controller in ingresso. Se la soluzione trarrebbe vantaggio dall'API gateway, usare gateway applicazione per i contenitori. Consente di gestire il bilanciamento del carico e gestire la gestione del traffico in ingresso tra gateway applicazione e i pod. gateway applicazione per Contenitori controlla le impostazioni dei gateway applicazione.

Dettagli dello scenario

I principali vantaggi della soluzione sono:

Tempo di inattività ridotto durante la distribuzione.
Strategia di rollback pianificata.
Controllo e operazioni migliorate durante il rilascio e la distribuzione delle modifiche e degli aggiornamenti del servizio Azure Kubernetes.
Test della necessità di eseguire procedure di ripristino di emergenza.

I principi chiave e gli aspetti fondamentali della distribuzione blu-verde sono descritti in questi articoli:

Dal punto di vista dell'automazione e del CI/CD, la soluzione può essere implementata in diversi modi. Suggerimenti:

Bicep o Terraform per IaC.
Azure Pipelines o GitHub Actions per CI/CD.

Potenziali casi d'uso

La distribuzione blu-verde consente di apportare modifiche ai cluster senza influire sulle applicazioni e sui carichi di lavoro in esecuzione. Di seguito sono riportati alcuni esempi di modifiche:

Modifiche operative
Attivazione di nuove funzionalità del servizio Azure Kubernetes
Modifiche alle risorse condivise nei cluster
Aggiornamento della versione di Kubernetes
Modifica di risorse e oggetti Kubernetes, ad esempio il gateway in ingresso, la mesh del servizio, gli operatori, i criteri di rete e così via
Eseguire il rollback alla versione precedente di un cluster del servizio Azure Kubernetes ancora distribuito, senza influire sui carichi di lavoro in esecuzione nel cluster

Considerazioni

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

La distribuzione blu-verde può essere completamente automatizzata, ad esempio una distribuzione zero-touch. In genere, un'implementazione iniziale include trigger manuali per attivare le fasi. Lungo il percorso e con le funzionalità di maturità e monitoraggio appropriate, è possibile automatizzare i trigger. Ciò significa che sono presenti test automatizzati e metriche specifiche, contratto di servizio e SLO per automatizzare i trigger.
È importante avere nomi host dedicati per i cluster blu e verde e anche per avere configurazioni endpoint dedicate nei gateway e nei servizi di bilanciamento del carico che si trovano davanti ai cluster. Questo è fondamentale per migliorare l'affidabilità e la validità della distribuzione del nuovo cluster. In questo modo, la convalida della distribuzione avviene con la stessa architettura e le stesse configurazioni di un cluster di produzione standard.
Si consideri una situazione in cui i cluster del servizio Azure Kubernetes sono risorse condivise per più applicazioni gestite da business unit diverse. In questi casi è comune che la piattaforma del servizio Azure Kubernetes sia gestita da un team dedicato responsabile del funzionamento complessivo e del ciclo di vita dei cluster e che siano presenti endpoint nei cluster a scopo di amministrazione e operazioni. È consigliabile che questi endpoint abbiano un controller di ingresso dedicato nei cluster del servizio Azure Kubernetes per una corretta separazione dei problemi e per l'affidabilità.
La distribuzione blu-verde è utile per implementare e testare soluzioni di continuità aziendale e ripristino di emergenza (BC/DR) per il servizio Azure Kubernetes e i carichi di lavoro correlati. In particolare, fornisce le strutture fondamentali per la gestione di più cluster, inclusi i casi in cui i cluster vengono distribuiti tra più aree.
Il successo con la distribuzione blu-verde si basa sull'applicazione di tutti gli aspetti dell'implementazione, ad esempio automazione, monitoraggio e convalida, non solo alla piattaforma del servizio Azure Kubernetes, ma anche ai carichi di lavoro e alle app distribuite nella piattaforma. In questo modo è possibile ottenere il massimo vantaggio dalla distribuzione blu-verde.
Nella soluzione proposta sono presenti due gateway applicazione per ogni scenario pubblico e privato, quindi in totale quattro. Questa decisione consiste nell'applicare la distribuzione verde blu a livello di gateway di app Azure lication per evitare tempi di inattività causati da errori di configurazione dei gateway. Lo svantaggio principale di questa decisione è il costo, poiché sono presenti quattro istanze gateway applicazione. Vengono eseguiti in parallelo solo nel periodo di tempo in cui sono presenti modifiche rilevanti alle configurazioni di gateway applicazione, ad esempio i criteri WAF o una configurazione di ridimensionamento. Per un'ulteriore ottimizzazione dei costi, è possibile scegliere un singolo gateway applicazione per ogni scenario, ovvero due gateway applicazione in totale. Sarà quindi necessario spostare la logica blu/verde nel gateway applicazione, invece di Frontdoor di Azure. Quindi, invece che Frontdoor di Azure sia controllato in modo imperativo, gateway applicazione è.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

La distribuzione blu-verde ha un effetto diretto e positivo sulla disponibilità della piattaforma e dei carichi di lavoro del servizio Azure Kubernetes. In particolare, aumenta la disponibilità durante la distribuzione delle modifiche della piattaforma servizio Azure Kubernetes. Se le sessioni utente sono gestite correttamente, si verifica un tempo di inattività minimo.
La distribuzione blu-verde offre copertura per l'affidabilità durante la distribuzione perché, per impostazione predefinita, è possibile eseguire il rollback alla versione precedente del cluster del servizio Azure Kubernetes se si verifica un errore nella nuova versione del cluster.

Ottimizzazione dei costi

L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

La distribuzione blu-verde è ampiamente adottata in Azure a causa dell'elasticità nativa fornita dal cloud. In questo modo è possibile ottimizzare i costi in termini di operazioni e consumo di risorse. La maggior parte dei risparmi derivanti dalla rimozione del cluster non più necessaria dopo la distribuzione corretta di una nuova versione del cluster.
Quando viene distribuita una nuova versione, è tipico ospitare i cluster blu e verde nella stessa subnet, per continuare a avere la stessa baseline di costo. Tutte le connessioni di rete e l'accesso alle risorse e ai servizi sono uguali per i due cluster e tutti i servizi e le risorse di Azure rimangono invariati.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

La distribuzione blu-verde, implementata correttamente, offre automazione, recapito continuo e distribuzione resiliente.
Uno degli aspetti chiave del recapito continuo è che offre incrementi iterativi delle modifiche della piattaforma e del carico di lavoro. Con la distribuzione blu-verde del servizio Azure Kubernetes, si ottiene il recapito continuo a livello di piattaforma, in modo controllato e sicuro.
La resilienza è fondamentale per la distribuzione blu-verde, perché include l'opzione per eseguire il rollback al cluster precedente.
La distribuzione blu-verde offre il livello di automazione appropriato per ridurre il lavoro correlato alla strategia di continuità aziendale.
Il monitoraggio della piattaforma e delle app è fondamentale per una corretta implementazione. Per la piattaforma è possibile usare le funzionalità di monitoraggio native di Azure. Per le app, il monitoraggio deve essere progettato e implementato.

Distribuire lo scenario

Per un esempio implementato di una distribuzione blu-verde descritta in questa guida, vedere Acceleratore di zona di destinazione del servizio Azure Kubernetes.

Questa implementazione di riferimento si basa su gateway applicazione e gateway applicazione Controller in ingresso (AGIC).This reference implementation is based on gateway applicazione and gateway applicazione Ingress Controller (AGIC). Ogni cluster ha un proprio gateway applicazione e il commutatore di traffico viene eseguito tramite DNS, in particolare tramite CNAME la configurazione.

Importante

Per i carichi di lavoro cruciali, è importante combinare distribuzioni blu/verde, come descritto in questa guida con l'automazione della distribuzione e la convalida continua per ottenere distribuzioni senza tempi di inattività. Altre informazioni e indicazioni sono disponibili nella metodologia di progettazione mission-critical.

Considerazioni sulle aree

È possibile distribuire i cluster blu e verde in aree separate o nella stessa area. La progettazione e i principi operativi non sono influenzati da questa scelta. Tuttavia, alcuni tipi di configurazioni di rete aggiuntive possono essere interessati, ad esempio:

Una rete virtuale dedicata e una subnet per il servizio Azure Kubernetes e il gateway applicazione.
Connessione con servizi di backup come Monitoraggio, Registro Contenitori e Key Vault.
Visibilità frontdoor di Azure del gateway applicazione.

Esistono prerequisiti per la distribuzione nella stessa area:

Le reti virtuali e le subnet devono essere ridimensionate per ospitare due cluster.
La sottoscrizione di Azure deve fornire capacità sufficiente per i due cluster.

Distribuzione del controller in ingresso e dei servizi di bilanciamento del carico esterni

Esistono diversi approcci alla distribuzione del controller di ingresso e dei servizi di bilanciamento del carico esterno:

È possibile avere un singolo controller di ingresso con un servizio di bilanciamento del carico esterno dedicato, ad esempio l'implementazione di riferimento dell'architettura descritta in questa guida. AGIC è un'applicazione Kubernetes che consente di usare il servizio di bilanciamento del carico gateway applicazione L7 per esporre il software cloud a Internet. In alcuni scenari, sono presenti endpoint di amministrazione nei cluster del servizio Azure Kubernetes oltre agli endpoint dell'applicazione. Gli endpoint di amministrazione sono destinati a eseguire attività operative nelle applicazioni o per attività di configurazione come l'aggiornamento di mappe di configurazione, segreti, criteri di rete e manifesti.
È possibile avere un singolo servizio di bilanciamento del carico esterno che gestisce più controller di ingresso distribuiti nello stesso cluster o in più cluster. Questo approccio non è trattato nell'implementazione di riferimento. In questo scenario è consigliabile disporre di gateway applicazione separati per gli endpoint pubblici e per quelli privati.
L'architettura risultante proposta e illustrata in questa guida è basata su un controller di ingresso standard distribuito come parte del cluster del servizio Azure Kubernetes, ad esempio NGINX e Envoy basato su . Nell'implementazione di riferimento si usa AGIC, il che significa che esiste una connessione diretta tra il gateway applicazione e i pod del servizio Azure Kubernetes, ma questo non influisce sull'architettura blu-verde complessiva.

Collaboratori

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

Autori principali:

Vincenzo Morra | SAO Incubazione Architetto

Altri contributori:

Oscar Pla Alvarez | Domain Solution Architect

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

Condividi tramite

Distribuzione blu-verde dei cluster del servizio Azure Kubernetes