AKS-basislijn voor clusters met meerdere regio's

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

Deze architectuur is gebaseerd op de AKS-basislijnarchitectuur, het aanbevolen startpunt van Microsoft voor de AKS-infrastructuur. De AKS-basislijn bevat infrastructuurfuncties zoals Azure Active Directory -podidentiteit (Azure AD), beperkingen voor in- en uitvoeren, resourcelimieten en andere beveiligde AKS-infrastructuurconfiguraties. Deze infrastructurele details worden niet in dit document behandeld. U wordt aangeraden vertrouwd te raken met de AKS-basislijn voordat u doorgaat met de inhoud voor meerdere regio's.

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. Hieronder vindt u alleen de onderdelen die uniek zijn voor deze architectuur met meerdere clusters. Voor de rest verwijst u naar de AKS-basislijnarchitectuur.

• Meerdere clusters/meerdere regio's 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 meer beschikbaar is, wordt verkeer gerouteerd naar een regio die het dichtst bij de gebruiker ligt die de aanvraag heeft ingediend.
• hub-spoke-netwerk per regio Er wordt een regionaal hub-spoke-netwerkpaar geïmplementeerd voor elk regionaal AKS-exemplaar. Azure Firewall Manager worden gebruikt voor het beheren van firewallbeleidsregels in alle regio's.
• Regionaal sleutelopslag Azure Key Vault is in elke regio ingericht voor het opslaan van gevoelige waarden en sleutels die specifiek zijn voor het AKS-exemplaar en ondersteunende services die in die regio zijn gevonden.
• Azure Front Door Azure Front Door wordt gebruikt om verkeer te balanceren en te omgeleid naar een regionale Azure Application Gateway-instantie, die zich voor elk AKS-cluster bevindt. Azure Front Door maakt wereldwijde routering in laag zeven mogelijk, die beide vereist zijn voor deze referentiearchitectuur.
• Log Analytics Regionale Log Analytics-exemplaren worden gebruikt voor het opslaan van regionale metrische netwerkgegevens 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 containerafbeeldingen 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 het repliceren van afbeeldingen naar de geselecteerde Azure-regio's en het bieden van voortdurende toegang tot afbeeldingen, zelfs als er een storing in een regio is.

Ontwerppatronen

Deze referentiearchitectuur maakt gebruik van twee cloudontwerppatronen. Geografisch knooppunt (geodes),waar elke regio elke aanvraag kan verwerken, en Implementatiestempels waar meerdere onafhankelijke kopieën van een toepassing of toepassingsonderdeel worden geïmplementeerd vanuit één bron (implementatiesjabloon).

Overwegingen bij het geografische knooppuntpatroon

Wanneer u regio's selecteert waarin elk AKS-cluster wordt geïmplementeerd, kunt u overwegen om regio's dicht bij de workload-consument of uw klanten te overwegen. Overweeg ook om gekoppelde Azure-regio's te gebruiken. Gekoppelde regio's bestaan uit twee regio's binnen dezelfde geografie, die van invloed zijn op hoe Azure-onderhoud wordt uitgevoerd. Naarmate uw cluster verder wordt geschaald dan twee regio's, blijft u de plaatsing van regionale paren plannen voor elk paar AKS-clusters. Zie Gekoppelde Azure-regio's voor meer informatie over gepareerde regio's.

Binnen elke regio worden de knooppunten in de AKS-knooppuntgroepen verdeeld over meerdere beschikbaarheidszones om problemen door zone-storingen te voorkomen. Beschikbaarheidszones worden ondersteund in een beperkt aantal regio's, wat van invloed is op de plaatsing van regionale clusters. Zie AKS Beschikbaarheidszones voor meer informatie over AKS en beschikbaarheidszones, inclusief een lijst met ondersteunde regio'Beschikbaarheidszones.

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 zegel. 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 zegel-exemplaar maken. Wanneer u een proces voor het maken en beheren van implementatiestempels selecteert, is het belangrijk om rekening te houden met het volgende:

• Zegeldefinitietechnologie selecteren die ge generaliseerde configuratie mogelijk maakt, zoals infrastructuur als code
• Instantiespecifieke waarden opgeven met behulp van een implementatie-invoermechanisme, zoals variabelen of parameterbestanden
• Implementatiehulpprogramma's selecteren die flexibele, herhaalbare en idempotente implementatie mogelijk maken
• In een actief/actief-zegelconfiguratie moet u rekening houden met de verdeling van het verkeer over elke stempel
• Wanneer stempels worden toegevoegd aan en verwijderd uit de verzameling, moet u rekening houden met capaciteits- en kostenproblemen
• Denk na over het verkrijgen van zichtbaarheid en/of het bewaken van de verzameling stempels als één eenheid

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

Clusterimplementatie en bootstrapping

Wanneer u meerdere Kubernetes-clusters implementeert in zeer beschikbare en geografisch gedistribueerde configuraties, is het essentieel om de som van elk Kubernetes-cluster als gekoppelde eenheid te beschouwen. 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 door extra Kubernetes-exemplaren toe te voegen of te verwijderen. Denk na over regionale fouten en zorg ervoor dat eventuele bijproducten van een storing worden gecompenseerd in uw implementatie- en configuratieplan.

Clusterdefinitie

U hebt veel opties voor het implementeren van een Azure Kubernetes Service cluster. De Azure Portal, Azure CLI en Azure PowerShell zijn allemaal goede opties voor het implementeren van afzonderlijke of niet-gekoppelde AKS-clusters. Deze hulpprogramma's kunnen echter uitdagingen vormen bij het werken met veel nauw gekoppelde AKS-clusters. Als u bijvoorbeeld de Azure Portal u de kans op een misserconfiguratie 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. Hoewel u een herhaalbaar en geautomatiseerd proces kunt maken met behulp van de opdrachtregelprogramma's, is het aantal zaken zoals idempotentie, implementatiefoutbeheer en foutherstel van toepassing op u en de scripts die u bouwt.

Wanneer u met veel AKS-exemplaren werkt, raden we u aan infrastructuur als codeoplossingen te gebruiken, zoals Azure Resource Manager-sjablonen, Bicep-sjablonen of Terraform-configuraties. Infrastructuur als code-oplossingen bieden een geautomatiseerde, schaalbare en idempotente implementatieoplossing. Deze referentiearchitectuur bevat een ARM-sjabloon voor de gedeelde oplossingenservices en vervolgens een andere voor de AKS-clusters en regionale services. Met infrastructuur als code kan een implementatiestempel worden gedefinieerd met ge generaliseerde configuraties, zoals netwerken, autorisatie en diagnostische gegevens. Een implementatieparameterbestand kan worden opgegeven 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 als code-assets kunnen kostbaar 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. In dergelijke gevallen is het gebruik van een meer imperatieve benadering, zoals met opdrachtregelprogramma's of zelfs een handmatige benadering, geen probleem.

Clusterimplementatie

Zodra de clusterstempeldefinitie is gedefinieerd, hebt u veel opties voor het implementeren van afzonderlijke of meerdere zegel-exemplaren. Het wordt aanbevolen moderne continue integratietechnologie te gebruiken, zoals GitHub Actions of Azure Pipelines. Het voordeel van implementatieoplossingen op basis van continue integratie is onder andere:

• Implementaties op basis van code waarmee stempels kunnen worden toegevoegd en verwijderd met behulp van code
• Geïntegreerde testmogelijkheden
• Geïntegreerde omgevings- en faseringsmogelijkheden
• Geïntegreerde oplossingen voor geheimenbeheer
• Integratie met code-/implementatiebronbeheer
• Implementatiegeschiedenis en logboekregistratie

Wanneer nieuwe stempels worden toegevoegd aan of verwijderd uit het globale cluster, moet de implementatiepijplijn worden bijgewerkt om deze weer te geven. In de referentie-implementatie wordt elke regio geïmplementeerd als een afzonderlijke stap binnen een GitHub-actiewerkstroom (voorbeeld). Deze configuratie is eenvoudig omdat elk clusterin exemplaar duidelijk is gedefinieerd in de implementatiepijplijn. Deze configuratie biedt echter enige 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 door deze lijst lopen en een cluster implementeren in elke regio in de lijst. 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 van de lijst met gewenste regio's wordt.

Houd er ook rekening mee dat het verwijderen van een clusterstempel uit de implementatiepijplijn er niet noodzakelijkerwijs voor zorgt dat deze ook buiten gebruik wordt gesteld. Afhankelijk van uw implementatietechnologie 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 elk Kubernetes-exemplaar of elke Kubernetes-zegel is geïmplementeerd, moeten clusteronderdelen, zoals ingress-controllers, identiteitsoplossingen en workloadonderdelen, worden geïmplementeerd en geconfigureerd. U moet ook overwegen om beveiligings-, toegangs- en governancebeleid toe te passen op het cluster.

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

GitOps

In plaats van kubertnets-onderdelen handmatig te configureren, kunt u geautomatiseerde hulpprogramma's gebruiken om configuraties toe te passen op een Kubernetes-cluster wanneer deze configuraties worden ingecheckt in een bronopslagplaats. Dit proces wordt vaak Aangeduid als GitOps en populaire GitOps-oplossingen voor Kubernetes zijn Flux en Cd.

GitOps wordt uitgebreid beschreven in de referentiearchitectuur voor AKS-basislijnen. De belangrijke opmerking hier is dat het gebruik van een op GitOps gebaseerde configuratiebenadering ervoor zorgt dat elke Kubernetes-instantie op dezelfde manier wordt geconfigureerd zonder dat er een bespoke-inspanning nodig is.

Azure Policy

Naarmate er meerdere Kubernetes-exemplaren worden toegevoegd, neemt het voordeel van op beleid gebaseerde governance, naleving en configuratie toe. Met behulp van beleidsregels biedt Azure Policies in dit geval een gecentraliseerde en schaalbare methode voor clusterbeheer. Het voordeel van AKS-beleid wordt beschreven in de AKS-basislijnreferentiearchitectuur.

Azure Policy is ingeschakeld in deze referentie-implementatie wanneer de AKS-clusters worden gemaakt en het beperkende initiatief in de controlemodus wordt toegewezen om inzicht te krijgen in niet-naleving. De implementatie stelt ook aanvullende 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 containerafbeeldingen in het cluster worden uitgevoerd. U kunt uw eigen aangepaste initiatieven maken. Combineer de beleidsregels die van toepassing zijn op uw workload in één toewijzing.

Beleidsbereik verwijst naar het doel van elk beleids- 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 is geïmplementeerd. Naarmate de footprint van het wereldwijde cluster toeneemt, leidt dit tot veel dubbel beleid. U kunt beleidsregels ook instellen op een Azure-abonnement of Azure-beheergroep, waardoor één set beleidsregels kan worden toegepast op alle AKS-clusters binnen het bereik van een abonnement en/of alle abonnementen die onder een beheergroep worden gevonden.

Houd rekening met het volgende 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 Frameworks Management group and subscription organization (Beheergroep en abonnementsorganisatie van Cloud Adoption Frameworks) voor materiaal dat u helpt bij het opstellen van een strategie voor beleidsbeheer.

Workloadimplementatie

Naast de configuratie van het AKS-exemplaar moet u rekening houden met de workload die in elk regionaal exemplaar of elke regionale stempel is geïmplementeerd. Implementatieoplossingen of pijplijnen vereisen configuratie voor elke regionale stempel. Als er extra stempels worden toegevoegd aan het globale cluster, moet het implementatieproces worden uitgebreid of flexibel genoeg zijn om ruimte te bieden aan de nieuwe regionale instanties.

Houd rekening met de volgende items bij het plannen van de implementatie van workloads.

• 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 om de workload op alle clusterstempels te implementeren.
• Geef stempelspecifieke instantiedetails op als implementatieparameters.
• Denk na over hoe diagnostische logboekregistratie van toepassingen en gedistribueerde tracering worden geconfigureerd voor waarneembaarheid voor de hele toepassing.

Beschikbaarheid/failover

Een belangrijke motivatie voor het kiezen van een Kubernetes-architectuur met meerdere regio's is servicebeschikbaarheid. Dat wil zeggen dat als een service of serviceonderdeel niet meer beschikbaar is in één regio, verkeer moet worden gerouteerd naar een regio waar die service beschikbaar is. Een architectuur met meerdere regio's bevat veel verschillende foutpunten. In deze sectie worden al 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 er één exemplaar uitgaat, moet er een nieuwe instantie worden gemaakt. Ten slotte kunnen er liveheidstests worden gebruikt om de status van de toepassing of het proces dat in de pod wordt uitgevoerd te controleren. Als de service niet op de juiste manier reageert, wordt de pod door de liveness-test verwijderd, waardoor de ReplicaSet een nieuw exemplaar moet maken.

Zie Kubernetes ReplicaSet voor meer informatie.

Toepassingspods (globaal)

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

Zorg dat u in deze situatie het toegenomen verkeer/de aanvragen naar het resterende cluster compenseren. Enkele zaken om rekening mee te houden:

• Zorg ervoor dat netwerk- en rekenbronnen de juiste grootte hebben om een plotselinge toename van het verkeer als gevolg van regio-failover op te vangen. Als u bijvoorbeeld Azure CNI, moet u ervoor zorgen dat u een subnet hebt dat ondersteuning biedt voor alle Pod-IPs met een piek in de verkeersbelasting.
• Gebruik Horizontale automatische schaalverhoging van pods om het aantal podreplica's te verhogen om de toegenomen regionale vraag te compenseren.
• Gebruik automatische schaalverhoging van AKS-clusters om het aantal Kubernetes-instantieknooppunt te verhogen om de toegenomen regionale vraag te compenseren.

Zie Horizontal Pod Autoscaler en AKS cluster autoscaler voor meer informatie.

Kubernetes-knooppuntgroepen (regionaal)

Soms kan er een lokale storing optreden in rekenresources, bijvoorbeeld als er geen stroom meer beschikbaar is voor één rek Azure-servers. Gebruik Azure-beschikbaarheidszones om te voorkomen dat uw AKS-knooppunten een regionale single point-fout worden. 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)

Bij een volledige regionale fout worden Azure Front Door naar de resterende en gezonde regio's gerouteerd. Zorg er ook in deze situatie voor dat u het toegenomen verkeer/de aanvragen naar het resterende cluster kunt compenseren.

Zie voor meer informatie Azure Front Door.

Netwerktopologie

Net als bij de referentiearchitectuur voor AKS-basislijnen maakt deze architectuur gebruik van een hub-spoke-netwerktopologie. Naast de overwegingen die zijn opgegeven in de AKS-basislijnreferentiearchitectuur,moet u rekening houden met het volgende:

• Implementeert een hub-spoke voor elk regionaal AKS-exemplaar, waarbij de virtuele hub-spoke-netwerken zijn peered.
• Routeer al het uitgaande verkeer via een Azure Firewall in elk regionaal hubnetwerk. Gebruik Azure Firewall Manager voor het beheren van firewallbeleid in alle regio's.
• Volg de IP-grootten in de referentiearchitectuur voor AKS-basislijnen en sta extra IP-adressen toe voor bewerkingen voor zowel knooppunt- als podschaal in het geval van een regionale storing.

Verkeersbeheer

Met de referentiearchitectuur voor AKS-basislijnen wordt werkbelastingverkeer rechtstreeks doorgestuurd naar een Azure Application Gateway-exemplaar en vervolgens doorgestuurd naar de resources voor load balancer/AKS-ingress. Wanneer u met meerdere clusters werkt, worden clientaanvragen gerouteerd via een Azure Front Door-exemplaar, dat wordt gerouteerd naar het Azure Application Gateway-exemplaar.

1. De gebruiker verzendt een aanvraag naar een domeinnaam (bijvoorbeeld , die wordt opgelost naar het https://contoso-web.azurefd.net) Azure Front Door exemplaar. Deze aanvraag wordt versleuteld met een jokertekencertificaat (*.azurefd.net) dat is uitgegeven voor alle subdomeinen van Azure Front Door. De Azure Front Door-instantie valideert de aanvraag op basis van WAF-beleid, selecteert de snelste back-Azure Application Gateway (op basis van status en latentie) en gebruikt openbare DNS om het ip-adres van de back-Azure Application Gateway om te lossen.

2. Front Door aanvraag wordt doorgestuurd naar de geselecteerde juiste Application Gateway-instantie, die fungeert als het toegangspunt voor de regionale zegel. Het verkeer loopt via internet en wordt versleuteld door Azure Front Door. Overweeg een methode om ervoor te zorgen dat het Application Gateway alleen verkeer van het Front Door accepteert. Een van de benaderingen is het gebruik van een netwerkbeveiligingsgroep in het subnet dat de Application Gateway. Met de regels kan het inkomende (of uitgaande) verkeer worden gefilterd op basis van eigenschappen zoals Bron, Poort, Doel. Met de eigenschap Bron kunt u een ingebouwde servicetag instellen die IP-adressen voor een Azure-resource aangeeft. Deze abstractie maakt het eenvoudiger om de regel te configureren en te onderhouden en IP-adressen bij te houden. Overweeg daarnaast het gebruik van de Front Door naar back-Application Gateway-header om ervoor te zorgen dat het Application Gateway-exemplaar alleen verkeer van het Front Door X-Azure-FDID accepteert. Zie Protocolondersteuning voor HTTP Front Door headers in Azure Front Door voor meer informatie over Azure Front Door.

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 behulp van één ARM-sjabloon om alle gedeelde resources te implementeren en vervolgens een andere om elke regionale zegel te implementeren. In deze sectie worden al deze gedeelde resources en overwegingen voor het gebruik van elk van deze resources in meerdere AKS-exemplaren bekeken.

Container Registry

Azure Container Registry wordt in deze referentiearchitectuur gebruikt om services voor containerafbeeldingen te bieden (pull). Houd rekening met de volgende items wanneer u Azure Container Registry in een clusterimplementatie met meerdere regio's.

Geografische beschikbaarheid

Door een containerregister te plaatsen in elke regio waarin een AKS-cluster is geïmplementeerd, kunnen bewerkingen dicht bij het netwerk worden uitgevoerd, waardoor snelle, betrouwbare overdrachten van de laag van de afbeelding mogelijk zijn. Meerdere service-eindpunten voor afbeeldingen bieden ook beschikbaarheid in het geval dat regionale services niet beschikbaar zijn. Met behulp van geo-replicatiefunctionaliteit van Azure Container Registries kunt u één exemplaar Container Registry 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-replicatiein Azure Container Registry voor meer informatie over Azure Container Registry.

Afbeelding met meerdere ACR-replica's vanuit de Azure Portal.

Clustertoegang

Elk AKS-exemplaar heeft toegang nodig voor het binnenhalen van afbeeldingslagen uit de Azure Container Registry. Er zijn meerdere manieren om toegang tot uw Azure Container Registry; Deze referentiearchitectuur maakt gebruik van een beheerde Azure-identiteit voor elk cluster, die vervolgens de rol AcrPull krijgt op het Container Registry cluster. Zie AKS Baseline Reference Architecture (Referentiearchitectuur voor AKS-basislijnen) Container Registry informatie en aanbevelingen voor het gebruik van beheerde identiteitenvoor Container Registry toegang.

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

Log Analytics en Azure Monitor

De functie Azure Monitor containers is het aanbevolen hulpprogramma voor bewaking en logboekregistratie, omdat u gebeurtenissen in realtime kunt bekijken. Azure Monitor maakt gebruik van een Log Analytics-werkruimte voor het opslaan van diagnostische logboeken. Zie de referentiearchitectuur voor AKS-basislijnen voor meer informatie.

Bij het overwegen van bewaking voor een implementatie in verschillende regio's, zoals deze referentiearchitectuur, is het belangrijk om rekening te houden met de koppeling tussen elke zegel. In dit geval kunt u elk stempel beschouwen als 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 zegel om informatie over de enkele Log Analytics-werkruimte te gebruiken en elk cluster er verbinding mee te maken.

Nu elk regionaal cluster diagnostische logboeken weglaten aan één Log Analytics-werkruimte, kunnen deze gegevens, samen met metrische resourcegegevens, worden gebruikt om gemakkelijker rapporten en dashboards te maken die het volledige cluster vertegenwoordigen.

Azure Front Door

Azure Front Door wordt gebruikt om de belasting te balanceren en verkeer naar elk AKS-cluster te routeren. Azure Front Door maakt wereldwijde routering in laag zeven mogelijk, die beide vereist zijn voor deze referentiearchitectuur.

Clusterconfiguratie

Als er regionale AKS-exemplaren worden toegevoegd, moet de Application Gateway die naast het Kubernetes-cluster wordt geïmplementeerd, worden geregistreerd als een Front Door-back-end voor de juiste routering. Voor deze bewerking is een update van uw infrastructuur als code-assets vereist. Deze bewerking kan ook worden losgekoppeld van de implementatieconfiguratie en worden beheerd met hulpprogramma's zoals de Azure CLI. De ingesloten implementatiepijplijn voor referentie-implementaties maakt gebruik van een afzonderlijke Azure CLI-stap voor deze bewerking.

Certificaten

Front Door biedt geen ondersteuning voor zelf-ondertekende 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 X3-certificaat voor Let's Encrypt Authority te maken. Wanneer u een productiecluster plant, gebruikt u de voorkeursmethode van uw organisatie voor het aanschaffen van TLS-certificaten.

Zie Toegestane certificeringsinstanties voor het inschakelen van aangepaste HTTPS op Front Door voor meer informatie over andere CERTIFICERINGsinstanties die worden Azure Front Door.

Clustertoegang en -identiteit

Zoals besproken in de referentiearchitectuur voor AKS-basislijnen,is het raadzaam om Azure Active Directory als toegangs-id-provider van de clusters te gebruiken. De Azure Active Directory kunnen vervolgens worden gebruikt om de toegang tot clusterbronnen te beheren.

Wanneer u meerdere clusters beheert, moet u beslissen over een toegangsschema. Een aantal opties:

• Maak een globale clusterbrede toegangsgroep 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 cluster-exemplaar. Met deze optie neemt de administratieve overhead toe; Het biedt echter ook gedetailleerdere clustertoegang.
• Definieer gedetailleerde toegangsbesturingselementen voor Kubernetes-objecttypen en -naamruimten en correleer deze met een structuur van een Azure Directory-groep. Met deze optie neemt de administratieve overhead aanzienlijk toe; Het biedt echter gedetailleerde toegang tot niet alleen elk cluster, maar ook de naamruimten en Kubernetes-API's die in elk cluster zijn gevonden.

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

Zie AKS Azure AD-integratie voor meer informatie Azure Active Directory het beheren van toegang tot AKS-clusters met AKS.

Gegevens, status en cache

Wanneer u een wereldwijd gedistribueerd cluster van AKS-exemplaren gebruikt, moet u rekening houden met de architectuur van de toepassing, het proces of andere werkbelastingen die in het cluster kunnen worden uitgevoerd. Moet de workload op basis van een status over het cluster worden verdeeld en moet deze toegang hebben tot een statusopslag? Als een proces elders in het cluster opnieuw wordt gemaakt vanwege een fout, heeft de werkbelasting of het proces dan nog steeds toegang tot een afhankelijke statusopslag- of cachingoplossing? Status kan op veel manieren worden bereikt; Het kan echter complex zijn in één Kubernetes-cluster. De complexiteit neemt toe wanneer u meerdere geclusterde Kubernetes-exemplaren toevoegt. Vanwege regionale toegang en complexiteit kunt u overwegen om uw toepassingen te ontwerpen voor het gebruik van een wereldwijd gedistribueerde state store-service.

De referentie-implementatie voor meerdere clusters bevat geen demonstratie of configuratie voor statusproblemen. Als u toepassingen op geclusterde AKS-exemplaren wilt uitvoeren, kunt u workloads 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 voor meer informatie Azure Cosmos DB.

Als uw workload gebruikmaakt van een cachingoplossing, 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 caches en dat de caching-oplossingen aanwezig zijn op alle regionale AKS-instanties.

Kostenbeheer

Gebruik de Azure-prijscalculator om de kosten te schatten voor de services die in de architectuur worden gebruikt. Andere best practices worden beschreven in de sectie Kostenoptimalisatie in Microsoft Azure Well-Architected Framework.