Magas rendelkezésre állású Kubernetes-fürtminta

Ez a cikk azt ismerteti, hogyan építhet ki és üzemeltethet magas rendelkezésre állású Kubernetes-alapú infrastruktúrát Azure Kubernetes Service (AKS) motor használatával az Azure Stack Hubon. Ez a forgatókönyv gyakori a kritikus számítási feladatokkal rendelkező szervezeteknél a szigorúan korlátozott és szabályozott környezetekben. Olyan tartományokban lévő szervezetek, mint a pénzügy, a védelem és a kormányzat.

Kontextus és probléma

Számos szervezet fejleszt natív felhőalapú megoldásokat, amelyek a legkorszerűbb szolgáltatásokat és technológiákat használják, például a Kubernetes-t. Bár az Azure a világ legtöbb régiójában biztosít adatközpontokat, néha vannak peremhálózati használati esetek és forgatókönyvek, amelyekben az üzletileg kritikus fontosságú alkalmazásoknak egy adott helyen kell futniuk. Megfontolandó szempontok:

• Helyérzékenység
• Az alkalmazás és a helyszíni rendszerek közötti késés
• Sávszélesség megőrzése
• Kapcsolatok
• Jogszabályi vagy jogszabályi követelmények

Az Azure az Azure Stack Hubdal együtt kezeli a legtöbb problémát. Az alábbiakban az Azure Stack Hubon futó Kubernetes sikeres implementálásának lehetőségeiről, döntéseiről és megfontolandó szempontjairól olvashat.

Megoldás

Ez a minta feltételezi, hogy szigorú korlátozásokkal kell foglalkoznunk. Az alkalmazásnak a helyszínen kell futnia, és az összes személyes adat nem érheti el a nyilvános felhőszolgáltatásokat. A monitorozási és egyéb nem PII-adatok elküldhetők az Azure-ba, és ott dolgozhatók fel. A külső szolgáltatások, például a nyilvános tárolóregisztrációs adatbázis vagy más szolgáltatások elérhetők, de tűzfalon vagy proxykiszolgálón keresztül szűrhetők.

Az itt látható mintaalkalmazást úgy tervezték, hogy a Kubernetes natív megoldásait használja, amikor csak lehetséges. Ezzel a kialakítással elkerülheti a szállítók zárolását a platformalapú natív szolgáltatások használata helyett. Az alkalmazás például egy saját üzemeltetésű MongoDB-adatbázis háttérrendszerét használja PaaS-szolgáltatás vagy külső adatbázis-szolgáltatás helyett. További információ: A Kubernetes bemutatása az Azure-ban képzési terv.

Az előző ábra a Kubernetesen az Azure Stack Hubon futó mintaalkalmazás alkalmazásarchitektúráját mutatja be. Az alkalmazás több összetevőből áll, többek között a következőkből:

1. Egy AKS Engine-alapú Kubernetes-fürt az Azure Stack Hubon.
2. A tanúsítványkezelő, amely a Kubernetes tanúsítványkezeléséhez szükséges eszközöket biztosít, amellyel automatikusan lekérheti a tanúsítványokat a Let's Encrypt szolgáltatásból.
3. Egy Kubernetes-névtér, amely az előtér (ratings-web), az API (ratings-api) és az adatbázis (ratings-mongodb) alkalmazásösszetevőit tartalmazza.
4. A bejövő forgalomvezérlő, amely a HTTP/HTTPS-forgalmat a Kubernetes-fürt végpontjaihoz irányítja.

A mintaalkalmazás az alkalmazásarchitektúra szemléltetésére szolgál. Minden összetevő példa. Az architektúra csak egyetlen alkalmazástelepítést tartalmaz. A magas rendelkezésre állás (HA) eléréséhez legalább kétszer futtatjuk az üzembe helyezést két különböző Azure Stack Hub-példányon – ezek ugyanazon a helyen vagy két (vagy több) különböző helyen futtathatók:

Az olyan szolgáltatások, mint a Azure Container Registry, az Azure Monitor és más szolgáltatások az Azure Stack Hubon kívül vagy a helyszínen vannak üzemeltetve. Ez a hibrid kialakítás megvédi a megoldást egyetlen Azure Stack Hub-példány kimaradásától.

Összetevők

A teljes architektúra a következő összetevőkből áll:

Az Azure Stack Hub az Azure olyan bővítménye, amely helyszíni környezetben futtathat számítási feladatokat azure-szolgáltatások biztosításával az adatközpontban. További információt az Azure Stack Hub áttekintésében talál.

Azure Kubernetes Service Motor (AKS Engine) a felügyelt Kubernetes szolgáltatásajánlat mögötti motor, Azure Kubernetes Service (AKS), amely jelenleg elérhető az Azure-ban. Az Azure Stack Hub esetében az AKS Engine lehetővé teszi teljes körűen kiemelt, önkiszolgáló Kubernetes-fürtök üzembe helyezését, skálázását és frissítését az Azure Stack Hub IaaS-képességeinek használatával. További információt az AKS-motor áttekintése című témakörben talál.

Az Ismert problémák és korlátozások című témakörben további információt kaphat az Azure-beli AKS-motor és az Azure Stack Hub AKS-motorja közötti különbségekről.

Az Azure Virtual Network (VNet) a Kubernetes-fürtinfrastruktúrát üzemeltető Virtual Machines (VM-ek) hálózati infrastruktúrájának biztosítására szolgál az egyes Azure Stack Hubokon.

