Aanbevolen overzicht van oplossing voor actieve en actieve hoge beschikbaarheid 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. In het geval van een noodgeval waardoor de regio niet meer beschikbaar is, 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.
Hoewel er meerdere patronen zijn die herstelmogelijkheden kunnen bieden voor een AKS-oplossing, bevat deze handleiding een overzicht van de aanbevolen oplossing voor hoge beschikbaarheid met actieve actieve beschikbaarheid voor AKS. Binnen deze oplossing implementeren we twee onafhankelijke en identieke AKS-clusters in twee gekoppelde Azure-regio's met beide clusters die actief verkeer bedienen.
Notitie
De volgende use case kan worden beschouwd als standaardpraktijk binnen AKS. Het is intern gecontroleerd en gecontroleerd in combinatie met onze Microsoft-partners.
Overzicht van oplossing voor actieve en actieve hoge beschikbaarheid
Deze oplossing is afhankelijk van twee identieke AKS-clusters die zijn geconfigureerd voor actief verkeer. U plaatst een globale traffic manager, zoals Azure Front Door, voor de twee clusters om verkeer over deze clusters te verdelen. U moet de clusters consistent configureren voor het hosten van een exemplaar van alle toepassingen die nodig zijn om de oplossing te laten functioneren.
Beschikbaarheidszones zijn een andere manier om hoge beschikbaarheid en fouttolerantie voor uw AKS-cluster binnen dezelfde regio te garanderen. Met beschikbaarheidszones kunt u uw clusterknooppunten verdelen over meerdere geïsoleerde locaties binnen een Azure-regio. Als er op deze manier één zone uitvalt vanwege een stroomstoring, hardwarestoring of netwerkprobleem, kan uw cluster uw toepassingen blijven uitvoeren en bedienen. Beschikbaarheidszones verbeteren ook de prestaties en schaalbaarheid van uw cluster door de latentie en conflicten tussen knooppunten te verminderen. Als u beschikbaarheidszones voor uw AKS-cluster wilt instellen, moet u de zonenummers opgeven bij het maken of bijwerken van uw knooppuntgroepen. Zie Wat zijn Azure-beschikbaarheidszones voor meer informatie?
Notitie
Veel regio's ondersteunen beschikbaarheidszones. Overweeg om regio's met beschikbaarheidszones te gebruiken om meer tolerantie en beschikbaarheid voor uw workloads te bieden. Zie Herstellen van een serviceonderbreking in de hele regio voor meer informatie.
Scenario's en configuraties
Deze oplossing wordt het beste geïmplementeerd bij het hosten van staatloze toepassingen en/of met andere technologieën die ook in beide regio's zijn geïmplementeerd, zoals horizontaal schalen. In scenario's waarin de gehoste toepassing afhankelijk is van resources, zoals databases, die actief in slechts één regio actief zijn, wordt u aangeraden in plaats daarvan een actief-passieve oplossing te implementeren voor potentiële kostenbesparingen, omdat actief-passief meer downtime heeft dan actief-actief.
Onderdelen
De oplossing voor actieve en actieve hoge beschikbaarheid maakt gebruik van veel Azure-services. In deze sectie worden alleen de onderdelen behandeld die uniek zijn voor deze architectuur met meerdere clusters. Zie de AKS-basislijnarchitectuur voor meer informatie over de resterende onderdelen.
Meerdere clusters en regio's: u implementeert meerdere AKS-clusters, elk in een afzonderlijke Azure-regio. Tijdens normale bewerkingen routeert uw Azure Front Door-configuratie netwerkverkeer tussen alle regio's. Als één regio niet beschikbaar is, wordt verkeer gerouteerd naar een regio met de snelste laadtijd voor de gebruiker.
Hub-spoke-netwerk per regio: er wordt een regionaal hub-spoke-netwerkpaar geïmplementeerd voor elk regionaal AKS-exemplaar. Azure Firewall Manager-beleid beheert het firewallbeleid in alle regio's.
Regionaal sleutelarchief: u richt Azure Key Vault in elke regio in om gevoelige waarden en sleutels op te slaan die specifiek zijn voor het AKS-exemplaar en om services te ondersteunen die in die regio zijn gevonden.
Azure Front Door: Azure Front Door-load balanceert en routeert verkeer naar een regionaal Azure-toepassing Gateway-exemplaar, dat zich vóór elk AKS-cluster bevindt. Met Azure Front Door is laag zeven globale routering mogelijk.
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:
Azure Kubernetes Service