AKS-baslinje för kluster i flera regioner

Den här referensarkitekturen beskriver hur du kör flera instanser av ett Azure Kubernetes Service-kluster (AKS) över flera regioner i en konfiguration med aktiv/aktiv och hög tillgänglig.

Den här arkitekturen bygger på AKS-baslinjearkitekturen, Microsofts rekommenderade startpunkt för AKS-infrastruktur. AKS-baslinjen innehåller information om infrastrukturfunktioner som Azure Active Directory-poddidentitet (Azure AD), ingress- och utgående begränsningar, resursgränser och andra säkra AKS-infrastrukturkonfigurationer. Den här infrastrukturinformationen tas inte upp i det här dokumentet. Vi rekommenderar att du bekantar dig med AKS-baslinjen innan du fortsätter med innehållet i flera regioner.

referensimplementering av den här arkitekturen finns på GitHub.

Komponenter

Många komponenter och Azure-tjänster används i AKS-referensarkitekturen för flera regioner. Endast de komponenter som är unika för den här arkitekturen för flera kluster visas nedan. För de återstående referenserna refererar du till AKS-baslinjearkitekturen.

• Flera kluster/flera regioner Flera AKS-kluster distribueras var och en i en separat Azure-region. Under normal drift dirigeras nätverkstrafiken mellan alla regioner. Om en region blir otillgänglig dirigeras trafiken till en region som är närmast den användare som utfärdade begäran.
• hub-spoke-nätverk per region Ett regionalt hub-spoke-nätverkspar distribueras för varje regional AKS-instans. Azure Firewall Manager används för att hantera brandväggsprinciper i alla regioner.
• Regionalt nyckelarkiv Azure Key Vault i varje region för lagring av känsliga värden och nycklar som är specifika för AKS-instansen och stödtjänster som finns i den regionen.
• Azure Front Door Azure Front Door används för att belastningsutjämna och dirigera trafik till en Azure Application Gateway instans, som finns framför varje AKS-kluster. Azure Front Door tillåter global routning på nivå sju, som båda krävs för den här referensarkitekturen.
• Log Analytics Regionala Log Analytics-instanser 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.
• Containerregister Containeravbildningarna för arbetsbelastningen lagras i ett hanterat containerregister. I den här arkitekturen används 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 avbrott.

Designmönster

Den här referensarkitekturen använder två molndesignmönster. Geografisk nod (geodes), där alla regioner kan hantera alla förfrågningar och distributionsstämplar där flera oberoende kopior av ett program eller en programkomponent distribueras från en enda källa (distributionsmall).

Överväganden för mönster för geografiska noder

När du väljer regioner där varje AKS-kluster ska distribueras bör du överväga regioner nära arbetsbelastningskonsumenten eller dina kunder. Överväg också att använda parkopplade Azure-regioner. Sammankopplade regioner består av två regioner inom samma geografiska område, vilket påverkar hur Azure-underhållet utförs. När klustret skalar över två regioner fortsätter du att planera för regional parplacering för varje par av AKS-kluster. Mer information om parerade regioner finns i Parkopplade Azure-regioner.

I varje region sprids noderna 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 placeringen 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 ett AKS-kluster för flera regioner distribueras flera AKS-instanser i flera regioner. Var och en av dessa instanser betraktas som en stämpel. Om det uppstår ett regionalt fel eller om du behöver lägga till mer kapacitet och/eller regional närvaro för klustret 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 teknik för stämpeldefinition som möjliggör generaliserad konfiguration, till exempel infrastruktur som kod
• Ange instansspecifika värden med hjälp av en mekanism för distributionsindata, 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 över varje stämpel
• När stämplar läggs till och tas bort från samlingen bör du tänka på kapacitets- och kostnadsproblem
• Överväg hur du ska få insyn och/eller övervaka insamlingen av stämplar som en enda enhet

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

Klusterdistribution och start

När du distribuerar flera Kubernetes-kluster i hög tillgängliga och geografiskt distribuerade konfigurationer är det viktigt att du ser summan av varje Kubernetes-kluster som en kopplad enhet. Du kanske vill utveckla koddrivna strategier för automatiserad distribution och konfiguration för att säkerställa att varje Kubernetes-instans är så identisk som möjligt. Du bör överväga strategier för att skala ut och in genom att lägga till eller ta bort ytterligare Kubernetes-instanser. Du bör tänka igenom regionala fel och se till att eventuella biprodukter av ett fel kompenseras i din distribution och konfigurationsplan.

Klusterdefinition

Du har många alternativ för att distribuera ett Azure Kubernetes Service kluster. Modulen Azure Portal, Azure CLI Azure PowerShell är hyfsade alternativ för att distribuera enskilda eller icke-kopplade AKS-kluster. Dessa verktyg kan dock ge utmaningar när du arbetar med många nära kopplade AKS-kluster. Om du till exempel använder Azure Portal öppnar möjligheten för misskonfiguration på grund av missade steg eller otillgängliga konfigurationsalternativ. Dessutom är distribution och konfiguration av många kluster som använder portalen en snabb process som kräver en eller flera teknikers fokus. Du kan skapa en repeterbar och automatiserad process med hjälp av kommandoradsverktygen, men anus av saker som idempotens, kontroll av distributionsfel och återställning av fel finns på dig och de skript som du skapar.

När du arbetar med många AKS-instanser rekommenderar vi att du överväger infrastruktur som kodlösningar, till exempel Azure Resource Manager, Bicep-mallar eller Terraform-konfigurationer. Infrastruktur som kod-lösningar ger en automatiserad, skalbar och idempotent distributionslösning. Den här referensarkitekturen innehåller en ARM-mall för lösningarnas delade tjänster och sedan en annan för AKS-kluster + regionala tjänster. Med infrastruktur som kod kan en distributionsstämpel definieras med generaliserade konfigurationer som nätverk, auktorisering och diagnostik. En parameterfil för distribution kan tillhandahållas med regionala specifika 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 infrastrukturen som kodtillgångar kan vara kostsam. I vissa fall, till exempel när ett statiskt/fast antal AKS-instanser distribueras, kan omkostnaderna för infrastrukturen som kod uppväga fördelarna. I dessa fall är det ok att använda en mer imperativ metod, till exempel med kommandoradsverktyg eller till och med en manuell metod.

Klusterdistribution

När klusterstämpeldefinitionen 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 som GitHub Actions eller Azure Pipelines. Fördelarna med lösningar för kontinuerlig integreringsbaserad distribution ä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 hemlighetshantering
• Integrering med källkods-/distributionskällkontroll
• Distributionshistorik och loggning

När nya stämplar läggs till eller tas bort från det globala klustret måste distributionspipelinen uppdateras för att återspeglas. I referensimplementering distribueras varje region som ett enskilt steg i ett GitHub åtgärdsarbetsflöde (exempel). Den här konfigurationen är enkel eftersom varje klusterinstans är tydligt definierad i distributionspipelinen. Den här konfigurationen medför dock vissa administrativa kostnader för att lägga till och ta bort kluster från distributionen.

Ett annat alternativ är att använda logik för att skapa kluster baserat på en lista över önskade platser eller andra datapunkter. Distributionspipelinen kan till exempel innehålla en lista över önskade regioner. ett steg i pipelinen kan sedan gå igenom listan och distribuera ett kluster till varje region som finns i listan. Nackdelen med den här konfigurationen är komplexiteten i distributions generalisering 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.

Observera också att borttagning av en klusterstämpel från distributionspipelinen inte nödvändigtvis säkerställer att den också inaktiveras. Beroende på din distributionsteknik och konfiguration kan du behöva ett extra steg för att se till att AKS-instanserna har inaktiverats korrekt.

Start av kluster

När varje Kubernetes-instans eller stämpel har distribuerats måste klusterkomponenter som ingress-styrenheter, identitetslösningar och arbetsbelastningskomponenter distribueras och konfigureras. Du måste också överväga att tillämpa principer för säkerhet, åtkomst och styrning i klustret.

På samma sätt som med distribution kan dessa konfigurationer bli svåra att hantera över flera Kubernetes-instanser manuellt. Överväg i stället följande alternativ för konfiguration och princip i stor skala.

GitOps

I stället för att konfigurera Kubertnets-komponenter manuellt bör du överväga att använda automatiserade verktyg för att tillämpa konfigurationer på ett Kubernetes-kluster eftersom dessa konfigurationer checkas in på en källdatabas. Den här processen kallas ofta GitOps, och populära GitOps-lösningar för Kubernetes omfattar Flux och Argo CD.

GitOps beskrivs mer ingående i referensarkitekturen för AKS-baslinje. Det viktiga här är att en GitOps-baserad konfigurationsmetod hjälper till att säkerställa att varje Kubernetes-instans är konfigurerad på samma sätt utan att behöva göra något.

Azure Policy

När flera Kubernetes-instanser läggs till ökar fördelen med principdriven styrning, efterlevnad och konfiguration. Med hjälp av principer tillhandahåller Azure-principer i det här fallet en centraliserad och skalbar metod för klusterkontroll. Fördelen med AKS-principer beskrivs i referensarkitekturen för AKS-baslinje.

Azure Policy aktiveras i den här referensimplementering när AKS-klustren skapas och tilldelar det restriktiva initiativet i granskningsläge för att få insyn i bristande efterlevnad. Implementeringen anger också ytterligare 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 se till 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 i en enda tilldelning.

Principomfång avser målet för varje princip och principinitiativ. Referensimplementering som är associerad med den här arkitekturen använder en ARM-mall för att tilldela principer till resursgruppen som varje AKS-kluster distribueras till. När det globala klustrets fotavtryck växer resulterar det i många duplicerade principer. Du kan också ange omfångsprinciper för en Azure-prenumeration eller Azure-hanteringsgrupp, vilket gör att en enda uppsättning principer kan tillämpas på alla AKS-kluster inom omfånget för en prenumeration och/eller alla prenumerationer som finns under en hanteringsgrupp.

Tänk på följande när du utformar principen för flera AKS-kluster:

• Principer som ska tillämpas globalt på alla AKS-instanser kan tillämpas på en hanteringsgrupp eller prenumeration
• Genom att placera varje regionalt kluster i en egen resursgrupp kan du tillämpa regionspecifika principer på resursgruppen

Information om material som hjälper dig att upprätta en strategi för principhantering finns i Hanteringsgrupp och prenumerationsorganisation för Cloud Adoption Frameworks.

Arbetsbelastningsdistribution

Utöver AKS-instanskonfigurationen bör du överväga den arbetsbelastning som distribueras till varje regional instans eller stämpel. Distributionslösningar eller pipelines kräver konfiguration för att hantera varje regional stämpel. När ytterligare stämplar läggs till i det globala klustret måste distributionsprocessen utökas eller vara tillräckligt flexibel för att hantera de nya regionala instanserna.

Tänk på följande när du planerar för arbetsbelastningsdistribution.

• Generalisera distributionen, till exempel med ett Helm-diagram, för att säkerställa att en enda distributionskonfiguration kan användas över flera klusterstämplar.
• Använd en enda pipeline för kontinuerlig distribution som konfigurerats för att distribuera arbetsbelastningen över alla klusterstämplar.
• Ange information om stämpelspecifika instanser som distributionsparametrar.
• Överväg hur programdiagnostikloggning och distribuerad spårning konfigureras för programomfattande observerbarhet.

Tillgänglighet/redundans

En viktig motivering för att välja en Kubernetes-arkitektur för flera regioner är tjänsttillgänglighet. Det innebär att 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 diskuteras var och en av dessa potentiella felpunkter.

Programpoddar (regionala)

Ett Kubernetes-distributionsobjekt används för att skapa flera repliker av en podd (ReplicaSet). Om den 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 går ned bör en ny instans skapas igen. Slutligen kan liveavsökningar användas för att kontrollera tillståndet för programmet eller processen som körs i podden. Om tjänsten inte svarar på rätt sätt tar liveavsö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 betjäna begäranden. I det här fallet dirigerar Azure Front Door-instansen all trafik till de återstående felfria regionerna. Kubernetes-kluster och poddar i dessa regioner fortsätter att betjäna begäranden.

Var noga i den här situationen för att kompensera för ökad trafik/förfrågningar till det återstående klustret. Några saker att tänka på:

• Se till att nätverks- och beräkningsresurser har rätt storlek för att absorbera plötslig ökning av trafiken på grund av region-redundans. När du till exempel använder Azure CNI bör du se till att du har ett undernät som har stöd för alla podd-IP-adresser med hög 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.

Mer information finns i Horizontal Pod Autoscaler andAKS cluster autoscaler.

Kubernetes-nodpooler (regionala)

Ibland kan ett lokaliserat fel uppstå för beräkningsresurser, till exempel om strömmen blir otillgänglig för ett enda rack med Azure-servrar. Använd Azure-tillgänglighetszoner för att skydda AKS-noderna från att bli ett regionalt fel med en enda punkt. Användning av tillgänglighetszoner säkerställer att AKS-noder i en viss tillgänglighetszon är fysiskt åtskilda från de som definierats i en annan tillgänglighetszon.

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

Kubernetes-nodpooler (globala)

I ett fullständigt regionalt fel dirigerar Azure Front Door trafik till de återstående och felfria regionerna. Var återigen noga i den här situationen för att kompensera för ökad trafik/förfrågningar till det återstående klustret.

Mer information finns i Azure Front Door.

Nätverkstopologi

I likhet med referensarkitekturen för AKS-baslinjen använder den här arkitekturen en nätverkstopologi av nav och ekrar. Utöver de överväganden som anges i referensarkitekturen för AKS-baslinjebör du tänka på följande:

• Implementera en hub-spoke för varje regional AKS-instans, där de virtuella hubb-eker-nätverken är peer-ade.
• Dirigera all utgående trafik via en Azure Firewall instans som finns i varje regionalt hubbnätverk. Använd Azure Firewall Manager för att hantera brandväggsprinciper i alla regioner.
• Följ IP-storleksändringen som finns i referensarkitekturen för AKS-baslinje plus tillåt ytterligare IP-adresser för både nod- och poddskalningsåtgärder i händelse av ett regionalt fel.

Trafikhantering

Med referensarkitekturen för AKS-baslinjen dirigeras arbetsbelastningstrafik direkt till en Azure Application Gateway-instans och vidarebefordras sedan till resurserna för lastbalanserare/AKS-ingress i backend. När du arbetar med flera kluster dirigeras klientbegäranden via en Azure Front Door instans, som dirigeras till Azure Application Gateway instansen.

1. Användaren skickar en begäran till ett domännamn (t.ex. ), som https://contoso-web.azurefd.net matchas mot Azure Front Door instansen. Den här begäran krypteras med ett jokerteckencertifikat (*.azurefd.net) utfärdat för alla underdomäner i Azure Front Door. Den Azure Front Door-instansen verifierar begäran mot WAF-principer, väljer den snabbaste server (baserat på hälsa och svarstid) och använder offentlig DNS för att matcha serverorganisationens IP-adress (Azure Application Gateway instans).

2. Front Door vidarebefordrar begäran till den valda Application Gateway instansen, som fungerar som startpunkt för den regionala stämpeln. Trafiken flödar via Internet och krypteras av Azure Front Door. Ö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 dessutom att använda Front Door till backend-huvudet för att säkerställa att Application Gateway-instansen endast accepterar trafik från X-Azure-FDID Front Door instansen. Mer information om Front Door finns i Protokollstöd för HTTP-huvuden i Azure Front Door.

Överväganden för delade resurser

Även om fokus för den här referensarkitekturen ligger på att ha flera Kubernetes-instanser utspridda över flera Azure-regioner, är det bra att ha vissa delade resurser över alla instanser. Referensimplementering för AKS i flera regioner med en enda ARM-mall 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.

Container Registry

Azure Container Registry används i den här referensarkitekturen för att tillhandahålla containeravbildningstjänster (pull). Tänk på följande när du arbetar Azure Container Registry i en klusterdistribution i flera regioner.

Geografisk tillgänglighet

Genom att placera ett containerregister i varje region där ett AKS-kluster distribueras kan du använda nätverks close-åtgärder, vilket möjliggör snabba och tillförlitliga överföringar av avbildningslager. Om du har flera tjänstslutpunkter för avbildningar får du även tillgänglighet om regionala tjänster inte är tillgängliga. Med geo-replikeringsfunktionen i Azure Container Registries kan du hantera en Container Registry instans som replikeras till flera regioner.

Referensimplementering för AKS i flera regioner skapade Container Registry instans och repliker av den här instansen i varje klusterregion. Mer information om Azure Container Registry finns i Geo-replikering i Azure Container Registry.

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

Klusteråtkomst

Varje AKS-instans kräver åtkomst för att hämta avbildningslager från Azure Container Registry. Det finns flera sätt att upprätta åtkomst till Azure Container Registry. I den här referensarkitekturen används en hanterad Azure-identitet för varje kluster, som sedan beviljas AcrPull-rollen på Container Registry instansen. Mer information och rekommendationer om hur du använder hanterade identiteter för Container Registry åtkomst finns i referensarkitekturen för AKS-baslinje.

Den här konfigurationen definieras i ARM-mallen för klusterstämpeln så att den nya AKS-instansen beviljas åtkomst varje gång en ny stämpel distribueras. Eftersom Container Registry är en delad resurs bör du se till att mallen för distributionsstämpeln kan använda och använda nödvändig information, i det här fallet resurs-ID:t för Container Registry.

Log Analytics och Azure Monitor

Funktionen Azure Monitor för containrar är det rekommenderade verktyget för övervakning och loggning eftersom du kan visa händelser i realtid. Azure Monitor använder en Log Analytics-arbetsyta för att lagra diagnostikloggar. Mer information finns i Referensarkitektur för AKS-baslinje.

När du överväger övervakning för en implementering mellan regioner, till exempel den här referensarkitekturen, är det viktigt att överväga kopplingen mellan varje stämpel. I det här fallet bör du överväga varje stämpel som en komponent i en enskild enhet (regionalt kluster). Referensimplementering för AKS i flera regioner använder 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 enskilda Log Analytics-arbetsytan och ansluta varje kluster till den.

Nu när varje regionalt kluster utelämnar diagnostikloggar till en enda Log Analytics-arbetsyta kan dessa data, tillsammans med resursmått, användas för att enklare skapa rapporter och instrumentpaneler som representerar hela det globala klustret.

Azure Front Door

Azure Front Door används för att belastningsutjämna och dirigera trafik till varje AKS-kluster. Azure Front Door tillåter lager sju global routning, som båda krävs för den här referensarkitekturen.

Klusterkonfiguration

När regionala AKS-instanser läggs till måste Application Gateway distribueras tillsammans med Kubernetes-klustret registreras som en Front Door serverdelar för korrekt 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 verktyg som Azure CLI. Distributionspipelinen för inkluderade referensimplementeringar använder ett distinkt Azure CLI-steg för den här åtgärden.

Certifikat

Front Door stöder inte själv signerade certifikat ens i Dev/Test-miljöer. Om du vill aktivera HTTPS-trafik måste du skapa ditt TLS/SSL-certifikat som signerats av en certifikatutfärdare (CA). Referensimplementering använder Certbot för att skapa ett Let's Encrypt Authority X3-certifikat. När du planerar för ett produktionskluster bör du använda organisationens föredragna metod för att köpa TLS-certifikat.

Information om andra certifikatutfärdare som stöds av Front Door finns i Tillåtna certifikatutfärdareför att aktivera anpassad HTTPS på Azure Front Door .

Klusteråtkomst och identitet

Som beskrivs i referensarkitekturen för AKS-baslinjerekommenderar vi att Azure Active Directory som klusteråtkomstidentitetsprovider. De Azure Active Directory 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 är:

• Skapa en global åtkomstgrupp för hela klustret där medlemmar kan komma åt alla objekt i varje Kubernetes-instans i klustret. Det här alternativet ger minimala administrationsbehov. Den ger dock betydande behörighet till alla gruppmedlem.
• 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 det administrativa arbetet. Men det ger även mer detaljerad klusteråtkomst.
• Definiera detaljerade åtkomstkontroller för Kubernetes-objekttyper och namnrymder och korrelera detta med en Azure Directory-gruppstruktur. Med det här alternativet ökar det administrativa arbetet avsevärt. Den ger dock detaljerad åtkomst till inte bara varje kluster utan även namnrymderna och Kubernetes-API:erna som finns i varje kluster.

Med den inkluderade referensimplementering skapas två AAD grupper för administratörsåtkomst. Dessa grupper anges vid tidpunkten för distribution av klusterstämpel med hjälp av parameterfilen för distribution. Medlemmar i varje grupp har fullständig åtkomst till motsvarande klusterstämpel.

Mer information om hur du hanterar AKS-klusteråtkomst med Azure Active Directory finns i AKS Azure AD-integrering.

Data, tillstånd och cache

När du använder ett globalt distribuerat kluster av AKS-instanser bör du överväga arkitekturen för programmet, processen eller andra arbetsbelastningar som kan köras i klustret. Eftersom den tillståndsbaserade arbetsbelastningen är utspridd i klustret, behöver den då åtkomst till ett tillståndslager? Om en process återskapas någon annanstans i klustret på grund av fel, kommer arbetsbelastningen eller processen att fortsätta ha åtkomst till ett beroende tillståndslager eller en cachelagringslösning? Tillstånd kan uppnås på många sätt. Det kan dock vara komplext i ett enda Kubernetes-kluster. Komplexiteten ökar när du lägger till flera klustrade Kubernetes-instanser. På grund av regional åtkomst och komplexitet bör du överväga att skapa dina program för att använda en globalt distribuerad tillståndslagertjänst.

Referensimplementeringen för flera kluster innehåller ingen demonstration eller konfiguration av tillståndsproblem. Om du kör program över klustrade AKS-instanser bör du överväga att skapa en arbetsbelastning för att använda 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 lokala repliker av din databas. Mer information finns i Azure Cosmos DB.

Om din arbetsbelastning använder en cachelagringslösning ska du se till att den är skapad så att cachelagringstjänsterna fortsätter att fungera. Det gör du genom att se till att själva arbetsbelastningen är motståndskraftig mot cacherelaterad redundans och att cachelagringslösningarna finns på alla regionala AKS-instanser.

Kostnadshantering

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.