Betrouwbaarheid in Azure Container Apps

Azure Container Apps is een volledig beheerde, serverloze containerhostingservice voor het implementeren van microservices en containertoepassingen.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Container Apps tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Het beschrijft ook hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen en benadrukt belangrijke informatie over de service level agreement (SLA) van Container Apps.

Aanbevelingen voor productie-implementatie

Zie praktijken voor architectuur voor Container Apps in het Azure Well-Architected Framework om te leren hoe u Container Apps implementeert ter ondersteuning van de betrouwbaarheidsvereisten van uw oplossing, en hoe betrouwbaarheid andere aspecten van uw architectuur beïnvloedt.

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u Container Apps gebruikt, implementeert u een omgeving die fungeert als de basisimplementatie-eenheid en definieert u een veilige grens rond een groep container-apps. In de omgeving configureert u kerninstellingen, waaronder ondersteuning voor beschikbaarheidszones en netwerkconfiguratie. De twee typen omgevingen zijn omgevingen met workloadprofielen en omgevingen die alleen op verbruik gericht zijn. Zie Compute- en factureringsstructuren in Container Apps voor meer informatie.

U kunt meerdere apps in één omgeving implementeren. Elke app draait een of meer containers. Een omgeving kan ook een of meer taken uitvoeren, die niet-interactieve taken vertegenwoordigen. Zie voor meer informatie Containers in Container Apps en Jobs in Container Apps.

Elke app heeft een of meer replica's, die de actieve exemplaren van de app vertegenwoordigen. U kunt bepalen hoe uw app wordt geschaald, inclusief het minimum- en maximumaantal replica's en hoe de app dynamisch replica's toevoegt en verwijdert. De platformplanner zorgt voor optimale distributie over fysieke hosts en voldoet aan de minimale vereisten voor het aantal replica's. Zie Schaalregels instellen in Container Apps voor meer informatie.

Container Apps ondersteunt de betrouwbaarheid van uw toepassingen met behulp van verschillende mogelijkheden:

• Automatische gezondheidscontrole: De ingebouwde controller voor inkomend verkeer verdeelt automatisch de belasting over gezonde replica's. Als een replica voor de gezondheidscontroles mislukt of de onderliggende infrastructuur gedurende langere tijd niet beschikbaar is, start de service de mislukte containers automatisch opnieuw op of maakt het vervangende replica's. Het herdistribueert ook verkeer van ongezonde replica's en beheert herhalingen van netwerkverzoeken in het cluster. Dit automatische herstelproces vereist geen tussenkomst van de klant en onderhoudt het opgegeven aantal replica's. Zie Gezondheidsonderzoeken voor meer informatie.

• Toepassingstolerantie via Dapr: Container Apps biedt een nauwe integratie met Dapr, een framework dat ondersteuning biedt voor microservices op productieniveau en toepassingen in containers. Dapr bevat functies waarmee u de tolerantie kunt verbeteren, waaronder het afhandelen van fouten in andere services. Zie Microservices met Container Apps voor meer informatie.

• Infrastructuurtolerantie voor systeemonderdelen: Deze tolerantie omvat het besturingsvlak, ingangscontrollers en containerruntime. In regio's met beschikbaarheidszones biedt Container Apps zoneredundantie. Zie Tolerantie voor fouten in beschikbaarheidszones voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Container Apps verwerkt automatisch veel tijdelijke fouten via de mechanismen voor opnieuw proberen op platformniveau en statuscontrole. Voer de volgende acties uit om ervoor te zorgen dat uw toepassingen bestand zijn tegen tijdelijke fouten:

• Configureer statustests waarmee het platform toepassingsspecifieke foutvoorwaarden kan detecteren en erop kan reageren. Stel de juiste drempelwaarden voor fouten en time-outwaarden in op basis van de opstartkenmerken van uw toepassing. Gebruik bijvoorbeeld een foutdrempel van 3 met een periode van 10 seconden voor liveness probes, om te voorkomen dat containers voortijdig opnieuw opstarten tijdens tijdelijke problemen. Zie Gezondheidsonderzoeken voor meer informatie.

• Gebruik beleid voor tolerantie voor servicedetectie (preview) om proactief fouten in serviceaanvragen te voorkomen, te detecteren en te herstellen. Wanneer u bijvoorbeeld een tolerantiebeleid gebruikt, kan elke binnenkomende aanvraag voor de app automatisch opnieuw worden geprobeerd als er een tijdelijke fout is waardoor de app niet reageert. Zie Veerkracht van servicedetectie (preview) voor meer informatie.

• Implementeer logica voor opnieuw proberen in uw toepassingen voor externe serviceaanroepen, databaseverbindingen en API-aanvragen.

  Als uw toepassing Dapr gebruikt om te integreren met clouddiensten, kunt u Dapr-componentbetrouwbaarheid (voorlopige versie) gebruiken om hertries, time-outs en circuitonderbrekers te configureren.

  Voor andere afhankelijkheden moet uw toepassing tijdelijke fouten afhandelen. Gebruik exponentiële terugvalstrategieën en circuitonderbrekerpatronen voor het aanroepen van externe services om trapsgewijze storingen tijdens onderbrekingen in downstream services te voorkomen. Ingebouwde servicedetectie- en taakverdelingsfuncties van Container Apps leiden verkeer automatisch weg van mislukte exemplaren, maar uw beleid voor opnieuw proberen op toepassingsniveau zorgt ervoor dat tijdelijke problemen correct worden verwerkt voordat statuscontroles op platformniveau het opnieuw opstarten van containers activeren.

• Ontwerptaken die bestand zijn tegen tijdelijke fouten, inclusief fouten tijdens het uitvoeren van taken of in hun afhankelijkheden. Ontwerp uw taken om het werk te hervatten wanneer ze opnieuw worden gestart, of ontwerp voor idempotentie, zodat ze veilig opnieuw kunnen worden uitgevoerd.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Wanneer u een Container Apps-omgeving maakt, kunt u zoneredundantie inschakelen om de onderliggende infrastructuur over meerdere beschikbaarheidszones in de gekozen Azure-regio te verdelen. Container Apps plant automatisch de replica's van uw apps in verschillende zones. Deze distributie vindt transparant plaats, wat betekent dat u geen zoneplaatsing hoeft op te geven voor afzonderlijke replica's.

Zoneredundantie verbetert de tolerantie van uw toepassing tot fouten op zoneniveau door ervoor te zorgen dat de replica's van uw container-app worden verspreid over meerdere zones.

In het volgende diagram ziet u een zone-redundante container-app met drie replica's. Elke replica draait in een afzonderlijke beschikbaarheidszone.

Requirements

• Controleer de regioondersteuning. Zoneredundantie is beschikbaar in alle regio's die container-apps en beschikbaarheidszones ondersteunen.

  Zie Azure-regio's met ondersteuning voor beschikbaarheidszones om te zien welke regio's beschikbaarheidszones ondersteunen.

  Zie Product beschikbaarheid per regio om te zien welke regio's ondersteuning bieden voor Container Apps.

• Werkbelastingprofielen gebruiken. Zoneredundantie is beschikbaar voor alle Container Apps-abonnementen, waaronder zowel verbruiks- als toegewezen workloadprofielen.

• Schakel zoneredundantie in tijdens het maken van de omgeving. Deze instelling kan niet worden gewijzigd nadat de omgeving is gemaakt.

• Een Container Apps-omgeving implementeren in een virtueel netwerk. Het virtuele netwerk moet zich in een regio bevinden die beschikbaarheidszones ondersteunt. Zorg ervoor dat het virtuele netwerk een subnet van voldoende grootte heeft. Omgevingen met alleen verbruik hebben een subnet met een /23 CIDR-bereik (Classless Inter-Domain Routing) of groter nodig, terwijl omgevingen voor workloadprofielen een /27 CIDR-bereik of groter vereisen.

• Stel het minimale aantal replica's in op ten minste twee om de distributie over meerdere beschikbaarheidszones te garanderen. Overweeg om een hoger minimumaantal replica's in te stellen als een van de volgende voorwaarden van toepassing is:

  • De verwachte piekbelasting heeft meer dan twee replica's nodig.

  • u moet bestand zijn tegen meerdere gelijktijdige zone-uitvallen.

  • U wilt de wachttijd minimaliseren voor de creatie van nieuwe replica's in andere zones tijdens een storing in een zone.

Kosten

Er worden geen extra kosten in rekening gebracht buiten de standaardprijs voor Container Apps wanneer u zoneredundantie inschakelt. U betaalt dezelfde tarieven voor rekenresources, aanvragen en vCore-seconden, ongeacht of zoneredundantie is ingeschakeld of niet. Zie prijzen voor Container Apps en Container Apps-facturering voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

• Maak een zone-redundante Container Apps-omgeving. Zie Een zone-redundante container-app maken voor instructies voor de implementatie die betrekking hebben op Azure Portal, de Azure CLI en Azure PowerShell.

• Migreren naar een zone-redundante implementatie. U kunt zoneredundantie niet inschakelen voor een bestaande Container Apps-omgeving. Als u bestaande omgevingen wilt upgraden die niet zone-redundant zijn, maakt u een nieuwe omgeving met zoneredundantie ingeschakeld in een ondersteunde regio. Implementeer vervolgens uw container-apps opnieuw.

• Zoneredundantie uitschakelen. Zoneredundantie kan niet worden uitgeschakeld nadat deze is ingeschakeld tijdens het maken van de omgeving. Als u een niet-zone-redundante implementatie nodig hebt, moet u een nieuwe omgeving maken zonder de optie zoneredundantie in te schakelen of te implementeren in een regio die geen ondersteuning biedt voor beschikbaarheidszones.

• Controleer zoneredundantie. U kunt Azure Portal, De Azure CLI en Azure PowerShell gebruiken om de status van zoneredundantie van uw omgeving te controleren.

Capaciteitsplanning en -beheer

Als een beschikbaarheidszone niet beschikbaar is, gebruikt het Container Apps-platform uw schaalregels om te bepalen wanneer verloren replica's in die zone moeten worden vervangen. Het is belangrijk om uw schaalregels correct te configureren, zodat de planner de juiste planningsbeslissingen kan nemen.

Volg deze principes om uw schaalregels correct te configureren:

• Stel een minimum aantal replica's in dat uw toepassing kan tolereren. Het kan even duren voordat verloren replica's zijn vervangen omdat het platform moet detecteren dat de oude replica's zijn verdwenen. Vervolgens moeten nieuwe replica's opstarten en een gezonde status van een gereedheidscontrole retourneren voordat ze binnenkomende aanvragen kunnen verwerken. Als u geen perioden met minder dan het minimale aantal opgegeven replica's kunt tolereren, kunt u overwegen om extra voorzieningen te treffen om de prestaties van uw toepassing te behouden, zelfs als een zone niet beschikbaar is.

• Stel resourceaanvragen en -limieten in om de Container Apps-planner te helpen optimale plaatsingsbeslissingen te nemen in verschillende zones. Onderspecifieke resourcevereisten kunnen leiden tot ongelijke distributie- of plaatsingsfouten tijdens hoge belasting.

Zie Regels voor schalen instellen voor meer informatie over configuratieopties.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer Container Apps-resources zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

• Verkeersroutering tussen zones: Met zone-redundante Container Apps werkt het platform in een actief-actief model waarbij meerdere replica's tegelijkertijd verkeer bedienen. De ingresscontroller verdeelt binnenkomende aanvragen over alle gezonde replica's, ongeacht hun zone, en maakt standaard gebruik van round-robin load balancing. Elke zone verwerkt aanvragen onafhankelijk en het platform geeft geen prioriteit aan een specifieke zone voor de distributie van verkeer. Gezondheidstests zijn afkomstig van alle zones om een nauwkeurige gezondheidsbeoordeling van elke replica vanuit meerdere invalshoeken te garanderen.

• Gegevensreplicatie tussen zones: Container Apps repliceert geen toepassingsgegevens tussen zones omdat deze is ontworpen voor staatloze workloads. Alle gegevens die uw app opslaat in tijdelijke opslag, inclusief in container-specifieke opslag en replica-specifieke opslag, worden verwijderd wanneer de container of replica wordt afgesloten.

  Voor stateful gegevensvereisten koppelt u een Azure Files-bestandsshare die is geconfigureerd voor zone-redundante opslag of gebruikt u andere Azure-services, zoals Azure Cosmos DB of Azure SQL Database, die hun eigen replicatiemogelijkheden voor meerdere zones bieden.

  Het platform repliceert alleen de metagegevens van het besturingsvlak, inclusief uw app-configuraties, schaalregels en geheimen in zones voor hoge beschikbaarheid. Containerafbeeldingen worden indien nodig opgehaald uit uw containerregister in elke zone wanneer replica's worden aangemaakt.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer Container Apps-resources zijn geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone is.

• Detectie en reactie: Azure detecteert automatisch zonefouten. Container Apps stopt onmiddellijk met het plannen van nieuwe replica's in de mislukte zone en begint het verkeer te herverdelen naar functionerende replica's in de resterende zones. Het platform verwerkt alle failoverbewerkingen automatisch zonder dat uw tussenkomst is vereist.

• Bekendmaking: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  U kunt ook de status van uw apps bewaken via metrische gegevens van Container Apps in Azure Monitor. Configureer waarschuwingen voor verlaagde replica-aantallen en aanvraagfoutpercentages om onmiddellijke meldingen te ontvangen wanneer er zonegerelateerde problemen optreden.

• Actieve aanvragen: Aanvragen tijdens de vlucht naar replica's in de mislukte zone kunnen worden verwijderd of er zijn time-outs of verbindingsfouten opgetreden. Taakuitvoeringen die in de betrokken zone worden uitgevoerd, worden afgebroken en zijn gemarkeerd als mislukt.

• Verwachte gegevensverlies: Er treden geen gegevensverlies op het platformniveau van Container Apps op omdat de service is ontworpen voor stateless workloads. Alle gegevens die zijn opgeslagen in tijdelijke opslag in de beschikbaarheidszone, gaan verloren wanneer de replica wordt beëindigd en tijdelijke opslag mag alleen worden gebruikt voor tijdelijke gegevens.

• Verwachte downtime: Toepassingen ondervinden minimale tot geen downtime tijdens zonefouten. De werkelijke impact is afhankelijk van de statustestinstellingen van uw toepassing en het aantal replica's in gezonde zones. Zorg ervoor dat clients richtlijnen voor het afhandelen van tijdelijke fouten volgen om eventuele effecten te minimaliseren.

  Alle taken die worden uitgevoerd in de betrokken zone, worden afgebroken en zijn gemarkeerd als mislukt. Als u een taak nodig hebt om bestand te zijn tegen een zonefout, configureert u nieuwe pogingen of configureert u parallelle uitvoering, zodat de taak meerdere kopieën van dezelfde uitvoering uitvoert. Zie Geavanceerde taakconfiguratie voor meer informatie.

• Verkeer omleiden: De statustests van de ingangscontroller detecteren snel onbereikbare replica's en verwijderen ze uit de taakverdelingsgroep. Afhankelijk van de configuratie van de statustest van uw app, vindt dit failoverproces doorgaans ongeveer 30 seconden plaats. Inkomend verkeer dat daarna aankomt, wordt verdeeld over de overige gezonde replica's. Deze verkeersomleiding vindt transparant plaats voor clients die dezelfde toepassings-URL blijven gebruiken.

  Als sessieaffiniteit is ingeschakeld en een zone uitvalt, worden clients die eerder naar replica's in die zone zijn gerouteerd, doorgestuurd naar nieuwe replica's omdat de vorige replica's niet meer beschikbaar zijn. Elke status die aan de vorige replica's is gekoppeld, gaat verloren.

  Er worden geen nieuwe instanties van taken gestart in de defecte zone.

• Exemplaarbeheer: Nieuwe replica-exemplaren kunnen worden gemaakt in zones die in orde zijn als uw regels voor automatisch schalen worden geactiveerd op basis van een verhoogde belasting.

Zoneherstel

Wanneer een beschikbaarheidszone herstelt na een fout, wordt de zone automatisch opnieuw geïntegreerd in de actieve service zonder dat uw tussenkomst is vereist. De statustests van het platform detecteren wanneer infrastructuur in de herstelde zone beschikbaar komt en Container Apps begint met het plannen van nieuwe replica's naar die zone op basis van uw schaalconfiguratie. Bestaande replica's in gezonde zones blijven verkeer bedienen tijdens het re-integratieproces, waardoor serviceonderbrekingen worden voorkomen.

Container Apps herverdeelt geleidelijk de verspreiding van replica's over alle beschikbare zones als onderdeel van normale schaalbewerkingen. Deze automatische herverdeling vindt plaats wanneer replica's worden gemaakt als gevolg van schaalvergroting of wanneer ongezonde replica's worden vervangen. Het platform dwingt geen onmiddellijke herdistributie van bestaande gezonde replica's af, waardoor onnodige herstart van containers wordt voorkomen en de stabiliteit van de toepassing behouden blijft tijdens het herstel.

Testen op zonefouten

Het Container Apps-platform beheert verkeersroutering, failover en failback voor zone-redundante container-apps. Deze functie wordt volledig beheerd, dus u hoeft geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.

Als u de tolerantie van uw toepassing voor zonefouten wilt valideren, simuleert u onderbrekingen op zoneniveau op de toepassingslaag met behulp van gecontroleerde testmethoden. Stop of verwijder replica's uit specifieke zones door de toepassing omlaag te schalen en te controleren hoe de resterende replica's de verhoogde belasting verwerken. Bewaak belangrijke metrische gegevens tijdens het testen van tolerantie, waaronder het aantal replica's, het succespercentage van aanvragen, de reactietijden en het gedrag van automatische schaalaanpassing. Zorg ervoor dat het minimale aantal replica's de beschikbaarheid van de service behoudt wanneer replica's worden verwijderd en controleer of uw schaalregels de verhoogde belasting van de resterende replica's kunnen afhandelen. Test uw health probe configuraties door health endpoints opzettelijk te laten falen om te bevestigen dat het platform ongezonde instanties tijdens de verwachte periodes uit de rotatie verwijdert.

Tolerantie voor storingen in de hele regio

Container Apps is een service met één regio. Als de regio niet meer beschikbaar is, zijn uw omgeving en apps ook niet beschikbaar.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

U kunt omgevingen in meerdere regio's implementeren om het risico te beperken dat een storing in één regio van invloed is op uw toepassing. De volgende stappen helpen de tolerantie te versterken:

• Implementeer uw toepassingen in omgevingen in elke regio. Elke omgeving vereist een eigen virtuele netwerkconfiguratie en subnetvereisten zijn onafhankelijk van toepassing op elke regionale implementatie. Uw containerinstallatiekopieën moeten beschikbaar zijn in alle regio's, die u kunt bereiken met behulp van Azure Container Registry waarvoor geo-replicatie is ingeschakeld.

• Configureer taakverdelings- en failoverbeleid met behulp van een service zoals Azure Front Door of Azure Traffic Manager.

• Repliceer uw gegevens tussen regio's, zodat u de laatste toepassingsstatus kunt herstellen.

Backups en herstel

Container Apps biedt geen ingebouwde back-upmogelijkheden voor uw toepassingen of gegevens. Als stateless containerhostingplatform verwacht Container Apps dat toepassingen hun eigen strategieën voor gegevenspersistentie en herstel beheren via externe services. Uw toepassingscontainers en hun lokale bestandssystemen zijn kortstondig en alle gegevens die lokaal zijn opgeslagen, gaan verloren wanneer replica's opnieuw worden opgestart of verplaatst.

Tolerantie tijdens toepassingsupdates

Gebruik revisiebeheer om updates voor uw toepassing te implementeren zonder uitvaltijd. U kunt nieuwe revisies maken met bijgewerkte containerinstallatiekopieën en een cutover uitvoeren met behulp van een blauwgroene implementatiestrategie of geleidelijk verkeer verplaatsen met behulp van regels voor het splitsen van verkeer. Tijdens toepassingsupdates onderhoudt het platform minimale replicaaantallen door nieuwe containers te maken voordat oude containers worden buiten gebruik gesteld, waardoor serviceonderbrekingen worden voorkomen.

Zie Wijzigingen bijwerken en implementeren in Container Apps voor meer informatie.

Tolerantie voor serviceonderhoud

Container Apps voert automatisch platformonderhoud uit om beveiligingsupdates toe te passen, nieuwe functies te implementeren en de betrouwbaarheid van de service te verbeteren. Het platform maakt gebruik van rolling updates tussen foutdomeinen en beschikbaarheidszones om onderbreking van actieve toepassingen te verminderen. Tijdens onderhoudsvensters blijven uw containers zonder onderbreking actief omdat updates in fasen worden toegepast op de onderliggende infrastructuur.

U kunt uw eigen onderhoudsvensters opgeven. Dit zijn perioden die u wilt laten uitvoeren op uw apps. Houd er rekening mee dat kritieke updates kunnen optreden buiten uw onderhoudsvensters. Zie Gepland onderhoud voor Container Apps voor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

De SLA voor beschikbaarheid voor Container Apps is gebaseerd op de schaalregels die u voor uw apps instelt.

Verwante inhoud

• Overzicht van container-apps
• Gezondheidsprobes in Container Apps
• Automatisch schalen in Container Apps
• Waarneembaarheid in Container Apps
• betrouwbaarheidsdocumentatie voor Azure
• richtlijnen voorWell-Architected Framework-betrouwbaarheid