Az Azure Kubernetes Service (AKS) magas rendelkezésre állásának és vészhelyreállításának áttekintése

A felhőbeli alkalmazások létrehozásakor és kezelésekor mindig fennáll a kimaradások és a katasztrófák miatti fennakadások kockázata. Az üzletmenet-folytonosság (BC) biztosításához magas rendelkezésre állás (HA) és vészhelyreállítás (DR) tervezésére van szükség.

A HA egy olyan rendszer vagy szolgáltatás tervezésére és megvalósítására utal, amely rendkívül megbízható, és minimális állásidőt kínál. A HA olyan eszközök, technológiák és folyamatok kombinációja, amelyek biztosítják, hogy egy rendszer vagy szolgáltatás elérhető legyen a kívánt funkció elvégzéséhez. A HA a DR tervezésének kritikus összetevője. A dr. a vészből való helyreállítás és az üzleti műveletek normál állapotba történő visszaállításának folyamata. A DR a BC egy részhalmaza, amely az üzleti funkciók fenntartásának vagy gyors folytatásának folyamata nagy mértékű fennakadás esetén.

Ez a cikk az AKS-ben üzembe helyezett alkalmazások ajánlott eljárásait ismerteti, de semmiképpen sem jelenti a lehetséges megoldások teljes listáját.

A technológia áttekintése

Egy Kubernetes-fürt két összetevőre osztható:

  • A vezérlősík, amely az alapvető Kubernetes-szolgáltatásokat és az alkalmazás-számítási feladatok vezénylését biztosítja, és
  • Az alkalmazás számítási feladatait futtató csomópontok.

A Kubernetes vezérlősíkjának és csomópontösszetevőinek diagramja.

AKS-fürt létrehozásakor az Azure-platform automatikusan létrehoz és konfigurál egy vezérlősíkot. Az AKS két tarifacsomagot kínál a fürtkezeléshez: az ingyenes és a standard szintet. További információ: Ingyenes és Standard tarifacsomagok az AKS-fürtkezeléshez.

A vezérlősík és erőforrásai csak abban a régióban találhatók, ahol a fürtöt létrehozta. Az AKS egy bérlős vezérlősíkot biztosít dedikált API-kiszolgálóval, ütemezővel stb. Ön határozza meg a csomópontok számát és méretét, és az Azure platform konfigurálja a vezérlősík és a csomópontok közötti biztonságos kommunikációt. A vezérlősíkkal való interakció a Kubernetes API-kkal történik, például kubectl a Kubernetes-irányítópulton.

Az alkalmazások és a támogató szolgáltatások futtatásához Kubernetes-csomópontra van szükség. Az AKS-fürtök legalább egy csomóponttal, egy Azure-beli virtuális géppel (VM) rendelkeznek, amely a Kubernetes-csomópont összetevőit és a tároló futtatókörnyezetét futtatja. A csomópontok Azure-beli virtuálisgép-mérete határozza meg a processzorokat, a memóriát, a méretet és az elérhető tárolási típust (például a nagy teljesítményű SSD-t vagy a normál HDD-t). Tervezze meg a virtuális gép és a tárterület méretét, hogy az alkalmazások nagy mennyiségű processzort és memóriát vagy nagy teljesítményű tárolót igényelnek-e. Az AKS-ben a fürt csomópontjaihoz tartozó virtuálisgép-rendszerkép Ubuntu Linuxon, Azure Linuxon vagy Windows Server 2022-n alapul. Amikor létrehoz egy AKS-fürtöt, vagy kibővíti a csomópontok számát, az Azure-platform automatikusan létrehozza és konfigurálja a kért virtuális gépek számát.

Az AKS fürt- és számításifeladat-összetevőiről további információt az AKS Kubernetes alapfogalmaiban talál.

Fontos tényezők

Regionális és globális erőforrások

A regionális erőforrások üzembehelyezési bélyegző részeként vannak kiépítve egyetlen Azure-régióban. Ezek az erőforrások semmit sem osztanak meg más régiókban lévő erőforrásokkal, és egymástól függetlenül eltávolíthatók vagy replikálhatók más régiókba. További információ: Regionális erőforrások.

A globális erőforrások megosztják a rendszer élettartamát, és globálisan elérhetők egy többrégiós üzembe helyezés kontextusában. További információ: Globális erőforrások.

Helyreállítási célok

A teljes vészhelyreállítási tervnek üzleti követelményeket kell meghatároznia az alkalmazás által implementálandó minden egyes folyamathoz:

  • A helyreállítási pont célkitűzése (RPO) az elfogadható adatvesztés maximális időtartama. Az RPO mértékegysége időegység, például perc, óra vagy nap.
  • A helyreállítási idő célkitűzése (RTO) az elfogadható állásidő maximális időtartama, amelynek állásidejét az Ön specifikációja határozza meg. Ha például egy katasztrófa elfogadható állásideje nyolc óra, akkor az RTO nyolc óra.

Rendelkezésreállási zónák

Rendelkezésre állási zónákkal eloszthatja az adatokat több zónában ugyanabban a régióban. Egy régión belül a rendelkezésre állási zónák elég közel vannak ahhoz, hogy alacsony késésű kapcsolatokat létesíthessenek más rendelkezésre állási zónákkal, de elég messze vannak egymástól ahhoz, hogy csökkenjen annak a valószínűsége, hogy egynél többre hatással lesznek a helyi kimaradások vagy az időjárás. További információ: Javaslatok a rendelkezésre állási zónák és régiók használatáról.

Zonális rugalmasság

Az AKS-fürtök rugalmasak a zónahibákkal szemben. Ha egy zóna meghibásodik, a fürt továbbra is a fennmaradó zónákban fut. A fürt vezérlősíkja és csomópontjai el vannak osztva a zónák között, és az Azure-platform automatikusan kezeli a csomópontok elosztását. További információ: AKS zonális rugalmasság.

Terheléselosztás

Globális terheléselosztás

A globális terheléselosztási szolgáltatások a forgalmat regionális háttérrendszerek, felhők vagy hibrid helyszíni szolgáltatások között osztják el. Ezek a szolgáltatások a végfelhasználói forgalmat a legközelebbi elérhető háttérrendszerhez irányítják. Emellett reagálnak a szolgáltatás megbízhatóságának vagy teljesítményének változásaira a rendelkezésre állás és a teljesítmény maximalizálása érdekében. A következő Azure-szolgáltatások biztosítják a globális terheléselosztást:

Regionális terheléselosztás

A regionális terheléselosztási szolgáltatások virtuális hálózatokon belüli forgalmat osztanak el virtuális gépeken, illetve zóna- és zónaredundáns szolgáltatási végpontokon egy régión belül. A következő Azure-szolgáltatások biztosítják a regionális terheléselosztást:

Megfigyelhetőség

A hatékony működés és a maximális megbízhatóság érdekében adatokat kell gyűjtenie az alkalmazásokból és az infrastruktúrából. Az Azure eszközöket biztosít az AKS-számítási feladatok monitorozásához és kezeléséhez. További információ: Megfigyelhetőségi erőforrások.

Hatókördefiníció

Az alkalmazás üzemideje az AKS-fürtök kezelésekor válik fontossá. Az AKS alapértelmezés szerint magas rendelkezésre állást biztosít egy virtuálisgép-méretezési csoport több csomópontjának használatával, de ezek a csomópontok nem védik a rendszert a régióhibáktól. Az üzemidő maximalizálása érdekében tervezze meg előre az üzletmenet folytonosságát, és készüljön fel a vészhelyreállításra az alábbi ajánlott eljárásokkal:

  • Tervezze meg az AKS-fürtöket több régióban.
  • A forgalmat több fürt között irányíthatja az Azure Traffic Managerrel.
  • Használjon georeplikációs elemet a tárolórendszerkép-nyilvántartásokhoz.
  • Alkalmazásállapot tervezése több fürtben.
  • Több régióban replikálja a tárterületet.

Üzembehelyezési modell implementációi

Üzembehelyezési modell Előnyök Hátrányok
Aktív-aktív • Nincs adatvesztés vagy inkonzisztencia a feladatátvétel során
• Nagy rugalmasság
• Nagyobb teljesítményű erőforrások jobb kihasználtsága
• Komplex megvalósítás és felügyelet
• Magasabb költség
• Terheléselosztót és forgalomirányítási formát igényel
Aktív-passzív • Egyszerűbb megvalósítás és felügyelet
• Alacsonyabb költség
• Nincs szükség terheléselosztóra vagy forgalomkezelőre
• Adatvesztés vagy inkonzisztencia a feladatátvétel során
• Hosszabb helyreállítási idő és állásidő
• Az erőforrások kihasználatlansága
Passzív-hideg • Legalacsonyabb költség
• Nem igényel szinkronizálást, replikációt, terheléselosztót vagy traffic managert
• Alacsony prioritású, nem kritikus számítási feladatokhoz alkalmas
• Nagy az adatvesztés vagy az inkonzisztencia kockázata a feladatátvétel során
• Leghosszabb helyreállítási idő és állásidő
• Manuális beavatkozást igényel a fürt aktiválásához és a biztonsági mentés aktiválásához

Aktív-aktív magas rendelkezésre állású üzembehelyezési modell

Az aktív-aktív magas rendelkezésre állású (HA) üzembehelyezési modellben két független AKS-fürt van üzembe helyezve két különböző Azure-régióban (általában párosított régiókban, például Közép-Kanada keleti régiójában vagy az USA 2. keleti régiójában és az USA középső régiójában), amelyek aktívan kiszolgálják a forgalmat.

Ezzel a példaarchitektúrával:

  • Két AKS-fürtöt helyez üzembe külön Azure-régiókban.
  • A normál műveletek során a hálózati forgalom mindkét régió között áthalad. Ha egy régió elérhetetlenné válik, a forgalom automatikusan a kérést kiállító felhasználóhoz legközelebbi régióba irányítja.
  • Minden regionális AKS-példányhoz van egy központi küllős pár. Az Azure Firewall Manager-szabályzatok a különböző régiókban kezelik a tűzfalszabályokat.
  • Az Azure Key Vault minden régióban ki van építve a titkos kulcsok és kulcsok tárolására.
  • Az Azure Front Door terheléselosztja és irányítja a forgalmat egy regionális Azure-alkalmazás átjárópéldányhoz, amely az egyes AKS-fürtök előtt helyezkedik el.
  • A regionális Log Analytics-példányok regionális hálózati metrikákat és diagnosztikai naplókat tárolnak.
  • A számítási feladat tárolórendszerképei egy felügyelt tárolóregisztrációs adatbázisban vannak tárolva. A rendszer egyetlen Azure Container Registryt használ 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.

Ha aktív-aktív üzemi modellt szeretne létrehozni az AKS-ben, hajtsa végre a következő lépéseket:

  1. Két azonos üzembe helyezés létrehozása két különböző Azure-régióban.

  2. Hozzon létre két példányt a webalkalmazásból.

  3. Hozzon létre egy Azure Front Door-profilt a következő erőforrásokkal:

    • Egy végpont.
    • Két forráscsoport, mindegyik egy prioritással rendelkezik.
    • Egy útvonal.
  4. Csak az Azure Front Door-példányból korlátozza a webalkalmazások hálózati forgalmát. 5. Konfigurálja az összes többi háttérbeli Azure-szolgáltatást, például adatbázisokat, tárfiókokat és hitelesítési szolgáltatókat.

  5. Kód üzembe helyezése mindkét webalkalmazásban folyamatos üzembe helyezéssel.

További információ: Ajánlott aktív-aktív magas rendelkezésre állású megoldás áttekintése az AKS-hez.

Aktív-passzív vészhelyreállítás üzembehelyezési modellje

Az aktív-passzív vészhelyreállítási (DR) üzemi modellben két független AKS-fürt van üzembe helyezve két különböző Azure-régióban (általában párosított régiókban, például Kanada középső és keleti régiójában, illetve az USA 2. keleti régiójában és az USA középső régiójában), amelyek aktívan szolgálják a forgalmat. A forgalmat egy adott időpontban csak az egyik fürt szolgálja ki aktívan. A másik fürt ugyanazokat a konfigurációs és alkalmazásadatokat tartalmazza, mint az aktív fürt, de csak akkor fogadja el a forgalmat, ha egy forgalomkezelő irányítja.

