Szerkesztés

Megosztás a következőn keresztül:


Az AKS-fürtök kék-zöld üzembe helyezése

Azure Kubernetes Service (AKS)
Azure Application Gateway
Azure Container Registry
Azure Front Door
Azure DNS

Ez a cikk útmutatást nyújt egy kék-zöld üzembehelyezési stratégia implementálásához az Azure Kubernetes Service-fürt (AKS) új verziójának teszteléséhez, miközben továbbra is futtatja az aktuális verziót. Az új verzió ellenőrzése után az útválasztási változás a felhasználói forgalmat arra váltja. Az ilyen módon történő üzembe helyezés növeli a rendelkezésre állást az AKS-fürtök módosításainak , beleértve a frissítéseket is. Ez a cikk az Azure által felügyelt szolgáltatásokat és natív Kubernetes-funkciókat használó AKS kék-zöld üzembe helyezésének tervezését és megvalósítását ismerteti.

Architektúra

Ez a szakasz az AKS-fürtök kék-zöld üzembe helyezésének architektúráit ismerteti. Két eset létezik:

  • Az alkalmazások és API-k nyilvánosak.
  • Az alkalmazások és API-k privát elérésűek.

Van egy hibrid eset is, amelyről itt nem esik szó, amelyben a fürtben a nyilvános és a privát elérésű alkalmazások és API-k vegyesen jelennek meg.

Az alábbi ábrán a nyilvánosan elérhető eset architektúrája látható:

A nyilvános elérésű architektúra ábrája.

Töltse le az architektúra Visio-fájlját.

Az Azure Front Door és az Azure DNS biztosítja a kék és zöld fürtök közötti forgalmat kapcsoló útválasztási mechanizmust. További információ: Kék-zöld üzembe helyezés az Azure Front Door használatával. Az Azure Front Door használatával teljes vagy szabályozottabb, súlyokon alapuló kapcsolót is implementálhat. Ez a technika a legmegbízhatóbb és leghatékonyabb az Azure-környezetben. Ha saját DNS-t és terheléselosztót szeretne használni, győződjön meg arról, hogy biztonságos és megbízható kapcsolóra vannak konfigurálva.

Azure-alkalmazás Átjáró biztosítja a nyilvános végpontok számára dedikált előtérvégpontokat.

Ez a diagram a magánjellegű esethez készült:

A privát elérésű architektúra ábrája.

Töltse le az architektúra Visio-fájlját.

Ebben az esetben egyetlen Azure DNS-példány valósítja meg a forgalom váltását a kék és a zöld fürtök között. Ez a művelet a használatával A és CNAME a rekordokkal történik. További részletekért lásd a T3 szakaszt : Forgalom váltása a zöld fürtre.

Az Application Gateway biztosítja a privát végpontok számára dedikált előtérvégpontokat.

Munkafolyamat

Kék-zöld üzembe helyezés esetén öt fázisban frissítjük a fürt aktuális verzióját az új verzióra. Leírásunk szerint a kék fürt az aktuális verzió, a zöld fürt pedig az új.

A szakaszok a következők:

  1. T0: A kék fürt be van kapcsolva.
  2. T1: A zöld fürt üzembe helyezése.
  3. T2: Szinkronizálja a Kubernetes-állapotot a kék és a zöld fürtök között.
  4. T3: Forgalom váltása a zöld fürtre.
  5. T4: Pusztítsa el a kék fürtöt.

Az új verzió élőben való használata után az lesz a kék fürt, amely a következő módosítás vagy frissítés után következik.

A kék és zöld fürtök egyszerre, de csak korlátozott ideig futnak, ami optimalizálja a költségeket és a működési erőfeszítéseket.

Áttűnési eseményindítók

A fázisról a fázisra való áttérésre szolgáló eseményindítók automatizálhatók. Amíg ez meg nem valósul, néhány vagy mindegyik manuális. Az eseményindítók a következőkhöz kapcsolódnak:

  • Konkrét számítási feladatok metrikái, szolgáltatási szintű célkitűzések (SLA-k) és szolgáltatásiszint-szerződések (SLA-k): Ezeket főként a T3 fázisban használják az AKS-fürt általános állapotának ellenőrzésére a forgalom váltása előtt.
  • Azure-platformmetrikák: Ezek a számítási feladatok és az AKS-fürt állapotának és állapotának kiértékelésére szolgálnak. Minden áttűnésnél használják őket.

A fürtök hálózati felderíthetősége

A fürtök számára a következő módokon biztosíthatja a hálózati felderíthetőséget:

  • Olyan DNS-rekordokat tartalmaz, amelyek a fürtökre mutatnak. Példa:

    • aks-blue.contoso.com a kék fürt privát vagy nyilvános IP-címére mutat.
    • aks-green.contoso.com a zöld fürt privát vagy nyilvános IP-címére mutat.

    Ezután ezeket a gazdagépneveket közvetlenül vagy az egyes fürtök előtt található Application Gateway háttérkészlet-konfigurációjában használhatja.

  • Olyan DNS-rekordokkal rendelkezik, amelyek az application gatewayekre mutatnak. Példa:

    • aks-blue.contoso.com az Application Gateway privát vagy nyilvános IP-címére mutat, amely háttérkészletként tartalmazza a kék fürt privát vagy nyilvános IP-címét.
    • aks-green.contoso.com az Application Gateway privát vagy nyilvános IP-címére mutat, amely háttérkészletként tartalmazza a zöld fürt privát vagy nyilvános IP-címét.

T0: A kék fürt be van kapcsolva

A kezdeti fázis( T0) az, hogy a kék fürt élő. Ez a szakasz előkészíti a fürt új verzióját az üzembe helyezéshez.

A T0 szakasz diagramja: a kék fürt be van kapcsolva.

A T1 fázis eseményindító feltétele a fürt új verziójának, a zöld fürtnek a kiadása.

T1: A zöld fürt üzembe helyezése

Ez a szakasz megkezdi az új zöld fürt üzembe helyezését. A kék fürt továbbra is be van kapcsolva, és az élő forgalom továbbra is hozzá lesz irányítva.

A T1 fázis diagramja: zöld fürt üzembe helyezése.

A T2 fázisba lépés eseményindítója a zöld AKS-fürt platformszintű ellenőrzése. Az ellenőrzés Azure Monitor-metrikákat és CLI-parancsokat használ az üzembe helyezés állapotának ellenőrzéséhez. További információ: Az Azure Kubernetes Service (AKS) monitorozási és monitorozási AKS-adatreferenciával való monitorozása.

Az AKS-monitorozás különböző szintekre osztható, ahogyan az alábbi ábrán látható:

Az AKS monitorozási szintjeinek diagramja.

A fürt állapotát az 1. és a 2. szinten, illetve a 3. szinten értékeli ki a rendszer. Az 1. szint esetében a Monitor natív többfürtes nézetével ellenőrizheti az állapotot, ahogy az itt látható:

Képernyőkép a monitorozási fürtökről.

A 2. szinten győződjön meg arról, hogy a Kubernetes API-kiszolgáló és a Kubelet megfelelően működik. A Kubelet-munkafüzetet használhatja a Monitorban, pontosabban a munkafüzet két rácsát, amelyek a csomópontok fő működési statisztikáit jelenítik meg:

  • A csomópontrácsok áttekintése az összes műveletet, a teljes hibákat és a sikeres műveleteket százalék és trend szerint összegzi az egyes csomópontok esetében.
  • A művelettípus-rácsok áttekintése minden művelettípushoz megadja a műveletek számát, a hibákat és a sikeres műveleteket százalék és trend szerint.

A 3. szint az AKS-ben alapértelmezés szerint üzembe helyezett Kubernetes-objektumokhoz és alkalmazásokhoz van dedikált, például omsagent, kube-proxy stb. Ebben az ellenőrzésben a Monitor Elemzések nézetével ellenőrizheti az AKS-üzemelő példányok állapotát:

Képernyőkép a Monitorozás Elemzések nézetről.

Alternatív megoldásként használhatja a Központi telepítés és HPA metrikákban dokumentált dedikált munkafüzetet a Container Insights használatával. Példa:

Egy dedikált munkafüzet képernyőképe.

Az ellenőrzés sikerességét követően áttérhet a T2 fázisra.

T2: A Kubernetes-állapot szinkronizálása a kék és a zöld fürtök között

Ebben a szakaszban az alkalmazások, operátorok és Kubernetes-erőforrások még nincsenek üzembe helyezve a zöld fürtben, vagy legalábbis nem mindegyik alkalmazható és telepíthető az AKS-fürt kiépítésekor. Ennek a fázisnak a végső célja az, hogy a szinkronizálás végén a zöld fürt visszafelé kompatibilis legyen a kékkel. Ha igen, a zöld fürtre való váltás előtt ellenőrizheti az új fürt állapotát.

A Kubernetes-állapot különböző módokon szinkronizálható a fürtök között:

  • Ismételt üzembe helyezés folyamatos integrációval és folyamatos teljesítéssel (CI/CD). Általában elegendő ugyanazokat a CI-/CD-folyamatokat használni, amelyeket az alkalmazások normál üzembe helyezéséhez használnak. Ehhez gyakori eszközök a következők: GitHub Actions, Azure DevOps és Jenkins.
  • GitOps, a Cloud Native Computing Foundation (CNCF) webhelyén előléptetett megoldásokkal, például Flux és ArgoCD.
  • Testre szabott megoldás, amely a Kubernetes-konfigurációkat és -erőforrásokat egy adattárban tárolja. Ezek a megoldások általában olyan Kubernetes-jegyzékgenerátorokon alapulnak, amelyek metaadat-definíciókból indulnak ki, majd a létrehozott Kubernetes-jegyzékeket egy olyan adattárban tárolják, mint az Azure Cosmos DB. Ezek általában egyéni megoldások, amelyek a használatban lévő alkalmazásleírási keretrendszeren alapulnak.

Az alábbi ábra a Kubernetes-állapot szinkronizálásának folyamatát mutatja be:

A T2 szakasz ábrája: A Kubernetes-állapot szinkronizálása a kék és a zöld fürtök között.

A szinkronizálás során az alkalmazások új verzióinak üzembe helyezése általában nem engedélyezett az élő fürtben. Ez az időszak a szinkronizálással kezdődik, és a zöld fürtre való váltás befejeződésekor fejeződik be. A Kubernetes üzemelő példányainak letiltása eltérő lehet. Két lehetséges megoldás:

  • Tiltsa le az üzembehelyezési folyamatokat.

  • Tiltsa le az üzembe helyezéseket végrehajtó Kubernetes szolgáltatásfiókot.

    A szolgáltatásfiók letiltását automatizálhatja az Open Policy Agent (OPA) használatával. Ehhez még nem lehet Natív AKS-funkciókat használni, mert még előzetes verzióban vannak.

A szinkronizálási időszak elkerülhető olyan speciális mechanizmusokkal, amelyek több fürtön kezelik a Kubernetes-állapotot.

A szinkronizálás befejezése után ellenőrizni kell a fürtöt és az alkalmazásokat. Ide tartoznak az alábbiak:

Javasoljuk, hogy végezzen terheléstesztelési munkamenetet is, amely összehasonlítja a zöld fürtalkalmazások teljesítményét egy teljesítménykonfigurációval. Használhatja az előnyben részesített eszközt vagy az Azure Load Testinget.

A zöld fürt általában olyan belső URL-címmel van elérhetővé téve az Application Gatewayen vagy a külső terheléselosztón, amely nem látható a külső felhasználók számára.

Az új fürt ellenőrzése után továbbléphet a következő szakaszra, hogy a forgalmat az új fürtre váltsa.

T3: Forgalom váltása a zöld fürtre

Miután a szinkronizálás befejeződött, és a zöld fürt érvényesítve van platform- és alkalmazásszinten, készen áll arra, hogy elsődleges fürtként előléptesse, és megkezdje az élő forgalom fogadását. A kapcsoló hálózati szinten történik. A számítási feladatok gyakran állapot nélküliek. Ha azonban a számítási feladatok állapotalapúak, egy további megoldást kell alkalmazni az állapot fenntartásához és a gyorsítótárazáshoz a kapcsoló során.

Íme egy diagram, amely a kapcsoló alkalmazása után a célállapotot mutatja:

A T3 fázis diagramja: zöld fürt forgalmi kapcsolója.

