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 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 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ů na HealthService: Každý hraniční uzel v každém datacentru Azure, který obsluhuje požadavky, volá službu Health Service, aby zjistily, jestli mají funkční připojení ke službě Health Service. 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 |
|---|---|
| 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. rozhodnutí o návrhu bylo provedeno, že kontrola by hledala pouze přítomnost stavového souboru 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 razítko. Po nasazení aplikace se ujistěte, že je k dispozici soubor stavu. Absence zdravotního souboru způsobí, že služba vždy odpoví NENÍ V POŘÁDKU. 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átký čas do vypršení 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 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 jsou 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.
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 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 vstupní body clusterů, požadavky musí obsahovat správnou hlavičku ID služby 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 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
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 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 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 se nedají 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ě 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. 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 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 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ů. | 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ě uzly AKS nestahují Docker image po dobu několika minut, zatímco probíhá přechod na záložní DNS. | No |
| 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í 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. | 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ží 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 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í. | No |
| Azure Kubernetes Service | Předplatné dosáhne kvóty jader procesoru a přidá nové uzly. | Operace škálování nahoru/ven selžou, ale neměly by ovlivnit existující uzly a jejich provoz. 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í: 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. 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 | 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ě 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. | 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. | No |
| Úč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í. Provoz se na tento účet úložiště neodesílá. 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č CSI pro AKS načte všechny tajné kódy ze služby Key Vault a selže. Pody se nedají 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. Zmírněny 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, 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 prostor IP adres (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í. | 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.