Översikt över hög tillgänglighet och haveriberedskap för Azure Kubernetes Service (AKS)
När du skapar och hanterar program i molnet finns det alltid en risk för avbrott från avbrott och katastrofer. För att säkerställa affärskontinuitet (BC) måste du planera för hög tillgänglighet (HA) och haveriberedskap (DR).
Ha avser design och implementering av ett system eller en tjänst som är mycket tillförlitlig och har minimal stilleståndstid. Ha är en kombination av verktyg, tekniker och processer som säkerställer att ett system eller en tjänst är tillgänglig för att utföra sin avsedda funktion. HA är en viktig komponent i DR-planeringen. DR är processen att återställa från en katastrof och återställa affärsåtgärder till ett normalt tillstånd. DR är en delmängd av BC, vilket är processen att underhålla affärsfunktioner eller snabbt återuppta dem i händelse av ett större avbrott.
Den här artikeln beskriver några rekommenderade metoder för program som distribueras till AKS, men är inte på något sätt menat som en fullständig lista över möjliga lösningar.
Tekniköversikt
Ett Kubernetes-kluster är indelat i två komponenter:
- Kontrollplanet, som tillhandahåller kubernetes-kärntjänster och orkestrering av programarbetsbelastningar, och
- Noderna som kör dina programarbetsbelastningar.
När du skapar ett AKS-kluster skapar och konfigurerar Azure-plattformen automatiskt ett kontrollplan. AKS erbjuder två prisnivåer för klusterhantering: den kostnadsfria nivån och standardnivån. Mer information finns i Prisnivåer för kostnadsfria och standard för AKS-klusterhantering.
Kontrollplanet och dess resurser finns bara i den region där du skapade klustret. AKS tillhandahåller ett kontrollplan med en enda klientorganisation med en dedikerad API-server, schemaläggare osv. Du definierar antalet och storleken på noderna, och Azure-plattformen konfigurerar säker kommunikation mellan kontrollplanet och noderna. Interaktion med kontrollplanet sker via Kubernetes-API:er, till exempel kubectl eller Kubernetes-instrumentpanelen.
Om du vill köra dina program och stödtjänster behöver du en Kubernetes-nod. Ett AKS-kluster har minst en nod, en virtuell Azure-dator (VM) som kör Kubernetes-nodkomponenterna och containerkörningen. Storleken på den virtuella Azure-datorn för dina noder definierar processorer, minne, storlek och den tillgängliga lagringstypen (till exempel högpresterande SSD eller vanlig HÅRDDISK). Planera den virtuella datorn och lagringsstorleken kring om dina program kan kräva stora mängder cpu och minne eller lagring med höga prestanda. I AKS baseras VM-avbildningen för klustrets noder på Ubuntu Linux, Azure Linux eller Windows Server 2022. När du skapar ett AKS-kluster eller skalar ut antalet noder skapar och konfigurerar Azure-plattformen automatiskt det begärda antalet virtuella datorer.
Mer information om kluster- och arbetsbelastningskomponenter i AKS finns i Kubernetes kärnbegrepp för AKS.
Viktigt!
Regionala och globala resurser
Regionala resurser etableras som en del av en distributionsstämpel till en enda Azure-region. Dessa resurser delar ingenting med resurser i andra regioner, och de kan tas bort eller replikeras separat till andra regioner. Mer information finns i Regionala resurser.
Globala resurser delar systemets livslängd och de kan vara globalt tillgängliga inom ramen för en distribution i flera regioner. Mer information finns i Globala resurser.
Återställningsmål
En fullständig haveriberedskapsplan måste ange affärskrav för varje process som programmet implementerar:
- Mål för återställningspunkt (RPO) är den maximala varaktigheten för acceptabel dataförlust. RPO mäts i tidsenheter, till exempel minuter, timmar eller dagar.
- Mål för återställningstid (RTO) är den maximala varaktigheten för acceptabel stilleståndstid, med stilleståndstid som definieras av din specifikation. Om den acceptabla stilleståndstiden i en katastrof till exempel är åtta timmar är RTO åtta timmar.
Tillgänglighetszoner
Du kan använda tillgänglighetszoner för att sprida dina data över flera zoner i samma region. I en region är tillgänglighetszonerna tillräckligt nära för att ha anslutningar med låg latens till andra tillgänglighetszoner, men de är tillräckligt långt ifrån varandra för att minska sannolikheten för att fler än en kommer att påverkas av lokala avbrott eller väder. Mer information finns i Rekommendationer för användning av tillgänglighetszoner och regioner.
Zonindelad motståndskraft
AKS-kluster är motståndskraftiga mot zonfel. Om en zon misslyckas fortsätter klustret att köras i de återstående zonerna. Klustrets kontrollplan och noder är spridda över zonerna och Azure-plattformen hanterar automatiskt fördelningen av noderna. Mer information finns i AKS-zonresiliens.
Belastningsutjämning
Global belastningsutjämning
Globala belastningsutjämningstjänster distribuerar trafik mellan regionala serverdelar, moln eller lokala hybridtjänster. Dessa tjänster dirigerar slutanvändartrafik till närmaste tillgängliga serverdel. De reagerar också på ändringar i tjänstens tillförlitlighet eller prestanda för att maximera tillgänglighet och prestanda. Följande Azure-tjänster tillhandahåller global belastningsutjämning:
- Azure Front Door
- Azure Traffic Manager
- Azure Load Balancer mellan regioner
- Azure Kubernetes Fleet Manager
Regional belastningsutjämning
Regionala belastningsutjämningstjänster distribuerar trafik i virtuella nätverk mellan virtuella datorer eller zonindela och zonredundanta tjänstslutpunkter i en region. Följande Azure-tjänster tillhandahåller regional belastningsutjämning:
Överskådlighet
Du måste samla in data från program och infrastruktur för att möjliggöra effektiva åtgärder och maximerad tillförlitlighet. Azure tillhandahåller verktyg som hjälper dig att övervaka och hantera dina AKS-arbetsbelastningar. Mer information finns i Observerbarhetsresurser.
Omfångsdefinition
Programupptid blir viktigt när du hanterar AKS-kluster. Som standard ger AKS hög tillgänglighet genom att använda flera noder i en vm-skalningsuppsättning, men dessa noder skyddar inte systemet från ett regionfel. För att maximera drifttiden planerar du framåt för att upprätthålla affärskontinuitet och förbereda dig för haveriberedskap med hjälp av följande metodtips:
- Planera för AKS-kluster i flera regioner.
- Dirigera trafik över flera kluster med Hjälp av Azure Traffic Manager.
- Använd geo-replikering för dina containeravbildningsregister.
- Planera för programtillstånd i flera kluster.
- Replikera lagring över flera regioner.
Implementeringar av distributionsmodell
| Distributionsmodell | Fördelar | Nackdelar |
|---|---|---|
| Aktiv-aktiv | • Ingen dataförlust eller inkonsekvens under redundansväxling • Hög återhämtning • Bättre användning av resurser med högre prestanda |
• Komplex implementering och hantering • Högre kostnad • Kräver en lastbalanserare och form av trafikroutning |
| Aktiv-passiv | • Enklare implementering och hantering • Lägre kostnad • Kräver ingen lastbalanserare eller traffic manager |
• Potential för dataförlust eller inkonsekvens under redundansväxling • Längre återställningstid och stilleståndstid • Underutnyttjande av resurser |
| Passiv-kall | • Lägsta kostnad • Kräver inte synkronisering, replikering, lastbalanserare eller traffic manager • Lämplig för lågprioriterad, icke-kritisk arbetsbelastning |
• Hög risk för dataförlust eller inkonsekvens under redundansväxling • Längsta återställningstid och stilleståndstid • Kräver manuella åtgärder för att aktivera kluster och utlösa säkerhetskopiering |
Distributionsmodell för aktiv-aktiv hög tillgänglighet
I distributionsmodellen för aktiv-aktiv hög tillgänglighet (HA) har du två oberoende AKS-kluster distribuerade i två olika Azure-regioner (vanligtvis kopplade regioner, till exempel Kanada, centrala och Kanada, östra eller USA, östra 2 och USA, centrala) som aktivt hanterar trafik.
Med den här exempelarkitekturen:
- Du distribuerar två AKS-kluster i separata Azure-regioner.
- Under normal drift dirigerar nätverkstrafik mellan båda regionerna. Om en region blir otillgänglig dirigeras trafiken automatiskt till en region närmast den användare som utfärdade begäran.
- Det finns ett distribuerat hub-spoke-par för varje regional AKS-instans. Azure Firewall Manager-principer hanterar brandväggsreglerna i regionerna.
- Azure Key Vault etableras i varje region för att lagra hemligheter och nycklar.
- Azure Front Door lastbalanserar och dirigerar trafik till en regional Azure Application Gateway-instans, som ligger framför varje AKS-kluster.
- Regionala Log Analytics-instanser lagrar regionala nätverksmått och diagnostikloggar.
- Containeravbildningarna för arbetsbelastningen lagras i ett hanterat containerregister. Ett enda Azure Container Registry används för alla Kubernetes-instanser i klustret. Geo-replikering för Azure Container Registry möjliggör replikering av avbildningar till de valda Azure-regionerna och ger fortsatt åtkomst till avbildningar, även om en region upplever ett avbrott.
Om du vill skapa en aktiv-aktiv distributionsmodell i AKS utför du följande steg:
Skapa två identiska distributioner i två olika Azure-regioner.
Skapa två instanser av webbappen.
Skapa en Azure Front Door-profil med följande resurser:
- En slutpunkt.
- Två ursprungsgrupper, var och en med prioriteten en.
- En väg.
Begränsa nätverkstrafiken till webbapparna endast från Azure Front Door-instansen. 5. Konfigurera alla andra Azure-tjänster på serverdelen, till exempel databaser, lagringskonton och autentiseringsprovidrar.
Distribuera kod till båda webbapparna med kontinuerlig distribution.
Mer information finns i Översikt över rekommenderad aktiv-aktiv hög tillgänglighetslösning för AKS.
Distributionsmodell för aktiv-passiv haveriberedskap
I distributionsmodellen för aktiv-passiv haveriberedskap (DR) har du två oberoende AKS-kluster distribuerade i två olika Azure-regioner (vanligtvis kopplade regioner, till exempel Kanada, centrala och Kanada, östra eller USA, östra 2 och USA, centrala) som aktivt hanterar trafik. Endast ett av klustren hanterar aktivt trafik vid en viss tidpunkt. Det andra klustret innehåller samma konfigurations- och programdata som det aktiva klustret, men accepterar inte trafik om det inte dirigeras av en trafikhanterare.
Med den här exempelarkitekturen:
- Du distribuerar två AKS-kluster i separata Azure-regioner.
- Under normal drift dirigerar nätverkstrafiken till det primära AKS-klustret, som du angav i Azure Front Door-konfigurationen.
- Prioritet måste anges mellan 1-5 där 1 är högst och 5 är den lägsta.
- Du kan ange flera kluster till samma prioritetsnivå och ange vikten för varje.
- Om det primära klustret blir otillgängligt (haveri inträffar) dirigeras trafiken automatiskt till nästa region som valts i Azure Front Door.
- All trafik måste gå via Azure Front Door-trafikhanteraren för att det här systemet ska fungera.
- Azure Front Door dirigerar trafik till Azure App Gateway i den primära regionen (klustret måste markeras med prioritet 1). Om den här regionen misslyckas omdirigerar tjänsten trafik till nästa kluster i prioritetslistan.
- Regler kommer från Azure Front Door.
- Ett hub-spoke-par distribueras för varje regional AKS-instans. Azure Firewall Manager-principer hanterar brandväggsreglerna i regionerna.
- Azure Key Vault etableras i varje region för att lagra hemligheter och nycklar.
- Regionala Log Analytics-instanser lagrar regionala nätverksmått och diagnostikloggar.
- Containeravbildningarna för arbetsbelastningen lagras i ett hanterat containerregister. Ett enda Azure Container Registry används för alla Kubernetes-instanser i klustret. Geo-replikering för Azure Container Registry möjliggör replikering av avbildningar till de valda Azure-regionerna och ger fortsatt åtkomst till avbildningar, även om en region upplever ett avbrott.
Om du vill skapa en aktiv-passiv distributionsmodell i AKS utför du följande steg:
Skapa två identiska distributioner i två olika Azure-regioner.
Konfigurera regler för automatisk skalning för det sekundära programmet så att det skalas till samma instansantal som det primära när den primära regionen blir inaktiv. Även om den är inaktiv behöver den inte skalas upp. Detta bidrar till att minska kostnaderna.
Skapa två instanser av webbprogrammet, med en på varje kluster.
Skapa en Azure Front Door-profil med följande resurser:
- En slutpunkt.
- En ursprungsgrupp med prioriteten en för den primära regionen.
- En andra ursprungsgrupp med prioriteten två för den sekundära regionen.
- En väg.
Begränsa nätverkstrafiken till webbprogrammen från endast Azure Front Door-instansen.
Konfigurera alla andra Azure-tjänster på serverdelen, till exempel databaser, lagringskonton och autentiseringsprovidrar.
Distribuera kod till båda webbprogrammen med kontinuerlig distribution.
Mer information finns i översikten över rekommenderad aktiv-passiv haveriberedskapslösning för AKS.
Distributionsmodell för passiv-kall redundans
Distributionsmodellen för passiv-kall redundans konfigureras på samma sätt som distributionsmodellen för aktiv-passiv haveriberedskap, förutom att klustren förblir inaktiva tills en användare aktiverar dem i händelse av en katastrof. Vi anser att den här metoden är utanför omfånget eftersom den omfattar en liknande konfiguration som aktiv-passiv, men med den extra komplexiteten i manuella åtgärder för att aktivera klustret och utlösa en säkerhetskopia.
Med den här exempelarkitekturen:
- Du skapar två AKS-kluster, helst i olika regioner eller zoner för bättre återhämtning.
- När du behöver redundansväxla aktiverar du distributionen för att ta över trafikflödet.
- Om det primära passiva klustret slutar fungera måste du aktivera det kalla klustret manuellt för att ta över trafikflödet.
- Det här villkoret måste anges antingen med manuella indata varje gång eller en viss händelse enligt din beskrivning.
- Azure Key Vault etableras i varje region för att lagra hemligheter och nycklar.
- Regionala Log Analytics-instanser lagrar regionala nätverksmått och diagnostikloggar för varje kluster.
Om du vill skapa en distributionsmodell för passiv-kall redundans i AKS utför du följande steg:
- Skapa två identiska distributioner i olika zoner/regioner.
- Konfigurera regler för automatisk skalning för det sekundära programmet så att det skalas till samma instansantal som det primära när den primära regionen blir inaktiv. Även om den är inaktiv behöver den inte skalas upp, vilket bidrar till att minska kostnaderna.
- Skapa två instanser av webbprogrammet, med en på varje kluster.
- Konfigurera alla andra Azure-tjänster på serverdelen, till exempel databaser, lagringskonton och autentiseringsprovidrar.
- Ange ett villkor när det kalla klustret ska utlösas. Du kan använda en lastbalanserare om du behöver det.
Mer information finns i översikten över den rekommenderade passiv-kalla redundanslösningen för AKS.
Kvoter och begränsningar för tjänsten
AKS anger standardgränser och kvoter för resurser och funktioner, inklusive användningsbegränsningar för vissa VM-SKU:er.
| Resurs | Gräns |
|---|---|
| Maximalt antal kluster per prenumeration | 5000 Obs! Sprida kluster mellan olika regioner för att ta hänsyn till Begränsningar för Azure API-begränsning |
| Maximalt antal noder per kluster med VM-skalningsuppsättningar och Standard Load Balancer SKU | 5 000 över alla nodpooler Obs! Om du inte kan skala upp till 5 000 noder per kluster kan du läsa Metodtips för stora kluster. |
| Maximalt antal noder per nodpool (vm-skalningsuppsättningar nodpooler) | 1000 |
| Maximalt antal nodpooler per kluster | 100 |
| Maximalt antal poddar per nod: med Kubenet-nätverksprogram 1 | Max: 250 Standard för Azure CLI: 110 Standard för Azure Resource Manager-mall: 110 Standard för azure-portaldistribution: 30 |
| Maximalt antal poddar per nod: med Azure Container Networking Interface (Azure CNI)1 | Max: 250 Högsta rekommenderade för Windows Server-containrar: 110 Standard: 30 |
| Open Service Mesh (OSM) AKS-tillägg | Kubernetes-klusterversion: VERSIONER som stöds av AKS OSM-styrenheter per kluster: 1 Poddar per OSM-styrenhet: 1600 Kubernetes-tjänstkonton som hanteras av OSM: 160 |
| Maximalt belastningsutjämnat kubernetes-tjänster per kluster med Standard Load Balancer SKU | 300 |
| Maximalt antal noder per kluster med tillgänglighetsuppsättningar för virtuella datorer och basic load balancer-SKU | 100 |
1 Windows Server-containrar måste använda plugin-programmet för Azure CNI-nätverk. Kubenet stöds inte för Windows Server-containrar.
| Kubernetes-kontrollplansnivå | Gräns |
|---|---|
| Standard-nivå | Skalar automatiskt Kubernetes API-server baserat på belastning. Större kontrollplanskomponentgränser och API-server/etc-instanser. |
| Kostnadsfri nivå | Begränsade resurser med gränsen för inflight-begäranden på 50 muterande och 100 skrivskyddade anrop. Rekommenderad nodgräns på 10 noder per kluster. Bäst för experimentering, inlärning och enkel testning. Rekommenderas inte för produktions-/kritiska arbetsbelastningar. |
Mer information finns i AKS-tjänstkvoter och -gränser.
Backup
Azure Backup stöder säkerhetskopiering av AKS-klusterresurser och beständiga volymer som är kopplade till klustret med hjälp av ett tillägg för säkerhetskopiering. Backup-valvet kommunicerar med AKS-klustret via tillägget för att utföra säkerhetskopierings- och återställningsåtgärder.
Mer information finns i följande artiklar: