Delen via

Overzicht van passieve koude oplossingen voor AKS (Azure Kubernetes Service)

  • 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.

In deze handleiding wordt een passieve koude oplossing voor AKS beschreven. 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 wanneer de toepassing nodig is.

Notitie

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

Overzicht van passieve koude oplossingen

In deze benadering hebben we twee onafhankelijke AKS-clusters die in twee Azure-regio's worden geïmplementeerd. Wanneer de toepassing nodig is, activeren we het passieve cluster om verkeer te ontvangen. Als het passieve cluster uitvalt, moeten we het koude cluster handmatig activeren om de verkeersstroom over te nemen. We kunnen deze voorwaarde elke keer instellen via een handmatige invoer of om een bepaalde gebeurtenis op te geven.

Scenario's en configuraties

Deze oplossing wordt het beste geïmplementeerd als een workload 'gebruik indien nodig', wat handig is voor scenario's waarvoor workloads op specifieke tijdstippen van de dag moeten worden uitgevoerd of op aanvraag moeten worden uitgevoerd. Voorbeelden van gebruiksvoorbeelden voor een passieve koude benadering zijn:

  • Een productiebedrijf dat een complexe en resource-intensieve simulatie moet uitvoeren op een grote gegevensset. In dit geval bevindt het passieve cluster zich in een cloudregio die krachtige computing- en opslagservices biedt. Het passieve cluster wordt alleen gebruikt wanneer de simulatie wordt geactiveerd door de gebruiker of volgens een schema. Als het cluster niet werkt bij het activeren, kan het koude cluster worden gebruikt als back-up en kan de workload erop worden uitgevoerd.
  • Een overheidsinstantie die een back-up van zijn kritieke systemen en gegevens moet onderhouden in geval van een cyberaanval of natuurramp. In dit geval bevindt het passieve cluster zich op een veilige en geïsoleerde locatie die niet toegankelijk is voor het publiek.

Onderdelen

De oplossing voor passief-koude noodherstel 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. Wanneer de app nodig is, wordt het passieve cluster geactiveerd om netwerkverkeer te ontvangen.

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.

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.

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 het passieve cluster niet goed werkt vanwege een probleem in de specifieke Azure-regio, kunt u het koude cluster activeren en al het verkeer omleiden naar de regio van dat cluster. U kunt dit proces gebruiken terwijl het passieve cluster is gedeactiveerd totdat het opnieuw werkt. Het koude cluster kan enkele minuten duren om online te komen, omdat het is uitgeschakeld en het installatieproces moet voltooien. Deze benadering is niet ideaal voor tijdgevoelige toepassingen. In dat geval raden we u aan een actief-actieve failover te overwegen.

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: