AKS-baslinje för kluster i flera regioner

Den här arkitekturen beskriver hur du kör flera instanser av ett AkS-kluster (Azure Kubernetes Service) i flera regioner i en aktiv/aktiv konfiguration med hög tillgänglighet.

Den här arkitekturen bygger på AKS-baslinjearkitekturen, Microsofts rekommenderade startpunkt för AKS-infrastrukturen. AKS-baslinjen beskriver infrastrukturella funktioner som Microsoft Entra-arbetsbelastnings-ID, begränsningar för ingress och utgående trafik, resursgränser och andra säkra konfigurationer av AKS-infrastruktur. Dessa infrastrukturdetaljer beskrivs inte i det här dokumentet. Vi rekommenderar att du bekantar dig med AKS-baslinjen innan du fortsätter med innehållet i flera regioner.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Komponenter

Många komponenter och Azure-tjänster används i den här AKS-arkitekturen i flera regioner. Endast de komponenter som är unika för den här arkitekturen för flera kluster visas här. Mer information finns i ARKITEKTURen för AKS-baslinje.

• regionala AKS-kluster: flera AKS- kluster distribueras, var och en i en separat Azure-region. Under normal drift dirigeras nätverkstrafik mellan alla regioner. Om en region blir otillgänglig dirigeras trafiken till en återstående region närmast den användare som utfärdade begäran.
• Regionala nav-ekernätverk: Ett regionalt virtuellt nav-ekernätverk distribueras för varje regional AKS-instans. Azure Firewall Manager används principer för att hantera brandväggsprinciper i alla regioner.
• Regionalt nyckelvalv:Azure Key Vault- etableras i varje region. Nyckelvalv används för att lagra känsliga värden och nycklar som är specifika för AKS-klustret och stödtjänster som finns i den regionen.
• Flera loggarbetsytor: Regionala Log Analytics- arbetsytor används för att lagra regionala nätverksmått och diagnostikloggar. Dessutom används en delad Log Analytics-instans för att lagra mått och diagnostikloggar för alla AKS-instanser.
• AKS-flotta: En Azure Kubernetes Fleet Manager distribueras för att samordna både uppdateringar av Kubernetes-klusterversioner och uppdateringar av nodavbildningsversioner i vart och ett av de regionala AKS-klustren.
• Fleet Hub-kluster (Microsoft-hanterat):Alternativt kan ett enda Azure Kubernetes Fleet Manager-hubbkluster distribueras för att stödja specifika funktioner i flottor, till exempel spridning av arbetsbelastningar. Hubbklustret är en regionalt begränsad Azure-resurs som hjälper till att hantera arbetsbelastningsspridning och belastningsutjämning i flera medlemskluster. Det är bäst att distribuera hubbklustret som ett privat hubbkluster, som måste kunna nås från medlemskluster för att stödja pulsslagssignaler och utföra konfigurationsavstämningsprocesser.
• Global Azure Front Door-profil:Azure Front Door- används för att belastningsutjämning och dirigera trafik till en regional Azure Application Gateway-instans, som finns framför varje AKS-kluster. Azure Front Door möjliggör global routning i layer 7, som båda krävs för den här arkitekturen.
• Globalt containerregister: Containeravbildningarna för arbetsbelastningen lagras i ett hanterat containerregister. I den här arkitekturen används ett enda Azure Container Registry 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 drabbas av ett avbrott.

Alternativ

Den här lösningen använder Azure Kubernetes Fleet Manager. Flottor möjliggör en rad funktioner för att hantera flera kluster, med fokus på att minska driftkostnaderna dag 2 genom att tillhandahålla ett kontrollplan som kan samordna aktiviteter över flera kluster. Fördelarna med Fleet Manager ökar i takt med att antalet kluster i din flotta växer.

I den här lösningen samordnar flottan Kubernetes-versionsuppdateringar över flera kluster samt uppdateringar av nodavbildningsversioner. Dessa funktioner kräver inte att ett hubbkluster distribueras. Du kan välja att låta varje kluster utföra Kubernetes-version och nodavbildningsuppdateringar oberoende av varandra, vilket inte kräver en flotta. Men om du gör det kommer kluster sannolikt att få versionsuppdateringar vid olika tidpunkter, och det kan bli svårt att verifiera din arbetsbelastning och konfiguration med flera versioner i produktionsmiljön samtidigt.

Du kan också använda en flotta för samordning av arbetsbelastningsdistribution, vilket kräver att du lägger till ett hubbkluster. Distributioner av arbetsbelastningar beskrivs mer detaljerat senare i den här artikeln.

Designmönster

Den här arkitekturen använder två mönster för molndesign:

• Geodes (geografiska noder), där alla regioner kan hantera alla begäranden.
• Distributionsstämplar, där flera oberoende kopior av ett program eller en programkomponent distribueras från en enda källa, till exempel en distributionsmall.

Överväganden för Geode-mönster

När du väljer regioner för att distribuera varje AKS-kluster bör du överväga regioner nära arbetsbelastningskonsumenten eller dina kunder. Överväg också att använda replikering mellan regioner. Replikering mellan regioner replikerar asynkront samma program och data i andra Azure-regioner för haveriberedskapsskydd. När klustret skalas bortom två regioner fortsätter du att planera för replikering mellan regioner för varje par AKS-kluster.

Inom varje region sprids noder i AKS-nodpoolerna över flera tillgänglighetszoner för att förhindra problem på grund av zonfel. Tillgänglighetszoner stöds i en begränsad uppsättning regioner, vilket påverkar placering av regionala kluster. Mer information om AKS och tillgänglighetszoner, inklusive en lista över regioner som stöds, finns i AKS-tillgänglighetszoner.

Överväganden för distributionsstämpel

När du hanterar en AKS-lösning för flera regioner distribuerar du flera AKS-kluster i flera regioner. Vart och ett av dessa kluster betraktas som en stämpel. Om det uppstår ett regionalt fel, eller om du behöver lägga till mer kapacitet eller regional närvaro för dina kluster, kan du behöva skapa en ny stämpelinstans. När du väljer en process för att skapa och hantera distributionsstämplar är det viktigt att tänka på följande:

• Välj lämplig teknik för stämpeldefinitioner som möjliggör generaliserad konfiguration. Du kan till exempel använda Bicep för att definiera infrastruktur som kod.
• Ange instansspecifika värden med hjälp av en distributionsindatamekanism, till exempel variabler eller parameterfiler.
• Välj distributionsverktyg som möjliggör flexibel, repeterbar och idempotent distribution.
• I en aktiv/aktiv stämpelkonfiguration bör du överväga hur trafiken balanseras mellan varje stämpel. Den här arkitekturen använder Azure Front Door för global belastningsutjämning.
• När stämplar läggs till och tas bort från samlingen bör du överväga kapacitets- och kostnadsbekymmer.
• Fundera på hur du kan få insyn i och övervaka samlingen av stämplar som en enda enhet.

Vart och ett av dessa objekt beskrivs med specifik vägledning i följande avsnitt.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Klusterdistribution och startsteg

När du distribuerar flera Kubernetes-kluster i konfigurationer med hög tillgänglighet och geografiskt distribuerade konfigurationer är det viktigt att överväga summan av varje Kubernetes-kluster som en kopplad enhet. Du kanske vill utveckla koddrivna strategier för automatisk distribution och konfiguration för att säkerställa att varje Kubernetes-instans är så identisk som möjligt. Överväg strategier för att skala ut och in, bland annat genom att lägga till eller ta bort andra Kubernetes-kluster. Din design och distributions- och konfigurationsplan bör ta hänsyn till avbrott i tillgänglighetszonen, regionala fel och andra vanliga scenarier.

Klusterdefinition

Du har många alternativ för att distribuera ett Azure Kubernetes Service-kluster. Modulen Azure Portal, Azure CLI och Azure PowerShell är alla anständiga alternativ för att distribuera enskilda eller icke-kopplade AKS-kluster. Dessa metoder kan dock innebära utmaningar när du arbetar med många nära kopplade AKS-kluster. Om du till exempel använder Azure Portal öppnas möjligheten till felkonfiguration på grund av missade steg eller konfigurationsalternativ som inte är tillgängliga. Distributionen och konfigurationen av många kluster som använder portalen är en tidskrävande process som kräver fokus från en eller flera tekniker. Om du använder Azure CLI eller Azure PowerShell kan du skapa en repeterbar och automatiserad process med hjälp av kommandoradsverktygen. Ansvaret för idempotens, distributionsfelkontroll och återställning av fel ligger dock på dig och de skript som du skapar.

När du arbetar med flera AKS-instanser rekommenderar vi att du överväger infrastruktur som kodlösningar, till exempel Bicep, Azure Resource Manager-mallar eller Terraform. Infrastruktur som kodlösningar tillhandahåller en automatiserad, skalbar och idempotent distributionslösning. Du kan till exempel använda en Bicep-fil för lösningens delade tjänster och en annan för AKS-kluster och andra regionala tjänster. Om du använder infrastruktur som kod kan en distributionsstämpel definieras med generaliserade konfigurationer som nätverk, auktorisering och diagnostik. En distributionsparameterfil kan tillhandahållas med regionspecifika värden. Med den här konfigurationen kan en enda mall användas för att distribuera en nästan identisk stämpel i alla regioner.

Kostnaden för att utveckla och underhålla infrastruktur som kodtillgångar kan vara kostsam. I vissa fall kan kostnaden för att definiera infrastruktur som kod uppväga fördelarna, till exempel när du har ett mycket litet (t.ex. 2 eller 3) och oförändrat antal AKS-instanser. I dessa fall är det acceptabelt att använda en mer imperativ metod, till exempel med kommandoradsverktyg eller till och med manuella metoder med Azure Portal.

Klusterdistribution

När klusterstämpeln har definierats har du många alternativ för att distribuera enskilda eller flera stämpelinstanser. Vår rekommendation är att använda modern teknik för kontinuerlig integrering, till exempel GitHub Actions eller Azure Pipelines. Fördelarna med kontinuerliga integrationsbaserade distributionslösningar är:

• Kodbaserade distributioner som gör att stämplar kan läggas till och tas bort med hjälp av kod
• Integrerade testfunktioner
• Integrerade miljö- och mellanlagringsfunktioner
• Integrerade lösningar för hantering av hemligheter
• Integrering med källkontroll för både programkod och distributionsskript och mallar
• Distributionshistorik och loggning
• Åtkomstkontroll och granskningsfunktioner, för att kontrollera vem som kan göra ändringar och under vilka förutsättningar

När nya stämplar läggs till eller tas bort från det globala klustret måste distributionspipelinen uppdateras för att förbli konsekvent. En metod är att distribuera varje regions resurser som ett enskilt steg i ett GitHub Actions-arbetsflöde. Den här konfigurationen är enkel eftersom varje klusterinstans är tydligt definierad i distributionspipelinen. Den här konfigurationen omfattar vissa administrativa kostnader för att lägga till och ta bort kluster från distributionen.

Ett annat alternativ är att skapa affärslogik för att skapa kluster baserat på en lista över önskade platser eller andra indikerar datapunkter. Distributionspipelinen kan till exempel innehålla en lista över önskade regioner. Ett steg i pipelinen kan sedan loopa igenom den här listan och distribuera ett kluster till varje region som finns i listan. Nackdelen med den här konfigurationen är komplexiteten i distributionsgeneraliseringen och att varje klusterstämpel inte uttryckligen beskrivs i distributionspipelinen. Den positiva fördelen är att det blir en enkel uppdatering av listan över önskade regioner att lägga till eller ta bort klusterstämplar från pipelinen.

När ett kluster har skapats måste det registreras i flottan som ett medlemskluster. Det här steget kan slutföras genom att distribuera en Resource Manager-resurs av typen Microsoft.ContainerService/fleets/members, som refererar till medlemsklustrets resurs-ID. När medlemsklustret har registrerats i flottan kan det läggas till för att uppdatera körningar och använda andra flottfunktioner som du konfigurerar.

Om du tar bort en klusterstämpel från distributionspipelinen inaktiveras inte alltid stämpelns resurser. Beroende på distributionslösningen och konfigurationen kan du behöva ett extra steg för att inaktivera AKS-instanserna och andra Azure-resurser. Överväg att använda distributionsstackar för att aktivera fullständig livscykelhantering av Azure-resurser, inklusive rensning när du inte behöver dem längre.

Klusterstövlar

När varje Kubernetes-instans eller stämpel har distribuerats måste klusterkomponenter som ingresskontrollanter, identitetslösningar och arbetsbelastningskomponenter distribueras och konfigureras. Du kan behöva skapa Kubernetes-namnområden, och du måste också överväga att tillämpa principer för säkerhet, åtkomst och styrning i klustret. Dessa åtgärder kallas bootstrapping av klustret för att förbereda för arbetsbelastningar som ska distribueras till det.

På samma sätt som för distribution kan det bli svårt att hantera konfigurationer i flera Kubernetes-instanser manuellt. Om du använder ett hubbkluster med Azure Kubernetes Fleet Manager kan du distribuera en del av konfigurationen för bootstrapping i din flotta, till exempel namnområden. Andra bootstrapping-komponenter kräver dock en annan distributionsmetod.

Du bör överväga något av följande alternativ för att tillämpa bootstrap-konfiguration och princip i stor skala.

GitOps

I stället för att konfigurera Kubernetes-komponenter manuellt i varje kluster rekommenderar vi att du använder automatiserade metoder för att tillämpa konfigurationer på ett Kubernetes-kluster, eftersom dessa konfigurationer checkas in på en källlagringsplats. Den här processen kallas ofta GitOps och populära GitOps-lösningar för Kubernetes är Flux och Argo CD. Till exempel möjliggör Flux-tillägget för AKS att klustren startas automatiskt och omedelbart efter att klustren har distribuerats.

GitOps beskrivs mer ingående i referensarkitekturen för AKS-baslinjen. Genom att använda en GitOps-baserad metod för konfiguration ser du till att varje Kubernetes-instans konfigureras på samma sätt utan skräddarsydda åtgärder. En effektiviserad konfigurationsprocess blir ännu viktigare när storleken på din flotta växer.

Du kan använda en GitOps-metod för att distribuera basklusterkonfigurationen. Du kan registrera klustret i flottan för att delta i aktiviteter som omfattar hela flottan, till exempel automatiska uppgraderingsdistributioner.

Du kan också använda GitOps för att distribuera dina arbetsbelastningar. Mer information finns i avsnittet om distribution av arbetsbelastningar nedan.

Azure Policy

När flera Kubernetes-instanser läggs till ökar fördelen med principdriven styrning, efterlevnad och konfiguration. Användning av principer, särskilt Azure Policy, tillhandahåller en centraliserad och skalbar metod för klusterkontroll. Fördelen med AKS-principer beskrivs i referensarkitekturen för AKS-baslinjen.

Azure Policy ska aktiveras när AKS-klustren skapas. Initiativ bör tilldelas i granskningsläge för att få insyn i inkompatibilitet. Du kan också ange fler principer som inte ingår i några inbyggda initiativ. Dessa principer anges i neka-läge. Det finns till exempel en princip för att säkerställa att endast godkända containeravbildningar körs i klustret. Överväg att skapa egna anpassade initiativ. Kombinera de principer som gäller för din arbetsbelastning till en enda tilldelning.

Principomfång refererar till målet för varje princip- och principinitiativ. Du kan använda Bicep för att tilldela principer till den resursgrupp som varje AKS-kluster distribueras till. När fotavtrycket för det globala klustret växer resulterar det i många duplicerade principer. Du kan också omfångsprinciper för en Azure-prenumeration eller Azure-hanteringsgrupp. Med den här metoden kan du tillämpa en enda uppsättning principer på alla AKS-kluster inom omfånget för en prenumeration, eller alla prenumerationer som finns under en hanteringsgrupp.

När du utformar en princip för flera AKS-kluster bör du tänka på följande:

• Tillämpa principer som ska tillämpas globalt på alla AKS-instanser för en hanteringsgrupp eller prenumeration.
• Placera varje regionalt kluster i en egen resursgrupp, vilket gör att regionspecifika principer kan tillämpas på resursgruppen.

Se Cloud Adoption Framework-resursorganisationen för material som hjälper dig att upprätta en strategi för principhantering.

Fleet-registrering

När ett kluster har distribuerats och konfigurerats registrerar du det i flottan som ett medlemskluster. Varje medlemskluster kan tilldelas till en uppdateringsgrupp, som kan användas som en del av en uppdateringsstrategi för att avgöra var i en uppdateringskörning klustret uppdateras. Mer information om klusterregistrering, grupper och uppdateringsstrategier finns i Definiera återanvändbara uppdateringsstrategier med Azure Kubernetes Fleet Manager.

Distribution av arbetsbelastning

Varje AKS-kluster i din arkitektur kör program som stöder din arbetsbelastning. Det är viktigt att planera hur du ska distribuera och uppgradera dina arbetsbelastningskomponenter på ett säkert och kontrollerat sätt och hur du ska upprätthålla konsekvensen i programversionerna mellan varje kluster. Utöver AKS-instanskonfiguration bör du därför överväga de arbetsbelastningar som distribueras till varje regional instans eller stämpel. Dina distributionslösningar eller pipelines kräver konfiguration för varje regional stämpel. När fler stämplar läggs till i det globala klustret måste distributionsprocessen utökas, eller så måste den vara tillräckligt flexibel för att hantera de nya regionala instanserna.

Det finns flera distributionsmetoder som du kan överväga, bland annat:

• Rörledningar: För scenarier med ett litet antal kluster och relativt få enkla distributioner är det ofta bäst att använda enkla dedikerade pipelines för kontinuerlig leverans (CD).

  En enda pipeline distribuerar vanligtvis en arbetsbelastning till ett eller flera kluster. Den här metoden minimerar driftkostnaderna och förblir hanterbar i lågskaliga miljöer. När du flyttar från en enskild klustermodell till en klustermodell kan du utveckla de distributionspipelines som du redan har på plats.

• Azure Kubernetes Fleet Manager-arbetsbelastningsspridning: Spridning av vagnparksarbetsbelastningar hjälper till att samordna arbetsbelastningsdefinitioner över flera medlemskluster från ett centraliserat kontrollplan. Flottor har stöd för en tillförlitlig och skalbar metod för arbetsbelastningsdistributioner, vilket möjliggör ett stort antal arbetsbelastningar och medlemskluster.

  Arbetsbelastningsspridning kräver användning av ett hubbkluster, som är ett Microsoft-hanterat AKS-kluster som hjälper till att spåra det förväntade tillståndet för dina medlemskluster. Det här hubbklustret är en regional resurs. Om ett regionalt avbrott påverkar hubbklustret kan arbetsbelastningsspridningen uppleva tillfälliga störningar.

• GitOps: När infrastrukturen mognar ytterligare blir det allt mer fördelaktigt att anta en GitOps-baserad strategi. GitOps möjliggör deklarativa, granskningsbara och pull-baserade distributionsmekanismer som erbjuder skalbarhet, styrning och teamsamarbete. Övergången till den här modellen rekommenderas särskilt när du hanterar en stor och dynamisk klusterflotta i flera regioner.

  Mer information finns i GitOps för Azure Kubernetes Service.

Tänk på följande frågor för att avgöra vilken metod som passar din lösning:

