Ez a referenciaarchitektúra azt ismerteti, hogyan futtathat egy Azure Kubernetes Service-fürt több példányát több régióban aktív/aktív és magas rendelkezésre állású konfigurációban.
Ez az architektúra az AKS alaparchitektúrájára épül, amely a Microsoft ajánlott kiindulópontja az AKS-infrastruktúrához. Az AKS alapkonfigurációja olyan infrastrukturális funkciókat részletez, mint a Microsoft Entra Számítási feladat ID, a bejövő és kimenő forgalom korlátozásai, az erőforráskorlátok és más biztonságos AKS-infrastruktúra-konfigurációk. Ezek az infrastrukturális részletek nem szerepelnek ebben a dokumentumban. Javasoljuk, hogy a többrégiós tartalom megismerése előtt ismerkedjen meg az AKS alapkonfigurációjával.
Felépítés
Töltse le az architektúra Visio-fájlját.
Az architektúra referencia-implementációja elérhető a GitHubon.
Összetevők
A többrégiós AKS referenciaarchitektúra számos összetevőt és Azure-szolgáltatást használ. Az alábbiakban csak azokat az összetevőket soroljuk fel, amelyek egyediek ehhez a többfürt-architektúrához. A fennmaradó résznél hivatkozzon az AKS Alapkonfigurációs architektúrára.
- Több fürt /több régió Több AKS-fürt van üzembe helyezve, amelyek mindegyike külön Azure-régióban található. A normál műveletek során a hálózati forgalom az összes régió között van irányítva. Ha egy régió elérhetetlenné válik, a rendszer a forgalmat a kérést kibocsátó felhasználóhoz legközelebbi régióba irányítja.
- küllős hálózat régiónként Egy regionális küllős hálózati pár minden regionális AKS-példányhoz üzembe van helyezve. Az Azure Firewall Manager-szabályzatok az összes régió tűzfalszabályzatának kezelésére szolgálnak.
- Az Azure Key Vault regionális kulcstárolója minden régióban ki van építve az AKS-példányra jellemző bizalmas értékek és kulcsok, valamint az adott régióban található támogató szolgáltatások tárolására.
- Az Azure Front Door Azure Front Door a forgalom terheléselosztására és átirányítására szolgál egy regionális Azure-alkalmazás átjárópéldányhoz, amely az egyes AKS-fürtök előtt helyezkedik el. Az Azure Front Door lehetővé teszi a 7. réteg globális útválasztását, amelyek mindegyike szükséges ehhez a referenciaarchitektúrához.
- A Log Analytics regionális Log Analytics-példányai regionális hálózati metrikák és diagnosztikai naplók tárolására szolgálnak. Emellett egy megosztott Log Analytics-példány is használható az összes AKS-példány metrikáinak és diagnosztikai naplóinak tárolására.
- Tárolóregisztrációs adatbázis A számítási feladat tárolólemezképei egy felügyelt tárolóregisztrációs adatbázisban vannak tárolva. Ebben az architektúrában egyetlen Azure Container Registryt használunk a fürt összes Kubernetes-példányához. Az Azure Container Registry georeplikálása lehetővé teszi a rendszerképek replikálását a kijelölt Azure-régiókba, és folyamatos hozzáférést biztosít a képekhez még akkor is, ha egy régió leállást tapasztal.
Tervezési minták
Ez a referenciaarchitektúra két felhőtervezési mintát használ. Földrajzi csomópont (geodézia), ahol bármely régió bármilyen kérést kiszolgálhat, és üzembe helyezési bélyegek , amelyekben egy alkalmazás vagy alkalmazás-összetevő több független példánya van üzembe helyezve egyetlen forrásból (üzembehelyezési sablon).
A földrajzi csomópont mintáinak szempontjai
Amikor régiókat választ ki az egyes AKS-fürtök üzembe helyezéséhez, vegye figyelembe a számítási feladat felhasználójához vagy ügyfeleihez közeli régiókat. Fontolja meg a régiók közötti replikációt is. A régiók közötti replikáció aszinkron módon replikálja ugyanazokat az alkalmazásokat és adatokat más Azure-régiókban vészhelyreállítási védelem céljából. Mivel a fürt mérete meghaladja a két régiót, tervezze meg a régiók közötti replikációt minden egyes AKS-fürtpár esetében.
Az egyes régiókban az AKS-csomópontkészletek csomópontjai több rendelkezésre állási zónában vannak elosztva, hogy megelőzzék a zónahibák miatti problémákat. A rendelkezésre állási zónák korlátozott számú régióban támogatottak, ami befolyásolja a regionális fürtök elhelyezését. Az AKS-sel és a rendelkezésre állási zónákkal kapcsolatos további információkért, beleértve a támogatott régiók listáját, tekintse meg az AKS rendelkezésre állási zónáit.
Üzembehelyezési bélyeggel kapcsolatos szempontok
Többrégiós AKS-fürt kezelésekor a rendszer több AKS-példányt helyez üzembe több régióban. A példányok mindegyike bélyegnek minősül. Regionális hiba vagy további kapacitás és/vagy regionális jelenlét hozzáadása esetén előfordulhat, hogy létre kell hoznia egy új bélyegpéldányt. Az üzembehelyezési bélyegek létrehozására és kezelésére szolgáló folyamat kiválasztásakor fontos megfontolni a következő szempontokat:
- Válassza ki a megfelelő technológiát a bélyegdefiníciókhoz, amelyek lehetővé teszik az általános konfigurációt, például az infrastruktúrát kódként
- Példányspecifikus értékek megadása üzembehelyezési bemeneti mechanizmussal, például változókkal vagy paraméterfájlokkal
- Válassza ki a rugalmas, megismételhető és idempotens üzembe helyezést lehetővé tevő üzembehelyezési eszközt
- Aktív/aktív bélyegkonfiguráció esetén fontolja meg, hogy a forgalom hogyan van osztva az egyes bélyegek között
- Mivel a bélyegeket hozzáadják és eltávolítják a gyűjteményből, fontolja meg a kapacitással és a költséggel kapcsolatos problémákat
- Fontolja meg, hogyan nyerhet láthatóságot és/vagy figyelheti a bélyegek gyűjteményét egyetlen egységként.
A referenciaarchitektúra alábbi szakaszai részletesen ismertetik ezeket az elemeket.
Flottakezelés
Ez a megoldás egy többfürtből és többrégiós topológiából álló topológiát képvisel, anélkül, hogy egy fejlett vezénylő belefoglalja az összes fürtöt egy egységes flotta részeként. A fürtszám növekedésével érdemes lehet regisztrálni a tagokat az Azure Kubernetes Fleet Managerben a részt vevő fürtök jobb szintű felügyeletéhez. Az itt bemutatott infrastruktúra-architektúra alapvetően nem változik a Fleet Managerbe való regisztrációval, de a 2. nap műveletei és hasonló tevékenységei egy olyan vezérlősík előnyeit élvezik, amely egyszerre több fürtöt is megcéloz.
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.
Fürt üzembe helyezése és rendszerindítás
Ha több Kubernetes-fürtöt helyez üzembe magas rendelkezésre állású és földrajzilag elosztott konfigurációkban, elengedhetetlen, hogy az egyes Kubernetes-fürtök összegét összekapcsolt egységként tekintsük. Érdemes lehet kódalapú stratégiákat kidolgozni az automatizált üzembe helyezéshez és konfiguráláshoz, hogy az egyes Kubernetes-példányok a lehető legnagyobb mértékben azonosak legyenek. Érdemes megfontolni a horizontális fel- és beskálázási stratégiákat más Kubernetes-példányok hozzáadásával vagy eltávolításával. Azt szeretné, hogy a tervezési és üzembe helyezési és konfigurációs terv figyelembe veszi a regionális hibákat vagy más gyakori forgatókönyveket.
Fürtdefiníció
Számos lehetősége van az Azure Kubernetes Service-fürt üzembe helyezésére. Az Azure Portal, az Azure CLI és az Azure PowerShell modul mind megfelelő lehetőségek az egyéni vagy nem összekapcsolt AKS-fürtök üzembe helyezéséhez. Ezek a módszerek azonban kihívást jelenthetnek számos szorosan összekapcsolt AKS-fürt használatakor. Az Azure Portal használatával például a kihagyott lépések vagy a nem elérhető konfigurációs beállítások miatt megnyílik a lehetőség a hibás konfigurációra. Emellett számos fürt üzembe helyezése és konfigurálása a portál használatával egy időben történő folyamat, amely egy vagy több mérnök fókuszát igényli. A parancssori eszközökkel megismételhető és automatizált folyamatot hozhat létre. Az idempotencia, az üzembe helyezési hibák kezelése és a hibahelyreállítás azonban Önre és a buildelt szkriptekre hárul.
Ha sok AKS-példányt használ, javasoljuk, hogy az infrastruktúrát kódmegoldásként, például Azure Resource Manager-sablonként, Bicep-sablonként vagy Terraform-konfigurációként tekintse. Az infrastruktúra kódmegoldásként automatizált, skálázható és idempotens üzembe helyezési megoldást biztosít. Ez a referenciaarchitektúra tartalmaz egy ARM-sablont a megosztott megoldásokhoz, majd egy másikat az AKS-fürtökhöz és a regionális szolgáltatásokhoz. Ha az infrastruktúrát kódként használja, az üzembehelyezési bélyegző általános konfigurációkkal, például hálózatkezeléssel, engedélyezéssel és diagnosztikával határozható meg. Az üzembehelyezési paraméterfájl régióspecifikus értékekkel is megadható. Ezzel a konfigurációval egyetlen sablon használatával szinte azonos bélyeg helyezhető üzembe bármely régióban.
Az infrastruktúra kódegységként való fejlesztésének és karbantartásának költsége költséges lehet. Bizonyos esetekben, például ha statikus/rögzített számú AKS-példány van üzembe helyezve, a kódként használt infrastruktúra többletterhelése meghaladhatja az előnyöket. Ezekben az esetekben az imperatívabb megközelítés, például a parancssori eszközök vagy akár a manuális megközelítés használata is rendben van.
Fürt üzembe helyezése
A fürtbélyeg definíciójának definiálása után számos lehetősége van az egyes vagy több bélyegpéldányok üzembe helyezésére. Javasoljuk, hogy használjon modern folyamatos integrációs technológiát, például a GitHub Actionst vagy az Azure Pipelinest. A folyamatos integrációalapú üzembehelyezési megoldások előnyei a következők:
- Kódalapú üzemelő példányok, amelyek lehetővé teszik a bélyegek kóddal való hozzáadását és eltávolítását
- Integrált tesztelési képességek
- Integrált környezet és előkészítési képességek
- Integrált titkos kódok kezelési megoldásai
- Integráció a kód/ üzembehelyezési forrásvezérlővel
- Üzembe helyezési előzmények és naplózás
Az új bélyegek globális fürtből való hozzáadásakor vagy eltávolításakor az üzembehelyezési folyamatot frissíteni kell a konzisztensség érdekében. A referencia-implementációban minden régió külön lépésként lesz üzembe helyezve egy GitHub Action-munkafolyamaton belül (példa). Ez a konfiguráció egyszerű, mert minden fürtpéldány egyértelműen definiálva van az üzembe helyezési folyamaton belül. Ez a konfiguráció némi adminisztratív többletterhelést jelent a fürtök üzembe helyezésből való hozzáadásában és eltávolításában.
Egy másik lehetőség az lenne, ha logikát használna fürtök létrehozásához a kívánt helyek vagy egyéb adatpontok listája alapján. Az üzembehelyezési folyamat például tartalmazhatja a kívánt régiók listáját; A folyamat egy lépése ezt követően végighaladhat ezen a listán, és üzembe helyezhet egy fürtöt a listában található minden régióban. Ennek a konfigurációnak a hátránya az üzembe helyezés általánosításának összetettsége, és hogy az egyes fürtbélyegek nincsenek explicit módon részletezve az üzembe helyezési folyamatban. A pozitív előnye, hogy a fürtbélyegek hozzáadása vagy eltávolítása a folyamatból egyszerű frissítéssé válik a kívánt régiók listájára.
Emellett a fürtbélyeg eltávolítása az üzembe helyezési folyamatból nem feltétlenül biztosítja, hogy az is leszerelésre kerüljön. Az üzembe helyezési megoldástól és a konfigurációtól függően szükség lehet egy további lépésre annak biztosításához, hogy az AKS-példányok megfelelően leszereltek.
Fürt rendszerindítása
Az egyes Kubernetes-példányok vagy -bélyegek üzembe helyezése után a fürtösszetevőket, például a bejövőforgalom-vezérlőket, az identitásmegoldásokat és a számítási feladat összetevőit üzembe kell helyezni és konfigurálni kell. Érdemes megfontolnia a biztonsági, hozzáférési és szabályozási szabályzatok alkalmazását is a fürtön.
Az üzembe helyezéshez hasonlóan ezek a konfigurációk is kihívást jelenthetnek több Kubernetes-példány manuális kezelése során. Ehelyett fontolja meg a következő beállításokat a nagy léptékű konfigurációhoz és szabályzathoz.
GitOps
A Kubernetes-összetevők manuális konfigurálása helyett fontolja meg az automatizált metódusok használatát a kubernetes-fürtök konfigurációinak alkalmazásához, mivel ezek a konfigurációk bekerülnek egy forrásadattárba. Ezt a folyamatot gyakran GitOps-nak nevezik, és a Kuberneteshez készült népszerű GitOps-megoldások közé tartozik a Flux és az Argo CD. Ez az implementáció az AKS Flux bővítményét használja a fürtök automatikus és közvetlenül a fürtök üzembe helyezése után történő rendszerindításának engedélyezéséhez.
A GitOps részletesebben ismerteti az AKS referenciaarchitektúrát. A lényeg itt az, hogy a GitOps-alapú konfigurációs módszer használata segít biztosítani, hogy minden Kubernetes-példány hasonlóan legyen konfigurálva, anélkül, hogy erőfeszítést kellene tenni. Ez még fontosabb lesz a flotta méretének növekedésével.
Azure Policy
Több Kubernetes-példány hozzáadásakor nő a szabályzatalapú szabályozás, a megfelelőség és a konfiguráció előnye. A szabályzatok használatával az Azure Policy egy központosított és skálázható módszert biztosít a fürtvezérléshez. Az AKS-szabályzatok előnyeit az AKS alapkonfigurációs architektúrája ismerteti.
Az Azure Policy engedélyezve van ebben a referencia-implementációban az AKS-fürtök létrehozásakor, és naplózási módban rendeli hozzá a korlátozó kezdeményezést, hogy betekintést nyerjen a meg nem felelésbe. A megvalósítás további szabályzatokat is beállít, amelyek nem részei a beépített kezdeményezéseknek. Ezek a házirendek Megtagadás módban vannak beállítva. Létezik például egy szabályzat, amely biztosítja, hogy csak a jóváhagyott tárolólemezképek fussanak a fürtben. Fontolja meg saját egyéni kezdeményezések létrehozását. Egyesítse a számítási feladatra vonatkozó szabályzatokat egyetlen hozzárendelésben.
A szabályzat hatóköre az egyes szabályzatok és szakpolitikai kezdeményezések céljára vonatkozik. Az architektúrához társított referencia-implementáció arm-sablonnal rendel házirendeket ahhoz az erőforráscsoporthoz, amelybe az egyes AKS-fürtök telepítve lesznek. A globális fürt lábnyomának növekedésével számos ismétlődő házirendet eredményez. A szabályzatokat azure-előfizetésre vagy Azure felügyeleti csoportra is hatókörbe helyezheti. Ez a módszer lehetővé teszi, hogy egyetlen szabályzatkészletet alkalmazzon az előfizetés hatókörén belüli összes AKS-fürtre és/vagy a felügyeleti csoportban található összes előfizetésre.
Több AKS-fürt házirendjének tervezésekor vegye figyelembe a következő elemeket:
- Az összes AKS-példányra globálisan alkalmazandó szabályzatok felügyeleti csoportra vagy előfizetésre alkalmazhatók
- Az egyes regionális fürtök saját erőforráscsoportba helyezése lehetővé teszi az erőforráscsoportra alkalmazott régióspecifikus szabályzatok alkalmazását
Tekintse meg felhőadaptálási keretrendszer erőforrás-szervezetnél azokat az anyagokat, amelyek segítenek a szabályzatkezelési stratégia kialakításában.
Számítási feladatok üzembe helyezése
Az AKS-példány konfigurációja mellett vegye figyelembe az egyes regionális példányokban vagy -bélyegzőkben üzembe helyezett számítási feladatot. Az üzembehelyezési megoldásokhoz vagy folyamatokhoz konfigurációra lesz szükség az egyes regionális bélyegek elhelyezéséhez. Mivel a rendszer további bélyegeket ad hozzá a globális fürthöz, az üzembe helyezési folyamatot ki kell terjeszteni, vagy elég rugalmasan kell kezelni az új regionális példányokat.
A számítási feladatok üzembe helyezésének tervezésekor vegye figyelembe az alábbi elemeket.
- Általánosítsa az üzembe helyezést, például egy Helm-diagrammal, hogy egyetlen üzembehelyezési konfiguráció több fürtbélyeg között is használható legyen.
- Használjon egyetlen folyamatos üzembehelyezési folyamatot, amely úgy van konfigurálva, hogy a számítási feladatot az összes fürtbélyegen üzembe helyezze.
- Adjon meg bélyegspecifikus példányadatokat üzembehelyezési paraméterekként.
- Gondolja át, hogyan van konfigurálva az alkalmazásdiagnosztikai naplózás és az elosztott nyomkövetés az alkalmazásszintű megfigyelhetőség érdekében.
Rendelkezésre állás és feladatátvétel
A többrégiós Kubernetes-architektúra kiválasztásának jelentős motivációja a szolgáltatások rendelkezésre állása. Vagyis ha egy szolgáltatás vagy szolgáltatásösszetevő elérhetetlenné válik egy régióban, a forgalmat egy olyan régióba kell irányítani, ahol a szolgáltatás elérhető. A többrégiós architektúra számos különböző hibapontot tartalmaz. Ebben a szakaszban ezeket a lehetséges hibapontokat tárgyaljuk.
Alkalmazás podok (regionális)
A Kubernetes üzembehelyezési objektuma egy pod (ReplicaSet) több replikáját is létrehozza. Ha az egyik nem érhető el, a forgalom a többi között lesz irányítva. A Kubernetes ReplicaSet megkísérli a megadott számú replika működését. Ha egy példány leáll, újra létre kell hozni egy új példányt. Végül a podon futó alkalmazás vagy folyamat állapotának ellenőrzésére használható élőségi mintavételek. Ha a szolgáltatás nem válaszol, az élőség-mintavétel eltávolítja a podot, ami arra kényszeríti a ReplicaSetet, hogy hozzon létre egy új példányt.
További információ: Kubernetes ReplicaSet.
Alkalmazás podok (globális)
Amikor egy teljes régió elérhetetlenné válik, a fürt podjai már nem érhetők el a kérések kiszolgálására. Ebben az esetben az Azure Front Door-példány az összes forgalmat a többi kifogástalan régióba irányítja. Az ezekben a régiókban található Kubernetes-fürtök és podok továbbra is kiszolgálják a kéréseket.
Ebben a helyzetben ügyeljen arra, hogy kompenzálja a fennmaradó fürt felé irányuló megnövekedett forgalmat/ kéréseket. Néhány megfontolandó szempont:
- Győződjön meg arról, hogy a hálózati és számítási erőforrások megfelelő méretűek ahhoz, hogy elnyeljék a régió feladatátvétele miatti hirtelen forgalomnövekedést. Az Azure CNI használatakor például győződjön meg arról, hogy rendelkezik olyan alhálózattal, amely támogatja a kiugró forgalommal rendelkező pod IP-címeket.
- A podreplikák számának növeléséhez használja a vízszintes podok automatikus skálázását a megnövekedett regionális igények kompenzálása érdekében.
- Az AKS-fürt automatikus skálázási funkciójának használatával növelje a Kubernetes-példány csomópontszámát a megnövekedett regionális kereslet kompenzálásához.
További információ: Vízszintes pod automatikus skálázása és AKS-fürt automatikus skálázása.
Kubernetes-csomópontkészletek (regionális)
Esetenként honosított hiba fordulhat elő a számítási erőforrásoknál, például ha a teljesítmény elérhetetlenné válik az Azure-kiszolgálók egyetlen állványán. Annak érdekében, hogy az AKS-csomópontok ne váljon egy pontból regionális hibává, használja az Azure Rendelkezésre állási zónákat. A rendelkezésre állási zónák használata biztosítja, hogy egy adott rendelkezésre állási zónában lévő AKS-csomópontok fizikailag elkülönülnek a másik rendelkezésre állási zónában meghatározottaktól.
További információ: AKS és Azure rendelkezésre állási zónák.
Kubernetes-csomópontkészletek (globális)
Teljes regionális hiba esetén az Azure Front Door átirányítja a forgalmat a fennmaradó és kifogástalan állapotú régiókba. Ebben a helyzetben is ügyeljen arra, hogy kompenzálja a fennmaradó fürt felé irányuló megnövekedett forgalmat/ kéréseket.
További információ: Azure Front Door.
hálózati topológia,
Az AKS referenciaarchitektúrához hasonlóan ez az architektúra küllős hálózati topológiát használ. Az AKS referenciaarchitektúrájában meghatározott szempontok mellett vegye figyelembe az alábbi ajánlott eljárásokat:
- Implementáljon egy küllős küllőt minden regionális AKS-példányhoz, ahol a küllős virtuális hálózatok társviszonyban vannak.
- Az összes kimenő forgalom átirányítása az egyes regionális központi hálózatokban található Azure Firewall-példányon keresztül. Az Azure Firewall Manager-szabályzatok használatával minden régióban kezelheti a tűzfalszabályzatokat.
- Kövesse az AKS alapkonfigurációs architektúrájában található IP-méretezést, és adjon meg további IP-címeket a csomópont- és podméretezési műveletekhez is, ha regionális hibát tapasztal.
Forgalomkezelés
Az AKS alapkonfigurációs architektúrájával a számítási feladatok forgalmát közvetlenül egy Azure-alkalmazás Gateway-példányra irányítjuk, majd továbbítjuk a háttérbeli terheléselosztóra/ AKS bejövő erőforrásokra. Ha több fürttel dolgozik, az ügyfélkérések egy Azure Front Door-példányon keresztül lesznek átirányítva, amely az Azure-alkalmazás Átjárópéldányra irányítja át.
Töltse le a diagram Visio-fájlját.
A felhasználó kérést küld egy tartománynévnek (például
https://contoso-web.azurefd.net), amelyet a rendszer felold az Azure Front Door-példánynak. Ez a kérés az Azure Front Door összes altartományához kiadott helyettesítő tanúsítvánnyal (*.azurefd.net) van titkosítva. Az Azure Front Door-példány érvényesíti a kérést WAF-szabályzatok alapján, kiválasztja a leggyorsabb háttérrendszert (az állapot és a késés alapján), és nyilvános DNS használatával oldja fel a háttérbeli IP-címet (Azure-alkalmazás átjárópéldányt).A Front Door továbbítja a kérelmet a kiválasztott megfelelő Application Gateway-példánynak, amely a regionális bélyeg belépési pontjaként szolgál. A forgalom az interneten keresztül áramlik, és az Azure Front Door titkosítja. Fontolja meg azt a módszert, amely biztosítja, hogy az Application Gateway-példány csak a Front Door-példányból érkező forgalmat fogadja el. Az egyik módszer egy hálózati biztonsági csoport használata az Application Gatewayt tartalmazó alhálózaton. A szabályok szűrhetik a bejövő (vagy kimenő) forgalmat olyan tulajdonságok alapján, mint a forrás, a port, a cél. A Forrás tulajdonság lehetővé teszi egy beépített szolgáltatáscímke beállítását, amely egy Azure-erőforrás IP-címeit jelzi. Ez az absztrakció megkönnyíti a szabály konfigurálását és karbantartását, valamint az IP-címek nyomon követését. Emellett érdemes lehet a Front Doort a háttérfejlécre
X-Azure-FDIDhasználni annak biztosítása érdekében, hogy az Application Gateway-példány csak a Front Door-példányból érkező forgalmat fogadja el. További információ a Front Door fejlécekről: Http-fejlécek protokolltámogatása az Azure Front Doorban.
Megosztott erőforrásokkal kapcsolatos szempontok
Bár a referenciaarchitektúra középpontjában a több Kubernetes-példány több Azure-régióban való elterjesztése áll, érdemes néhány megosztott erőforrással rendelkezni az összes példányon. Az AKS többrégiós referencia-implementációja egyetlen ARM-sablon használatával üzembe helyezi az összes megosztott erőforrást, majd egy másikat az egyes regionális bélyegek üzembe helyezéséhez. Ez a szakasz részletesen ismerteti ezeket a megosztott erőforrásokat, és figyelembe veszi az egyes AKS-példányok mindegyikének használatát.
Container Registry
Az Azure Container Registry ebben a referenciaarchitektúrában tárolórendszerkép-szolgáltatások (lekérés) biztosítására szolgál. Vegye figyelembe a következő elemeket, amikor az Azure Container Registryt többrégiós fürttelepítésben dolgozik.
Földrajzi elérhetőség
A tárolóregisztrációs adatbázis minden olyan régióban való elhelyezése, amelyben egy AKS-fürt üzembe van helyezve, lehetővé teszi a hálózatzárási műveleteket, lehetővé téve a gyors és megbízható képréteg-átvitelt. Több képszolgáltatás-végponttal rendelkezik a rendelkezésre állás biztosításához, ha a regionális szolgáltatások nem érhetők el. Az Azure Container Registries georeplikációs funkcióval több régióba replikált Container Registry-példány kezelhető.
Az AKS többrégiós referencia-implementáció egyetlen Container Registry-példányt hozott létre, és ennek a példánynak a replikáit minden fürtrégióban. További információ az Azure Container Registry replikációról: Georeplikálás az Azure Container Registryben.
Az Azure Portalon több ACR-replikát ábrázoló kép.
Fürthozzáférés
Minden AKS-példánynak hozzáférésre van szüksége a rendszerképrétegek Azure Container Registryből való lekéréséhez. Az Azure Container Registryhez való hozzáférés többféleképpen is létrehozható; ez a referenciaarchitektúra minden fürthöz egy Azure Managed Identity-et használ, amely ezután megkapja az AcrPull-szerepkört a Container Registry-példányon. A felügyelt identitások tárolóregisztrációs hozzáféréshez való használatával kapcsolatos további információkért és javaslatokért tekintse meg az AKS alapkonfigurációs referenciaarchitektúrát.
Ez a konfiguráció a fürtbélyeg ARM-sablonjában van definiálva, így minden új bélyeg üzembe helyezésekor az új AKS-példány hozzáférést kap. Mivel a Tárolóregisztrációs adatbázis megosztott erőforrás, győződjön meg arról, hogy az üzembe helyezési bélyegsablon felhasználhatja és felhasználhatja a szükséges adatokat, ebben az esetben a Tárolóregisztrációs adatbázis erőforrás-azonosítóját.
Azure Monitor
Az Azure Monitor Container Insights szolgáltatás az ajánlott eszköz a fürt és a tároló számítási feladatainak teljesítményének és állapotának figyeléséhez és megértéséhez. A Container Insights egy Log Analytics-munkaterületet is használ a naplóadatok tárolására, az Azure Monitor Metrics pedig numerikus idősoros adatok tárolására. A Prometheus-metrikákat a Container Elemzések is gyűjtheti, és elküldheti az adatokat a Prometheushoz készült Azure Monitor által felügyelt szolgáltatásnak vagy az Azure Monitor naplóinak.
Az AKS-fürt diagnosztikai beállításait úgy is konfigurálhatja, hogy erőforrásnaplókat gyűjtsön és elemezzen az AKS vezérlősík összetevőiből, és továbbíthassa egy Log Analytics-munkaterületre.
Az AKS-ről további információt az AKS alapkonfigurációs architektúrája tartalmaz.
Az olyan régiók közötti implementációk monitorozásának mérlegelésekor, mint például ez a referenciaarchitektúra, fontos figyelembe venni az egyes bélyegek közötti összekapcsolást. Ebben az esetben minden egyes bélyeget egyetlen egység (regionális fürt) összetevőjének tekintünk. A többrégiós AKS-referencia-implementáció egyetlen Log Analytics-munkaterületet használ, amelyet az egyes Kubernetes-fürtök osztanak meg. A többi megosztott erőforráshoz hasonlóan definiálja a regionális bélyeget az egyetlen Log Analytics-munkaterület adatainak felhasználásához és az egyes fürtök csatlakoztatásához.
Most, hogy az egyes regionális fürtök diagnosztikai naplókat bocsátanak ki egyetlen Log Analytics-munkaterületre, ezek az adatok az erőforrás-metrikákkal együtt egyszerűbben készíthetnek olyan jelentéseket és irányítópultokat, amelyek a globális fürt teljes egészét képviselik.
Azure Front Door
Az Azure Front Door az egyes AKS-fürtök terheléselosztására és a forgalom irányítására szolgál. Az Azure Front Door lehetővé teszi a 7. réteg globális útválasztását, amelyek mindegyike szükséges ehhez a referenciaarchitektúrához.
Cluster configuration
A regionális AKS-példányok hozzáadásakor a Kubernetes-fürt mellett üzembe helyezett Application Gatewayt Front Door-háttérrendszerként kell regisztrálni a megfelelő útválasztáshoz. Ehhez a művelethez kódegységként frissíteni kell az infrastruktúrát. Másik lehetőségként ez a művelet leválasztható az üzembehelyezési konfigurációról, és kezelhető olyan eszközökkel, mint az Azure CLI. A hivatkozott referencia-implementációk üzembehelyezési folyamata ehhez a művelethez egy különálló Azure CLI-lépést használ.
Diplomák
A Front Door még Dev/Test környezetben sem támogatja az önaláírt tanúsítványokat. A HTTPS-forgalom engedélyezéséhez létre kell hoznia egy hitelesítésszolgáltató (CA) által aláírt TLS/SSL-tanúsítványt. A referencia-implementáció a Certbot használatával hoz létre egy Let's Encrypt Authority X3 tanúsítványt. Éles fürt tervezésekor használja a szervezet által előnyben részesített TLS-tanúsítványok beszerzésének módszerét.
További információ a Front Door által támogatott egyéb hitelesítésszolgáltatókról: Engedélyezett hitelesítésszolgáltatók az egyéni HTTPS engedélyezéséhez az Azure Front Dooron.
Fürthozzáférés és -identitás
Az AKS alapkonfigurációs referenciaarchitektúrájában leírtaknak megfelelően ajánlott a Microsoft Entra ID-t használni a fürtök hozzáférési identitásszolgáltatójaként. A Microsoft Entra-csoportok ezután a fürterőforrásokhoz való hozzáférés szabályozására használhatók.
Ha több fürtöt kezel, el kell döntenie egy hozzáférési sémát. A lehetőségek a következők:
- Hozzon létre egy globális fürtszintű hozzáférési csoportot, amelyben a tagok a fürt minden Kubernetes-példányában elérhetik az összes objektumot. Ez a beállítás minimális adminisztrációs szükségletet biztosít; azonban jelentős jogosultságot biztosít bármely csoporttag számára.
- Hozzon létre egy egyéni hozzáférési csoportot minden olyan Kubernetes-példányhoz, amely egy adott fürtpéldány objektumaihoz való hozzáférést biztosít. Ezzel a beállítással a rendszergazdai többletterhelés nő; azonban részletesebb fürthozzáférést is biztosít.
- Részletes hozzáférés-vezérlők definiálása a Kubernetes-objektumtípusokhoz és névterekhez, és az eredmények egy Azure Directory-csoportstruktúrával való korrelálása. Ezzel a lehetőséggel a felügyeleti többletterhelés jelentősen megnő; Azonban nem csak az egyes fürtökhöz biztosít részletes hozzáférést, hanem az egyes fürtökben található névterekhez és Kubernetes APIS-hoz is.
A mellékelt referencia-implementációval két Microsoft Entra-csoport jön létre a rendszergazdai hozzáféréshez. Ezek a csoportok a fürtbélyeg üzembehelyezési idején vannak megadva az üzembe helyezési paraméterfájl használatával. Az egyes csoportok tagjai teljes hozzáféréssel rendelkeznek a megfelelő fürtbélyeghez.
Az AKS-fürthozzáférés Microsoft Entra-azonosítóval való kezeléséről további információt az AKS Microsoft Entra-integrációban talál.
Adatok, állapot és gyorsítótár
Ha AKS-példányokat tartalmazó globálisan elosztott fürtöt használ, fontolja meg az alkalmazás, a folyamat vagy más, a fürtben futtatható számítási feladatok architektúráját. Mivel az állapotalapú számítási feladatok a fürtben elterülnek, hozzá kell férnie egy állapottárolóhoz? Ha hiba miatt egy folyamat újra létrejön a fürt más részein, a számítási feladat vagy folyamat továbbra is hozzáfér egy függő állapottárhoz vagy gyorsítótárazási megoldáshoz? Az állapot többféleképpen is elérhető; azonban összetett lehet egyetlen Kubernetes-fürtben. Ha több fürtözött Kubernetes-példányban ad hozzá, az összetettség nő. A regionális hozzáféréssel és az összetettséggel kapcsolatos problémák miatt fontolja meg az alkalmazások globálisan elosztott állapottár-szolgáltatás használatára való tervezését.
A többfürt-referencia implementációja nem tartalmaz állapotproblémák bemutatását vagy konfigurálásának módját. Ha fürtözött AKS-példányokon futtat alkalmazásokat, fontolja meg a számítási feladatok globálisan elosztott adatszolgáltatás, például az Azure Cosmos DB használatát. Az Azure Cosmos DB egy globálisan elosztott adatbázis, amely lehetővé teszi az adatok olvasását és írását az adatbázis helyi replikáiból. További információ: Azure Cosmos DB.
Ha a számítási feladat gyorsítótárazási megoldást használ, győződjön meg arról, hogy a gyorsítótárazási szolgáltatások működőképesek maradnak. Ehhez győződjön meg arról, hogy maga a számítási feladat rugalmas a gyorsítótárral kapcsolatos feladatátvétellel szemben, és hogy a gyorsítótárazási megoldások minden regionális AKS-példányon megtalálhatók.
Költségoptimalizálás
Az Azure díjkalkulátorával megbecsülhető az architektúrában használt szolgáltatások költségei. Egyéb ajánlott eljárásokat a Microsoft Azure Well-Architected Framework Költségoptimalizálás szakaszában, valamint a költségek optimalizálása című cikkben szereplő konkrét költségoptimalizálási konfigurációs lehetőségeket ismertetjük.
Fontolja meg az AKS költségelemzésének engedélyezését a fürtinfrastruktúra részletes költségfelosztásához a Kubernetes-specifikus szerkezetek szerint.
További lépések
- AKS rendelkezésre állási zónák
- Azure Kubernetes Fleet Manager
- Georeplikáció az Azure Container Registryben
- Párosított Azure-régiók