AKS-basislijn voor clusters met meerdere regio's

In deze architectuur wordt beschreven hoe u meerdere exemplaren van een AKS-cluster (Azure Kubernetes Service) uitvoert in meerdere regio's in een configuratie die actief/actief en maximaal beschikbaar is.

Deze architectuur bouwt voort op de basislijnarchitectuur van AKS, het aanbevolen startpunt van Microsoft voor de AKS-infrastructuur. De infrastructuurfuncties van de AKS-basislijndetails, zoals Microsoft Entra Workload-ID, beperkingen voor inkomend en uitgaand verkeer, resourcelimieten en andere beveiligde AKS-infrastructuurconfiguraties. Deze infrastructuurdetails worden niet behandeld in dit document. U wordt aangeraden vertrouwd te raken met de AKS-basislijn voordat u doorgaat met de inhoud in meerdere regio's.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

Veel onderdelen en Azure-services worden gebruikt in deze AKS-architectuur met meerdere regio's. Alleen de onderdelen met uniekheid voor deze architectuur met meerdere clusters worden hier vermeld. Raadpleeg de AKS-basislijnarchitectuur voor de rest.

• Regionale AKS-clusters: er worden meerdere AKS-clusters geïmplementeerd, elk in een afzonderlijke Azure-regio. Tijdens normale bewerkingen wordt netwerkverkeer gerouteerd tussen alle regio's. Als één regio niet beschikbaar is, wordt verkeer doorgestuurd naar een regio die zich het dichtst bij de gebruiker bevindt die de aanvraag heeft uitgegeven.
• Regionale hub-spoke-netwerken: er wordt een regionaal hub-spoke-netwerkpaar geïmplementeerd voor elk regionaal AKS-exemplaar. Azure Firewall Manager-beleid wordt gebruikt voor het beheren van firewallbeleid in alle regio's.
• Regionale sleutelkluis: Azure Key Vault wordt ingericht in elke regio. Sleutelkluizen worden gebruikt voor het opslaan van gevoelige waarden en sleutels die specifiek zijn voor het AKS-cluster en ondersteunende services die zich in die regio bevinden.
• Meerdere logboekwerkruimten: Regionale Log Analytics-werkruimten worden gebruikt voor het opslaan van metrische gegevens voor regionale netwerken en diagnostische logboeken. Daarnaast wordt een gedeeld Log Analytics-exemplaar gebruikt voor het opslaan van metrische gegevens en diagnostische logboeken voor alle AKS-exemplaren.
• Globaal Azure Front Door-profiel: Azure Front Door wordt gebruikt om verkeer te verdelen en te routeren naar een regionaal Azure-toepassing Gateway-exemplaar, dat zich vóór elk AKS-cluster bevindt. Azure Front Door maakt globale routering van laag 7 mogelijk, die beide vereist zijn voor deze architectuur.
• Globaal containerregister: de containerinstallatiekopieën voor de workload worden opgeslagen in een beheerd containerregister. In deze architectuur wordt één Azure Container Registry gebruikt voor alle Kubernetes-exemplaren in het cluster. Geo-replicatie voor Azure Container Registry maakt het repliceren van installatiekopieën naar de geselecteerde Azure-regio's mogelijk en biedt continue toegang tot installatiekopieën, zelfs als een regio een storing ondervindt.

Ontwerppatronen

Deze architectuur maakt gebruik van twee cloudontwerppatronen:

• Geodes (geografische knooppunten), waarbij elke regio elke aanvraag kan verwerken.
• Implementatiestempels, waarbij meerdere onafhankelijke kopieën van een toepassing of toepassingsonderdeel worden geïmplementeerd vanuit één bron, zoals een implementatiesjabloon.

Overwegingen voor geodepatronen

Wanneer u regio's selecteert om elk AKS-cluster te implementeren, kunt u regio's in de buurt van de workloadconsumer of uw klanten overwegen. Overweeg ook replicatie tussen regio's te gebruiken. Replicatie tussen regio's replicatie repliceert asynchroon dezelfde toepassingen en gegevens in andere Azure-regio's voor herstel na noodgevallen. Naarmate uw cluster groter wordt dan twee regio's, kunt u doorgaan met het plannen van replicatie tussen regio's voor elk paar AKS-clusters.

Binnen elke regio worden knooppunten in de AKS-knooppuntgroepen verspreid over meerdere beschikbaarheidszones om problemen te voorkomen als gevolg van zonefouten. Beschikbaarheidszones worden ondersteund in een beperkt aantal regio's, wat invloed heeft op de plaatsing van regionale clusters. Zie AKS-beschikbaarheidszones voor meer informatie over AKS en beschikbaarheidszones, waaronder een lijst met ondersteunde regio's.

Overwegingen voor implementatiestempels

Wanneer u een AKS-oplossing met meerdere regio's beheert, implementeert u meerdere AKS-clusters in meerdere regio's. Elk van deze clusters wordt beschouwd als een stempel. Als er sprake is van een regionale fout of als u meer capaciteit of regionale aanwezigheid voor uw clusters wilt toevoegen, moet u mogelijk een nieuw stempelexemplaren maken. Wanneer u een proces selecteert voor het maken en beheren van implementatiestempels, is het belangrijk om rekening te houden met het volgende:

• Selecteer de juiste technologie voor stempeldefinities waarmee gegeneraliseerde configuratie mogelijk is. U kunt bijvoorbeeld Bicep gebruiken voor het definiëren van infrastructuur als code.
• Geef exemplaarspecifieke waarden op met behulp van een implementatie-invoermechanisme, zoals variabelen of parameterbestanden.
• Selecteer implementatiehulpprogramma's die flexibele, herhaalbare en idempotente implementatie mogelijk maken.
• In een actieve/actieve stempelconfiguratie kunt u overwegen hoe verkeer wordt verdeeld over elke zegel. Deze architectuur maakt gebruik van Azure Front Door voor wereldwijde taakverdeling.
• Aangezien er stempels worden toegevoegd en verwijderd uit de verzameling, kunt u rekening houden met capaciteit en kostenproblemen.
• Overweeg hoe u de verzameling stempels als één eenheid beter zichtbaar kunt maken en bewaken.

Elk van deze items wordt gedetailleerd beschreven met specifieke richtlijnen in de volgende secties.

Wagenparkbeheer

Deze oplossing vertegenwoordigt een topologie met meerdere clusters en meerdere regio's, zonder dat er een geavanceerde orchestrator is opgenomen om alle clusters als onderdeel van een geïntegreerde vloot te behandelen. Wanneer het aantal clusters toeneemt, kunt u overwegen om de leden in Azure Kubernetes Fleet Manager in te schrijven voor beter beheer op schaal van de deelnemende clusters. De infrastructuurarchitectuur die hier wordt gepresenteerd, verandert niet fundamenteel met de inschrijving in Fleet Manager, maar dag-2 bewerkingen en vergelijkbare activiteiten profiteren van een besturingsvlak dat tegelijkertijd op meerdere clusters kan worden gericht.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Clusterimplementatie en bootstrapping

Bij het implementeren van meerdere Kubernetes-clusters in maximaal beschikbare en geografisch gedistribueerde configuraties is het essentieel om rekening te houden met de som van elk Kubernetes-cluster als een gekoppelde eenheid. U kunt codegestuurde strategieën ontwikkelen voor geautomatiseerde implementatie en configuratie om ervoor te zorgen dat elke Kubernetes-instantie zo identiek mogelijk is. Overweeg strategieën voor uit- en inschalen, waaronder door andere Kubernetes-clusters toe te voegen of te verwijderen. Uw ontwerp- en implementatie- en configuratieplan moeten rekening houden met storingen in de beschikbaarheidszone, regionale storingen en andere veelvoorkomende scenario's.

Clusterdefinitie

U hebt veel opties voor het implementeren van een Azure Kubernetes Service-cluster. De Azure-portal, de Azure CLI en de Azure PowerShell-module zijn allemaal fatsoenlijke opties voor het implementeren van afzonderlijke of niet-gekoppelde AKS-clusters. Deze methoden kunnen echter uitdagingen opleveren bij het werken met veel nauw gekoppelde AKS-clusters. Als u bijvoorbeeld Azure Portal gebruikt, wordt de kans geopend voor onjuiste configuratie vanwege gemiste stappen of niet-beschikbare configuratieopties. De implementatie en configuratie van veel clusters met behulp van de portal is een tijdrovend proces waarvoor de focus van een of meer technici vereist is. Als u de Azure CLI of Azure PowerShell gebruikt, kunt u een herhaalbaar en geautomatiseerd proces maken met behulp van de opdrachtregelprogramma's. De verantwoordelijkheid van idempotentie, implementatiefoutbeheer en herstel van fouten bevindt zich echter op u en de scripts die u bouwt.

Wanneer u met meerdere AKS-exemplaren werkt, raden we u aan infrastructuur als codeoplossingen, zoals Bicep, Azure Resource Manager-sjablonen of Terraform, te overwegen. Infrastructuur als codeoplossingen bieden een geautomatiseerde, schaalbare en idempotente implementatieoplossing. U kunt bijvoorbeeld één Bicep-bestand gebruiken voor de gedeelde services van de oplossing en een ander bestand voor de AKS-clusters en andere regionale services. Als u infrastructuur als code gebruikt, kan een implementatiestempel worden gedefinieerd met gegeneraliseerde configuraties, zoals netwerken, autorisatie en diagnostische gegevens. Een implementatieparameterbestand kan worden geleverd met regiospecifieke waarden. Met deze configuratie kan één sjabloon worden gebruikt om een bijna identieke stempel in elke regio te implementeren.

De kosten voor het ontwikkelen en onderhouden van infrastructuur omdat codeassets kostbaar kunnen zijn. In sommige gevallen kan de overhead van het definiëren van infrastructuur als code opwegen tegen de voordelen, zoals wanneer u een zeer klein (bijvoorbeeld 2 of 3) hebt en het onveranderlijke aantal AKS-exemplaren. Voor deze gevallen is het acceptabel om een meer imperatieve benadering te gebruiken, zoals met opdrachtregelprogramma's of zelfs handmatige benaderingen met Azure Portal.

Clusterimplementatie

Nadat de clusterstempel is gedefinieerd, hebt u veel opties voor het implementeren van afzonderlijke of meerdere stempelexemplaren. Onze aanbeveling is om moderne technologie voor continue integratie te gebruiken, zoals GitHub Actions of Azure Pipelines. De voordelen van implementatieoplossingen op basis van continue integratie zijn onder andere:

• Op code gebaseerde implementaties waarmee stempels kunnen worden toegevoegd en verwijderd met behulp van code
• Geïntegreerde testmogelijkheden
• Geïntegreerde omgeving en faseringsmogelijkheden
• Geïntegreerde oplossingen voor geheimenbeheer
• Integratie met broncodebeheer voor zowel toepassingscode als implementatiescripts en sjablonen
• Implementatiegeschiedenis en logboekregistratie
• Mogelijkheden voor toegangsbeheer en controle om te bepalen wie wijzigingen kan aanbrengen en onder welke voorwaarden

Wanneer er nieuwe stempels worden toegevoegd aan of verwijderd uit het globale cluster, moet de implementatiepijplijn worden bijgewerkt om consistent te blijven. Eén benadering is het implementeren van de resources van elke regio als een afzonderlijke stap binnen een GitHub Actions-werkstroom. Deze configuratie is eenvoudig omdat elk clusterexemplementatie duidelijk is gedefinieerd in de implementatiepijplijn. Deze configuratie omvat enkele administratieve overhead bij het toevoegen en verwijderen van clusters uit de implementatie.

Een andere optie is om bedrijfslogica te maken om clusters te maken op basis van een lijst met gewenste locaties of andere die gegevenspunten aangeven. De implementatiepijplijn kan bijvoorbeeld een lijst met gewenste regio's bevatten; een stap in de pijplijn kan vervolgens deze lijst doorlopen, waarbij een cluster in elke regio in de lijst wordt geïmplementeerd. Het nadeel van deze configuratie is de complexiteit van de implementatie-generalisatie en dat elke clusterstempel niet expliciet wordt beschreven in de implementatiepijplijn. Het positieve voordeel is dat het toevoegen of verwijderen van clusterstempels uit de pijplijn een eenvoudige update wordt van de lijst met gewenste regio's.

Als u een clusterstempel uit de implementatiepijplijn verwijdert, worden de resources van de stempel niet altijd buiten gebruik gesteld. Afhankelijk van uw implementatieoplossing en -configuratie hebt u mogelijk een extra stap nodig om de AKS-exemplaren en andere Azure-resources buiten gebruik te stellen. Overweeg het gebruik van implementatiestacks om volledig levenscyclusbeheer van Azure-resources mogelijk te maken, inclusief opschonen wanneer u ze niet meer nodig hebt.

Cluster bootstrapping

Nadat elke Kubernetes-instantie of -zegel is geïmplementeerd, moeten clusteronderdelen zoals toegangsbeheerobjectcontrollers, identiteitsoplossingen en workloadonderdelen worden geïmplementeerd en geconfigureerd. U moet ook overwegen beveiligings-, toegangs- en governancebeleid toe te passen in het cluster.

Net als bij de implementatie kunnen deze configuraties lastig worden om te beheren in verschillende Kubernetes-exemplaren handmatig. Overweeg in plaats daarvan de volgende opties voor configuratie en beleid op schaal.

GitOps

In plaats van Kubernetes-onderdelen handmatig te configureren, is het raadzaam om geautomatiseerde methoden te gebruiken om configuraties toe te passen op een Kubernetes-cluster, omdat deze configuraties worden ingecheckt in een bronopslagplaats. Dit proces wordt vaak GitOps genoemd en populaire GitOps-oplossingen voor Kubernetes omvatten Flux en Argo CD. Met de Flux-extensie voor AKS kunt u bijvoorbeeld automatisch opstarten van de clusters en onmiddellijk nadat de clusters zijn geïmplementeerd.

GitOps is uitgebreider in de referentiearchitectuur van de AKS-basislijn. Door een op GitOps gebaseerde benadering voor configuratie te gebruiken, zorgt u ervoor dat elke Kubernetes-instantie op dezelfde manier wordt geconfigureerd zonder dat u op maat hoeft te werken. Een gestroomlijnd configuratieproces wordt nog belangrijker naarmate de grootte van uw vloot groeit.

Azure Policy

Naarmate er meerdere Kubernetes-exemplaren worden toegevoegd, neemt het voordeel van beleidgestuurde governance, naleving en configuratie toe. Het gebruik van beleid, met name Azure Policy, biedt een gecentraliseerde en schaalbare methode voor clusterbeheer. Het voordeel van AKS-beleid wordt beschreven in de referentiearchitectuur van de AKS-basislijn.

Azure Policy moet worden ingeschakeld wanneer de AKS-clusters worden gemaakt. Initiatieven moeten worden toegewezen in de controlemodus om inzicht te krijgen in niet-naleving. U kunt ook meer beleidsregels instellen die geen deel uitmaken van ingebouwde initiatieven. Deze beleidsregels worden ingesteld in de modus Weigeren. Er is bijvoorbeeld een beleid om ervoor te zorgen dat alleen goedgekeurde containerinstallatiekopieën in het cluster worden uitgevoerd. Overweeg om uw eigen aangepaste initiatieven te maken. Combineer de beleidsregels die van toepassing zijn op uw workload in één toewijzing.

Het beleidsbereik verwijst naar het doel van elk beleid en beleidsinitiatief. U kunt Bicep gebruiken om beleidsregels toe te wijzen aan de resourcegroep waarin elk AKS-cluster wordt geïmplementeerd. Naarmate de footprint van het globale cluster groeit, resulteert dit in veel dubbele beleidsregels. U kunt ook beleidsregels toepassen op een Azure-abonnement of Azure-beheergroep. Met deze methode kunt u één set beleidsregels toepassen op alle AKS-clusters binnen het bereik van een abonnement of alle abonnementen die zijn gevonden onder een beheergroep.

Houd rekening met de volgende items bij het ontwerpen van beleid voor meerdere AKS-clusters:

• Beleidsregels toepassen die globaal moeten worden toegepast op alle AKS-exemplaren op een beheergroep of abonnement.
• Plaats elk regionaal cluster in een eigen resourcegroep, zodat regiospecifieke beleidsregels kunnen worden toegepast op de resourcegroep.

Zie Cloud Adoption Framework-resourceorganisatie voor materialen die u helpen bij het opzetten van een strategie voor beleidsbeheer.

Workloadimplementatie

Overweeg naast de configuratie van het AKS-exemplaar de workload die in elke regionale instantie of stempel is geïmplementeerd. Voor implementatieoplossingen of pijplijnen is een configuratie vereist voor elke regionale stempel. Naarmate er meer stempels worden toegevoegd aan het globale cluster, moet het implementatieproces worden uitgebreid of moet het flexibel genoeg zijn om de nieuwe regionale exemplaren aan te kunnen.

Houd rekening met de volgende items bij het plannen van de workloadimplementatie.

• Generaliseer de implementatie, zoals met een Helm-grafiek, om ervoor te zorgen dat één implementatieconfiguratie kan worden gebruikt voor meerdere clusterstempels.
• Gebruik één pijplijn voor continue implementatie die is geconfigureerd voor het implementeren van de workload voor alle clusterstempels.
• Geef zegelspecifieke instantiedetails op als implementatieparameters.
• Overweeg hoe diagnostische logboekregistratie van toepassingen en gedistribueerde tracering zijn geconfigureerd voor waarneembaarheid voor de hele toepassing.

Beschikbaarheid en failover

Een belangrijke motivatie voor het kiezen van een Kubernetes-architectuur met meerdere regio's is de beschikbaarheid van de service. Als een service of serviceonderdeel niet meer beschikbaar is in één regio, moet verkeer worden doorgestuurd naar een regio waar nog een exemplaar van die service beschikbaar is. Een architectuur met meerdere regio's bevat veel verschillende storingspunten. In deze sectie wordt elk van deze mogelijke foutpunten besproken.

Fouten in toepassingspods

Een Kubernetes Deployment-object wordt gebruikt om een ReplicaSet te maken, waarmee meerdere replica's van een pod worden beheerd. Als één pod niet beschikbaar is, wordt verkeer gerouteerd tussen de resterende pods. De Kubernetes ReplicaSet probeert het opgegeven aantal replica's actief te houden. Als één exemplaar uitvalt, moet er automatisch een nieuw exemplaar worden gemaakt. Liveness-tests kunnen worden gebruikt om de status van de toepassing of het proces dat wordt uitgevoerd in de pod te controleren. Als de service niet reageert, verwijdert de livenesstest de pod, waardoor de ReplicaSet wordt gedwongen een nieuw exemplaar te maken.

Zie Kubernetes ReplicaSet voor meer informatie.

Hardwarefouten in datacenter

Gelokaliseerde fouten kunnen af en toe optreden. Energie kan bijvoorbeeld niet meer beschikbaar zijn voor één rek met Azure-servers. Gebruik Azure-beschikbaarheidszones om uw AKS-knooppunten te beschermen tegen een single point of failure. Door beschikbaarheidszones te gebruiken, zorgt u ervoor dat AKS-knooppunten in een ene beschikbaarheidszone fysiek worden gescheiden van die knooppunten die zijn gedefinieerd in een andere beschikbaarheidszone.

Zie AKS- en Azure-beschikbaarheidszones voor meer informatie.

Fouten in Azure-regio's

Wanneer een hele regio niet meer beschikbaar is, zijn de pods in het cluster niet meer beschikbaar om aanvragen te verwerken. In dit geval stuurt Azure Front Door al het verkeer naar de resterende gezonde regio's. De Kubernetes-clusters en -pods in de gezonde regio's blijven aanvragen verwerken.

Zorg ervoor dat in deze situatie meer aanvragen en verkeer naar het resterende cluster worden gecompenseerd. Overweeg het volgende:

• Zorg ervoor dat netwerk- en rekenresources de juiste grootte hebben om plotselinge toename van het verkeer te absorberen vanwege failover van regio's. Als u bijvoorbeeld Azure CNI gebruikt, moet u ervoor zorgen dat u een subnet hebt dat groot genoeg is om alle IP-adressen van pods te ondersteunen terwijl het verkeer wordt bespioneerd.
• Gebruik de horizontale automatische schaalaanpassing voor pods om het aantal podreplica's te verhogen om de toegenomen regionale vraag te compenseren.
• Gebruik de automatische schaalaanpassing van AKS-clusters om het aantal Kubernetes-exemplaarknooppunten te verhogen om de toegenomen regionale vraag te compenseren.

Zie Automatische schaalaanpassing van horizontale pods en automatische schaalaanpassing van AKS-clusters voor meer informatie.

Netwerktopologie

Net als bij de referentiearchitectuur van de AKS-basislijn maakt deze architectuur gebruik van een sternetwerktopologie. Naast de overwegingen die zijn opgegeven in de referentiearchitectuur voor de AKS-basislijn, moet u rekening houden met de volgende aanbevolen procedures:

• Implementeer een hub-spoke-set virtuele netwerken voor elk regionaal AKS-exemplaar. Binnen elke regio koppelt u elke spoke aan het virtuele hubnetwerk.
• Routeer al het uitgaande verkeer via een Azure Firewall-exemplaar dat in elk regionaal hubnetwerk is gevonden. Gebruik Azure Firewall Manager-beleid om firewallbeleid voor alle regio's te beheren.
• Volg de IP-grootte in de referentiearchitectuur van de AKS-basislijn en sta meer IP-adressen toe voor zowel knooppunt- als podschaalbewerkingen als u een regionale storing in een andere regio ondervindt en het verkeer naar de resterende regio's aanzienlijk toeneemt.

Verkeersbeheer

Met de referentiearchitectuur van de AKS-basislijn wordt werkbelastingverkeer rechtstreeks doorgestuurd naar een Azure-toepassing Gateway-exemplaar en vervolgens doorgestuurd naar de back-end load balancer en AKS-toegangsbeheerresources. Wanneer u met meerdere clusters werkt, worden de clientaanvragen gerouteerd via een Azure Front Door-exemplaar, dat wordt gerouteerd naar het Azure-toepassing Gateway-exemplaar.

Download een Visio-bestand van dit diagram.

1. De gebruiker verzendt een aanvraag naar een domeinnaam (zoals https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), die is omgezet in het Azure Front Door-profiel. Deze aanvraag wordt versleuteld met een jokertekencertificaat (*.azurefd.net) dat is uitgegeven voor alle subdomeinen van Azure Front Door. Azure Front Door valideert de aanvraag op basis van firewallbeleid voor webtoepassingen, selecteert de snelste oorsprong (op basis van status en latentie) en gebruikt openbare DNS om het oorspronkelijke IP-adres (Azure-toepassing Gateway-exemplaar) op te lossen.

2. Azure Front Door stuurt de aanvraag door naar het geselecteerde juiste Application Gateway-exemplaar, dat fungeert als het toegangspunt voor de regionale stempel. Het verkeer stroomt via internet. Azure Front Door zorgt ervoor dat het verkeer naar de oorsprong is versleuteld.

   Overweeg een methode om ervoor te zorgen dat het Application Gateway-exemplaar alleen verkeer van het Front Door-exemplaar accepteert. Eén benadering is het gebruik van een netwerkbeveiligingsgroep in het subnet dat de Application Gateway bevat. De regels kunnen binnenkomend (of uitgaand) verkeer filteren op basis van eigenschappen zoals Bron, Poort, Bestemming. Met de eigenschap Bron kunt u een ingebouwde servicetag instellen die IP-adressen voor een Azure-resource aangeeft. Met deze abstractie kunt u de regel eenvoudiger configureren en onderhouden en IP-adressen bijhouden. Overweeg bovendien om de X-Azure-FDID header te gebruiken, die Azure Front Door toevoegt aan de aanvraag voordat deze naar de oorsprong wordt verzonden, om ervoor te zorgen dat het Application Gateway-exemplaar alleen verkeer van het Front Door-exemplaar accepteert. Zie Protocolondersteuning voor HTTP-headers in Azure Front Door voor meer informatie over Front Door-headers.

Overwegingen voor gedeelde resources

Hoewel de focus van dit scenario ligt op het hebben van meerdere Kubernetes-exemplaren over meerdere Azure-regio's, is het zinvol om bepaalde resources in alle regio's te delen. Eén benadering is het gebruik van één Bicep-bestand om alle gedeelde resources te implementeren en vervolgens een andere om elke regionale stempel te implementeren. In deze sectie wordt elk van deze gedeelde resources en overwegingen beschreven voor het gebruik van elk van deze gedeelde resources voor meerdere AKS-exemplaren.

Container Registry

Azure Container Registry wordt in deze architectuur gebruikt om containerinstallatiekopieënservices te bieden. Het cluster haalt containerinstallatiekopieën op uit het register. Houd rekening met de volgende items bij het werken met Azure Container Registry in een clusterimplementatie met meerdere regio's.

Geografische beschikbaarheid

Plaats een containerregister in elke regio waarin een AKS-cluster is geïmplementeerd. Deze aanpak maakt netwerkbewerkingen met lage latentie mogelijk, waardoor snelle, betrouwbare overdrachten van de afbeeldingslaag mogelijk zijn. Dit betekent ook dat u meerdere service-eindpunten voor installatiekopieën hebt om beschikbaarheid te bieden wanneer regionale services niet beschikbaar zijn. Met de geo-replicatiefunctionaliteit van Azure Container Registry kunt u één containerregister beheren dat automatisch wordt gerepliceerd naar meerdere regio's.

Overweeg om één register te maken, met replica's in elke Azure-regio die clusters bevat. Zie Geo-replicatie in Azure Container Registry voor meer informatie over Azure Container Registry-replicatie.

Afbeelding van meerdere Azure Container Registry-replica's vanuit Azure Portal.

Clustertoegang

Voor elk AKS-cluster is toegang tot het containerregister vereist, zodat deze containerinstallatiekopielagen kan ophalen. Er zijn meerdere manieren om toegang tot Azure Container Registry tot stand te brengen. In deze architectuur wordt voor elk cluster een beheerde identiteit gemaakt, die vervolgens de AcrPull rol in het containerregister krijgt. Zie de referentiearchitectuur van de AKS-basislijn voor meer informatie en aanbevelingen over het gebruik van beheerde identiteiten voor Toegang tot Azure Container Registry.

Deze configuratie wordt gedefinieerd in het Bicep-bestand met clusterstempels, zodat telkens wanneer een nieuwe stempel wordt geïmplementeerd, de nieuwe AKS-instantie toegang krijgt. Omdat het containerregister een gedeelde resource is, moet u ervoor zorgen dat uw implementaties de resource-id van het containerregister als parameter bevatten.

Azure Monitor

De functie Azure Monitor Container Insights is het aanbevolen hulpprogramma voor het bewaken en begrijpen van de prestaties en status van uw cluster- en containerworkloads. Container insights maakt gebruik van zowel een Log Analytics-werkruimte voor het opslaan van logboekgegevens als metrische gegevens van Azure Monitor voor het opslaan van numerieke tijdreeksgegevens. Prometheus-metrische gegevens kunnen ook worden verzameld door Container Insights en de gegevens kunnen worden verzonden naar de beheerde Azure Monitor-service voor Prometheus - of Azure Monitor-logboeken. Zie de referentiearchitectuur van de AKS-basislijn voor meer informatie.

U kunt ook de diagnostische instellingen voor uw AKS-cluster configureren voor het verzamelen en analyseren van resourcelogboeken van de onderdelen van het AKS-besturingsvlak en deze doorsturen naar een Log Analytics-werkruimte.

Wanneer u een bewakingsoplossing ontwerpt voor een architectuur met meerdere regio's, is het belangrijk dat u rekening houdt met de koppeling tussen elke stempel. U kunt één Log Analytics-werkruimte implementeren die wordt gedeeld door elk Kubernetes-cluster. Net als bij de andere gedeelde resources definieert u uw regionale stempel om informatie te gebruiken over de enkele wereldwijd gedeelde Log Analytics-werkruimte en verbindt u elk regionaal cluster met die ene gedeelde werkruimte. Wanneer elk regionaal cluster diagnostische logboeken naar die ene Log Analytics-werkruimte verzendt, kunt u de gegevens, samen met metrische gegevens van resources, gebruiken om eenvoudiger rapporten en dashboards te maken die u helpen begrijpen hoe uw hele oplossing voor meerdere regio's wordt uitgevoerd.

Azure Front Door

Azure Front Door wordt gebruikt om verkeer naar elk AKS-cluster te verdelen en te routeren. Azure Front Door maakt ook globale routering van laag 7 mogelijk. Deze mogelijkheden zijn vereist voor dit scenario.

Clusterconfiguratie

Wanneer elk regionaal AKS-exemplaar wordt toegevoegd, moet de Application Gateway die naast het Kubernetes-cluster wordt geïmplementeerd, worden ingeschreven als een origin in Azure Front Door, waardoor deze beschikbaar is voor routering. Voor deze bewerking is een update van uw infrastructuur als codeassets vereist. U kunt deze bewerking ook loskoppelen van de implementatieconfiguratie en beheren met behulp van hulpprogramma's zoals de Azure CLI.

Certificaten

Azure Front Door biedt geen ondersteuning voor origins met behulp van zelfondertekende certificaten, zelfs in ontwikkel- of testomgevingen. Als u HTTPS-verkeer wilt inschakelen, moet u uw TLS/SSL-certificaat maken dat is ondertekend door een certificeringsinstantie (CA). Zie Toegestane certificeringsinstanties voor het inschakelen van aangepaste HTTPS op Azure Front Door voor meer informatie over andere CA's die door Front Door worden ondersteund.

Voor het testen of voor niet-productieclusters kunt u overwegen om Certbot te gebruiken om een X3-certificaat van Let's Encrypt Authority X3 te maken voor elk van de toepassingsgateways.

Bij het plannen van een productiecluster gebruikt u de voorkeursmethode van uw organisatie voor het aanschaffen van TLS-certificaten.

Clustertoegang en identiteit

Zoals besproken in de referentiearchitectuur van de AKS-basislijn, raden we u aan Om Microsoft Entra-id te gebruiken als id-provider voor uw clusters. De Microsoft Entra-groepen kunnen vervolgens worden gebruikt om de toegang tot clusterbronnen te beheren.

Wanneer u meerdere clusters beheert, moet u beslissen over een toegangsschema. De volgende opties zijn beschikbaar:

• Maak een globale toegangsgroep voor het hele cluster, waar leden toegang hebben tot alle objecten in elk Kubernetes-exemplaar in het cluster. Deze optie biedt minimale beheerbehoeften; het verleent echter aanzienlijke bevoegdheden aan elk groepslid.
• Maak een afzonderlijke toegangsgroep voor elk Kubernetes-exemplaar dat wordt gebruikt om toegang te verlenen tot objecten in een afzonderlijk clusterexemplaren. Met deze optie neemt de administratieve overhead toe; Het biedt echter ook gedetailleerdere clustertoegang.
• Definieer gedetailleerde toegangsbeheer voor Kubernetes-objecttypen en naamruimten en correleer de resultaten met een Microsoft Entra-groepsstructuur. Met deze optie neemt de administratieve overhead aanzienlijk toe; Het biedt echter gedetailleerde toegang tot niet alleen elk cluster, maar de naamruimten en Kubernetes-API's die in elk cluster worden gevonden.

Voor beheerderstoegang kunt u een Microsoft Entra-groep maken voor elke regio. Verdeel elke groep volledige toegang tot het bijbehorende clusterstempel in die regio. Leden van elke groep hebben vervolgens beheerderstoegang tot de bijbehorende clusters.

Zie AKS Microsoft Entra-integratie voor meer informatie over het beheren van AKS-clustertoegang met Microsoft Entra-id.

Gegevens, status en cache

Wanneer u een wereldwijd gedistribueerde set AKS-clusters gebruikt, moet u rekening houden met de architectuur van de toepassing, het proces of andere workloads die in het cluster kunnen worden uitgevoerd. Als workloads op basis van statussen verspreid zijn over de clusters, moeten ze dan toegang krijgen tot een statusarchief? Als een proces elders in het cluster opnieuw wordt gemaakt vanwege een fout, heeft de workload of het proces nog steeds toegang tot een afhankelijke oplossing voor statusopslag of caching? Status kan op veel manieren worden opgeslagen, maar het is complex om zelfs in één Kubernetes-cluster te beheren. De complexiteit neemt toe bij het toevoegen van meerdere Kubernetes-clusters. Vanwege regionale toegang en complexiteit kunt u overwegen om uw toepassingen te ontwerpen voor het gebruik van een wereldwijd gedistribueerde statusopslagservice.

Het ontwerp van deze architectuur bevat geen configuratie voor statusproblemen. Als u één logische toepassing uitvoert op meerdere AKS-clusters, kunt u overwegen om uw workload te ontwerpen voor het gebruik van een wereldwijd gedistribueerde gegevensservice, zoals Azure Cosmos DB. Azure Cosmos DB is een wereldwijd gedistribueerd databasesysteem waarmee u gegevens kunt lezen en schrijven vanuit de lokale replica's van uw database, en de Cosmos DB-service beheert geo-replicatie voor u. Zie Azure Cosmos DB voor meer informatie.

Als uw workload gebruikmaakt van een caching-oplossing, moet u ervoor zorgen dat u uw cachingservices ontwerpt, zodat ze functioneel blijven, zelfs tijdens failover-gebeurtenissen. Zorg ervoor dat de workload zelf bestand is tegen failover in de cache en dat de cacheoplossingen aanwezig zijn op alle regionale AKS-exemplaren.

Kostenoptimalisatie

Gebruik de Azure-prijscalculator om de kosten te schatten voor de services die in de architectuur worden gebruikt. Andere aanbevolen procedures worden beschreven in de sectie Kostenoptimalisatie in Microsoft Azure Well-Architected Framework en specifieke configuratieopties voor kostenoptimalisatie in het artikel Kosten optimaliseren .

Overweeg AKS-kostenanalyse in te schakelen voor gedetailleerde kostentoewijzing van clusterinfrastructuur door Kubernetes-specifieke constructies.

Volgende stappen

• AKS-beschikbaarheidszones
• Azure Kubernetes Fleet Manager
• Geo-replicatie in Azure Container Registry
• Gekoppelde Azure-regio's

Verwante resources

• Azure Well-Architected Framework review for Azure Kubernetes Service (AKS)
• Basislijnarchitectuur voor een AKS-cluster (Azure Kubernetes Service)
• CI/CD-pijplijn voor workloads op basis van een container
• Integratie van AKS Microsoft Entra
• Documentatie voor Azure Front Door
• Documentatie voor Azure Cosmos DB