Blauwgroene implementatie van AKS-clusters

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

Dit artikel bevat richtlijnen voor het implementeren van een blauwgroene implementatiestrategie om een nieuwe versie van een AKS-cluster (Azure Kubernetes Service) te testen terwijl de huidige versie blijft worden uitgevoerd. Zodra de nieuwe versie is gevalideerd, wordt door een routeringswijziging het gebruikersverkeer naar deze wijziging overgeschakeld. Door op deze manier te implementeren, wordt de beschikbaarheid verhoogd bij het aanbrengen van wijzigingen, inclusief upgrades, naar AKS-clusters. In dit artikel wordt het ontwerp en de implementatie van een blauwgroene implementatie van AKS beschreven die gebruikmaakt van door Azure beheerde services en systeemeigen Kubernetes-functies.

Architectuur

In deze sectie worden architecturen beschreven voor blauwgroene implementatie van AKS-clusters. Er zijn twee mogelijke situaties:

De toepassingen en API's zijn openbaar.
De toepassingen en API's zijn privégericht.

Er is ook een hybride case, die hier niet wordt besproken, waarin er een combinatie is van openbare en privégerichte toepassingen en API's in het cluster.

In het volgende diagram ziet u de architectuur voor de openbare case:

Een Visio-bestand van deze architectuur downloaden.

Azure Front Door en Azure DNS bieden het routeringsmechanisme waarmee verkeer tussen de blauwe en groene clusters wordt overgeschakeld. Zie Blauwgroene implementatie met Azure Front Door voor meer informatie. Door Azure Front Door te gebruiken, is het mogelijk om een volledige switch of een meer gecontroleerde switch te implementeren die is gebaseerd op gewichten. Deze techniek is de meest betrouwbare en efficiënte in een Azure-omgeving. Als u uw eigen DNS en load balancer wilt gebruiken, moet u ervoor zorgen dat deze zijn geconfigureerd om een veilige en betrouwbare switch te bieden.

Azure-toepassing Gateway biedt de front-ends, die zijn toegewezen aan de openbare eindpunten.

Dit diagram is bedoeld voor de privégerichte case:

Een Visio-bestand van deze architectuur downloaden.

In dit geval implementeert één Azure DNS-exemplaar het schakelen tussen verkeer tussen de blauwe en groene clusters. Dit wordt gedaan met behulp van A en CNAME records. Zie sectie T3 voor meer informatie: Verkeer overschakelen naar het groene cluster.

Application Gateway biedt de front-ends, die zijn toegewezen aan de privé-eindpunten.

Workflow

In een blauwgroene implementatie zijn er vijf fasen voor het bijwerken van de huidige versie van het cluster naar de nieuwe versie. In onze beschrijving is het blauwe cluster de huidige versie en het groene cluster is het nieuwe.

De fasen zijn:

T0: Het blauwe cluster is ingeschakeld.
T1: Implementeer het groene cluster.
T2: Synchroniseer de Kubernetes-status tussen de blauwe en groene clusters.
T3: Verkeer overschakelen naar het groene cluster.
T4: Vernietig het blauwe cluster.

Zodra de nieuwe versie live is, wordt deze het blauwe cluster voor elke wijziging of update.

De blauwe en groene clusters worden tegelijkertijd uitgevoerd, maar alleen gedurende een beperkte periode, waarmee de kosten en operationele inspanningen worden geoptimaliseerd.

Overgangstriggers

De triggers voor de overgang van fase naar fase kunnen worden geautomatiseerd. Totdat dat is bereikt, zijn sommige of allemaal handmatig. De triggers zijn gerelateerd aan:

Specifieke metrische gegevens over workloads, serviceniveaudoelstellingen (SLO's) en service level agreements (SLA's): deze worden voornamelijk gebruikt in de T3-fase om de algehele status van het AKS-cluster te valideren voordat u het verkeer overschakelt.
Metrische gegevens van het Azure-platform: deze worden gebruikt om de status en status van de workloads en het AKS-cluster te evalueren. Ze worden gebruikt in alle overgangen.

Netwerkdetectie van de clusters

U kunt netwerkdetectie bieden voor de clusters op de volgende manieren:

Dns-records hebben die naar de clusters verwijzen. Voorbeeld:
- aks-blue.contoso.com verwijst naar het privé- of openbare IP-adres van het blauwe cluster.
- aks-green.contoso.com verwijst naar het privé- of openbare IP-adres van het groene cluster.
Vervolgens kunt u deze hostnamen rechtstreeks of in de configuratie van de back-endpool van de toepassingsgateway gebruiken die zich vóór elk cluster bevindt.
Dns-records hebben die verwijzen naar de toepassingsgateways. Voorbeeld:
- aks-blue.contoso.com verwijst naar het privé- of openbare IP-adres van de toepassingsgateway, die als back-endpool het privé- of openbare IP-adres van het blauwe cluster heeft.
- aks-green.contoso.com verwijst naar het privé- of openbare IP-adres van de toepassingsgateway, dat als back-endpool het privé- of openbare IP-adres van het groene cluster heeft.

T0: Het blauwe cluster is ingeschakeld

De eerste fase, T0, is dat het blauwe cluster live is. In deze fase wordt de nieuwe versie van het cluster voorbereid op implementatie.

De triggervoorwaarde voor de T1-fase is de release van een nieuwe versie van het cluster, het groene cluster.

T1: Het groene cluster implementeren

In deze fase wordt de implementatie van het nieuwe groene cluster gestart. Het blauwe cluster blijft ingeschakeld en het liveverkeer wordt nog steeds naar het cluster gerouteerd.

De trigger om naar de T2-fase te gaan, is de validatie van het groene AKS-cluster op platformniveau. De validatie maakt gebruik van metrische gegevens van Azure Monitor en CLI-opdrachten om de status van de implementatie te controleren. Zie Bewaking van Azure Kubernetes Service (AKS) met AKS-gegevensreferenties bewaken en bewaken voor meer informatie.

De AKS-bewaking kan worden gesplitst in verschillende niveaus, zoals wordt weergegeven in het volgende diagram:

De status van het cluster wordt geëvalueerd op niveau 1 en 2 en op een deel van niveau 3. Voor niveau 1 kunt u de systeemeigen weergave voor meerdere clusters van Monitor gebruiken om de status te valideren, zoals hier wordt weergegeven:

Zorg ervoor dat de Kubernetes-API-server en Kubelet goed werken op niveau 2. U kunt de Kubelet-werkmap in Monitor gebruiken, met name de twee rasters van de werkmap met belangrijke operationele statistieken van de knooppunten:

Het overzicht per knooppuntraster bevat een overzicht van de totale bewerking, totale fouten en geslaagde bewerkingen per percentage en trend voor elk knooppunt.
Het overzicht per bewerkingstyperaster biedt voor elk type bewerking het aantal bewerkingen, fouten en geslaagde bewerkingen per percentage en trend.

Niveau 3 is toegewezen aan de Kubernetes-objecten en -toepassingen die standaard worden geïmplementeerd in AKS, zoals omsagent, kube-proxy enzovoort. Voor deze controle kunt u de inzichtenweergave van Monitor gebruiken om de status van de AKS-implementaties te controleren:

Als alternatief kunt u de toegewezen werkmap gebruiken die is gedocumenteerd in metrische gegevens voor implementatie en HPA met containerinzichten. Hier volgt een voorbeeld:

Nadat de validatie is voltooid, kunt u overstappen naar de T2-fase.

T2: De Kubernetes-status synchroniseren tussen de blauwe en groene clusters

In deze fase worden toepassingen, operators en Kubernetes-resources nog niet geïmplementeerd in het groene cluster, of ten minste niet allemaal van toepassing en geïmplementeerd wanneer het AKS-cluster wordt ingericht. Het uiteindelijke doel van deze fase is dat het groene cluster aan het einde van de synchronisatie compatibel is met het blauwe cluster. Zo ja, dan is het mogelijk om de status van het nieuwe cluster te valideren voordat u verkeer overschakelt naar het groene cluster.

Er zijn verschillende manieren om de Kubernetes-status tussen clusters te synchroniseren:

Opnieuw implementeren via continue integratie en continue levering (CI/CD). Meestal is het voldoende om dezelfde CI/CD-pijplijnen te gebruiken die worden gebruikt voor de normale implementatie van de apps. Algemene hulpprogramma's hiervoor zijn: GitHub Actions, Azure DevOps en Jenkins.
GitOps, met oplossingen die worden gepromoveerd op de CNCF-website (Cloud Native Computing Foundation), zoals Flux en ArgoCD.
Een aangepaste oplossing waarin de Kubernetes-configuraties en -resources in een gegevensarchief worden opgeslagen. Deze oplossingen zijn meestal gebaseerd op Kubernetes-manifestgeneratoren die beginnen met metagegevensdefinities en vervolgens de gegenereerde Kubernetes-manifesten opslaan in een gegevensarchief zoals Azure Cosmos DB. Dit zijn meestal aangepaste oplossingen die zijn gebaseerd op het framework voor toepassingsbeschrijvingen dat wordt gebruikt.

In het volgende diagram ziet u het proces voor het synchroniseren van de Kubernetes-status:

Normaal gesproken is de implementatie van nieuwe versies van toepassingen tijdens de synchronisatie niet toegestaan in het livecluster. Deze periode begint met de synchronisatie en eindigt wanneer de overstap naar het groene cluster is voltooid. De manier om implementaties in Kubernetes uit te schakelen, kan variëren. Twee mogelijke oplossingen zijn:

Schakel de implementatiepijplijnen uit.
Schakel het Kubernetes-serviceaccount uit waarmee implementaties worden uitgevoerd.

Het is mogelijk om het uitschakelen van het serviceaccount te automatiseren met behulp van de OPA (Open Policy Agent). Het is nog niet mogelijk om hiervoor systeemeigen AKS-functies te gebruiken, omdat ze nog in preview zijn.

De synchronisatieperiode kan worden vermeden door geavanceerde mechanismen te gebruiken waarmee de Kubernetes-status in meerdere clusters wordt beheerd.

Wanneer de synchronisatie is voltooid, is validatie van het cluster en de toepassingen vereist. Dit zijn onder andere de nieuwe mogelijkheden:

Een controle van de bewakings- en logboekregistratieplatforms om de status van het cluster te valideren. U kunt overwegen wat u doet in de T1: De groene clusterfase implementeren.
Functionele tests van de toepassing op basis van de hulpprogrammaketen die momenteel in gebruik is.

U wordt aangeraden ook een belastingtestsessie uit te voeren om de prestaties van de groene clustertoepassingen te vergelijken met een prestatiebasislijn. U kunt uw favoriete hulpprogramma of Azure Load Testing gebruiken.

Meestal wordt het groene cluster weergegeven op de toepassingsgateway of externe load balancer met een interne URL die niet zichtbaar is voor externe gebruikers.

Wanneer het nieuwe cluster is gevalideerd, kunt u doorgaan naar de volgende fase om verkeer over te schakelen naar het nieuwe cluster.

T3: Verkeer overschakelen naar het groene cluster

Nadat de synchronisatie is voltooid en het groene cluster is gevalideerd op platform- en toepassingsniveau, is het klaar om te worden gepromoveerd tot het primaire cluster en om het liveverkeer te ontvangen. De switch wordt uitgevoerd op netwerkniveau. Vaak zijn de workloads staatloos. Als de workloads echter stateful zijn, moet er een extra oplossing worden geïmplementeerd om de status en caching tijdens de switch te behouden.

Hier volgt een diagram waarin de doelstatus wordt weergegeven nadat de schakeloptie is toegepast:

De technieken die in dit artikel worden beschreven, implementeren volledige switches: 100% van het verkeer wordt doorgestuurd naar het nieuwe cluster. Dit komt doordat de routering wordt toegepast op DNS-niveau met een A of CNAME recordtoewijzing die wordt bijgewerkt om te verwijzen naar het groene cluster, en er is een toepassingsgateway voor elk cluster.

Hier volgt een voorbeeld van een configuratie voor het overschakelen van privé-eindpunten. De voorgestelde oplossing maakt gebruik van A records om over te schakelen. Vanuit het perspectief van DNS- en IP-toewijzing is de situatie als volgt vóór de switch:

A record aks.priv.contoso.com verwijst naar het privé-IP-adres van de blauwe toepassingsgateway.
A record aks-blue.priv.contoso.com verwijst naar het privé-IP-adres van de blauwe toepassingsgateway.
A record aks-green.priv.contoso.com verwijst naar het privé-IP-adres van de groene toepassingsgateway.

De switch wordt opnieuw geconfigureerd naar het volgende:

A record aks.priv.contoso.com verwijst naar het privé-IP-adres van de groene toepassingsgateway.
A record aks-blue.priv.contoso.com verwijst naar het privé-IP-adres van de blauwe toepassingsgateway.
A record aks-green.priv.contoso.com verwijst naar het privé-IP-adres van de groene toepassingsgateway.

De gebruikers van de clusters zien de switch na de time to live (TTL) en DNS-doorgifte van de records.

Voor openbare eindpunten maakt de aanbevolen benadering gebruik van Azure Front Door en Azure DNS. Dit is de configuratie vóór de switch:

CNAME record official-aks.contoso.com verwijst naar een record van het automatisch gegenereerde Azure Front Door-domein. Zie Zelfstudie: Een aangepast domein toevoegen aan uw Front Door voor meer informatie.
A record aks.contoso.com verwijst naar het openbare IP-adres van de blauwe toepassingsgateway.
De azure Front Door-oorsprongconfiguratie verwijst naar de aks.contoso.com hostnaam. Zie Origins- en origin-groepen in Azure Front Door voor meer informatie over het configureren van de back-endpools.
- A record aks-blue.contoso.com verwijst naar het openbare IP-adres van de blauwe toepassingsgateway.
- A record aks-green.contoso.com verwijst naar het openbare IP-adres van de groene toepassingsgateway.

De switch wordt opnieuw geconfigureerd naar het volgende:

CNAME record official-aks.contoso.com verwijst naar een record van het automatisch gegenereerde Azure Front Door-domein.
A record aks.contoso.com verwijst naar het openbare IP-adres van de groene toepassingsgateway.
De azure Front Door-oorsprongconfiguratie verwijst naar de aks.contoso.com hostnaam.
- A recordpunten aks-blue.contoso.com naar het openbare IP-adres van de blauwe toepassingsgateway.
- A record aks-green.contoso.com verwijst naar het openbare IP-adres van de groene toepassingsgateway.

Alternatieve schakeltechnieken, zoals gedeeltelijke switches voor canary-releases, zijn mogelijk met aanvullende Azure-services, zoals Azure Front Door of Traffic Manager. Zie Blauwgroene implementatie met Azure Front Door voor een implementatie van een blauwgroene verkeersswitch op Azure Front Door-niveau.

Zoals beschreven in het voorbeeld, is deze techniek gebaseerd op de definitie van vier hostnamen:

Officiële openbare hostnaam: de officiële openbare hostnaam die wordt gebruikt door eindgebruikers en consumenten.
Clusterhostnaam: de officiële hostnaam die wordt gebruikt door de consumenten van de workloads die worden gehost in de clusters.
Hostnaam van blauw cluster: de toegewezen hostnaam voor het blauwe cluster.
Hostnaam groen cluster: de toegewezen hostnaam voor het groene cluster.

De hostnaam van het cluster is de hostnaam die is geconfigureerd op toepassingsgatewayniveau om het inkomend verkeer te beheren. De hostnaam maakt ook deel uit van de AKS-configuratie voor inkomend verkeer om Transport Layer Security (TLS) correct te beheren. Deze host wordt alleen gebruikt voor livetransacties en aanvragen.

Als Azure Front Door ook deel uitmaakt van de implementatie, wordt dit niet beïnvloed door de switch, omdat deze alleen de officiële hostnaam van het cluster beheert. Het biedt de juiste abstractie voor de toepassingsgebruikers. Ze worden niet beïnvloed door de switch, omdat de DNS-record CNAME altijd verwijst naar Azure Front Door.

De hostnamen van het blauwe en groene cluster worden voornamelijk gebruikt om de clusters te testen en te valideren. Voor deze doeleinden worden de hostnamen weergegeven op het niveau van de toepassingsgateway met toegewezen eindpunten, en ook op het niveau van de AKS-ingangscontroller om TLS correct te beheren.

In deze fase is validatie gebaseerd op de metrische gegevens voor infrastructuur- en app-bewaking, en op officiële SLO en SLA, indien beschikbaar. Als de validatie slaagt, gaat u over naar de laatste fase om het blauwe cluster te vernietigen.

T4: Het blauwe cluster vernietigen

Het overschakelen van het verkeer brengt ons naar de laatste fase, waarin er nog steeds validatie en bewaking plaatsvindt om ervoor te zorgen dat het groene cluster werkt zoals verwacht met live verkeer. De validatie en bewaking hebben betrekking op zowel platform- als toepassingsniveau.

Nadat deze validatie is voltooid, kan het blauwe cluster worden vernietigd. De vernietiging is een stap die sterk wordt aanbevolen om de kosten te verlagen en goed gebruik te maken van de elasticiteit die Azure biedt, met name AKS.

Dit is de situatie nadat het blauwe cluster is vernietigd:

Onderdelen

Application Gateway is een load balancer voor webverkeer (OSI-laag 7) waarmee u verkeer naar uw webtoepassingen kunt beheren. In deze oplossing wordt het gebruikt als gateway voor HTTP-verkeer voor toegang tot de AKS-clusters.
Azure Kubernetes Service (AKS) is een beheerde Kubernetes-service die u kunt gebruiken voor het implementeren en beheren van toepassingen in containers. Dit toepassingsplatform is het belangrijkste onderdeel van dit patroon.
Azure Container Registry is een beheerde service die wordt gebruikt voor het opslaan en beheren van containerinstallatiekopieën en gerelateerde artefacten. In deze oplossing wordt gebruikt voor het opslaan en distribueren van containerinstallatiekopieën en artefacten, zoals Helm-grafieken, in de AKS-clusters.
Azure Monitor is een bewakingsoplossing voor het verzamelen, analyseren en reageren op bewakingsgegevens uit uw cloud- en on-premises omgevingen. Het biedt de belangrijkste bewakingsfuncties die nodig zijn om de blauwgroene implementatie uit te voeren. Het wordt in deze architectuur gebruikt vanwege de integratie met AKS en de mogelijkheid om logboekregistratie, bewaking en waarschuwingsmogelijkheden te bieden die kunnen worden gebruikt om de faseovergangen te beheren.
Azure Key Vault helpt bij het oplossen van de volgende problemen: Geheimenbeheer, Sleutelbeheer en Certificaatbeheer; het wordt gebruikt voor het opslaan en beheren van de geheimen en certificaten die vereist zijn op platfomr- en toepassingsniveau voor deze oplossing.
Azure Front Door is een wereldwijd load balancer- en toepassingseindpuntbeheersysteem. Deze wordt in deze oplossing gebruikt als het openbare eindpunt voor HTTP-toepassingen die worden gehost op AKS. In deze oplossing heeft het de kritieke verantwoordelijkheid om de verkeersswitch tussen de blauwe en groene toepassingsgateways te beheren.
Azure DNS is een service voor het hosten van DNS-domeinen die naamomzetting verzorgt met behulp van de Microsoft Azure-infrastructuur. Het beheert de hostnamen die worden gebruikt in de oplossing voor de blauwe en groene clusters en speelt een belangrijke rol in de verkeersswitches, met name voor privé-eindpunten.

Alternatieven

Er zijn alternatieve technieken voor het implementeren van de verkeersswitches die meer controle kunnen bieden. Het is bijvoorbeeld mogelijk om een gedeeltelijke switch uit te voeren met behulp van verkeersregels die zijn gebaseerd op een of meer van de volgende:
- Percentage inkomend verkeer
- HTTP-kopteksten
- Cookies
Een ander alternatief dat meer bescherming biedt tegen problemen die worden veroorzaakt door wijzigingen, is door implementaties op basis van ring te hebben. In plaats van alleen blauwe en groene clusters, is het mogelijk om meer clusters te hebben, genaamd ringen. Elke ring is groot genoeg voor het aantal gebruikers dat toegang heeft tot de nieuwe versie van AKS. Wat betreft de blauwgroene implementatie die hier wordt beschreven, kunnen de ringen worden verwijderd om de juiste kostenoptimalisatie en -controle te hebben.
Mogelijke alternatieven voor Application Gateway zijn NGINX en HAProxy.
Een mogelijk alternatief voor Container Registry is Harbor.
In sommige gevallen is het mogelijk om verschillende taakverdeling en DNS-services te gebruiken om de verkeersswitches uit te voeren, in plaats van Azure Front Door en Azure DNS.
Deze oplossing is gebaseerd op de kubernetes-API's van de standaardcontroller voor inkomend verkeer. Als uw oplossing in plaats daarvan baat heeft bij de Gateway-API, gebruikt u Application Gateway voor containers. Het kan helpen bij het beheren van taakverdeling en het afhandelen van inkomend verkeerbeheer tussen Application Gateway en de pods. Application Gateway for Containers bepaalt de instellingen van de toepassingsgateways.

Scenariodetails

De belangrijkste voordelen van de oplossing zijn:

Geminimaliseerde downtime tijdens de implementatie.
Geplande terugdraaistrategie.
Verbeterde controle en bewerkingen tijdens de release en implementatie van AKS-wijzigingen en -upgrades.
Testen op de noodzaak om noodherstelprocedures (DR) uit te voeren.

In deze artikelen worden de belangrijkste principes en fundamentele aspecten van blauwgroene implementatie besproken:

Vanuit het perspectief van automatisering en CI/CD kan de oplossing op meerdere manieren worden geïmplementeerd. We raden u aan:

Bicep of Terraform voor IaC.
Azure Pipelines of GitHub Actions voor CI/CD.

Potentiële gebruikscases

Met blauwgroene implementatie kunt u wijzigingen aanbrengen in clusters zonder dat dit van invloed is op de actieve toepassingen en workloads. Voorbeelden van wijzigingen zijn:

Operationele wijzigingen
Nieuwe AKS-functies activeren
Wijzigingen in gedeelde resources in de clusters
De Kubernetes-versie bijwerken
Kubernetes-resources en -objecten wijzigen, zoals de toegangsgateway, de service-mesh, operators, netwerkbeleid, enzovoort
Terugdraaien naar de vorige versie van een AKS-cluster dat nog steeds wordt geïmplementeerd, zonder dat dit van invloed is op de werkbelastingen die in het cluster worden uitgevoerd

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.

Blauwgroene implementatie kan volledig worden geautomatiseerd, zoals een zero-touch-implementatie. Meestal bevat een eerste implementatie handmatige triggers om de fasen te activeren. Onderweg en met de juiste volwassenheid en bewakingsfuncties is het mogelijk om de triggers te automatiseren. Dit betekent dat er geautomatiseerde tests en specifieke metrische gegevens, SLA en SLO zijn om de triggers te automatiseren.
Het is belangrijk om toegewezen hostnamen te hebben voor de blauwe en groene clusters en om toegewezen eindpuntconfiguraties te hebben op de gateways en load balancers die zich vóór de clusters bevinden. Dit is essentieel voor het verbeteren van de betrouwbaarheid en geldigheid van de implementatie van het nieuwe cluster. Op deze manier vindt de validatie van de implementatie plaats met dezelfde architectuur en configuraties van een standaardproductiecluster.
Overweeg een situatie waarin de AKS-clusters gedeelde resources zijn voor meerdere toepassingen die worden beheerd door verschillende bedrijfseenheden. In dergelijke gevallen is het gebruikelijk dat het AKS-platform zelf wordt beheerd door een toegewezen team dat verantwoordelijk is voor de algehele werking en levenscyclus van de clusters en dat er eindpunten in de clusters zijn voor beheerders- en ops-doeleinden. We raden u aan dat deze eindpunten een toegewezen ingangscontroller in de AKS-clusters hebben voor een juiste scheiding van problemen en voor betrouwbaarheid.
Blauwgroene implementatie is handig voor het implementeren en testen van bedrijfscontinuïteit en oplossingen voor herstel na noodgevallen (BC/DR) voor AKS en gerelateerde workloads. Het biedt met name de fundamentele structuren voor het beheren van meerdere clusters, waaronder gevallen waarin de clusters worden verspreid over meerdere regio's.
Succes met blauwgroene implementatie is afhankelijk van het toepassen van alle aspecten van de implementatie, zoals automatisering, bewaking en validatie, niet alleen op het AKS-platform, maar ook op de workloads en apps die op het platform zijn geïmplementeerd. Als u dit doet, profiteert u optimaal van blauwgroene implementatie.
In de voorgestelde oplossing zijn er twee Application Gateways per scenario openbaar en privé, dus in totaal vier. Deze beslissing is om blauwgroene implementatie toe te passen op Azure-toepassing Gatewayniveau om downtime te voorkomen die wordt veroorzaakt door een onjuiste configuratie van de gateways. Het belangrijkste nadeel van deze beslissing is de kosten, omdat er vier Application Gateway-exemplaren zijn. Ze worden alleen parallel uitgevoerd in de periode waarin er relevante wijzigingen zijn in de Application Gateway-configuraties, zoals WAF-beleid of een schaalconfiguratie. Voor verdere kostenoptimalisatie kunt u kiezen voor één Application Gateway per scenario, wat betekent dat er in totaal twee Application Gateways zijn. Hiervoor moet u de blauw/groene logica verplaatsen naar de toepassingsgateway in plaats van Azure Front Door. In plaats van Dat Azure Front Door imperatief wordt beheerd, is Application Gateway.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

Blauwgroene implementatie heeft een direct en positief effect op de beschikbaarheid van het AKS-platform en de workloads. Het verhoogt met name de beschikbaarheid tijdens de implementatie van wijzigingen in het AKS-platform. Er is weinig downtime als gebruikerssessies goed worden beheerd.
Blauwgroene implementatie biedt dekking voor betrouwbaarheid tijdens de implementatie, omdat er standaard de optie is om terug te keren naar de vorige versie van het AKS-cluster als er iets misgaat in de nieuwe clusterversie.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Blauwgroene implementatie wordt veel gebruikt in Azure vanwege de systeemeigen elasticiteit die door de cloud wordt geboden. Dit maakt het mogelijk om de kosten te optimaliseren op het gebied van bewerkingen en resourceverbruik. De meeste besparingen zijn het gevolg van het verwijderen van het cluster dat niet meer nodig is na het implementeren van een nieuwe versie van het cluster.
Wanneer een nieuwe versie wordt geïmplementeerd, is het gebruikelijk om zowel de blauwe als de groene clusters in hetzelfde subnet te hosten, om dezelfde kostenbasislijn te blijven hebben. Alle netwerkverbindingen en toegang tot de resources en services zijn hetzelfde voor de twee clusters en alle Azure-services en -resources blijven hetzelfde.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

Blauwgroene implementatie, goed geïmplementeerd, biedt automatisering, continue levering en flexibele implementatie.
Een van de belangrijkste aspecten van continue levering is dat het iteratief incrementele wijzigingen aan platform- en workloadwijzigingen levert. Met blauwgroene implementatie van AKS bereikt u continue levering op platformniveau, op een gecontroleerde en veilige manier.
Tolerantie is fundamenteel voor blauwgroene implementatie, omdat het de optie bevat om terug te keren naar het vorige cluster.
Blauwgroene implementatie biedt het juiste automatiseringsniveau om de inspanningen met betrekking tot bedrijfscontinuïteitsstrategie te verminderen.
Het bewaken van het platform en de apps is van cruciaal belang voor een succesvolle implementatie. Voor het platform is het mogelijk om de systeemeigen bewakingsmogelijkheden van Azure te gebruiken. Voor de apps moet bewaking worden ontworpen en geïmplementeerd.

Dit scenario implementeren

Zie AKS Landing Zone Accelerator voor een geïmplementeerd voorbeeld van een blauwgroene implementatie die in deze handleiding wordt beschreven.

Deze referentie-implementatie is gebaseerd op Application Gateway en Application Gateway Ingress Controller (AGIC). Elk cluster heeft een eigen toepassingsgateway en de verkeersswitch wordt uitgevoerd via DNS, met name via CNAME configuratie.

Belangrijk

Voor bedrijfskritieke workloads is het belangrijk om blauw/groene implementaties te combineren, zoals beschreven in deze handleiding met implementatieautomatisering en continue validatie om implementaties zonder downtime te realiseren. Meer informatie en richtlijnen zijn beschikbaar in de bedrijfskritieke ontwerpmethodologie.

Overwegingen voor regio's

U kunt de blauwe en groene clusters implementeren in afzonderlijke regio's of in dezelfde regio. De ontwerp- en operationele principes worden niet beïnvloed door deze keuze. Bepaalde typen aanvullende netwerkconfiguraties kunnen echter worden beïnvloed, zoals:

Een toegewezen virtueel netwerk en subnet voor AKS en de toepassingsgateway.
Verbinding maken met back-upservices zoals Monitor, Container Registry en Key Vault.
Azure Front Door-zichtbaarheid van de toepassingsgateway.

Er zijn vereisten voor implementatie in dezelfde regio:

De virtuele netwerken en subnetten moeten de grootte hebben om twee clusters te hosten.
Het Azure-abonnement moet voldoende capaciteit bieden voor de twee clusters.

Implementatie van de ingangscontroller en externe load balancers

Er zijn verschillende benaderingen voor de implementatie van de ingangscontroller en externe load balancers:

U kunt één ingangscontroller met een toegewezen externe load balancer hebben, zoals de referentie-implementatie van de architectuur die in deze handleiding wordt beschreven. AGIC is een Kubernetes-toepassing waarmee de Load Balancer van Application Gateway L7 kan worden gebruikt om cloudsoftware beschikbaar te maken op internet. In bepaalde scenario's zijn er beheerderseindpunten in de AKS-clusters naast de toepassingseindpunten. De beheereindpunten zijn bedoeld voor het uitvoeren van operationele taken in de toepassingen of voor configuratietaken, zoals het bijwerken van configuratietoewijzingen, geheimen, netwerkbeleid en manifesten.
U kunt één externe load balancer hebben die meerdere ingangscontrollers bedient die zijn geïmplementeerd in hetzelfde cluster of op meerdere clusters. Deze benadering wordt niet behandeld in de referentie-implementatie. In dit scenario raden we u aan afzonderlijke toepassingsgateways te hebben voor openbare eindpunten en voor privé-eindpunten.
De resulterende architectuur die in deze handleiding wordt voorgesteld en wordt weergegeven, is gebaseerd op een standaardcontroller voor inkomend verkeer dat is geïmplementeerd als onderdeel van het AKS-cluster, zoals NGINX en Envoy - gebaseerde controller. In de referentie-implementatie gebruiken we AGIC, wat betekent dat er een directe verbinding is tussen de toepassingsgateway en de AKS-pods, maar dit heeft geen invloed op de algehele blauwgroene architectuur.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Microsoft Morra | SAO Incubation Architect

Andere Inzenders:

Oscar Pla Alvarez | Domeinoplossingsarchitect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Delen via

Blauwgroene implementatie van AKS-clusters