Azure Kubernetes Service (AKS) leegyszerűsíti a felügyelt Kubernetes-fürtök üzembe helyezését az Azure-ban azáltal, hogy kiteríti a működési többletterhelést az Azure-felhőplatformra. Mivel az AKS egy üzemeltetett Kubernetes-szolgáltatás, az Azure olyan kritikus feladatokat kezel, mint az állapotfigyelés és a karbantartás, valamint a vezérlősík.
Az AKS-fürtök különböző forgatókönyvekben és módokon oszthatók meg több bérlő között. Bizonyos esetekben a különböző alkalmazások ugyanabban a fürtben futtathatók. Más esetekben ugyanazon alkalmazás több példánya is futtatható ugyanabban a megosztott fürtben, egy-egy bérlő esetén. A több-bérlős kifejezés gyakran írja le ezeket a megosztási típusokat. A Kubernetes nem rendelkezik a végfelhasználók és bérlők első osztályú fogalmával. Ennek ellenére számos funkciót kínál a különböző bérlői követelmények kezeléséhez.
Ez a cikk az AKS néhány funkcióját ismerteti, amelyeket több-bérlős rendszerek létrehozásakor használhat. A több-bérlős Kubernetes általános útmutatását és ajánlott eljárásait a Kubernetes dokumentációjában több-bérlős találja.
Több-bérlős típusok
Az AKS-fürtök több bérlőn való megosztásának első lépése a használható minták és eszközök kiértékelése. Általánosságban elmondható, hogy a Kubernetes-fürtökben a több-bérlősség két fő kategóriába tartozik, de számos változat továbbra is lehetséges. A Kubernetes dokumentációja két gyakori használati esetet ír le a több-bérlős használathoz: több csapat és több ügyfél.
Több csapat
A több-bérlősség gyakori formája, ha egy fürtöt több csapat között oszt meg egy szervezeten belül. Minden csapat üzembe helyezhet, monitorozhat és üzemeltethet egy vagy több megoldást. Ezeknek a számítási feladatoknak gyakran kommunikálniuk kell egymással, valamint más belső vagy külső alkalmazásokkal, amelyek ugyanazon a fürtön vagy más üzemeltetési platformokon találhatók.
Ezen túlmenően ezeknek a számítási feladatoknak kommunikálniuk kell a szolgáltatásokkal, például egy relációs adatbázissal, egy NoSQL-adattárral vagy egy üzenetkezelő rendszerrel, amely ugyanabban a fürtben fut, vagy platformként fut, mint egy Szolgáltatás (PaaS) szolgáltatás az Azure-ban.
Ebben a forgatókönyvben a csapatok tagjai gyakran közvetlen hozzáféréssel rendelkeznek a Kubernetes-erőforrásokhoz olyan eszközökkel, mint például a kubectl. Vagy a tagok közvetett hozzáféréssel rendelkeznek a GitOps-vezérlőken keresztül, például Flux és Argo CD, vagy más kiadásautomatizálási eszközökkel.
Erről a forgatókönyvről további információt a Kubernetes dokumentációjában Több csapat című témakörben talál.
Több ügyfél
A több-bérlősség egy másik gyakori formája gyakran egy szolgáltatott szoftver (SaaS) szállítója. Vagy egy szolgáltató egy számítási feladat több példányát futtatja, amelyek külön bérlőnek minősülnek az ügyfeleik számára. Ebben a forgatókönyvben az ügyfelek nem rendelkeznek közvetlen hozzáféréssel az AKS-fürthöz, de csak az alkalmazásukhoz férnek hozzá. Emellett azt sem tudják, hogy az alkalmazás a Kubernetesen fut. A költségoptimalizálás gyakran kritikus fontosságú szempont. A szolgáltatók Kubernetes-szabályzatokat használnak, például erőforráskvótákat és hálózati szabályzatokat, hogy a számítási feladatokat erősen elkülönítse egymástól.
A forgatókönyvről további információt a Kubernetes dokumentációjában Több ügyfél című témakörben talál.
Elkülönítési modellek
A Kubernetes dokumentációjának
A fürtök több-bérlős kihasználtsága alternatívát jelent számos dedikált egybérlős fürt kezelésére. A több-bérlős Kubernetes-fürt operátorainak el kell különíteni a bérlőket egymástól. Ez az elkülönítés minimálisra csökkenti a sérült vagy rosszindulatú bérlők által a fürtben és más bérlőkben okozott károkat.
Ha több felhasználó vagy csapat ugyanazt a fürtöt rögzített számú csomóponttal osztja meg, az egyik csapat több erőforrást is használhat, mint az erőforrások méltányos aránya. A rendszergazdák erőforráskvótákat használhatnak a probléma megoldásához.
Az elkülönítés által biztosított biztonsági szint alapján megkülönböztetheti a puha és a kemény több-bérlősséget.
- A rugalmas több-bérlősség egyetlen vállalaton belül megfelelő, ahol a bérlők különböző csapatok vagy részlegek, amelyek megbíznak egymással. Ebben a forgatókönyvben az elkülönítés célja a számítási feladatok integritásának garantálása, a fürterőforrások különböző belső felhasználói csoportok közötti vezénylálása és a lehetséges biztonsági támadások elleni védelem.
- A kemény több-bérlősség olyan forgatókönyveket ír le, amelyekben a heterogén bérlők nem bíznak egymásban, gyakran biztonsági és erőforrás-megosztási szempontból.
Ha több-bérlős AKS-fürtöt szeretne létrehozni, vegye figyelembe a Kubernetes által biztosított erőforrás-elkülönítés és több-bérlősség rétegeit, többek között a következőket:
- Fürt
- Namespace
- Csomópontkészlet vagy csomópont
- Hüvely
- Konténer
Emellett figyelembe kell vennie a különböző erőforrások több bérlő közötti megosztásának biztonsági következményeit is. Csökkentheti például a fürtben szükséges gépek számát az ugyanazon a csomóponton található különböző bérlők podjainak ütemezésével. Előfordulhat azonban, hogy meg kell akadályoznia bizonyos számítási feladatok szétosztását. Előfordulhat például, hogy nem engedélyezi a szervezeten kívüli nem megbízható kód futtatását ugyanazon a csomóponton, mint a bizalmas adatokat feldolgozó tárolók.
Bár a Kubernetes nem tudja garantálni a bérlők közötti tökéletesen biztonságos elkülönítést, olyan funkciókat kínál, amelyek adott használati esetekhez elegendőek lehetnek. Ajánlott eljárásként minden bérlőt és annak Kubernetes-erőforrásait a névterekre kell különválasztnia. Ezután a Kubernetes szerepköralapú hozzáférés-vezérlési (RBAC) és hálózati szabályzatok használatával kényszerítheti ki a bérlői elkülönítést. Az alábbi diagram például azt a tipikus SaaS-szolgáltatói modellt mutatja be, amely ugyanazon alkalmazás több példányát üzemelteti ugyanazon a fürtön, egy-egy bérlőhöz. Minden alkalmazás külön névtérben található.
Az AKS-sel többféleképpen is tervezhet és építhet több-bérlős megoldásokat. Mindegyik módszer saját kompromisszumokkal rendelkezik az infrastruktúra üzembe helyezése, a hálózati topológia és a biztonság szempontjából. Ezek a módszerek befolyásolják az elkülönítés szintjét, a megvalósítási erőfeszítéseket, a működési összetettséget és a költségeket. A bérlői elkülönítést a vezérlő- és adatsíkokon alkalmazhatja a követelményeknek megfelelően.
Vezérlősík elkülönítése
Ha elkülönítéssel rendelkezik a vezérlősík szintjén, garantálhatja, hogy a különböző bérlők nem férhetnek hozzá egymás erőforrásaihoz, például podokhoz és szolgáltatásokhoz. Emellett nem befolyásolhatják más bérlők alkalmazásainak teljesítményét. További információ: Vezérlősík elkülönítési a Kubernetes dokumentációjában. Az elkülönítés vezérlési sík szintjén történő megvalósításának legjobb módja, ha elkülöníti az egyes bérlők számítási feladatait és Kubernetes-erőforrásait egy külön névtérbe.
A Kubernetes dokumentációjának
- A névterek lehetővé teszik, hogy különböző bérlői számítási feladatok létezhessenek a saját virtuális munkaterületükön anélkül, hogy ez hatással lehet egymás munkájára. A szervezeten belüli különálló csapatok névterek használatával elkülöníthetik a projektjeiket egymástól, mivel ugyanazokat az erőforrásneveket használhatják különböző névterekben anélkül, hogy a nevek átfedésbe kerülnének.
- RBAC-szerepkörök és szerepkörkötések névtér-hatókörű erőforrások, amelyekkel a csapatok korlátozhatják a bérlői felhasználókat és folyamatokat, hogy csak a névterükben férhessenek hozzá az erőforrásokhoz és szolgáltatásokhoz. A különböző csapatok szerepköröket határozhatnak meg az engedélyek vagy képességek egyetlen név alatt történő csoportosításához. Ezután hozzárendelik ezeket a szerepköröket a felhasználói fiókokhoz és a szolgáltatásfiókokhoz, hogy csak az engedélyezett identitások férhessenek hozzá egy adott névtér erőforrásaihoz.
- cpu-hoz és memóriához erőforráskvóták névtérrel rendelkező objektumok. A Teams felhasználhatja őket annak biztosítására, hogy az azonos fürtön osztozó számítási feladatok erősen el legyenek különítve a rendszererőforrás-használattól. Ezzel a módszerrel biztosítható, hogy minden külön névtérben futó bérlőalkalmazás rendelkezzen a futtatáshoz szükséges erőforrásokkal, és elkerülje zajos szomszédproblémákat, ami hatással lehet az azonos fürtöt használó többi bérlőalkalmazásra.
- hálózati szabályzatok olyan névtérbeli objektumok, amelyeket a csapatok alkalmazhatnak annak kikényszerítéséhez, hogy egy adott bérlőalkalmazáshoz mely hálózati forgalom engedélyezett. A hálózati házirendek használatával elkülönítheti az azonos fürtön osztozó különböző számítási feladatokat hálózati szempontból.
- A különböző névterekben futó csapatalkalmazások különböző szolgáltatásfiókokat használhatnak az ugyanazon fürtben, külső alkalmazásokban vagy felügyelt szolgáltatásokban lévő erőforrások eléréséhez.
- Névterek használatával javíthatja a vezérlősík szintjén a teljesítményt. Ha egy megosztott fürt számítási feladatai több névtérbe vannak rendezve, a Kubernetes API-ban kevesebb elem kereshető a műveletek futtatásakor. Ez a szervezet csökkentheti az API-kiszolgáló felé irányuló hívások késését, és növelheti a vezérlősík átviteli sebességét.
A névtér szintjén történő elkülönítésről a Kubernetes dokumentációjában található alábbi forrásokban talál további információt:
Adatsík elkülönítése
Az adatsíkok elkülönítése biztosítja, hogy a különböző bérlők podjai és számítási feladatai megfelelően el legyenek különítve egymástól. További információ: Adatsík-elkülönítési a Kubernetes dokumentációjában.
Hálózatelkülönítés
Amikor modern, mikroszolgáltatás-alapú alkalmazásokat futtat a Kubernetesben, gyakran szeretné szabályozni, hogy mely összetevők kommunikálhatnak egymással. Alapértelmezés szerint az AKS-fürtök összes podja korlátozás nélkül küldhet és fogadhat forgalmat, beleértve az azonos fürtöt használó egyéb alkalmazásokat is. A biztonság javítása érdekében hálózati szabályokat határozhat meg a forgalom szabályozásához. A hálózati házirend egy Kubernetes-specifikáció, amely hozzáférési szabályzatokat határoz meg a podok közötti kommunikációhoz. A hálózati házirendek használatával elkülönítheti az azonos fürtöt használó bérlőalkalmazások közötti kommunikációt.
Az AKS kétféleképpen valósítja meg a hálózati szabályzatokat:
- Az Azure rendelkezik a hálózati szabályzatok, úgynevezett Azure-hálózati szabályzatok implementációjával.
- Calico hálózati szabályzatok egy nyílt forráskódú hálózati és hálózati biztonsági megoldás, amelyet Tigeraalapított.
Mindkét implementáció Linux iptables használatával kényszeríti ki a megadott szabályzatokat. A hálózati szabályzatok engedélyezett és nem engedélyezett IP-párokra vannak lefordítva. Ezek a párok ezután iptables szűrőszabályokként vannak beprogramozva. Az Azure hálózati szabályzatait csak az Azure CNI hálózati beépülő modullal konfigurált AKS-fürtökkel használhatja. A Calico hálózati szabályzatai azonban Azure CNI- és kubenetis támogatnak. További információ: Podok közötti adatforgalom védelme hálózati házirendek használatával az Azure Kubernetes Service.
További információ: Hálózatelkülönítési a Kubernetes dokumentációjában.
Tárolók elkülönítése
Az Azure számos felügyelt, PaaS-adatadattárat biztosít, például Azure SQL Database és Azure Cosmos DB, valamint egyéb tárolási szolgáltatásokat, amelyeket állandó kötetként a számítási feladatokhoz. A megosztott AKS-fürtön futó bérlői alkalmazások oszthatnak meg egy adatbázist vagy fájltárolót, vagy használhatják egy dedikált adattárat és tárolási erőforrást. A több-bérlős forgatókönyvekben az adatok kezelésének különböző stratégiáiról és megközelítéséről további információt A több-bérlős megoldásokban a tárolás és az adatok architekturális megközelítései.
Az AKS-en futó számítási feladatok állandó köteteket is használhatnak az adatok tárolására. Az Azure-ban állandó köteteket az Azure Storage által támogatott Kubernetes-erőforrásokként. Manuálisan is létrehozhat adatköteteket, és közvetlenül podokhoz rendelheti őket, vagy az AKS automatikusan létrehozhatja őket állandó kötet jogcímekhasználatával. Az AKS beépített tárolási osztályokat biztosít az Azure Disks, az Azure Files
Ha az AKS beépített tárosztályok nem megfelelőek egy vagy több bérlő számára, egyéni tárosztályokat hozhat létre a különböző bérlők igényeinek megfelelően. Ezek a követelmények közé tartozik a kötetméret, a tárolási termékváltozat, a szolgáltatásiszint-szerződés (SLA), a biztonsági mentési szabályzatok és a tarifacsomag.
Konfigurálhat például egy egyéni tárosztályt minden bérlőhöz. Ezután címkéket alkalmazhat a névtérben létrehozott állandó kötetekre a költségeik visszaszámlázásához. További információ: Azure-címkék használata az AKS-.
További információ: Storage-elkülönítési a Kubernetes dokumentációjában.
Csomópontelkülönítés
A bérlői számítási feladatokat úgy konfigurálhatja, hogy külön ügynökcsomópontokon fussanak, így elkerülheti zajos szomszédproblémákat, és csökkentheti az információk felfedésének kockázatát. Az AKS-ben létrehozhat egy külön fürtöt vagy csak egy dedikált csomópontkészletet az elkülönítésre, a biztonságra, a jogszabályi megfelelőségre és a teljesítményre vonatkozó szigorú követelményekkel rendelkező bérlők számára.
A , tűrések, csomópontfeliratok, csomópontválasztókés csomópont-affinitás használatával korlátozhatja, hogy a bérlők podjai csak bizonyos csomópontokon vagy csomópontkészleteken fussanak.
Az AKS általában különböző szinteken biztosítja a számítási feladatok elkülönítését, például:
- A rendszermag szintjén a bérlői számítási feladatokat egyszerű virtuális gépeken (virtuális gépeken) futtatva megosztott ügynökcsomópontokon, valamint Pod Sandboxing használatával, Kata-tárolókalapján.
- Fizikai szinten a bérlői alkalmazások dedikált fürtökön vagy csomópontkészleteken való üzemeltetésével.
- Hardverszinten a bérlői számítási feladatok Dedikált Azure-gazdagépeken való futtatásával, amelyek garantálják, hogy az ügynökcsomópont virtuális gépei dedikált fizikai gépeket futtassanak. A hardveres elkülönítés biztosítja, hogy a dedikált gazdagépeken ne legyenek más virtuális gépek, ami további elkülönítési réteget biztosít a bérlői számítási feladatok számára.
Ezeket a technikákat kombinálhatja. Futtathat például bérlőnkénti fürtöket és csomópontkészleteket egy azure-beli dedikált gazdagépcsoportban, a számítási feladatok elkülönítéséhez és a fizikai elkülönítéshez hardverszinten. Létrehozhat megosztott vagy bérlőnkénti csomópontkészleteket is, amelyek támogatják Federal Information Process Standard (FIPS), bizalmas virtuális gépeket, vagy gazdagépalapú titkosítási.
Csomópontelkülönítéssel egyszerűen társíthatja és felszámíthatja a csomópontok vagy csomópontkészletek egy csoportjának költségeit egyetlen bérlőhöz. Ez szigorúan a megoldás által elfogadott bérlői modellhez kapcsolódik.
További információ: csomópontelkülönítési a Kubernetes dokumentációjában.
Bérlői modellek
Az AKS további csomópontelkülönítési és bérlői modelleket biztosít.
Automatizált egybérlős üzemelő példányok
Egy automatizált egybérlős üzembehelyezési modellben minden bérlőhöz külön erőforráskészletet kell üzembe helyeznie, az alábbi példában látható módon:
Minden bérlői számítási feladat dedikált AKS-fürtön fut, és különböző Azure-erőforrásokhoz fér hozzá. Az ezzel a modellel létrehozott több-bérlős megoldások általában széles körben használják az infrastruktúrát kódként (IaC). Például Bicep, Azure Resource Manager, Terraform, vagy az Azure Resource Manager REST API-k segítenek kezdeményezni és koordinálni a bérlő által dedikált erőforrások igény szerinti üzembe helyezését. Ezt a megközelítést akkor használhatja, ha minden ügyfél számára teljesen különálló infrastruktúrát kell kiépítenie. Az üzembe helyezés tervezésekor fontolja meg a Üzembehelyezési bélyegek mintahasználatát.
előnyök:
- Ennek a megközelítésnek az egyik fő előnye, hogy az egyes bérlői AKS-fürtök API-kiszolgálója külön van. Ez a megközelítés teljes elkülönítést biztosít a bérlők között a biztonsági, hálózati és erőforrás-felhasználási szinttől. Azok a támadók, amelyek csak az egyetlen bérlőhöz tartozó tárolókhoz és csatlakoztatott kötetekhez férnek hozzá, hozzáférnek a tárolókhoz és a csatlakoztatott kötetekhez. A teljes elkülönítésű bérlői modell kritikus fontosságú néhány olyan ügyfél számára, aki magas szabályozási megfelelőségi többletterheléssel rendelkezik.
- A bérlők valószínűleg nem befolyásolják egymás rendszerteljesítményét, így elkerülheti zajos szomszédproblémákat. Ez a szempont az API-kiszolgálóra irányuló forgalmat is magában foglalja. Az API-kiszolgáló egy megosztott, kritikus összetevő minden Kubernetes-fürtben. Az egyéni vezérlők, amelyek nem szabályozatlan, nagy mennyiségű forgalmat generálnak az API-kiszolgálóval szemben, a fürt instabilitását okozhatják. Ez az instabilitás kéréshibákhoz, időtúllépésekhez és API-újrapróbálkozási viharokhoz vezet. Az üzemidejű SLA funkcióval skálázhatja fel az AKS-fürt vezérlősíkját a forgalmi igények kielégítése érdekében. A dedikált fürtök kiépítése azonban jobb megoldás lehet azoknak az ügyfeleknek, akik a számítási feladatok elkülönítése terén erős követelményeket támasztanak.
- A frissítéseket és módosításokat fokozatosan helyezheti üzembe a bérlők között, ami csökkenti a rendszerszintű kimaradás valószínűségét. Az Azure-költségek egyszerűen visszaszámlázhatók a bérlőknek, mivel minden erőforrást egyetlen bérlő használ.
kockázatok:
- A költséghatékonyság alacsony, mivel minden bérlő dedikált erőforráskészletet használ.
- A folyamatos karbantartás valószínűleg időigényes, mert több AKS-fürtön kell megismételnie a karbantartási tevékenységeket, egy-egy bérlő esetében. Fontolja meg az üzemeltetési folyamatok automatizálását és a változások fokozatos alkalmazását a környezeteken keresztül. Az egyéb üzembehelyezési műveletek, például a teljes tulajdon jelentési és elemzési műveletei is hasznosak lehetnek. Győződjön meg arról, hogy több üzemelő példány adatainak lekérdezését és manipulálására tervezi.
Teljes mértékben több-bérlős üzemelő példányok
Egy teljes mértékben több-bérlős üzemelő példányban egyetlen alkalmazás szolgálja ki az összes bérlő kéréseit, és az összes Azure-erőforrás meg van osztva, beleértve az AKS-fürtöt is. Ebben az összefüggésben csak egy infrastruktúrával rendelkezik az üzembe helyezéshez, a monitorozáshoz és a karbantartáshoz. Az összes bérlő használja az erőforrást az alábbi ábrán látható módon:
előnyök:
- Ez a modell a megosztott összetevőkkel rendelkező megoldások alacsonyabb költségei miatt vonzó. Ha ezt a bérlői modellt használja, előfordulhat, hogy egy nagyobb AKS-fürtöt kell üzembe helyeznie, és magasabb termékváltozatot kell bevezetnie minden megosztott adatadat-tárházhoz. Ezek a módosítások segítenek fenntartani a bérlői erőforrások, például az adattárak által generált forgalmat.
kockázatok:
- Ebben az összefüggésben egyetlen alkalmazás kezeli a bérlők összes kérését. Olyan biztonsági intézkedéseket kell megterveznie és implementálnia, amelyek megakadályozzák, hogy a bérlők hívásokkal elárasztsák az alkalmazást. Ezek a hívások lelassíthatják a teljes rendszert, és hatással lehetnek az összes bérlőre.
- Ha a forgalmi profil nagy mértékben változó, az AKS-fürt automatikus skálázását úgy kell konfigurálnia, hogy a podok és az ügynökcsomópontok száma változik. A konfiguráció alapja a rendszererőforrás-használat, például a PROCESSZOR és a memória. Másik lehetőségként a podok és fürtcsomópontok számának horizontális felskálázása és skálázása egyéni metrikák alapján. Használhatja például a függőben lévő kérések számát vagy egy olyan külső üzenetkezelő rendszer metrikáit, amelyek Kubernetes-alapú eseményvezérelt automatikus skálázót (KEDA) használnak.
- Győződjön meg arról, hogy az egyes bérlők adatait különválasztja, és biztonsági intézkedéseket alkalmaz a különböző bérlők közötti adatszivárgás elkerülése érdekében.
- Ügyeljen arra, hogy nyomon kövesse és társítsa az Azure-költségeket az egyes bérlőkhöz a tényleges használatuk alapján. A nem Microsoft-megoldások, például kubecost, segíthetnek a különböző csapatok és bérlők költségeinek kiszámításában és lebontásában.
- A karbantartás egyszerűbb lehet egyetlen üzemelő példány esetében, mivel csak egy Azure-erőforráskészletet kell frissítenie, és egyetlen alkalmazást kell fenntartania. Ugyanakkor kockázatosabb is lehet, mert az infrastruktúra vagy az alkalmazás összetevőinek bármilyen módosítása hatással lehet a teljes ügyfélbázisra.
- Érdemes megfontolni a méretezési korlátozásokat is. Nagyobb valószínűséggel éri el az Azure erőforrás-méretezési korlátait, ha megosztott erőforráskészlettel rendelkezik. Az erőforráskvóta-korlát elérése érdekében a bérlőket több Azure-előfizetés között is eloszthatja.
Horizontálisan particionált üzemelő példányok
Másik lehetőségként fontolja meg a több-bérlős Kubernetes-alkalmazás horizontális particionálását. Ez a módszer az összes bérlőben megosztja a megoldás egyes összetevőit, és dedikált erőforrásokat helyez üzembe az egyes bérlők számára. Létrehozhat például egyetlen több-bérlős Kubernetes-alkalmazást, majd létrehozhat egy-egy adatbázist minden bérlőhöz, ahogy az ábrán látható:
előnyök:
- A horizontálisan particionált üzemelő példányok segíthetnek enyhíteni zajos szomszédproblémákat. Ezt a megközelítést akkor érdemes megfontolni, ha azt állapítja meg, hogy a Kubernetes-alkalmazás forgalmi terhelésének nagy része az egyes bérlők számára külön üzembe helyezhető összetevők miatt van. Előfordulhat például, hogy az adatbázisok elnyelik a rendszer terhelésének nagy részét, mert a lekérdezési terhelés magas. Ha egyetlen bérlő nagy számú kérést küld a megoldásnak, előfordulhat, hogy az adatbázis teljesítménye negatívan befolyásolja, de más bérlők adatbázisai és megosztott összetevői, például az alkalmazásszint nem változnak.
kockázatok:
- Vízszintesen particionált üzembe helyezés esetén továbbra is figyelembe kell vennie az összetevők automatizált üzembe helyezését és felügyeletét, különösen azokat az összetevőket, amelyeket egyetlen bérlő használ.
- Előfordulhat, hogy ez a modell nem biztosítja a szükséges elkülönítési szintet azoknak az ügyfeleknek, akik belső szabályzat vagy megfelelőségi okokból nem oszthatnak meg erőforrásokat más bérlőkkel.
Függőlegesen particionált üzemelő példányok
Az egy-bérlős és a teljes mértékben több-bérlős modellek előnyeit kihasználhatja egy hibrid modellel, amely vertikálisan particionál bérlőket több AKS-fürtön vagy csomópontkészleten. Ez a megközelítés a következő előnyöket nyújtja az előző két bérleti modellel szemben:
- Használhatja az egybérlős és a több-bérlős üzemelő példányok kombinációját. Előfordulhat például, hogy az ügyfelek többsége több-bérlős infrastruktúrán osztozik egy AKS-fürtön és -adatbázison. Egybérlős infrastruktúrát is üzembe helyezhet azokon az ügyfeleken, akik nagyobb teljesítményt és elkülönítést igényelnek.
- Bérlőket több regionális AKS-fürtön is üzembe helyezhet, akár különböző konfigurációkkal is. Ez a technika akkor a leghatékonyabb, ha a bérlők különböző földrajzi helyeken vannak elosztva.
A bérlői modell különböző változatait implementálhatja. Választhatja például, hogy a több-bérlős megoldást különböző szolgáltatási szinteken, más költséggel kínálja. A tarifamodell több termékváltozatot is biztosít, amelyek mindegyike növekményes teljesítményt és elkülönítést biztosít az erőforrásmegosztás, a teljesítmény, a hálózat és az adatelkülönítés szempontjából. Vegye figyelembe a következő szinteket:
- Alapszint: A bérlői kérelmeket egyetlen, több-bérlős Kubernetes-alkalmazás szolgálja ki, amely más bérlőkkel van megosztva. Az adatok tárolása egy vagy több adatbázisban történik, amelyekben az összes alapszintű bérlő osztozik.
- Standard szint: A bérlői kérelmeket egy külön névtérben futó dedikált Kubernetes-alkalmazás szolgálja ki, amely elkülönítési határokat biztosít a biztonság, a hálózatkezelés és az erőforrás-felhasználás szempontjából. Minden bérlői alkalmazás, amely mindegyik bérlőhöz tartozik, ugyanazt az AKS-fürtöt és csomópontkészletet használja más standard szintű ügyfelekkel.
- Prémium szint: A bérlői alkalmazás dedikált csomópontkészletben vagy AKS-fürtön fut, hogy magasabb SLA-t, jobb teljesítményt és nagyobb fokú elkülönítést garantáljon. Ez a szint rugalmas költségmodellt biztosíthat a bérlőalkalmazást üzemeltető ügynökcsomópontok száma és termékváltozata alapján. A dedikált fürtök vagy csomópontkészletek alternatív megoldásaként használhatja a Pod-védőfalat a különböző bérlői számítási feladatok elkülönítéséhez.
Az alábbi ábra egy olyan forgatókönyvet mutat be, amelyben az A és b bérlők megosztott AKS-fürtön futnak, míg a C bérlő egy külön AKS-fürtön fut.
Az alábbi diagram egy olyan forgatókönyvet mutat be, amelyben az A és b bérlők ugyanazon a csomópontkészleten futnak, míg a C bérlő egy dedikált csomópontkészleten fut.
Ez a modell különböző SLA-kat is kínálhat különböző szintekhez. Az alapszint például 99,9-% üzemidőt kínálhat, a standard szint 99,95% üzemidőt, a prémium szint pedig 99,99% üzemidőt kínálhat. A magasabb SLA-t magasabb rendelkezésre állási célokat engedélyező szolgáltatások és szolgáltatások használatával implementálhatja.
előnyök:
- Mivel továbbra is megosztja az infrastruktúrát, továbbra is élvezheti a megosztott több-bérlős üzemelő példányok költségeinek egy részét. Több alapszintű és standard szintű bérlőalkalmazásban megosztott fürtöket és csomópontkészleteket is üzembe helyezhet, amelyek kevésbé költséges virtuálisgép-méretet használnak az ügynökcsomópontokhoz. Ez a megközelítés jobb sűrűséget és költségmegtakarítást garantál. A prémium szintű ügyfelek számára magasabb virtuálisgép-mérettel és maximális számú podreplikával és csomóponttal rendelkező AKS-fürtöket és csomópontkészleteket helyezhet üzembe magasabb áron.
- Rendszerszolgáltatásokat futtathat, például CoreDNS, Konnectivityvagy Azure Application Gateway bejövőforgalom-vezérlő, dedikált rendszermódú csomópontkészletben. A , tűrések, csomópontfeliratok, csomópontválasztók, valamint csomópont-affinitás használatával futtathat bérlőalkalmazást egy vagy több felhasználói módú csomópontkészleten.
- Használhatja , tűréseket, csomópontfeliratokat, csomópontválasztókat, és csomópont-affinitás használhatja a megosztott erőforrások futtatásához. Használhat például egy bejövőforgalom-vezérlőt vagy üzenetkezelő rendszert egy dedikált csomópontkészleten, amely rendelkezik egy adott virtuálisgép-mérettel, automatikus skálázási beállításokkal és rendelkezésre állási zónák támogatásával.
kockázatok:
- A Kubernetes-alkalmazást úgy kell megterveznie, hogy támogassa a több-bérlős és az egybérlős üzemelő példányokat is.
- Ha azt tervezi, hogy engedélyezi az infrastruktúra közötti migrálást, meg kell fontolnia, hogyan migrálja az ügyfeleket egy több-bérlős üzemelő példányból a saját egybérlős üzemelő példányukba.
- Több AKS-fürt monitorozásához és kezeléséhez egységes stratégiára és egyetlen üvegpanelre vagy egy nézőpontra van szükség.
Automatikus skálázás
A bérlői alkalmazások által generált forgalomigénynek megfelelően engedélyezheti a fürt automatikus skálázási az AKS ügynökcsomópontjainak skálázásához. Az automatikus skálázás a következő körülmények között segít a rendszerek válaszkészségében:
- A forgalom terhelése adott munkaidőben vagy az év időszakában nő.
- A bérlői vagy megosztott nagy terhelések egy fürtön vannak üzembe helyezve.
- Az ügynökcsomópontok elérhetetlenné válnak egy rendelkezésre állási zóna kimaradása miatt.
Ha engedélyezi az automatikus skálázást egy csomópontkészlethez, meg kell adnia a csomópontok minimális és maximális számát a várt számítási feladatok méretétől függően. A csomópontok maximális számának konfigurálásával elegendő helyet biztosíthat a fürt összes bérlői podjához, függetlenül attól, hogy milyen névtérben futnak.
A forgalom növekedésekor a fürt automatikus skálázása új ügynökcsomópontokat ad hozzá, hogy a podok ne kerülhessenek függő állapotba az erőforráshiány, például a CPU és a memória miatt.
Ha a terhelés csökken, a fürt automatikus skálázása csökkenti a csomópontkészlet ügynökcsomópontjainak számát a megadott határok alapján, ami segít csökkenteni az üzemeltetési költségeket.
A podok automatikus skálázásával automatikusan skálázhatja a podokat az erőforrásigények alapján. HorizontalPodAutoscaler automatikusan skálázza a podreplikák számát a processzor- vagy memóriakihasználtság vagy egyéni metrikák alapján. A KEDAhasználatával bármilyen tároló skálázható a Kubernetesben a külső rendszerekből ( például Azure Event Hubs vagy Azure Service Bus) származó események száma alapján, amelyet a bérlői alkalmazások használnak.
függőleges pod automatikus skálázási (VPA) lehetővé teszi a podok hatékony erőforrás-kezelését. A podokhoz lefoglalt PROCESSZOR és memória módosításával a VPA segít csökkenteni a bérlői alkalmazások futtatásához szükséges csomópontok számát. Kevesebb csomópont használata csökkenti a teljes tulajdonjogi költséget, és segít elkerülni zajos szomszédproblémákat.
Rendeljen kapacitásfoglalási csoportokat csomópontkészletekhez, hogy jobb erőforrás-lefoglalást és elkülönítést biztosítson a különböző bérlők számára.
Fenntartás
A fürt- vagy csomópontkészlet-frissítések során a bérlői alkalmazásokat érintő állásidő kockázatának csökkentése érdekében ütemezze az AKS-t tervezett karbantartási csúcsidőn kívül. Heti karbantartási időszakok ütemezése a bérlői alkalmazásokat és csomópontkészleteket futtató AKS-fürtök vezérlősíkjának frissítéséhez a számítási feladatok hatásának minimalizálása érdekében. A fürt egy vagy több heti karbantartási időszakát ütemezheti egy adott nap vagy időtartomány megadásával. Minden karbantartási művelet az ütemezett ablakok alatt történik.
Biztonság
Az alábbi szakaszok a több-bérlős megoldások AKS-sel való biztonsági ajánlott eljárásait ismertetik.
Fürthozzáférés
Ha egy AKS-fürtöt több csapat között oszt meg egy szervezeten belül, implementálnia kell a minimális jogosultsági elvét a különböző bérlők egymástól való elkülönítéséhez. Különösen meg kell győződnie arról, hogy a felhasználók csak a Kubernetes-névterekhez és -erőforrásokhoz férnek hozzá, amikor olyan eszközöket használnak, mint kubectl, Helm, Fluxvagy Argo CD.
Az AKS-hitelesítéssel és engedélyezéssel kapcsolatos további információkért tekintse meg az alábbi cikkeket:
- Hozzáférési és identitásbeállítások az AKS-
- AKS által felügyelt Microsoft Entra integrációs
- Kubernetes szerepköralapú hozzáférés-vezérlése Microsoft Entra-azonosítóval az AKS-ben
Számítási feladatok identitása
Ha több bérlői alkalmazást üzemeltet egyetlen AKS-fürtön, és minden alkalmazás külön névtérben található, akkor minden számítási feladatnak egy másik Kubernetes-szolgáltatásfiókot kell használnia és hitelesítő adatokat az alsóbb rétegbeli Azure-szolgáltatások eléréséhez. A szolgáltatásfiókok a Kubernetes egyik elsődleges felhasználói típusa. A Kubernetes API szolgáltatásfiókokat tárol és kezel. A szolgáltatásfiók hitelesítő adatai Kubernetes-titkos kulcsként vannak tárolva, így az engedélyezett podok használhatják őket az API-kiszolgálóval való kommunikációra. A legtöbb API-kérés hitelesítési jogkivonatot biztosít egy szolgáltatásfiókhoz vagy egy normál felhasználói fiókhoz.
Az AKS-fürtökön üzembe helyezendő bérlői számítási feladatok a Microsoft Entra alkalmazás hitelesítő adataival férhetnek hozzá a Microsoft Entra azonosítóval védett erőforrásaihoz, például az Azure Key Vaulthoz és a Microsoft Graphhoz. KubernetesHez készült Microsoft Entra számítási feladat azonosítója integrálható a Kubernetes natív képességeivel, hogy összefésüljenek bármely külső identitásszolgáltatóval.
Pod-védőfal
Az AKS tartalmaz egy Pod-védőfalas nevű mechanizmust, amely elkülönítési határt biztosít a tárolóalkalmazás és a tároló gazdagép megosztott kernele és számítási erőforrásai között, például a PROCESSZOR, a memória és a hálózatkezelés között. A Pod sandboxing kiegészíti az egyéb biztonsági intézkedéseket vagy adatvédelmi vezérlőket, amelyek segítenek a bérlői számítási feladatoknak a bizalmas információk védelmében, valamint a szabályozási, iparági vagy szabályozási megfelelőségi követelményeknek való megfelelésben, például a Payment Card Industry Data Security Standard (PCI DSS), a Nemzetközi Szabványügyi Szervezet (ISO) 27001 és az egészségbiztosítás hordozhatóságáról és elszámoltathatóságáról szóló törvényben (HIPAA).
Ha külön fürtökön vagy csomópontkészleteken helyez üzembe alkalmazásokat, határozottan elkülönítheti a különböző csapatok vagy ügyfelek bérlői számítási feladatait. Több fürt és csomópontkészlet használata számos szervezet és SaaS-megoldás elkülönítési követelményeinek megfelelő lehet, de vannak olyan helyzetek, amikor egy megosztott virtuálisgép-csomópontkészletekkel rendelkező fürt hatékonyabb. Használhat például egyetlen fürtöt, ha nem megbízható és megbízható podokat futtat ugyanazon a csomóponton, vagy ugyanazon a csomóponton közösen helyezi el a DaemonSets és a kiemelt tárolókat a gyorsabb helyi kommunikáció és funkcionális csoportosítás érdekében. Pod-védőfalas segíthet a bérlői alkalmazások szigorú elkülönítésében ugyanazon a fürtcsomóponton anélkül, hogy külön fürtökben vagy csomópontkészletekben kellene futtatnia ezeket a számítási feladatokat. Más módszerek megkövetelik a kód újrafordítását, vagy más kompatibilitási problémákat okozhatnak, de az AKS pod-tesztkörnyezete bármilyen nem módosított tárolót futtathat a fokozott biztonsági virtuálisgép-határokon belül.
Az AKS pod-tesztkörnyezete
További információ:
Dedikált Azure-gazdagép
Dedikált Azure-gazdagép olyan szolgáltatás, amely egyetlen Azure-előfizetéshez dedikált fizikai kiszolgálókat biztosít, és hardveres elkülönítést biztosít fizikai kiszolgálói szinten. Ezeket a dedikált gazdagépeket kiépítheti egy régióban, a rendelkezésre állási zónában és a tartalék tartományban, és a virtuális gépeket közvetlenül a kiépített gazdagépekre helyezheti.
Az Azure Dedikált gazdagép AKS-sel való használatának számos előnye van, például:
A hardveres elkülönítés biztosítja, hogy a dedikált gazdagépeken ne legyenek más virtuális gépek, ami további elkülönítési réteget biztosít a bérlői számítási feladatok számára. A dedikált gazdagépek ugyanabban az adatközpontban vannak üzembe helyezve, és ugyanazon a hálózaton és a mögöttes tárolási infrastruktúrán osztoznak, mint más, nem izolált gazdagépek.
Az Azure Dedikált gazdagép szabályozza az Azure platform által kezdeményezett karbantartási eseményeket. A karbantartási időszak kiválasztásával csökkentheti a szolgáltatásokra gyakorolt hatást, és gondoskodhat a bérlői számítási feladatok rendelkezésre állásáról és adatvédettségéről.
Az Azure Dedikált gazdagép segíthet az SaaS-szolgáltatóknak annak biztosításában, hogy a bérlői alkalmazások megfeleljenek a bizalmas információk védelmére vonatkozó szabályozási, iparági és szabályozási megfelelőségi követelményeknek. További információ: Dedikált Azure-gazdagép hozzáadása AKS-fürthöz.
Karpenter
Karpenter egy nyílt forráskódú csomópont-életciklus felügyeleti projekt, amely a Kubernetes számára készült. A Karpenter Kubernetes-fürthöz való hozzáadása javíthatja a számítási feladatok futtatásának hatékonyságát és költségeit a fürtön. Karpenter figyeli azokat a podokat, amelyeket a Kubernetes ütemezője ütemezhetetlennek jelöl. Emellett dinamikusan kiépít és kezel olyan csomópontokat, amelyek megfelelnek a pod követelményeinek.
A Karpenter részletes vezérlést biztosít a csomópontok kiépítése és a számítási feladatok felügyelt fürtön való elhelyezése felett. Ez a vezérlő javítja a több-bérlősséget az erőforrás-kiosztás optimalizálásával, az egyes bérlői alkalmazások elkülönítésének biztosításával és a működési költségek csökkentésével. Ha több-bérlős megoldást hoz létre az AKS-en, a Karpenter hasznos képességeket biztosít a különböző bérlők támogatásához szükséges különböző alkalmazáskövetelmények kezeléséhez. Előfordulhat például, hogy egyes bérlői alkalmazások GPU-ra optimalizált csomópontkészleteken futnak, mások pedig memóriaoptimalizált csomópontkészleteken futnak. Ha az alkalmazás alacsony késést igényel a tároláshoz, a Karpenter használatával jelezheti, hogy egy podhoz egy adott rendelkezésre állási zónában futó csomópont szükséges, hogy a tárolási és az alkalmazásszintet áthelyezhesse.
Az AKS lehetővé teszi a csomópontok automatikus üzembe helyezését az AKS-fürtökön a Karpenteren keresztül. A legtöbb felhasználónak a csomópont automatikus fejlesztési módjával kell engedélyeznie a Karpentert felügyelt bővítményként. További információ: csomópont automatikusan történő üzembe helyezése. Ha speciálisabb testreszabásra van szüksége, választhatja a Karpenter önkiszolgáló üzemeltetését. További információ: AKS Karpenter-szolgáltató.
Bizalmas virtuális gépek
A bizalmas virtuális gépek használatával hozzáadhat egy vagy több csomópontkészletet az AKS-fürthöz a bérlők szigorú elkülönítési, adatvédelmi és biztonsági követelményeinek kezelése érdekében. bizalmas virtuális gépek hardveralapú megbízható végrehajtási környezetet használnak. AMD Secure Encrypted Virtualization – Secure Nested Paging (SEV-SNP) bizalmas virtuális gépek megtagadják a hipervizor és más gazdagépfelügyeleti kód hozzáférését a virtuális gépek memóriájához és állapotához, ami védelmi réteget és részletes védelmet biztosít az operátorok hozzáférése ellen. További információ: Bizalmas virtuális gépek használata egy AKS-fürtben.
Federal Information Process Standards (FIPS)
FIPS 140-3 egy amerikai kormányzati szabvány, amely meghatározza az informatikai termékek és rendszerek titkosítási moduljainak minimális biztonsági követelményeit. Ha engedélyezi FIPS-megfelelőséget az AKS-csomópontkészletekhez, javíthatja a bérlői számítási feladatok elkülönítését, adatvédelmet és biztonságot. FIPS megfelelőség biztosítja az érvényesített titkosítási modulok használatát a titkosításhoz, kivonatoláshoz és más, biztonsággal kapcsolatos műveletekhez. A FIPS-kompatibilis AKS-csomópontkészletekkel robusztus titkosítási algoritmusok és mechanizmusok használatával megfelelhet a szabályozási és iparági megfelelőségi követelményeknek. Az Azure dokumentációt nyújt az AKS-csomópontkészletekhez készült FIPS engedélyezéséről, amely lehetővé teszi a több-bérlős AKS-környezetek biztonsági helyzetének megerősítését. További információ: FIPS engedélyezése az AKS-csomópontkészletekhez.
Saját kulcsok (BYOK) használata Azure-lemezekkel
Az Azure Storage titkosítja egy inaktív tárfiók összes adatát, beleértve az AKS-fürt operációs rendszerét és adatlemezeit is. Alapértelmezés szerint az adatok a Microsoft által felügyelt kulcsokkal lesznek titkosítva. A titkosítási kulcsok további szabályozásához az ügyfél által felügyelt kulcsokat is megadhatja az operációs rendszer többi részén és az AKS-fürtök adatlemezeinek titkosításához. További információ:
- BYOK azure-lemezekkel az AKS-.
- Azure Disk Storagekiszolgálóoldali titkosítása.
Gazdagépalapú titkosítás
gazdagépalapú titkosítási az AKS-en tovább erősíti a bérlői számítási feladatok elkülönítését, az adatvédelmet és a biztonságot. Ha engedélyezi a gazdagépalapú titkosítást, az AKS titkosítja a mögöttes gazdagépeken inaktív adatokat, ami segít biztosítani a bizalmas bérlői adatok jogosulatlan hozzáféréssel szembeni védelmét. Az ideiglenes lemezek és a rövid élettartamú operációsrendszer-lemezek inaktív állapotban, platform által felügyelt kulcsokkal vannak titkosítva, amikor engedélyezi a végpontok közötti titkosítást.
Az AKS-ben az operációs rendszer és az adatlemezek alapértelmezés szerint kiszolgálóoldali titkosítást használnak platform által felügyelt kulcsokkal. Ezeknek a lemezeknek a gyorsítótárai inaktív állapotban, platform által felügyelt kulcsokkal vannak titkosítva. Saját kulcstitkosítási kulcsot meg a adatvédelmi kulcs titkosításához borítéktitkosítással, más néven burkoló. Az operációs rendszer és az adatlemezek gyorsítótára a megadott BYOK keresztül is titkosítva lesz.
A gazdagépalapú titkosítás biztonsági réteget biztosít a több-bérlős környezetekhez. Az operációs rendszerben és az adatlemez-gyorsítótárakban lévő bérlők adatai a kiválasztott lemeztitkosítási típustól függően az ügyfél által felügyelt vagy platform által felügyelt kulcsokkal vannak titkosítva. További információ:
- gazdagépalapú titkosítás AKS-
- BYOK azure-lemezekkel az AKS-
- Azure Disk Storage kiszolgálóoldali titkosítása
Hálózati
Az alábbi szakaszok a több-bérlős megoldások AKS-sel való hálózatkezelési ajánlott eljárásait ismertetik.
Az API-kiszolgálóhoz való hálózati hozzáférés korlátozása
A Kubernetesben az API-kiszolgáló kéréseket kap a fürt műveleteinek végrehajtására, például erőforrások létrehozására vagy csomópontok számának skálázására. Ha egy AKS-fürtöt több csapat között oszt meg egy szervezeten belül, az alábbi megoldások egyikével védje a vezérlősíkhoz való hozzáférést.
Privát AKS-fürtök
Privát AKS-fürt használatával meggyőződhet arról, hogy az API-kiszolgáló és a csomópontkészletek közötti hálózati forgalom a virtuális hálózaton belül marad. A privát AKS-fürtökben a vezérlősík vagy az API-kiszolgáló olyan belső IP-címmel rendelkezik, amely csak az AKS-fürt ugyanazon virtuális hálózatában található Azure privát végpontkeresztül érhető el. Hasonlóképpen, az ugyanabban a virtuális hálózatban lévő virtuális gépek privát módon kommunikálhatnak a vezérlősíkkal a privát végponton keresztül. További információ: Privát AKS-fürt létrehozása.
Engedélyezett IP-címtartományok
A fürtbiztonság és a támadások minimalizálása érdekében a második lehetőség a engedélyezett IP-címtartományokhasználata. Ez a megközelítés egy nyilvános AKS-fürt vezérlősíkjának elérését az IP-címek és az osztály nélküli Inter-Domain útválasztási (CIDR) tartományok jól ismert listájára korlátozza. Engedélyezett IP-címek használata esetén azok továbbra is nyilvánosan elérhetők, de a hozzáférés több tartományra korlátozódik. További információ: Az API-kiszolgáló biztonságos elérése engedélyezett IP-címtartományok használatával az AKS.
Private Link-integráció
Azure Private Link szolgáltatás egy infrastruktúra-összetevő, amely lehetővé teszi az alkalmazások számára, hogy privát módon csatlakozzanak egy szolgáltatáshoz egy Azure privát végponton keresztül,, amely egy virtuális hálózatban van meghatározva, és egy Azure Load Balancer-példány előtérbeli IP-konfigurációjára csatlakozik. A Private Linksegítségével a szolgáltatók biztonságosan biztosíthatják szolgáltatásaikat a bérlőiknek, amelyek az Azure-ból vagy a helyszínen csatlakozhatnak adatkiszivárgási kockázatok nélkül.
A Private Link szolgáltatásintegrációs használatával biztonságos módon biztosíthat privát kapcsolatot a bérlőknek az AKS által üzemeltetett számítási feladataikhoz anélkül, hogy nyilvános végpontot kellene elérhetővé tenniük a nyilvános interneten.
További információ arról, hogyan konfigurálhatja a Private Linket egy Azure-ban üzemeltetett több-bérlős megoldáshoz: Több-bérlős és Privát kapcsolat.
Fordított proxyk
A fordított proxy egy terheléselosztó és egy API-átjáró, amelyet általában a bérlői alkalmazások előtt használnak a bejövő kérelmek védelmére, szűrésére és küldésére. A népszerű fordított proxyk olyan funkciókat támogatnak, mint a terheléselosztás, az SSL leállítása és a 7. rétegbeli útválasztás. A fordított proxykat általában a biztonság, a teljesítmény és a megbízhatóság növelése érdekében implementálják. A Kubernetes népszerű fordított proxyi a következő implementációkat tartalmazzák:
- NGINX bejövőforgalom-vezérlő egy népszerű fordított proxykiszolgáló, amely olyan speciális funkciókat támogat, mint a terheléselosztás, az SSL-megszakítás és a 7. rétegbeli útválasztás.
- Traefik Kubernetes bejövőforgalom-szolgáltató egy Kubernetes bejövőforgalom-vezérlő, amely a bejövő forgalom specifikációjának támogatásával a fürtszolgáltatásokhoz való hozzáférés kezelésére használható.
- HAProxy Kubernetes bejövőforgalom-vezérlő egy újabb fordított proxy a Kuberneteshez, amely támogatja az olyan szabványos funkciókat, mint a TLS leállítása, az URL-útvonalalapú útválasztás stb.
- Azure Application Gateway bejövőforgalom-vezérlő (AGIC) egy Kubernetes- alkalmazás, amely lehetővé teszi, hogy az AKS-ügyfelek azure-natív Application Gateway L7 terheléselosztót használjanak a bérlői alkalmazások nyilvános interneten vagy belsőleg a virtuális hálózaton futó más rendszerek számára való elérhetővé tétele érdekében.
Ha egy AKS által üzemeltetett fordított proxyt használ több bérlői alkalmazás bejövő kéréseinek biztonságossá tételéhez és kezeléséhez, vegye figyelembe az alábbi javaslatokat:
- Üzemeltetje a fordított proxyt egy dedikált csomópontkészleten, amely úgy van konfigurálva, hogy nagy hálózati sávszélességű virtuálisgép-méretet használjon, és engedélyezett gyorsított hálózati.
- Konfigurálja a fordított proxyt futtató csomópontkészletet az automatikus skálázáshoz.
- A bérlői alkalmazások megnövekedett késésének és időtúllépésének elkerülése érdekében adjon meg egy automatikus skálázási szabályzatot, hogy a bejövőforgalom-vezérlő podjainak száma azonnal kibővüljön, és a forgalom ingadozásainak megfelelően szerződést kötjön.
- A méretezhetőség és a szegregáció szintjének növelése érdekében fontolja meg a bérlői alkalmazások felé irányuló bejövő forgalom horizontális felosztását a bejövő forgalom több példánya között.
Az Azure Application Gateway bejövőforgalom-vezérlő (AGIC)használatakor fontolja meg az alábbi ajánlott eljárások implementálását:
- Konfigurálja az Application Gateway, amelyet a bejövőforgalom-vezérlő automatikus skálázásihasznál. Ha az automatikus skálázás engedélyezve van, az Application Gateway és a webalkalmazási tűzfal (WAF) v2 termékváltozatai az alkalmazás forgalmi követelményei alapján ki- vagy beskálázhatók. Ez a mód jobb rugalmasságot biztosít az alkalmazás számára, és szükségtelenné teszi az application gateway méretének vagy példányszámának becslését. Ez a mód a költségek megtakarítását is segíti azáltal, hogy nem követeli meg, hogy az átjáró csúcskiépítésű kapacitáson fusson a várt maximális forgalmi terheléshez. Meg kell adnia a példányok minimális (és opcionálisan maximális) számát.
- Fontolja meg az AGIC-több példányának üzembe helyezését , amelyek mindegyike külön Application Gateway-van társítva, ha a bérlői alkalmazások száma meghaladja a helyek maximális számát. Feltételezve, hogy minden bérlői alkalmazás dedikált névtérben fut, használja több névtértámogatási a bérlői alkalmazásokat az AGIC-több példányában.
Integráció az Azure Front Doorral
Azure Front Door egy globális 7. rétegbeli terheléselosztó és egy modern felhőbeli tartalomkézbesítési hálózat (CDN) a Microsofttól, amely gyors, megbízható és biztonságos hozzáférést biztosít a felhasználók és a webalkalmazások között világszerte. Az Azure Front Door olyan funkciókat támogat, mint a kérések gyorsítása, az SSL leállítása, a válasz gyorsítótárazása, a WAF a peremhálózaton, az URL-alapú útválasztás, az átírás és az átirányítás, amelyeket az AKS által üzemeltetett több-bérlős alkalmazások nyilvános interneten való elérhetővé bocsátáskor használhat.
Előfordulhat például, hogy egy AKS által üzemeltetett több-bérlős alkalmazással szeretné kiszolgálni az ügyfelek összes kérését. Ebben az összefüggésben az Azure Front Door használatával több egyéni tartományt kezelhet, egy-egy bérlőhöz. Megszakíthatja az SSL-kapcsolatokat a peremhálózaton, és az összes forgalmat átirányíthatja az AKS által üzemeltetett több-bérlős alkalmazáshoz, amely egyetlen gazdagépnévvel van konfigurálva.
Az Azure Front Door konfigurálható úgy, hogy módosítsa a kérelem forrás állomásfejlécét, hogy megfeleljen a háttéralkalmazás tartománynevének. Az ügyfél által küldött eredeti Host fejlécet a rendszer a X-Forwarded-Host fejlécen keresztül propagálja, és a több-bérlős alkalmazás kódja ezen információk segítségével leképezi a bejövő kérést a megfelelő bérlői.
Azure Web Application Firewallaz Azure Front Dooron központi védelmet biztosít a webalkalmazások számára. Az Azure Web Application Firewall segíthet megvédeni az AKS által üzemeltetett bérlői alkalmazásokat, amelyek nyilvános végpontot tehetnek közzé az interneten a rosszindulatú támadások ellen.
Az Azure Front Door Premiumot úgy konfigurálhatja, hogy privát módon csatlakozzon egy vagy több AKS-fürtön futó bérlőalkalmazáshoz egy belső terheléselosztó-forráson keresztül, Private Linkhasználatával. További információ: Az Azure Front Door Premium csatlakoztatása belső terheléselosztó-forráshoz a Private Link.
Kimenő kapcsolatok
Amikor az AKS által üzemeltetett alkalmazások nagyszámú adatbázishoz vagy külső szolgáltatáshoz csatlakoznak, a fürt ki van téve a forráshálózati címfordítás (SNAT) portjának kimerülésének. SNAT-portok egyedi azonosítókat hoznak létre, amelyek különböző folyamatok fenntartására szolgálnak, amelyeket az azonos számítási erőforrásokon futó alkalmazások kezdeményeznek. Ha több bérlőalkalmazást futtat egy megosztott AKS-fürtön, nagy számú kimenő hívást kezdeményezhet, ami SNAT-portkimerüléshez vezethet. Az AKS-fürtök három különböző módon képesek kezelni a kimenő kapcsolatokat:
-
Azure Load Balancer: Az AKS alapértelmezés szerint egy standard termékváltozatú Load Balancert állít be és használ a kimenő kapcsolatokhoz. Előfordulhat azonban, hogy az alapértelmezett beállítás nem felel meg az összes forgatókönyv követelményeinek, ha a nyilvános IP-címek nem engedélyezettek, vagy ha további ugrásokra van szükség a kimenő forgalomhoz. A nyilvános terheléselosztó alapértelmezés szerint egy alapértelmezett nyilvános IP-címmel jön létre, amelyet a kimenő szabályok használni. A kimenő szabályok lehetővé teszik, hogy explicit módon definiálja az SNAT-t egy nyilvános standard terheléselosztóhoz. Ez a konfiguráció lehetővé teszi a terheléselosztó nyilvános IP-címeinek használatát, hogy kimenő internetkapcsolatot biztosítson a háttérpéldányokhoz. Szükség esetén az SNAT-portok
elkerülése érdekében konfigurálhatja a nyilvános terheléselosztó kimenő szabályait több nyilvános IP-cím használatára. További információ: A terheléselosztó előtérbeli IP-címének használata kimenő szabályokon keresztüli kimenő forgalomhoz. - Azure NAT Gateway: Konfigurálhat egy AKS-fürtöt az Azure NAT Gateway használatával a bérlői alkalmazások kimenő forgalmának irányításához. A NAT Gateway nyilvános IP-címenként legfeljebb 64 512 kimenő UDP- és TCP-forgalmat tesz lehetővé, legfeljebb 16 IP-címmel. Az SNAT-portok kimerülésének elkerülése érdekében, ha NAT-átjárót használ az AKS-fürt kimenő kapcsolatainak kezelésére, több nyilvános IP-címet vagy nyilvános IP-címelőtagot társíthat az átjáróhoz. További információ: Azure NAT Gateway több-bérlős.
- felhasználó által definiált útvonal (UDR): Testre szabhatja az AKS-fürt kimenő útvonalát, hogy támogassa az egyéni hálózati forgatókönyveket, például azokat, amelyek nem engedélyezik a nyilvános IP-címeket, és megkövetelik, hogy a fürt egy hálózati virtuális berendezés (NVA) mögé üljön. Ha felhasználó által definiált útválasztásikonfigurál egy fürtöt, az AKS nem konfigurálja automatikusan a kimenő útvonalakat. A kimenő forgalom beállítását végre kell hajtania. Például egy Azure Firewallkeresztül irányíthatja a kimenő forgalmat. Az AKS-fürtöt egy meglévő virtuális hálózatban kell üzembe helyeznie egy korábban konfigurált alhálózattal. Ha nem szabványos terheléselosztó-architektúrát használ, explicit kimenő forgalmat kell létrehoznia. Ehhez az architektúrához explicit módon kell kimenő forgalmat küldeni egy berendezésnek, például tűzfalnak, átjárónak vagy proxynak. Vagy az architektúra lehetővé teszi, hogy a hálózati címfordítást (NAT) a standard terheléselosztóhoz vagy berendezéshez hozzárendelt nyilvános IP-címre lehessen fordítani.
Ellenőrző
Az Azure Monitor és tárolóelemzési segítségével figyelheti a megosztott AKS-fürtön futó bérlői alkalmazásokat, és kiszámíthatja az egyes névterek költséglebontásait. Az Azure Monitor használatával monitorozza az AKS állapotát és teljesítményét. Ez magában foglalja a naplók és metrikák, telemetriai elemzések és az összegyűjtött adatok vizualizációinak gyűjtését a trendek azonosításához és a riasztások konfigurálásához, amelyek proaktív módon értesítik Önt a kritikus problémákról. Engedélyezheti tárolóelemzési, hogy bővítse ezt a monitorozást.
Nyílt forráskódú eszközöket is alkalmazhat, például Prometheus és Grafana, amelyeket széles körben használnak a Kubernetes monitorozásához. Más, nem Microsoft-eszközök is alkalmazhatók a figyeléshez és a megfigyelhetőséghez.
Költségek
A költségszabályozás a költségek szabályozására szolgáló szabályzatok folyamatos implementálásának folyamata. A Kubernetes-környezetben a szervezetek számos módszert használhatnak a költségek szabályozására és optimalizálására. Ezek a módszerek magukban foglalják a natív Kubernetes-eszközök használatát az erőforrás-használat és -felhasználás kezeléséhez és szabályozásához, valamint a mögöttes infrastruktúra proaktív figyeléséhez és optimalizálásához. A bérlőnkénti költségek kiszámításakor figyelembe kell vennie a bérlői alkalmazás által használt összes erőforráshoz kapcsolódó költségeket. A bérlőknek a díjak visszaszámlázására alkalmazott megközelítés a megoldás által alkalmazott bérleti modelltől függ. Az alábbi lista részletesebben ismerteti a bérlői modelleket:
- Teljes mértékben több-bérlős: Ha egyetlen több-bérlős alkalmazás kiszolgálja az összes bérlői kérést, az Ön feladata nyomon követni az erőforrás-felhasználást és az egyes bérlők által generált kérelmek számát. Ezt követően ennek megfelelően számítja fel ügyfeleit.
- Dedikált fürt: Ha egy fürt egyetlen bérlőnek van szentelve, egyszerűen felszámíthatja az Azure-erőforrások költségeit az ügyfélnek. A teljes tulajdonosi költség számos tényezőtől függ, beleértve a virtuális gépek számát és méretét, a hálózati forgalom hálózati költségeit, a nyilvános IP-címeket, a terheléselosztókat és a tárolási szolgáltatásokat, például a felügyelt lemezeket vagy az Azure-fájlokat, amelyeket a bérlői megoldás használ. A költségszámítási műveletek megkönnyítése érdekében címkézhet meg egy AKS-fürtöt és annak erőforrásait a csomópont erőforráscsoportjában. További információ: Címkék hozzáadása a fürthöz.
- Dedikált csomópontkészlet: Azure-címkét alkalmazhat egy új vagy meglévő csomópontkészletre, amely egyetlen bérlőnek van dedikáltan. A rendszer a csomópontkészletben lévő összes csomópontra alkalmazza a címkéket, és a frissítések révén megmaradnak. A rendszer címkéket alkalmaz azokra az új csomópontokra is, amelyek a kiskálázási műveletek során hozzáadódnak egy csomópontkészlethez. A címke hozzáadása segíthet olyan feladatokban, mint a szabályzatkövetés vagy a költségszámítás. További információ: Címkék hozzáadása csomópontkészletekhez.
- Egyéb erőforrások: Címkék használatával hozzárendelheti a dedikált erőforrások költségeit egy adott bérlőhöz. A nyilvános IP-címeket, fájlokat és lemezeket egy Kubernetes-jegyzék használatával címkézheti meg. Az ily módon beállított címkék akkor is megőrzik a Kubernetes-értékeket, ha később egy másik módszerrel frissíti őket. Ha a kubernetesen keresztül eltávolítja a nyilvános IP-címeket, fájlokat vagy lemezeket, a Kubernetes-csoportok által megadott címkék el lesznek távolítva. A Kubernetes által nem nyomon követett erőforrások címkéi változatlanok maradnak. További információ: Címkék hozzáadása a Kuberneteshasználatával.
Nyílt forráskódú eszközök, például KubeCosthasználatával monitorozhatja és szabályozhatja az AKS-fürtök költségeit. Hatókörbe helyezheti a költségfelosztást egy üzemelő példányra, szolgáltatásra, címkére, podra és névtérre, így rugalmasan térítheti vissza vagy jelenítheti meg a fürt felhasználóit. További információ: Költségszabályozás a Kubecost.
További információ a több-bérlős alkalmazások költségeinek méréséről, lefoglalásáról és optimalizálásáról: Több-bérlős megoldások költségkezelésének és lefoglalásának architekturális megközelítései. A költségoptimalizálással kapcsolatos általános útmutatásért tekintse meg az Azure Well-Architected-keretrendszer cikkét, A költségoptimalizálási pilléráttekintése című cikket.
Kormányzás
Ha több bérlő azonos infrastruktúrával rendelkezik, az adatvédelmi, megfelelőségi és szabályozási követelmények kezelése bonyolulttá válhat. Erős biztonsági intézkedéseket és adatszabályozási szabályzatokat kell implementálnia. A megosztott AKS-fürtök nagyobb kockázatot jelentenek az adatsértések, a jogosulatlan hozzáférés és az adatvédelmi előírásoknak való meg nem fel nem felelési problémák esetén. Előfordulhat, hogy minden bérlő egyedi adatszabályozási követelményekkel és megfelelőségi szabályzatokkal rendelkezik, amelyek megnehezítik az adatok biztonságának és adatvédettségének biztosítását.
Microsoft Defender for Containers egy natív felhőbeli tárolóbiztonsági megoldás, amely fenyegetésészlelési és védelmi képességeket biztosít a Kubernetes-környezetekhez. A Defender for Containers használatával javíthatja az adatszabályozás és a megfelelőség állapotát, ha több bérlőt üzemeltet egy Kubernetes-fürtben. A Defender for Containers használatával megvédheti a bizalmas adatokat, észlelheti és reagálhat a fenyegetésekre a tároló viselkedésének és hálózati forgalmának elemzésével, és megfelelhet a jogszabályi követelményeknek. Naplózási képességeket, naplókezelést és jelentéskészítést biztosít a szabályozók és ellenőrök megfelelőségének bemutatásához.
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ő:
- Paolo Salvatori | Vezető ügyfélmérnök
Egyéb közreműködők:
- Bohdan Cherchyk | Vezető ügyfélmérnök
- John Downs | Fő szoftvermérnök
- Chad Kittel | Fő szoftvermérnök
- Arsen Vladimirskiy | Vezető ügyfélmérnök