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 till infrastrukturen, och programmet ovanpå, ska distribueras utan driftstopp till 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 endast till dessa nya stämplar. På samma sätt distribueras den nya programversionen endast 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 det fastställs att trafik hanteras från de nya stämplarna utan problem tas de tidigare stämplarna bort.

Intrång, kaos och stresstestning rekommenderas för den distribuerade miljön. Proaktiv testning av infrastrukturen identifierar svagheter och hur det distribuerade programmet fungerar 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.

  • Noll stilleståndstidsuppdateringar – Uppdateringar och uppgraderingar distribueras till miljön utan avbrott i det distribuerade programmet.

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

  • Delade och dedikerade resurser – Azure-resurser som är dedikerade och delade till 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

Distribution: 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 – pipelines som används av arkitekturen för alla bygg-, test- och versionsaktiviteter.

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 DevOps Services?.

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

Distribution: Noll stilleståndstidsuppdateringar

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 associerade konfiguration.

  • Program – den värdbaserade tjänst eller det program 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 blir 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 stämpeln kommer aldrig att vara värd för flera versioner av programmet sida vid sida.

  • Enkel återställning – Trafik 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:

Filial beskrivning
feature/* och fix/* Startpunkterna för alla ändringar. Dessa grenar skapas av utvecklare och bör ges ett beskrivande namn, t.ex feature/catalog-update . eller fix/worker-timeout-bug. När ändringarna är klara att sammanfogas skapas en pull-begäran (PR) mot grenen main . Varje pr måste godkännas av minst en granskare. Med begränsade undantag måste varje ändring som föreslås i en pr köras via valideringspipelinen från slutpunkt till slutpunkt (E2E). E2E-pipelinen bör användas av utvecklare 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. main Ändringar i görs endast via pull-begäranden. En grenprincip förbjuder direktskrivningar. Nattliga versioner mot den permanenta integration (int) miljön 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: Branching-strategi

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 med main hjälp av en vanlig PR. I stället för att skapa en ny versionsgren är snabbkorrigeringen "cherry-picked" i en befintlig versionsgren. Den här grenen har redan distribuerats till prod miljön. CI/CD-pipelinen som ursprungligen distribuerade versionsgrenen med alla tester körs igen och distribuerar nu snabbkorrigeringen som en del av pipelinen.

För att undvika större problem är det viktigt att snabbkorrigeringen innehåller några isolerade incheckningar som enkelt kan plockas och integreras i versionsgrenen. Om isolerade incheckningar inte kan plockas med körsbär för att integreras i versionsgrenen är det en indikation på att ändringen inte kvalificerar sig som en snabbkorrigering. Ändringen bör distribueras som en fullständig ny version och eventuellt kombineras 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:

  • Kortlivad – 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 integration (int) det 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 (förinställd) miljö läggas till. Miljön staging används för att distribuera och verifiera release grenar med samma uppdateringsprocess som prod (blå/grön distribution).

    • Integrering (int) – Versionen int distribueras varje kväll från grenen main med samma process som prod. Växlingen av trafik är snabbare än den tidigare versionsenheten. I stället för int att gradvis byta trafik under flera dagar, som i prod, slutförs processen 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.

    • Produktion (prod) – Versionen prod distribueras endast från release/* grenar. 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 prod på ä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. Ett planerat 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 har tagit över.

Versionsenheter

En versionsenhet är flera regionala stämplar per specifik version. 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 distribueras innan den första regionala stämpeln för en versionsenhet distribueras. Resurserna refereras till i Terraform-mallarna för stämplarna.

Front Door

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 konfigureras om för att gradvis växla över trafiken till de nya stämplarna.

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.

  • Ursprung – 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 versionsenhet bör ha samma vikt tilldelad.

    2. En ursprungsgrupp för API:et, som finns på AKS. 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 ursprungsgruppen för användargränssnittet.

    2. En routningsregel för varje API som för närvarande stöds av ursprunget. Exempelvis: /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.

Distribution: Distributionsprocess

En blå/grön distribution är målet med distributionsprocessen. En ny version från en release/* gren distribueras till 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. Samma pipeline kan köras igen för snabbkorrigeringsdistributioner.

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

En växel/parameter som skiljer mellan versioner som gör och inte introducerar en ny API-version bör planeras för. Baserat på om versionen introducerar en ny API-version måste en ny ursprungsgrupp med API-serverdelarna skapas. Du kan också lägga till nya API-serverdelar 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 distributionspipelinen för en versionsenhet finns det en destrueringsfas som tar bort alla stämplar när en versionsenhet inte längre behövs. All trafik flyttas till en ny version. Det här steget omfattar borttagning av versionsenhetsreferenser 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örhandsversion – Kontrollera följande innan du startar en version:

    • Kontrollera att det senaste tillståndet för grenen main 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 lanseringen – Kontrollera att innan gamla stämplar förstörs och deras referenser tas bort från Front Door:

    • 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 den 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.

Distribution: Kompatibilitetsöverväganden för programdata vidarebefordras

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 har infogats av ett senare API eller en senare version av arbetskomponenten. Den ignorerar delar som den inte förstår.

Testning

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. Kompilering och distribution fortsätter inte.

  • 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. Röktester 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.

  • Test av felinmatning – Dessa tester kan automatiseras eller köras manuellt. Automatiserad testning i arkitekturen integrerar Azure Chaos Studio som en del av distributionspipelines.

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

Testning: Ramverk

Onlinereferensimplementeringen 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. Enhetstester körs automatiskt av Azure Pipelines innan containerbyggen.
JMeter med Azure Load Testing Inläsning Azure Load Testing är en hanterad tjänst som används för att köra Apache JMeter-belastningstestdefinitioner .
Locust Inläsning 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 öppen källkod Node.js bibliotek 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. Att åtgärda dessa problem hjälper till att verifiera programmets återhämtning till otillförlitliga villkor, 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.

Manuell

Manuell inmatningstestning 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-måttvyn . 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 AKS.

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

  • DNS-baserad felinmatning – 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ändelsehubbar.

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

    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 Azure-Privat DNS zon 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 redundans för klienter.

  • Brandväggsblockering – De flesta Azure-tjänster har stöd för 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åtna regler eller lägga till nya blockregler . 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 Result
    Key Vault När åtkomsten till Key Vault blockeras var den mest direkta effekten att nya poddar inte kunde skapa. 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 kommer att observeras. Felmeddelandet genereras av resultatet av den periodiska uppdateringskontrollen för hemligheter. Även om det är otestat antas det att körningen av en distribution inte fungerar när 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änst 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å bör minimeras automatiskt genom 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 har hämtats och cachelagrats tidigare på en AKS-nod att fungera. Skapandet fungerar fortfarande på grund av k8s-distributionsflaggan pullPolicy=IfNotPresent. Noder som inte har hämtat och cachelagrat en bild innan blocket inte kan skapa en ny podd och misslyckas omedelbart med ErrImagePull fel. kubectl describe pod visar motsvarande 403 Forbidden meddelande.
    AKS-inkommande lastbalanserare Ändringen av de inkommande reglerna för HTTP(S)(portarna 80 och 443) i den AKS-hanterade nätverkssäkerhetsgruppen (NSG) för att neka resulterar i att trafik för användar- eller hälsoavsökning inte når 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.