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 region som är närmast användaren som utfärdade begäran.
- Regionala nav-ekernätverk: Ett regionalt nav-ekernätverkspar distribueras för varje regional AKS-instans. Azure Firewall Manager-principer används 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.
- 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.
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.
Vagnparkshantering
Den här lösningen representerar en topologi för flera kluster och flera regioner, utan att en avancerad orkestrerare tas med för att behandla alla kluster som en del av en enhetlig flotta. När antalet kluster ökar bör du överväga att registrera medlemmarna i Azure Kubernetes Fleet Manager för bättre skalningshantering av de deltagande klustren. Infrastrukturarkitekturen som presenteras här ändras inte i grunden med registreringen till Fleet Manager, men dag-2-åtgärder och liknande aktiviteter drar nytta av ett kontrollplan som kan rikta in sig på flera kluster samtidigt.
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.
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 måste också överväga att tillämpa säkerhets-, åtkomst- och styrningsprinciper i klustret.
På samma sätt som med distributionen 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 Kubernetes-komponenter manuellt 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.
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.
Distribution av arbetsbelastning
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 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.
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 stämpelspecifik instansinformation som distributionsparametrar.
- Överväg hur programdiagnostikloggning och distribuerad spårning konfigureras för programomfattande observerbarhet.
Tillgänglighet och redundans
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.
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).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-FDIDanvä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.
Container Registry
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
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.
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 enda Log Analytics-arbetsytan kan du använda data, tillsammans med resursmått, för att enklare 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
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.
Klusteråtkomst och identitet
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.
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.
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