Rekommenderad lösning för aktiv-aktiv hög tillgänglighet – översikt för Azure Kubernetes Service (AKS)
När du skapar ett program i Azure Kubernetes Service (AKS) och väljer en Azure-region när resursen skapas är det en enskild regionapp. I händelse av en katastrof som gör att regionen blir otillgänglig blir ditt program också otillgängligt. Om du skapar en identisk distribution i en sekundär Azure-region blir ditt program mindre känsligt för en katastrof i en enda region, vilket garanterar affärskontinuitet och all datareplikering i regionerna gör att du kan återställa ditt senaste programtillstånd.
Det finns flera mönster som kan ge återställning för en AKS-lösning, men den här guiden beskriver den rekommenderade lösningen för aktiv-aktiv hög tillgänglighet för AKS. I den här lösningen distribuerar vi två oberoende och identiska AKS-kluster till två parkopplade Azure-regioner med båda kluster som aktivt hanterar trafik.
Kommentar
Följande användningsfall kan betraktas som standardpraxis i AKS. Den har granskats internt och granskats tillsammans med våra Microsoft-partner.
Översikt över lösning för aktiv-aktiv hög tillgänglighet
Den här lösningen förlitar sig på två identiska AKS-kluster som har konfigurerats för att aktivt hantera trafik. Du placerar en global trafikhanterare, till exempel Azure Front Door, framför de två klustren för att distribuera trafik över dem. Du måste konsekvent konfigurera klustren så att de är värdar för en instans av alla program som krävs för att lösningen ska fungera.
Tillgänglighetszoner är ett annat sätt att säkerställa hög tillgänglighet och feltolerans för ditt AKS-kluster i samma region. Med tillgänglighetszoner kan du distribuera dina klusternoder över flera isolerade platser i en Azure-region. På så sätt kan klustret fortsätta att köra och hantera dina program om en zon slutar fungera på grund av ett strömavbrott, maskinvarufel eller nätverksproblem. Tillgänglighetszoner förbättrar också prestanda och skalbarhet för klustret genom att minska svarstiden och konkurrensen mellan noder. Om du vill konfigurera tillgänglighetszoner för ditt AKS-kluster måste du ange zonnumren när du skapar eller uppdaterar nodpoolerna. Mer information finns i Vad är Azure-tillgänglighetszoner?
Kommentar
Många regioner stöder tillgänglighetszoner. Överväg att använda regioner med tillgänglighetszoner för att ge mer återhämtning och tillgänglighet för dina arbetsbelastningar. Mer information finns i Återställa från ett avbrott i hela regionen.
Scenarier och konfigurationer
Den här lösningen implementeras bäst när du är värd för tillståndslösa program och/eller med andra tekniker som också distribueras i båda regionerna, till exempel horisontell skalning. I scenarier där det värdbaserade programmet är beroende av resurser, till exempel databaser, som aktivt bara finns i en region, rekommenderar vi i stället att du implementerar en aktiv-passiv lösning för potentiella kostnadsbesparingar, eftersom aktiv-passiv har mer stilleståndstid än aktiv-aktiv.
Komponenter
Lösningen för aktiv-aktiv hög tillgänglighet använder många Azure-tjänster. Det här avsnittet beskriver endast de komponenter som är unika för den här arkitekturen för flera kluster. Mer information om de återstående komponenterna finns i AKS-baslinjearkitekturen.
Flera kluster och regioner: Du distribuerar flera AKS-kluster, var och en i en separat Azure-region. Under normal drift dirigerar Azure Front Door-konfigurationen nätverkstrafik mellan alla regioner. Om en region blir otillgänglig dirigeras trafiken till en region med den snabbaste inläsningstiden för användaren.
Hub-spoke-nätverk per region: Ett regionalt nav-ekernätverkspar distribueras för varje regional AKS-instans. Azure Firewall Manager-principer hanterar brandväggsprinciperna i alla regioner.
Regionalt nyckelarkiv: Du etablerar Azure Key Vault i varje region för att lagra känsliga värden och nycklar som är specifika för AKS-instansen och för att stödja tjänster som finns i den regionen.
Azure Front Door: Azure Front Door lastbalanserar och dirigerar trafik till en regional Azure Application Gateway-instans , som finns framför varje AKS-kluster. Azure Front Door möjliggör global routning på nivå sju .
Log Analytics: Regionala Log Analytics-instanser lagrar regionala nätverksmått och diagnostikloggar. En delad instans lagrar mått och diagnostikloggar för alla AKS-instanser.
Container Registry: Containeravbildningarna för arbetsbelastningen lagras i ett hanterat containerregister. Med den här lösningen används en enda Azure Container Registry-instans för alla Kubernetes-instanser i klustret. Med geo-replikering för Azure Container Registry kan du replikera avbildningar till de valda Azure-regionerna och ge fortsatt åtkomst till avbildningar även om en region upplever ett avbrott.
Redundansväxling
Om en tjänst eller tjänstkomponent blir otillgänglig i en region ska trafiken dirigeras till en region där tjänsten är tillgänglig. En arkitektur för flera regioner innehåller många olika felpunkter. I det här avsnittet tar vi upp potentiella felpunkter.
Programpoddar (regionala)
Ett Kubernetes-distributionsobjekt skapar flera repliker av en podd (ReplicaSet). Om en inte är tillgänglig dirigeras trafiken mellan de återstående replikerna. Kubernetes ReplicaSet försöker hålla det angivna antalet repliker igång. Om en instans slutar fungera bör en ny instans återskapas. Liveness-avsökningar kan kontrollera tillståndet för programmet eller processen som körs i podden. Om podden inte svarar tar liveness-avsökningen bort podden, vilket tvingar ReplicaSet att skapa en ny instans.
Mer information finns i Kubernetes ReplicaSet.
Programpoddar (globala)
När en hel region blir otillgänglig är poddarna i klustret inte längre tillgängliga för att hantera begäranden. I det här fallet dirigerar Azure Front Door-instansen all trafik till de återstående hälsoregionerna. Kubernetes-klustren och poddarna i dessa regioner fortsätter att hantera begäranden. Kom ihåg följande vägledning för att kompensera för ökad trafik och förfrågningar till det återstående klustret:
- Kontrollera att nätverks- och beräkningsresurserna har rätt storlek för att absorbera en plötslig ökning av trafiken på grund av regionredundans. När du till exempel använder Azure Container Network Interface (CNI) ser du till att du har ett undernät som kan stödja alla podd-IP-adresser med en spikad trafikbelastning.
- Använd horizontal pod autoscaler för att öka antalet poddrepliker för att kompensera för den ökade regionala efterfrågan.
- Använd AKS Cluster Autoscaler för att öka antalet Kubernetes-instansnoder för att kompensera för den ökade regionala efterfrågan.
Kubernetes-nodpooler (regionala)
Ibland kan lokaliserade fel uppstå för beräkningsresurser, till exempel att strömmen blir otillgänglig i ett enda rack med Azure-servrar. Om du vill skydda dina AKS-noder från att bli ett regionalt fel med en enskild punkt använder du Azure Tillgänglighetszoner. Tillgänglighetszoner ser till att AKS-noder i varje tillgänglighetszon är fysiskt åtskilda från dem som definieras i en annan tillgänglighetszon.
Kubernetes-nodpooler (global)
I ett fullständigt regionalt fel dirigerar Azure Front Door trafik till de återstående felfria regionerna. Se återigen till att kompensera för ökad trafik och förfrågningar till det återstående klustret.
Strategi för redundanstestning
Det finns för närvarande inga tillgängliga mekanismer i AKS för att ta bort en hel distributionsregion i testsyfte, men Azure Chaos Studio erbjuder möjligheten att skapa ett kaosexperiment i klustret.
Nästa steg
Om du överväger en annan lösning kan du läsa följande artiklar: