Blågrön distribution av AKS-kluster

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

Den här artikeln innehåller vägledning om hur du implementerar en blågrön distributionsstrategi för att testa en ny version av ett AkS-kluster (Azure Kubernetes Service) medan du fortsätter att köra den aktuella versionen. När den nya versionen har verifierats växlar en routningsändring användartrafik till den. Om du distribuerar på det här sättet ökar tillgängligheten när du gör ändringar, inklusive uppgraderingar, till AKS-kluster. I den här artikeln beskrivs design och implementering av en blågrön distribution av AKS som använder Azure-hanterade tjänster och inbyggda Kubernetes-funktioner.

Arkitektur

I det här avsnittet beskrivs arkitekturer för blågrön distribution av AKS-kluster. Det finns två fall:

Programmen och API:erna är offentliga.
Programmen och API:erna är privata.

Det finns också ett hybridfall, som inte beskrivs här, där det finns en blandning av offentliga och privata program och API:er i klustret.

Följande diagram visar arkitekturen för det offentliga ärendet:

Ladda ned en Visio-fil med den här arkitekturen.

Azure Front Door och Azure DNS tillhandahåller den routningsmekanism som växlar trafik mellan de blå och gröna klustren. Mer information finns i Blågrön distribution med Azure Front Door. Genom att använda Azure Front Door är det möjligt att implementera en fullständig växel eller en mer kontrollerad växel som baseras på vikter. Den här tekniken är den mest tillförlitliga och effektiva i en Azure-miljö. Om du vill använda din egen DNS och lastbalanserare måste du vara säker på att de är konfigurerade för att tillhandahålla en säker och tillförlitlig växel.

Azure Application Gateway tillhandahåller klientdelarna som är dedikerade till de offentliga slutpunkterna.

Det här diagrammet är för det privata ärendet:

Ladda ned en Visio-fil med den här arkitekturen.

I det här fallet implementerar en enda Azure DNS-instans växlingen av trafik mellan de blå och gröna klustren. Detta görs med hjälp A av och CNAME poster. Mer information finns i avsnittet T3: Växla trafik till det gröna klustret.

Application Gateway tillhandahåller klientdelarna, som är dedikerade till de privata slutpunkterna.

Arbetsflöde

I en blågrön distribution finns det fem steg för att uppdatera den aktuella versionen av klustret till den nya versionen. I vår beskrivning är det blå klustret den aktuella versionen och det gröna klustret är det nya.

Stegen är:

T0: Det blå klustret är aktiverat.
T1: Distribuera det gröna klustret.
T2: Synkronisera Kubernetes-tillståndet mellan de blå och gröna klustren.
T3: Växla trafik till det gröna klustret.
T4: Förstör det blå klustret.

När den nya versionen är live blir den det blå klustret för den ändring eller uppdatering som kommer härnäst.

De blå och gröna klustren körs samtidigt, men bara under en begränsad tidsperiod, vilket optimerar kostnader och driftsinsatser.

Övergångsutlösare

Utlösare för övergång från fas till fas kan automatiseras. Tills det har uppnåtts är vissa eller alla manuella. Utlösarna är relaterade till:

Specifika arbetsbelastningsmått, servicenivåmål (SLO) och serviceavtal (SLA): Dessa används främst i T3-fasen för att verifiera AKS-klustrets övergripande tillstånd innan trafiken växlas.
Azure-plattformsmått: Dessa används för att utvärdera status och hälsotillstånd för arbetsbelastningarna och AKS-klustret. De används i alla övergångar.

Klustrens nätverksidentifiering

Du kan tillhandahålla nätverksidentifiering för klustren på följande sätt:

Ha DNS-poster som pekar på klustren. Till exempel:
- aks-blue.contoso.com pekar på det blå klustrets privata eller offentliga IP-adress.
- aks-green.contoso.com pekar på det gröna klustrets privata eller offentliga IP-adress.
Sedan kan du använda dessa värdnamn direkt eller i serverdelspoolens konfiguration av programgatewayen som finns framför varje kluster.
Ha DNS-poster som pekar på programgatewayerna. Till exempel:
- aks-blue.contoso.com pekar på den privata eller offentliga IP-adressen för programgatewayen, som som serverdelspool har den privata eller offentliga IP-adressen för det blå klustret.
- aks-green.contoso.com pekar på den privata eller offentliga IP-adressen för programgatewayen, som som serverdelspool har den privata eller offentliga IP-adressen för det gröna klustret.

T0: Det blå klustret är på

Det inledande steget, T0, är att det blå klustret är live. I det här steget förbereds den nya versionen av klustret för distribution.

Utlösarvillkoret för T1-fasen är lanseringen av en ny version av klustret, det gröna klustret.

T1: Distribuera det gröna klustret

Det här steget påbörjar distributionen av det nya gröna klustret. Det blå klustret är fortfarande aktiverat och den aktiva trafiken dirigeras fortfarande till det.

Utlösaren för att flytta till T2-fasen är valideringen av det gröna AKS-klustret på plattformsnivå. Verifieringen använder Azure Monitor-mått och CLI-kommandon för att kontrollera hälsotillståndet för distributionen. Mer information finns i Övervaka Azure Kubernetes Service (AKS) med aks-datareferens för övervakning och övervakning.

AKS-övervakningen kan delas upp i olika nivåer, enligt följande diagram:

Klustrets hälsa utvärderas på nivå 1 och 2 och på någon nivå 3. För nivå 1 kan du använda den inbyggda vyn för flera kluster från Monitor för att verifiera hälsotillståndet, som du ser här:

På nivå 2 kontrollerar du att Kubernetes API-servern och Kubelet fungerar korrekt. Du kan använda Kubelet-arbetsboken i Monitor, specifikt de två rutnäten i arbetsboken som visar nyckeloperativstatistik för noderna:

Översikten efter nodrutnät sammanfattar total åtgärd, totalt antal fel och lyckade åtgärder per procent och trend för varje nod.
Översikten efter åtgärdstypsrutnät ger för varje typ av åtgärd antalet åtgärder, fel och lyckade åtgärder per procent och trend.

Nivå 3 är dedikerad till Kubernetes-objekt och -program som distribueras som standard i AKS, till exempel omsagent, kube-proxy och så vidare. För den här kontrollen kan du använda Insights-vyn i Monitor för att kontrollera statusen för AKS-distributionerna:

Som ett alternativ kan du använda den dedikerade arbetsbok som finns dokumenterad i Mått för distribution och HPA med containerinsikter. Här är ett exempel:

När valideringen har slutförts kan du övergå till T2-fasen.

T2: Synkronisera Kubernetes-tillståndet mellan de blå och gröna klustren

I det här skedet distribueras inte program, operatorer och Kubernetes-resurser ännu i det gröna klustret, eller åtminstone är inte alla tillämpliga och distribuerade när AKS-klustret etableras. Det slutliga målet med det här steget är att det gröna klustret i slutet av synkroniseringen är bakåtkompatibelt med det blå. I så fall är det möjligt att verifiera statusen för det nya klustret innan du växlar trafik till det gröna klustret.

Det finns olika sätt att synkronisera Kubernetes-tillståndet mellan kluster:

Omdistribuering via kontinuerlig integrering och kontinuerlig leverans (CI/CD). Vanligtvis räcker det att använda samma CI/CD-pipelines som används för den normala distributionen av apparna. Vanliga verktyg för att göra detta är: GitHub Actions, Azure DevOps och Jenkins.
GitOps, med lösningar som marknadsförs på CNCF-webbplatsen (Cloud Native Computing Foundation), till exempel Flux och ArgoCD.
En anpassad lösning som lagrar Kubernetes-konfigurationer och -resurser i ett datalager. Vanligtvis baseras dessa lösningar på Kubernetes-manifestgeneratorer som börjar från metadatadefinitioner och sedan lagrar de genererade Kubernetes-manifesten i ett datalager som Azure Cosmos DB. Det här är vanligtvis anpassade lösningar som baseras på det ramverk för programbeskrivning som används.

Följande diagram visar processen för att synkronisera Kubernetes-tillståndet:

Under synkroniseringen tillåts vanligtvis inte distribution av nya versioner av program i det aktiva klustret. Den här tidsperioden börjar med synkroniseringen och avslutas när växlingen till det gröna klustret slutförs. Hur du inaktiverar distributioner i Kubernetes kan variera. Två möjliga lösningar är:

Inaktivera distributionspipelines.
Inaktivera kubernetes-tjänstkontot som kör distributioner.

Det går att automatisera inaktivering av tjänstkontot med hjälp av OPA (Open Policy Agent). Det är ännu inte möjligt att använda inbyggda AKS-funktioner för detta eftersom de fortfarande är i förhandsversion.

Synkroniseringsperioden kan undvikas med hjälp av avancerade mekanismer som hanterar Kubernetes-tillståndet i flera kluster.

När synkroniseringen är klar krävs verifiering av klustret och programmen. Detta omfattar:

En kontroll av övervaknings- och loggningsplattformarna för att verifiera klustrets hälsotillstånd. Du kan överväga att göra det du gör i T1: Distribuera den gröna klusterfasen .
Funktionell testning av programmet baserat på den verktygskedja som används för närvarande.

Vi rekommenderar att du även kör en belastningstestsession för att jämföra prestanda för de gröna klusterprogrammen med en prestandabaslinje. Du kan använda önskat verktyg eller Azure Load Testing.

Vanligtvis exponeras det gröna klustret på programgatewayen eller den externa lastbalanseraren med en intern URL som inte är synlig för externa användare.

När det nya klustret har verifierats kan du gå vidare till nästa steg för att växla trafik till det nya klustret.

T3: Växla trafik till det gröna klustret

När synkroniseringen är klar och det gröna klustret har verifierats på plattforms- och programnivå är det redo att höjas upp till det primära klustret och börja ta emot den aktiva trafiken. Växeln utförs på nätverksnivå. Ofta är arbetsbelastningarna tillståndslösa. Men om arbetsbelastningarna är tillståndskänsliga måste en ytterligare lösning implementeras för att upprätthålla tillståndet och cachelagringen under växeln.

Här är ett diagram som visar måltillståndet när växeln har tillämpats:

De tekniker som beskrivs i den här artikeln implementerar fullständiga växlar: 100 % av trafiken dirigeras till det nya klustret. Det beror på att routningen tillämpas på DNS-nivå med en posttilldelning eller CNAME posttilldelning A som uppdateras så att den pekar på det gröna klustret, och det finns en programgateway för varje kluster.

Här är ett exempel på konfiguration för att växla privata slutpunkter. Den föreslagna lösningen använder A poster för att göra växeln. Ur ett DNS- och IP-mappningsperspektiv är situationen följande före växeln:

A post aks.priv.contoso.com pekar på den privata IP-adressen för den blå programgatewayen.
A post aks-blue.priv.contoso.com pekar på den privata IP-adressen för den blå programgatewayen.
A post aks-green.priv.contoso.com pekar på den privata IP-adressen för den gröna programgatewayen.

Växeln konfigureras om till följande:

A post aks.priv.contoso.com pekar på den privata IP-adressen för den gröna programgatewayen.
A post aks-blue.priv.contoso.com pekar på den privata IP-adressen för den blå programgatewayen.
A post aks-green.priv.contoso.com pekar på den privata IP-adressen för den gröna programgatewayen.

Användarna av klustren ser växeln efter TTL (Time To Live) och DNS-spridning av posterna.

För offentliga slutpunkter använder den rekommenderade metoden Azure Front Door och Azure DNS. Här är konfigurationen före växeln:

CNAME post official-aks.contoso.com pekar på en post för den automatiskt genererade Azure Front Door-domänen. Mer information finns i Självstudiekurs: Lägga till en anpassad domän i din Front Door.
A post aks.contoso.com pekar på den blå programgatewayens offentliga IP-adress.
Azure Front Door-ursprungskonfigurationen pekar på aks.contoso.com värdnamnet. Mer information om hur du konfigurerar serverdelspoolerna finns i Ursprung och ursprungsgrupper i Azure Front Door.
- A post aks-blue.contoso.com pekar på den blå programgatewayens offentliga IP-adress.
- A post aks-green.contoso.com pekar på den gröna programgatewayens offentliga IP-adress.

Växeln konfigureras om till följande:

CNAME post official-aks.contoso.com pekar på en post för den automatiskt genererade Azure Front Door-domänen.
A post aks.contoso.com pekar på den gröna programgatewayens offentliga IP-adress.
Azure Front Door-ursprungskonfigurationen pekar på aks.contoso.com värdnamnet.
- A post aks-blue.contoso.com pekar på den blå programgatewayens offentliga IP-adress.
- A post aks-green.contoso.com pekar på den gröna programgatewayens offentliga IP-adress.

Alternativa växlingstekniker, till exempel partiella växlar för kanarieversioner, är möjliga med ytterligare Azure-tjänster som Azure Front Door eller Traffic Manager. En implementering av en blågrön trafikväxel på Azure Front Door-nivå finns i Blågrön distribution med Azure Front Door.

Enligt beskrivningen i exemplet baseras den här tekniken utifrån ett nätverksperspektiv på definitionen av fyra värdnamn:

Officiellt offentligt värdnamn: Det officiella offentliga värdnamnet som används av slutanvändare och konsumenter.
Klustervärdnamn: Det officiella värdnamnet som används av användarna av de arbetsbelastningar som finns i klustren.
Värdnamn för blått kluster: Det dedikerade värdnamnet för det blå klustret.
Värdnamn för grönt kluster: Det dedikerade värdnamnet för det gröna klustret.

Klustervärdnamnet är det som konfigureras på programgatewaynivå för att hantera inkommande trafik. Värdnamnet är också en del av AKS-ingresskonfigurationen för att hantera TLS (Transport Layer Security) korrekt. Den här värden används endast för livetransaktioner och begäranden.

Om Azure Front Door också ingår i distributionen påverkas den inte av växeln eftersom den endast hanterar det officiella klustervärdnamnet. Det ger rätt abstraktion för programanvändare. De påverkas inte av växeln eftersom DNS-posten CNAME alltid pekar på Azure Front Door.

De blå och gröna klustervärdnamnen används främst för att testa och verifiera klustren. För detta ändamål exponeras värdnamnen på programgatewaynivå med dedikerade slutpunkter och även på AKS-ingresskontrollantnivå för att hantera TLS korrekt.

I det här skedet baseras valideringen på måtten för infrastruktur- och appövervakning, och på officiellt serviceavtal och serviceavtal när det är tillgängligt. Om valideringen lyckas övergår du till den sista fasen för att förstöra det blå klustret.

T4: Förstör det blå klustret

Om du byter trafik kommer vi till det sista steget, där det fortfarande sker validering och övervakning för att säkerställa att det gröna klustret fungerar som förväntat med livetrafik. Valideringen och övervakningen omfattar både plattforms- och programnivå.

När verifieringen är klar kan det blå klustret förstöras. Förstörelsen är ett steg som rekommenderas starkt för att minska kostnaderna och utnyttja elasticiteten som Azure tillhandahåller, särskilt AKS.

Här är situationen när det blå klustret har förstörts:

Komponenter

Application Gateway är en lastbalanserare för webbtrafik (OSI layer 7) som gör att du kan hantera trafik till dina webbprogram. I den här lösningen används den som gateway för HTTP-trafik för åtkomst till AKS-kluster.
Azure Kubernetes Service (AKS) är en hanterad Kubernetes-tjänst som du kan använda för att distribuera och hantera containerbaserade program. Den här programplattformen är huvudkomponenten i det här mönstret.
Azure Container Registry är en hanterad tjänst som används för att lagra och hantera containeravbildningar och relaterade artefakter. I den här lösningen används för att lagra och distribuera containeravbildningar och artefakter, till exempel Helm-diagram, i AKS-kluster.
Azure Monitor är en övervakningslösning för att samla in, analysera och svara på övervakningsdata från molnmiljöer och lokala miljöer. Den innehåller de grundläggande övervakningsfunktioner som krävs för att köra den blågröna distributionen. Den används i den här arkitekturen på grund av dess integrering med AKS och dess förmåga att tillhandahålla funktioner för loggning, övervakning och aviseringar som kan användas för att hantera fasövergångarna.
Azure Key Vault hjälper dig att lösa följande problem: Hantering av hemligheter, nyckelhantering och certifikathantering. Det används för att lagra och hantera hemligheter och certifikat som krävs på platfomr- och programnivå för den här lösningen.
Azure Front Door är ett globalt lastbalanserare och programslutpunktshanteringssystem. Den används i den här lösningen som offentlig slutpunkt för HTTP-program som finns i AKS. I den här lösningen har den det kritiska ansvaret att hantera trafikväxlingen mellan de blå och gröna programgatewayerna.
Azure DNS är en värdtjänst för DNS-domäner som tillhandahåller namnmatchning med hjälp av Microsoft Azure-infrastruktur. Den hanterar värdnamnen som används i lösningen för de blå och gröna klustren och spelar en viktig roll i trafikväxlarna, särskilt för privata slutpunkter.

Alternativ

Det finns alternativa metoder för att implementera trafikväxlarna som kan ge mer kontroll. Det är till exempel möjligt att göra en partiell växel med hjälp av trafikregler som baseras på ett eller flera av följande:
- Procentandel av inkommande trafik
- HTTP-rubriker
- Kakor
Ett annat alternativ som ger bättre skydd mot problem som orsakas av ändringar är att ha ringbaserade distributioner. I stället för bara blå och gröna kluster är det möjligt att ha fler kluster, som kallas ringar. Varje ring är tillräckligt stor för antalet användare som har åtkomst till den nya versionen av AKS. När det gäller den blågröna distributionen som beskrivs här kan ringarna tas bort för att ha rätt kostnadsoptimering och kontroll.
Möjliga alternativ till Application Gateway är NGINX och HAProxy.
Ett möjligt alternativ till Container Registry är Harbor.
I vissa fall är det möjligt att använda olika belastningsutjämnings- och DNS-tjänster för att utföra trafikväxlarna, i stället för Azure Front Door och Azure DNS.
Den här lösningen baseras på kubernetes-API:er för standard ingresskontrollanter. Om din lösning i stället skulle dra nytta av Gateway-API:et använder du Application Gateway för containrar. Det kan hjälpa dig att hantera belastningsutjämning och hantera inkommande trafikhantering mellan Application Gateway och poddarna. Application Gateway för containrar styr inställningarna för programgatewayerna.

Information om scenario

De största fördelarna med lösningen är:

Minimerad stilleståndstid under distributionen.
Planerad återställningsstrategi.
Förbättrad kontroll och åtgärder under lanseringen och distributionen av AKS-ändringar och uppgraderingar.
Testning för behovet av att köra haveriberedskapsprocedurer (DR).

De viktigaste principerna och de grundläggande aspekterna av blågrön distribution beskrivs i följande artiklar:

När det gäller automatisering och CI/CD kan lösningen implementeras på flera olika sätt. Vi föreslår:

Bicep eller Terraform för IaC.
Azure Pipelines eller GitHub Actions för CI/CD.

Potentiella användningsfall

Blågrön distribution gör det möjligt att göra ändringar i kluster utan att påverka program och arbetsbelastningar som körs. Exempel på ändringar är:

Driftsändringar
Aktivera nya AKS-funktioner
Ändringar av delade resurser i klustren
Uppdatera Kubernetes-versionen
Ändra Kubernetes-resurser och -objekt, till exempel ingressgatewayen, tjänstnätet, operatörer, nätverksprinciper och så vidare
Återställa till den tidigare versionen av ett AKS-kluster som fortfarande har distribuerats, utan att påverka de arbetsbelastningar som körs i klustret

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Blågrön distribution kan automatiseras helt, till exempel en zero-touch-distribution. Vanligtvis har en inledande implementering manuella utlösare för att aktivera stegen. Längs vägen och med rätt mognads- och övervakningsfunktioner är det möjligt att automatisera utlösarna. Det innebär att det finns automatiserad testning och specifika mått, SLA och SLO för att automatisera utlösarna.
Det är viktigt att ha dedikerade värdnamn för de blå och gröna klustren och även att ha dedikerade slutpunktskonfigurationer på gatewayer och lastbalanserare som finns framför klustren. Detta är viktigt för att förbättra tillförlitligheten och giltigheten för distributionen av det nya klustret. På så sätt sker verifieringen av distributionen med samma arkitektur och konfigurationer av ett standardproduktionskluster.
Överväg en situation där AKS-klustren är delade resurser för flera program som hanteras av olika affärsenheter. I sådana fall är det vanligt att SJÄLVA AKS-plattformen hanteras av ett dedikerat team som ansvarar för den övergripande driften och livscykeln för klustren och att det finns slutpunkter i klustren för administratörs- och driftsändamål. Vi föreslår att dessa slutpunkter har en dedikerad ingresskontrollant i AKS-klustren för korrekt uppdelning av problem och för tillförlitlighet.
Blågrön distribution är användbart för att implementera och testa lösningar för affärskontinuitet och haveriberedskap (BC/DR) för AKS och relaterade arbetsbelastningar. I synnerhet tillhandahåller den de grundläggande strukturerna för att hantera flera kluster, inklusive fall där klustren är spridda mellan flera regioner.
Framgång med blågrön distribution bygger på att tillämpa alla aspekter av implementeringen, till exempel automatisering, övervakning och validering, inte bara på AKS-plattformen, utan även på de arbetsbelastningar och appar som distribueras på plattformen. Om du gör det får du största möjliga nytta av blågrön distribution.
I den föreslagna lösningen finns det två Application Gateways per varje scenario offentligt och privat, så totalt fyra. Det här beslutet är att tillämpa blågrön distribution på Azure Application Gateway-nivå för att undvika stilleståndstid som orsakas av felkonfiguration av gatewayerna. Den största nackdelen med det här beslutet är kostnaden, eftersom det finns fyra Application Gateway-instanser. De körs parallellt endast under den tidsperiod då det finns relevanta ändringar i Application Gateway-konfigurationerna, till exempel WAF-principer eller en skalningskonfiguration. För ytterligare kostnadsoptimering kan du välja en enda Application Gateway per varje scenario, vilket innebär totalt två Application Gateway. Detta kräver att du flyttar den blå/gröna logiken till programgatewayen i stället för Azure Front Door. Så i stället för att Azure Front Door är imperativt kontrollerat är Application Gateway det.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Blågrön distribution har en direkt och positiv effekt på tillgängligheten för AKS-plattformen och arbetsbelastningarna. I synnerhet ökar tillgängligheten under distributionen av AKS-plattformsändringar. Det finns lite stilleståndstid om användarsessioner hanteras på ett bra sätt.
Blågrön distribution ger täckning för tillförlitlighet under distributionen eftersom det som standard finns möjlighet att återställa till den tidigare versionen av AKS-klustret om något går fel i den nya klusterversionen.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra driftseffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Blågrön distribution används ofta i Azure på grund av den interna elasticitet som tillhandahålls av molnet. Detta gör det möjligt att optimera kostnaderna när det gäller åtgärder och resursförbrukning. De flesta besparingarna beror på att klustret som inte längre behövs när du har distribuerat en ny version av klustret har distribuerats.
När en ny version distribueras är det vanligt att vara värd för både de blå och gröna klustren i samma undernät för att fortsätta att ha samma kostnadsbaslinje. Alla nätverksanslutningar och åtkomst till resurser och tjänster är desamma för de två klustren, och alla Azure-tjänster och -resurser förblir desamma.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

Blågrön distribution, korrekt implementerad, ger automatisering, kontinuerlig leverans och elastisk distribution.
En av de viktigaste aspekterna av kontinuerlig leverans är att den iterativt levererar ökningar av plattforms- och arbetsbelastningsändringar. Med en blågrön distribution av AKS får du kontinuerlig leverans på plattformsnivå på ett kontrollerat och säkert sätt.
Återhämtning är grundläggande för blågrön distribution, eftersom den innehåller alternativet att återställa till det tidigare klustret.
Blågrön distribution ger rätt automatiseringsnivå för att minska arbetet med strategi för affärskontinuitet.
Övervakning av plattformen och apparna är avgörande för en lyckad implementering. För plattformen är det möjligt att använda de inbyggda Azure-övervakningsfunktionerna. För apparna måste övervakning utformas och implementeras.

Distribuera det här scenariot

Ett implementerat exempel på en blågrön distribution som beskrivs i den här guiden finns i ACCELERATOR för AKS-landningszon.

Den här referensimplementeringen baseras på Application Gateway och Application Gateway Ingress Controller (AGIC). Varje kluster har en egen programgateway och trafikväxeln görs via DNS, särskilt via CNAME konfiguration.

Viktigt!

För verksamhetskritiska arbetsbelastningar är det viktigt att kombinera blå/gröna distributioner enligt beskrivningen i den här guiden med distributionsautomation och kontinuerlig validering för att uppnå noll driftstopp. Mer information och vägledning finns i den verksamhetskritiska designmetoden.

Regionöverväganden

Du kan distribuera de blå och gröna klustren till separata regioner eller till samma region. Design- och driftprinciperna påverkas inte av det här valet. Vissa typer av ytterligare nätverkskonfigurationer kan dock påverkas, till exempel:

Ett dedikerat virtuellt nätverk och undernät för AKS och programgatewayen.
Anslutning till säkerhetskopieringstjänster som Monitor, Container Registry och Key Vault.
Azure Front Door-synlighet för programgatewayen.

Det finns förutsättningar för att distribuera till samma region:

De virtuella nätverken och undernäten måste vara stora för att vara värdar för två kluster.
Azure-prenumerationen måste tillhandahålla tillräcklig kapacitet för de två klustren.

Distribution av ingresskontrollanten och externa lastbalanserare

Det finns olika metoder för distribution av ingresskontrollanten och externa lastbalanserare:

Du kan ha en enda ingresskontrollant med en dedikerad extern lastbalanserare, som referensimplementeringen av arkitekturen som beskrivs i den här guiden. AGIC är ett Kubernetes-program som gör det möjligt att använda Application Gateway L7-lastbalanseraren för att exponera molnprogramvara för Internet. I vissa scenarier finns det administratörsslutpunkter i AKS-klustren utöver programslutpunkterna. Administratörsslutpunkterna är till för att utföra operativa uppgifter i programmen eller för konfigurationsuppgifter som att uppdatera konfigurationskartor, hemligheter, nätverksprinciper och manifest.
Du kan ha en enda extern lastbalanserare som hanterar flera ingresskontrollanter som distribueras i samma kluster eller i flera kluster. Den här metoden beskrivs inte i referensimplementeringen. I det här scenariot rekommenderar vi att du har separata programgatewayer för offentliga slutpunkter och för privata.
Den resulterande arkitekturen som föreslås och visas i den här guiden baseras på en standardkontrollant för ingress som distribueras som en del av AKS-klustret, till exempel NGINX - och Envoy-baserade . I referensimplementeringen använder vi AGIC, vilket innebär att det finns en direkt anslutning mellan programgatewayen och AKS-poddarna, men detta påverkar inte den övergripande blågröna arkitekturen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Vincenzo Morra | SAO-inkubationsarkitekt

Övriga medarbetare:

Oscar Pla Alvarez | Arkitekt för domänlösning

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Dela via

Blågrön distribution av AKS-kluster