Gezondheidsmodellering voor bedrijfskritieke workloads

De bewaking van toepassingen en infrastructuur is een belangrijk onderdeel van elke infrastructuurimplementatie. Voor een bedrijfskritieke workload is bewaking een essentieel onderdeel van de implementatie. Door toepassingsstatus en belangrijke metrische gegevens van Azure-resources te bewaken, kunt u zien of de omgeving werkt zoals verwacht.

Om deze metrische gegevens volledig te begrijpen en de algehele status van een workload te evalueren, is een holistisch begrip van alle bewaakte gegevens vereist. Een statusmodel kan helpen bij de evaluatie van de algehele status door een duidelijke indicatie weer te geven van de status van de workload in plaats van onbewerkte metrische gegevens. De status wordt vaak weergegeven als 'verkeerslichtindicatoren', zoals rood, groen of geel. Weergave van een statusmodel met duidelijke indicatoren maakt het intuïtief voor een operator om de algehele status van de workload te begrijpen en snel te reageren op problemen die zich voordoen.

Statusmodellering kan worden uitgebreid naar de volgende operationele taken voor de bedrijfskritieke implementatie:

• Application Health Service : toepassingsonderdeel op het rekencluster dat een API biedt om de status van een stempel te bepalen.

• Monitoring - verzameling van prestatie- en toepassingscounters die de gezondheid en prestaties van de toepassing en infrastructuur evalueren.

• Waarschuwingen: bruikbare waarschuwingen voor problemen of storingen in de infrastructuur en toepassing.

• Foutanalyse - Uitsplitsing en analyse van eventuele fouten, inclusief documentatie over de hoofdoorzaak.

Deze taken vormen een uitgebreid gezondheidsmodel voor de bedrijfskritieke infrastructuur. De ontwikkeling van een gezondheidsmodel kan en moet een volledig en integraal onderdeel zijn van elke bedrijfskritieke implementatie.

Zie Statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure voor meer informatie.

Applicatie Gezondheidsdienst

Application Health Service (HealthService) is een toepassingsonderdeel dat zich in het rekencluster bevindt met de catalogusservice (CatalogService) en de achtergrondprocessor (BackgroundProcessor). HealthService biedt een REST API voor Azure Front Door om de status van een stempel te bepalen. De HealthService is een complex onderdeel dat de status van afhankelijkheden weerspiegelt, naast zijn eigen.

Wanneer het rekencluster niet beschikbaar is, reageert de health-service niet. Wanneer de services actief zijn, worden periodieke controles uitgevoerd op de volgende onderdelen in de infrastructuur:

• Er wordt geprobeerd een query uit te voeren op Azure Cosmos DB.

• Er wordt geprobeerd een bericht naar Event Hubs te verzenden. De achtergrondmedewerker filtert het bericht uit.

• In het opslagaccount wordt een statusbestand opgezocht. Dit bestand kan worden gebruikt om een regio uit te schakelen, zelfs als de andere controles nog steeds correct werken. Dit bestand kan worden gebruikt om te communiceren met andere processen. Als het bijvoorbeeld nodig is om de stamp voor onderhoud te verwijderen, kan het bestand worden verwijderd om een ongezonde status te veroorzaken en verkeer om te leiden.

• Er wordt een query uitgevoerd op het statusmodel om te bepalen of alle operationele metrische gegevens binnen de vooraf vastgestelde drempelwaarden vallen. Wanneer het gezondheidsmodel aangeeft dat de stempel ongezond is, mag het verkeer niet naar de stempel worden geleid, zelfs als de andere tests die de HealthService uitvoert succesvol worden doorgegeven. Het Gezondheidsmodel neemt een vollediger beeld van de gezondheidsstatus in beschouwing.

Alle gezondheidscontroleresultaten worden gedurende een configureerbaar aantal seconden in de cache opgeslagen, standaard 10. Deze bewerking voegt mogelijk een kleine latentie toe bij het detecteren van storingen, maar zorgt ervoor dat niet elke HealthService-query back-end-aanroepen vereist, waardoor de belasting van het cluster en downstreamservices wordt verminderd.

Dit cachepatroon is belangrijk, omdat het aantal HealthService-query's aanzienlijk toeneemt bij het gebruik van een globale router zoals Azure Front Door: Elk edge-knooppunt in elk Azure-datacenter dat aanvragen doet, roept de Health Service aan om te bepalen of deze een functionele back-endverbinding heeft. Het opslaan van de resultaten vermindert extra clusterbelasting die wordt gegenereerd door statuscontroles.

Configuratie

De HealthService en de CatalogService hebben configuratie-instellingen die gemeenschappelijk zijn tussen de onderdelen, met uitzondering van de volgende instellingen die uitsluitend door de HealthService worden gebruikt:

Instelling	Waarde
HealthServiceCacheDurationSeconds	Hiermee bepaalt u de verlooptijd van de geheugencache in seconden.
HealthServiceStorageConnectionString	Verbindingsreeks voor het opslagaccount waarin het statusbestand moet aanwezig zijn.
HealthServiceBlobContainerName	Opslagcontainer waarin het statusbestand aanwezig moet zijn.
HealthServiceBlobName	Naam van het statusbestand: statuscontrole zoekt naar dit bestand.
HealthServiceOverallTimeoutSeconds	Time-out voor de hele controle: de standaardwaarde is 3 seconden. Als de controle niet binnen dit interval is voltooid, rapporteert de service een slechte status.

Implementatie

Alle controles worden asynchroon en parallel uitgevoerd. Als een van beide mislukt, wordt het hele stempel beschouwd als niet beschikbaar.

Controleer of de resultaten in de cache worden opgeslagen in het geheugen, met behulp van de standaard, niet-gedistribueerde ASP.NET Core-MemoryCache. SysConfig.HealthServiceCacheDurationSeconds bepaalt de verlooptijd van de cache. De standaardinstelling is 10 seconden.

Notitie

De SysConfig.HealthServiceCacheDurationSeconds configuratie-instelling vermindert de extra belasting die wordt gegenereerd door gezondheidscontroles, omdat niet elke aanvraag resulteert in een downstream-oproep van de afhankelijke services.

In de volgende tabel worden de statuscontroles voor de onderdelen in de infrastructuur weergegeven:

Onderdeel	Gezondheidscontrole
Blob van opslagaccount	De blobcontrole dient momenteel twee doeleinden: 1. Test of het mogelijk is om Blob Storage te bereiken. Het opslagaccount wordt gebruikt door andere componenten in de omgeving en wordt beschouwd als een kritieke hulpbron. 2. Schakel een regio handmatig uit door het statusbestand te verwijderen. Er is een ontwerpbeslissing genomen dat de controle alleen zou zoeken naar een aanwezigheid van een statusbestand in de opgegeven blobcontainer. De inhoud van het bestand wordt niet verwerkt. Er is een mogelijkheid om een geavanceerder systeem in te stellen dat de inhoud van het bestand leest en een andere status retourneert op basis van de inhoud van het bestand. Voorbeelden van inhoud zijn GEZOND, ONGEZOND en ONDERHOUD. Het statusbestand verwijderen schakelt de stempel uit. Zorg ervoor dat het statusbestand aanwezig is na het implementeren van de toepassing. Als het gezondheidsbestand ontbreekt, reageert de service altijd met ONGEZOND. Front Door herkent de backend niet als beschikbaar. Terraform maakt het bestand en moet aanwezig zijn na de implementatie van de infrastructuur.
Event Hub	Event Hubs-gezondheidsrapportage verwerkt de EventHubProducerService. Deze service rapporteert gezond als het een nieuw bericht naar Event Hubs kan verzenden. Voor het filteren heeft dit bericht een identificatie-eigenschap toegevoegd: HEALTHCHECK=TRUE Dit bericht wordt genegeerd aan de ontvangende kant. De AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() configuratie-instelling controleert op de HEALTHCHECK eigenschap.
Azure Cosmos DB	Azure Cosmos DB gezondheidsrapportage beheert de CosmosDbService, die als gezond wordt gerapporteerd als deze aan de volgende voorwaarden voldoet: 1. Kan verbinding maken met de Azure Cosmos DB-database en een query uitvoeren. 2. Kan een testdocument naar de database schrijven. Het testdocument heeft een korte ingestelde levensduur. Azure Cosmos DB verwijdert deze automatisch. HealthService voert twee afzonderlijke tests uit. Als Azure Cosmos DB zich in een status bevindt waarin leesbewerkingen en schrijfbewerkingen niet werken, zorgen de twee tests ervoor dat er een waarschuwing wordt geactiveerd.

Azure Cosmos DB-zoekopdrachten

Voor de alleen-lezenquery wordt de volgende query gebruikt, die geen gegevens ophaalt en geen groot effect heeft op de algehele belasting:

SELECT GetCurrentDateTime ()

De schrijfquery maakt een dummy ItemRating met minimale inhoud:

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);

Controleren

Azure Log Analytics wordt gebruikt als het centrale archief voor logboeken en metrische gegevens voor alle toepassings- en infrastructuuronderdelen. Azure-toepassing Insights wordt gebruikt voor alle bewakingsgegevens van toepassingen. Elke stempel in de infrastructuur heeft een toegewezen Log Analytics-werkruimte en een Application Insights-exemplaar. Er wordt een afzonderlijke Log Analytics-werkruimte gebruikt voor de wereldwijd gedeelde resources, zoals Front Door en Azure Cosmos DB.

Alle stempels worden kortstondig en continu vervangen bij elke nieuwe release. De per-stempel Log Analytics-werkruimten worden als een wereldwijde resource geïmplementeerd in een aparte bewakingsresourcegroep, net als de stempel Log Analytics-resources. Deze resources delen niet de levenscyclus van een stempel.

Zie Unified Data Sink voor gecorreleerde analyse voor meer informatie.

Bewaking: gegevensbronnen

• Diagnostische instellingen: alle Azure-services die worden gebruikt voor Azure Mission-Critical, zijn geconfigureerd voor het verzenden van alle diagnostische gegevens, inclusief logboeken en metrische gegevens naar de implementatiespecifieke (globale of stempel) Log Analytics-werkruimte. Dit proces gebeurt automatisch als onderdeel van de Terraform-implementatie. Nieuwe opties worden automatisch geïdentificeerd en toegevoegd als onderdeel van terraform apply.

• Kubernetes-bewaking: Diagnostische instellingen worden gebruikt voor het verzenden van AKS-logboeken (Azure Kubernetes Service) en metrische gegevens naar Log Analytics. AKS is geconfigureerd voor het gebruik van Container Insights. Container Insights implementeert de OMSAgentForLinus via een Kubernetes DaemonSet op elk knooppunt in de AKS-clusters. De OMSAgentForLinux kan extra logboeken en metrische gegevens verzamelen vanuit het Kubernetes-cluster en deze verzenden naar de bijbehorende Log Analytics-werkruimte. Deze extra logboeken en metrische gegevens bevatten gedetailleerdere gegevens over pods, implementaties, services en de algehele clusterstatus. Voor meer inzichten uit de verschillende onderdelen, zoals ingress-nginx, cert-manager en andere componenten die zijn geïmplementeerd in Kubernetes naast de missie-kritieke workload, is het mogelijk om Prometheus-scraping te gebruiken. Prometheus-scraping configureert de OMSAgentForLinux om prometheus-metrische gegevens van verschillende eindpunten in het cluster te scrapen.

• Application Insights-gegevensbewaking: Application Insights wordt gebruikt om bewakingsgegevens van de toepassing te verzamelen. De code wordt geïnstrueerd voor het verzamelen van gegevens over de prestaties van de toepassing met de Application Insights SDK. Kritieke informatie, zoals de resulterende statuscode en de duur van afhankelijkheidsaanroepen en tellers voor niet-verwerkte uitzonderingen, worden verzameld. Deze informatie wordt gebruikt in het statusmodel en is beschikbaar voor waarschuwingen en probleemoplossing.

Bewaking: Application Insights-beschikbaarheidstests

Om de beschikbaarheid van de afzonderlijke stempels en de algehele oplossing vanuit een extern oogpunt te bewaken, worden Application Insights-beschikbaarheidstests op twee plaatsen ingesteld:

• Regionale beschikbaarheidstests: Deze tests worden ingesteld in de regionale Application Insights-exemplaren en worden gebruikt om de beschikbaarheid van de stempels te bewaken. Deze tests richten zich rechtstreeks op de clusters en de statische opslagaccounts van de stempels. Als u de ingangspunten van de clusters rechtstreeks wilt aanroepen, moeten aanvragen de juiste Front Door ID-header bevatten, anders weigert de ingangscontroller de aanroepen.

• Wereldwijde beschikbaarheidstest: deze tests worden ingesteld in het globale Application Insights-exemplaar en worden gebruikt om de beschikbaarheid van de algehele oplossing te bewaken door Front Door te pingen. Er worden twee tests gebruikt: een om een API-aanroep te testen op basis van de CatalogService en één om de startpagina van de website te testen.

Bewaking: queries

Azure Mission-Critical maakt gebruik van verschillende KQL-query's (Kusto-querytaal) om aangepaste query's als functies te implementeren om gegevens op te halen uit Log Analytics. Deze query's worden opgeslagen als afzonderlijke bestanden in onze codeopslagplaats, gescheiden voor wereldwijde implementaties en stempelimplementaties. Ze worden automatisch geïmporteerd en toegepast via Terraform als onderdeel van elke pijplijnuitvoering van de infrastructuur.

Deze benadering scheidt de querylogica van de visualisatielaag. De Log Analytics-query's worden rechtstreeks vanuit code aangeroepen, bijvoorbeeld vanuit de HealthService-API. Een ander voorbeeld is van een visualisatieprogramma, zoals Azure Dashboards, Monitor Workbooks of Grafana.

Bewaking: Visualisatie

We gebruiken Grafana om de resultaten van onze Log Analytics-statusquery's in onze referentie-implementatie te visualiseren. Grafana toont de resultaten van Log Analytics-query's en bevat geen logica zelf. We brengen de Grafana-stack los van de levenscyclus van de implementatie van de oplossing.

Zie Visualisatie voor meer informatie.

Waarschuwingen

Waarschuwingen vormen een belangrijk onderdeel van de algehele operationele strategie. Proactieve bewaking, zoals het gebruik van dashboards, moet worden gebruikt met waarschuwingen die onmiddellijk aandacht vestigen op problemen.

Deze waarschuwingen vormen een uitbreiding van het gezondheidsmodel door de operator te waarschuwen voor een wijziging in de gezondheidsstatus, namelijk naar een verslechterde/gele status of een ongezonde/rode status. Door de waarschuwing in te stellen op het hoofdknooppunt van het statusmodel, is de operator onmiddellijk op de hoogte van elk bedrijfsniveau dat van invloed is op de status van de oplossing: dit hoofdknooppunt wordt immers geel of rood als een van de onderliggende gebruikersstromen of resources gele of rode metrische gegevens rapporteert. De operator kan hun aandacht richten op de visualisatie van het gezondheidsmodel voor het oplossen van problemen.

Zie Automatische reactie op incidenten voor meer informatie.

Foutanalyse

Het opstellen van de foutanalyse is meestal een theoretische planningsoefening. Deze theoretische oefening moet worden gebruikt als invoer voor de geautomatiseerde foutinjecties die deel uitmaken van het continue validatieproces. Door de hier gedefinieerde foutmodi te simuleren, kunnen we de tolerantie van de oplossing valideren tegen deze fouten om storingen te minimaliseren.

De volgende tabel bevat voorbeeldfouten van de verschillende onderdelen van de Azure Mission-Critical-referentie-implementatie.

Dienst	Risico	Invloed/Mitigatie/Opmerking	Uitval
Microsoft Entra ID	Microsoft Entra-id is niet meer beschikbaar.	Momenteel is er geen oplossing mogelijk. Een benadering voor meerdere regio's beperkt geen storingen omdat het een wereldwijde service is. Deze service is een harde afhankelijkheid. Microsoft Entra-id wordt gebruikt voor besturingsvlakbewerkingen, zoals het maken van nieuwe AKS-knooppunten, het ophalen van containerinstallatiekopieën uit ACR of voor toegang tot Key Vault bij het opstarten van pods. Bestaande, actieve onderdelen moeten kunnen blijven werken wanneer Microsoft Entra ID problemen ondervindt. Het is waarschijnlijk dat nieuwe pods of AKS-knooppunten niet kunnen spawn. Als schalingsbewerkingen gedurende deze tijd vereist zijn, dan kan dit leiden tot een verminderde gebruikerservaring en mogelijk tot storingen.	Gedeeltelijk
Azure DNS	Azure DNS wordt niet meer beschikbaar en DNS-omzetting mislukt.	Als Azure DNS niet meer beschikbaar is, mislukt de DNS-omzetting voor gebruikersaanvragen en tussen verschillende onderdelen van de toepassing. Momenteel is er geen mogelijke maatregel beschikbaar voor dit scenario. Een benadering voor meerdere regio's beperkt geen storingen omdat het een wereldwijde service is. Azure DNS is een harde afhankelijkheid. Externe DNS-services als back-up zouden niet helpen, omdat alle PaaS-onderdelen die worden gebruikt, afhankelijk zijn van Azure DNS. Dns omzeilen door over te schakelen naar IP is geen optie. Azure-services hebben geen statische, gegarandeerde IP-adressen.	Volledig
Voordeur	Algemene storing Front Door.	Als Front Door helemaal uitvalt, is er geen beperking. Deze service is een harde afhankelijkheid.	Ja
Voordeur	Routerings-/frontend-/backend-configuratiefouten.	Dit kan gebeuren als gevolg van niet-overeenkomende configuratie bij het implementeren. Moet worden opgemerkt in de testfase. Front-endconfiguratie met DNS is specifiek voor elke omgeving. Risicobeperking: Terugdraaien naar de vorige configuratie moet de meeste problemen oplossen. Als het enkele minuten duurt voordat wijzigingen in Front Door zijn geïmplementeerd, veroorzaakt dit een storing.	Volledig
Voordeur	Het beheerde TLS/SSL-certificaat wordt verwijderd.	Dit kan gebeuren als gevolg van niet-overeenkomende configuratie bij het implementeren. Moet worden opgespoord in de testfases. Technisch gezien zou de site nog steeds werken, maar TLS/SSL-certificaatfouten verhinderen dat gebruikers toegang krijgen tot de site. Risicobeperking: het opnieuw uitgeven van het certificaat kan ongeveer 20 minuten duren, plus het herstellen en opnieuw uitvoeren van de pijplijn.	Volledig
Azure Cosmos DB	De naam van de database/verzameling wordt gewijzigd.	Dit kan gebeuren als gevolg van niet-overeenkomende configuratie bij het implementeren: Terraform overschrijft de hele database, wat kan leiden tot gegevensverlies. Gegevensverlies kan worden voorkomen door vergrendelingen op database-/verzamelingsniveau te gebruiken. Toepassing heeft geen toegang tot gegevens. App-configuratie moet worden bijgewerkt en pods opnieuw worden opgestart.	Ja
Azure Cosmos DB	Regionale storing	Azure Mission-Critical heeft schrijfbewerkingen voor meerdere regio's ingeschakeld. Als er een fout optreedt bij een lees- of schrijfbewerking, probeert de client de huidige bewerking opnieuw uit te voeren. Alle toekomstige bewerkingen worden permanent gerouteerd naar de volgende regio in volgorde van voorkeur. Als de voorkeurslijst één vermelding had (of leeg was), maar het account andere regio's beschikbaar heeft, wordt deze doorgestuurd naar de volgende regio in de lijst met accounts.	Nee
Azure Cosmos DB	Ernstige vertraging door een gebrek aan Request Units (RU's).	Afhankelijk van het aantal RU's en de taakverdeling die op front Door-niveau wordt gebruikt, kunnen bepaalde stempels dynamisch worden uitgevoerd op azure Cosmos DB-gebruik, terwijl andere stempels meer aanvragen kunnen verwerken. Risicobeperking: Betere belastingverdeling of meer RU's.	Nee
Azure Cosmos DB	Partitie volledig	De groottelimiet voor logische partities in Azure Cosmos DB is 20 GB. Als gegevens voor een partitiesleutel binnen een container deze grootte bereiken, mislukken extra schrijfaanvragen met de fout 'Partitiesleutel heeft maximale grootte bereikt'.	Gedeeltelijk (DB-schrijfbewerkingen uitgeschakeld)
Azure Container Registry	Regionale storing	Containerregister maakt gebruik van Traffic Manager om een failover uit te schakelen tussen replicaregio's. Elke aanvraag moet automatisch worden omgeleid naar een andere regio. In het slechtste geval halen AKS-knooppunten voor een paar minuten geen Docker-images op terwijl DNS-failover plaatsvindt.	Nee
Azure Container Registry	Afbeelding of afbeeldingen verwijderd	Er kunnen geen afbeeldingen worden opgehaald. Deze storing mag alleen van invloed zijn op nieuw geladen/opnieuw opgestarte knooppunten. Bestaande knooppunten moeten de afbeeldingen in de cache hebben opgeslagen. Risicobeperking: Als snel wordt ontdekt dat de nieuwste build pipelines opnieuw moeten worden uitgevoerd, zouden de images weer in het register opgenomen moeten worden.	Nee
Azure Container Registry	Demping	Beperking kan het opschalen vertragen, wat kan leiden tot een tijdelijk verminderde prestatie. Risicobeperking: Azure Mission-Critical maakt gebruik van de Premium SKU die 10.000 leesbewerkingen per minuut biedt. Containerimages zijn geoptimaliseerd en hebben slechts weinig lagen. ImagePullPolicy is ingesteld op IfNotPresent om eerst lokaal opgeslagen versies te gebruiken. Opmerking: Het ophalen van een containerimage bestaat uit meerdere leesbewerkingen, Afhankelijk van het aantal lagen. Het aantal leesbewerkingen per minuut is beperkt en is afhankelijk van de grootte van de ACR-SKU.	Nee
Azure Kubernetes Service	Cluster upgrade mislukt	AKS Node-upgrades moeten op verschillende tijdstippen worden uitgevoerd op de stempels. Als de ene upgrade mislukt, moet het andere cluster niet worden beïnvloed. Clusterupgrades moeten op rollende wijze worden geïmplementeerd op de knooppunten om te voorkomen dat alle knooppunten niet meer beschikbaar zijn.	Nee
Azure Kubernetes Service	Applicatiepod wordt gedood tijdens het bedienen van een aanvraag.	Dit resultaat kan leiden tot fouten van eindgebruikers en slechte gebruikerservaring. Risicobeperking: Kubernetes verwijdert standaard pods op een nette manier. Eerst worden pods uit services verwijderd en vervolgens ontvangt de workload een SIGTERM met een gratieperiode om openstaande aanvragen af te ronden en gegevens te schrijven voordat deze wordt beëindigd. De toepassingscode moet SIGTERM begrijpen en de respijtperiode moet mogelijk worden bijgesteld als het langer duurt om de werklast uit te schakelen.	Nee
Azure Kubernetes Service	Rekencapaciteit is niet beschikbaar in de regio om meer knooppunten toe te voegen.	Omhoog/uitschalen mislukt, maar dit moet geen invloed hebben op bestaande knooppunten en hun werking. In het ideale geval moet verkeer automatisch worden verplaatst naar andere regio's voor taakverdeling.	Nee
Azure Kubernetes Service	Het abonnement bereikt het CPU-kernquotum om nieuwe knooppunten toe te voegen.	Het opschalen van capaciteit mislukt, maar het zou geen invloed moeten hebben op de bestaande knooppunten en hun werking. In het ideale geval moet verkeer automatisch worden verplaatst naar andere regio's voor taakverdeling.	Nee
Azure Kubernetes Service	Let's Encrypt TLS/SSL-certificaten kunnen niet worden uitgegeven of vernieuwd.	Het cluster moet niet in orde zijn in de richting van Front Door en verkeer moet worden verplaatst naar andere stempels. Maatregel: Onderzoek de hoofdoorzaak van het probleem of de vernieuwingsfout.	Nee
Azure Kubernetes Service	Wanneer resourceaanvragen/limieten onjuist zijn geconfigureerd, kunnen pods een CPU-gebruik van 100% bereiken en aanvragen niet verwerken. Het mechanisme voor opnieuw proberen van toepassingen moet mislukte aanvragen kunnen herstellen. Nieuwe pogingen kunnen een langere aanvraagduur veroorzaken, zonder dat de fout aan de client wordt weergegeven. Overmatige belasting veroorzaakt uiteindelijk een storing.	Nee (als de belasting niet overmatig is)
Azure Kubernetes Service	Containerafbeeldingen van derden / register niet beschikbaar	Voor sommige componenten, zoals cert-manager en ingress-nginx, moeten containerafbeeldingen en helm charts worden gedownload vanuit externe containerregisters (uitgaand verkeer). Als een of meer van deze opslagplaatsen of installatiekopieën niet beschikbaar zijn, kunnen nieuwe exemplaren op nieuwe knooppunten (waarbij de installatiekopieën nog niet in de cache zijn opgeslagen) mogelijk niet worden gestart. Mogelijke mitigatie: In sommige scenario's kan het zinvol zijn om containerafbeeldingen van derden te importeren in het containerregister per oplossing. Dit scenario voegt extra complexiteit toe en moet zorgvuldig worden gepland en operationeel worden gemaakt.	Gedeeltelijk (tijdens schaal- en update-/upgradebewerkingen)
Event Hub	Berichten kunnen niet worden verzonden naar de Event Hubs	Stempel wordt onbruikbaar voor schrijfbewerkingen. Gezondheidsdienst zou dit automatisch moeten detecteren en het stempel uit de omloop halen.	Nee
Event Hub	Berichten kunnen niet worden gelezen door de BackgroundProcessor	Berichten worden in de wachtrij geplaatst. Berichten mogen niet verloren gaan omdat ze behouden blijven. Deze fout wordt momenteel niet gedekt door de Health Service. Er zouden bewakings- en waarschuwingstaken op de worker moeten worden ingesteld om fouten in het lezen van berichten te detecteren. Beperking: De stempel moet handmatig worden uitgeschakeld totdat het probleem is opgelost.	Nee
Opslagaccount	Opslagaccount wordt onbruikbaar voor de worker bij het zetten van checkpoints voor Event Hubs.	Stamp verwerkt geen berichten van de Event Hubs. Het opslagaccount wordt ook gebruikt door de HealthService. De HealthService moet opslagproblemen detecteren en de stempel uit de roulatie nemen. Er kan worden verwacht dat andere services in de stempel gelijktijdig worden beïnvloed.	Nee
Opslagaccount	Statische website ondervindt problemen.	Als de statische website problemen ondervindt, detecteert Front Door deze fout. Verkeer wordt niet naar dit opslagaccount verzonden. Caching bij Front Door kan dit probleem ook verhelpen.	Nee
Key Vault	Key Vault is niet beschikbaar voor GetSecret bewerkingen.	Aan het begin van nieuwe pods haalt de AKS CSI-driver alle geheimen uit Key Vault op en faalt. Pods kunnen niet worden gestart. Er is momenteel elke 5 minuten een automatische update. De update mislukt. Fouten zouden moeten verschijnen in kubectl describe pod, maar de pod blijft werken.	Nee
Key Vault	Key Vault is niet beschikbaar voor GetSecret of SetSecret bewerkingen.	Nieuwe implementaties kunnen niet worden uitgevoerd. Op dit moment kan deze fout ertoe leiden dat de hele implementatiepijplijn wordt gestopt, zelfs als er slechts één regio wordt beïnvloed.	Nee
Key Vault	Beperking van Key Vault	Key Vault heeft een limiet van 1000 bewerkingen per 10 seconden. Vanwege de automatische update van geheimen, kunt u in theorie deze limiet bereiken als u veel (duizenden) pods in een stempel had. Mogelijke beperking: verlaag de updatefrequentie nog verder of schakel deze volledig uit.	Nee
Toepassing	Onjuiste configuratie	Onjuiste verbindingsreeksen of geheimen die in de app zijn geïnjecteerd. Beperkt door geautomatiseerde implementatie (pijplijn verwerkt configuratie automatisch) en blauwgroene implementatie van updates.	Nee
Toepassing	Verlopen inloggegevens (stempelresource)	Als bijvoorbeeld het SAS-token of de sleutel van het opslagaccount van de Event Hub is gewijzigd zonder deze correct bij te werken in Key Vault, zodat de pods deze kunnen gebruiken, mislukt het respectieve toepassingsonderdeel. Deze fout moet vervolgens van invloed zijn op de Health Service en de stempel moet automatisch uit de rotatie worden gehaald. Risicobeperking: gebruik verificatie op basis van Microsoft Entra ID voor alle services die dit ondersteunen. AKS vereist dat pods zich authentiseren met behulp van Microsoft Entra Workload-ID in de preview-modus. Het gebruik van Pod Identity werd overwogen in de referentie-implementatie. Er is vastgesteld dat Pod Identity momenteel niet stabiel genoeg was, en er is besloten het niet te gebruiken voor de huidige referentiearchitectuur. Pod-identiteit kan in de toekomst een oplossing zijn.	Nee
Toepassing	Verlopen referenties (globaal gedeelde resource)	Als de Azure Cosmos DB-API-sleutel bijvoorbeeld is gewijzigd zonder deze correct bij te werken in alle sleutelkluizen, zodat de pods deze kunnen gebruiken, mislukken de respectieve toepassingsonderdelen. Met deze fout worden alle stempels tegelijkertijd omlaag gestempeld en is er sprake van een storing in de hele workload. Zie het vorige item voor een mogelijke manier om de noodzaak van sleutels en geheimen met Microsoft Entra-verificatie te omzeilen.	Volledig
Virtueel netwerk	Ip-adresruimte van subnet uitgeput	Als de IP-adresruimte op een subnet is uitgeput, kunnen er geen uitschaalbewerkingen plaatsvinden, zoals het maken van nieuwe AKS-knooppunten of pods. Er treedt geen storing op, maar het kan de prestaties verminderen en de gebruikerservaring beïnvloeden. Risicobeperking: vergroot de IP-ruimte (indien mogelijk). Als dit geen optie is, kan het helpen om de resources per knooppunt (grotere VM-SKU's) of per pod (meer CPU/geheugen) te verhogen, zodat elke pod meer verkeer kan verwerken, waardoor de behoefte aan uitschalen wordt verminderd.	Nee

Volgende stappen

Implementeer de referentie-implementatie om volledig inzicht te krijgen in de resources en de configuratie die in deze architectuur wordt gebruikt.

Implementatie: Bedrijfskritiek online