Azure Load Balancer a Kubernetes API-végponthoz és az Nginx bejövőforgalom-vezérlőhöz használatos. A terheléselosztó egy adott szolgáltatást kínáló csomópontokra és virtuális gépekre irányítja a külső (például internetes) forgalmat.

Azure Container Registry (ACR) a fürtön üzembe helyezett privát Docker-rendszerképek és Helm-diagramok tárolására szolgál. Az AKS-motor egy Azure AD identitással hitelesítheti a tárolóregisztrációs adatbázist. A Kubernetes nem igényel ACR-t. Használhat más tárolóregisztrációs adatbázisokat is, például Docker Hub.

Az Azure Repos a kód kezeléséhez használható verziókövetési eszközök készlete. Használhatja a GitHubot vagy más Git-alapú adattárakat is. További információt az Azure Repos áttekintésében talál.

Az Azure Pipelines az Azure DevOps Services része, és automatizált buildeket, teszteket és üzembe helyezéseket futtat. Külső CI-/CD-megoldásokat is használhat, például a Jenkinst. További információt az Azure Pipeline áttekintésében talál.

Az Azure Monitor metrikákat és naplókat gyűjt és tárol, beleértve az Azure-szolgáltatások platformmetrikáit a megoldásban és az alkalmazástelemetria esetében. Ezekkel az adatokkal figyelheti az alkalmazást, riasztásokat és irányítópultokat állíthat be, valamint elvégezheti a hibák kiváltó okainak elemzését. Az Azure Monitor integrálható a Kubernetesszel, hogy metrikákat gyűjtsön a vezérlőkből, csomópontokból és tárolókból, valamint tárolónaplókból és fő csomópontnaplókból. További információt az Azure Monitor áttekintésében talál.

Az Azure Traffic Manager egy DNS-alapú forgalom terheléselosztó, amely lehetővé teszi a forgalom optimális elosztását különböző Azure-régiók vagy Azure Stack Hub-üzemelő példányok között. A Traffic Manager magas rendelkezésre állást és válaszképességet is biztosít. Az alkalmazásvégpontoknak kívülről kell elérhetőnek lenniük. További helyszíni megoldások is elérhetők.

A Kubernetes Bejövőforgalom-vezérlő HTTP(S) útvonalakat tesz elérhetővé egy Kubernetes-fürt szolgáltatásai számára. Erre a célra Nginx vagy bármilyen megfelelő bemeneti vezérlő használható.

A Helm a Kubernetes üzembe helyezésének csomagkezelője, amely lehetővé teszi különböző Kubernetes-objektumok, például üzembe helyezések, szolgáltatások és titkos kódok egyetlen "diagramba" való összecsomagolását. Közzéteheti, üzembe helyezheti, vezérelheti a verziókezelést, és frissítheti a diagramobjektumokat. Azure Container Registry a csomagolt Helm-diagramok tárolására használható adattárként.

Kialakítási szempontok

Ez a minta a cikk következő szakaszaiban részletesebben ismertetett néhány magas szintű szempontot követi:

• Az alkalmazás Kubernetes-natív megoldásokat használ a szállítók zárolásának elkerülése érdekében.
• Az alkalmazás mikroszolgáltatás-architektúrát használ.
• Az Azure Stack Hubnak nincs szüksége bejövőre, de engedélyezi a kimenő internetkapcsolatot.

Ezek az ajánlott eljárások a valós számítási feladatokra és forgatókönyvekre is érvényesek lesznek.

Méretezési szempontok

A méretezhetőség fontos ahhoz, hogy a felhasználók egységes, megbízható és jól teljesítő hozzáférést biztosítsanak az alkalmazáshoz.

A mintaforgatókönyv az alkalmazásverem több rétegének méretezhetőségét ismerteti. Íme egy magas szintű áttekintés a különböző rétegekről:

Architektúraszint	Befolyásolja	Hogyan?
Alkalmazás	Alkalmazás	Vízszintes skálázás a podok/replikák/Container Instances* száma alapján
Fürt	Kubernetes-fürt	A csomópontok száma (1 és 50 között), virtuálisgép-termékváltozat-méretek és csomópontkészletek (az Azure Stack Hub AKS-motorja jelenleg csak egyetlen csomópontkészletet támogat); az AKS Engine méretezési parancsának használatával (manuális)
Infrastruktúra	Azure Stack Hub	Csomópontok, kapacitások és skálázási egységek száma az Azure Stack Hub üzemelő példányán belül

* A Kubernetes vízszintes pod automatikus skálázási eszközének (HPA) használata; automatizált metrikaalapú skálázás vagy vertikális skálázás a tárolópéldányok (processzor/memória) méretezésével.

Azure Stack Hub (infrastruktúraszint)

Ennek az implementációnak az alapja az Azure Stack Hub infrastruktúra, mivel az Azure Stack Hub fizikai hardveren fut egy adatközpontban. A hub hardverének kiválasztásakor meg kell adnia a cpu-t, a memóriasűrűséget, a tárolók konfigurációját és a kiszolgálók számát. Az Azure Stack Hub skálázhatóságával kapcsolatos további információkért tekintse meg az alábbi forrásanyagokat:

• Az Azure Stack Hub kapacitástervezésének áttekintése
• További skálázásiegység-csomópontok hozzáadása az Azure Stack Hubban

Kubernetes-fürt (fürtszintű)

Maga a Kubernetes-fürt az Azure (Stack) IaaS-összetevőkre épül, beleértve a számítási, tárolási és hálózati erőforrásokat is. A Kubernetes-megoldások fő- és feldolgozó csomópontokat tartalmaznak, amelyek virtuális gépekként vannak üzembe helyezve az Azure-ban (és az Azure Stack Hubban).

• A vezérlősík csomópontjai (fő) biztosítják az alapvető Kubernetes-szolgáltatásokat és az alkalmazás számítási feladatainak vezénylését.
• A munkavégző csomópontok (feldolgozók) futtatják az alkalmazás számítási feladatait.

A virtuálisgép-méretek kezdeti üzembe helyezéshez való kiválasztásakor több szempontot is figyelembe kell venni:

• Költség – A munkavégző csomópontok tervezésekor vegye figyelembe a virtuális gépekre vonatkozó teljes költséget. Ha például az alkalmazás számítási feladatai korlátozott erőforrásokat igényelnek, tervezze meg kisebb méretű virtuális gépek üzembe helyezését. Az Azure Stack Hubot, például az Azure-t általában használati alapon számlázzák, ezért a kubernetes-szerepkörökhöz tartozó virtuális gépek megfelelő méretezése elengedhetetlen a használati költségek optimalizálásához.

• Méretezhetőség – A fürt méretezhetősége a fő- és feldolgozó csomópontok számának horizontális fel- és leskálázásával, vagy további csomópontkészletek hozzáadásával érhető el (jelenleg nem érhető el az Azure Stack Hubon). A fürt skálázása a Container Insights (Azure Monitor + Log Analytics) használatával gyűjtött teljesítményadatok alapján végezhető el.

  Ha az alkalmazásnak több (vagy kevesebb) erőforrásra van szüksége, horizontálisan felskálázhatja (vagy be) az aktuális csomópontokat (1 és 50 csomópont között). Ha több mint 50 csomópontra van szüksége, létrehozhat egy további fürtöt egy külön előfizetésben. Nem skálázhatja vertikálisan vertikálisan a tényleges virtuális gépeket egy másik virtuálisgép-méretre a fürt ismételt üzembe helyezése nélkül.

  A skálázás manuálisan történik a Kubernetes-fürt kezdeti üzembe helyezéséhez használt AKS Engine segéd virtuális gép használatával. További információ: Kubernetes-fürtök skálázása

• Kvóták – Vegye figyelembe azOkat a kvótákat , amelyeket az AKS üzembe helyezésének megtervezésekor konfigurált az Azure Stack Hubon. Győződjön meg arról, hogy minden előfizetés rendelkezik a megfelelő csomagokkal és a konfigurált kvótával. Az előfizetésnek el kell fogadnia a fürtökhöz szükséges számítási, tárolási és egyéb szolgáltatások mennyiségét a vertikális felskálázás során.

• Alkalmazás számítási feladatai – Tekintse meg a Fürtök és számítási feladatok fogalmait a Kubernetes alapfogalmai Azure Kubernetes Service dokumentumban. Ez a cikk segít a megfelelő virtuálisgép-méret hatókörének meghatározásában az alkalmazás számítási és memóriaigényei alapján.

Alkalmazás (alkalmazásszint)

Az alkalmazásrétegben a Kubernetes Horizontal Pod AutoScaler (HPA) eszközt használjuk. A HPA különböző metrikák (például processzorkihasználtság) alapján növelheti vagy csökkentheti a replikák (pod/Container Instances) számát az üzemelő példányban.

Egy másik lehetőség a tárolópéldányok vertikális skálázása. Ez egy adott üzemelő példányhoz igényelt és elérhető processzor- és memóriamennyiség módosításával valósítható meg. További információt a Tárolók erőforrásainak kezelése kubernetes.io című témakörben talál.

Hálózatkezelési és kapcsolati szempontok

A hálózatkezelés és a kapcsolat az Azure Stack Hubon futó Kubernetes esetében korábban említett három rétegre is hatással van. Az alábbi táblázat a rétegeket és az általuk tartalmazott szolgáltatásokat mutatja be:

Réteg	Befolyásolja	Mi?
Alkalmazás	Alkalmazás	Hogyan érhető el az alkalmazás? Elérhetővé válik az interneten?
Fürt	Kubernetes-fürt	Kubernetes API, AKS-motor virtuális gép, Tárolórendszerképek lekérése (kimenő forgalom), Monitorozási adatok és telemetria küldése (kimenő forgalom)
Infrastruktúra	Azure Stack Hub	Az Azure Stack Hub felügyeleti végpontjainak, például a portálnak és az Azure Resource Manager végpontjainak akadálymentessége.

Alkalmazás

Az alkalmazásréteg esetében a legfontosabb szempont az, hogy az alkalmazás elérhető-e és elérhető-e az internetről. A Kubernetes szempontjából az internet akadálymentessége azt jelenti, hogy egy üzemelő példányt vagy podot kubernetes szolgáltatással vagy bejövőforgalom-vezérlővel kell felfedni.

Ha egy alkalmazást nyilvános IP-cím használatával Load Balancer vagy bejövőforgalom-vezérlőn keresztül ad ki, az nem jelenti azt, hogy az alkalmazás már elérhető az interneten keresztül. Lehetséges, hogy az Azure Stack Hub olyan nyilvános IP-címmel rendelkezik, amely csak a helyi intraneten látható – nem minden nyilvános IP-cím valóban internetkapcsolattal rendelkezik.

Az előző blokk az alkalmazás bejövő forgalmát veszi figyelembe. Egy másik témakör, amelyet figyelembe kell venni a Kubernetes sikeres üzembe helyezéséhez, a kimenő/kimenő forgalom. Íme néhány használati eset, amelyek kimenő forgalmat igényelnek:

