Dela via

Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure

  • Artikel

Distributionen och testningen av den verksamhetskritiska miljön är en viktig del av den övergripande referensarkitekturen. De enskilda programstämplarna distribueras med hjälp av infrastruktur som kod från en källkodslagringsplats. Uppdateringar av infrastrukturen och programmet överst ska distribueras utan avbrottstid för programmet. En DevOps-pipeline för kontinuerlig integrering rekommenderas för att hämta källkoden från lagringsplatsen och distribuera enskilda stämplar i Azure.

Distribution och uppdateringar är den centrala processen i arkitekturen. Infrastruktur- och programrelaterade uppdateringar bör distribueras till helt oberoende stämplar. Endast de globala infrastrukturkomponenterna i arkitekturen delas mellan stämplarna. Befintliga stämplar i infrastrukturen berörs inte. Infrastrukturuppdateringar distribueras till dessa nya stämplar. På samma sätt distribueras de nya programversionerna till dessa nya stämplar.

De nya stämplarna läggs till i Azure Front Door. Trafiken flyttas gradvis över till de nya stämplarna. När trafik hanteras från de nya frimärkena utan problem tas de tidigare stämplarna bort.

Penetrationstestning, kaos och stresstestning rekommenderas för den implementerade miljön. Proaktiv testning av infrastrukturen identifierar svagheter och hur det distribuerade programmet beter sig om det uppstår ett fel.

Distribution

Distributionen av infrastrukturen i referensarkitekturen är beroende av följande processer och komponenter:

  • DevOps – källkoden från GitHub och pipelines för infrastrukturen.

  • Zero downtime updates – Uppdateringar och uppgraderingar implementeras i miljön utan driftsavbrott för den implementerade applikationen.

  • Miljöer – Kortvariga och permanenta miljöer som används för arkitekturen.

  • Delade och dedikerade resurser – Azure-resurser som är dedikerade och delade för stämplar och övergripande infrastruktur.

Diagram över distributionsprocessens flödesschema.

Mer information finns i Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure: Designöverväganden

Driftsättning: DevOps

DevOps-komponenterna tillhandahåller källkodslagringsplatsen och CI/CD-pipelines för distribution av infrastrukturen och uppdateringarna. GitHub och Azure Pipelines valdes som komponenter.

  • GitHub- – Innehåller källkodslagringsplatserna för programmet och infrastrukturen.

  • Azure Pipelines – De pipelines som arkitekturen använder för alla bygg-, test- och utgivningsaktiviteter.

En extra komponent i designen som används för distributionen är byggagenter. Microsofts värdbaserade byggagenter används som en del av Azure Pipelines för att distribuera infrastrukturen och uppdateringarna. Användningen av Microsoft Hosted-byggagenter tar bort hanteringsbördan för utvecklare att underhålla och uppdatera byggagenten.

Mer information om Azure Pipelines finns i Vad är Azure Pipelines?.

diagram över flödesschemat för DevOps-pipelinen.

Mer information finns i Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure: Infrastruktur som kod-distributioner

Implementering: Uppdateringar utan driftstopp

Strategin för uppdatering av noll stilleståndstid i referensarkitekturen är central för det övergripande verksamhetskritiska programmet. Metoden för att ersätta i stället för att uppgradera stämplarna säkerställer en ny installation av programmet i en infrastrukturstämpel. Referensarkitekturen använder en blå/grön metod och möjliggör separata test- och utvecklingsmiljöer.

Det finns två huvudkomponenter i referensarkitekturen:

  • Infrastruktur – Azure-tjänster och -resurser. Distribuerad med Terraform och dess tillhörande konfiguration.

  • Application – Den värdbaserade tjänsten eller programmet som hanterar användare. Baserat på Docker-containrar och npm-skapade artefakter i HTML och JavaScript för användargränssnittet för ensidesprogram (SPA).

I många system finns det ett antagande att programuppdateringar är vanligare än infrastrukturuppdateringar. Därför utvecklas olika uppdateringsprocedurer för var och en. Med en infrastruktur för offentliga moln kan ändringar ske i snabbare takt. En distributionsprocess för programuppdateringar och infrastrukturuppdateringar valdes. En metod säkerställer att infrastruktur- och programuppdateringar alltid är synkroniserade. Med den här metoden kan du:

  • En konsekvent process – Färre chanser till misstag om infrastruktur- och programuppdateringar blandas ihop i en version, avsiktligt eller inte.

  • Aktiverar blå/grön distribution – Varje uppdatering distribueras med hjälp av en gradvis migrering av trafik till den nya versionen.

  • Enklare distribution och felsökning av programmet – Hela miljön kör aldrig flera versioner av programmet samtidigt.

  • Enkel återställning – Trafiken kan växlas tillbaka till de stämplar som kör den tidigare versionen om fel eller problem uppstår.

  • Eliminering av manuella ändringar och konfigurationsavvikelser – Varje miljö är en ny distribution.