• Förväntar du dig att antalet kluster ska vara fast eller öka med tiden? Om du planerar att utöka antalet kluster, eller om du planerar att justera antalet kluster dynamiskt, kan det snabbt bli otympligt att underhålla varje klusters konfiguration i dina distributionspipelines.
• Hur många distributionsbara enheter måste du hantera? Om du har ett litet antal monolitiska program har du bara ett litet antal enskilda distributioner att samordna. Men om du har en distribuerad mikrotjänstbaserad arkitektur, ett stort antal arbetsbelastningar eller båda. kan detta snabbt växa till hundratals distributionsbara enheter. Det kan bli omöjligt att skapa en pipeline för varje distribution.
• Vilken typ av distributionsstrategier behöver du? Vanliga strategier är löpande uppdateringar, blågröna distributioner och kanariedistributioner. Vissa distributionsmetoder måste tillåta "bakningstid" mellan distributioner, med noggrann övervakning för att söka efter eventuella regressioner som introduceras av distributionen. Utvärdera varje distributionsmetod för att avgöra om den stöder dina specifika krav.
• Vilka nätverkssäkerhetsbegränsningar fungerar klustren i? Azure Kubernetes Fleet Manager fungerar under en nav-och-eker-klustertopologi, där medlemskluster underhåller utgående anslutningar till ett centralt hubbkluster för arbetsbelastningsavstämning och pulsslagsövervakning. En GitOps-baserad strategi kräver att deltagande kluster upprättar utgående åtkomst till en Git-lagringsplats. När du använder pipelines kräver pipelineagenten vanligtvis anslutning till varje kluster för att utföra distributionsåtgärder.

Oavsett hur du samordnar dina distributioner vill du generalisera varje distribution, till exempel med ett Helm-diagram, för att säkerställa att en enda distributionskonfiguration kan användas i flera kluster (stämplar). Tänk också på hur programdiagnostikloggning och distribuerad spårning kan konfigureras för programomfattande observerbarhet i vart och ett av dina kluster.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i checklistan för Designgranskning för tillförlitlighet.

En viktig motivation för att välja en Kubernetes-arkitektur i flera regioner är tjänstens tillgänglighet. Om en tjänst eller tjänstkomponent blir otillgänglig i en region bör trafiken dirigeras till en region där en annan instans av tjänsten fortfarande är tillgänglig. En arkitektur för flera regioner innehåller många olika felpunkter. I det här avsnittet beskrivs var och en av dessa potentiella felpunkter.

Programpoddfel

Ett Kubernetes-distributionsobjekt används för att skapa en ReplicaSet som hanterar flera repliker av en podd. Om en podd inte är tillgänglig dirigeras trafiken mellan de återstående. Kubernetes ReplicaSet försöker hålla det angivna antalet repliker igång. Om en instans slutar fungera bör en ny instans skapas automatiskt. Liveness-avsökningar kan användas för att kontrollera tillståndet för programmet eller processen som körs i podden. Om tjänsten inte svarar tar liveness-avsökningen bort podden, vilket tvingar ReplicaSet att skapa en ny instans.

Mer information finns i Kubernetes ReplicaSet.

Maskinvarufel för datacenter

Lokaliserade fel kan ibland inträffa. Ström kan till exempel bli otillgängligt för ett enda rack med Azure-servrar. Om du vill skydda dina AKS-noder från att bli en enskild felpunkt använder du Azure-tillgänglighetszoner. Genom att använda tillgänglighetszoner ser du till att AKS-noder i en tillgänglighetszon är fysiskt åtskilda från de noder som definierats i en annan tillgänglighetszon.

Mer information finns i AKS- och Azure-tillgänglighetszoner.

Fel i Azure-regionen

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 all trafik till de återstående felfria regionerna. Kubernetes-klustren och poddarna i de felfria regionerna fortsätter att hantera begäranden.

Var försiktig i den här situationen för att kompensera för ökade begäranden och trafik till det återstående klustret. Tänk också på följande faktorer:

• Se till 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 CNI kontrollerar du att du har ett undernät som är tillräckligt stort för att stödja alla podd-IP-adresser medan trafiken ökar.
• 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.

Mer information finns i Horizontal Pod Autoscaler and AKS cluster autoscaler (Horisontell autoskalning av poddar och AKS-kluster autoskalning).

Nätverkstopologi

På samma sätt som referensarkitekturen för AKS-baslinjen använder den här arkitekturen en nätverkstopologi med nav-ekrar. Utöver de överväganden som anges i referensarkitekturen för AKS-baslinjen bör du överväga följande metodtips:

• Implementera en hub-spoke-uppsättning virtuella nätverk för varje regional AKS-instans. I varje region peerkopplar du varje eker till det virtuella hubbnätverket.
• Dirigera all utgående trafik via en Azure Firewall-instans som finns i varje regionalt hubbnätverk. Använd Azure Firewall Manager-principer för att hantera brandväggsprinciper i alla regioner.
• Följ DEN IP-storleksändring som finns i referensarkitekturen för AKS-baslinjen och tillåt fler IP-adresser för både nod- och poddskalningsåtgärder om du skulle drabbas av ett regionalt fel i en annan region och trafiken till de återstående regionerna ökar avsevärt.

Trafikhantering

Med referensarkitekturen för AKS-baslinjen dirigeras arbetsbelastningstrafiken direkt till en Azure Application Gateway-instans och vidarebefordras sedan till serverdelslastbalanseraren och AKS-ingressresurserna. När du arbetar med flera kluster dirigeras klientbegäranden via en Azure Front Door-instans som dirigeras till Azure Application Gateway-instansen.

Ladda ned en Visio-fil med det här diagrammet.

1. Användaren skickar en begäran till ett domännamn (till exempel https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), som matchas till Azure Front Door-profilen. Den här begäran krypteras med ett jokerteckencertifikat (*.azurefd.net) som utfärdats för alla underdomäner i Azure Front Door. Azure Front Door validerar begäran mot brandväggsprinciper för webbprogram, väljer det snabbaste ursprunget (baserat på hälsa och svarstid) och använder offentlig DNS för att matcha ursprungs-IP-adressen (Azure Application Gateway-instans).

2. Azure Front Door vidarebefordrar begäran till den valda lämpliga Application Gateway-instansen, som fungerar som startpunkt för den regionala stämpeln. Trafiken flödar över Internet. Azure Front Door ser till att trafiken till ursprunget krypteras.

   Överväg en metod för att säkerställa att Application Gateway-instansen endast accepterar trafik från Front Door-instansen. En metod är att använda en nätverkssäkerhetsgrupp i undernätet som innehåller Application Gateway. Reglerna kan filtrera inkommande (eller utgående) trafik baserat på egenskaper som Källa, Port, Mål. Med egenskapen Källa kan du ange en inbyggd tjänsttagg som anger IP-adresser för en Azure-resurs. Den här abstraktionen gör det enklare att konfigurera och underhålla regeln och hålla reda på IP-adresser. Överväg också att X-Azure-FDID använda huvudet, som Azure Front Door lägger till i begäran innan den skickas till ursprunget, för att säkerställa att Application Gateway-instansen endast accepterar trafik från Front Door-instansen. Mer information om Front Door-huvuden finns i Protokollstöd för HTTP-huvuden i Azure Front Door.

Överväganden för delade resurser

Medan fokus i det här scenariot ligger på att ha flera Kubernetes-instanser spridda över flera Azure-regioner, är det klokt att dela vissa resurser i alla regioner. En metod är att använda en enda Bicep-fil för att distribuera alla delade resurser och sedan en annan för att distribuera varje regional stämpel. Det här avsnittet beskriver var och en av dessa delade resurser och överväganden för att använda var och en över flera AKS-instanser.

Containerregistret

Azure Container Registry används i den här arkitekturen för att tillhandahålla containeravbildningstjänster. Klustret hämtar containeravbildningar från registret. Tänk på följande när du arbetar med Azure Container Registry i en klusterdistribution i flera regioner.

Geografisk tillgänglighet

Placera ett containerregister i varje region där ett AKS-kluster distribueras. Den här metoden möjliggör nätverksåtgärder med låg fördröjning, vilket möjliggör snabba och tillförlitliga överföringar av avbildningslager. Det innebär också att du har flera avbildningstjänstslutpunkter för att tillhandahålla tillgänglighet när regionala tjänster inte är tillgängliga. Med hjälp av Azure Container Registrys geo-replikeringsfunktion kan du hantera ett containerregister som replikeras automatiskt till flera regioner.

Överväg att skapa ett enskilt register med repliker i varje Azure-region som innehåller kluster. Mer information om Replikering av Azure Container Registry finns i Geo-replikering i Azure Container Registry.

Bild som visar flera Azure Container Registry-repliker inifrån Azure Portal.

Klusteråtkomst

Varje AKS-kluster kräver åtkomst till containerregistret så att det kan hämta containeravbildningslager. Det finns flera sätt att upprätta åtkomst till Azure Container Registry. I den här arkitekturen skapas en hanterad identitet för varje kluster, som sedan beviljas AcrPull rollen i containerregistret. Mer information och rekommendationer om hur du använder hanterade identiteter för Åtkomst till Azure Container Registry finns i referensarkitekturen för AKS-baslinjen.

Den här konfigurationen definieras i Bicep-filen för klusterstämpeln, så att den nya AKS-instansen beviljas åtkomst varje gång en ny stämpel distribueras. Eftersom containerregistret är en delad resurs kontrollerar du att dina distributioner innehåller resurs-ID:t för containerregistret som en parameter.

Azure Monitor

När du utformar en övervakningslösning för en arkitektur i flera regioner är det viktigt att överväga kopplingen mellan varje stämpel. Du kan distribuera en enda Log Analytics-arbetsyta som delas av varje Kubernetes-kluster. Precis som med andra delade resurser definierar du din regionala stämpel för att använda information om den enda globalt delade Log Analytics-arbetsytan och ansluter varje regionalt kluster till den delade arbetsytan. När varje regionalt kluster genererar diagnostikloggar till den enskilda Log Analytics-arbetsytan kan du använda data, tillsammans med resursmått, för att skapa rapporter och instrumentpaneler som hjälper dig att förstå hur hela din lösning för flera regioner körs.

Azure Front Door-tjänsten

Azure Front Door används för att belastningsutjämning och dirigera trafik till varje AKS-kluster. Azure Front Door möjliggör även global routning i layer 7. Dessa funktioner krävs för det här scenariot.

Klusterkonfiguration

När varje regional AKS-instans läggs till måste Application Gateway som distribueras tillsammans med Kubernetes-klustret registreras som ett ursprung i Azure Front Door, vilket gör den tillgänglig för routning. Den här åtgärden kräver en uppdatering av infrastrukturen som kodtillgångar. Den här åtgärden kan också frikopplas från distributionskonfigurationen och hanteras med hjälp av verktyg som Azure CLI.

Certifikat

Azure Front Door stöder inte ursprung med självsignerade certifikat, inte ens i utvecklings- eller testmiljöer. För att aktivera HTTPS-trafik måste du skapa ditt TLS/SSL-certifikat som signerats av en certifikatutfärdare (CA). Information om andra certifikatutfärdare som Front Door stöder finns i Tillåtna certifikatutfärdare för att aktivera anpassad HTTPS på Azure Front Door.

För testning eller för icke-produktionskluster kan du överväga att använda Certbot för att skapa ett Let's Encrypt Authority X3-certifikat för var och en av programgatewayerna.

När du planerar för ett produktionskluster använder du din organisations metod för att skaffa TLS-certifikat.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i checklistan för Designgranskning för Security.

Åtkomstkontroll för kluster

Som beskrivs i referensarkitekturen för AKS-baslinjen rekommenderar vi att du använder Microsoft Entra-ID som identitetsprovider för dina kluster. Microsoft Entra-grupperna kan sedan användas för att styra åtkomsten till klusterresurser.

När du hanterar flera kluster måste du bestämma dig för ett åtkomstschema. Alternativen inkluderar:

• Skapa en global klusteromfattande åtkomstgrupp där medlemmar kan komma åt alla objekt i varje Kubernetes-instans i klustret. Det här alternativet ger minimala administrationsbehov. Det ger dock betydande privilegier till alla gruppmedlemmar.
• Skapa en enskild åtkomstgrupp för varje Kubernetes-instans som används för att bevilja åtkomst till objekt i en enskild klusterinstans. Med det här alternativet ökar de administrativa kostnaderna. Men det ger också mer detaljerad klusteråtkomst.
• Definiera detaljerade åtkomstkontroller för Kubernetes-objekttyper och namnområden och korrelera resultatet med en Microsoft Entra-gruppstruktur. Med det här alternativet ökar de administrativa kostnaderna avsevärt. Den ger dock detaljerad åtkomst till inte bara varje kluster utan även namnrymderna och Kubernetes-API:erna som finns i varje kluster.

För administrativ åtkomst bör du överväga att skapa en Microsoft Entra-grupp för varje region. Ge varje grupp fullständig åtkomst till motsvarande klusterstämpel i den regionen. Medlemmar i varje grupp har sedan administrativ åtkomst till motsvarande kluster.

Mer information om hur du hanterar AKS-klusteråtkomst med Microsoft Entra-ID finns i AKS Microsoft Entra-integrering.

Säkerhet för dina flottresurser

När du använder en flotta för att centralisera aspekter av klusterhanteringen är det viktigt att skydda flottans resurser för att undvika missbruk. Fleet-resurser använder rollbaserad åtkomstkontroll i Azure och du kan ge flottan behörighet till en begränsad uppsättning administratörer. Följ principen om lägsta behörighet och ge minsta möjliga åtkomst till flottans resurs ( flottans kontrollplan ).

Om din flotta använder ett hubbkluster bör du överväga följande extra rekommendationer:

• Utvärdera de rolltilldelningar som du skapar i hubbklustret ( rolltilldelningarna för dataplanet ). Dessa rolltilldelningar ger åtkomst till de Kubernetes-resurser som flottan skapar. Omfångsrolltilldelningar till ett enskilt Kubernetes-namnområde där det är möjligt.
• Använd ett privat hubbkluster för att begränsa Internetanslutningen. Se dock till att nätverksarkitekturen tillåter medlemskluster att nå hubbklustret.

Data, tillstånd och cacheminne

När du använder en globalt distribuerad uppsättning AKS-kluster bör du överväga arkitekturen för programmet, processen eller andra arbetsbelastningar som kan köras i klustret. Behöver de komma åt ett tillståndslager om tillståndsbaserade arbetsbelastningar är spridda över klustren? Om en process återskapas någon annanstans i klustret på grund av ett fel, fortsätter arbetsbelastningen eller processen att ha åtkomst till ett beroende tillståndslager eller en cachelagringslösning? Tillstånd kan lagras på många sätt, men det är komplext att hantera även i ett enda Kubernetes-kluster. Komplexiteten ökar när du lägger till flera Kubernetes-kluster. På grund av problem med regional åtkomst och komplexitet bör du överväga att utforma dina program så att de använder en globalt distribuerad tjänst för tillståndslager.

Den här arkitekturens design innehåller inte konfiguration för tillståndsproblem. Om du kör ett enda logiskt program i flera AKS-kluster kan du överväga att utforma arbetsbelastningen så att den använder en globalt distribuerad datatjänst, till exempel Azure Cosmos DB. Azure Cosmos DB är ett globalt distribuerat databassystem som gör att du kan läsa och skriva data från de lokala replikerna i databasen, och Cosmos DB-tjänsten hanterar geo-replikering åt dig. Mer information finns i Azure Cosmos DB.

Om din arbetsbelastning använder en cachelagringslösning ser du till att du skapar dina cachelagringstjänster så att de fungerar även under redundanshändelser. Kontrollera att själva arbetsbelastningen är motståndskraftig mot cacherelaterad redundans och att cachelagringslösningarna finns på alla regionala AKS-instanser.

Driftskvalitet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

När du använder en miljö med flera kluster med en vagnparksresurs blir övervakningen mer utmanande. På samma sätt bör du fundera på hur du ska samordna uppdateringar av AKS-klusterkomponenterna.

Övervaka kluster och arbetsbelastningar

Manuell granskning av instrumentpaneler och loggar kan bli svår när antalet kluster ökar, så tänk på hur du systematiskt aggregerar loggar och mått.

Azure Monitor Container Insights-funktionen är det rekommenderade verktyget för att övervaka och förstå prestanda och hälsa för dina kluster- och containerarbetsbelastningar. Container Insights använder både en Log Analytics-arbetsyta för att lagra loggdata och Azure Monitor Metrics för att lagra numeriska tidsseriedata. Prometheus-mått kan också samlas in av Container Insights och data kan skickas till antingen Azure Monitor-hanterad tjänst för Prometheus eller Azure Monitor-loggar. Mer information finns i referensarkitekturen för AKS-baslinjen.

Du kan också konfigurera diagnostikinställningarna för AKS-klustret för att samla in och analysera resursloggar från AKS-kontrollplanskomponenterna och vidarebefordra dem till en Log Analytics-arbetsyta.

Mer information om hur du konfigurerar Azure Monitor-arbetsytor i en miljö med flera kluster finns i Azure Monitor.

Övervaka flottans verksamhet

När Fleet Manager orkestrerar en uppdateringskörning kan du övervaka körningens förlopp när den fortskrider mellan kluster. Data lagras i Azure Resource Graph och kan exporteras till Azure Monitor för aviseringar och lagring.

Om du väljer att använda Fleet Manager för arbetsbelastningsspridning kan du övervaka distributionen med hjälp av Azure-portalen eller kubectl.

Du kan också samla in resursloggar från vagnparksresursen och vidarebefordra dem till en Log Analytics-arbetsyta.

Tillämpa uppdateringar i hela flottan

I den här referensarkitekturen tillämpar Fleet Manager Uppdateringar av Kubernetes-version och nodbilduppdateringar i hela flottan. Du kan ange uppgraderingsstrategier som konfigurerar hur uppgraderingar distribueras i dina kluster. Fleet Manager respekterar även underhållsperioder på varje kluster, så det är en bra idé att ställa in underhållsperioderna som är lämpliga för varje kluster. Underhållsperioder på varje kluster kan vara olika när du använder kluster i flera geografiska områden och därför i olika tidszoner.

Mer information finns i Uppdatera Kubernetes- och nodavbildningar i flera medlemskluster.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för kostnadsoptimering.

Använd Priskalkylatorn för Azure för att beräkna kostnaderna för de tjänster som används i arkitekturen. Andra metodtips beskrivs i avsnittet Kostnadsoptimering i Microsoft Azure Well-Architected Framework och specifika konfigurationsalternativ för kostnadsoptimering i artikeln Optimera kostnader .

Överväg att aktivera AKS-kostnadsanalys för detaljerad klusterinfrastrukturkostnadsallokering av Kubernetes-specifika konstruktioner.

Nästa steg

• AKS-tillgänglighetszoner
• Azure Kubernetes Fleet Manager
• Geo-replikering i Azure Container Registry
• Länkade Azure-regioner

Relaterade resurser

• Azure Well-Architected Framework-granskning för Azure Kubernetes Service (AKS)
• Baslinjearkitektur för ett AKS-kluster (Azure Kubernetes Service)
• CI/CD-pipeline för containerbaserade arbetsbelastningar
• AKS Microsoft Entra-integrering
• Dokumentation om Azure Front Door
• Dokumentation om Azure Cosmos DB