• A DockerHubon vagy Azure Container Registry tárolt tárolórendszerképek lekérése
• Helm-diagramok beolvasása
• Application Insights-adatok (vagy egyéb monitorozási adatok) kibocsátása

Egyes vállalati környezetek esetében szükség lehet transzparens vagy nem transzparens proxykiszolgálók használatára. Ezek a kiszolgálók speciális konfigurációt igényelnek a fürt különböző összetevőin. Az AKS Engine dokumentációja különböző részleteket tartalmaz a hálózati proxyk elhelyezéséről. További részletekért lásd: AKS-motor és proxykiszolgálók

Végül a fürtök közötti forgalomnak az Azure Stack Hub-példányok között kell áramlani. A mintatelepítés az egyes Azure Stack Hub-példányokon futó egyéni Kubernetes-fürtökből áll. A közöttük lévő forgalom, például a két adatbázis közötti replikációs forgalom "külső forgalom". A külső forgalmat egy helyek közötti VPN-en vagy az Azure Stack Hub nyilvános IP-címén keresztül kell átirányítani a Kubernetes két Azure Stack Hub-példányhoz való csatlakoztatásához:

Csoport

A Kubernetes-fürtnek nem feltétlenül kell elérhetőnek lennie az interneten keresztül. A megfelelő rész a fürt működtetéséhez használt Kubernetes API, például a használatával kubectl. A Kubernetes API-végpontnak mindenki számára elérhetőnek kell lennie, aki a fürtöt üzemelteti, vagy alkalmazásokat és szolgáltatásokat helyez üzembe rajta. Ez a témakör a DevOps szempontjából részletesebben is foglalkozik az üzembe helyezéssel (CI/CD) kapcsolatos szempontok alábbi szakaszában.

A fürt szintjén a kimenő forgalommal kapcsolatban is figyelembe kell venni néhány szempontot:

• Csomópontfrissítések (Ubuntu esetén)
• Monitorozási adatok (elküldve az Azure LogAnalyticsnak)
• Kimenő forgalmat igénylő egyéb ügynökök (az egyes üzembe helyezők környezetére jellemző)

Mielőtt üzembe helyezené a Kubernetes-fürtöt az AKS Engine használatával, tervezze meg a végső hálózatkezelési tervet. Dedikált Virtual Network létrehozása helyett hatékonyabb lehet fürtöt üzembe helyezni egy meglévő hálózatban. Használhat például egy meglévő helyek közötti VPN-kapcsolatot, amely már konfigurálva van az Azure Stack Hub-környezetben.

Infrastruktúra

Az infrastruktúra az Azure Stack Hub felügyeleti végpontjaihoz való hozzáférésre utal. A végpontok közé tartoznak a bérlői és felügyeleti portálok, valamint az Azure Resource Manager rendszergazdai és bérlői végpontok. Ezek a végpontok szükségesek az Azure Stack Hub és annak alapvető szolgáltatásainak üzemeltetéséhez.

Adat- és tárolási szempontok

Az alkalmazás két példánya lesz üzembe helyezve két különálló Kubernetes-fürtön két Azure Stack Hub-példányon. Ez a kialakítás megköveteli, hogy átgondoljuk, hogyan replikáljuk és szinkronizáljuk az adatokat közöttük.

Az Azure-ral beépített képességünk van arra, hogy több régióban és zónában replikáljuk a tárterületet a felhőben. Az Azure Stack Hub jelenleg nem rendelkezik natív módszerekkel a tárolók két különböző Azure Stack Hub-példányra történő replikálására – két független felhőt alkotnak, amelyek nem rendelkeznek átfogó kezelési móddal. Az Azure Stack Hubon futó alkalmazások rugalmasságának megtervezése arra kényszeríti, hogy figyelembe vegye ezt a függetlenséget az alkalmazástervezésben és az üzemelő példányokban.

A legtöbb esetben a tárolóreplikációra nincs szükség az AKS-en üzembe helyezett rugalmas és magas rendelkezésre állású alkalmazásokhoz. Az alkalmazástervben azonban érdemes megfontolnia az Azure Stack Hub-példányonkénti független tárolást. Ha ez a kialakítás aggodalomra ad okot, vagy útjában áll a megoldás Üzembe helyezése az Azure Stack Hubon, Microsoft partnerektől származó lehetséges megoldások biztosítják a tárolómellékleteket. A tármellékletek több Azure Stack Hubon és Azure-ban is biztosítanak tárreplikációs megoldást. További információ: Partnermegoldások.

Architektúránkban ezeket a rétegeket a következőnek tekintettük:

Konfigurálás

A konfiguráció magában foglalja az Azure Stack Hub, az AKS Engine és maga a Kubernetes-fürt konfigurációját. A konfigurációt a lehető legnagyobb mértékben automatizálni kell, és kódként infrastruktúraként kell tárolni egy Olyan Git-alapú verziókövetési rendszerben, mint az Azure DevOps vagy a GitHub. Ezek a beállítások nem szinkronizálhatók egyszerűen több üzemelő példány között. Ezért azt javasoljuk, hogy kívülről tárolja és alkalmazza a konfigurációt, és használja a DevOps-folyamatot.

Alkalmazás

Az alkalmazást egy Git-alapú adattárban kell tárolni. Amikor új üzembe helyezést, az alkalmazás módosításait vagy vészhelyreállítást hajtanak végre, könnyen üzembe helyezhető az Azure Pipelines használatával.

Adatok

A legtöbb alkalmazástervben az adatok a legfontosabb szempontok. Az alkalmazásadatoknak szinkronban kell maradniuk az alkalmazás különböző példányai között. Az adatoknak biztonsági mentési és vészhelyreállítási stratégiára is szükségük van, ha kimaradás történik.

Ennek a kialakításnak a megvalósítása nagymértékben függ a technológiai döntésektől. Íme néhány megoldási példa egy adatbázis magas rendelkezésre állású módon történő implementálására az Azure Stack Hubon:

• SQL Server 2016-os rendelkezésre állási csoport üzembe helyezése az Azure-ban és az Azure Stack Hubban
• Magas rendelkezésre állású MongoDB-megoldás üzembe helyezése az Azure-ban és az Azure Stack Hubban

A magas rendelkezésre állású és rugalmas megoldások esetében még összetettebb szempont az adatok több helyen történő használata. Megfontolandó szempontok:

• Késés és hálózati kapcsolat az Azure Stack Hubs között.
• A szolgáltatásokhoz és engedélyekhez tartozó identitások rendelkezésre állása. Minden Azure Stack Hub-példány integrálható egy külső címtárral. Az üzembe helyezés során az Azure Active Directory (Azure AD) vagy a Active Directory összevonási szolgáltatások (AD FS) (ADFS) használata mellett dönt. Így lehetséges egyetlen identitás használata, amely több független Azure Stack Hub-példánnyal is kommunikálhat.

Folyamatos üzletmenet és vészhelyreállítás

Az üzletmenet-folytonosság és a vészhelyreállítás (BCDR) fontos témakör mind az Azure Stack Hubban, mind az Azure-ban. A fő különbség az, hogy az Azure Stack Hubban az operátornak a teljes BCDR-folyamatot kell kezelnie. Az Azure-ban a BCDR egyes részeit a Microsoft kezeli automatikusan.

A BCDR ugyanazokat a területeket érinti, mint az előző szakaszban említett adatok és tárolás szempontjai:

• Infrastruktúra/konfiguráció
• Alkalmazás rendelkezésre állása
• Alkalmazásadatok

Ahogy az előző szakaszban is említettük, ezek a területek az Azure Stack Hub-operátor felelősségei, és szervezetektől függően változhatnak. Tervezze meg a BCDR-t az elérhető eszközök és folyamatok szerint.

Infrastruktúra és konfiguráció

Ez a szakasz az Azure Stack Hub fizikai és logikai infrastruktúráját és konfigurációját ismerteti. A rendszergazda és a bérlői helyek műveleteit ismerteti.

Az Azure Stack Hub-példányok karbantartásáért az Azure Stack Hub operátora (vagy rendszergazdája) felelős. Beleértve az olyan összetevőket, mint a hálózat, a tárolás, az identitás és más témakörök, amelyek nem tartoznak a jelen cikk hatálya alá. Az Azure Stack Hub-műveletek jellemzőivel kapcsolatos további információkért tekintse meg az alábbi forrásanyagokat:

• Adatok helyreállítása az Azure Stack Hubban az Infrastruktúra biztonsági mentése szolgáltatással
• Az Azure Stack Hub biztonsági mentésének engedélyezése a felügyeleti portálról
• Helyreállítás végzetes adatvesztés esetén
• Infrastructure Backup Service – ajánlott eljárások

Az Azure Stack Hub az a platform és háló, amelyen a Kubernetes-alkalmazások üzembe lesznek helyezve. A Kubernetes-alkalmazás alkalmazástulajdonosa az Azure Stack Hub felhasználója lesz, és hozzáféréssel rendelkezik a megoldáshoz szükséges alkalmazásinfrastruktúra üzembe helyezéséhez. Ebben az esetben az alkalmazásinfrastruktúra az AKS Engine használatával üzembe helyezett Kubernetes-fürtöt és a környező szolgáltatásokat jelenti. Ezeket az összetevőket egy Azure Stack Hub-ajánlat által korlátozott Azure Stack Hub-ajánlat fogja üzembe helyezni az Azure Stack Hubban. Győződjön meg arról, hogy a Kubernetes-alkalmazás tulajdonosa által elfogadott ajánlat elegendő kapacitással rendelkezik (az Azure Stack Hub kvótáiban kifejezve) a teljes megoldás üzembe helyezéséhez. Ahogy az előző szakaszban is javasolt, az alkalmazás üzembe helyezését kódkénti infrastruktúra és olyan üzembehelyezési folyamatok használatával kell automatizálni, mint az Azure DevOps Azure Pipelines.

Az Azure Stack Hub-ajánlatokkal és -kvótákkal kapcsolatos további információkért lásd: Azure Stack Hub-szolgáltatások, -csomagok, -ajánlatok és -előfizetések áttekintése

Fontos, hogy biztonságosan mentse és tárolja az AKS-motor konfigurációját, beleértve a kimeneteit is. Ezek a fájlok bizalmas információkat tartalmaznak a Kubernetes-fürt eléréséhez, ezért védeni kell őket a nem rendszergazdai hozzáféréssel való hozzáféréstől.

Alkalmazás rendelkezésre állása

Az alkalmazásnak nem szabad az üzembe helyezett példány biztonsági másolataira támaszkodnia. Általános gyakorlatként helyezze üzembe újra az alkalmazást teljesen a kódkénti infrastruktúra mint minták alapján. Például újra üzembe helyezheti az Azure DevOps Azure Pipelines használatával. A BCDR-eljárásnak magában kell foglalnia az alkalmazás ugyanazon vagy egy másik Kubernetes-fürtön való ismételt üzembe helyezését.

Alkalmazásadatok

