Delen via

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

  • Artikel

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 gevoelig voor een noodgeval met één regio, wat de bedrijfscontinuïteit garandeert en elke gegevensreplicatie in de regio's kunt u uw laatste toepassingsstatus 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 verkeer actief verwerkt.

Notitie

De volgende praktijk is intern gecontroleerd 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 biedt echter op elk 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.

Onderdelen

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 beschikbaar is, wordt verkeer automatisch gerouteerd naar de volgende regio die is geselecteerd in Azure Front Door. Al het verkeer moet via Azure Front Door lopen om dit systeem te laten werken.

Azure Front Door: Azure Front Door-load balanceert en routeert verkeer naar het Azure-toepassing Gateway-exemplaar 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: er wordt een hub-spoke-paar geïmplementeerd voor elk regionaal AKS-exemplaar. Azure Firewall Manager-beleid beheert de firewallregels voor elke regio.

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 containerinstallatiekopieën voor de workload worden opgeslagen in een beheerd containerregister. 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 installatiekopieën, zelfs als een regio een storing ondervindt.

Failoverproces

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 er geen verkeer beschikbaar is, wordt verkeer gerouteerd tussen de resterende replica's. De Kubernetes ReplicaSet probeert het opgegeven aantal replica's actief te houden. Als één exemplaar uitvalt, moet een nieuw exemplaar opnieuw worden gemaakt. Liveness-tests kunnen de status van de toepassing controleren of het proces dat wordt uitgevoerd in de pod. Als de pod niet reageert, verwijdert de livenesstest de pod, waardoor de ReplicaSet wordt gedwongen 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 het Azure Front Door-exemplaar al het verkeer naar de resterende statusregio'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 CNI (Azure Container Network Interface) gebruikt, moet u ervoor zorgen dat u een subnet hebt dat alle pod-IP's kan ondersteunen met een piek in de belasting van het verkeer.
  • Gebruik de horizontale automatische schaalaanpassing voor pods om het aantal podreplica's te verhogen om de toegenomen regionale vraag te compenseren.
  • 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 uw AKS-knooppunten te beschermen tegen regionale storingen op één punt. 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)

In een volledige regionale fout routeert Azure Front Door verkeer naar de resterende gezonde regio's. Zorg er opnieuw voor dat u meer verkeer en aanvragen naar het resterende cluster compenseert.

Strategie voor failovertests

Hoewel er momenteel geen mechanismen beschikbaar zijn binnen AKS om een hele implementatieregio uit te schakelen voor testdoeleinden, biedt Azure Chaos Studio de mogelijkheid om een chaos-experiment op uw cluster te maken.

Volgende stappen

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