Nasazení a testování důležitých úloh v Azure

Testování a bezpečné nasazení změn aplikací a infrastruktury je klíčovým prvkem provozu architektury kritické pro splnění mise. Nasaďte razítka jednotlivých aplikací pomocí infrastruktury jako kódu z úložiště zdrojového kódu. Nasaďte aktualizace do infrastruktury a aplikace nad ní bez výpadku aplikace. Pomocí kanálu kontinuální integrace DevOps načtěte zdrojový kód z úložiště a nasaďte razítka jednotlivých nasazení v Azure.

Nasazení a aktualizace jsou ústředním procesem architektury. Aktualizace související s infrastrukturou a aplikacemi by se měly nasadit na plně nezávislé razítka. Pobočky sdílejí pouze globální komponenty infrastruktury v architektuře. Stávající razítka v infrastruktuře nebudou změněna. Aktualizace infrastruktury se nasazují na tyto nové razítka. Stejně tak se nové verze aplikací nasadí do těchto nových razítek.

Nové razítka se přidají do služby Azure Front Door. Provoz je postupně přesměrováván na nová razítka. Když je provoz veden z nových razítek bez problémů, předchozí razítka se smažou.

Pro nasazené prostředí se doporučuje penetrace, chaos a zátěžové testování. Proaktivní testování infrastruktury zjišťuje slabá místa a jak se nasazená aplikace chová, pokud dojde k selhání.

Nasazení

Nasazení klíčové infrastruktury závisí na následujících procesech a komponentách:

• DevOps – zdrojový kód z GitHubu a pipelines pro infrastrukturu.

• Bezvýpadkové aktualizace – Aktualizace a upgrady se nasazují do prostředí bez výpadku nasazované aplikace.

• Prostředí – krátkodobá a trvalá prostředí používaná pro architekturu.

• Sdílené a vyhrazené prostředky – prostředky Azure, které jsou vyhrazeny a sdíleny pro razítka a celkovou infrastrukturu.

Další informace najdete v tématu Nasazení a testování důležitých úloh na Azure: Aspekty návrhu.

Nasazení: DevOps

Komponenty DevOps poskytují úložiště zdrojového kódu a kanály CI/CD pro nasazení infrastruktury a aktualizací. Jako komponenty byly vybrány GitHub a Azure Pipelines.

• GitHub – obsahuje úložiště zdrojového kódu pro aplikaci a infrastrukturu.

• azure Pipelines – kanály používané architekturou pro všechny úlohy sestavení, testování a vydání.

Agenti sestavení jsou další komponentou potřebnou k nasazení. Nasaďte infrastrukturu a aktualizace pomocí agentů sestavení hostovaných Microsoftem jako součást služby Azure Pipelines. Použití agentů sestavení hostovaných Microsoftem eliminuje zatížení správy vývojářům při údržbě a aktualizaci agenta sestavení.

Další informace o službě Azure Pipelines najdete v tématu Co je Azure Pipelines?.

Další informace najdete v tématu Nasazení a testování důležitých úloh na Azure: Nasazení infrastruktury jako kódu.

Nasazení: Aktualizace bez přerušení

Strategie aktualizace bez výpadku v architektuře je zásadní pro celkovou zásadní podnikovou aplikaci. Metodika nahrazení místo aktualizace infrastrukturních jednotek zajišťuje novou instalaci aplikace do infrastrukturní jednotky. Architektura využívá modrý/zelený přístup a umožňuje samostatná testovací a vývojová prostředí.

Architektura má dvě hlavní součásti:

• Infrastruktura – služby a prostředky Azure. Nasazeno s využitím Terraformu a přidružené konfigurace.

• application – hostovaná služba nebo aplikace, která obsluhuje uživatele. Na základě kontejnerů Docker a artefaktů postavených pomocí npm v HTML a JavaScriptu pro uživatelské rozhraní jednostránkové aplikace (SPA).

V mnoha systémech existuje předpoklad, že aktualizace aplikací jsou častější než aktualizace infrastruktury. V důsledku toho se pro každý z nich vyvíjejí různé postupy aktualizace. S infrastrukturou veřejného cloudu se změny můžou provádět rychleji. Byl vybrán jeden proces nasazení pro aktualizace aplikací a aktualizace infrastruktury. Jedním z přístupů je, že se infrastruktura a aktualizace aplikací vždy synchronizují. Tento přístup umožňuje:

• jeden konzistentní proces – méně šancí na chyby v případě, že se aktualizace infrastruktury a aplikací vzájemně kombinují ve vydané verzi, úmyslně nebo ne.

• Umožňuje nasazení Blue/Green – Každá aktualizace se nasadí s využitím postupné migrace provozu do nové verze.

• Jednodušší nasazení a ladění aplikace – celé prostředí nikdy není hostitelem více verzí aplikace současně.

• jednoduché vrácení zpět – Provoz se dá přepnout zpět na razítka, která používají předchozí verzi, pokud dojde k chybám nebo problémům.

• Odstranění ručních změn a posunů konfigurace – každé prostředí je nové nasazení.

Další informace najdete v tématu Nasazení a testování důležitých úloh na Azure: Dočasné modré/zelené nasazení.

Strategie větvení

Základem strategie aktualizace je použití větví v úložišti Git. Architektura používá tři typy větví:

Větev / Pobočka	Popis
feature/* a fix/*	Vstupní body pro všechny změny. Vývojáři vytvářejí tyto větve a měli by mít popisný název, například feature/catalog-update nebo fix/worker-timeout-bug. Jakmile jsou změny připravené ke sloučení, vytvoří se pull request (PR) na větev main. Alespoň jeden recenzent musí schválit všechny žádosti o přijetí změn. S omezenými výjimkami musí každá změna navržená v pull requestu projít kompletním ověřovacím procesem end-to-end (E2E). Vývojáři by měli použít kanál E2E k otestování a ladění změn v kompletním prostředí.
main	Stabilní, nepřetržitě pohybující se větev. Většinou se používá k testování integrace. Změny main se provádějí jen prostřednictvím pull requestů. Zásada odvětví zakazuje přímé záznamy. Noční sestavení v rámci trvalého prostředí integration (int) jsou automaticky spouštěna z větve main. Větev main se považuje za stabilní. Za každých okolností by mělo být bezpečné předpokládat, že se z projektu dá vytvořit nová verze.
release/*	Větve vydání jsou vytvářeny pouze z větve main. Větve se řídí formátem release/2021.7.X. Zásady větví se používají k tomu, aby větve release/* mohli vytvářet pouze správci úložiště. K nasazení do prod prostředí se používají pouze tyto větve.

Další informace najdete v tématu Nasazení a testování důležitých úloh na Azure: Strategie větvení.

Hotfixy

Pokud je opravný balíček naléhavě nutný kvůli chybě nebo jinému problému a nemůže projít běžným procesem vydání, je k dispozici postup pro aplikaci opravného balíčku. Důležité aktualizace zabezpečení a opravy uživatelského prostředí, které nebyly zjištěny během počátečního testování, se považují za platné příklady oprav hotfix.

Hotfix musí být vytvořen v nové větvi fix a poté sloučen do main pomocí běžného pull requestu. Místo vytvoření nového vydání je oprava hotfix přesunuta pomocí cherry-pick do stávající větve vydání. Tato větev je již nasazena do prod prostředí. Kanál CI/CD, který původně nasadil release branch se všemi testy, se znovu spustí a nasadí hotfix jako součást pipeline.

Aby se předešlo velkým problémům, je důležité, aby hotfix obsahoval několik izolovaných commitů, které lze snadno vybrat a integrovat do uvolněné větve. Pokud se izolované commity nedají vybrat a použít k integraci do release větve, znamená to, že změna neodpovídá kritériím pro hotfix. Nasaďte změnu jako úplnou novou verzi. Zkombinujte ji se zpětným vrácením do bývalé stabilní verze, dokud nebude možné nasadit novou verzi.

Nasazení: Prostředí

Architektura používá pro infrastrukturu dva typy prostředí:

• Krátkodobá – Kanál ověřování E2E se používá k nasazení krátkodobých prostředí. Krátkodobá prostředí se používají k čistému ověřování nebo ladění prostředí pro vývojáře. Ověřovací prostředí je možné vytvořit z větve feature/*, podrobit se testům a pak je zničit, pokud byly všechny testy úspěšné. Ladicí prostředí se nasazují stejným způsobem jako validace, ale nejsou zničena okamžitě. Tato prostředí by neměla existovat déle než několik dní a měla by být odstraněna při sloučení odpovídajícího PR feature větve.

• trvalé – v trvalých prostředích existují verze integration (int) a production (prod). Tato prostředí jsou nepřetržitě aktivní a nezničí se. Prostředí používají pevné názvy domén, jako je int.mission-critical.app. V reálné implementaci architektury by mělo být přidáno prostředí staging (předprodukční). Prostředí staging slouží k nasazení a ověření větví release se stejným procesem aktualizace jako prod (modré/zelené nasazení).

  • integrace (int) – verze se nasazuje každou noc z větve stejným postupem jako . Přechod provozu je rychlejší než u předchozí verze. Místo postupného přepínání provozu během několika dnů, jako v prod, se proces pro int dokončí během několika minut nebo hodin. Tento rychlejší přechod zajišťuje, že aktualizované prostředí bude připravené příští ráno. Pokud jsou všechny testy v pipeline úspěšné, stará razítka se automaticky odstraní.

  • Production (prod) – prod verze se nasazuje pouze z větví release/*. Přepnutí provozu používá podrobnější kroky. Mezi každým krokem je ruční schvalovací brána. Každá verze vytvoří nové regionální instance a nasadí novou verzi aplikace do těchto instancí. Stávající razítka se v procesu nedotknou. Nejdůležitějším aspektem prod je, aby byl "vždy zapnutý". K žádnému plánovanému nebo neplánovanému výpadku by nikdy nemělo dojít. Jedinou výjimkou jsou základní změny databázové vrstvy. Může být potřeba časové období plánované údržby.

Nasazení: Sdílené a vyhrazené prostředky

Trvalá prostředí (int a prod) v architektuře mají různé typy prostředků v závislosti na tom, jestli jsou sdílená s celou infrastrukturou nebo vyhrazená pro jednotlivý otisk. Prostředky mohou být vyhrazeny pro konkrétní vydání a existují pouze do chvíle, kdy je převezme další vydání.

Uvolněné jednotky

Jednotka vydání je několik regionálních razítek pro specifickou verzi vydání. Razítka obsahují všechny zdroje, které nejsou sdíleny s jinými razítky. Tyto prostředky jsou virtuální sítě, cluster Azure Kubernetes Service, Event Hubs a Azure Key Vault. Azure Cosmos DB a ACR jsou nakonfigurované se zdroji dat Terraformu.

Globálně sdílené prostředky

Všechny prostředky sdílené mezi jednotkami vydaných verzí jsou definovány v nezávislé šabloně Terraformu. Tyto prostředky jsou Front Door, Azure Cosmos DB, Container Registry (ACR) a pracovní prostory služby Log Analytics a další prostředky související s monitorováním. Tyto prostředky jsou nasazeny před nasazením prvního regionálního razítka releasové jednotky. Na prostředky se odkazuje v šablonách Terraformu pro razítka.

Front Door

Front Door je globálně sdílený prostředek napříč datovými centry, ale jeho konfigurace se mírně liší od ostatních globálních prostředků. Po nasazení nového razítka musí být služba Front Door znovu nakonfigurovaná. Je nutné překonfigurovat Front Door tak, aby postupně přesměroval provoz na nové značky.

Konfiguraci back-endu služby Front Door není možné přímo definovat v šabloně Terraformu. Konfigurace se vloží pomocí proměnných Terraformu. Hodnoty proměnných se vytvářejí před spuštěním nasazení Terraformu.

Konfigurace jednotlivých komponent pro nasazení služby Front Door je definována takto:

• Frontend – afinitu relace je nakonfigurovaná tak, aby uživatelé během jedné relace nepřepínali mezi různými verzemi uživatelského rozhraní.

• origins – Služba Front Door je nakonfigurovaná se dvěma typy skupin původu:

  1. Skupina původu pro statické úložiště, která obsluhuje uživatelské rozhraní. Skupina obsahuje účty úložiště webu ze všech aktuálně aktivních jednotek vydání. Různé váhy lze přiřadit ke zdrojům z různých jednotek uvolňování, aby se provoz postupně přesunul na novější jednotku. Každý původ z jednotky uvolnění by měl mít přiřazenou stejnou hmotnost.

  2. Skupina původu pro rozhraní API, která je hostovaná ve službě Azure Kubernetes Service. Pokud existují jednotky vydaných verzí s různými verzemi rozhraní API, existuje skupina původu rozhraní API pro každou jednotku vydané verze. Pokud všechny jednotky vydaných verzí nabízejí stejné kompatibilní rozhraní API, všechny zdroje se přidají do stejné skupiny a přiřadí se různé váhy.

• pravidla směrování – Existují dva typy pravidel směrování:

  1. Pravidlo směrování pro uživatelské rozhraní propojené se skupinou původu úložiště uživatelského rozhraní.

  2. Pravidlo směrování pro každé rozhraní API aktuálně podporované zdroji Příklad: /api/1.0/* a /api/2.0/*.

  Pokud verze zavádí novou verzi back-endových rozhraní API, změny se projeví v uživatelském rozhraní, které je nasazené v rámci vydané verze. Konkrétní verze uživatelského rozhraní vždy volá konkrétní verzi adresy URL rozhraní API. Uživatelé obsluhovaní verzí uživatelského rozhraní automaticky používají příslušné back-endové rozhraní API. Pro různé instance verze rozhraní API jsou potřeba konkrétní pravidla směrování. Tato pravidla jsou propojená s odpovídajícími skupinami původu. Pokud nové rozhraní API nebylo zavedeno, všechna pravidla směrování související s rozhraním API odkazují na jednu skupinu původu. V tomto případě nezáleží na tom, jestli se uživateli obsluhuje uživatelské rozhraní z jiné verze než rozhraní API.

Nasazení: Proces nasazení

Jako přístup pro klíčové procesy nasazení používejte modré/zelené nasazení. Nasaďte nové verze do produkčních prostředí pomocí větví vydaných verzí. Postupně přesouvejte uživatelský provoz na instance nasazení v nové verzi.

Prvním krokem v procesu nasazení nové verze je nasazení infrastruktury pro novou verzi pomocí nástrojů pro infrastrukturní kódování, jako je Terraform. Spuštěním kanálu nasazení infrastruktury nasaďte novou infrastrukturu z vybrané větve vydané verze. Paralelně se zřizováním infrastruktury sestavte nebo naimportujte image kontejneru a nasdílejte je do globálně sdíleného registru kontejneru. Po dokončení předchozích procesů nasaďte aplikaci do razítek nasazení. Z pohledu procesu je to jeden kanál a jedno nasazení, ale proces má několik sekvenčních a paralelních fází.

Nejprve se odešle do geograficky replikovaného registru v domovské oblasti registru a pak se asynchronně replikuje do každé oblasti repliky. Dokud se replikace nedokončí, stažení z regionální instance může selhat s chybou manifest unknown, i když nahrání proběhlo úspěšně. Zahrňte do kroku nasazení aplikace mechanismus opakování s prodlevou nebo volání az acr replication list, aby byl odolný vůči tomuto oknu propagace, a zajistěte, aby kroky publikování byly idempotentní, takže opakování znovu nepřidá tag ani znovu nevytvoří artefakty s odlišnými digestry.

Po nasazení a ověření nové vydané jednotky se tato jednotka přidá do služby Front Door, aby přijímala uživatelský provoz.

Naplánujte přepínač či parametr, který rozlišuje mezi verzemi, které zavádějí novou verzi rozhraní API, a těmi, které to nezavádějí. Na základě toho, jestli verze zavádí novou verzi rozhraní API, vytvořte novou skupinu původu s back-endy rozhraní API. Alternativně můžete do existující skupiny původu přidat nové back-endy rozhraní API. Přidejte nové účty úložiště uživatelského rozhraní do odpovídající existující skupiny původu. Nastavte váhy pro nové zdroje tak, aby se dosáhlo požadovaného rozdělení provozu. Vytvořte nové pravidlo směrování, které odpovídá příslušné skupině původu.

V rámci přidání nové jednotky vydání by měly být váhy nových původů nastaveny na požadovanou minimální úroveň uživatelského provozu. Pokud se nezjistí žádné problémy, mělo by se během časového období zvýšit množství provozu uživatelů na novou skupinu původu. Pokud chcete upravit parametry hmotnosti, měli byste stejný postup nasazení provést znovu s požadovanými hodnotami.

Rozebrání jednotky

V rámci kanálu nasazení pro jednotku verze existuje fáze zničení, která odebere všechna razítka, jakmile už jednotku verze nepotřebujete. Veškerý provoz je přesunut do nové verze. Tato fáze zahrnuje odstranění odkazů na uvolněné jednotky ze služby Front Door. Toto odebrání je důležité pro povolení vydání nové verze později. Front Door musí odkazovat na jednu jednotku vydání, abychom mohli připravit další verzi v budoucnu.

Kontrolní seznamy

V rámci procesu vydávání verzí by se měl použít kontrolní seznam před a po vydání. Následující příklad je příkladem položek, které by měly být minimálně na každém kontrolním seznamu.

• Kontrolní seznam před vydáním – Před zahájením vydání zkontrolujte následující položky:

  • Ujistěte se, že byla nejaktuálnější verze větve main úspěšně nasazena a otestována v prostředí int.

  • Aktualizujte soubor protokolu změn prostřednictvím pull requestu ve větvi main.

  • Vytvořte release/ větev z větve main.

• Seznam úkolů po vydání – Než budou stará razítka zničena a jejich odkazy budou odstraněny ze služby Front Door, zkontrolujte, že:

  • Shluky již nepřijímají příchozí data.

  • Event Hubs a jiné fronty zpráv neobsahují žádné nezpracované zprávy.

Nasazení: Omezení a rizika strategie aktualizace

Strategie nasazení s modrou zelenou barvou pro klíčové úlohy má určitá omezení a rizika, která by se měla zvážit:

• Vyšší náklady – při vydávání aktualizací je mnoho komponent infrastruktury aktivních dvakrát po dobu vydání.

• Složitost služby Front Door – Proces aktualizace ve službě Front Door je složitý pro implementaci a údržbu. Schopnost efektivně provádět modrá/zelená nasazení s nulovými výpadky závisí na správném fungování.

• Malé změny časově náročné – proces aktualizace vede k delšímu procesu vydávání malých změn. Omezení lze částečně zmírnit pomocí dobře navrženého procesu hotfix.

Nasazení: Úvahy o kompatibilitě dat aplikací směrem do budoucnosti

Strategie aktualizace může podporovat více verzí rozhraní API a pracovních komponent spuštěných souběžně. Vzhledem k tomu, že se služba Azure Cosmos DB sdílí mezi dvěma nebo více verzemi, je možné, že datové prvky změněné jednou verzí nemusí vždy odpovídat verzi rozhraní API nebo pracovních procesů, které ho využívají. Vrstvy rozhraní API a pracovníci musí implementovat návrh kompatibility s budoucími verzemi. Starší verze rozhraní API nebo pracovních komponent zpracovávají data vložená novější verzí rozhraní API nebo pracovní součásti. Ignoruje části, kterým nerozumí.

Testování

Architektura obsahuje různé testy používané v různých fázích v rámci implementace testování.

Mezi tyto testy patří:

• Jednotkové testy – tyto testy ověřují, že obchodní logika aplikace funguje podle očekávání. Sada testů jednotek by se měla spustit automaticky před každým sestavením kontejneru službou Azure Pipelines. Pokud některý test selže, kanál se zastaví. Kompilace a uvedení do provozu se zastaví. Vývojář musí tento problém vyřešit, než bude možné potrubí spustit znovu.

• Zátěžové testy – Tyto testy pomáhají vyhodnotit kapacitu, škálovatelnost a potenciální úzká místa pro danou úlohu nebo stack. Generátor zatížení uživatele musí být použit k vytvoření syntetických vzorů zatížení, které lze použít k simulaci skutečného provozu.

• smoke testy – Tyto testy identifikují, zda je infrastruktura a úloha k dispozici a fungují podle očekávání. Kouřové testy se spouští jako součást každého nasazení.

• testy uživatelského rozhraní – tyto testy ověřují, že uživatelské rozhraní bylo nasazeno a funguje podle očekávání.

• testy injekce selhání – tyto testy je možné automatizovat nebo spouštět ručně. Automatizované testování v architektuře integruje Azure Chaos Studio jako součást kanálů nasazení.

Další informace najdete v tématu Nasazení a testování důležitých úloh na Azure: Průběžné ověřování a testování.

Testování: Architektury

Zvažte použití možností testování a architektur, jako jsou tyto.

.NET Framework	Zkouška	Popis
NUnit	Jednotka	Tato architektura se používá pro testování kódu .NET jednotek. Azure Pipelines provádí testy jednotek automaticky před sestaveními kontejnerů.
JMeter s využitím služby Azure Load Testing	Náklad	Azure Load Testing je spravovaná služba, která slouží ke spouštění definic Apache JMeter zátěžových testů.
Kobylka	Náklad	Locust je open-source framework pro zátěžové testování napsaný v Pythonu.
dramatik	Uživatelské rozhraní a kouř	Playwright je opensourcová knihovna Node.js pro automatizaci Chromium, Firefoxu a WebKitu pomocí jednoho rozhraní API.
Štúdio Chaosu Azure	Vkládání chyb	Azure Chaos Studio jako volitelný krok v procesu end-to-end ověřování pro simulaci chyb a testování odolnosti.

Testování: Testování vstřikování selhání a chaosového inženýrství

Distribuované aplikace by měly být odolné vůči výpadkům služeb a komponent. Testování injekce selhání (označované také jako injekce chyb nebo chaosové inženýrství) je praxe, při kterém jsou aplikace a služby vystaveny reálným stresům a selháním.

Odolnost je vlastnost celého systému a vkládání chyb pomáhá najít problémy v aplikaci. Řešení těchto problémů pomáhá ověřit odolnost aplikací vůči nespolehlivým podmínkám, chybějícím závislostem a dalším chybám.

Automatický

Tato architektura integruje Azure Chaos Studio k nasazení a spuštění sady experimentů Azure Chaos Studio, aby se na úrovni instance vnesly různé chyby. Experimenty chaosu je možné spustit jako volitelnou součást E2E nasazovacího potrubí. Při provádění testů se volitelný zátěžový test vždy spustí paralelně. Zátěžový test se používá pro vytvoření zatížení na clusteru a ověření účinku vstřiknutých chyb.

Manuál

Testování ruční simulace selhání by mělo být provedeno v prostředí pro end-to-end validaci. Toto prostředí zajišťuje úplné reprezentativní testy bez rizika zásahu z jiných prostředí. Většinu selhání vygenerovaných pomocí testů je možné pozorovat přímo v zobrazení metrik Application Insights Live. Zbývající chyby jsou k dispozici v zobrazení Chyby a odpovídajících tabulkách protokolu. Jiná selhání vyžadují podrobnější ladění, jako je použití kubectl k monitorování chování ve službě Azure Kubernetes Service.

Mezi dva příklady testů vkládání selhání provedených proti architektuře patří:

• DNS (Domain Name Service) – injekce selhání pomocí – testovací případ, který může simulovat více potíží. Selhání rozlišování DNS kvůli selhání serveru DNS nebo Azure DNS. Testování založené na DNS může pomoct simulovat obecné problémy s připojením mezi klientem a službou, například když se BackgroundProcessor nemůže připojit ke službě Event Hubs.

  Ve scénářích s jedním hostitelem můžete upravit místní soubor hosts tak, aby přepsal přesměrování DNS. Ve větším prostředí s dynamickými servery, jako je AKS, není hosts soubor praktický. Zóny Azure Privátní DNS lze použít jako alternativu pro testování scénářů selhání.

  Azure Event Hubs a Azure Cosmos DB jsou dvě služby Azure, které lze použít ke způsobování selhání založených na systému doménových jmen (DNS). Rozlišení DNS služby Event Hubs lze manipulovat pomocí zóny Azure Privátní DNS propojené s virtuální sítí jedné z instancí. Azure Cosmos DB je globálně replikovaná služba s konkrétními regionálními koncovými body. Manipulace se záznamy DNS pro tyto koncové body může simulovat selhání v konkrétní oblasti a otestovat převzetí služeb klientů při selhání.

• blokování brány firewall – Většina služeb Azure podporuje omezení přístupu brány firewall podle virtuálních sítí nebo IP adres. Tato omezení slouží k omezení přístupu ke službě Azure Cosmos DB nebo event Hubs. Jednoduchým postupem je odebrat existující pravidla Povolit nebo přidat nová pravidla Blokovat. Tento postup může simulovat chybné konfigurace brány firewall nebo výpadky služeb.

  Následující ukázkové služby v architektuře je možné testovat pomocí testu brány firewall:

  Služba	Výsledek
  Úložiště klíčů	Pokud je přístup ke službě Key Vault zablokovaný, nejpřímějším účinkem je selhání spuštění nových podů. Ovladač CSI služby Key Vault, který načítá tajné kódy při spuštění podu, nemůže provádět své úlohy a brání spuštění podu. U kubectl describe pod CatalogService-deploy-my-new-pod -n workloadlze pozorovat odpovídající chybové zprávy . Existující pody nadále fungují, i když se zobrazuje stejná chybová zpráva. Výsledky pravidelné kontroly aktualizace tajemství generují chybovou zprávu. I když není otestováno, nasazení nelze spustit, když je služba Key Vault nepřístupná. Úlohy Terraformu a Azure CLI během běhu pipelines provádí požadavky k službě Key Vault.
  Event Hubs	Pokud je přístup ke službě Event Hubs zablokovaný, nové zprávy odeslané službou CatalogService a HealthService selžou. Načítání zpráv procesem BackgroundProcess postupně selhávají, s konečným selháním do několika minut.
  Azure Cosmos DB	Odebrání stávající zásady brány firewall pro virtuální síť způsobí, že služba Health Service začne téměř okamžitě selhávat. Tento postup simuluje pouze konkrétní případ, celý výpadek služby Azure Cosmos DB. Většina případů selhání na regionální úrovni se automaticky zmírní transparentním přepnutím klienta do jiné oblasti Azure Cosmos DB. Dříve popsané testování vkládání chyb na základě DNS je smysluplnějším testem pro službu Azure Cosmos DB.
  Registr kontejnerů (ACR)	Když je přístup k ACR zablokovaný, vytváření nových podů, které se již načetly a uložily do mezipaměti na uzlu AKS, funguje dál. Vytvoření stále funguje díky příznaku nasazení K8spullPolicy=IfNotPresent. Uzly nemůžou vytvořit nový pod a operace se okamžitě nezdaří s chybami ErrImagePull , pokud uzel nepřetáhne image do mezipaměti před blokem. kubectl describe pod zobrazí odpovídající 403 Forbidden zprávu.
  Nástroj pro vyrovnávání zatížení příchozího přenosu dat AKS	Změna příchozích pravidel pro HTTP(S) (porty 80 a 443) ve spravované skupině zabezpečení sítě AKS (NSG) na zablokuje způsobí, že provoz sondy stavu nebo uživatelská data nedokáže dosáhnout do clusteru. Určení původní příčiny selhání tohoto testu je obtížné, protože test simuluje blokování mezi síťovou cestou služby Front Door a regionálním razítkem. Front Door okamžitě zjistí toto selhání a vyřadí identifikátor z provozu.

Další kroky

Kritické pro misi: Modelování zdraví