Översikt över passiv-kall lö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 passiv-kall lö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 hanterar trafik när programmet behövs.
Kommentar
Följande praxis har granskats internt och granskats tillsammans med våra Microsoft-partner.
Översikt över passiv-kall lösning
I den här metoden har vi två oberoende AKS-kluster som distribueras i två Azure-regioner. När programmet behövs aktiverar vi det passiva klustret för att ta emot trafik. Om det passiva klustret slutar fungera måste vi aktivera det kalla klustret manuellt för att ta över trafikflödet. Vi kan ange det här villkoret via en manuell inmatning varje gång eller för att ange en viss händelse.
Scenarier och konfigurationer
Den här lösningen implementeras bäst som en "använd efter behov"-arbetsbelastning, vilket är användbart för scenarier som kräver att arbetsbelastningar körs vid specifika tidpunkter på dagen eller körs på begäran. Exempel på användningsfall för en passiv-kall metod är:
- Ett tillverkningsföretag som behöver köra en komplex och resursintensiv simulering på en stor datamängd. I det här fallet finns det passiva klustret i en molnregion som erbjuder högpresterande databehandling och lagringstjänster. Det passiva klustret används bara när simuleringen utlöses av användaren eller av ett schema. Om klustret inte fungerar vid utlösande kan det kalla klustret användas som en säkerhetskopia och arbetsbelastningen kan köras på det i stället.
- En myndighet som behöver upprätthålla en säkerhetskopia av sina kritiska system och data i händelse av en cyberattack eller en naturkatastrof. I det här fallet finns det passiva klustret på en säker och isolerad plats som inte är tillgänglig för allmänheten.
Komponenter
Den passiv-kalla 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. När appen behövs aktiveras det passiva klustret för att ta emot nätverkstrafik.
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.
Hub-spoke-par: Ett hub-spoke-par distribueras för varje regional AKS-instans. Azure Firewall Manager-principer hanterar brandväggsreglerna i varje region.
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 det passiva klustret inte fungerar korrekt på grund av ett problem i den specifika Azure-regionen kan du aktivera det kalla klustret och omdirigera all trafik till klustrets region. Du kan använda den här processen medan det passiva klustret inaktiveras tills det börjar fungera igen. Det kan ta några minuter innan det kalla klustret är online eftersom det har inaktiverats och behöver slutföra installationsprocessen. Den här metoden är inte idealisk för tidskänsliga program. I så fall rekommenderar vi att du överväger en aktiv-aktiv redundansväxling.
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: