AKS-basislijn voor clusters met meerdere regio's

Deze referentiearchitectuur bevat informatie over het uitvoeren van meerdere exemplaren van een AKS-cluster (Azure Kubernetes Service) in meerdere regio's in een actieve/actieve en maximaal beschikbare configuratie.

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. Het is raadzaam om 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.

Er is een referentie-implementatie van deze architectuur beschikbaar op GitHub.

Onderdelen

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

• Meerdere clusters/meerdere regio's Meerdere AKS-clusters worden 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.
• hub-spoke-netwerk per regio Een regionaal hub-spoke-netwerkpaar wordt geïmplementeerd voor elk regionaal AKS-exemplaar. Azure Firewall Manager-beleid wordt gebruikt voor het beheren van firewallbeleid in alle regio's.
• Het regionale sleutelarchief van Azure Key Vault wordt ingericht in elke regio voor het opslaan van gevoelige waarden en sleutels die specifiek zijn voor het AKS-exemplaar en ondersteunende services in die regio.
• Azure Front Door 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. Met Azure Front Door is laag zeven globale routering mogelijk, die beide vereist zijn voor deze referentiearchitectuur.
• Regionale Log Analytics-exemplaren van Log Analytics 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.
• 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 referentiearchitectuur maakt gebruik van twee cloudontwerppatronen. Geografisch knooppunt (geodes), waarbij elke regio elke aanvraag kan verwerken en implementatiestempels waarbij meerdere onafhankelijke kopieën van een toepassing of toepassingsonderdeel worden geïmplementeerd vanuit één bron (implementatiesjabloon).

Overwegingen voor geografische knooppuntpatronen

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

Bij het beheren van een AKS-cluster met meerdere regio's worden meerdere AKS-exemplaren geïmplementeerd in meerdere regio's. Elk van deze exemplaren wordt beschouwd als een stempel. In het geval van een regionale storing of de noodzaak om meer capaciteit en/of regionale aanwezigheid voor uw cluster toe te voegen, 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 die gegeneraliseerde configuratie mogelijk maken, zoals infrastructuur als code
• Geef exemplaarspecifieke waarden op met behulp van een implementatie-invoermechanisme, zoals variabelen of parameterbestanden
• Implementatiehulpprogramma's selecteren die flexibele, herhaalbare en idempotente implementatie mogelijk maken
• In een actieve/actieve stempelconfiguratie kunt u overwegen hoe verkeer wordt verdeeld over elke zegel
• Aangezien er stempels worden toegevoegd en verwijderd uit de verzameling, kunt u rekening houden met capaciteits- en kostenproblemen
• Overweeg hoe u inzicht krijgt en/of de verzameling stempels als één eenheid bewaakt.

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

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. U wilt strategieën overwegen voor uit- en inschalen door andere Kubernetes-exemplaren toe te voegen of te verwijderen. U wilt dat uw ontwerp- en implementatie- en configuratieplan rekening houden met regionale fouten of 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 een gemiste configuratie vanwege gemiste stappen of niet-beschikbare configuratieopties. Daarnaast is de implementatie en configuratie van veel clusters met behulp van de portal een tijdig proces dat de focus van een of meer technici vereist. U kunt 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 veel AKS-exemplaren werkt, raden we u aan infrastructuur als codeoplossingen te overwegen, zoals Azure Resource Manager-sjablonen, Bicep-sjablonen of Terraform-configuraties. Infrastructuur als codeoplossingen bieden een geautomatiseerde, schaalbare en idempotente implementatieoplossing. Deze referentiearchitectuur bevat een ARM-sjabloon voor de oplossingen voor gedeelde services en vervolgens een andere voor de AKS-clusters en 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 regionale specifieke 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, zoals wanneer een statisch/vast aantal AKS-exemplaren wordt geïmplementeerd, kan de overhead van infrastructuur als code opwegen tegen de voordelen. Voor deze gevallen is het gebruik van een meer imperatieve benadering, zoals met opdrachtregelprogramma's of zelfs een handmatige benadering, in orde.

Clusterimplementatie

Zodra de definitie van het 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/implementatie
• Implementatiegeschiedenis en logboekregistratie

Wanneer er nieuwe stempels worden toegevoegd aan of verwijderd uit het globale cluster, moet de implementatiepijplijn worden bijgewerkt om consistent te blijven. In de referentie-implementatie wordt elke regio geïmplementeerd als een afzonderlijke stap binnen een GitHub Action-werkstroom (voorbeeld). 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 logica te gebruiken voor het maken van clusters 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.

Het verwijderen van een clusterstempel uit de implementatiepijplijn zorgt er ook niet voor dat het ook buiten gebruik wordt gesteld. Afhankelijk van uw implementatieoplossing en -configuratie hebt u mogelijk een extra stap nodig om ervoor te zorgen dat de AKS-exemplaren op de juiste wijze buiten gebruik zijn gesteld.

Cluster bootstrapping

Zodra elke Kubernetes-instantie of -stempel 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, kunt u overwegen 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. Deze implementatie maakt gebruik van de Flux-extensie voor AKS om het automatisch opstarten van de clusters in te schakelen en direct nadat de clusters zijn geïmplementeerd.

GitOps is uitgebreider in de referentiearchitectuur van de AKS-basislijn. Het belangrijkste punt hier is dat het gebruik van een op GitOps gebaseerde benadering voor configuratie ervoor zorgt dat elke Kubernetes-instantie op dezelfde manier wordt geconfigureerd zonder op maat gemaakte inspanningen. Dit 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 wordt ingeschakeld in deze referentie-implementatie wanneer de AKS-clusters worden gemaakt en het beperkende initiatief in de controlemodus toewijzen om inzicht te krijgen in niet-naleving. De implementatie stelt ook meer beleidsregels in 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 worden uitgevoerd in het cluster. 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. De referentie-implementatie die aan deze architectuur is gekoppeld, maakt gebruik van een ARM-sjabloon om beleid 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 en/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 die globaal moeten worden toegepast op alle AKS-exemplaren, kunnen worden toegepast op een beheergroep of abonnement
• Door elk regionaal cluster in een eigen resourcegroep te plaatsen, kunnen regiospecifieke beleidsregels 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 configuratie vereist voor elke regionale stempel. Naarmate er meer stempels worden toegevoegd aan het globale cluster, moet het implementatieproces worden uitgebreid of flexibel genoeg zijn om tegemoet te komen aan de nieuwe regionale instanties.

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 gerouteerd naar een regio waar die service beschikbaar is. Een architectuur met meerdere regio's bevat veel verschillende storingspunten. In deze sectie wordt elk van deze mogelijke foutpunten besproken.

Toepassingspods (regionaal)

Een Kubernetes-implementatieobject wordt gebruikt om meerdere replica's van een pod (ReplicaSet) te maken. Als er een niet beschikbaar is, wordt verkeer gerouteerd tussen de resterende. De Kubernetes ReplicaSet probeert het opgegeven aantal replica's actief te houden. Als één exemplaar uitvalt, moet een nieuw exemplaar opnieuw worden gemaakt. Ten slotte kunnen livenesstests worden gebruikt om de status van de toepassing of het proces dat wordt uitgevoerd in de pod te controleren. Als de service niet reageert, wordt de pod verwijderd door de livenesstest, waardoor de ReplicaSet wordt gedwongen een nieuw exemplaar te maken.

Zie Kubernetes ReplicaSet voor meer informatie.

Toepassingspods (globaal)

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 het Azure Front Door-exemplaar al het verkeer naar de resterende gezonde regio's. De Kubernetes-clusters en -pods in deze regio's blijven aanvragen verwerken.

Zorg ervoor dat in deze situatie meer verkeer/aanvragen naar het resterende cluster worden gecompenseerd. Enkele aandachtspunten:

• 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 ondersteuning biedt voor alle POD-IP's met een piek in het verkeer.
• Gebruik horizontale automatische schaalaanpassing voor pods om het aantal podreplica's te verhogen om de toegenomen regionale vraag te compenseren.
• Gebruik 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.

Kubernetes-knooppuntgroepen (regionaal)

Af en toe kan een gelokaliseerde fout optreden bij het berekenen van resources, bijvoorbeeld als de stroom niet beschikbaar is voor één rek met Azure-servers. Als u wilt voorkomen dat uw AKS-knooppunten een regionale storing van één punt worden, gebruikt u Azure-beschikbaarheidszones. Het gebruik van beschikbaarheidszones zorgt ervoor dat AKS-knooppunten in een bepaalde beschikbaarheidszone fysiek worden gescheiden van de knooppunten die zijn gedefinieerd in een andere beschikbaarheidszone.

Zie AKS- en Azure-beschikbaarheidszones voor meer informatie.

Kubernetes-knooppuntgroepen (globaal)

In een volledige regionale fout stuurt Azure Front Door verkeer naar de resterende en gezonde regio's. Zorg er opnieuw voor dat in deze situatie meer verkeer/aanvragen naar het resterende cluster worden gecompenseerd.

Zie Azure Front Door 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 voor elk regionaal AKS-exemplaar, waarbij de virtuele hub-spoke-netwerken worden gekoppeld.
• 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 bewerkingen voor knooppunt- en podschaalbewerkingen als er een regionale fout opgetreden is.

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/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.azurefd.net), die is omgezet naar het Azure Front Door-exemplaar. Deze aanvraag wordt versleuteld met een jokertekencertificaat (*.azurefd.net) dat is uitgegeven voor alle subdomeinen van Azure Front Door. Het Azure Front Door-exemplaar valideert de aanvraag op basis van WAF-beleid, selecteert de snelste back-end (op basis van de status en latentie) en gebruikt openbare DNS om het back-end-IP-adres (Azure-toepassing Gateway-exemplaar) op te lossen.

2. 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 en wordt versleuteld door Azure Front Door. Overweeg een methode om ervoor te zorgen dat het Application Gateway-exemplaar alleen verkeer van het Front Door-exemplaar accepteert. Een 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. U kunt ook de Front Door naar de back-endheader X-Azure-FDID gebruiken 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 deze referentiearchitectuur ligt op het hebben van meerdere Kubernetes-exemplaren verspreid over meerdere Azure-regio's, is het zinvol om een aantal gedeelde resources over alle exemplaren te hebben. De AKS-referentie-implementatie voor meerdere regio's met één ARM-sjabloon voor het implementeren van alle gedeelde resources 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 referentiearchitectuur gebruikt om containerinstallatiekopieservices (pull) te bieden. Houd rekening met de volgende items bij het werken met Azure Container Registry in een clusterimplementatie met meerdere regio's.

Geografische beschikbaarheid

Het positioneren van een containerregister in elke regio waarin een AKS-cluster wordt geïmplementeerd, maakt netwerksluitingsbewerkingen mogelijk, waardoor snelle, betrouwbare overdrachten van installatiekopielagen mogelijk zijn. Meerdere service-eindpunten voor installatiekopieën hebben om beschikbaarheid te bieden wanneer regionale services niet beschikbaar zijn. Met de geo-replicatiefunctionaliteit van Azure Container Registries kunt u één Container Registry-exemplaar beheren dat naar meerdere regio's wordt gerepliceerd.

De AKS-referentie-implementatie voor meerdere regio's heeft één Container Registry-exemplaar en replica's van dit exemplaar in elke clusterregio gemaakt. Zie Geo-replicatie in Azure Container Registry voor meer informatie over Azure Container Registry-replicatie.

Afbeelding van meerdere ACR-replica's vanuit Azure Portal.

Clustertoegang

Voor elk AKS-exemplaar is toegang vereist voor het ophalen van afbeeldingslagen uit Azure Container Registry. Er zijn meerdere manieren om toegang tot Azure Container Registry tot stand te brengen; deze referentiearchitectuur maakt gebruik van een Azure Managed Identity voor elk cluster, dat vervolgens de AcrPull-rol op het Container Registry-exemplaar krijgt. Zie de referentiearchitectuur van de AKS-basislijn voor meer informatie en aanbevelingen voor het gebruik van beheerde identiteiten voor containerregistertoegang.

Deze configuratie wordt gedefinieerd in de ARM-sjabloon voor clusterstempels, zodat telkens wanneer een nieuwe stempel wordt geïmplementeerd, de nieuwe AKS-instantie toegang krijgt. Omdat containerregister een gedeelde resource is, moet u ervoor zorgen dat uw implementatiestempelsjabloon de benodigde gegevens kan gebruiken en gebruiken, in dit geval de resource-id van het Container Registry.

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 verzenden naar de beheerde Azure Monitor-service voor Prometheus - of Azure Monitor-logboeken.

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

AKS Zie de referentiearchitectuur van de AKS-basislijn voor meer informatie.

Bij het overwegen van bewaking voor een implementatie in meerdere regio's, zoals deze referentiearchitectuur, is het belangrijk dat u rekening houdt met de koppeling tussen elke zegel. In dit geval kunt u elk stempel gebruiken voor een onderdeel van één eenheid (regionaal cluster). De AKS-referentie-implementatie voor meerdere regio's maakt gebruik van één Log Analytics-werkruimte die wordt gedeeld door elk Kubernetes-cluster. Net als bij de andere gedeelde resources definieert u uw regionale stempel voor het verbruiken van informatie over de enkele Log Analytics-werkruimte en verbindt u elk cluster ermee.

Nu elk regionaal cluster diagnostische logboeken naar één Log Analytics-werkruimte verzendt, kunnen deze gegevens, samen met metrische resourcegegevens, worden gebruikt om eenvoudiger rapporten en dashboards te maken die het hele globale cluster vertegenwoordigen.

Azure Front Door

Azure Front Door wordt gebruikt om verkeer naar elk AKS-cluster te verdelen en te routeren. Met Azure Front Door is laag zeven globale routering mogelijk, die beide vereist zijn voor deze referentiearchitectuur.

Clusterconfiguratie

Omdat regionale AKS-exemplaren worden toegevoegd, moet application gateway die naast het Kubernetes-cluster is geïmplementeerd, worden ingeschreven als een Front Door-back-end voor de juiste routering. Voor deze bewerking is een update van uw infrastructuur als codeassets vereist. U kunt deze bewerking ook loskoppelen van de implementatieconfiguratie en worden beheerd met hulpprogramma's zoals de Azure CLI. De inbegrepen implementatiepijplijn voor referentie-implementaties maakt gebruik van een afzonderlijke Azure CLI-stap voor deze bewerking.

Certificaten

Front Door biedt geen ondersteuning voor zelfondertekende certificaten, zelfs niet in Dev/Test-omgevingen. Als u HTTPS-verkeer wilt inschakelen, moet u uw TLS/SSL-certificaat maken dat is ondertekend door een certificeringsinstantie (CA). De referentie-implementatie maakt gebruik van Certbot om een Let's Encrypt Authority X3-certificaat te maken. Bij het plannen van een productiecluster gebruikt u de voorkeursmethode van uw organisatie voor het aanschaffen van TLS-certificaten.

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.

Clustertoegang en identiteit

Zoals besproken in de referentiearchitectuur van de AKS-basislijn, is het raadzaam om Microsoft Entra-id te gebruiken als de toegangs-id-provider van de 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 Azure Directory-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 zijn gevonden.

Met de opgenomen referentie-implementatie worden twee Microsoft Entra-groepen gemaakt voor beheerderstoegang. Deze groepen worden opgegeven tijdens de implementatietijd van het clusterstempel met behulp van het parameterbestand voor de implementatie. Leden van elke groep hebben volledige toegang tot de bijbehorende clusterstempel.

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 gedistribueerd cluster van AKS-exemplaren gebruikt, kunt u de architectuur van de toepassing, het proces of andere workloads overwegen die in het cluster kunnen worden uitgevoerd. Als de workload op basis van statussen verspreid is over het cluster, moet deze 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 bereikt; Het kan echter complex zijn in één Kubernetes-cluster. De complexiteit neemt toe bij het toevoegen van meerdere geclusterde Kubernetes-exemplaren. Vanwege regionale toegang en complexiteit kunt u overwegen om uw toepassingen te ontwerpen voor het gebruik van een wereldwijd gedistribueerde statusopslagservice.

De implementatie van referentie voor meerdere clusters bevat geen demonstratie of configuratie voor statusproblemen. Als u toepassingen uitvoert op geclusterde AKS-exemplaren, 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 uit lokale replica's van uw database kunt lezen of schrijven. Zie Azure Cosmos DB voor meer informatie.

Als uw workload gebruikmaakt van een cacheoplossing, moet u ervoor zorgen dat deze is ontworpen zodat cachingservices functioneel blijven. Om dit te doen, moet u ervoor zorgen 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 om 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