Distribuzione e test per carichi di lavoro cruciali in Azure

La distribuzione e il test dell'ambiente mission critical sono un elemento fondamentale dell'architettura di riferimento complessiva. I singoli stamp dell'applicazione vengono distribuiti usando l'infrastruttura come codice da un repository di codice sorgente. Aggiornamenti all'infrastruttura e l'applicazione deve essere distribuita con tempi di inattività zero nell'applicazione. È consigliabile usare una pipeline di integrazione continua DevOps per recuperare il codice sorgente dal repository e distribuire i singoli timbri in Azure.

La distribuzione e gli aggiornamenti sono il processo centrale nell'architettura. Gli aggiornamenti correlati all'infrastruttura e alle applicazioni devono essere distribuiti in stamp completamente indipendenti. Solo i componenti dell'infrastruttura globale nell'architettura vengono condivisi tra i francobolli. I francobolli esistenti nell'infrastruttura non vengono toccati. Gli aggiornamenti dell'infrastruttura verranno distribuiti solo in questi nuovi francobolli. Analogamente, la nuova versione dell'applicazione verrà distribuita solo in questi nuovi francobolli.

I nuovi francobolli vengono aggiunti a Frontdoor di Azure. Il traffico viene gradualmente spostato verso i nuovi francobolli. Quando viene determinato che il traffico viene servito dai nuovi francobolli senza emissione, i francobolli precedenti vengono eliminati.

I test di penetrazione, caos e stress sono consigliati per l'ambiente distribuito. Il test proattivo dell'infrastruttura rileva i punti deboli e il comportamento dell'applicazione distribuita in caso di errore.

Distribuzione

La distribuzione dell'infrastruttura nell'architettura di riferimento dipende dai processi e dai componenti seguenti:

• DevOps : il codice sorgente di GitHub e le pipeline per l'infrastruttura.

• Aggiornamenti senza tempi di inattività: Aggiornamenti e gli aggiornamenti vengono distribuiti nell'ambiente senza tempi di inattività per l'applicazione distribuita.

• Ambienti : ambienti permanenti e di breve durata usati per l'architettura.

• Risorse condivise e dedicate: risorse di Azure dedicate e condivise ai francobolli e all'infrastruttura complessiva.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Considerazioni sulla progettazione

Distribuzione: DevOps

I componenti DevOps forniscono il repository del codice sorgente e le pipeline CI/CD per la distribuzione dell'infrastruttura e degli aggiornamenti. GitHub e Azure Pipelines sono stati scelti come componenti.

• GitHub : contiene i repository di codice sorgente per l'applicazione e l'infrastruttura.

• Azure Pipelines : le pipeline usate dall'architettura per tutte le attività di compilazione, test e rilascio.

Un componente aggiuntivo nella progettazione usata per la distribuzione è costituito dagli agenti di compilazione. Gli agenti di compilazione ospitati da Microsoft vengono usati come parte di Azure Pipelines per distribuire l'infrastruttura e gli aggiornamenti. L'uso degli agenti di compilazione ospitati da Microsoft elimina il carico di gestione per gli sviluppatori per gestire e aggiornare l'agente di compilazione.

Per altre informazioni su Azure Pipelines, vedere Che cos'è Azure DevOps Services?.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Distribuzioni di infrastruttura come codice

Distribuzione: aggiornamenti senza tempi di inattività

La strategia di aggiornamento senza tempi di inattività nell'architettura di riferimento è fondamentale per l'applicazione mission critical complessiva. La metodologia di sostituzione anziché l'aggiornamento dei francobolli garantisce una nuova installazione dell'applicazione in un timbro dell'infrastruttura. L'architettura di riferimento usa un approccio blu/verde e consente ambienti di test e sviluppo separati.

Esistono due componenti principali dell'architettura di riferimento:

• Infrastruttura : servizi e risorse di Azure. Distribuito con Terraform e la configurazione associata.

• Applicazione : servizio ospitato o applicazione che serve gli utenti. In base ai contenitori Docker e agli artefatti creati da npm in HTML e JavaScript per l'interfaccia utente dell'applicazione a pagina singola.

In molti sistemi esiste un presupposto che gli aggiornamenti delle applicazioni saranno più frequenti rispetto agli aggiornamenti dell'infrastruttura. Di conseguenza, vengono sviluppate diverse procedure di aggiornamento per ognuna di esse. Con un'infrastruttura cloud pubblica, le modifiche possono verificarsi a un ritmo più rapido. È stato scelto un processo di distribuzione per gli aggiornamenti dell'applicazione e gli aggiornamenti dell'infrastruttura. Un approccio garantisce che gli aggiornamenti dell'infrastruttura e delle applicazioni siano sempre sincronizzati. Questo approccio consente di:

• Un processo coerente: meno probabilità di errori se gli aggiornamenti dell'infrastruttura e dell'applicazione vengono combinati in una versione, intenzionalmente o meno.

• Abilita la distribuzione blu/verde: ogni aggiornamento viene distribuito usando una migrazione graduale del traffico alla nuova versione.

• Distribuzione e debug più semplici dell'applicazione : l'intero stamp non ospiterà mai più versioni dell'applicazione affiancate.

• Rollback semplice: il traffico può essere riportato agli indicatori che eseguono la versione precedente se si verificano errori o problemi.

• Eliminazione di modifiche manuali e deviazione della configurazione: ogni ambiente è una nuova distribuzione.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: distribuzioni temporanee blu/verde

Strategia di ramificazione

La base della strategia di aggiornamento è l'uso di rami all'interno del repository Git. L'architettura di riferimento usa tre tipi di rami:

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Strategia di diramazione

Aggiornamenti rapidi

Quando è necessario un hotfix urgente a causa di un bug o di un altro problema e non può eseguire il normale processo di rilascio, è disponibile un percorso hotfix. Gli aggiornamenti critici della sicurezza e le correzioni all'esperienza utente che non sono stati individuati durante i test iniziali sono considerati esempi validi di hotfix.

L'hotfix deve essere creato in un nuovo fix ramo e quindi unito all'uso main di una richiesta pull normale. Invece di creare un nuovo ramo di versione, l'hotfix è "cherry-picked" in un ramo di versione esistente. Questo ramo è già distribuito nell'ambiente prod . La pipeline CI/CD che ha originariamente distribuito il ramo di rilascio con tutti i test viene eseguita nuovamente e ora distribuirà l'hotfix come parte della pipeline.

Per evitare problemi principali, è importante che l'hotfix contenga alcuni commit isolati che possono essere facilmente scelti e integrati nel ramo di rilascio. Se non è possibile selezionare commit isolati per l'integrazione nel ramo di versione, è un'indicazione che la modifica non è idonea come hotfix. La modifica deve essere distribuita come nuova versione completa e potenzialmente combinata con un rollback a una versione stabile precedente fino a quando non è possibile distribuire la nuova versione.

Distribuzione: ambienti

L'architettura di riferimento usa due tipi di ambienti per l'infrastruttura:

• Breve durata : la pipeline di convalida E2E viene usata per distribuire ambienti di breve durata. Gli ambienti di breve durata vengono usati per ambienti di convalida o debug puri per gli sviluppatori. Gli ambienti di convalida possono essere creati dal feature/* ramo, sottoposti a test e quindi eliminati se tutti i test hanno avuto esito positivo. Gli ambienti di debug vengono distribuiti nello stesso modo della convalida, ma non vengono eliminati immediatamente. Questi ambienti non devono esistere per più di qualche giorno e devono essere eliminati quando viene unita la richiesta pull corrispondente del ramo di funzionalità.

• Permanente: negli ambienti permanenti sono integration (int) disponibili versioni e production (prod) . Questi ambienti vivono continuamente e non vengono distrutti. Gli ambienti usano nomi di dominio fissi come int.mission-critical.app. In un'implementazione reale dell'architettura di riferimento, è necessario aggiungere un staging ambiente (pre-prod). L'ambiente staging viene usato per distribuire e convalidare release i rami con lo stesso processo di aggiornamento di prod (distribuzione Blu/Verde).

  • Integrazione (int): la int versione viene distribuita di notte dal main ramo con lo stesso processo di prod. Il passaggio del traffico è più veloce rispetto all'unità di rilascio precedente. Invece di passare gradualmente il traffico in più giorni, come in prod, il processo per int il completamento viene completato entro pochi minuti o ore. Questo cambio più rapido garantisce che l'ambiente aggiornato sia pronto entro la mattina successiva. I vecchi stamp vengono eliminati automaticamente se tutti i test nella pipeline hanno esito positivo.

  • Produzione (prod): la prod versione viene distribuita solo dai release/* rami. Il passaggio al traffico usa passaggi più granulari. Un gate di approvazione manuale è compreso tra ogni passaggio. Ogni versione crea nuovi francobolli regionali e distribuisce la nuova versione dell'applicazione ai francobolli. I francobolli esistenti non vengono toccati nel processo. La considerazione più importante per prod è che deve essere "sempre attivo". Non dovrebbero mai verificarsi tempi di inattività pianificati o non pianificati. L'unica eccezione è rappresentato dalle modifiche fondamentali apportate al livello del database. Potrebbe essere necessaria una finestra di manutenzione pianificata.

Distribuzione: risorse condivise e dedicate

Gli ambienti permanenti (int e prod) all'interno dell'architettura di riferimento hanno diversi tipi di risorse a seconda che siano condivisi con l'intera infrastruttura o dedicati a un singolo timbro. Le risorse possono essere dedicate a una versione specifica ed esistono solo fino a quando l'unità di rilascio successiva non è stata acquisita.

Unità di rilascio

Un'unità di rilascio è un numero di stamp a livello di area per ogni versione di rilascio specifica. Gli stamp contengono tutte le risorse che non sono condivise con gli altri francobolli. Queste risorse sono reti virtuali, cluster servizio Azure Kubernetes, Hub eventi e Azure Key Vault. Azure Cosmos DB e Registro Azure Container sono configurati con le origini dati Terraform.

Risorse condivise a livello globale

Tutte le risorse condivise tra le unità di rilascio vengono definite in un modello Terraform indipendente. Queste risorse sono Frontdoor, Azure Cosmos DB, Registro Container e le aree di lavoro Log Analytics e altre risorse correlate al monitoraggio. Queste risorse vengono distribuite prima della distribuzione del primo timbro a livello di area di un'unità di rilascio. Le risorse vengono a cui si fa riferimento nei modelli Terraform per i francobolli.

Frontdoor

Anche se Frontdoor è una risorsa condivisa a livello globale tra timbri, la configurazione è leggermente diversa rispetto alle altre risorse globali. Frontdoor deve essere riconfigurato dopo la distribuzione di un nuovo stamp. Frontdoor deve essere riconfigurato per passare gradualmente al traffico verso i nuovi francobolli.

La configurazione back-end di Frontdoor non può essere definita direttamente nel modello Terraform. La configurazione viene inserita con le variabili Terraform. I valori delle variabili vengono costruiti prima dell'avvio della distribuzione di Terraform.

La configurazione dei singoli componenti per la distribuzione di Frontdoor è definita come:

• Front-end : l'affinità di sessione è configurata per garantire che gli utenti non passino da versioni diverse dell'interfaccia utente durante una singola sessione.

• Origini : Frontdoor è configurato con due tipi di gruppi di origine:

  1. Gruppo di origine per l'archiviazione statica che serve l'interfaccia utente. Il gruppo contiene gli account di archiviazione del sito Web da tutte le unità di rilascio attualmente attive. È possibile assegnare pesi diversi alle origini di diverse unità di rilascio per spostare gradualmente il traffico in un'unità più recente. A ogni origine di un'unità di rilascio deve essere assegnato lo stesso peso.

  2. Un gruppo di origine per l'API, ospitato nel servizio Azure Kubernetes. Se sono presenti unità di rilascio con versioni API diverse, esiste un gruppo di origine API per ogni unità di rilascio. Se tutte le unità di versione offrono la stessa API compatibile, tutte le origini vengono aggiunte allo stesso gruppo e assegnate pesi diversi.

• Regole di routing: esistono due tipi di regole di routing:

  1. Regola di routing per l'interfaccia utente collegata al gruppo di origine di archiviazione dell'interfaccia utente.

  2. Regola di routing per ogni API attualmente supportata dalle origini. Ad esempio: /api/1.0/* e /api/2.0/*.

  Se una versione introduce una nuova versione delle API back-end, le modifiche rifletteranno nell'interfaccia utente distribuita come parte della versione. Una versione specifica dell'interfaccia utente chiamerà sempre una versione specifica dell'URL dell'API. Gli utenti serviti da una versione dell'interfaccia utente useranno automaticamente l'API back-end corrispondente. Sono necessarie regole di routing specifiche per diverse istanze della versione dell'API. Queste regole sono collegate ai gruppi di origine corrispondenti. Se non è stata introdotta una nuova API, tutte le regole di routing correlate all'API sono collegate al gruppo di origine singolo. In questo caso, non importa se un utente viene servito dall'interfaccia utente da una versione diversa rispetto all'API.

Distribuzione: processo di distribuzione

Una distribuzione blu/verde è l'obiettivo del processo di distribuzione. Una nuova versione da un release/* ramo viene distribuita nell'ambiente prod . Il traffico utente viene gradualmente spostato agli indicatori per la nuova versione.

Come primo passaggio del processo di distribuzione di una nuova versione, l'infrastruttura per la nuova unità di rilascio viene distribuita con Terraform. L'esecuzione della pipeline di distribuzione dell'infrastruttura distribuisce la nuova infrastruttura da un ramo di versione selezionato. In parallelo al provisioning dell'infrastruttura, le immagini del contenitore vengono compilate o importate e sottoposte a push nel registro contenitori condiviso globale. Al termine dei processi precedenti, l'applicazione viene distribuita nei francobolli. Dal punto di vista dell'implementazione, si tratta di una pipeline con più fasi dipendenti. È possibile riesezionare la stessa pipeline per le distribuzioni di hotfix.

Dopo aver distribuito e convalidato la nuova unità di versione, viene aggiunta a Frontdoor per ricevere il traffico degli utenti.

È necessario pianificare un commutatore/parametro che distingue tra le versioni che eseguono e non introducono una nuova versione dell'API. In base a se la versione introduce una nuova versione dell'API, è necessario creare un nuovo gruppo di origine con i back-end dell'API. In alternativa, è possibile aggiungere nuovi back-end API a un gruppo di origine esistente. I nuovi account di archiviazione dell'interfaccia utente vengono aggiunti al gruppo di origine esistente corrispondente. I pesi per le nuove origini devono essere impostati in base alla divisione del traffico desiderata. È necessario creare una nuova regola di routing come descritto in precedenza che corrisponde al gruppo di origine appropriato.

Come parte dell'aggiunta della nuova unità di rilascio, i pesi delle nuove origini devono essere impostati sul traffico utente minimo desiderato. Se non vengono rilevati problemi, la quantità di traffico utente deve essere aumentata al nuovo gruppo di origine in un periodo di tempo. Per regolare i parametri di peso, è necessario eseguire di nuovo gli stessi passaggi di distribuzione con i valori desiderati.

Disinstallazione dell'unità di rilascio

Come parte della pipeline di distribuzione per un'unità di rilascio, esiste una fase di eliminazione definitiva che rimuove tutti i timbri una volta che un'unità di rilascio non è più necessaria. Tutto il traffico viene spostato in una nuova versione di rilascio. Questa fase include la rimozione dei riferimenti alle unità di rilascio da Frontdoor. Questa rimozione è fondamentale per abilitare il rilascio di una nuova versione in una data successiva. Frontdoor deve puntare a una singola unità di rilascio per essere preparata per la versione successiva in futuro.

Elenchi di controllo

Nell'ambito della frequenza di rilascio, è consigliabile usare un elenco di controllo per la versione preliminare e successiva. L'esempio seguente è costituito da elementi che devono trovarsi almeno in qualsiasi elenco di controllo.

• Elenco di controllo di versioni non definitive: prima di avviare una versione, verificare quanto segue:

  • Verificare che lo stato più recente del main ramo sia stato distribuito correttamente e testato nell'ambiente int .

  • Aggiornare il file del log delle modifiche tramite una richiesta pull per il main ramo .

  • Creare un release/ ramo dal main ramo .

• Elenco di controllo post-rilascio: prima che i vecchi francobolli vengano eliminati definitivamente e i relativi riferimenti vengano rimossi da Frontdoor, verificare che:

  • I cluster non ricevono più traffico in ingresso.

  • Hub eventi e altre code di messaggi non contengono messaggi non elaborati.

Distribuzione: limitazioni e rischi della strategia di aggiornamento

La strategia di aggiornamento descritta in questa architettura di riferimento presenta alcune limitazioni e rischi da menzionare:

• Costo più elevato: quando si rilasciano gli aggiornamenti, molti dei componenti dell'infrastruttura sono attivi due volte per il periodo di rilascio.

• Complessità di Frontdoor: il processo di aggiornamento in Frontdoor è complesso da implementare e gestire. La possibilità di eseguire distribuzioni blu/verde efficaci con tempo di inattività zero dipende dal corretto funzionamento.

• Piccole modifiche che richiedono molto tempo: il processo di aggiornamento comporta un processo di rilascio più lungo per piccole modifiche. Questa limitazione può essere parzialmente attenuata con il processo hotfix descritto nella sezione precedente.

Distribuzione: Considerazioni sulla compatibilità per l'inoltro dei dati delle applicazioni

La strategia di aggiornamento può supportare più versioni di un'API e componenti di lavoro in esecuzione simultaneamente. Poiché Azure Cosmos DB è condiviso tra due o più versioni, è possibile che gli elementi dati modificati da una versione non corrispondano sempre alla versione dell'API o dei ruoli di lavoro che lo usano. I livelli API e i ruoli di lavoro devono implementare la progettazione della compatibilità in avanti. Le versioni precedenti dell'API o dei componenti di lavoro elaborano i dati inseriti da una versione successiva dell'API o del componente di lavoro. Ignora le parti che non capisce.

Test in corso

L'architettura di riferimento contiene test diversi usati in diverse fasi all'interno dell'implementazione del test.

Questi test includono:

• Unit test : questi test verificano che la logica di business dell'applicazione funzioni come previsto. L'architettura di riferimento contiene una suite di unit test di esempio eseguita automaticamente prima di ogni compilazione di contenitori da Azure Pipelines. Se un test ha esito negativo, la pipeline verrà interrotta. La compilazione e la distribuzione non procederanno.

• Test di carico: questi test consentono di valutare la capacità, la scalabilità e i potenziali colli di bottiglia per un determinato carico di lavoro o stack. L'implementazione di riferimento contiene un generatore di carico utente per creare modelli di carico sintetici che possono essere usati per simulare il traffico reale. Il generatore di carico può anche essere usato indipendentemente dall'implementazione di riferimento.

• Smoke test : questi test identificano se l'infrastruttura e il carico di lavoro sono disponibili e agiscono come previsto. I test smoke vengono eseguiti come parte di ogni distribuzione.

• Test dell'interfaccia utente: questi test verificano che l'interfaccia utente sia stata distribuita e funzioni come previsto. L'implementazione corrente acquisisce solo screenshot di diverse pagine dopo la distribuzione senza alcun test effettivo.

• Test di iniezione di errori: questi test possono essere automatizzati o eseguiti manualmente. I test automatizzati nell'architettura integrano Azure Chaos Studio come parte delle pipeline di distribuzione.

Per altre informazioni, vedere Distribuzione e test per carichi di lavoro cruciali in Azure: Convalida e test continui

Test: framework

Implementazione di riferimento online di funzionalità e framework di test esistenti ogni volta che è possibile.

Test: test di iniezione di errori e Chaos Engineering

Le applicazioni distribuite devono essere resilienti alle interruzioni del servizio e dei componenti. Il test di iniezione di errori (noto anche come Fault Injection o Chaos Engineering) è la pratica di sottoporre applicazioni e servizi a stress e errori reali.

La resilienza è una proprietà di un intero sistema e l'inserimento di errori consente di individuare i problemi nell'applicazione. La risoluzione di questi problemi consente di convalidare la resilienza delle applicazioni a condizioni inaffidabili, dipendenze mancanti e altri errori.

I test manuali e automatici possono essere eseguiti sull'infrastruttura per individuare errori e problemi nell'implementazione.

Automatico

L'architettura di riferimento integra Azure Chaos Studio per distribuire ed eseguire un set di esperimenti di Azure Chaos Studio per inserire vari errori a livello di stamp. Gli esperimenti Chaos possono essere eseguiti come parte facoltativa della pipeline di distribuzione E2E. Quando vengono eseguiti i test, il test di carico facoltativo viene sempre eseguito in parallelo. Il test di carico viene usato per creare il carico nel cluster per convalidare l'effetto degli errori inseriti.

Manuale

I test manuali di inserimento degli errori devono essere eseguiti in un ambiente di convalida E2E. Questo ambiente garantisce test rappresentativi completi senza rischi di interferenza da altri ambienti. La maggior parte degli errori generati con i test può essere osservata direttamente nella visualizzazione metriche live di Application Insights. Gli errori rimanenti sono disponibili nella visualizzazione Errori e nelle tabelle di log corrispondenti. Altri errori richiedono un debug più approfondito, ad esempio l'uso di kubectl per osservare il comportamento all'interno del servizio Azure Kubernetes.

Due esempi di test di inserimento degli errori eseguiti sull'architettura di riferimento sono:

• Inserimento di errori basato su DNS: un test case in grado di simulare più problemi. Errori di risoluzione DNS causati dall'errore di un server DNS o di DNS di Azure. I test basati su DNS consentono di simulare problemi generali di connessione tra un client e un servizio, ad esempio quando BackgroundProcessor non riesce a connettersi a Hub eventi.

  Negli scenari a host singolo è possibile modificare il file locale hosts per sovrascrivere la risoluzione DNS. In un ambiente più grande con più server dinamici come il servizio Azure Kubernetes, un hosts file non è fattibile. Le zone DNS privato di Azure possono essere usate come alternativa agli scenari di test degli errori.

  Hub eventi di Azure e Azure Cosmos DB sono due dei servizi di Azure usati nell'implementazione di riferimento che possono essere usati per inserire errori basati su DNS. La risoluzione DNS di Hub eventi può essere modificata con una zona di DNS privato di Azure collegata alla rete virtuale di uno dei francobolli. Azure Cosmos DB è un servizio replicato a livello globale con endpoint a livello di area specifici. La manipolazione dei record DNS per tali endpoint può simulare un errore per un'area specifica e testare il failover dei client.

• Blocco del firewall: la maggior parte dei servizi di Azure supporta le restrizioni di accesso al firewall in base a reti virtuali e/o indirizzi IP. Nell'infrastruttura di riferimento queste restrizioni vengono usate per limitare l'accesso ad Azure Cosmos DB o a Hub eventi. Una semplice procedura consiste nel rimuovere le regole Consenti esistenti o aggiungere nuove regole di blocco. Questa procedura può simulare errori di configurazione del firewall o interruzioni del servizio.

  I servizi di esempio seguenti nell'implementazione di riferimento possono essere testati con un test del firewall:

  Service	Risultato
  Insieme di credenziali delle chiavi di	Quando l'accesso a Key Vault viene bloccato, l'effetto più diretto è stato l'errore di generazione di nuovi pod. Il driver CSI di Key Vault che recupera i segreti all'avvio del pod non può eseguire le attività e impedisce l'avvio del pod. È possibile osservare i messaggi di errore corrispondenti con kubectl describe po CatalogService-deploy-my-new-pod -n workload. I pod esistenti continueranno a funzionare, anche se verrà osservato lo stesso messaggio di errore. Il messaggio di errore viene generato dai risultati del controllo periodico degli aggiornamenti per i segreti. Anche se non testato, si presuppone che l'esecuzione di una distribuzione non funzioni mentre Key Vault non è accessibile. Le attività terraform e dell'interfaccia della riga di comando di Azure all'interno dell'esecuzione della pipeline inseguono richieste a Key Vault.
  Hub eventi	Quando l'accesso a Hub eventi è bloccato, i nuovi messaggi inviati da CatalogService e HealthService avranno esito negativo. Il recupero dei messaggi da BackgroundProcess avrà esito negativo lentamente, con un errore totale entro pochi minuti.
  Azure Cosmos DB	La rimozione dei criteri firewall esistenti per una rete virtuale comporta la Servizio integrità per iniziare a non riuscire con un ritardo minimo. Questa procedura simula solo un caso specifico, un'interruzione completa di Azure Cosmos DB. La maggior parte dei casi di errore che si verificano a livello di area deve essere mitigata automaticamente dal failover trasparente del client in un'area diversa di Azure Cosmos DB. Il test di inserimento degli errori basato su DNS descritto in precedenza è un test più significativo per Azure Cosmos DB.
  Registro Contenitori	Quando l'accesso a Registro Azure Container viene bloccato, la creazione di nuovi pod di cui è stato eseguito il pull e memorizzato nella cache in precedenza in un nodo del servizio Azure Kubernetes continuerà a funzionare. La creazione funziona ancora a causa del flag pullPolicy=IfNotPresentdi distribuzione k8s . I nodi che non hanno eseguito il pull e memorizzato nella cache un'immagine prima che il blocco non possa generare un nuovo pod e non riesce immediatamente con ErrImagePull errori. kubectl describe pod visualizza il messaggio corrispondente 403 Forbidden .
  Bilanciamento del carico in ingresso del servizio Azure Kubernetes	La modifica delle regole in ingresso per HTTP(S)(porte 80 e 443) nel gruppo di sicurezza di rete gestito del servizio Azure Kubernetes (NSG) per negare i risultati del traffico del probe di integrità o dell'utente non riesce a raggiungere il cluster. Il test di questo errore è difficile individuare la causa radice, simulata come blocco tra il percorso di rete di Frontdoor e un timbro a livello di area. Frontdoor rileva immediatamente questo errore e rimuove il timbro dalla rotazione.