Mer information finns i Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure: Tillfälliga blå/gröna distributioner

Förgreningsstrategi

Grunden för uppdateringsstrategin är användningen av grenar på Git-lagringsplatsen. Referensarkitekturen använder tre typer av grenar:

Gren Beskrivning
feature/* och fix/* Startpunkterna för alla ändringar. Utvecklare skapar dessa grenar och bör få ett beskrivande namn, till exempel feature/catalog-update eller fix/worker-timeout-bug. När ändringarna är klara för sammanfogning skapas en pull-förfrågan (PR) mot main-grenen. Minst en granskare måste godkänna alla pull-begäranden. Med begränsade undantag måste varje ändring som föreslås i en PR genomgå slut-till-slut-valideringspipelinen. Utvecklare bör använda E2E-pipelinen för att testa och felsöka ändringar i en fullständig miljö.
main Den kontinuerligt framåtgående och stabila grenen. Används främst för integreringstestning. Ändringar i main görs endast via pull-begäranden. En grenprincip förbjuder direktskrivningar. Nattliga utgåvor mot den permanenta miljön integration (int) körs automatiskt från grenen main. Grenen main anses vara stabil. Det bör vara säkert att anta att en version kan skapas från den när som helst.
release/* Versionsgrenar skapas endast från grenen main. Grenarna följer formatet release/2021.7.X. Grenprinciper används så att endast lagringsplatsadministratörer kan skapa release/* grenar. Endast dessa grenar används för att distribuera till prod-miljön.

Mer information finns i Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure: Förgreningsstrategi

Snabbkorrigeringar

När en snabbkorrigering krävs omedelbart på grund av ett fel eller annat problem och inte kan gå igenom den regelbundna lanseringsprocessen är en snabbkorrigeringssökväg tillgänglig. Viktiga säkerhetsuppdateringar och korrigeringar av användarupplevelsen som inte identifierades under den första testningen anses vara giltiga exempel på snabbkorrigeringar.

Snabbkorrigeringen måste skapas i en ny fix gren och sedan sammanfogas till main med hjälp av en vanlig PR. I stället för att skapa en ny versionsgren plockas snabbkorrigeringen in i en befintlig versionsgren. Den här grenen har redan distribuerats till miljön prod. CI/CD-pipelinen som ursprungligen distribuerade versionsgrenen med alla tester körs igen och distribuerar snabbkorrigeringen som en del av pipelinen.

För att undvika större problem är det viktigt att hotfixen innehåller några isolerade förändringar som enkelt kan väljas ut och integreras i releasgrenen. Om isolerade commit-ar inte kan väljas ut för att integreras i versionsgrenen är det en indikation på att ändringen inte kvalificerar sig som en snabbkorrigering. Distribuera ändringen som en helt ny version. Kombinera den med en återställning till en tidigare stabil version tills den nya versionen kan distribueras.

Distribution: Miljöer

Referensarkitekturen använder två typer av miljöer för infrastrukturen:

  • kortlivade – E2E-valideringspipelinen används för att distribuera kortvariga miljöer. Kortvariga miljöer används för ren validering eller felsökning av miljöer för utvecklare. Valideringsmiljöer kan skapas från grenen feature/*, genomgå tester och sedan förstöras om alla tester lyckades. Felsökningsmiljöer distribueras på samma sätt som validering, men förstörs inte omedelbart. Dessa miljöer bör inte finnas på mer än några dagar och bör tas bort när motsvarande PR för funktionsgrenen slås samman.

  • Permanent – I permanenta miljöer finns det integration (int) och production (prod) versioner. Dessa miljöer lever kontinuerligt och förstörs inte. Miljöerna använder fasta domännamn som int.mission-critical.app. I en verklig implementering av referensarkitekturen bör en staging -miljö (preprod) läggas till. Den staging miljön används för att distribuera och verifiera release grenar med samma uppdateringsprocess som prod (blå/grön distribution).

    • Integration (int) – Versionen int implementeras varje natt från main-branch med samma process som prod. Växlingen av trafik är snabbare än i den tidigare versionen. I stället för att gradvis byta trafik under flera dagar, som i prod, slutförs processen för int inom några minuter eller timmar. Den här snabbare övergången säkerställer att den uppdaterade miljön är klar nästa morgon. Gamla stämplar tas bort automatiskt om alla tester i pipelinen lyckas.

    • Production (prod) – version prod distribueras endast från release/* brancher. Trafikväxlingen använder mer detaljerade steg. En manuell godkännandegrind finns mellan varje steg. Varje version skapar nya regionala stämplar och distribuerar den nya programversionen till stämplarna. Befintliga stämplar berörs inte i processen. Det viktigaste att tänka på för prod är att det ska vara "alltid på". Ingen planerad eller oplanerad stilleståndstid ska någonsin inträffa. Det enda undantaget är grundläggande ändringar i databaslagret. En planerad underhållsperiod kan behövas.

Distribution: Delade och dedikerade resurser

De permanenta miljöerna (int och prod) i referensarkitekturen har olika typer av resurser beroende på om de delas med hela infrastrukturen eller är dedikerade till en enskild stämpel. Resurser kan dedikeras till en viss version och finns bara tills nästa versionsenhet tar över.

Versionsenheter

En utgåvaenhet består av flera regionala markörer per specifik utgåva. Stämplar innehåller alla resurser som inte delas med de andra stämplarna. Dessa resurser är virtuella nätverk, Azure Kubernetes Service-kluster, Event Hubs och Azure Key Vault. Azure Cosmos DB och ACR konfigureras med Terraform-datakällor.

Globalt delade resurser

Alla resurser som delas mellan versionsenheter definieras i en oberoende Terraform-mall. Dessa resurser är Front Door, Azure Cosmos DB, Container Registry (ACR) och Log Analytics-arbetsytor och andra övervakningsrelaterade resurser. Dessa resurser implementeras innan den första regionala markeringen för en versionsenhet implementeras. Resurserna refereras till i Terraform-mallarna för stämplarna.

Ytterdörr

Front Door är en globalt delad resurs mellan stämplar, men konfigurationen skiljer sig något från de andra globala resurserna. Front Door måste konfigureras om när en ny stämpel har distribuerats. Front Door måste omkonfigureras för att gradvis styra om trafiken till de nya markörerna.

Serverdelskonfigurationen för Front Door kan inte definieras direkt i Terraform-mallen. Konfigurationen infogas med Terraform-variabler. Variabelvärdena skapas innan Terraform-distributionen startas.

Den enskilda komponentkonfigurationen för Front Door-distributionen definieras som:

  • Klientdel – Sessionstillhörighet har konfigurerats för att säkerställa att användarna inte växlar mellan olika gränssnittsversioner under en enda session.

  • Origins – Front Door har konfigurerats med två typer av ursprungsgrupper:

    1. En ursprungsgrupp för statisk lagring som hanterar användargränssnittet. Gruppen innehåller webbplatsens lagringskonton från alla aktuella aktiva versionsenheter. Olika vikter kan tilldelas till ursprunget från olika versionsenheter för att gradvis flytta trafik till en nyare enhet. Varje ursprung från en utlämningsenhet bör ha samma vikt tilldelad.

    2. En ursprungsgrupp för API:et som finns i Azure Kubernetes Service. Om det finns versionsenheter med olika API-versioner finns det en API-ursprungsgrupp för varje versionsenhet. Om alla versionsenheter erbjuder samma kompatibla API läggs alla ursprung till i samma grupp och tilldelas olika vikter.

  • Routningsregler – Det finns två typer av routningsregler:

    1. En routningsregel för användargränssnittet som är länkat till lagringsursprungsgruppen för användargränssnittet.

    2. En routningsregel för varje API som för närvarande stöds av ursprunget. Till exempel: /api/1.0/* och /api/2.0/*.

    Om en version introducerar en ny version av serverdels-API:erna återspeglas ändringarna i användargränssnittet som distribueras som en del av versionen. En specifik version av användargränssnittet anropar alltid en specifik version av API-URL:en. Användare som hanteras av en användargränssnittsversion använder automatiskt respektive serverdels-API. Specifika routningsregler behövs för olika instanser av API-versionen. Dessa regler är länkade till motsvarande ursprungsgrupper. Om ett nytt API inte introducerades länkar alla API-relaterade routningsregler till den enskilda ursprungsgruppen. I det här fallet spelar det ingen roll om en användare hanteras av användargränssnittet från en annan version än API:et.

Driftsättning: Driftsättningsprocess

En blå/grön distribution är målet med distributionsprocessen. En ny version från en release/*-gren distribueras till den prod-miljön. Användartrafiken flyttas gradvis till stämplarna för den nya versionen.

Som ett första steg i distributionsprocessen för en ny version distribueras infrastrukturen för den nya versionsenheten med Terraform. Körningen av infrastrukturdistributionspipelinen distribuerar den nya infrastrukturen från en vald versionsgren. Parallellt med infrastrukturetablering skapas eller importeras containeravbildningarna och skickas till det globalt delade containerregistret (ACR). När de tidigare processerna har slutförts distribueras programmet till stämplarna. Ur implementeringssynpunkt är det en pipeline med flera beroende faser. Den samma pipeline kan köras igen för hotfixdistribueringar.

När den nya versionsenheten har distribuerats och verifierats läggs den nya enheten till i Front Door för att ta emot användartrafik.

En växel/parameter som skiljer mellan versioner som antingen introducerar eller inte introducerar en ny API-version bör planeras för. Beroende på om utgåvan introducerar en ny API-version måste en ny ursprungsgrupp med backend-servrarna skapas. Du kan också lägga till nya API-backends i en befintlig ursprungsgrupp. Nya UI-lagringskonton läggs till i motsvarande befintliga ursprungsgrupp. Vikter för nya ursprung bör anges enligt önskad trafikdelning. En ny routningsregel enligt beskrivningen ovan måste skapas som motsvarar lämplig ursprungsgrupp.

Som en del av tillägget av den nya versionsenheten bör vikterna för det nya ursprunget anges till önskad minsta användartrafik. Om inga problem identifieras bör mängden användartrafik ökas till den nya ursprungsgruppen under en viss tidsperiod. Om du vill justera viktparametrarna ska samma distributionssteg köras igen med önskade värden.

Nedrivning av versionsenhet

Som en del av distributionskedjan för en versionsenhet finns det en borttagningsfas som tar bort alla stämplar när en versionsenhet inte längre behövs. All trafik flyttas till en ny utgåva. Det här steget omfattar borttagning av referenser till versioneringsenheter från Front Door. Den här borttagningen är viktig för att aktivera lanseringen av en ny version vid ett senare tillfälle. Front Door måste peka på en enda versionsenhet för att kunna förberedas för nästa version i framtiden.

Checklistor

Som en del av lanseringstakt bör en checklista före och efter lanseringen användas. Följande exempel är objekt som ska finnas i en checklista som minst.

  • checklista för förlansering – Kontrollera följande innan du påbörjar en release:

    • Kontrollera att den senaste statusen för main-grenen har distribuerats till och testats i int-miljön.

    • Uppdatera ändringsloggfilen via en PR mot grenen main.

    • Skapa en release/ gren från grenen main.

  • checklista efter publicering – Innan gamla stämplar förstörs och deras referenser tas bort från Front Door, kontrollera att:

    • Kluster tar inte längre emot inkommande trafik.

    • Event Hubs och andra meddelandeköer innehåller inga obearbetade meddelanden.

Distribution: Begränsningar och risker med uppdateringsstrategin

Uppdateringsstrategin som beskrivs i den här referensarkitekturen har vissa begränsningar och risker som bör nämnas:

  • Högre kostnad – När uppdateringar släpps är många av infrastrukturkomponenterna aktiva två gånger under lanseringsperioden.

  • Front Door-komplexitet – Uppdateringsprocessen i Front Door är komplex att implementera och underhålla. Möjligheten att köra effektiva blå/gröna distributioner utan stilleståndstid beror på att processen fungerar korrekt.

  • Små ändringar tidskrävande – Uppdateringsprocessen resulterar i en längre lanseringsprocess för små ändringar. Den här begränsningen kan delvis minskas med snabbkorrigeringsprocessen som beskrivs i föregående avsnitt.

Utplacering: Överväganden för framåtkompatibilitet av applikationsdata

Uppdateringsstrategin kan stödja flera versioner av ett API och arbetskomponenter som körs samtidigt. Eftersom Azure Cosmos DB delas mellan två eller flera versioner finns det en möjlighet att dataelement som ändras av en version kanske inte alltid matchar den version av API:et eller arbetare som använder det. API-lagren och arbetarna måste implementera framåtriktad kompatibilitetsdesign. Tidigare versioner av API:et eller arbetskomponenterna bearbetar data som infogats av en senare API- eller arbetskomponentversion. Den ignorerar delar som den inte förstår.

Test

Referensarkitekturen innehåller olika tester som används i olika steg i testimplementeringen.

Dessa tester omfattar:

  • Enhetstester – Dessa tester verifierar att programmets affärslogik fungerar som förväntat. Referensarkitekturen innehåller en exempelsvit med enhetstester som körs automatiskt före varje containerbygge av Azure Pipelines. Om ett test misslyckas stoppas pipelinen. Bygg- och distributionsstopp. Utvecklaren måste åtgärda problemet innan pipelinen kan köras igen.

  • Belastningstester – Dessa tester hjälper till att utvärdera kapacitet, skalbarhet och potentiella flaskhalsar för en viss arbetsbelastning eller stack. Referensimplementeringen innehåller en användarbelastningsgenerator för att skapa syntetiska belastningsmönster som kan användas för att simulera verklig trafik. Belastningsgeneratorn kan också användas oberoende av referensimplementeringen.

  • Röktester – Dessa tester identifierar om infrastrukturen och arbetsbelastningen är tillgängliga och fungerar som förväntat. Smoketester körs som en del av varje distribution.

  • användargränssnittstester – Dessa tester verifierar att användargränssnittet har distribuerats och fungerar som förväntat. Den aktuella implementeringen samlar bara in skärmbilder av flera sidor efter distributionen utan några faktiska tester.

  • Felinmatningstester – Dessa tester kan automatiseras eller köras manuellt. Automatiserad testning i arkitekturen integrerar Azure Chaos Studio som en del av distributionsvägarna.

Mer information finns i Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure: Kontinuerlig validering och testning

Testning: Ramverk

Onlinereferensimplementeringen använder befintliga testfunktioner och ramverk när det är möjligt.

Ramverk Test Beskrivning
NUnit Enhet Det här ramverket används för enhetstestning av .NET Core-delen av implementeringen. Azure Pipelines kör enhetstester automatiskt innan containerbyggen.
JMeter med Azure Load Testing Ladda Azure Load Testing är en hanterad tjänst som används för att köra Apache JMeter- belastningstestdefinitioner.
Gräshoppa Ladda Locust är ett ramverk för belastningstestning med öppen källkod som skrivits i Python.
dramatiker Användargränssnitt och rök Playwright är ett bibliotek med öppen källkod Node.js för att automatisera Chromium, Firefox och WebKit med ett enda API. Dramaförfattarens testdefinition kan också användas oberoende av referensimplementeringen.
Azure Chaos Studio Felinmatning Referensimplementeringen använder Azure Chaos Studio som ett valfritt steg i E2E-valideringspipelinen för att mata in fel för återhämtningsverifiering.

Testning: Test av felinmatning och Chaos Engineering

Distribuerade program ska vara motståndskraftiga mot avbrott i tjänster och komponenter. Felinmatningstestning (även kallat felinmatning eller kaosteknik) är praxis att utsätta program och tjänster för verkliga påfrestningar och fel.

Motståndskraft är en egenskap för ett helt system och att mata in fel hjälper till att hitta problem i programmet. Åtgärda dessa problem hjälper till att validera appliceringens motståndskraft mot otillförlitliga förhållanden, saknade beroenden och andra fel.

Manuella och automatiska tester kan köras mot infrastrukturen för att hitta fel och problem i implementeringen.

Automatisk

Referensarkitekturen integrerar Azure Chaos Studio- för att distribuera och köra en uppsättning Azure Chaos Studio-experiment för att mata in olika fel på stämpelnivå. Kaosexperiment kan köras som en valfri del av E2E-distributionspipelinen. När testerna körs körs det valfria belastningstestet alltid parallellt. Belastningstestet används för att skapa belastning på klustret för att verifiera effekten av de inmatade felen.

Handbok

Manuell felinjektionstestning ska utföras i en E2E-valideringsmiljö. Den här miljön garanterar fullständiga representativa tester utan risk för interferens från andra miljöer. De flesta fel som genereras med testerna kan observeras direkt i Application Insights Live-metrikvy. De återstående felen är tillgängliga i vyn Fel och motsvarande loggtabeller. Andra fel kräver djupare felsökning, till exempel användning av kubectl för att observera beteendet i Azure Kubernetes Service.

Två exempel på felinjektionstester som utförs mot referensarkitekturen är:

  • DNS (Domain Name Service)-baserad felinjektion – ett testfall som kan simulera flera problem. DNS-matchningsfel på grund av antingen fel på en DNS-server eller Azure DNS. DNS-baserad testning kan hjälpa till att simulera allmänna anslutningsproblem mellan en klient och en tjänst, till exempel när BackgroundProcessor inte kan ansluta till händelsehubbarna.

    I scenarier med enskild värd kan du ändra den lokala hosts-filen för att skriva över DNS-upplösningen. I en större miljö med flera dynamiska servrar som AKS är en hosts fil inte möjlig. Azure Private DNS-zoner kan användas som ett alternativ för att testa fel-scenarier.

    Azure Event Hubs och Azure Cosmos DB är två av de Azure-tjänster som används i referensimplementeringen som kan användas för att mata in DNS-baserade fel. Event Hubs DNS-matchning kan manipuleras med en Privat DNS-zon i Azure som är kopplad till det virtuella nätverket för en av stämplarna. Azure Cosmos DB är en globalt replikerad tjänst med specifika regionala slutpunkter. Manipulering av DNS-posterna för dessa slutpunkter kan simulera ett fel för en viss region och testa omkoppling för klienter.

  • Brandvägg som blockerar – De flesta Azure-tjänster stöder brandväggsåtkomstbegränsningar baserat på virtuella nätverk och/eller IP-adresser. I referensinfrastrukturen används dessa begränsningar för att begränsa åtkomsten till Azure Cosmos DB eller Event Hubs. En enkel procedur är att ta bort befintliga Tillåt regler eller lägga till nya Blockera regler. Den här proceduren kan simulera brandväggsfelkonfigurationer eller tjänstfel.

    Följande exempeltjänster i referensimplementeringen kan testas med ett brandväggstest:

    Tjänst Resultat
    Key Vault När åtkomsten till Key Vault blockeras var den mest direkta effekten att nya poddar inte kunde starta. Key Vault CSI-drivrutinen som hämtar hemligheter vid poddstart kan inte utföra sina uppgifter och förhindrar att podden startar. Motsvarande felmeddelanden kan observeras med kubectl describe po CatalogService-deploy-my-new-pod -n workload. Befintliga poddar fortsätter att fungera, även om samma felmeddelande observeras. Resultatet av den periodiska uppdateringskontrollen för hemligheter genererar felmeddelandet. Även om det är otestat fungerar det inte att köra en distribution medan Key Vault är otillgängligt. Terraform- och Azure CLI-uppgifter inom pipelinekörningen skickar begäranden till Key Vault.
    Event Hubs När åtkomsten till Event Hubs blockeras misslyckas nya meddelanden som skickas av CatalogService och HealthService. Hämtning av meddelanden från BackgroundProcess misslyckas långsamt, med totalt fel inom några minuter.
    Azure Cosmos DB Borttagning av den befintliga brandväggsprincipen för ett virtuellt nätverk resulterar i att hälsotjänsten börjar misslyckas med minsta fördröjning. Den här proceduren simulerar bara ett specifikt ärende, ett helt Azure Cosmos DB-avbrott. De flesta felfall som inträffar på regional nivå minimeras automatiskt med transparent redundansväxling av klienten till en annan Azure Cosmos DB-region. Det DNS-baserade felinmatningstest som beskrevs tidigare är ett mer meningsfullt test för Azure Cosmos DB.
    Containerregister (ACR) När åtkomsten till ACR blockeras fortsätter skapandet av nya poddar som hämtas och cachelagras tidigare på en AKS-nod att fungera. Skapelsen fungerar fortfarande på grund av K8s-distributionsflaggan pullPolicy=IfNotPresent. Noder kan inte skapa en ny pod och misslyckas direkt med ErrImagePull-fel om noden inte hämtar och cachelagrar en avbild innan blocket. kubectl describe pod visar motsvarande 403 Forbidden meddelande.
    AKS-ingress lastbalanserare Ändringen av de inkommande reglerna för HTTP(S) (portarna 80 och 443) i den AKS-hanterade nätverkssäkerhetsgruppen (NSG) till Neka resulterar i att användartrafik eller hälsoavsöknings-trafik inte kan nå klustret. Testet av det här felet är svårt att hitta rotorsaken, som simulerades som blockering mellan nätverkssökvägen för Front Door och en regional stämpel. Front Door upptäcker omedelbart detta fel och tar bort stämpeln från rotationen.