Ezzel a példaarchitektúrával:

  • Két AKS-fürtöt helyez üzembe külön Azure-régiókban.
  • A normál műveletek során a hálózati forgalom az elsődleges AKS-fürtre irányítja, amelyet az Azure Front Door konfigurációjában állított be.
    • A prioritást 1–5 között kell beállítani, és 1 a legmagasabb, az 5 pedig a legalacsonyabb.
    • Több fürtöt is beállíthat ugyanarra a prioritási szintre, és megadhatja az egyes fürtök súlyát.
  • Ha az elsődleges fürt elérhetetlenné válik (katasztrófa történik), a forgalom automatikusan az Azure Front Doorban kiválasztott következő régióba kerül.
    • A rendszer működéséhez minden forgalomnak át kell haladnia az Azure Front Door traffic managerén.
  • Az Azure Front Door átirányítja a forgalmat az elsődleges régió Azure-alkalmazás átjárójához (a fürtöt 1. prioritással kell megjelölni). Ha ez a régió meghibásodik, a szolgáltatás átirányítja a forgalmat a prioritási listában szereplő következő fürtre.
    • A szabályok az Azure Front Doorból származnak.
  • Minden regionális AKS-példányhoz központi küllős pár van üzembe helyezve. Az Azure Firewall Manager-szabályzatok a különböző régiókban kezelik a tűzfalszabályokat.
  • Az Azure Key Vault minden régióban ki van építve a titkos kulcsok és kulcsok tárolására.
  • A regionális Log Analytics-példányok regionális hálózati metrikákat és diagnosztikai naplókat tárolnak.
  • A számítási feladat tárolórendszerképei egy felügyelt tárolóregisztrációs adatbázisban vannak tárolva. A rendszer egyetlen Azure Container Registryt használ 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.

Ha aktív-passzív üzemi modellt szeretne létrehozni az AKS-ben, hajtsa végre a következő lépéseket:

  1. Két azonos üzembe helyezés létrehozása két különböző Azure-régióban.

  2. Konfigurálja a másodlagos alkalmazás automatikus skálázási szabályait, hogy az az elsődleges régió inaktívvá válásakor az elsődleges példányszámra skálázható legyen. Inaktív állapotban nem szükséges felskálázni. Ez segít csökkenteni a költségeket.

  3. Hozzon létre két webalkalmazás-példányt, mindegyik fürtön egy-egy példánysal.

  4. Hozzon létre egy Azure Front Door-profilt a következő erőforrásokkal:

    • Egy végpont.
    • Egy elsődleges régióhoz tartozó prioritású forráscsoport.
    • Egy második forráscsoport, amelynek prioritása kettő a másodlagos régióban.
    • Egy útvonal.
  5. A webalkalmazások hálózati forgalmának korlátozása csak az Azure Front Door-példányból.

  6. Konfigurálja az összes többi háttérbeli Azure-szolgáltatást, például adatbázisokat, tárfiókokat és hitelesítési szolgáltatókat.

  7. Kód üzembe helyezése mindkét webalkalmazásban folyamatos üzembe helyezéssel.

További információkért tekintse meg az AKS ajánlott aktív-passzív vészhelyreállítási megoldásának áttekintését.

Passzív hideg feladatátvételi üzemi modell

A passzív-hideg feladatátvételi üzemi modell ugyanúgy van konfigurálva, mint az aktív-passzív vészhelyreállítási üzemi modell, kivéve, hogy a fürtök inaktívak maradnak, amíg a felhasználó nem aktiválja őket katasztrófa esetén. Ezt a megközelítést hatókörön kívülinek tekintjük, mivel az aktív-passzívhoz hasonló konfigurációt foglal magában, de a manuális beavatkozás összetettebbé teszi a fürt aktiválását és a biztonsági mentés elindítását.

Ezzel a példaarchitektúrával:

  • A jobb rugalmasság érdekében két AKS-fürtöt hozhat létre, lehetőleg különböző régiókban vagy zónákban.
  • Ha feladatátvételt kell végrehajtania, aktiválja az üzembe helyezést a forgalom átvételéhez.
  • Ha az elsődleges passzív fürt leáll, manuálisan kell aktiválnia a hideg fürtöt a forgalom átvételéhez.
  • Ezt a feltételt minden alkalommal manuális bemenettel vagy egy Ön által megadott eseménysel kell beállítani.
  • Az Azure Key Vault minden régióban ki van építve a titkos kulcsok és kulcsok tárolására.
  • A regionális Log Analytics-példányok regionális hálózati metrikákat és diagnosztikai naplókat tárolnak az egyes fürtökhöz.