Az alkalmazásadatok kritikus fontosságúak az adatvesztés minimalizálásához. Az előző szakaszban bemutattuk az alkalmazás két (vagy több) példánya közötti adatreplikálási és -szinkronizálási technikákat. Az adatok tárolásához használt adatbázis-infrastruktúrától (MySQL, MongoDB, MSSQL stb.) függően különböző rendelkezésre állási és biztonsági mentési technikák közül választhat.

Az integritás elérésének ajánlott módjai a következők:

• Egy natív biztonsági mentési megoldás az adott adatbázishoz.
• Olyan biztonsági mentési megoldás, amely hivatalosan támogatja az alkalmazás által használt adatbázistípus biztonsági mentését és helyreállítását.

Fontos

Ne tárolja a biztonsági mentési adatokat ugyanazon az Azure Stack Hub-példányon, ahol az alkalmazásadatok találhatók. Az Azure Stack Hub-példány teljes kimaradása a biztonsági mentéseket is veszélyeztetné.

Rendelkezésre állási szempontok

Az Azure Stack Hubon az AKS Engine-en keresztül üzembe helyezett Kubernetes nem felügyelt szolgáltatás. Ez egy Kubernetes-fürt automatikus üzembe helyezése és konfigurálása az Azure Infrastructure As-a-Service (IaaS) használatával. Így ugyanolyan rendelkezésre állást biztosít, mint a mögöttes infrastruktúra.

Az Azure Stack Hub-infrastruktúra már rugalmas a hibákkal szemben, és olyan képességeket biztosít, mint a rendelkezésre állási csoportok, amelyek több tartalék és frissítési tartomány között osztják el az összetevőket. Az alapul szolgáló technológia (feladatátvételi fürtszolgáltatás) azonban hardverhiba esetén továbbra is leáll egy érintett fizikai kiszolgálón lévő virtuális gépek esetében.

Ajánlott üzembe helyezni az éles Kubernetes-fürtöt és a számítási feladatot két (vagy több) fürtön. Ezeket a fürtöket különböző helyeken vagy adatközpontokban kell üzemeltetni, és az Azure Traffic Managerhez hasonló technológiákkal kell irányítani a felhasználókat a fürt válaszideje vagy földrajzi hely alapján.

Az egyetlen Kubernetes-fürtvel rendelkező ügyfelek általában egy adott alkalmazás szolgáltatás IP-címéhez vagy DNS-nevéhez csatlakoznak. Többfürt-alapú üzemelő példányban az ügyfeleknek olyan Traffic Manager DNS-névhez kell csatlakozniuk, amely az egyes Kubernetes-fürtök szolgáltatásaira/bejövő forgalmára mutat.

Megjegyzés

Ez a minta az Azure-beli (felügyelt) AKS-fürtök esetében is ajánlott eljárás.

Az AKS Engine-en keresztül üzembe helyezett Kubernetes-fürtnek legalább három fő csomópontból és két munkavégző csomópontból kell állnia.

Identitással és biztonsággal kapcsolatos szempontok

Az identitás és a biztonság fontos témakörök. Különösen akkor, ha a megoldás független Azure Stack Hub-példányokra terjed ki. A Kubernetes és az Azure (beleértve az Azure Stack Hubot) is különböző mechanizmusokkal rendelkezik a szerepköralapú hozzáférés-vezérléshez (RBAC):

• Az Azure RBAC szabályozza az Erőforrásokhoz való hozzáférést az Azure-ban (és az Azure Stack Hubban), beleértve az új Azure-erőforrások létrehozásának lehetőségét. Az engedélyek felhasználókhoz, csoportokhoz vagy szolgáltatásnevekhez rendelhetők hozzá. (A szolgáltatásnév az alkalmazások által használt biztonsági identitás.)
• A Kubernetes RBAC szabályozza a Kubernetes API engedélyeit. A podok létrehozása és a podok listázása például olyan műveletek, amelyek engedélyezhetők (vagy megtagadhatók) a felhasználók számára az RBAC-n keresztül. Ha Kubernetes-engedélyeket szeretne hozzárendelni a felhasználókhoz, szerepköröket és szerepkörkötéseket kell létrehoznia.

Azure Stack Hub-identitás és RBAC

Az Azure Stack Hub két identitásszolgáltatói lehetőséget kínál. A használt szolgáltató a környezettől és attól függ, hogy csatlakoztatott vagy leválasztott környezetben fut-e:

• Azure AD – csak csatlakoztatott környezetben használható.
• ADFS hagyományos Active Directory-erdőbe – csatlakoztatott vagy leválasztott környezetben is használható.

Az identitásszolgáltató kezeli a felhasználókat és csoportokat, beleértve az erőforrásokhoz való hozzáférés hitelesítését és engedélyezését. Hozzáférés adható az Azure Stack Hub-erőforrásokhoz, például előfizetésekhez, erőforráscsoportokhoz és egyéni erőforrásokhoz, például virtuális gépekhez vagy terheléselosztókhoz. A konzisztens hozzáférési modell használatához érdemes lehet ugyanazokat a csoportokat használni (akár közvetlen, akár beágyazott) az összes Azure Stack Hubshoz. Íme egy konfigurációs példa:

A példa egy dedikált csoportot (AAD vagy ADFS használatával) tartalmaz egy adott célra. Ha például közreműködői engedélyeket szeretne adni ahhoz az erőforráscsoporthoz, amely a Kubernetes-fürt infrastruktúráját tartalmazza egy adott Azure Stack Hub-példányon (itt "Seattle K8s-fürt közreműködője"). Ezek a csoportok ezután egy átfogó csoportba lesznek beágyazva, amely az egyes Azure Stack Hubokhoz tartozó "alcsoportokat" tartalmazza.

A mintafelhasználó mostantól "Közreműködő" engedéllyel rendelkezik mindkét erőforráscsoporthoz, amely a Kubernetes-infrastruktúra erőforrásainak teljes készletét tartalmazza. A felhasználó mindkét Azure Stack Hub-példány erőforrásaihoz hozzáférhet, mivel a példányok azonos identitásszolgáltatóval rendelkeznek.

Fontos

Ezek az engedélyek csak az Azure Stack Hubot és a rajta üzembe helyezett erőforrások egy részét érintik. Az ilyen szintű hozzáféréssel rendelkező felhasználók sok kárt okozhatnak, de nem tudják elérni a Kubernetes IaaS virtuális gépeket és a Kubernetes API-t anélkül, hogy további hozzáférést adna a Kubernetes-környezethez.

Kubernetes-identitás és RBAC

A Kubernetes-fürtök alapértelmezés szerint nem ugyanazt az identitásszolgáltatót használják, mint az aláfektetett Azure Stack Hub. A Kubernetes-fürtöt, a fő- és munkavégző csomópontokat üzemeltető virtuális gépek a fürt üzembe helyezése során megadott SSH-kulcsot használják. Ez az SSH-kulcs szükséges ahhoz, hogy ezekhez a csomópontokhoz SSH-val csatlakozzon.

A Kubernetes API -t (például a használatával kubectlelért) szolgáltatásfiókok is védik, beleértve az alapértelmezett "fürtadminisztrátori" szolgáltatásfiókot is. A szolgáltatásfiók hitelesítő adatai kezdetben a .kube/config Kubernetes főcsomópontjaiban lévő fájlban vannak tárolva.

Titkos kódok kezelése és az alkalmazások hitelesítő adatai

A titkos kódok, például a kapcsolati sztringek vagy az adatbázis hitelesítő adatainak tárolásához számos lehetőség közül választhat, például:

• Azure Key Vault
• A Kubernetes titkos kódjai
• Külső megoldások, például a HashiCorp Vault (kubernetesen futó)

Ne tároljon titkos kódokat vagy hitelesítő adatokat egyszerű szövegben a konfigurációs fájlokban, alkalmazáskódokban vagy szkriptekben. És ne tárolja őket verziókövetési rendszerben. Ehelyett az üzembe helyezés automatizálásának szükség szerint le kell kérnie a titkos kulcsokat.

Javítás és frissítés

A javítás és frissítés (PNU) folyamata Azure Kubernetes Service részben automatizált. A Kubernetes verziófrissítései manuálisan aktiválódnak, a biztonsági frissítések pedig automatikusan lesznek alkalmazva. Ezek a frissítések tartalmazhatnak operációsrendszer-biztonsági javításokat vagy kernelfrissítéseket. Az AKS nem indítja újra automatikusan ezeket a Linux-csomópontokat a frissítési folyamat befejezéséhez.

Az Azure Stack Hubon az AKS Engine használatával üzembe helyezett Kubernetes-fürtök PNU-folyamata nem felügyelt, és a fürt üzemeltetőjének felelőssége.

Az AKS Engine a két legfontosabb feladat elvégzésében segít:

• Frissítés újabb Kubernetes- és alap operációsrendszer-rendszerkép-verzióra
• Csak az alap operációs rendszer lemezképének frissítése

Az újabb alap operációsrendszer-rendszerképek a legújabb operációsrendszer-biztonsági javításokat és kernelfrissítéseket tartalmazzák.

A felügyelet nélküli frissítési mechanizmus automatikusan telepíti azokat a biztonsági frissítéseket, amelyek még az operációs rendszer új alaprendszerkép-verziójának az Azure Stack Hub Marketplace-en való megjelenése előtt jelennek meg. A felügyelet nélküli frissítés alapértelmezés szerint engedélyezve van, és automatikusan telepíti a biztonsági frissítéseket, de nem indítja újra a Kubernetes-fürtcsomópontokat. A csomópontok újraindítása a nyílt forráskódú KUbernetes REboot Daemon (kured)) használatával automatizálható. Kured figyeli az újraindítást igénylő Linux-csomópontokat, majd automatikusan kezeli a futó podok és csomópontok újraindítási folyamatának átütemezését.

Üzembe helyezéssel (CI/CD) kapcsolatos szempontok

Az Azure és az Azure Stack Hub ugyanazokat az Azure Resource Manager REST API-kat teszi elérhetővé. Ezek az API-k a többi Azure-felhőhez hasonlóan vannak kezelve (Azure, Azure China 21Vianet, Azure Government). Előfordulhat, hogy az API-verziók eltérőek a felhők között, és az Azure Stack Hub csak a szolgáltatások egy részét biztosítja. A felügyeleti végpont URI-ja az egyes felhőkhöz és az Azure Stack Hub minden példányához eltérő.

Az említett apró különbségeken kívül az Azure Resource Manager REST API-k konzisztens módot biztosítanak az Azure és az Azure Stack Hub együttes használatához. Itt ugyanaz az eszközkészlet használható, mint bármely más Azure-felhőben. Az Azure DevOps, például a Jenkins vagy a PowerShell segítségével szolgáltatásokat helyezhet üzembe és vezényelhet az Azure Stack Hubban.

Megfontolások

Az Azure Stack Hub üzemelő példányaival kapcsolatban az egyik fő különbség az internet akadálymentessége. Az internet akadálymentessége határozza meg, hogy egy Microsoft üzemeltetett vagy egy saját üzemeltetésű buildügynököt válasszon a CI/CD-feladatokhoz.

A saját üzemeltetésű ügynökök az Azure Stack Hubon (IaaS virtuális gépként) vagy egy olyan hálózati alhálózaton futhatnak, amely hozzáfér az Azure Stack Hubhoz. A különbségekről további információt az Azure Pipelines-ügynökökben olvashat.

Az alábbi képen eldöntheti, hogy saját üzemeltetésű vagy Microsoft üzemeltetett buildügynökre van-e szüksége:

• Elérhetők az Azure Stack Hub felügyeleti végpontjai az interneten keresztül?
  • Igen: Az Azure Pipelinest Microsoft üzemeltetett ügynökökkel használhatjuk az Azure Stack Hubhoz való csatlakozáshoz.
  • Nem: Olyan saját üzemeltetésű ügynökökre van szükségünk, amelyek képesek csatlakozni az Azure Stack Hub felügyeleti végpontjaihoz.
• Elérhető a Kubernetes-fürt az interneten keresztül?
  • Igen: Az Azure Pipelinest Microsoft üzemeltetett ügynökökkel használva közvetlenül kommunikálhatunk a Kubernetes API-végponttal.
  • Nem: Olyan saját üzemeltetésű ügynökökre van szükségünk, amelyek képesek csatlakozni a Kubernetes-fürt API-végpontjaihoz.

Olyan esetekben, amikor az Azure Stack Hub felügyeleti végpontjai és a Kubernetes API az interneten keresztül érhetők el, az üzembe helyezés egy Microsoft üzemeltetett ügynököt használhat. Ez az üzembe helyezés az alábbi alkalmazásarchitektúrát eredményezi:

Ha az Azure Resource Manager végpontjai, a Kubernetes API vagy mindkettő nem érhető el közvetlenül az interneten keresztül, használhatunk egy saját üzemeltetésű buildügynököt a folyamat lépéseinek futtatásához. Ennek a kialakításnak kevesebb kapcsolatra van szüksége, és csak helyszíni hálózati kapcsolattal telepíthető az Azure Resource Manager végpontjaihoz és a Kubernetes API-hoz:

Megjegyzés

Mi a helyzet a leválasztott forgatókönyvekkel? Olyan esetekben, amikor az Azure Stack Hub vagy a Kubernetes vagy mindkettő nem rendelkezik internetkapcsolattal rendelkező felügyeleti végpontokkal, továbbra is lehetséges az Azure DevOps használata az üzemelő példányokhoz. Használhat saját üzemeltetésű ügynökkészletet (amely egy helyszíni vagy magát az Azure Stack Hubot futtató DevOps-ügynök), vagy egy teljesen saját üzemeltetésű Azure DevOps Server a helyszínen. A helyi ügynöknek csak kimenő HTTPS-kapcsolatra (TCP/443) van szüksége.

A minta egy Kubernetes-fürtöt (üzembe helyezve és az AKS-motorral vezénylve) használhat minden Azure Stack Hub-példányon. Tartalmaz egy előtérből, egy középszintű, háttérszolgáltatásokból (például MongoDB) és egy nginx-alapú bejövőforgalom-vezérlőből álló alkalmazást. A K8s-fürtön üzemeltetett adatbázis helyett használhatja a "külső adattárakat". Az adatbázis-beállítások közé tartozik a MySQL, a SQL Server vagy bármilyen, az Azure Stack Hubon vagy az IaaS-ben üzemeltetett adatbázis. Az ilyen konfigurációk nem tartoznak a hatókörbe.

Partneri megoldások

Vannak Microsoft partnermegoldások, amelyek kiterjeszthetik az Azure Stack Hub képességeit. Ezek a megoldások hasznosnak bizonyultak a Kubernetes-fürtökön futó alkalmazások üzembe helyezésében.

Tárolási és adatmegoldások

Az Adat- és tárolási szempontok című szakaszban leírtak szerint az Azure Stack Hub jelenleg nem rendelkezik natív megoldással a tároló több példányra történő replikálására. Az Azure-sal ellentétben a tárterület több régióban való replikálásának képessége nem létezik. Az Azure Stack Hubban minden példány saját különálló felhő. A megoldások azonban Microsoft partnerektől érhetők el, amelyek lehetővé teszik a tárolóreplikálást az Azure Stack Hubsban és az Azure-ban.

SKÁLÁZÁS

A skálázás olyan webes tárhelyet biztosít, amely 2009 óta működteti a digitális vállalkozásokat. A Scality RING, szoftveresen definiált tárolónk korlátlan tárolókészletté alakítja az árucikk x86-kiszolgálókat bármilyen típusú adathoz (fájlhoz és objektumhoz) petabájtos skálán.

FELHŐBELI

A Cloudian leegyszerűsíti a nagyvállalati tárolást korlátlan skálázható tárterülettel, amely egyetlen, könnyen felügyelt környezetbe összesíti a hatalmas adathalmazokat.

Következő lépések

A cikkben bevezetett fogalmakról további információt a következő cikkben talál:

• Felhők közötti skálázás és földrajzilag elosztott alkalmazásminták az Azure Stack Hubban.
• Mikroszolgáltatás-architektúra Azure Kubernetes Service (AKS) esetén.

Ha készen áll a megoldási példa tesztelésére, folytassa a Magas rendelkezésre állású Kubernetes-fürt üzembe helyezési útmutatójával. Az üzembe helyezési útmutató részletes útmutatást nyújt az összetevők üzembe helyezéséhez és teszteléséhez.