Översikt över aktiv-passiv haveriberedskapslösning 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. När regionen blir otillgänglig under en katastrof blir programmet 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.

Den här guiden beskriver en aktiv-passiv haveriberedskapslösning för AKS. I den här lösningen distribuerar vi två oberoende och identiska AKS-kluster till två parkopplade Azure-regioner med endast ett kluster som aktivt betjänar trafik.

Kommentar

Följande praxis har granskats internt och granskats tillsammans med våra Microsoft-partner.

Översikt över aktiv-passiv lösning

I den här haveriberedskapsmetoden har vi två oberoende AKS-kluster som distribueras i två Azure-regioner. Det är dock bara ett av klustren som aktivt hanterar trafik samtidigt. Det sekundära klustret (som inte aktivt betjänar trafik) innehåller samma konfigurations- och programdata som det primära klustret, men accepterar ingen trafik om den inte dirigeras av Azure Front Door Traffic Manager.

Scenarier och konfigurationer

Den här lösningen implementeras bäst när du är värd för program som är beroende av resurser, till exempel databaser, som aktivt hanterar trafik i en region. I scenarier där du behöver vara värd för tillståndslösa program som distribueras i båda regionerna, till exempel horisontell skalning, rekommenderar vi att du överväger en aktiv-aktiv lösning, eftersom aktiv-passiv innebär extra svarstid.

Komponenter

Den aktiva-passiva haveriberedskapslösningen använder många Azure-tjänster. Den här exempelarkitekturen omfattar följande komponenter:

Flera kluster och regioner: Du distribuerar flera AKS-kluster, var och en i en separat Azure-region. Under normala åtgärder dirigeras nätverkstrafiken till det primära AKS-klustret som anges i Azure Front Door-konfigurationen.

Konfigurerad klusterprioritering: Du anger en prioriteringsnivå mellan 1–5 för varje kluster (med 1 som högsta prioritet och 5 som lägsta prioritet). Du kan ange flera kluster till samma prioritetsnivå och ange vikten för varje kluster. Om det primära klustret blir otillgängligt dirigeras trafiken automatiskt till nästa region som valts i Azure Front Door. All trafik måste gå via Azure Front Door för att det här systemet ska fungera.

Azure Front Door: Azure Front Door lastbalanserar och dirigerar trafik till Azure Application Gateway-instansen i den primära regionen (klustret måste markeras med prioritet 1). I händelse av ett regionfel omdirigerar tjänsten trafik till nästa kluster i prioritetslistan.

Mer information finns i Prioritetsbaserad trafikroutning.

Hub-spoke-par: Ett hub-spoke-par distribueras för varje regional AKS-instans. Azure Firewall Manager-principer hanterar brandväggsreglerna i varje region.

Key Vault: Du etablerar ett Azure Key Vault i varje region för att lagra hemligheter och nycklar.

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:

• Översikt över aktiv aktiv lösning med hög tillgänglighet för Azure Kubernetes Service (AKS)
• Översikt över passiv kall lösning för Azure Kubernetes Service (AKS)