A passzív-hideg feladatátvételi üzemi modell AKS-ben való létrehozásához hajtsa végre a következő lépéseket:

  1. Hozzon létre két azonos üzembe helyezést különböző zónákban/régiókban.
  2. Konfigurálja a másodlagos alkalmazás automatikus skálázási szabályait, hogy az az elsődleges régió inaktívvá válásakor az elsődleges példányszámra skálázható legyen. Inaktív állapotban nem szükséges felskálázni, ami segít csökkenteni a költségeket.
  3. Hozzon létre két webalkalmazás-példányt, mindegyik fürtön egy-egy példánysal.
  4. Konfigurálja az összes többi háttérbeli Azure-szolgáltatást, például adatbázisokat, tárfiókokat és hitelesítési szolgáltatókat.
  5. Adjon meg egy feltételt, amikor a hideg fürtöt aktiválni kell. Szükség esetén használhat terheléselosztót.

További információ: Ajánlott passzív-hideg feladatátvételi megoldás áttekintése az AKS-hez.

Szolgáltatási kvóták és korlátok

Az AKS beállítja az erőforrásokra és szolgáltatásokra vonatkozó alapértelmezett korlátokat és kvótákat, beleértve bizonyos virtuálisgép-termékváltozatok használati korlátozásait is.

Erőforrás Korlát
Fürtök maximális száma előfizetésenként 5000
Megjegyzés: Fürtök elosztása különböző régiókban az Azure API szabályozási korlátainak figyelembe vételével
Fürtenkénti csomópontok maximális száma virtuálisgép-méretezési csoportokkal és standard Load Balancer termékváltozattal 5000 az összes csomópontkészletben
Megjegyzés: Ha fürtenként legfeljebb 5000 csomópontot nem tud skálázni, tekintse meg a nagy méretű fürtök ajánlott eljárásait.
Csomópontkészletenkénti csomópontok maximális száma (Virtuálisgép-méretezési csoportok csomópontkészletei) 1000
Fürtenkénti csomópontkészletek maximális száma 100
Csomópontonkénti podok maximális száma: 1 Kubenet hálózati beépülő modullal Maximum: 250
Alapértelmezett Azure CLI: 110
Alapértelmezett Azure Resource Manager-sablon: 110
Az Azure Portal üzembe helyezése alapértelmezett: 30
Csomópontonkénti podok maximális száma: Azure Container Networking Interface (Azure CNI)1 Maximum: 250
Ajánlott maximális érték Windows Server-tárolókhoz: 110
Alapértelmezett: 30
A Service Mesh (OSM) AKS-bővítmény megnyitása Kubernetes-fürt verziója: AKS által támogatott verziók
OSM-vezérlők fürtönként: 1
Podok OSM-vezérlőnként: 1600
OsM által felügyelt Kubernetes-szolgáltatásfiókok: 160
Maximális terheléselosztású kubernetes-szolgáltatások fürtenként standard Load Balancer termékváltozattal 300
Fürtenkénti csomópontok maximális száma virtuálisgép-rendelkezésre állási csoportokkal és alapszintű Load Balancer termékváltozattal 100

1 Windows Server-tárolónak Azure CNI hálózati beépülő modult kell használnia. A Kubenet nem támogatott a Windows Server-tárolók esetében.

Kubernetes vezérlősík szintje Korlát
Standard csomag A Kubernetes API-kiszolgáló automatikus méretezése a terhelés alapján. Nagyobb vezérlősík-összetevők és API-kiszolgáló-/stb. példányok.
Ingyenes szint Korlátozott erőforrások 50 mutációs és 100 írásvédett hívással rendelkező, gyakorlott kérésekkel . Fürtenként 10 csomópont javasolt csomópontkorlátja. A legjobb kísérletezéshez, tanuláshoz és egyszerű teszteléshez. Éles/kritikus számítási feladatokhoz nem ajánlott.

További információ: AKS szolgáltatáskvóták és korlátok.

Backup

Az Azure Backup támogatja az AKS-fürterőforrások és a fürthöz csatlakoztatott állandó kötetek biztonsági mentését egy biztonsági mentési bővítmény használatával. A Backup-tároló a bővítményen keresztül kommunikál az AKS-fürttel a biztonsági mentési és visszaállítási műveletek végrehajtásához.

További információért tekintse át az alábbi cikkeket: