Översikt över rekommenderad aktiv–aktiv-lösning för hög tillgänglighet 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 app med en enda region. 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 med en enda region, vilket garanterar affärskontinuitet och all datareplikering i regionerna gör att du kan återställa ditt senaste programtillstånd.

Även om det finns flera mönster som kan ge återställningsbarhet för en AKS-lösning, beskriver den här guiden den rekommenderade aktiv-aktiv-lösningen för 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 betjänar trafik.

Note

Följande användningsfall kan betraktas som standardpraxis i AKS. Det har granskats internt och granskats tillsammans med våra Microsoft partners.

Översikt över lösning för hög tillgänglighet med aktiv-aktiv-konfiguration

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?

Note

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 endast 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

Den aktiva lösningen för 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 din Azure Front Door konfiguration 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-and-spoke-nätverk per region: Ett regionalt hub-and-spoke-nä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 bilder även om en region upplever ett avbrott.

Failöverprocess

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 replik inte är tillgänglig, omdirigeras 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-kontroller kan kontrollera statusen för applikationen eller processen som körs i podden. Om podden inte svarar tar liveness-proben 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. Tänk på 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 eventuell 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 och kompensera för den ökade efterfrågan i regionen.
  • 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. Du skyddar dina AKS-noder i den här aktiv-aktiv-lösningen från att utgöra en enskild regional felpunkt genom att använda Azure Availability Zones. 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)

Vid ett fullständigt regionalt avbrott dirigerar Azure Front Door trafiken till de återstående fungerande regionerna. Se återigen till att kompensera för den ökade trafiken och de ökade förfrågningarna till det återstående klustret.

Strategi för redundanstestning

Det finns för närvarande inga mekanismer i AKS för att ta bort en hel distributionsregion i testsyfte, men du kan använda Azure Chaos Studio Arbetsytor för att simulera ett avbrott i tillgänglighetszonen för klustrets nodpooler.

Nästa steg

Om du överväger en annan lösning kan du läsa följande artiklar:

  • Uppdaterades senast