Overzicht van oplossing voor actief-passief herstel na noodgevallen voor Azure Kubernetes Service (AKS)

Wanneer u een toepassing maakt in Azure Kubernetes Service (AKS) en een Azure regio kiest tijdens het maken van resources, is dit een app met één regio. Wanneer de regio niet meer beschikbaar is tijdens een noodgeval, is uw toepassing ook niet meer beschikbaar. Als u een identieke implementatie in een secundaire Azure-regio maakt, is uw toepassing minder kwetsbaar voor een ramp in één regio, wat de bedrijfscontinuïteit waarborgt, en dankzij gegevensreplicatie tussen de regio's kunt u de meest recente toestand van uw toepassing herstellen.

Deze handleiding bevat een oplossing voor actief-passief herstel na noodgevallen voor AKS. Binnen deze oplossing implementeren we twee onafhankelijke en identieke AKS-clusters in twee gekoppelde Azure regio's met slechts één cluster dat actief verkeer bedient.

Opmerking

De volgende praktijk is intern beoordeeld en gecontroleerd in combinatie met onze Microsoft partners.

Overzicht van actief-passieve oplossingen

In deze aanpak voor herstel na noodgevallen hebben we twee onafhankelijke AKS-clusters die in twee Azure regio's worden geïmplementeerd. Slechts één van de clusters verwerkt echter op een bepaald moment actief verkeer. Het secundaire cluster (niet actief verkeer dient) bevat dezelfde configuratie- en toepassingsgegevens als het primaire cluster, maar accepteert geen verkeer, tenzij dit wordt geleid door Azure Front Door Traffic Manager.

Scenario's en configuraties

Deze oplossing wordt het beste geïmplementeerd bij het hosten van toepassingen die afhankelijk zijn van resources, zoals databases, die actief verkeer in één regio bedienen. In scenario's waarin u staatloze toepassingen moet hosten die zijn geïmplementeerd in beide regio's, zoals horizontaal schalen, raden we u aan een actief-actief oplossing te overwegen, omdat actief-passief extra latentie omvat.

Componenten

De oplossing voor actief-passief herstel na noodgevallen maakt gebruik van veel Azure services. Deze voorbeeldarchitectuur omvat de volgende onderdelen:

Meerdere clusters en regio's: u implementeert meerdere AKS-clusters, elk in een afzonderlijke Azure regio. Tijdens normale bewerkingen wordt netwerkverkeer doorgestuurd naar het primaire AKS-cluster dat is ingesteld in de Azure Front Door-configuratie.

Geconfigureerde prioriteitstelling van clusters: u stelt een prioriteitsniveau in tussen 1-5 voor elk cluster (waarbij 1 de hoogste prioriteit heeft en 5 de laagste prioriteit heeft). U kunt meerdere clusters instellen op hetzelfde prioriteitsniveau en het gewicht voor elk cluster opgeven. Als het primaire cluster niet meer beschikbaar is, wordt verkeer automatisch gerouteerd naar de volgende regio die is geselecteerd in Azure Front Door. Al het verkeer moet door Azure Front Door lopen om dit systeem te laten werken.

Azure Front Door: Azure Front Door verdeelt de belasting en routeert verkeer naar het exemplaar van Azure Application Gateway in de primaire regio (cluster moet worden gemarkeerd met prioriteit 1). In het geval van een regiofout leidt de service verkeer om naar het volgende cluster in de prioriteitslijst.

Zie Op prioriteit gebaseerde verkeersroutering voor meer informatie.

Hub-spoke-paar: Voor elke regionale AKS-instantie wordt een hub-spoke-paar geïmplementeerd. Azure Firewall Manager beleidsregels de firewallregels voor elke regio beheren.

Key Vault: U richt een Azure Key Vault in elke regio in om geheimen en sleutels op te slaan.

Log Analytics: Regionale Log Analytics-exemplaren slaan metrische gegevens en diagnostische logboeken voor regionale netwerken op. In een gedeeld exemplaar worden metrische gegevens en diagnostische logboeken voor alle AKS-exemplaren opgeslagen.

Container Registry: De containerimages voor de workload worden opgeslagen in een beheerde containerregistry. Met deze oplossing wordt één Azure Container Registry exemplaar gebruikt voor alle Kubernetes-exemplaren in het cluster. Met geo-replicatie voor Azure Container Registry kunt u installatiekopieën repliceren naar de geselecteerde Azure regio's en hebt u continue toegang tot afbeeldingen, zelfs als een regio een storing ondervindt.

Failover-proces

Als een service of serviceonderdeel niet meer beschikbaar is in één regio, moet verkeer worden doorgestuurd naar een regio waar die service beschikbaar is. Een architectuur met meerdere regio's bevat veel verschillende storingspunten. In deze sectie behandelen we de mogelijke storingspunten.

Toepassingspods (regionaal)

Een Kubernetes-implementatieobject maakt meerdere replica's van een pod (ReplicaSet). Als een van de replica's niet beschikbaar is, wordt verkeer tussen de resterende replica's gerouteerd. De Kubernetes ReplicaSet probeert het opgegeven aantal replica's actief te houden. Als één exemplaar uitvalt, moet een nieuw exemplaar opnieuw worden gemaakt. Liveness-probes kunnen de status controleren van de toepassing of het proces dat in de pod wordt uitgevoerd. Als de pod niet reageert, verwijdert de liveness-probe de pod, wat de ReplicaSet dwingt een nieuw exemplaar te maken.

Zie Kubernetes ReplicaSet voor meer informatie.

Toepassingspods (globaal)

Wanneer een hele regio niet meer beschikbaar is, zijn de pods in het cluster niet meer beschikbaar om aanvragen te verwerken. In dit geval stuurt de Azure Front Door-instantie al het verkeer naar de resterende gezonde regio's. De Kubernetes-clusters en -pods in deze regio's blijven aanvragen verwerken. Houd rekening met de volgende richtlijnen om meer verkeer en aanvragen voor het resterende cluster te compenseren:

  • Zorg ervoor dat netwerk- en rekenresources de juiste grootte hebben om plotselinge toename van het verkeer te absorberen vanwege failover van regio's. Als u bijvoorbeeld Azure CNI (Container Network Interface) gebruikt, moet u ervoor zorgen dat u een subnet hebt dat ondersteuning biedt voor alle pod-IP's met een piek in de belasting van het verkeer.
  • Gebruik de Horizontal Pod Autoscaler om het aantal podreplica's te verhogen, zodat de gestegen regionale vraag kan worden opgevangen.
  • Gebruik de automatische schaalaanpassing van AKS-clusters om het aantal Kubernetes-exemplaarknooppunten te verhogen om de toegenomen regionale vraag te compenseren.

Kubernetes-knooppuntgroepen (regionaal)

Af en toe kan er een gelokaliseerde fout optreden bij het berekenen van resources, zoals stroom die niet beschikbaar is in één rek met Azure servers. Gebruik Azure Beschikbaarheidszones om te voorkomen dat uw AKS-knooppunten in deze actief-passieve oplossing één regionaal storingspunt vormen. Beschikbaarheidszones zorgen ervoor dat AKS-knooppunten in elke beschikbaarheidszone fysiek worden gescheiden van de knooppunten die zijn gedefinieerd in een andere beschikbaarheidszone.

Kubernetes-knooppuntgroepen (globaal)

Bij een volledige regionale storing stuurt Azure Front Door verkeer naar de resterende gezonde regio's. Zorg er nogmaals voor dat u compenseert voor het toegenomen verkeer en de extra aanvragen naar het resterende cluster.

Failoverteststrategie

Hoewel er momenteel geen mechanismen in AKS bestaan om een hele implementatieregio uit te schakelen voor testdoeleinden, kunt u Azure Chaos Studio Werkruimten gebruiken om een storing in de beschikbaarheidszone te simuleren voor de knooppuntgroepen van uw cluster.

Volgende stappen 

Als u een andere oplossing overweegt, raadpleegt u de volgende artikelen:

  • Laatst bijgewerkt om