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. Zdravotní model může pomoci s vyhodnocením celkového zdravotního stavu tím, že zobrazuje jasný indikátor zdraví pracovní zátěže místo nezpracovaných metrik. Stav se často prezentuje jako indikátory podobné „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, na které lze reagovat, o problémech nebo výpadcích v infrastruktuře a aplikacích.
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.
Služba zdraví aplikace
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 nefunkční, služba Health Service nereaguje. 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. Pracovník na pozadí vyfiltruje zprávu.
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 razítko uvolněno pro účely údržby, může být soubor odstraněn, aby se vynutil nefunkční stav a přesměroval 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. Pokud model zdraví ukazuje, že instance je nezdravá, provoz by se neměl směrovat na tuto instance, i když ostatní testy prováděné HealthService jsou úspěšné. 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ů na službu Health Service. Každý hraniční uzel v každém datacentru Azure, který obsluhuje požadavky, volá službu Health Service, aby zjistil, zda má funkční 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 hledá 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é.
Výsledky kontroly jsou ukládány v paměti pomocí standardu, nedistribuovaného ASP.NET Core MemoryCache.
SysConfig.HealthServiceCacheDurationSeconds řídí vypršení platnosti mezipaměti. Výchozí nastavení je 10 sekund.
Poznámka:
Nastavení konfigurace SysConfig.HealthServiceCacheDurationSeconds snižuje dodatečné zatížení generované kontrolami stavu, protože ne všechny požadavky 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 |
|---|---|
| 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ě je používán jinými komponentami v systémovém modulu a je považován za kritický prostředek. 2. Ručně "vypněte" oblast odstraněním souboru stavu. Bylo provedeno rozhodnutí o návrhu, že kontrola by hledala pouze přítomnost stavového souboru v zadaném blob kontejneru. 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 ZDRAVÝ, NEZDRAVÝ a ÚDRŽBA. Odebrání stavového souboru zakáže razítko. Po nasazení aplikace se ujistěte, že je k dispozici soubor stavu. Nepřítomnost zdravotního souboru způsobí, že služba vždy odpoví NEFUNKČNÍ. Služba Front Door nerozpozná tento backend jako dostupný. Terraform vytvoří soubor a měl by být k dispozici po nasazení infrastruktury. |
| Centrum událostí | Zprávy o stavu služby Event Hubs zpracovávají EventHubProducerService. 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=TRUETato 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 pro Azure Cosmos DB zpracovává CosmosDbService, které hlásí, že jsou v pořádku, pokud jsou: 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 má krátkou dobu platnosti. 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 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 centrální úložiště pro protokoly a metriky pro všechny komponenty aplikací a infrastruktury. Azure Application 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 zdroje nesdílejí ž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 jsou identifikovány automaticky a přidány jako součást
terraform apply.Monitorování Kubernetes: Nastavení diagnostiky se používají 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 na každý uzel v clusterech AKS prostřednictvím DaemonSetu Kubernetes. 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 kritické pracovní zátěže, je možné použít sběr dat Prometheus. Výstřižky Prometheus konfigurují OMSAgentForLinux pro scrapování metrik Prometheus z různých koncových bodů v clusteru.
Sledování dat pomocí Application Insights: Application Insights se používá ke shromažďování sledovacích dat z aplikace. Kód se instrumentuje 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, doba trvání volání závislostí a čítače neošetřených výjimek. 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 razítek a celkového řešení z vnějšího pohledu, testy dostupnosti Application Insights jsou nastaveny na dvou místech:
Regionální testy dostupnosti: Tyto testy jsou nastavené v regionálních instancích Application Insights a používají se k monitorování dostupnosti testovacích bodů. Tyto testy přímo cílí na clustery a statické účty úložiště stampů. Pokud chcete přímo oslovit vstupní body clusterů, musí požadavky obsahovat správnou hlavičku ID Front Door, jinak řadič vstupu volání 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 v dotazovacím jazyce Kusto (KQL) k implementaci vlastních dotazů jako funkcí pro načítání dat z Log Analytics. Tyto dotazy jsou ukládány jako jednotlivé soubory v našem úložišti kódu, odděleně pro globální a stamp nasazení. Importují a použijí se automaticky prostřednictvím Terraformu jako součást každého spuštění 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
Používáme Grafanu k vizualizaci výsledků zdravotních dotazů Log Analytics v naší referenční implementaci. Grafana zobrazuje výsledky dotazů Log Analytics a neobsahuje žádnou logiku. Zásobník Grafana vydáváme odděleně od nasazovacího cyklu řešení.
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 je okamžitě informován o vlivu na obchodní úroveň stavu řešení: Koneckonců, tento kořenový uzel se změní na žlutou nebo červenou, pokud některý ze základních uživatelských toků 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í
Sestavení analýzy selhání je většinou teoretické plánovací cvičení. Toto teoretické cvičení by se mělo použít jako vstup pro automatizované injekce selhání, které jsou součástí nepřetržitého ověřovacího procesu. Simulací zde definovaných režimů selhání můžeme ověřit odolnost řešení proti těmto selháním, abychom minimalizovali výpadky.
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 | Vliv, 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 pro více oblastí 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. Stávající spuštěné komponenty by měly být schopné dál běžet, když dojde k problémům s ID Microsoft Entra. Je pravděpodobné, že nové pody nebo uzly AKS nelze 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 Azure DNS přestane být k dispozici, vyřešení DNS pro požadavky uživatelů a mezi jednotlivými komponentami aplikace selže. V současné době pro tento scénář neexistuje žádné možné zmírnění. Přístup pro více oblastí 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ě selže, neexistuje žádné řešení. Tato služba je silná 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. Nasazení změn ve službě Front Door trvá několik minut, což způsobuje výpadek. | Ú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 brá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, k tomu se přidává oprava a opětovné spuštění kanálu. | Ú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 nemá 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ů. | Ne |
| 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 mohou být určité instance vysoce vytíženy ve službě Azure Cosmos DB, zatímco jiné instance mohou obsluhovat více požadavků. Zmírnění: Lepší distribuce zatížení nebo více RU. | Ne |
| Azure Cosmos DB | Oddíl je plný | 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ý režim (zakázány zápisy do databáze) |
| Azure Container Registry | Regionální výpadek | Registr kontejnerů používá Traffic Manager k přepnutí mezi regiony repliky při selhání. Všechny požadavky by se měly automaticky směrovat do jiné oblasti. V nejhorším případě uzly AKS nestahují Docker image po dobu několika minut, zatímco probíhá přechod na záložní DNS. | Ne |
| Azure Container Registry | Obrázek nebo odstraněné obrázky | 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í: Pokud se problém rychle zjistí, opětovné spuštění nejnovějších kanálů buildu by mělo vrátit image zpět do registru.** | Ne |
| Azure Container Registry | Omezování | Omezování může zpozdit operace škálování, 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. | Ne |
| Azure Kubernetes Service | Selhání upgradu clusteru | Upgrady uzlů AKS by měly probíhat v různých časech napříč clustery. 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ů. | Ne |
| Azure Kubernetes Service | Pod aplikace je ukončen během vyřizování žádosti. | Výsledkem tohoto výsledku můžou být chyby koncového uživatele a špatné uživatelské prostředí. 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ží signál SIGTERM. Ten má odkladovou dobu pro dokončení otevřených požadavků a zápis 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. | Ne |
| Azure Kubernetes Service | Výpočetní kapacita není dostupná v oblasti pro přidání dalších uzlů. | Operace rozšíření/zmenšení může selhat, ale neměla by mít vliv na existující uzly a jejich činnost. V ideálním případě by se provoz měl automaticky přesunout do jiných oblastí pro vyrovnávání zatížení. | Ne |
| Azure Kubernetes Service | Předplatné dosáhne kvóty jader procesoru a přidá nové uzly. | Operace rozšíření/zmenšení může selhat, ale neměla by mít vliv na existující uzly a jejich činnost. V ideálním případě by se provoz měl automaticky přesunout do jiných oblastí pro vyrovnávání zatížení. | Ne |
| Azure Kubernetes Service | Pojďme zašifrovat certifikáty TLS/SSL, které nelze vydat nebo obnovit. | Cluster by měl hlásit nefunkčnost ke službě Front Door a provoz by se měl přesměrovat na jiné servery. Zmírnění: Přezkoumejte původní příčinu problému nebo obnovení selhání. | Ne |
| 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 | Obraz kontejneru třetích stran nebo registr není k dispozici. | Některé komponenty, jako je cert-manager a ingress-nginx, vyžadují stahování obrazů kontejnerů a Helm chartů 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í: V některých scénářích by mohlo být vhodné importovat image kontejnerů třetích stran doregistru kontejnerů pro řešení. Tento scénář zvyšuje složitost a měl by být pečlivě naplánován a zprovozněn. | Čá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. Zdravotní služba by měla tuto skutečnost automaticky rozpoznat a odstranit razítko z oběhu. | Ne |
| Centrum událostí | Zprávy nelze číst pomocí BackgroundProcessor | Seřazují se zprávy 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ě deaktivováno, dokud se problém nevyřeší. | Ne |
| Účet úložiště | Účet úložiště se stane pro pracovníka nepoužitelným pro checkpointing v rámci služby Event Hubs. | Stamp nezpracovává zprávy ze služby Event Hubs. Účet úložiště používá také HealthService. Služba HealthService detekuje problémy s úložištěm a měla by razítko odstranit z oběhu. Lze předpokládat, že současně ovlivní ostatní služby v systému. | Ne |
| Účet úložiště | Na statickém webu dochází k problémům. | Pokud na statickém webu dojde k problémům, služba Front Door zjistí toto selhání. Na tento účet úložiště se neodesílají žádná data. Ukládání do mezipaměti ve službě Front Door může tento problém zmírnit. | Ne |
| Key Vault | Key Vault není k dispozici pro operace GetSecret. |
Na začátku nových podů ovladač CSI pro AKS načte všechny tajné kódy ze služby Key Vault a selže. Není možné spustit pody. 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, ale pod stále funguje. |
Ne |
| Key Vault | Key Vault není k dispozici pro operace GetSecret nebo SetSecret. |
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. | Ne |
| Úložiště klíčů | Omezování služby Key Vault | Key Vault má limit 1 000 operací za 10 sekund. Kvůli automatické aktualizaci tajemství byste teoreticky mohli dosáhnout tohoto limitu, pokud byste měli v jednom clusteru mnoho (tisíce) podů. Možné zmírnění: Snižte frekvenci aktualizací ještě dál nebo ho úplně vypněte. | Ne |
| Aplikace | Chybná konfigurace | Nesprávné připojovací řetězce nebo tajemství vložené do aplikace. Zmírněny automatizovaným nasazením (kanál zpracovává konfiguraci automaticky) a modrým zeleným zaváděním aktualizací. | Ne |
| Aplikace | Platnost přihlašovacích údajů vypršela (razítkový zdroj) | 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 zvažováno v rámci referenční implementace. Zjistilo se, že Pod Identity v současné době není dostatečně stabilní a bylo rozhodnuto proti použití pro aktuální referenční architekturu. Identita podu by mohla být řešením do budoucna. | Ne |
| 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 současně způsobila pád všech razítek a vedla k výpadku v celém pracovním zatížení. 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íť | Adresní prostor IP podsítě je vyčerpán | Pokud dojde k vyčerpání adresního prostoru IP adres v podsíti, nemohou proběhnout žádné operace rozšíření, jako je vytváření nových uzlů AKS nebo podů. K výpadku nedojde, ale může snížit výkon, což může mít vliv na uživatele. Zmírnění: zvyšte adresní prostor IP (pokud je to možné). Pokud to není možnost, může pomoci zvýšit prostředky na uzel (větší SKU virtuálních počítačů) nebo na pod (více CPU/paměti), aby každý pod mohl zpracovat více provozu, a tím snížit potřebu škálování. | Ne |
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.