A cikkben ismertetett technikák teljes kapcsolókat implementálnak: a forgalom 100%-a az új fürthöz lesz irányítva. Ennek az az oka, hogy az útválasztás DNS-szinten van alkalmazva egy A vagy CNAME rekordhozzárendeléssel, amely a zöld fürtre mutat, és mindegyik fürthöz tartozik egy application gateway.

Íme egy példa a privát végpontok közötti váltás konfigurációjára. A javasolt megoldás rekordokat használ A a váltáshoz. DNS- és IP-leképezési szempontból a következő helyzet áll fenn a váltás előtt:

  • A rekord aks.priv.contoso.com a kék alkalmazásátjáró privát IP-címére mutat.
  • A rekord aks-blue.priv.contoso.com a kék alkalmazásátjáró privát IP-címére mutat.
  • A rekord aks-green.priv.contoso.com a zöld alkalmazásátjáró privát IP-címére mutat.

A kapcsoló újrakonfigurálja a következőre:

  • A rekord aks.priv.contoso.com a zöld alkalmazásátjáró privát IP-címére mutat.
  • A rekord aks-blue.priv.contoso.com a kék alkalmazásátjáró privát IP-címére mutat.
  • A rekord aks-green.priv.contoso.com a zöld alkalmazásátjáró privát IP-címére mutat.

A fürtök felhasználói az élettartam (TTL) és a rekordok DNS-propagálása után látják a kapcsolót.

Nyilvános végpontok esetén az ajánlott megközelítés az Azure Front Doort és az Azure DNS-t használja. A kapcsoló előtti konfiguráció:

  • CNAME rekord official-aks.contoso.com az automatikusan létrehozott Azure Front Door-tartomány rekordjára mutat. További információkért lásd: Útmutató: Egyéni tartomány hozzáadása a Front Doorhoz
  • A rekord aks.contoso.com a kék application gateway nyilvános IP-címére mutat.
  • Az Azure Front Door forráskonfigurációja a aks.contoso.com gazdagép nevére mutat. A háttérkészletek konfigurálásával kapcsolatos további információkért tekintse meg az Azure Front Door origins és origin csoportjait.
    • A rekord aks-blue.contoso.com a kék application gateway nyilvános IP-címére mutat.
    • A rekord aks-green.contoso.com a zöld alkalmazásátjáró nyilvános IP-címére mutat.

A kapcsoló újrakonfigurálja a következőre:

  • CNAME rekord official-aks.contoso.com az automatikusan létrehozott Azure Front Door-tartomány rekordjára mutat.
  • A rekord aks.contoso.com a zöld alkalmazásátjáró nyilvános IP-címére mutat.
  • Az Azure Front Door forráskonfigurációja a aks.contoso.com gazdagép nevére mutat.
    • A rekord aks-blue.contoso.com a kék application gateway nyilvános IP-címére mutat.
    • A rekord aks-green.contoso.com a zöld alkalmazásátjáró nyilvános IP-címére mutat.

Az alternatív váltási technikák, például a kanári kiadások részleges kapcsolói, további Azure-szolgáltatások, például az Azure Front Door vagy a Traffic Manager használatával is lehetségesek. Az Azure Front Door szintjén kék-zöld forgalmi kapcsoló implementálását lásd : Kék-zöld üzembe helyezés az Azure Front Door használatával.

A példában leírtak szerint ez a módszer hálózatkezelési szempontból négy gazdagépnév definícióján alapul:

  • Hivatalos nyilvános állomásnév: A végfelhasználók és a fogyasztók által használt hivatalos nyilvános gazdagépnév.
  • Fürt gazdagépének neve: A fürtökben üzemeltetett számítási feladatok felhasználói által használt hivatalos gazdagépnév.
  • Kék fürt gazdagépneve: A kék fürt dedikált gazdagépneve.
  • Zöld fürt gazdagépneve: A zöld fürt dedikált gazdagépneve.

A fürt gazdagépének neve az, amely az Application Gateway szintjén konfigurálva van a bejövő forgalom kezelésére. A gazdagép neve is része az AKS bejövő konfigurációjának a Transport Layer Security (TLS) megfelelő kezelése érdekében. Ez a gazdagép csak élő tranzakciókhoz és kérésekhez használható.

Ha az Azure Front Door is része az üzembe helyezésnek, a kapcsoló nem érinti, mert csak a hivatalos fürt gazdagépnevét kezeli. Ez biztosítja a megfelelő absztrakciót az alkalmazás felhasználói számára. A kapcsoló nem érinti őket, mert a DNS-rekord CNAME mindig az Azure Front Doorra mutat.

A kék és zöld fürt gazdagépneveit elsősorban a fürtök tesztelésére és ellenőrzésére használják. E célból a gazdagépnevek az Application Gateway szintjén, dedikált végpontokkal, valamint az AKS bejövőforgalom-vezérlő szintjén jelennek meg a TLS megfelelő kezeléséhez.

Ebben a szakaszban az érvényesítés az infrastruktúra- és alkalmazásmonitorozási metrikákon, valamint a hivatalos SLO-n és SLA-n alapul, ha elérhető. Ha az érvényesítés sikeres, a kék fürt megsemmisítéséhez váltson az utolsó szakaszra.

T4: A kék fürt megsemmisítése

A forgalom sikeres váltása az utolsó szakaszba vezet, amelyben még mindig ellenőrzés és figyelés zajlik annak érdekében, hogy a zöld fürt a várt módon működjön az élő forgalommal. Az ellenőrzés és a monitorozás a platform és az alkalmazás szintjén is kiterjed.

Az ellenőrzés befejezése után a kék fürt megsemmisíthető. A megsemmisítés egy olyan lépés, amelyet erősen ajánlott a költségek csökkentése és az Azure által biztosított rugalmasság, különösen az AKS megfelelő kihasználása érdekében.

A kék fürt elpusztítása után a következő a helyzet:

A T4 szakasz diagramja: a kék fürt megsemmisül.

Összetevők

  • Az Application Gateway egy webes forgalom (OSI 7. réteg) terheléselosztó, amely lehetővé teszi a webalkalmazások felé irányuló forgalom kezelését. Ebben a megoldásban a HTTP-forgalom átjárójaként használják az AKS-fürtök eléréséhez.
  • Az Azure Kubernetes Service (AKS) egy felügyelt Kubernetes-szolgáltatás, amellyel tárolóalapú alkalmazásokat helyezhet üzembe és kezelhet. Ez az alkalmazásplatform a minta fő összetevője.
  • Az Azure Container Registry egy felügyelt szolgáltatás, amellyel tárolólemezképeket és kapcsolódó összetevőket tárolhat és kezelhet. Ebben a megoldásban tárolólemezképek és összetevők, például Helm-diagramok tárolására és terjesztésére szolgál az AKS-fürtökben.
  • Az Azure Monitor monitorozási megoldás a felhőből és a helyszíni környezetekből származó monitorozási adatok gyűjtésére, elemzésére és megválaszolására. Biztosítja a kék zöld üzembe helyezés végrehajtásához szükséges alapvető monitorozási funkciókat. Ebben az architektúrában az AKS-sel való integráció, valamint a fázisáttűnések kezelésére használható naplózási, figyelési és riasztási képességek biztosítása miatt használják.
  • Az Azure Key Vault a következő problémák megoldásában segít: Titkos kulcsok kezelése, kulcskezelés és tanúsítványkezelés; a megoldáshoz szükséges titkos kulcsok és tanúsítványok tárolására és kezelésére szolgál.
  • Az Azure Front Door egy globális terheléselosztó és alkalmazásvégpont-kezelő rendszer. Ebben a megoldásban az AKS-en üzemeltetett HTTP-alkalmazások nyilvános végpontjaként használják. Ebben a megoldásban a kék és a zöld alkalmazásátjárók közötti forgalomváltás kezelése a kritikus feladata.
  • Az Azure DNS a DNS-tartományok üzemeltetési szolgáltatása, amely a Microsoft Azure-infrastruktúra használatával biztosít névfeloldást. Kezeli a kék és zöld fürtök megoldásában használt gazdagépneveket, és fontos szerepet játszik a forgalmi kapcsolókban, különösen a privát végpontok esetében.

Alternatívák

  • Léteznek alternatív módszerek a forgalmi kapcsolók implementálására, amelyek több vezérlést biztosítanak. Részleges váltást például az alábbiak egyikén alapuló forgalmi szabályok használatával lehet végrehajtani:
    • Bejövő forgalom százalékos aránya
    • HTTP-fejlécek
    • Cookie-k
  • Egy másik lehetőség, amely nagyobb védelmet nyújt a változások által okozott problémák ellen, a gyűrűalapú üzembe helyezés. A kék és zöld fürtök helyett több fürtöt is lehet használni, ezeket gyűrűknek nevezzük. Minden gyűrű elég nagy ahhoz, hogy hány felhasználó fér hozzá az AKS új verziójához. Az itt ismertetett kék-zöld üzembe helyezéssel a gyűrűk eltávolíthatók a megfelelő költségoptimalizálás és -vezérlés érdekében.
  • Az Application Gateway lehetséges alternatívái az NGINX és a HAProxy.
  • A Container Registry egyik lehetséges alternatíva a Harbor.
  • Bizonyos körülmények között az Azure Front Door és az Azure DNS helyett különböző terheléselosztási és DNS-szolgáltatások használhatók a forgalmi kapcsolók elvégzéséhez.
  • Ez a megoldás a standard bejövőforgalom-vezérlő Kubernetes API-ján alapul. Ha a megoldás inkább az Átjáró API-t használná, használja az Application Gateway for Containerst. Segít kezelni a terheléselosztást, és kezelni a bejövő forgalom kezelését az Application Gateway és a podok között. A tárolókhoz készült Application Gateway szabályozza az alkalmazásátjárók beállításait.

Forgatókönyv részletei

A megoldás fő előnyei a következők:

  • Minimális állásidő az üzembe helyezés során.
  • Tervezett visszaállítási stratégia.
  • Továbbfejlesztett vezérlés és műveletek az AKS-módosítások és -frissítések kiadása és üzembe helyezése során.
  • Vészhelyreállítási (DR) eljárások végrehajtásának szükségességének tesztelése.

A kék-zöld környezet alapelveit és alapvető szempontjait az alábbi cikkek ismertetik:

Az automatizálás és a CI/CD szempontjából a megoldás többféleképpen implementálható. Javasoljuk a következőt:

Lehetséges használati esetek

A kék-zöld üzembe helyezés lehetővé teszi a fürtök módosítását anélkül, hogy az hatással lenne a futó alkalmazásokra és számítási feladatokra. Néhány példa a változásokra:

  • Működési változások
  • Új AKS-funkciók aktiválása
  • A fürtök megosztott erőforrásainak módosítása
  • A Kubernetes-verzió frissítése
  • A Kubernetes-erőforrások és -objektumok, például a bejövő átjáró, a szolgáltatásháló, az operátorok, a hálózati szabályzatok stb. módosítása
  • Visszalépés egy még üzembe helyezett AKS-fürt előző verziójára anélkül, hogy ez befolyásolná a fürtben futó számítási feladatokat

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

  • A kék-zöld üzembe helyezés teljesen automatizálható, például érintésmentes üzembe helyezés. A kezdeti implementációk általában manuális eseményindítókkal aktiválják a fázisokat. A megfelelő érettségi és monitorozási funkciókkal párhuzamosan automatizálható a triggerek. Ez azt jelenti, hogy az eseményindítók automatizálásához automatizált tesztelés és meghatározott metrikák, SLA és SLO érhető el.
  • Fontos, hogy a kék és zöld fürtök dedikált gazdagépnevekkel rendelkezzenek, valamint dedikált végpontkonfigurációkkal rendelkezzenek a fürtök előtt található átjárókon és terheléselosztókon. Ez elengedhetetlen az új fürt üzembe helyezésének megbízhatóságának és érvényességének javításához. Így az üzembe helyezés ellenőrzése egy szabványos éles fürt ugyanazon architektúrájával és konfigurációjával történik.
  • Fontolja meg azt a helyzetet, amelyben az AKS-fürtök megosztott erőforrások több, különböző üzleti egységek által felügyelt alkalmazáshoz. Ilyen esetekben gyakran előfordul, hogy magát az AKS-platformot egy dedikált csapat kezeli, amely a fürtök általános működéséért és életciklusáért felelős, és hogy a fürtökben vannak végpontok rendszergazdai és műveleti célokra. Javasoljuk, hogy ezek a végpontok rendelkezzenek dedikált bejövőforgalom-vezérlővel az AKS-fürtökben a problémák megfelelő elkülönítése és a megbízhatóság érdekében.
  • A kék-zöld üzembe helyezés az AKS-hez és a kapcsolódó számítási feladatokhoz használható üzletmenet-folytonossági és vészhelyreállítási (BC/DR) megoldások implementálására és tesztelésére használható. Különösen biztosítja a több fürt kezelésére szolgáló alapvető struktúrákat, beleértve azokat az eseteket is, amikor a fürtök több régió között oszlanak el.
  • A kék-zöld üzembe helyezés sikeressége az implementáció minden aspektusára támaszkodik, például az automatizálásra, a monitorozásra és az ellenőrzésre, nemcsak az AKS-platformra, hanem a platformon üzembe helyezett számítási feladatokra és alkalmazásokra is. Ezzel maximálisan kihasználhatja a kék-zöld környezet előnyeit.
  • A javasolt megoldásban minden forgatókönyvben két Application Gateway található nyilvános és privát, tehát összesen négy. Ez a döntés a kék zöld üzembe helyezés alkalmazása az átjáró szintjén Azure-alkalmazás az átjárók helytelen konfigurációja által okozott állásidő elkerülése érdekében. Ennek a döntésnek a fő hátránya a költség, mivel négy Application Gateway-példány létezik. Ezek csak abban az időszakban futnak párhuzamosan, amikor az Application Gateway konfigurációiban lényeges változások történnek, például WAF-szabályzatok vagy skálázási konfigurációk. A további költségoptimalizáláshoz minden forgatókönyvben egyetlen Application Gatewayt választhat, ez összesen két Application Gatewayt jelent. Ehhez a kék/zöld logikát az Application Gatewayre kell áthelyeznie az Azure Front Door helyett. Így az Azure Front Door kényszerítő vezérlése helyett az Application Gateway az.

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: A megbízhatósági pillér áttekintése.

  • A kék-zöld üzembe helyezés közvetlen és pozitív hatással van az AKS-platform és a számítási feladatok rendelkezésre állására. Különösen növeli a rendelkezésre állást az AKS-platform változásainak üzembe helyezése során. Kevés az állásidő, ha a felhasználói munkamenetek kezelése jól történik.
  • A kék-zöld üzembe helyezés biztosítja a megbízhatósági lefedettséget az üzembe helyezés során, mivel alapértelmezés szerint lehetősége van visszatérni az AKS-fürt előző verziójára, ha valami hiba történik az új fürtverzióban.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.

  • A kék-zöld üzembe helyezés széles körben elterjedt az Azure-ban a felhő által biztosított natív rugalmasság miatt. Ez lehetővé teszi a költségek optimalizálását a műveletek és az erőforrás-felhasználás során. A legtöbb megtakarítás a fürt új verziójának sikeres üzembe helyezése után már nem szükséges fürt eltávolításával jár.
  • Új verzió üzembe helyezésekor általában a kék és a zöld fürtöket is ugyanabban az alhálózatban kell üzemeltetni, hogy továbbra is ugyanazzal a költségkonfigurációval rendelkezzenek. Az összes hálózati kapcsolat és az erőforrásokhoz és szolgáltatásokhoz való hozzáférés megegyezik a két fürt esetében, és az összes Azure-szolgáltatás és erőforrás változatlan marad.

Működés eredményessége

Az üzemeltetési kiválóság azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben tartják azt. További információ: A működési kiválósági pillér áttekintése.

  • A kék-zöld üzembe helyezés megfelelően implementálva automatizálást, folyamatos teljesítést és rugalmas üzembe helyezést biztosít.
  • A folyamatos teljesítés egyik fő szempontja, hogy iteratív módon biztosítja a platform- és számítási feladatok változásainak növekményeit. Az AKS kék-zöld üzembe helyezésével folyamatos teljesítést érhet el platformszinten, szabályozott és biztonságos módon.
  • A rugalmasság alapvető fontosságú a kék-zöld környezethez, mivel magában foglalja az előző fürtre való visszaállítás lehetőségét.
  • A kék-zöld üzembe helyezés megfelelő szintű automatizálást biztosít az üzletmenet-folytonossági stratégiával kapcsolatos erőfeszítések csökkentéséhez.
  • A platform és az alkalmazások monitorozása elengedhetetlen a sikeres megvalósításhoz. A platformon a natív Azure-monitorozási képességek használhatók. Az alkalmazások esetében a monitorozást meg kell tervezni és végre kell hajtani.

A forgatókönyv üzembe helyezése

Az útmutatóban ismertetett kék-zöld üzembe helyezés implementálási példáját az AKS célzónagyorsítóban találja.

Ez a referencia-implementáció az Application Gateway és az Application Gateway bejövőforgalom-vezérlőjén (AGIC) alapul. Minden fürtnek saját alkalmazásátjárója van, és a forgalomkapcsoló a DNS-en keresztül történik, különösen a konfiguráción keresztül CNAME .

Fontos

A kritikus fontosságú számítási feladatok esetében fontos, hogy az útmutatóban ismertetett kék/zöld üzembe helyezéseket kombinálja az üzembe helyezés automatizálásával és a folyamatos ellenőrzéssel a nulla állásidő-üzembe helyezés elérése érdekében. További információk és útmutatás érhető el a kritikus fontosságú tervezési módszertanban.

Régióval kapcsolatos szempontok

A kék és zöld fürtöket külön régiókba vagy ugyanabba a régióba helyezheti üzembe. Ez a döntés nem befolyásolja a tervezési és üzemeltetési alapelveket. Bizonyos típusú további hálózati konfigurációk azonban hatással lehetnek, például:

  • Dedikált virtuális hálózat és alhálózat az AKS-hez és az application gatewayhez.
  • Csatlakozás olyan háttérszolgáltatásokkal, mint a Monitor, a Container Registry és a Key Vault.
  • Az Azure Front Door láthatósága az application gatewayen.

Az ugyanabban a régióban történő üzembe helyezésnek vannak előfeltételei:

  • A virtuális hálózatokat és alhálózatokat úgy kell méretezni, hogy két fürtöt üzemeltetjenek.
  • Az Azure-előfizetésnek elegendő kapacitást kell biztosítania a két fürt számára.

A bejövőforgalom-vezérlő és a külső terheléselosztók üzembe helyezése

A bejövőforgalom-vezérlő és a külső terheléselosztók üzembe helyezésének különböző megközelítései vannak:

  • Egyetlen bejövő vezérlővel rendelkezhet dedikált külső terheléselosztóval, például az ebben az útmutatóban ismertetett architektúra referencia-implementációjával. Az AGIC egy Kubernetes-alkalmazás, amely lehetővé teszi az Application Gateway L7 terheléselosztójának használatát a felhőalapú szoftverek internetes elérhetővé tétele érdekében. Bizonyos esetekben az alkalmazásvégpontok mellett rendszergazdai végpontok is vannak az AKS-fürtökben. A felügyeleti végpontok az alkalmazásokon vagy a konfigurációs feladatokon, például a konfigurációs térképek, titkos kódok, hálózati szabályzatok és jegyzékek frissítésére használhatók.
  • Egyetlen külső terheléselosztóval rendelkezhet, amely több bejövő vezérlőt is kiszolgál, amelyek ugyanazon a fürtön vagy több fürtön vannak üzembe helyezve. Ez a megközelítés nem szerepel a referencia-megvalósításban. Ebben a forgatókönyvben azt javasoljuk, hogy külön alkalmazásátjárókkal rendelkezzen a nyilvános és a privát végpontokhoz.
  • Az ebben az útmutatóban javasolt és ábrázolt architektúra egy szabványos bejövőforgalom-vezérlőn alapul, amely az AKS-fürt részeként van üzembe helyezve, például az NGINX - és az Envoy-alapúakon . A referencia-implementációban az AGIC-t használjuk, ami azt jelenti, hogy közvetlen kapcsolat van az application gateway és az AKS podok között, de ez nem befolyásolja az általános kék-zöld architektúrát.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

Egyéb közreműködők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések