Modelování stavu pro klíčové úlohy

Monitorování aplikací a infrastruktury je důležitou součástí jakéhokoli nasazení infrastruktury. V případě klíčové úlohy je monitorování důležitou součástí nasazení. Monitorování stavu aplikace a klíčových metrik prostředků Azure vám pomůže pochopit, jestli prostředí funguje podle očekávání.

Abyste tyto metriky plně porozuměli a vyhodnotili celkový stav úlohy, je potřeba holistický přehled o všech monitorovaných datech. Model stavu může pomoct s vyhodnocením celkového stavu zobrazením jasného indikátoru stavu úlohy místo nezpracovaných metrik. Stav se často prezentuje jako indikátory "semaforu", jako je červená, zelená nebo žlutá. Reprezentace modelu stavu s jasnými indikátory umožňuje operátorovi intuitivně porozumět celkovému stavu úlohy a rychle reagovat na problémy, které nastanou.

Modelování stavu je možné rozšířit do následujících provozních úloh pro klíčové nasazení:

• Application Health Service – Komponenta aplikace ve výpočetním clusteru, která poskytuje rozhraní API pro určení stavu razítka.

• Monitorování – shromažďování čítačů výkonu a aplikací, které vyhodnocují stav a výkon aplikace a infrastruktury.

• Upozorňování – výstrahy s možností použití problémů nebo výpadků v infrastruktuře a aplikaci

• Analýza selhání – rozpis a analýza všech selhání, včetně dokumentace původní příčiny

Tyto úlohy tvoří komplexní zdravotní model pro kritickou infrastrukturu. Vývoj modelu stavu může a měl by být vyčerpávajícím a nedílnou součástí jakéhokoli klíčového nasazení.

Další informace najdete v tématu Modelování stavu a pozorovatelnost důležitých úloh v Azure.

Application Health Service

Application Health Service (HealthService) je komponenta aplikace, která se nachází ve službě Catalog Service (CatalogService) a procesoru na pozadí (BackgroundProcessor) v rámci výpočetního clusteru. Služba HealthService poskytuje rozhraní REST API pro Službu Azure Front Door k volání za účelem určení stavu razítka. HealthService je složitá komponenta, která kromě vlastního stavu odráží stav závislostí.

Když je výpočetní cluster spuštěný, služba Health Service nebude reagovat. Když jsou služby v provozu, provádí pravidelné kontroly s následujícími komponentami v infrastruktuře:

• Pokusí se provést dotaz na službu Azure Cosmos DB.

• Pokusí se odeslat zprávu do služby Event Hubs. Zpráva je odfiltrována pracovníkem na pozadí.

• Vyhledá stavový soubor v účtu úložiště. Tento soubor lze použít k vypnutí oblasti, i když ostatní kontroly stále fungují správně. Tento soubor lze použít ke komunikaci s jinými procesy. Například pokud má být kolek uvolněn pro účely údržby, může být soubor odstraněn, aby se vynutil stav, který není v pořádku, a směrovat provoz.

• Dotazuje se na model stavu a určí, jestli jsou všechny provozní metriky v rámci předem určených prahových hodnot. Když model stavu značí, že kolek není v pořádku, provoz by se neměl směrovat na kolek, i když ostatní testy HealthService úspěšně vrátí. Model stavu bere v úvahu úplnější přehled o stavu.

Všechny výsledky kontroly stavu se ve výchozím nastavení ukládají do mezipaměti v paměti po dobu konfigurovatelného počtu sekund, a to ve výchozím nastavení 10. Tato operace potenciálně přidává malou latenci při zjišťování výpadků, ale zajišťuje, že každý dotaz HealthService nevyžaduje back-endová volání, čímž snižuje zatížení clusteru a podřízených služeb.

Tento vzor ukládání do mezipaměti je důležitý, protože při použití globálního směrovače, jako je Azure Front Door, výrazně roste počet dotazů HealthService: Každý hraniční uzel v každém datacentru Azure, který obsluhuje požadavky, zavolá službu Health Service, aby určila, jestli má funkční back-endové připojení. Ukládání výsledků do mezipaměti snižuje zatížení clusteru generované kontrolami stavu.

Konfigurace

Služba HealthService a CatalogService mají společná nastavení konfigurace mezi komponentami s výjimkou následujících nastavení používaných výhradně službou HealthService:

Nastavení	Hodnota
HealthServiceCacheDurationSeconds	Určuje dobu vypršení platnosti mezipaměti paměti v sekundách.
HealthServiceStorageConnectionString	Připojovací řetězec pro účet úložiště, kde se má zobrazit stavový soubor.
HealthServiceBlobContainerName	Kontejner úložiště, ve kterém by se měl zobrazit stavový soubor.
HealthServiceBlobName	Název stavového souboru – kontrola stavu bude hledat tento soubor.
HealthServiceOverallTimeoutSeconds	Časový limit pro celou kontrolu – výchozí hodnota je 3 sekundy. Pokud se kontrola v tomto intervalu nedokončí, služba hlásí, že není v pořádku.

Implementace

Všechny kontroly se provádějí asynchronně a paralelně. Pokud některý z nich selže, bude celé razítko považováno za nedostupné.

Zkontrolujte, jestli se výsledky ukládají do mezipaměti pomocí standardního, nedistribuovaného ASP.NET Core MemoryCache. Vypršení platnosti mezipaměti je řízeno SysConfig.HealthServiceCacheDurationSeconds a ve výchozím nastavení je nastavené na 10 sekund.

Poznámka:

Nastavení SysConfig.HealthServiceCacheDurationSeconds konfigurace snižuje další zatížení generované kontrolami stavu, protože ne každý požadavek způsobí podřízené volání závislých služeb.

Následující tabulka obsahuje podrobnosti o kontrolách stavu komponent v infrastruktuře:

Komponenta	Kontrola stavu
Objekt blob účtu úložiště	Kontrola objektu blob aktuálně slouží ke dvěma účelům: 1. Otestujte, jestli je možné se spojit se službou Blob Storage. Účet úložiště používá jiné komponenty v razítku a považuje se za kritický prostředek. 2. Ručně "vypněte" oblast odstraněním souboru stavu. Bylo provedeno rozhodnutí o návrhu, že kontrola bude hledat pouze přítomnost souboru stavu v zadaném kontejneru objektů blob. Obsah souboru se nezpracuje. Existuje možnost nastavit sofistikovanější systém, který čte obsah souboru a vrací jiný stav na základě obsahu souboru. Příklady obsahu jsou V POŘÁDKU, NENÍ V POŘÁDKU a ÚDRŽBA. Odebrání stavového souboru zakáže kolek. Po nasazení aplikace se ujistěte, že je k dispozici soubor stavu. Absence souboru stavu způsobí, že služba vždy odpoví chybným stavem. Front Door nerozpozná back-end jako dostupný. Soubor je vytvořený Terraformem a měl by být k dispozici po nasazení infrastruktury.
Centrum událostí	Generování sestav stavu služby Event Hubs zpracovává EventHubProducerServiceslužba . Tato služba hlásí, jestli je schopná odeslat novou zprávu do služby Event Hubs. Pro filtrování má tato zpráva přidanou identifikační vlastnost: HEALTHCHECK=TRUE Tato zpráva je ignorována na přijímajícím konci. Nastavení AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() konfigurace kontroluje HEALTHCHECK vlastnost.
Azure Cosmos DB	Generování sestav stavu služby Azure Cosmos DB zpracovává sestavy CosmosDbService, které jsou v pořádku, pokud je: 1. Můžete se připojit k databázi Azure Cosmos DB a provést dotaz. 2. Do databáze můžete napsat testovací dokument. Testovací dokument obsahuje krátkou sadu Time to Live a Azure Cosmos DB ji automaticky odebere. HealthService provádí dvě samostatné sondy. Pokud je služba Azure Cosmos DB ve stavu, kdy čtení funguje a zapisuje ne, obě sondy zajistí aktivaci výstrahy.

Dotazy azure Cosmos DB

Pro dotaz jen pro čtení se používá následující dotaz, který nenačítá žádná data a nemá velký vliv na celkové zatížení:

SELECT GetCurrentDateTime ()

Dotaz pro zápis vytvoří fiktivní ItemRating dotaz s minimálním obsahem:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Sledování

Azure Log Analytics se používá jako protokoly a metriky centrálního úložiště pro všechny komponenty aplikace a infrastruktury. Aplikace Azure lication Insights se používá pro všechna data monitorování aplikací. Každé razítko v infrastruktuře má vyhrazený pracovní prostor služby Log Analytics a instanci Application Insights. Samostatný pracovní prostor služby Log Analytics se používá pro globálně sdílené prostředky, jako jsou Front Door a Azure Cosmos DB.

Všechny známky jsou krátkodobé a průběžně nahrazené jednotlivými novými verzemi. Pracovní prostory Log Analytics podle razítka se nasazují jako globální prostředek v samostatné skupině prostředků monitorování jako prostředky Log Analytics s razítkem. Tyto prostředky nesdílely životní cyklus razítka.

Další informace najdete v tématu Sjednocená jímka dat pro korelaci analýzy.

Monitorování: Zdroje dat

• Nastavení diagnostiky: Všechny služby Azure používané pro Azure Mission-Critical jsou nakonfigurované tak, aby odesílaly všechna diagnostická data včetně protokolů a metrik do pracovního prostoru služby Log Analytics specifického pro nasazení (globální nebo razítko). Tento proces probíhá automaticky jako součást nasazení Terraformu. Nové možnosti budou identifikovány automaticky a přidány jako součást terraform apply.

• Monitorování Kubernetes: Nastavení diagnostiky slouží k odesílání protokolů a metrik služby Azure Kubernetes Service (AKS) do Log Analytics. Služba AKS je nakonfigurovaná tak, aby používala Službu Container Insights. Container Insights nasadí OMSAgentForLinus prostřednictvím daemonSet Kubernetes na každý uzel v clusterech AKS. OMSAgentForLinux dokáže shromažďovat další protokoly a metriky z clusteru Kubernetes a odesílat je do příslušného pracovního prostoru služby Log Analytics. Tyto další protokoly a metriky obsahují podrobnější data o podech, nasazeních, službách a celkovém stavu clusteru. Pokud chcete získat další přehled o různých komponentách, jako je ingress-nginx, cert-manager a další komponenty nasazené do Kubernetes vedle klíčové úlohy, je možné použít výstřižky Prometheus. Výstřižky Prometheus konfigurují OMSAgentForLinux pro scrapování metrik Prometheus z různých koncových bodů v clusteru.

• Telemetrie Application Insights: Application Insights se používá ke shromažďování telemetrických dat z aplikace. Kód byl instrumentován ke shromažďování dat o výkonu aplikace pomocí sady Application Insights SDK. Shromažďují se důležité informace, například výsledný stavový kód a doba trvání volání závislostí a čítačů pro neošetřené výjimky. Tyto informace se používají v modelu stavu a jsou k dispozici pro upozorňování a řešení potíží.

Monitorování: Testy dostupnosti Application Insights

Pokud chcete monitorovat dostupnost jednotlivých kolek a celkového řešení z vnějšího pohledu, nastaví se testy dostupnosti Application Insights na dvou místech:

• Testy dostupnosti v jednotlivých oblastech: Tyto testy jsou nastavené v místních instancích Application Insights a používají se k monitorování dostupnosti kolků. Tyto testy cílí na clustery a statické účty úložiště kolků přímo. Pokud chcete přímo volat body příchozího přenosu dat clusterů, musí požadavky obsahovat správnou hlavičku ID služby Front Door, jinak kontroler příchozího přenosu dat odmítne.

• Globální test dostupnosti: Tyto testy jsou nastavené v globální instanci Application Insights a používají se k monitorování dostupnosti celkového řešení příkazem ping služby Front Door. Používají se dva testy: Jeden k otestování volání rozhraní API pro CatalogService a jeden k otestování domovské stránky webu.

Monitorování: Dotazy

Azure Mission-Critical používá různé dotazy dotazovací jazyk Kusto (KQL) k implementaci vlastních dotazů jako funkcí pro načítání dat z Log Analytics. Tyto dotazy se ukládají jako jednotlivé soubory v našem úložišti kódu oddělené pro globální nasazení a nasazení kolků. Importují se a použijí se automaticky prostřednictvím Terraformu jako součást každého spuštění kanálu infrastruktury.

Tento přístup odděluje logiku dotazu od vrstvy vizualizace. Dotazy Log Analytics se volají přímo z kódu, například z rozhraní HEALTHService API. Dalším příkladem je nástroj pro vizualizaci, jako jsou Řídicí panely Azure, Monitor Workbooks nebo Grafana.

Monitorování: Vizualizace

K vizualizaci výsledků dotazů na stav Log Analytics jsme v referenční implementaci použili Grafana. Grafana se používá k zobrazení výsledků dotazů Log Analytics a neobsahuje žádnou logiku samotnou. Zásobník Grafana není součástí životního cyklu nasazení řešení, ale vydává se samostatně.

Další informace najdete v tématu Vizualizace.

Upozorňování

Výstrahy jsou důležitou součástí celkové provozní strategie. Proaktivní monitorování, jako je použití řídicích panelů, by se mělo používat s výstrahami, které vyvolávají okamžitou pozornost k problémům.

Tyto výstrahy tvoří rozšíření modelu stavu tím, že operátora upozorní na změnu stavu, a to buď na snížený nebo žlutý stav, nebo na stav není v pořádku nebo červený stav. Když nastavíte výstrahu na kořenový uzel modelu stavu, operátor okamžitě ví o všech obchodních úrovních vliv na stav řešení: Koneckonců se tento kořenový uzel změní na žlutou nebo červenou, pokud některý z podkladových toků uživatelů nebo prostředků hlásí žluté nebo červené metriky. Operátor může při řešení potíží nasměrovat pozornost na vizualizaci modelu stavu.

Další informace najdete v tématu Automatizovaná reakce na incidenty.

Analýza selhání

Vytvoření analýzy selhání je převážně teoretická plánování. Toto teoretické cvičení by se mělo použít jako vstup pro automatizované injektáže selhání, které jsou součástí procesu průběžného ověřování. Simulací zde definovaných režimů selhání můžeme ověřit odolnost řešení proti těmto selháním, abychom zajistili, že nedojde k výpadkům.

Následující tabulka uvádí příklady případů selhání různých komponent referenční implementace Azure Mission-Critical.

Služba	Riziko	Dopad, zmírnění rizik nebo komentář	Výpadek
Microsoft Entra ID	ID Microsoft Entra přestane být k dispozici.	V současné době neexistuje žádné možné zmírnění rizik. Přístup s více oblastmi nezmírní žádné výpadky, protože se jedná o globální službu. Tato služba je tvrdá závislost. Id Microsoft Entra se používá pro operace řídicí roviny, jako je vytvoření nových uzlů AKS, vyžádání imagí kontejnerů z ACR nebo přístup ke službě Key Vault při spuštění podu. Očekává se, že stávající spuštěné komponenty by měly být schopné běžet, když u ID Microsoft Entra dochází k problémům. Je pravděpodobné, že nové pody nebo uzly AKS nebudou moct vytvořit. Operace škálování jsou během této doby potřeba, což může vést ke snížení uživatelského prostředí a potenciálně k výpadkům.	Částečná
Azure DNS	Azure DNS přestane být dostupný a překlad DNS selže.	Pokud se Azure DNS stane nedostupným, překlad DNS pro požadavky uživatelů a mezi různými komponentami aplikace pravděpodobně selže. V současné době pro tento scénář neexistuje žádné možné zmírnění. Přístup s více oblastmi nezmírní žádné výpadky, protože se jedná o globální službu. Azure DNS je tvrdá závislost. Externí služby DNS jako zálohování by nepomohly, protože všechny komponenty PaaS, které se používaly, spoléhají na Azure DNS. Obejití DNS přepnutím na IP adresu není možnost. Služby Azure nemají statické a garantované IP adresy.	Úplný
Dveří	Obecný výpadek služby Front Door.	Pokud služba Front Door úplně klesne, neexistuje žádné omezení rizik. Tato služba je tvrdá závislost.	Ano
Dveří	Chyby konfigurace směrování, front-endu nebo back-endu	Může k tomu dojít kvůli neshodě konfigurace při nasazování. Měly by být zachyceny ve fázích testování. Konfigurace front-endu s DNS je specifická pro každé prostředí. Zmírnění rizik: Vrácení zpět na předchozí konfiguraci by mělo většinu problémů vyřešit. Vzhledem k tomu, že nasazení změn ve službě Front Door trvá několik minut, dojde k výpadku.	Úplný
Dveří	Spravovaný certifikát TLS/SSL se odstraní.	Může k tomu dojít kvůli neshodě konfigurace při nasazování. Měly by být zachyceny ve fázích testování. Technicky vzato by web stále fungoval, ale chyby certifikátů TLS/SSL zabrání uživatelům v přístupu k němu. Zmírnění: Opětovné vydání certifikátu může trvat přibližně 20 minut a navíc může kanál opravit a znovu spustit.	Úplný
Azure Cosmos DB	Databáze nebo kolekce se přejmenuje.	Může k tomu dojít kvůli neshodě konfigurace při nasazování – Terraform by přepsal celou databázi, což by mohlo vést ke ztrátě dat. Ztrátě dat je možné zabránit pomocí zámků na úrovni databáze nebo kolekce. Aplikace nebude mít přístup k žádným datům. Je potřeba aktualizovat konfiguraci aplikace a restartovat pody.	Ano
Azure Cosmos DB	Regionální výpadek	Služba Azure Mission-Critical má povolené zápisy do více oblastí. Pokud dojde k selhání čtení nebo zápisu, klient opakuje aktuální operaci. Všechny budoucí operace se trvale směrují do další oblasti v pořadí podle preference. V případě, že seznam předvoleb obsahoval jednu položku (nebo byl prázdný), ale účet má k dispozici další oblasti, bude směrovat do další oblasti v seznamu účtů.	No
Azure Cosmos DB	Rozsáhlé omezování kvůli nedostatku RU.	V závislosti na počtu RU a vyrovnávání zatížení použitém na úrovni služby Front Door můžou určité kolky běžet na využití služby Azure Cosmos DB za provozu, zatímco jiné kolky můžou obsluhovat více požadavků. Zmírnění: Lepší distribuce zatížení nebo více RU.	No
Azure Cosmos DB	Celý oddíl	Limit velikosti logického oddílu služby Azure Cosmos DB je 20 GB. Pokud data pro klíč oddílu v rámci kontejneru dosáhnou této velikosti, další požadavky na zápis selžou s chybou Klíč oddílu dosáhl maximální velikosti.	Částečné (zakázané zápisy databáze)
Azure Container Registry	Regionální výpadek	Registr kontejnerů používá Traffic Manager k převzetí služeb při selhání mezi oblastmi repliky. Všechny požadavky by se měly automaticky směrovat do jiné oblasti. V nejhorším případě nejde image Dockeru během převzetí služeb při selhání DNS načíst několik minut uzly AKS.	No
Azure Container Registry	Odstraněné image	Nelze načíst žádné obrázky. Tento výpadek by měl mít vliv jenom na nově vytvářené nebo restartované uzly. Existující uzly by měly mít image uložené v mezipaměti. **Zmírnění rizik: Pokud se zjistilo, že se rychle znovu spustí nejnovější kanály buildu, měly by se image vrátit zpět do registru.	No
Azure Container Registry	Omezování	Omezování může zpozdit operace horizontálního navýšení kapacity, což může vést k dočasnému snížení výkonu. Zmírnění: Azure Mission-Critical používá skladovou položku Premium, která poskytuje 10 tisíc operací čtení za minutu. Image kontejnerů jsou optimalizované a mají pouze malý počet vrstev. ImagePullPolicy je nastavena na IfNotPresent pro použití místně uložených verzí v mezipaměti jako první. Komentář: Vyžádání image kontejneru se skládá z několika operací čtení v závislosti na počtu vrstev. Počet operací čtení za minutu je omezený a závisí na velikosti skladové položky ACR.	No
Azure Kubernetes Service	Selhání upgradu clusteru	Upgrady uzlů AKS by měly probíhat v různých časech napříč kolky. Pokud jeden upgrade selže, neměl by to mít vliv na druhý cluster. Upgrady clusteru by se měly nasazovat postupně napříč uzly, aby se zabránilo nedostupnosti všech uzlů.	No
Azure Kubernetes Service	Pod aplikace se ukončí při obsluhování žádosti.	To může vést k chybám a špatnému uživatelskému prostředí koncového uživatele. Zmírnění: Kubernetes ve výchozím nastavení odebere pody elegantním způsobem. Pody se nejprve odeberou ze služeb a úloha obdrží SIGTERM s obdobím odkladu pro dokončení otevřených požadavků a zápisu dat před ukončením. Kód aplikace musí pochopit SIGTERM a období odkladu může být potřeba upravit, pokud ukončení úlohy trvá déle.	No
Azure Kubernetes Service	Výpočetní kapacita není dostupná v oblasti pro přidání dalších uzlů.	Operace vertikálního navýšení/snížení kapacity selžou, ale neměly by mít vliv na existující uzly a jejich operace. V ideálním případě by se provoz měl automaticky přesunout do jiných oblastí pro vyrovnávání zatížení.	No
Azure Kubernetes Service	Předplatné dosáhne kvóty jader procesoru a přidá nové uzly.	Operace vertikálního navýšení/snížení kapacity selžou, ale neměly by mít vliv na existující uzly a jejich operace. V ideálním případě by se provoz měl automaticky přesunout do jiných oblastí pro vyrovnávání zatížení.	No
Azure Kubernetes Service	Pojďme zašifrovat certifikáty TLS/SSL, které nelze vydat nebo obnovit.	Cluster by měl hlásit, že není v pořádku směrem ke službě Front Door a provoz by se měl přesunout na jiné kolky. Zmírnění: Prozkoumejte původní příčinu problému nebo selhání obnovení.	No
Azure Kubernetes Service	Pokud jsou požadavky na prostředky nebo limity nakonfigurované nesprávně, mohou pody dosáhnout 100% využití procesoru a neúspěšných požadavků. Mechanismus opakování aplikace by měl být schopný obnovit neúspěšné požadavky. Opakování může způsobit delší dobu trvání požadavku, aniž by se zobrazila chyba klientovi. Nadměrné zatížení nakonec způsobí selhání.	Ne (pokud zatížení není nadměrné)
Azure Kubernetes Service	Image kontejnerů třetích stran / registr nejsou k dispozici	Některé komponenty, jako je cert-manager a ingress-nginx, vyžadují stahování imagí kontejnerů a chartů Helm z externích registrů kontejnerů (odchozí provoz). V případě nedostupnosti jednoho nebo více těchto úložišť nebo imagí nemusí být možné spustit nové instance na nových uzlech (kde image ještě není uložená v mezipaměti). Možné zmírnění rizik: V některých scénářích by mohlo být vhodné importovat image kontejnerů třetích stran do registru kontejnerů pro jednotlivé řešení. To zvyšuje složitost a mělo by být pečlivě naplánováno a zprovozněno.	Částečně (během operací škálování a aktualizace/upgradu)
Centrum událostí	Zprávy nejde odeslat do služby Event Hubs	Razítko se stane nepoužitelným pro operace zápisu. Služba Health Service by to měla automaticky rozpoznat a vyřídit razítko z obměně.	No
Centrum událostí	Objekt BackgroundProcessor nemůže číst zprávy	Zprávy se zařadí do fronty. Zprávy by se neměly ztratit, protože jsou trvalé. V současné době tato chyba není pokryta službou Health Service. U pracovního procesu by mělo být zavedeno monitorování nebo upozorňování, aby se zjistily chyby při čtení zpráv. Zmírnění: Razítko by mělo být ručně zakázáno, dokud se problém nevyřeší.	No
Účet úložiště	Účet úložiště se stane nepoužitelným pracovním procesem pro kontrolu služby Event Hubs.	Razítko nezpracuje zprávy ze služby Event Hubs. Účet úložiště používá také HealthService. Služba HealthService by měla zjistit očekávané problémy s úložištěm a razítko by se mělo vyřadit z rotace. Dá se očekávat, že budou souběžně ovlivněny další služby v kolku.	No
Účet úložiště	Na statickém webu dochází k problémům.	Pokud služba obsluhy statického webu narazí na problémy, měla by tato chyba být zjištěna službou Front Door. Provoz se do tohoto účtu úložiště neodesílají. Ukládání do mezipaměti ve službě Front Door může tento problém zmírnit.	No
Key Vault	Key Vault není k dispozici pro GetSecret operace.	Na začátku nových podů ovladač AKS CSI načte všechny tajné kódy ze služby Key Vault a selže. Pody se nebudou moct spustit. V současné době probíhá automatická aktualizace každých 5 minut. Aktualizace se nezdaří. Chyby by se měly zobrazit v kubectl describe pod podu, ale pořád funguje.	No
Key Vault	Key Vault není k dispozici pro GetSecret operace nebo SetSecret operace.	Nová nasazení se nedají spustit. V současné době může toto selhání způsobit zastavení celého kanálu nasazení, a to i v případě, že je ovlivněna pouze jedna oblast.	No
Key Vault	Omezování služby Key Vault	Key Vault má limit 1 000 operací za 10 sekund. Kvůli automatické aktualizaci tajných kódů byste teoreticky dosáhli tohoto limitu, pokud byste měli v kolku mnoho (tisíc) podů. Možné zmírnění: Snižte frekvenci aktualizací ještě dál nebo ho úplně vypněte.	No
Aplikace	Chybná konfigurace	Nesprávné připojovací řetězec nebo tajné kódy vložené do aplikace. Mělo by se zmírnit automatizovaným nasazením (kanál zpracovává konfiguraci automaticky) a modrým zeleným zaváděním aktualizací.	No
Aplikace	Vypršela platnost přihlašovacích údajů (prostředek razítka)	Pokud se například token SAS centra událostí nebo klíč účtu úložiště změnil bez správné aktualizace ve službě Key Vault, aby je pody mohly používat, příslušná komponenta aplikace selže. Tato chyba by pak měla mít vliv na službu Health Service a razítko by se mělo automaticky vysunout z rotace. Zmírnění: Pro všechny služby, které ho podporují, použijte ověřování založené na ID microsoftu Entra. AKS vyžaduje, aby se pody ověřily pomocí ID úloh Microsoft Entra (Preview). Použití identity podu bylo považováno za referenční implementaci. Zjistilo se, že identita podu v současné době není dostatečně stabilní a byla rozhodnuto o použití pro aktuální referenční architekturu. Identita podu může být v budoucnu řešením.	No
Aplikace	Přihlašovací údaje s vypršenou platností (globálně sdílený prostředek)	Pokud se například klíč rozhraní API služby Azure Cosmos DB změnil bez správné aktualizace ve všech trezorech klíčů s razítkem, aby je pody mohly používat, příslušné komponenty aplikace selžou. Tato chyba by přinesla všechny kolky najednou a způsobila výpadek pro celou úlohu. Možný způsob, jak obejít potřebu klíčů a tajných kódů pomocí ověřování Microsoft Entra, najdete v předchozí položce.	Úplný
Virtuální síť	Nevyčerpal se adresní prostor IP podsítě	Pokud dojde k vyčerpání adresního prostoru IP adres v podsíti, nedochází k žádným operacím horizontálního navýšení kapacity, jako je vytváření nových uzlů AKS nebo podů. Nebude to vést k výpadku, ale může snížit výkon a ovlivnit uživatelské prostředí. Zmírnění: zvyšte prostor IP adres (pokud je to možné). Pokud to není možnost, může pomoct zvýšit prostředky na uzel (větší skladové položky virtuálních počítačů) nebo na pod (více procesorů a paměti), aby každý pod mohl zpracovávat více přenosů, čímž se snižuje potřeba horizontálního navýšení kapacity.	No

Další kroky

Nasaďte referenční implementaci, abyste získali úplný přehled o prostředcích a jejich konfiguraci používaných v této architektuře.

Implementace: Klíčové online