Modré a zelené nasazení clusterů AKS

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

Tento článek obsahuje pokyny k implementaci strategie nasazení s modrou zelenou barvou pro testování nové verze clusteru Azure Kubernetes Service (AKS) a zároveň pokračuje ve spouštění aktuální verze. Po ověření nové verze přepne do ní změna směrování uživatelský provoz. Nasazení tímto způsobem zvyšuje dostupnost při provádění změn, včetně upgradů, do clusterů AKS. Tento článek popisuje návrh a implementaci modrého zeleného nasazení AKS, které používá spravované služby Azure a nativní funkce Kubernetes.

Architektura

Tato část popisuje architektury pro modré zelené nasazení clusterů AKS. Existují dva možné případy:

Aplikace a rozhraní API jsou veřejně přístupné.
Aplikace a rozhraní API jsou privátní.

Existuje také hybridní případ, který zde není popsán, v němž existuje kombinace veřejných a privátních aplikací a rozhraní API v clusteru.

Následující diagram znázorňuje architekturu pro veřejný případ:

Stáhněte si soubor aplikace Visio s touto architekturou.

Azure Front Door a Azure DNS poskytují mechanismus směrování, který přepíná provoz mezi modrými a zelenými clustery. Další informace najdete v tématu Blue-green deployment with Azure Front Door. Pomocí služby Azure Front Door je možné implementovat úplný přepínač nebo kontrolovaný přepínač, který je založený na hmotnostech. Tato technika je nejspolehlivější a nejefektivnější v prostředí Azure. Pokud chcete použít vlastní DNS a nástroj pro vyrovnávání zatížení, musíte mít jistotu, že jsou nakonfigurované tak, aby poskytovaly bezpečný a spolehlivý přepínač.

Aplikace Azure lication Gateway poskytuje front-endy, které jsou vyhrazené pro veřejné koncové body.

Tento diagram je určený pro privátní případ:

Stáhněte si soubor aplikace Visio s touto architekturou.

V tomto případě jedna instance Azure DNS implementuje přepínání provozu mezi modrými a zelenými clustery. To se provádí pomocí A a CNAME záznamů. Podrobnosti najdete v části T3: Přepnutí provozu do zeleného clusteru.

Application Gateway poskytuje front-endy, které jsou vyhrazené pro privátní koncové body.

Workflow

V modrém nasazení existuje pět fází aktualizace aktuální verze clusteru na novou verzi. V našem popisu je modrý cluster aktuální verzí a zelený cluster je nový.

Fáze jsou:

T0: Modrý cluster je zapnutý.
T1: Nasaďte zelený cluster.
T2: Synchronizujte stav Kubernetes mezi modrými a zelenými clustery.
T3: Přepněte provoz do zeleného clusteru.
T4: Zničí modrý shluk.

Jakmile bude nová verze aktivní, stane se modrým clusterem pro jakoukoli změnu nebo aktualizaci.

Modré a zelené clustery běží současně, ale pouze po omezenou dobu, která optimalizuje náklady a provozní úsilí.

Aktivační události přechodu

Triggery pro přechod z fáze do fáze je možné automatizovat. Dokud toho nedosáhnete, některé nebo všechny jsou ruční. Triggery souvisejí s:

Konkrétní metriky úloh, cíle na úrovni služeb (SLA) a smlouvy o úrovni služeb (SLA): Tyto metriky se používají hlavně ve fázi T3 k ověření celkového stavu clusteru AKS před přepnutím provozu.
Metriky platformy Azure: Slouží k vyhodnocení stavu a stavu úloh a clusteru AKS. Používají se ve všech přechodech.

Zjistitelnost sítí clusterů

Zjistitelnost sítě pro clustery můžete poskytnout následujícími způsoby:

Mají záznamy DNS, které odkazují na clustery. Příklad:
- aks-blue.contoso.com odkazuje na privátní nebo veřejnou IP adresu modrého clusteru.
- aks-green.contoso.com odkazuje na privátní nebo veřejnou IP adresu zeleného clusteru.
Tyto názvy hostitelů pak můžete použít přímo nebo v konfiguraci back-endového fondu aplikační brány, která je před každým clusterem.
Mají záznamy DNS, které odkazují na aplikační brány. Příklad:
- aks-blue.contoso.com odkazuje na privátní nebo veřejnou IP adresu aplikační brány, která má jako back-endový fond privátní nebo veřejnou IP adresu modrého clusteru.
- aks-green.contoso.com odkazuje na privátní nebo veřejnou IP adresu služby Application Gateway, která má jako back-endový fond privátní nebo veřejnou IP adresu zeleného clusteru.

T0: Modrý cluster je zapnutý.

Počáteční fáze T0 spočívá v živém modrém clusteru. Tato fáze připraví novou verzi clusteru pro nasazení.

Aktivační podmínkou pro fázi T1 je vydání nové verze clusteru, zeleného clusteru.

T1: Nasazení zeleného clusteru

Tato fáze zahájí nasazení nového zeleného clusteru. Modrý cluster zůstane zapnutý a živý provoz se na něj stále směruje.

Triggerem pro přechod do fáze T2 je ověření zeleného clusteru AKS na úrovni platformy. Při ověřování se ke kontrole stavu nasazení používají metriky azure Monitoru a příkazy rozhraní příkazového řádku. Další informace najdete v tématu Monitorování služby Azure Kubernetes Service (AKS) s referenčními informacemi o monitorování a monitorování dat AKS.

Monitorování AKS je možné rozdělit na různé úrovně, jak je znázorněno v následujícím diagramu:

Stav clusteru se vyhodnocuje na úrovních 1 a 2 a na některé úrovni 3. Pro úroveň 1 můžete pomocí nativního zobrazení s více clustery ze služby Monitor ověřit stav, jak je znázorněno tady:

Na úrovni 2 se ujistěte, že server rozhraní API Kubernetes a Kubelet správně fungují. Sešit Kubelet můžete použít v monitoru, konkrétně dvě mřížky sešitu, které zobrazují klíčové provozní statistiky uzlů:

Přehled podle mřížky uzlů shrnuje celkovou operaci, celkové chyby a úspěšné operace podle procenta a trendu pro každý uzel.
Přehled podle mřížky typu operace poskytuje pro každý typ operace, počet operací, chyby a úspěšné operace podle procenta a trendu.

Úroveň 3 je vyhrazená pro objekty a aplikace Kubernetes nasazené ve výchozím nastavení v AKS, jako je omsagent, kube-proxy atd. Pro tuto kontrolu můžete pomocí zobrazení Přehledy monitorování zkontrolovat stav nasazení AKS:

Jako alternativu můžete použít vyhrazený sešit, který je zdokumentovaný v metrikách Nasazení a HPA s využitím Container Insights. Tady je příklad:

Po úspěšném ověření můžete přejít do fáze T2.

T2: Synchronizace stavu Kubernetes mezi modrými a zelenými clustery

V této fázi se aplikace, operátory a prostředky Kubernetes ještě nenasazují do zeleného clusteru nebo se alespoň ne všechny používají a nasazují při zřizování clusteru AKS. Konečným cílem této fáze je, že na konci synchronizace je zelený cluster zpětně kompatibilní s modrou. Pokud ano, je možné před přepnutím provozu na zelený cluster ověřit stav nového clusteru.

Mezi clustery můžete synchronizovat stav Kubernetes různými způsoby:

Opětovné nasazení prostřednictvím kontinuální integrace a průběžného doručování (CI/CD). Obvykle stačí použít stejné kanály CI/CD, které se používají pro normální nasazení aplikací. Mezi běžné nástroje pro tyto účely patří: GitHub Actions, Azure DevOps a Jenkins.
GitOps s řešeními, která se propagují na webu CLOUD Native Computing Foundation (CNCF), jako je Flux a ArgoCD.
Přizpůsobené řešení, které ukládá konfigurace a prostředky Kubernetes do úložiště dat. Tato řešení jsou obvykle založená na generátorech manifestu Kubernetes, které začínají definicemi metadat a následně ukládají vygenerované manifesty Kubernetes do úložiště dat, jako je Azure Cosmos DB. Obvykle se jedná o vlastní řešení založená na používané architektuře popisu aplikace.

Následující diagram znázorňuje proces synchronizace stavu Kubernetes:

Během synchronizace obvykle není nasazení nových verzí aplikací v živém clusteru povolené. Toto časové období začíná synchronizací a skončí po dokončení přechodu na zelený cluster. Způsob zakázání nasazení v Kubernetes se může lišit. Existují dvě možná řešení:

Zakažte kanály nasazení.
Zakažte účet služby Kubernetes, který spouští nasazení.

Zakázání účtu služby je možné automatizovat pomocí agenta OPA (Open Policy Agent). Zatím není možné používat nativní funkce AKS, protože jsou stále ve verzi Preview.

Období synchronizace se dá vyhnout pomocí pokročilých mechanismů, které spravují stav Kubernetes v několika clusterech.

Po dokončení synchronizace se vyžaduje ověření clusteru a aplikací. Sem patří:

Kontrola monitorovacích a protokolovacích platforem za účelem ověření stavu clusteru. Můžete zvážit, co děláte v T1: Nasazení zelené fáze clusteru .
Funkční testování aplikace na základě sady nástrojů, která se aktuálně používá.

Doporučujeme také spustit relaci zátěžového testu, abyste mohli porovnat výkon aplikací zeleného clusteru s standardními hodnotami výkonu. Můžete použít preferovaný nástroj nebo Azure Load Testing.

Zelený cluster je obvykle vystavený ve službě Application Gateway nebo externím nástroji pro vyrovnávání zatížení s interní adresou URL, která není viditelná pro externí uživatele.

Po ověření nového clusteru můžete přejít k další fázi a přepnout provoz do nového clusteru.

T3: Přepnutí provozu do zeleného clusteru

Po dokončení synchronizace a ověření zeleného clusteru na úrovni platformy a aplikací je připravený být povýšen na primární cluster a začít přijímat živý provoz. Přepínač se provádí na úrovni sítě. Úlohy jsou často bezstavové. Pokud jsou však úlohy stavové, je potřeba implementovat další řešení, aby se zachoval stav a ukládání do mezipaměti během přepnutí.

Tady je diagram znázorňující cílový stav po použití přepínače:

Techniky popsané v tomto článku implementují úplné přepínače: 100 % provozu se směruje do nového clusteru. Důvodem je to, že směrování se používá na úrovni DNS s přiřazením záznamu A nebo CNAME přiřazením záznamu, které je aktualizované tak, aby odkazovat na zelený cluster, a pro každý cluster je aplikační brána.

Tady je příklad konfigurace pro přepínání privátních koncových bodů. Navrhované řešení používá A k přepnutí záznamy. Z hlediska mapování DNS a IP adres je situace před přepínačem následující:

A záznam aks.priv.contoso.com odkazuje na privátní IP adresu modré aplikační brány.
A záznam aks-blue.priv.contoso.com odkazuje na privátní IP adresu modré aplikační brány.
A záznam aks-green.priv.contoso.com odkazuje na privátní IP adresu zelené aplikační brány.

Přepínač se překonfiguruje na následující:

A záznam aks.priv.contoso.com odkazuje na privátní IP adresu zelené aplikační brány.
A záznam aks-blue.priv.contoso.com odkazuje na privátní IP adresu modré aplikační brány.
A záznam aks-green.priv.contoso.com odkazuje na privátní IP adresu zelené aplikační brány.

Uživatelům clusterů se po uplynutí doby trvání (TTL) a šíření záznamů DNS zobrazí přepínač.

U veřejných koncových bodů se doporučeným přístupem používá Azure Front Door a Azure DNS. Tady je konfigurace před přepínačem:

CNAME záznam official-aks.contoso.com odkazuje na záznam automaticky vygenerované domény služby Azure Front Door. Další informace najdete v kurzu přidání vlastní domény do Front Dooru.
A záznam aks.contoso.com odkazuje na veřejnou IP adresu modré aplikační brány.
Konfigurace zdroje služby Azure Front Door odkazuje na aks.contoso.com název hostitele. Další informace o konfiguraci back-endových fondů najdete v tématu Zdroje a skupiny původu ve službě Azure Front Door.
- A záznam aks-blue.contoso.com odkazuje na veřejnou IP adresu modré aplikační brány.
- A záznam aks-green.contoso.com odkazuje na veřejnou IP adresu zelené aplikační brány.

Přepínač se překonfiguruje na následující:

CNAME záznam official-aks.contoso.com odkazuje na záznam automaticky vygenerované domény služby Azure Front Door.
A záznam aks.contoso.com odkazuje na veřejnou IP adresu zelené aplikační brány.
Konfigurace zdroje služby Azure Front Door odkazuje na aks.contoso.com název hostitele.
- A záznam aks-blue.contoso.com odkazuje na veřejnou IP adresu modré aplikační brány.
- A záznam aks-green.contoso.com odkazuje na veřejnou IP adresu zelené aplikační brány.

Alternativní techniky přepínání, jako jsou částečné přepínače pro kanárské verze, jsou možné s dalšími službami Azure, jako je Azure Front Door nebo Traffic Manager. Implementace přepínače s modrým zeleným provozem na úrovni služby Azure Front Door najdete v tématu Nasazení blue-green se službou Azure Front Door.

Jak je popsáno v příkladu, z hlediska sítí je tato technika založená na definici čtyř názvů hostitelů:

Oficiální veřejně přístupný název hostitele: Oficiální veřejný název hostitele, který používají koncoví uživatelé a spotřebitelé.
Název hostitele clusteru: Oficiální název hostitele, který používají příjemci úloh hostovaných v clusterech.
Název hostitele modrého clusteru: Vyhrazený název hostitele pro modrý cluster.
Název hostitele zeleného clusteru: Vyhrazený název hostitele pro zelený cluster.

Název hostitele clusteru je ten, který je nakonfigurovaný na úrovni aplikační brány pro správu příchozího přenosu dat. Název hostitele je také součástí konfigurace příchozího přenosu dat AKS, aby bylo možné správně spravovat protokol TLS (Transport Layer Security). Tento hostitel se používá pouze pro živé transakce a požadavky.

Pokud je azure Front Door také součástí nasazení, není to ovlivněno přepínačem, protože spravuje pouze oficiální název hostitele clusteru. Poskytuje správnou abstrakci pro uživatele aplikace. Na tento přepínač to nemá vliv, protože záznam DNS CNAME vždy odkazuje na Azure Front Door.

Názvy hostitelů modrého a zeleného clusteru se používají hlavně k otestování a ověřování clusterů. Pro tyto účely se názvy hostitelů zveřejňují na úrovni aplikační brány s vyhrazenými koncovými body a také na úrovni kontroleru příchozího přenosu dat AKS pro správnou správu protokolu TLS.

V této fázi je ověřování založené na metrikách monitorování infrastruktury a aplikací a na oficiální úrovni úrovně služeb a smlouvy SLA, pokud jsou k dispozici. Pokud ověření proběhne úspěšně, přejděte do konečné fáze, abyste modrý cluster zničili.

T4: Zničení modrého clusteru

Když přenos úspěšně přepnete, přejdeme do poslední fáze, ve které probíhá ověřování a monitorování, aby se zajistilo, že zelený cluster funguje očekávaným způsobem s živým provozem. Ověřování a monitorování pokrývá úroveň platformy i aplikace.

Po dokončení tohoto ověření je možné modrý cluster zničit. Zničení je krok, který důrazně doporučujeme, aby se snížily náklady a využívaly správnou elasticitu, kterou Azure poskytuje, zejména AKS.

Tady je situace po zničení modrého clusteru:

Komponenty

Application Gateway je nástroj pro vyrovnávání zatížení webového provozu (vrstva OSI 7), který umožňuje spravovat provoz do webových aplikací. V tomto řešení se používá jako brána pro provoz HTTP pro přístup ke clusterům AKS.
Azure Kubernetes Service (AKS) je spravovaná služba Kubernetes, kterou můžete použít k nasazení a správě kontejnerizovaných aplikací. Tato aplikační platforma je hlavní součástí tohoto modelu.
Azure Container Registry je spravovaná služba sloužící k ukládání a správě imagí kontejnerů a souvisejících artefaktů. V tomto řešení se používá k ukládání a distribuci imagí kontejnerů a artefaktů, jako jsou grafy Helm, v clusterech AKS.
Azure Monitor je monitorovací řešení pro shromažďování, analýzu a reagování na data monitorování z cloudu a místních prostředí. Poskytuje základní monitorovací funkce potřebné ke spuštění modré zeleného nasazení. Používá se v této architektuře kvůli integraci se službou AKS a její schopnost poskytovat možnosti protokolování, monitorování a upozorňování, které je možné použít ke správě přechodů fází.
Azure Key Vault pomáhá řešit následující problémy: Správa tajných kódů, správa klíčů a správa certifikátů. Slouží k ukládání a správě tajných kódů a certifikátů požadovaných na úrovni platfomru a aplikace pro toto řešení.
Azure Front Door je globální nástroj pro vyrovnávání zatížení a systém správy koncových bodů aplikace. Používá se v tomto řešení jako veřejný koncový bod pro aplikace HTTP hostované v AKS. V tomto řešení má zásadní odpovědnost za správu přepínání provozu mezi modrými a zelenými aplikačními bránami.
Azure DNS je hostitelská služba pro domény DNS, která poskytuje překlad názvů pomocí infrastruktury Microsoft Azure. Spravuje názvy hostitelů, které se používají v řešení pro modré a zelené clustery, a hraje důležitou roli v přepínačích přenosů, zejména pro privátní koncové body.

Alternativy

Existují alternativní techniky pro implementaci přepínačů provozu, které můžou poskytovat větší kontrolu. Pomocí pravidel provozu, která jsou založená na jedné nebo několika následujících pravidlech, je například možné provést částečný přepínač:
- Procento příchozího provozu
- Záhlaví HTTP
- Soubory cookie
Další alternativou, která poskytuje větší ochranu před problémy způsobenými změnami, je mít nasazení založená na okruhu. Místo modrých a zelených shluků je možné mít více shluků označovaných jako kruhy. Každý okruh je dostatečně velký pro počet uživatelů, kteří mají přístup k nové verzi AKS. Co se týče modrého zeleného nasazení, které je zde popsáno, je možné okruhy odebrat, aby měly správnou optimalizaci nákladů a kontrolu.
Možné alternativy ke službě Application Gateway jsou NGINX a HAProxy.
Možnou alternativou ke službě Container Registry je Harbor.
Za určitých okolností je možné k přepnutí provozu použít různé služby vyrovnávání zatížení a DNS, a ne Azure Front Door a Azure DNS.
Toto řešení je založené na rozhraních KUBERNEtes API kontroleru příchozího přenosu dat standardu. Pokud by vaše řešení místo rozhraní API brány využívalo, použijte Službu Application Gateway pro kontejnery. Může pomoct spravovat vyrovnávání zatížení a zpracovávat správu příchozího provozu mezi službou Application Gateway a pody. Application Gateway for Containers řídí nastavení aplikačních bran.

Podrobnosti scénáře

Hlavními výhodami řešení jsou:

Minimalizovaný výpadek během nasazení
Plánovaná strategie vrácení zpět
Vylepšené řízení a operace během vydávání a nasazování změn a upgradů AKS.
Testování nutnosti provádět postupy zotavení po havárii (DR).

Klíčové principy a základní aspekty modrého nasazení jsou popsány v těchto článcích:

Z pohledu automatizace a CI/CD je možné řešení implementovat několika způsoby. Doporučujeme:

Bicep nebo Terraform pro IaC.
Azure Pipelines nebo GitHub Actions pro CI/CD

Potenciální případy použití

Modré a zelené nasazení umožňuje provádět změny v clusterech, aniž by to mělo vliv na spuštěné aplikace a úlohy. Mezi příklady změn patří:

Provozní změny
Aktivace nových funkcí AKS
Změny sdílených prostředků v clusterech
Aktualizace verze Kubernetes
Úprava prostředků a objektů Kubernetes, jako je brána příchozího přenosu dat, síť služeb, operátory, zásady sítě atd.
Vrácení zpět na předchozí verzi clusteru AKS, který je stále nasazený, aniž by to mělo vliv na úlohy spuštěné v clusteru

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Nasazení s modrou zelenou barvou může být plně automatizované, jako je nasazení bez dotykového ovládání. Počáteční implementace má obvykle ruční aktivační události pro aktivaci fází. Společně se správnou vyspělostí a monitorovacími funkcemi je možné triggery automatizovat. To znamená, že pro automatizaci triggerů existuje automatizované testování a konkrétní metriky, smlouva SLA a SLO.
Je důležité mít vyhrazené názvy hostitelů pro modré a zelené clustery a také mít vyhrazené konfigurace koncových bodů na branách a nástrojích pro vyrovnávání zatížení, které jsou před clustery. To je důležité pro zlepšení spolehlivosti a platnosti nasazení nového clusteru. Ověření nasazení se tak provede se stejnou architekturou a konfigurací standardního produkčního clusteru.
Představte si situaci, kdy jsou clustery AKS sdílené prostředky pro více aplikací spravovaných různými obchodními jednotkami. V takových případech je běžné, že samotná platforma AKS je spravovaná vyhrazeným týmem, který zodpovídá za celkovou operaci a životní cyklus clusterů a že v clusterech existují koncové body pro účely správy a provozu. Doporučujeme, aby tyto koncové body měly vyhrazený kontroler příchozího přenosu dat v clusterech AKS pro řádné oddělení obav a spolehlivosti.
Modré a zelené nasazení je užitečné pro implementaci a testování řešení provozní kontinuity a zotavení po havárii (BC/DR) pro AKS a související úlohy. Konkrétně poskytuje základní struktury pro správu více clusterů, včetně případů, ve kterých jsou clustery rozloženy mezi více oblastí.
Úspěch s modrým zeleným nasazením spoléhá na použití všech aspektů implementace, jako je automatizace, monitorování a ověřování, nejen na platformu AKS, ale také na úlohy a aplikace nasazené na platformě. Díky tomu získáte maximální výhodu z modrého zeleného nasazení.
V navrhovaném řešení jsou pro každý scénář veřejné a soukromé dvě služby Application Gateway, takže celkem čtyři. Toto rozhodnutí je použít modré zelené nasazení na úrovni brány Aplikace Azure lication, aby se zabránilo výpadkům způsobeným chybnou konfigurací bran. Hlavní nevýhodou tohoto rozhodnutí jsou náklady, protože existují čtyři instance služby Application Gateway. Běží paralelně pouze v časovém období, ve kterém existují relevantní změny konfigurace služby Application Gateway, jako jsou zásady WAF nebo konfigurace škálování. Pro další optimalizaci nákladů se můžete rozhodnout pro jednu službu Application Gateway pro každý scénář, to znamená, že celkem dvě služby Application Gateway. To bude vyžadovat, abyste místo služby Azure Front Door přesunuli modrou/zelenou logiku do aplikační brány. Takže místo toho, aby služba Azure Front Door byla imperativní kontrolovaná, je application Gateway.

Spolehlivost

Spolehlivost zajišťuje, aby vaše aplikace splňovala závazky, které uděláte pro své zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.

Modré a zelené nasazení má přímý a pozitivní vliv na dostupnost platformy a úloh AKS. Konkrétně se zvyšuje dostupnost během nasazování změn platformy AKS. Pokud se relace uživatelů spravují dobře, dojde k malému výpadku.
Modré-zelené nasazení poskytuje pokrytí spolehlivosti během nasazení, protože ve výchozím nastavení je možnost vrátit se zpět na předchozí verzi clusteru AKS, pokud se v nové verzi clusteru něco nepovede.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

Nasazení s modrou zelenou barvou se v Azure široce přijímá z důvodu nativní elasticity poskytované cloudem. To umožňuje optimalizovat náklady z hlediska provozu a spotřeby prostředků. Většina úspor vede k odebrání clusteru, který už po úspěšném nasazení nové verze clusteru nepotřebujete.
Když je nasazená nová verze, je typické hostovat modré i zelené clustery ve stejné podsíti, aby nadále měly stejný nákladový směrný plán. Všechna síťová připojení a přístup k prostředkům a službám jsou pro oba clustery stejné a všechny služby a prostředky Azure zůstanou stejné.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v tématu Přehled pilíře efektivity provozu.

Modré zelené nasazení, správně implementované, poskytuje automatizaci, průběžné doručování a odolné nasazení.
Jedním z klíčových aspektů průběžného doručování je to, že iterativním způsobem přináší přírůstky změn platformy a úloh. Díky modrému zelenému nasazení AKS dosáhnete průběžného doručování na úrovni platformy řízeným a bezpečným způsobem.
Odolnost je zásadní pro modré zelené nasazení, protože zahrnuje možnost vrátit se zpět do předchozího clusteru.
Modré a zelené nasazení poskytuje správnou úroveň automatizace, která snižuje úsilí související se strategií kontinuity podnikových procesů.
Monitorování platformy a aplikací je zásadní pro úspěšnou implementaci. Pro platformu je možné použít nativní funkce monitorování Azure. U aplikací je potřeba monitorování navrhnout a implementovat.

Nasazení tohoto scénáře

Implementovaný příklad modrého zeleného nasazení popsaného v této příručce najdete v tématu Akcelerátor cílových zón AKS.

Tato referenční implementace je založená na application gateway a kontroleru příchozího přenosu dat služby Application Gateway (AGIC). Každý cluster má svou vlastní aplikační bránu a přepínač provozu se provádí přes DNS, zejména prostřednictvím CNAME konfigurace.

Důležité

U důležitých úloh je důležité zkombinovat nasazení s modrou/zelenou barvou, jak je popsáno v této příručce, s automatizací nasazení a průběžným ověřováním, abyste dosáhli nulového výpadku nasazení. Další informace a pokyny jsou k dispozici v metodologii návrhu kritické pro klíčové úkoly.

Aspekty oblastí

Modré a zelené clustery můžete nasadit do samostatných oblastí nebo do stejné oblasti. Tato volba nemá vliv na návrh a provozní principy. Některé typy dalších konfigurací sítě ale můžou být ovlivněné, například:

Vyhrazená virtuální síť a podsíť pro AKS a aplikační bránu.
Připojení ke službám zálohování, jako je Monitor, Container Registry a Key Vault
Přehled služby Azure Front Door o aplikační bráně

Existují požadavky pro nasazení do stejné oblasti:

Virtuální sítě a podsítě musí mít velikost pro hostování dvou clusterů.
Předplatné Azure musí poskytovat dostatečnou kapacitu pro oba clustery.

Nasazení kontroleru příchozího přenosu dat a externích nástrojů pro vyrovnávání zatížení

Existují různé přístupy k nasazení kontroleru příchozího přenosu dat a externích nástrojů pro vyrovnávání zatížení:

Můžete mít jeden kontroler příchozího přenosu dat s vyhrazeným externím nástrojem pro vyrovnávání zatížení, jako je referenční implementace architektury popsané v této příručce. AGIC je aplikace Kubernetes, která umožňuje používat nástroj pro vyrovnávání zatížení služby Application Gateway L7 k zveřejnění cloudového softwaru na internetu. V určitých scénářích existují kromě koncových bodů aplikace také koncové body správce v clusterech AKS. Koncové body správce slouží k provádění provozních úloh v aplikacích nebo pro úlohy konfigurace, jako jsou aktualizace map konfigurace, tajných kódů, zásad sítě a manifestů.
Můžete mít jeden externí nástroj pro vyrovnávání zatížení, který obsluhuje více kontrolerů příchozího přenosu dat nasazených ve stejném clusteru nebo v několika clusterech. Tento přístup se nevztahuje na referenční implementaci. V tomto scénáři doporučujeme mít samostatné aplikační brány pro veřejné koncové body a privátní brány.
Výsledná architektura navržená a znázorněná v této příručce je založená na standardním kontroleru příchozího přenosu dat, který je nasazený jako součást clusteru AKS, například na základě NGINX a envoy . V referenční implementaci používáme AGIC, což znamená, že mezi aplikační bránou a pody AKS existuje přímé připojení, ale to nemá vliv na celkovou modrou-zelenou architekturu.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Vincenzo Morra | Sao houkavý architekt

Další přispěvatelé:

Oscar Pla Alvarez | Architekt řešení domény

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Sdílet prostřednictvím

Modré a zelené nasazení clusterů AKS