Azure Kubernetes Service- (AKS-) fürt alaparchitektúrája

Ez a cikk egy ajánlott alapinfrastruktúra-architektúrát biztosít egy Azure Kubernetes Service-fürt (AKS) üzembe helyezéséhez. A tervezési alapelveket használja, és az Azure Well-Architected Framework AKS architekturális ajánlott eljárásain alapul. Ez a cikk több különböző interdiszciplináris csoportot, például a hálózatkezelési, biztonsági és identitáskezelő csoportokat segít végigvezetni ezen általános célú infrastruktúra üzembe helyezésekor.

Ez az architektúra nem számítási feladatokra összpontosít. Az AKS-fürtre összpontosít. Ez az információ a legtöbb AKS-fürt minimálisan ajánlott alapkonfigurációja. Integrálható az Azure-szolgáltatásokkal, amelyek megfigyelhetőséget biztosítanak, olyan hálózati topológiát biztosítanak, amely támogatja a többrégiós növekedést, és biztonságossá teszi a fürtön belüli forgalmat.

Az üzleti követelmények befolyásolják a célarchitektúrát, és különböző alkalmazáskörnyezetek között változhatnak. Tekintsük az architektúrát az előkészítési és éles fázisok kiindulópontjának.

Az architektúra implementációját a GitHubon használhatja: az AKS alapkonfigurációs referencia-implementációja. Használja alternatív kiindulási pontként, és konfigurálja a referenciaarchitektúrát az igényeinek megfelelően.

Hálózatkezelési konfiguráció

Hálózati topológia
Az IP-címek megtervezése
Bejövő erőforrások üzembe helyezése

Fürtszámítás

Az alapfürt számítása
Tárolórendszerkép-referencia
Szabályzatkezelés

Identitáskezelés

A Microsoft Entra-azonosító integrálása a fürthöz
Microsoft Entra-azonosító integrálása a számítási feladathoz

Biztonságos adatfolyam

A hálózati folyamat védelme
Titkos kódkezelés hozzáadása

Az üzletmenet folytonossága

Méretezhetőség
Fürt és csomópont rendelkezésre állása
Rendelkezésre állás és többrégiós támogatás

Üzemeltetés

Fürt- és számítási feladatok CI-/CD-folyamatai
Fürt állapota és metrikái
Költségkezelés és jelentéskészítés

hálózati topológia,

Ez az architektúra egy küllős hálózati topológiát használ. Helyezze üzembe a központot és a küllőket a virtuális hálózatok közötti társviszony-létesítésen keresztül csatlakozó különálló virtuális hálózatokban. Ez a topológia számos előnnyel rendelkezik. Használja ezt a topológiát a következőre:

• Szegregált felügyelet engedélyezése. Alkalmazhatja a szabályozást, és betarthatja a minimális jogosultság elvét. Emellett támogatja az Azure-beli célzóna fogalmát a feladatok elkülönítésével.

• Az Azure-erőforrások nyilvános interneten való közvetlen kitettségének minimalizálása.

• Biztosítson regionális központ- és küllős topológiákat. A jövőben bővítheti a küllős hálózati topológiákat, és elkülönítheti a számítási feladatokat.

• Webalkalmazási tűzfalszolgáltatással megvizsgálhatja az összes webalkalmazás HTTP-forgalmát.

• Több előfizetésre kiterjedő számítási feladatok támogatása.

• Bővíthetővé teheti az architektúrát. Új funkciók vagy számítási feladatok elhelyezéséhez a hálózati topológia újratervezése helyett új küllőket adhat hozzá.

• Támogatja az erőforrások, például a tűzfalak és a DNS-zónák hálózatok közötti megosztását.

• Igazodjon az Azure nagyvállalati szintű célzónához.

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

További információ: Küllős hálózati topológia az Azure-ban.

Az AKS alapszintű referenciaarchitektúráján található Windows-tárolók hálózattervezési változásairól további információt az AKS-en futó Windows-tárolókban talál.

Központi virtuális hálózat

A központi virtuális hálózat a kapcsolat és a megfigyelhetőség központi pontja. Ebben az architektúrában a központ a következőket tartalmazza:

• Az Azure Firewall globális tűzfalszabályzatokkal, amelyeket a központi informatikai csapatok határoznak meg a szervezeti szintű tűzfalszabályzat kényszerítéséhez.
• Azure Bastion virtuális gépekhez (virtuális gépekhez) való távoli hozzáféréshez.
• A VPN-kapcsolatok átjáróalhálózata.
• Az Azure Monitor a hálózati megfigyelhetőség érdekében.

A hálózaton belül az architektúra három alhálózattal rendelkezik.

Alhálózat az Azure Firewall üzemeltetéséhez

Az Azure Firewall felügyelt tűzfalszolgáltatás. Az Azure Firewall-példány biztosítja a kimenő hálózati forgalmat. E biztonsági réteg nélkül a forgalom egy rosszindulatú, nem Microsoft-szolgáltatással kommunikálhat, amely kiszűrheti a bizalmas számítási feladatok adatait. Az Azure Firewall Managerrel központilag üzembe helyezhet és konfigurálhat több Azure Firewall-példányt, és kezelheti az Azure Firewall-szabályzatokat ehhez a központi virtuális hálózati architektúratípushoz.

Átjáró üzemeltetéséhez tartozó alhálózat

Ez az alhálózat egy VPN-átjáró vagy egy Azure ExpressRoute-átjáró helyőrzője. Az átjáró kapcsolatot biztosít a helyszíni hálózat útválasztói és a virtuális hálózat között.

Alhálózat az Azure Bastion üzemeltetéséhez

Ez az alhálózat az Azure Bastion helyőrzője. Az Azure Bastion használatával biztonságosan elérheti az Azure-erőforrásokat anélkül, hogy az erőforrásokat az interneten tárja fel. Ez az alhálózat csak felügyeletre és műveletekre használható.

Küllős virtuális hálózat

A küllős virtuális hálózat tartalmazza az AKS-fürtöt és más kapcsolódó erőforrásokat. A küllő az alábbi alhálózatokkal rendelkezik.

Az Azure-alkalmazás Átjáró üzemeltetéséhez tartozó alhálózat

Az Application Gateway egy webes forgalom terheléselosztója, amely a 7. rétegben működik. A referencia-implementáció az Application Gateway v2 termékváltozatot használja, amely lehetővé teszi az Azure Web Application Firewall használatát. A webalkalmazási tűzfal védi a bejövő forgalmat a gyakori webes forgalommal kapcsolatos támadásoktól, beleértve a robotokat is. A példány nyilvános előtérbeli IP-konfigurációval rendelkezik, amely felhasználói kéréseket fogad. Az Application Gateway tervezés szerint dedikált alhálózatot igényel.

A bejövő erőforrások üzemeltetésére használt alhálózat

A forgalom irányításához és elosztásához a Traefik az a bejövő vezérlő, amely teljesíti a Kubernetes bejövő erőforrásait. Az Azure belső terheléselosztói ebben az alhálózatban találhatók. További információ: Belső terheléselosztó használata az AKS-sel.

Alhálózat a fürtcsomópontok üzemeltetéséhez

Az AKS két csomópontkészletet tart fenn, amelyek külön csomópontcsoportok. A rendszercsomópont-készlet az alapvető fürtszolgáltatásokat futtató podokat üzemelteti. A felhasználói csomópontkészlet futtatja a számítási feladatot és a bejövő forgalomvezérlőt a számítási feladat felé irányuló bejövő kommunikáció engedélyezéséhez.

Azure Private Link-végpontok üzemeltetésére szolgáló alhálózat

Privát kapcsolati kapcsolatokat hozhat létre az Azure Container Registryhez és az Azure Key Vaulthoz, hogy a felhasználók a küllős virtuális hálózaton belül egy privát végponton keresztül férhessenek hozzá ezekhez a szolgáltatásokhoz. A privát végpontokhoz nincs szükség dedikált alhálózatra. Privát végpontokat is elhelyezhet a központi virtuális hálózaton. Az alapkonfigurációban a végpontok a küllős virtuális hálózaton belül egy dedikált alhálózaton lesznek üzembe helyezve. Ez a megközelítés csökkenti a társhálózati hálózati kapcsolaton áthaladó forgalmat. Megtartja a fürthöz tartozó erőforrásokat ugyanabban a virtuális hálózaton. Az alhálózat szintjén részletes biztonsági szabályokat is alkalmazhat hálózati biztonsági csoportok használatával.

További információ: Private Link üzembe helyezési lehetőségek.

IP-címek tervezése

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

A virtuális hálózat címterének elég nagynak kell lennie az összes alhálózat tárolásához. A forgalmat fogadó összes entitást figyelembe kell venni. A Kubernetes az alhálózati címtérből lefoglalja az adott entitások IP-címeit. Vegye figyelembe ezeket a pontokat.

• Frissítések

  Az AKS rendszeresen frissíti a csomópontokat, hogy a mögöttes virtuális gépek naprakészek legyenek a biztonsági funkciókkal és más rendszerjavításokkal kapcsolatban. A frissítési folyamat során az AKS létrehoz egy csomópontot, amely ideiglenesen üzemelteti a podokat, míg a frissítési csomópontot kordonozza és üríti. Az ideiglenes csomóponthoz egy IP-cím van hozzárendelve a fürt alhálózatából. Győződjön meg arról, hogy elegendő címtér áll rendelkezésre ezekhez az ideiglenes csomóponti IP-címekhez.

  A podok esetében a stratégiától függően további címekre lehet szükség. A működés közbeni frissítésekhez a számítási feladatot futtató ideiglenes podok címére van szükség a tényleges podok frissítésekor. Ha a cserestratégiát használja, a podok el lesznek távolítva, és létrejönnek az újak. Így a régi podokhoz társított címek újra felhasználhatók.

• Méretezhetőség

  Vegye figyelembe az összes rendszer- és felhasználói csomópont csomópontszámát, valamint azok maximális méretezhetőségi korlátját. Tegyük fel, hogy 400%-kal szeretne felskálázni. A felskálázott csomópontok címeinek négyszeresére van szüksége.

  Ebben az architektúrában az erőforrások közvetlenül kapcsolatba lépnek az egyes podokkal. Tehát minden podnak egyedi címre van szüksége. A pod méretezhetősége befolyásolja a címszámítást. Ez a döntés attól függ, hogy hány podot szeretne növelni.

• Private Link-címek

  Vegye figyelembe a más Azure-szolgáltatásokkal privát kapcsolaton keresztüli kommunikációhoz szükséges címeket. Ez az architektúra két címmel rendelkezik a Container Registryre és a Key Vaultra mutató hivatkozásokhoz.

• Az Azure fenntart bizonyos címeket a használatukhoz. Nem rendelhetők hozzá.

Az előző lista nem teljes. Ha a terv más olyan erőforrásokkal is rendelkezik, amelyek befolyásolják az elérhető IP-címek számát, akkor ezeket a címeket is el kell fogadnia.

Ez az architektúra egyetlen számítási feladathoz készült. Éles AKS-fürtökben mindig különítse el a rendszercsomópont-készletet a felhasználói csomópontkészlettől. Ha több számítási feladatot futtat a fürtön, érdemes elkülöníteni a felhasználói csomópontkészleteket egymástól. Ha ezt teszi, az több kisebb méretű alhálózatot eredményez. Emellett a bejövő erőforrás összetettebb is lehet, ezért több bejövő vezérlőre is szükség lehet, amelyek további IP-címeket igényelnek.

Az architektúrával kapcsolatos szempontok teljes halmazát az AKS alaphálózati topológiája tartalmazza.

Az AKS-fürt IP-címének tervezésével kapcsolatos információkért lásd : A fürt IP-címzésének megtervezése.

Az AKS alapszintű referenciaarchitektúráján található Windows-tárolók IP-címtervezési szempontjairól további információt az AKS-en futó Windows-tárolókban talál.

Bővítmények és előzetes verziójú funkciók

A Kubernetes és az AKS folyamatosan fejlődik, gyorsabb kiadási ciklusokkal, mint a helyszíni környezetekhez készült szoftverek. Ez az alaparchitektúra az AKS előzetes verziójának funkcióitól és az AKS-bővítmények kiválasztásától függ. Íme a különbség a kettő között:

• Az AKS-csapat az előzetes verziójú funkciókat szállítva és fejlesztve ismerteti, mivel az előzetes verziójú funkciók nagy része csak néhány hónapig marad ebben az állapotban, mielőtt az általános rendelkezésre állási (GA) fázisra lépne.

• Az AKS-bővítmények és -bővítmények további, támogatott funkciókat biztosítanak. Az AKS kezeli a telepítést, a konfigurációt és az életciklust.

Ez az alaparchitektúra nem tartalmaz minden előzetes verziójú funkciót vagy bővítményt. Ehelyett csak azokat tartalmazza, amelyek jelentős értéket adnak egy általános célú fürthöz. Mivel ezek a funkciók előzetes verzióban érhetők el, ez az alaparchitektúra ennek megfelelően módosul. Vannak más előzetes verziójú funkciók vagy AKS-bővítmények, amelyeket érdemes lehet kiértékelni az előkészületi fürtökben. Ezek a funkciók javíthatják a biztonságot, a kezelhetőséget vagy más követelményeket. Nem Microsoft-bővítmények esetén telepítenie és karbantartania kell őket, beleértve az elérhető verziók nyomon követését és a frissítések telepítését a fürt Kubernetes-verziójának frissítése után.

Tárolórendszerkép-referencia

A számítási feladat mellett a fürt számos más rendszerképet is tartalmazhat, például a bejövőforgalom-vezérlőt. Előfordulhat, hogy a képek némelyike nyilvános regisztrációs adatbázisokban található. Vegye figyelembe ezeket a pontokat, amikor lekéri a képeket a fürtbe.

• A rendszerkép lekéréséhez hitelesítse a fürtöt.

• Importáljon egy nyilvános lemezképet a tárolóregisztrációs adatbázisba, amely igazodik a szolgáltatásszintű célkitűzéshez (SLO), ha nyilvános rendszerképet használ. Ellenkező esetben előfordulhat, hogy a rendszerkép nem várt rendelkezésre állási problémákba ütközik. Ha a rendszerkép szükség esetén nem érhető el, az üzemeltetési problémákat okozhat. A privát tárolóregisztrációs adatbázis( például az Azure Container Registry) nyilvános beállításjegyzék helyett való használatának néhány előnye:

  • Letilthatja a képekhez való jogosulatlan hozzáférést.
  • Nincsenek nyilvános elérésű függőségei.
  • A rendszerképek lekérési naplóihoz a tevékenységek monitorozásához és a csatlakozási problémák osztályozásához férhet hozzá.
  • Kihasználhatja az integrált tárolóvizsgálat és a rendszerkép-megfelelőség előnyeit.

• Képek lekérése engedélyezett adatbázisokból. Ezt a korlátozást az Azure Policy használatával kényszerítheti ki. Ebben a referencia-implementációban a fürt csak az üzembe helyezett Container Registry-példányról kér le lemezképeket.

Az alapfürt számításának konfigurálása

Az AKS-ben minden csomópontkészlet egy virtuálisgép-méretezési csoporthoz van leképezve. A csomópontok virtuális gépek az egyes csomópontkészletekben. A költségek csökkentése érdekében fontolja meg kisebb virtuálisgép-méret használatát a rendszercsomópont-készlethez. Ez a referencia-implementáció három DS2_v2 csomóponttal telepíti a rendszercsomópont-készletet. Ez a méret elegendő a rendszer podok várható terhelésének kielégítéséhez. Az operációs rendszer lemeze 512 GB.

A felhasználói csomópontkészlet esetében az alábbi szempontokat érdemes figyelembe venni:

• Nagyobb csomópontméretek kiválasztásával csomagolja be a csomóponton beállított podok maximális számát. A nagy csomópontok minimálisra csökkentik az összes csomóponton futó szolgáltatások, például a figyelés és a naplózás lábnyomát.

• Válassza ki a megfelelő virtuálisgép-típust, ha adott számítási feladatra vonatkozó követelményekkel rendelkezik. Előfordulhat például, hogy memóriaoptimalizált termékre van szüksége bizonyos számítási feladatokhoz, vagy gpu-gyorsított termékre mások számára. További információ: Az Azure-beli virtuális gépek méretei.

• Helyezzen üzembe legalább két csomópontot. Így a számítási feladat magas rendelkezésre állási mintával rendelkezik két replikával. Az AKS használatával a fürt újra létrehozása nélkül módosíthatja a csomópontok számát.

• Tervezze meg a számítási feladat tényleges csomópontméreteit a tervezőcsapat által meghatározott követelmények alapján. Az üzleti követelmények alapján ez az architektúra DS4_v2 használ az éles számítási feladatokhoz. A költségek csökkentése érdekében a méretet DS3_v2, ami a minimális javaslat.

• Tegyük fel, hogy a számítási feladat az egyes csomópontok legfeljebb 80%-át használja fel a fürt kapacitásának tervezésekor. A fennmaradó 20% az AKS-szolgáltatások számára van fenntartva.

• Állítsa be csomópontonként a maximális podokat a kapacitástervezés alapján. Ha kapacitás-alapkonfigurációt próbál létrehozni, kezdje 30-zal. Módosítsa ezt az értéket a számítási feladat követelményei, a csomópont mérete és az IP-korlátozások alapján.

A Microsoft Entra-azonosító integrálása a fürthöz

A fürthöz és a fürtről való hozzáférés védelme kritikus fontosságú. Gondoljon rá a fürt szempontjából, amikor biztonsági döntéseket hoz:

• Belső hozzáférés. Fontolja meg az AKS-hozzáférést az Azure-összetevőkhöz, például a hálózati infrastruktúrához, a Tárolóregisztrációs adatbázishoz és a Key Vaulthoz. Csak azokat az erőforrásokat engedélyezze, amelyeket a fürtnek engedélyeznie kell.
• Külső hozzáférés. Adjon hozzáférést az identitások számára a Kubernetes-fürthöz. Csak azokat a külső entitásokat engedélyezze, amelyek hozzáférhetnek a Kubernetes API-kiszolgálóhoz és az Azure Resource Managerhez.

AKS-hozzáférés az Azure-hoz

Az Azure-beli AKS-hozzáférés kétféleképpen kezelhető a Microsoft Entra-azonosítón keresztül: az Azure-erőforrások szolgáltatásnevei vagy felügyelt identitásai .

Az Azure-hoz való AKS-hozzáférés kezelésére szolgáló két módszer közül a felügyelt identitásokat javasoljuk. A szolgáltatásnevek esetében manuálisan vagy programozott módon kell kezelnie és elforgatnia a titkos kulcsokat. A felügyelt identitásokkal a Microsoft Entra ID kezeli és végrehajtja a titkos kódok hitelesítését és időben történő rotálását.

Javasoljuk, hogy engedélyezze és használja a felügyelt identitásokat , hogy a fürt a Microsoft Entra-azonosítón keresztül kommunikálhasson külső Azure-erőforrásokkal. Még ha nem is használja azonnal a Microsoft Entra ID-integrációt, később is beépítheti.

Alapértelmezés szerint a fürt két elsődleges identitást használ: a fürt identitását és a kubelet-identitást. Az AKS vezérlősík-összetevői a fürt identitásával kezelik a fürterőforrásokat, beleértve a bejövő terheléselosztókat és az AKS által felügyelt nyilvános IP-címeket. A kubelet-identitás a Container Registry használatával hitelesít. Egyes bővítmények a felügyelt identitás használatával is támogatják a hitelesítést.

Felügyelt identitásokat kell használnia, amikor a fürtnek lemezképeket kell lekérnie egy tárolóregisztrációs adatbázisból. Ehhez a művelethez a fürtnek le kell szereznie a beállításjegyzék hitelesítő adatait. Ha nem használ felügyelt identitást, akkor ezeket az információkat kubernetes titkos objektum formájában tárolhatja, és a titkos kulcs lekérésére használhatja imagePullSecrets . Ezt a megközelítést biztonsági összetettségek miatt nem javasoljuk. Nem csak a titkos kulcs előzetes ismeretére van szüksége, hanem a DevOps-folyamaton belül is tárolnia kell a titkos kulcsot. Egy másik ok, amiért nem javasoljuk ezt a megközelítést, a titkos kulcs rotációjának kezelésével kapcsolatos működési többletterhelés. Ehelyett adjon AcrPull hozzáférést a fürt kubelet által felügyelt identitásához a beállításjegyzékhez. Ez a megközelítés foglalkozik az aggályokkal.

Ebben az architektúrában a fürt hozzáfér a Microsoft Entra ID által védett Azure-erőforrásokhoz, és a fürt olyan műveleteket hajt végre, amelyek támogatják a felügyelt identitásokat. Az Azure szerepköralapú hozzáférés-vezérlésének (Azure RBAC) és engedélyeinek hozzárendelése a fürt felügyelt identitásaihoz a fürt műveleteitől függően. A fürt hitelesíti magát a Microsoft Entra-azonosítón, majd a hozzá rendelt szerepkörök alapján engedélyezi vagy megtagadja a hozzáférést. Íme néhány példa ebből a referencia-implementációból, ahol az Azure beépített szerepkörei hozzá vannak rendelve a fürthöz:

• Hálózati közreműködői szerepkör. Kezeli a fürt küllős virtuális hálózatának vezérlési képességét. Ezzel a szerepkör-hozzárendeléssel az AKS-fürt rendszer által hozzárendelt identitása együttműködhet a belső bejövőforgalom-vezérlő szolgáltatás dedikált alhálózatával.

• Monitorozási metrikák közzétevői szerepköre. Kezeli a fürt azon képességét, hogy metrikákat küldjön az Azure Monitornak.

• AcrPull-szerepkör. Kezeli, hogy a fürt képes-e lemezképeket lekérni a megadott Azure Container Registry-példányokból.

Fürthozzáférés

A Microsoft Entra integrációja a külső hozzáférés biztonságát is leegyszerűsíti. Használhatja például a kubectl-et. Első lépésként futtathatja a az aks get-credentials parancsot a fürt hitelesítő adatainak lekéréséhez. A Microsoft Entra ID a fürt hitelesítő adatainak lekéréséhez engedélyezett Azure-szerepkörökön hitelesíti az ön identitását. További információ: Elérhető fürtszerepkörök engedélyei.

Az AKS kétféleképpen támogatja a Kubernetes-hozzáférést a Microsoft Entra ID használatával. Az első a Microsoft Entra ID használata a natív Kubernetes RBAC rendszerrel integrált identitásszolgáltatóként. A másik módszer natív Azure RBAC-t használ a fürthozzáférés szabályozásához. A következő szakaszok mindkét megközelítést részletesen ismertetik.

Kubernetes RBAC társítása a Microsoft Entra-azonosítóval

A Kubernetes az RBAC-t az alábbiakon keresztül támogatja:

• Egy fürtszintű engedélyekkel vagy ClusterRole objektumokkal definiált Role engedélyek készlete.

• Olyan kötések, amelyek a műveletek elvégzéséhez engedéllyel rendelkező felhasználókat és csoportokat rendelnek hozzá. Kötések definiálása egy vagy ClusterRoleBinding objektum RoleBinding használatával.

A Kubernetes rendelkezik néhány beépített szerepkörök, például a fürt-rendszergazda, a szerkesztés és a megtekintés. Ezeket a szerepköröket a Microsoft Entra felhasználóihoz és csoportjaihoz kötheti, hogy a vállalati címtár használatával kezelje a hozzáférést. További információ: Kubernetes RBAC használata a Microsoft Entra-integrációval.

Győződjön meg arról, hogy a Microsoft Entra-csoportokat a fürt- és névtérhozzáféréshez a Microsoft Entra hozzáférési véleményei közé sorolja.

Az Azure RBAC használata Kubernetes-engedélyezéshez

A Kubernetes natív RBAC ClusterRoleBindings használata helyett és RoleBindings az integrált Microsoft Entra-hitelesítéssel való engedélyezéshez javasoljuk, hogy azure RBAC- és Azure-szerepkör-hozzárendeléseket használjon. Ez a megközelítés kényszeríti a fürt engedélyezési ellenőrzését. Ezeket a szerepköröket a felügyeleti csoport, az előfizetés vagy az erőforráscsoport hatókörében is hozzárendelheti. A hatókör alá tartozó összes fürt ezután örökli a szerepkör-hozzárendelések konzisztens készletét a Kubernetes-fürt objektumaihoz való hozzáféréshez szükséges engedélyekkel kapcsolatban.

További információ: Azure RBAC for Kubernetes authorization.

Helyi fiókok

Az AKS támogatja a natív Kubernetes-felhasználóhitelesítést. Nem javasoljuk, hogy ezzel a módszerrel biztosítson felhasználói hozzáférést a fürtökhöz. Ez a módszer tanúsítványalapú, és az elsődleges identitásszolgáltatón kívül történik, ami megnehezíti a központi felhasználók hozzáférés-vezérlését és szabályozását. A fürthöz való hozzáférést mindig a Microsoft Entra-azonosítóval kezelheti, és konfigurálhatja a fürtöt a helyi fiókok hozzáférésének explicit letiltására.

Ebben a referencia-implementációban a helyi fürtfiókok hozzáférése kifejezetten le van tiltva, amikor a rendszer telepíti a fürtöt.

Microsoft Entra-azonosító integrálása a számítási feladathoz

Hasonlóan ahhoz, hogy az Azure rendszer által hozzárendelt felügyelt identitással rendelkezik a teljes fürthöz, a pod szintjén is hozzárendelhet felügyelt identitásokat. A számítási feladatok identitása lehetővé teszi, hogy az üzemeltetett számítási feladat a Microsoft Entra-azonosítón keresztül férhessen hozzá az erőforrásokhoz. A számítási feladat például az Azure Storage-ban tárolja a fájlokat. Amikor hozzá kell férnie ezekhez a fájlokhoz, a pod azure-beli felügyelt identitásként hitelesíti magát az erőforráson.

Ebben a referencia-implementációban az AKS Microsoft Entra Számítási feladat ID biztosítja a podok felügyelt identitásait. Ez a megközelítés integrálható a Kubernetes natív képességeivel a külső identitásszolgáltatókkal való összevonáshoz. Az Microsoft Entra Számítási feladat ID összevonással kapcsolatos további információkért lásd: Számítási feladatok identitásának összevonása.

Bejövő forgalmi erőforrások üzembe helyezése

A Kubernetes bejövő erőforrásai kezelik a fürtbe irányuló bejövő forgalom útválasztását és elosztását. A bejövő erőforrásoknak két része van:

• Az AKS által felügyelt belső terheléselosztó. A terheléselosztó egy privát statikus IP-címen keresztül teszi elérhetővé a bejövőforgalom-vezérlőt. Egyetlen kapcsolattartó pontként szolgál, amely bejövő folyamatokat fogad.

  Ez az architektúra az Azure Load Balancert használja. A Load Balancer a bejövő erőforrások számára dedikált alhálózat fürtjén kívül található. Forgalmat fogad az Application Gatewaytől, és ez a kommunikáció az átviteli réteg biztonságán (TLS) keresztül történik. A bejövő forgalom TLS-titkosításáról további információt a bejövő forgalom folyamatában talál.

• A bejövőforgalom-vezérlő. Ez a példa a Traefiket használja. A fürt felhasználói csomópontkészletében fut. Forgalmat fogad a belső terheléselosztótól, leállítja a TLS-t, és HTTP-en keresztül továbbítja azt a számítási feladat podjaira.

A bejövőforgalom-vezérlő a fürt kritikus összetevője. Az összetevő konfigurálásakor vegye figyelembe az alábbi szempontokat.

• A tervezési döntések részeként korlátozza a bejövőforgalom-vezérlőt egy adott műveleti hatókörre. Engedélyezheti például, hogy a vezérlő csak egy adott számítási feladatot futtató podokkal kommunikáljon.

• Kerülje a replikák ugyanazon a csomóponton való elhelyezését, hogy elterjessze a terhelést, és biztosítsa az üzletmenet folytonosságát, ha egy csomópont meghibásodik. Erre podAntiAffinity a célra használható.

• Korlátozza, hogy a podok csak a felhasználói csomópontkészleten legyenek ütemezve a használatával nodeSelectors. Ez a beállítás elkülöníti a számítási feladatokat és a rendszer podjait.

• Nyisson meg portokat és protokollokat, amelyek lehetővé teszik, hogy bizonyos entitások forgalmat küldjenek a bejövőforgalom-vezérlőnek. Ebben az architektúrában a Traefik csak az Application Gatewayről fogad forgalmat.

• Konfigurálhatja readinessProbe és livenessProbe beállíthatja a podok állapotát a megadott időközönként. A bejövőforgalom-vezérlőnek olyan jeleket kell küldenie, amelyek a podok állapotát jelzik.

• Fontolja meg a bejövőforgalom-vezérlő adott erőforrásokhoz való hozzáférésének korlátozását és bizonyos műveletek elvégzésének lehetőségét. Ezt a korlátozást a Kubernetes RBAC-engedélyekkel valósíthatja meg. Ebben az architektúrában például a Traefik engedélyt kap a szolgáltatások és végpontok megtekintésére, lekérésére és listázására a Kubernetes-objektum ClusterRole szabályainak használatával.

Az AKS-en futó Windows-tárolók bejövő forgalmával kapcsolatos további információkért lásd az AKS-en futó Windows-tárolókat.

Útválasztó beállításai

A bejövőforgalom-vezérlő útvonalak használatával határozza meg a forgalom küldésének helyét. Az útvonalak határozzák meg a forrásportot, amelyen a forgalom érkezik, valamint a célportokra és protokollokra vonatkozó információkat.

Íme egy példa ebből az architektúrából:

A Traefik a Kubernetes-szolgáltatót használja az útvonalak konfigurálásához. A annotations, tlsés entrypoints a beállítások azt jelzik, hogy az útvonalak HTTPS-en keresztül lesznek kiszolgálva. A middlewares beállítás azt határozza meg, hogy csak az Application Gateway alhálózatából érkező forgalom engedélyezett. A válaszok gzip-kódolást használnak, ha az ügyfél elfogadja. Mivel a Traefik leáll a TLS-sel, a háttérszolgáltatásokkal való kommunikáció HTTP-en keresztül történik.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

A hálózati folyamat biztonságossá tétele

Ebben az architektúrában a hálózati folyamat a következőket tartalmazza:

• Bejövő forgalom az ügyfélről a fürtben futó számítási feladatra.

• Kimenő forgalom a fürt egyik podjáról vagy csomópontjáról egy külső szolgáltatásba.

• Podok közötti forgalom a podok között. Ez a forgalom magában foglalja a bejövőforgalom-vezérlő és a számítási feladat közötti kommunikációt. Ha a számítási feladat több, a fürtben üzembe helyezett alkalmazásból áll, az alkalmazások közötti kommunikáció is ebbe a kategóriába tartozik.

• Az ügyfél és a Kubernetes API-kiszolgáló közötti forgalom kezelése.

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

Ez az architektúra több biztonsági réteget is biztosít a forgalom minden típusának védelméhez.

Bejövő forgalom

Az architektúra csak az ügyféltől érkező TLS-titkosított kéréseket fogadja el. A TLS 1.2-es verziója a minimálisan engedélyezett verzió, korlátozott titkosítási készlettel. A kiszolgálónév-jelzés (SNI) szigorú egyeztetése engedélyezve van. A végpontok közötti TLS beállítása az Application Gatewayen keresztül történik két különböző TLS-tanúsítvány használatával, ahogyan az az alábbi ábrán látható.

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

1. Az ügyfél HTTPS-kérést küld a következő tartománynévre: bicycle.contoso.com. Ez a név egy DNS A rekordhoz van társítva az Application Gateway nyilvános IP-címéhez. Ez a forgalom titkosítva van, így biztosítható, hogy az ügyfélböngésző és az átjáró közötti forgalmat ne lehessen ellenőrizni vagy módosítani.

2. Az Application Gateway integrált webalkalmazási tűzfallal rendelkezik, és egyezteti a TLS kézfogását bicycle.contoso.com, amely csak biztonságos titkosítást tesz lehetővé. Az Application Gateway egy TLS-végpont, ami azért fontos, mert az Application Gateway webalkalmazási tűzfalának meg kell vizsgálnia az egyszerű szöveges választ. A Key Vault tárolja a TLS-tanúsítványt. A fürt egy felhasználó által hozzárendelt felügyelt identitással fér hozzá, amely integrálva van az Application Gatewayrel. További információért lásd a Key Vault tanúsítványokkal való TLS-megszakításról szóló részt.

   Az Application Gateway feldolgozza a webalkalmazás tűzfalának ellenőrzési szabályait, és olyan útválasztási szabályokat futtat, amelyek továbbítják a forgalmat a konfigurált háttérrendszerbe.

3. Ahogy a forgalom az Application Gatewayről a háttérrendszerbe kerül, a rendszer újra titkosítja egy másik TLS-tanúsítvánnyal, amely helyettesítő karakter *.aks-ingress.contoso.coma belső terheléselosztónak való továbbításkor. Ez az újratitkosítás biztosítja, hogy a nem biztonságos forgalom ne áramoljon a fürt alhálózatába.

4. A bejövőforgalom-vezérlő a terheléselosztón keresztül fogadja a titkosított forgalmat. A vezérlő egy másik TLS-végpont *.aks-ingress.contoso.com , amely http-en keresztül továbbítja a forgalmat a számítási feladat podjaira. A tanúsítványok a Key Vaultban vannak tárolva, és a Tárolótároló-illesztő (CSI) illesztőprogramja csatlakoztatja őket a fürthöz. További információ: Titkos kódkezelés hozzáadása.

A végpontok közötti TLS-forgalmat a számítási feladat podján keresztül minden ugráskor implementálhatja. Győződjön meg arról, hogy méri a teljesítményt, a késést és az üzemeltetési hatásokat, amikor döntést hoz a podok közötti forgalom védelméről. A legtöbb egybérlős fürt esetében, megfelelő RBAC vezérlősíkkal és kiforrott szoftverfejlesztési életciklus-gyakorlatokkal elegendő a TLS titkosítása a bejövőforgalom-vezérlőig és a webalkalmazási tűzfallal való védelem. Ez a megközelítés minimálisra csökkenti a számítási feladatok felügyeletének és többletterhelésének terhelését a gyenge hálózati teljesítmény miatt. A számítási feladatok és a megfelelőségi követelmények határozzák meg, hogy hol hajtja végre a TLS-leállítást.

Kimenő forgalom folyamata

Ebben az architektúrában azt javasoljuk, hogy a fürtből érkező összes kimenő forgalom az Azure Firewallon keresztül kommunikáljon. Vagy használhatja saját hasonló hálózati virtuális berendezését is. Nem javasoljuk más kimenő adatok használatát, például az Azure NAT Gatewayt vagy a HTTP-proxyt, mert nem biztosítanak hálózati forgalomvizsgálatot. A Teljes felügyelet szabályozása és a forgalom vizsgálata érdekében a fürtből érkező összes kimenő forgalom a tűzfalon keresztül halad át. Ezt a konfigurációt felhasználó által megadott útvonalakkal (UDR-ekkel) implementálhatja. Az útvonal következő ugrása az Azure Firewall privát IP-címe . Az Azure Firewall dönti el, hogy letiltja vagy engedélyezi-e a kimenő forgalmat. Ez a döntés az Azure Firewallban vagy a beépített fenyegetésfelderítési szabályokban meghatározott szabályokon alapul.

Az Azure Firewall alternatívája az AKS HTTP-proxy funkció használata. A fürtöt elhagyó összes forgalom a HTTP-proxy IP-címére kerül, amely továbbítja vagy elveti a forgalmat.

Mindkét módszer esetében tekintse át az AKS-hez szükséges kimenő hálózati forgalmi szabályokat .

A Teljes felügyelet vezérlő alól kivételt képez, ha a fürtnek más Azure-erőforrásokkal kell kommunikálnia. Előfordulhat például, hogy a fürtnek le kell kérnie egy frissített lemezképet a tárolóregisztrációs adatbázisból vagy titkos kulcsokat a Key Vaultból. Ezekben a forgatókönyvekben a Private Link használatát javasoljuk. Ennek az az előnye, hogy bizonyos alhálózatok közvetlenül érik el a szolgáltatást, és a fürt és a szolgáltatások közötti forgalom nem halad át az interneten. Hátránya, hogy a Private Linknek extra konfigurációra van szüksége a célszolgáltatás nyilvános végponton való használata helyett. Emellett nem minden Azure-szolgáltatás vagy termék támogatja a Private Linket. Ezekben az esetekben fontolja meg egy virtuális hálózati szolgáltatásvégpont engedélyezését az alhálózaton a szolgáltatás eléréséhez.

Ha a Privát kapcsolat vagy szolgáltatásvégpontok nem választhatók, a nyilvános végpontokon keresztül más szolgáltatásokat is elérhet, és az Azure Firewall szabályai és a célszolgáltatásba beépített tűzfal segítségével szabályozhatja a hozzáférést. Mivel ez a forgalom a tűzfal statikus IP-címén halad át, ezeket a címeket hozzáadhatja a szolgáltatás IP-engedélyezési listájához. Ennek egyik hátránya, hogy az Azure Firewallnak több szabályra van szüksége annak biztosításához, hogy csak egy adott alhálózatból érkező forgalmat engedélyezze. Vegye figyelembe ezeket a címeket, ha több IP-címet tervez a kimenő forgalomhoz az Azure Firewall használatával. Ellenkező esetben elérheti a portok kimerülését. További információ a több IP-cím tervezéséről: Azure Firewall létrehozása több IP-címmel.

Az AKS-alapú referenciaarchitektúra Windows-tárolóiban a Windows-specifikus kimenő forgalommal kapcsolatos szempontokról további információt az AKS-en futó Windows-tárolókban talál.

Pod–pod forgalom

Alapértelmezés szerint a podok a fürt bármely más podjáról fogadhatják a forgalmat. A Kubernetes NetworkPolicy használatával korlátozhatja a podok közötti hálózati forgalmat. A szabályzatok megfontoltan alkalmazhatók, vagy előfordulhat, hogy egy kritikus hálózati folyamat le van tiltva. Csak adott kommunikációs útvonalak, például a bejövőforgalom-vezérlő és a számítási feladat közötti forgalom engedélyezése engedélyezett. További információ: Hálózati szabályzatok.

Engedélyezze a hálózati házirendet a fürt kiépítésekor, mert később nem adhatja hozzá. Néhány lehetőség közül választhat az implementálható NetworkPolicytechnológiákhoz. Az Azure hálózati szabályzatot javasoljuk, amelyhez Azure Container Networking Interface (CNI) szükséges. További információkért lásd a következő megjegyzést. Más lehetőségek közé tartozik a Calico hálózati szabályzat, egy jól ismert nyílt forráskódú lehetőség. Fontolja meg a Calico használatát, ha fürtszintű hálózati szabályzatokat kell kezelnie. Calico-t nem fedi le a standard Azure-támogatás.

További információ: Különbségek az Azure hálózati házirendmotorjai között.

Felügyeleti forgalom

A fürt futtatásának részeként a Kubernetes API-kiszolgáló olyan erőforrásoktól fogadja a forgalmat, amelyek felügyeleti műveleteket szeretnének végezni a fürtön, például a fürt méretezéséhez szükséges erőforrások létrehozására irányuló kérések. Ilyen erőforrások például a buildügynök-készlet egy DevOps-folyamatban, egy Azure Bastion-példány az Azure Bastion alhálózaton belül, és maguk a csomópontkészletek. Ahelyett, hogy minden IP-címről elfogadná ezt a felügyeleti forgalmat, az AKS által engedélyezett IP-tartományok funkcióval csak az engedélyezett IP-tartományokból az API-kiszolgálóra érkező forgalmat engedélyezze.

További információ: API-kiszolgáló által engedélyezett IP-tartományok definiálása.

Egy másik szabályozási réteg esetében a további összetettség árán kiépítheti a privát AKS-fürtöt. Privát fürt használatával biztosíthatja, hogy az API-kiszolgáló és a csomópontkészletek közötti hálózati forgalom csak a magánhálózaton maradjon, és soha ne legyen kitéve az internetnek. További információ: AKS privát fürtök.

Titkos kódok kezelésének hozzáadása

Titkos kulcsokat tárol egy felügyelt kulcstárolóban, például a Key Vaultban. Ennek az az előnye, hogy egy felügyelt kulcstároló kezeli a titkos kulcsok rotálását. Erős titkosítást és hozzáférés-naplózási naplót biztosít. Emellett az alapvető titkos kulcsokat is kizárja az üzembehelyezési folyamatból. Ebben az architektúrában engedélyezve és konfigurálva van egy Key Vault-tűzfal, a Private Link pedig a titkos kulcsokhoz és tanúsítványokhoz hozzáférő Azure-erőforrásokból való csatlakozáskor használható.

A Key Vault jól integrálva van más Azure-szolgáltatásokkal. A titkos kódok eléréséhez használja a szolgáltatások beépített funkcióját. További információ arról, hogy az Application Gateway hogyan fér hozzá a bejövő forgalom TLS-tanúsítványaihoz, tekintse meg a bejövő forgalomról szóló szakaszt.

A Key Vault Azure RBAC-engedélymodellje lehetővé teszi a számítási feladatok identitásainak hozzárendelését a Key Vault Titkos kulcsok felhasználója vagy a Key Vault-olvasó szerepkör-hozzárendeléséhez, és hozzáférhet a titkos kulcsokhoz. További információ: Access Key Vault az RBAC használatával.

Fürt titkos kulcsának elérése

A számítási feladatok identitásainak használatával lehetővé kell tenni, hogy egy pod hozzáférhessen egy adott tár titkos kulcsaihoz. A lekérési folyamat megkönnyítéséhez használjon titkos kulcstár CSI-illesztőprogramot. Amikor a podnak titkos kódra van szüksége, az illesztőprogram csatlakozik a megadott tárolóhoz, lekéri a titkos kulcsot egy köteten, és csatlakoztatja a kötetet a fürtben. A pod ezután lekérheti a titkos kulcsot a kötet fájlrendszeréből.

A CSI-illesztőprogram számos szolgáltatóval rendelkezik a különböző felügyelt üzletek támogatásához. Ez az implementáció a Key Vaultot használja titkos kulcstár CSI-illesztőprogramjával. A bővítmény lekéri a TLS-tanúsítványt a Key Vaultból, és betölti az illesztőprogramot a bejövőforgalom-vezérlőt futtató podba. Ez a művelet a pod létrehozásakor történik, és a kötet mind a nyilvános, mind a titkos kulcsokat tárolja.

Számítási feladatok tárolása

Az architektúra számítási feladatai állapot nélküliek. Ha állapotot kell tárolnia, javasoljuk, hogy a fürtön kívül is őrizze meg. A számítási feladatok állapotára vonatkozó útmutató nem tartozik a jelen cikk hatókörébe.

További információ: Tárolási lehetőségek az AKS-ben lévő alkalmazásokhoz.

Házirendkezelés

Az AKS-fürtök kezelésének hatékony módja az irányítás szabályzatokon keresztüli kényszerítése. A Kubernetes az Open Policy Agent (OPA) Gatekeeper használatával implementálja a szabályzatokat. Az AKS-hez az Azure Policy használatával biztosítson szabályzatokat. Minden szabályzat a hatókörében lévő összes fürtre vonatkozik. Az OPA Gatekeeper kezeli a fürt szabályzatkényszerítését, és naplózza az összes szabályzat-ellenőrzést. A házirend módosításai nem jelennek meg azonnal a fürtben, ezért várjon némi késést.

Az AKS-fürtök kezeléséhez az Azure Policyt a következő műveletekre használhatja:

• Az AKS-fürtök üzembe helyezésének megakadályozása vagy korlátozása egy erőforráscsoportban vagy előfizetésben. Szabványok alkalmazása a szervezet számára. Követhet például egy elnevezési konvenciót, vagy megadhat egy címkét.
• Az AKS-fürt védelme a Kubernetes-hez készült Azure Policy használatával.

Szabályzatok beállításakor alkalmazza őket a számítási feladat követelményei alapján. Vegye figyelembe az alábbi tényezőket:

• Beállítja a szabályzatok gyűjteményét, más néven kezdeményezéseket, vagy egyéni szabályzatokat választ? Az Azure Policy két beépített kezdeményezést biztosít: alapszintű és korlátozott. Minden kezdeményezés az AKS-fürtökre vonatkozó beépített szabályzatok gyűjteménye. Javasoljuk, hogy válasszon ki egy kezdeményezést , és válasszon más házirendeket a fürthöz és a fürttel interakcióban lévő erőforrásokhoz, például a Tárolóregisztrációs adatbázishoz, az Application Gatewayhez vagy a Key Vaulthoz. A szervezet követelményei alapján válasszon szabályzatokat.

• Naplózni vagy megtagadni szeretné a műveletet? Naplózási módban a művelet engedélyezett, de nem megfelelőként van megjelölve. Olyan folyamatokkal rendelkezhet, amelyek rendszeres időközönként ellenőrzik a nem megfelelő állapotokat, és megteszik a szükséges lépéseket. Megtagadás módban a művelet le van tiltva, mert megsérti a szabályzatot. Ügyeljen arra, hogy ezt a módot válassza, mert túl korlátozó lehet ahhoz, hogy a számítási feladat működjön.

• Rendelkezik olyan területekkel a számítási feladatban, amelyeknek nem kellene terv szerint megfelelőnek lenniük? Az Azure Policy képes olyan Kubernetes-névterek megadására, amelyek mentesülnek a szabályzatkényszerítés alól. Javasoljuk, hogy továbbra is alkalmazza a szabályzatokat naplózási módban, hogy tisztában legyen ezekkel a példányokkal.

• Vannak olyan követelményei, amelyekre nem vonatkoznak a beépített szabályzatok? Létrehozhat egy egyéni Azure Policy-definíciót, amely az egyéni OPA Gatekeeper-szabályzatokat alkalmazza. Ne alkalmazzon egyéni szabályzatokat közvetlenül a fürtre. További információ: Egyéni szabályzatdefiníciók létrehozása és hozzárendelése.

• Rendelkezik szervezeti szintű követelményekkel? Ha igen, vegye fel ezeket a szabályzatokat a felügyeleti csoport szintjén. A fürtnek saját számítási feladatra vonatkozó szabályzatokat is hozzá kell rendelnie, még akkor is, ha a szervezet általános szabályzatokkal rendelkezik.

• Hozzárendeli az Azure-szabályzatokat adott hatókörökhöz? Győződjön meg arról, hogy az éles szabályzatok a gyártás előtti környezettel is érvényesítve vannak. Ellenkező esetben az éles környezetben való üzembe helyezés során váratlan további korlátozásokba ütközhet, amelyeket nem számol fel az előgyártás során.

Ez a referencia-implementáció lehetővé teszi az Azure Policyt az AKS-fürt létrehozásakor. A korlátozó kezdeményezés naplózási módban van hozzárendelve, hogy betekintést nyerjen a meg nem felelési viszonyokba.

Az implementáció olyan 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 a rendszerképek csak az üzembe helyezett Tárolóregisztrációs adatbázispéldányból legyenek lekértek. 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.

Annak megfigyeléséhez, hogy az Azure Policy hogyan működik a fürtben, elérheti a névtér összes gatekeeper-system podjának podnaplóit, valamint a azure-policy névtérben lévő kube-system és azure-policy-webhook podok naplóit.

A Windows-specifikus Azure Policy-szempontokról további információt az AKS-szabályzatkezelési cikkben található Windows-tárolókban talál.

Csomópontok és podok méretezhetősége

A növekvő igényeknek megfelelően a Kubernetes horizontális automatikus skálázással horizontálisan felskálázhatja a meglévő csomópontok podjait. Ha a Kubernetes már nem tud több podot ütemezni, a csomópontok számát az AKS-fürt automatikus skálázásával kell növelni. A teljes skálázási megoldásnak rendelkeznie kell a podreplikák és a fürt csomópontszámának skálázására is.

Két módszer létezik: automatikus skálázás vagy manuális skálázás.

Az automatikus skálázás és a manuális megközelítés egyaránt megköveteli a processzorhasználatra vagy az egyéni metrikákra vonatkozó riasztások figyelését és beállítását. A podméretezéshez az alkalmazás operátora a Kubernetes API-k módosításával növelheti vagy csökkentheti a ReplicaSet podreplikák számát. Fürtméretezés esetén egy metódust kell értesíteni, ha a Kubernetes-ütemező meghibásodik. Egy másik módja annak, hogy figyelje a függőben lévő podokat az idő függvényében. A csomópontok számát az Azure CLI-n vagy az Azure Portalon módosíthatja.

Az automatikus skálázási megközelítést javasoljuk, mert ezek közül néhány manuális mechanizmus az automatikus skálázási rendszerbe van beépítve.

Általános módszerként kezdjük a teljesítményteszteléssel a podok és csomópontok minimális számával. Ezekkel az értékekkel állapíthatja meg az alapkonfiguráció várható értékét. Ezután a teljesítménymetrikák és a manuális skálázás kombinációjával keresse meg a szűk keresztmetszeteket, és ismerje meg az alkalmazás skálázásra adott válaszát. Végül ezekkel az adatokkal állíthatja be az automatikus skálázás paramétereit. Az AKS-t használó teljesítmény-finomhangolási forgatókönyvről további információt a Teljesítmény finomhangolási forgatókönyve: Elosztott üzleti tranzakciók című témakörben talál.

A podok automatikus horizontális felskálázási eszköze

A Vízszintes podok automatikus skálázása (HPA) egy Kubernetes-erőforrás, amely skálázza a podok számát.

A HPA-erőforrásban javasoljuk a replikák minimális és maximális számának beállítását. Az értékek korlátozzák az automatikus skálázási korlátokat.

A HPA a processzorhasználat, a memóriahasználat és az egyéni metrikák alapján skálázható. Csak a processzorhasználat van megadva a dobozon kívül. A HorizontalPodAutoscaler definíció a metrikák célértékeit határozza meg. A specifikáció például beállítja a cél CPU-használatot. Miközben a podok futnak, a HPA-vezérlő a Kubernetes Metrics API-val ellenőrzi az egyes podok processzorhasználatát. Összehasonlítja ezt az értéket a célhasználattal, és kiszámítja az arányt. Ezután az arány alapján határozza meg, hogy a podok túlterheltek vagy alul vannak-e helyezve. A Kubernetes-ütemezőre támaszkodik, hogy új podokat rendeljen a csomópontokhoz, vagy távolítsa el a podokat a csomópontokról.

Előfordulhat, hogy egy versenyfeltétel, amelyben a HPA ellenőrzi, mielőtt egy skálázási művelet befejeződne. Az eredmény helytelen arányszámítás lehet. További információ: A skálázási események lehűlése.

Ha a számítási feladat eseményvezérelt, népszerű nyílt forráskódú lehetőség a Kubernetes eseményvezérelt automatikus skálázása (KEDA). Fontolja meg a KEDA-t, ha egy eseményforrás, például az üzenetsor a számítási feladatot hajtja, ahelyett, hogy a számítási feladat processzorhoz kötött vagy memóriaalapú. A KEDA számos eseményforrást vagy skálázót támogat. Használja azoknak az eseményforrásoknak a listáját, amelyeket a KEDA skálázhat a KEDA-skálázókon. A lista tartalmazza az Azure Monitor-skálázót, amely kényelmes módszer a KEDA-számítási feladatok Azure Monitor-metrikák alapján történő skálázására.

Fürtök automatikus méretezése

A fürt automatikus skálázási modulja egy AKS-bővítmény-összetevő, amely skálázza a csomópontkészlet csomópontjainak számát. Adja hozzá a fürt kiépítése során. Minden felhasználói csomópontkészlethez külön fürt automatikus skálázására van szükség.

A Kubernetes-ütemező aktiválja a fürt automatikus skálázását. Ha a Kubernetes-ütemező erőforrás-korlátozások miatt nem tud podot ütemezni, az automatikus skálázó automatikusan kiépít egy új csomópontot a csomópontkészletben. Ezzel szemben a fürt automatikus skálázója ellenőrzi a csomópontok nem használt kapacitását. Ha a csomópont nem a várt kapacitáson fut, a podok át lesznek helyezve egy másik csomópontra, és a nem használt csomópont el lesz távolítva.

Az automatikus skálázás engedélyezésekor állítsa be a csomópontok maximális számát és minimális számát. Az ajánlott értékek a számítási feladat várható teljesítményétől, a fürt növekedésének mértékétől és a költségek következményeitől függenek. A minimális szám az adott csomópontkészlet fenntartott kapacitása. Ebben a referencia-implementációban a minimális érték két értékre van állítva a számítási feladat egyszerűsége miatt.

A rendszercsomópont-készlet esetében az ajánlott minimális érték három.

Az alapkonfigurációs architektúra Windows-specifikus skálázási szempontjairól az AKS-ben található Windows-tárolók című cikkben talál további információt.

Üzletmenet-folytonossági döntések

Az üzletmenet folytonosságának fenntartása érdekében határozza meg az infrastruktúra és az alkalmazás SLO-ját. További információkért tekintse meg a megbízhatósági célok meghatározására vonatkozó javaslatokat. Tekintse át az AKS szolgáltatásiszint-szerződésének (SLA) feltételeit a legújabb SLA-ban online szolgáltatások cikkben.

Fürtcsomópontok

A számítási feladatok minimális rendelkezésre állási szintjének eléréséhez több csomópontra van szükség egy csomópontkészletben. Ha egy csomópont meghibásodik, az ugyanabban a csomópontkészletben és -fürtben lévő másik csomópont továbbra is futtathatja az alkalmazást. A megbízhatóság érdekében három csomópontot ajánlunk a rendszercsomópont-készlethez. A felhasználói csomópontkészlet esetében ne kevesebb, mint két csomóponttal kezdjen. Ha magasabb rendelkezésre állásra van szüksége, további csomópontokat építhet ki.

Elkülönítheti az alkalmazást a rendszerszolgáltatásoktól úgy, hogy egy külön csomópontkészletbe helyezi, más néven felhasználói csomópontkészletbe. Így a Kubernetes-szolgáltatások dedikált csomópontokon futnak, és nem versenyeznek a számítási feladattal. Javasoljuk, hogy címkéket, címkéket és szennyezettségeket használjon a csomópontkészlet azonosításához és a számítási feladatok ütemezéséhez. Győződjön meg arról, hogy a rendszercsomópont-készlet fertőzött a CriticalAddonsOnly fertőzöttséggel.

A fürt rendszeres frissítése, például az időszerű frissítések kulcsfontosságúak a megbízhatóság szempontjából. Azt is javasoljuk, hogy mintavételekkel figyelje a podok állapotát.

Pod rendelkezésre állása

Poderőforrás-követelmények megadása: Javasoljuk, hogy adja meg a poderőforrás-követelményeket az üzemelő példányokban. Az ütemező ezután megfelelően ütemezheti a podot. A megbízhatóság jelentősen csökken, ha a podok nem ütemezhetők.

Podkimaradási költségvetések beállítása: Ez a beállítás határozza meg, hogy egy üzemelő példány hány replikája kerülhet le egy frissítési vagy frissítési esemény során. További információ: Pod-megszakítási költségvetések.

Konfiguráljon több replikát az üzemelő példányban a fennakadások, például a hardverhibák kezelésére. A tervezett események, például frissítések és frissítések esetén a megszakítási költségvetés segíthet biztosítani a podreplikák szükséges számát az alkalmazás várható terhelésének kezeléséhez.

Erőforráskvóták beállítása a számítási feladatok névterén: A névtér erőforráskvótája segít biztosítani, hogy a podkvóták és a korlátok megfelelően legyenek beállítva egy üzemelő példányon. További információ: Erőforráskvóták kényszerítése.

Podkérelmek és korlátok beállítása: A kérések és korlátok beállítása lehetővé teszi, hogy a Kubernetes hatékonyan lefoglalja a processzor- és memóriaerőforrásokat a podokhoz, és lehetővé teszi, hogy a csomópontokon nagyobb tárolósűrűség legyen. A kérések és korlátok növelhetik a megbízhatóságot, miközben csökkentik a költségeket a jobb hardverhasználat miatt.

A számítási feladatok korlátainak becsléséhez tesztelje és állapítsa meg az alapkonfigurációt. Kezdje a kérelmek és a korlátok egyenlő értékeivel. Ezután fokozatosan hangolja ezeket az értékeket, amíg meg nem határoz egy küszöbértéket, amely instabilitást okozhat a fürtben.

Az üzembehelyezési jegyzékekben megadhatja a kérelmeket és a korlátokat. További információ: Podkérelmek és korlátok beállítása.

Rendelkezésre állási zónák és többrégiós támogatás

Bizonyos típusú kimaradások elleni védelemhez használjon rendelkezésre állási zónákat , ha a régió támogatja őket. Ezután a vezérlősík összetevői és a csomópontkészletek csomópontjai is képesek elosztani a zónákat. Ha egy teljes zóna nem érhető el, a régión belüli másik zónában lévő csomópont továbbra is elérhető. Minden csomópontkészlet egy külön virtuálisgép-méretezési csoportra van leképezve, amely kezeli a csomópontpéldányokat és a méretezhetőséget. Az AKS szolgáltatás kezeli a méretezési csoport műveleteit és konfigurációját. Íme néhány szempont, amikor több zónát engedélyez:

• Teljes infrastruktúra: Válasszon egy olyan régiót, amely támogatja a rendelkezésre állási zónákat. További információ: Korlátozások. Az üzemidős SLA használatához ki kell választania a Standard vagy a Premium szintet. A rendelkezésre állási SLA nagyobb rendelkezésre állási zónák használatakor.

• Fürt: A rendelkezésre állási zónákat csak a csomópontkészlet létrehozásakor állíthatja be. Később nem módosíthatók. A csomópontméreteket minden zónában támogatni kell, hogy a várt eloszlás lehetséges legyen. A mögöttes virtuálisgép-méretezési csoport ugyanazt a hardverkonfigurációt biztosítja a zónákban.

  A több zóna támogatása nem csak a csomópontkészletekre vonatkozik, hanem a vezérlősíkra is. Az AKS vezérlősíkja kiterjed a kért zónákra, például a csomópontkészletekre. Ha nem használja a zónatámogatást a fürtben, a vezérlősík összetevői nem garantáltan oszlanak el a rendelkezésre állási zónák között.

• Függő erőforrások: A teljes zónaszintű előnyökhöz minden szolgáltatásfüggőségnek támogatnia kell a zónákat is. Ha egy függő szolgáltatás nem támogatja a zónákat, lehetséges, hogy egy zónahiba a szolgáltatás meghiúsulását okozhatja.

  Egy felügyelt lemez például abban a zónában érhető el, ahol kiépítették. Ha hiba történik, előfordulhat, hogy a csomópont egy másik zónába kerül, de a felügyelt lemez nem kerül a csomóponttal a zónába.

Az architektúra egyszerűsége érdekében az AKS egyetlen régióban van üzembe helyezve, ahol az első, a második és a három rendelkezésre állási zónára kiterjedő csomópontkészletek állnak rendelkezésre. Az infrastruktúra egyéb erőforrásai, például az Azure Firewall és az Application Gateway is ugyanabban a régióban vannak üzembe helyezve, több zónatámogatással. A georeplikációs funkció engedélyezve van a Tárolóregisztrációs adatbázishoz.

Több régió

A rendelkezésre állási zónák engedélyezésekor nem elegendő a lefedettség abban a valószínűtlen esetben, ha egy teljes régió meghibásodik. A magasabb rendelkezésre állás érdekében futtasson több AKS-fürtöt különböző régiókban.

• A párosított régiók előnyben részesíthetők, ha elérhetők. A párosított régiók használatának egyik előnye a platformfrissítések megbízhatósága. Az Azure gondoskodik arról, hogy egyszerre csak egy régió legyen frissítve a párban. Egyes régiókban nincsenek párok. Ha a régiója nincs párosítva, akkor is üzembe helyezhet többrégiós megoldást más használandó régiók kiválasztásával. Fontolja meg egy folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamat használatát, amelyet úgy konfigurál, hogy vezényelje a helyreállítást egy régióhiba miatt. Bizonyos DevOps-eszközök, például a Flux megkönnyítik a többrégiós telepítéseket.

• Adja meg azt a helyet, ahol a redundáns szolgáltatás másodlagos példánya található, ha egy Azure-erőforrás támogatja a georedundanciát. A Tárolóregisztrációs adatbázis georeplikálásának engedélyezésével például automatikusan replikálja a rendszerképeket a kiválasztott Azure-régiókba. Emellett továbbra is hozzáférést biztosít a képekhez, még akkor is, ha az elsődleges régió kimaradásban van.

• Válasszon egy forgalmi útválasztót, amely a követelményeknek megfelelően elosztja a forgalmat zónák vagy régiók között. Ez az architektúra üzembe helyezi a Load Balancert, mert el tudja osztani a nemwebalapú forgalmat a zónák között. Ha régiók közötti forgalmat kell elosztania, fontolja meg az Azure Front Door használatát. További beállításokért lásd: Terheléselosztó kiválasztása.

Vészhelyreállítás

Ha hiba történik az elsődleges régióban, ideális esetben gyorsan létrehozhat egy új példányt egy másik régióban. Íme néhány javaslat:

• Használjon több régiót. Ha az elsődleges régió rendelkezik párosított régióval, használja ezt a párt. Ha nem, válassza ki a régiókat az adattárolási és késési követelmények alapján.

• Használjon olyan nem statisztikai számítási feladatot, amelyet hatékonyan replikálhat. Ha az állapotot a fürtben kell tárolnia, amelyet nem ajánlunk, győződjön meg arról, hogy gyakran készít biztonsági másolatot az adatokról egy másik régióban.

• Integrálja a helyreállítási stratégiát, például replikálást egy másik régióba a DevOps-folyamat részeként, hogy megfeleljen az SLO-nak.

• Az egyes Azure-szolgáltatások kiépítése a vészhelyreállítást támogató funkciókkal. Ebben az architektúrában például a Tárolóregisztrációs adatbázis engedélyezve van a georeplikációs szolgáltatáshoz. Ha egy régió meghibásodik, továbbra is lekérheti a rendszerképeket a replikált régióból.

• Telepítse az infrastruktúrát kódként, beleértve az AKS-fürtöt és minden más szükséges összetevőt. Ha egy másik régióban kell üzembe helyeznie, a szkripteket vagy sablonokat újra felhasználhatja egy azonos példány létrehozásához.

Fürt biztonsági mentése

Számos architektúra esetén kiépíthet egy új fürtöt, és visszaállíthatja azt az üzemeltetési állapotba a Git operations-alapú fürt rendszerindításával, majd az alkalmazás üzembe helyezésével. Ha azonban kritikus erőforrásállapot van, például konfigurációs térképek, feladatok és titkos kódok, amelyeket nem lehet rögzíteni a rendszerindítási folyamat során, fontolja meg a helyreállítási stratégiát. Javasoljuk, hogy állapot nélküli számítási feladatokat futtasson a Kubernetesben. Ha az architektúra lemezalapú állapotot tartalmaz, figyelembe kell vennie a tartalom helyreállítási stratégiáját is.

Ha a fürt biztonsági mentésének a helyreállítási stratégia részét kell képeznie, telepítenie kell egy olyan megoldást, amely megfelel a fürt üzleti követelményeinek. Ez az ügynök felelős azért, hogy a fürterőforrás-állapotot az Ön által választott célhelyre küldje, és koordinálja az Azure lemezalapú, állandó kötet pillanatképeit.

A VMware Velero egy olyan gyakori Kubernetes biztonsági mentési megoldás, amelyet közvetlenül telepíthet és kezelhet. Vagy az AKS biztonsági mentési bővítményével felügyelt Velero-implementációt biztosíthat. Az AKS biztonsági mentési bővítmény támogatja mind a Kubernetes-erőforrások, mind az állandó kötetek biztonsági mentését, az ütemezések és a biztonsági mentés hatóköre pedig az Azure Backup tárolókonfigurációjaként van kiterjesztve.

A referencia-implementáció nem implementálja a biztonsági mentést, amely további Azure-erőforrásokat foglal magában a felügyelethez, monitorozáshoz, vásárláshoz és biztonsághoz. Ezek az erőforrások közé tartozhat egy Azure Storage-fiók, egy Azure Backup-tároló és -konfiguráció, valamint a megbízható hozzáférési funkció. Ehelyett a Git-műveletek az állapot nélküli számítási feladatok futtatásának szándékával kombinálva a helyreállítási megoldás.

Válasszon és érvényesítsen egy olyan biztonsági mentési megoldást, amely megfelel az üzleti célkitűzésnek, beleértve a meghatározott helyreállítási pont célkitűzését és a helyreállítási idő célkitűzését. Definiálja a helyreállítási folyamatot egy csapat runbookban, és gyakorolja az összes üzleti szempontból kritikus számítási feladat esetében.

Kubernetes API server SLA

Az AKS ingyenes szolgáltatásként is használható, de ez a szint nem kínál pénzügyileg támogatott SLA-t. Az SLA beszerzéséhez ki kell választania a Standard szintet. Javasoljuk, hogy minden éles fürt használja a Standard szintet. Csak a kritikus fontosságú számítási feladatokhoz foglalja le az ingyenes szintet az előkészületi fürtökhöz, a Prémium szintet pedig csak a kritikus fontosságú számítási feladatokhoz. Az Azure rendelkezésre állási zónáinak használata esetén a Kubernetes API-kiszolgáló SLA-ja magasabb. A csomópontkészleteket és más erőforrásokat saját SLA-k fedik le. Az egyes szolgáltatásokhoz tartozó SLA-król az online szolgáltatások SLA-jában talál további információt.

Üzlet

Az architektúra zónákban és különösen régiókban történő üzembe helyezéséhez rendelkezésre állási költségekkel kapcsolatos kompromisszumok állnak fenn. Egyes replikációs funkciók, például a tárolóregisztrációs adatbázisban való georeplikálás, prémium termékváltozatokban érhetők el, ami drágább. A többrégiós üzemelő példányok esetében a költség is nő, mivel a sávszélesség díjai akkor érvényesek, ha a forgalom régiók között mozog.

Emellett további hálózati késésre számíthat a zónák vagy régiók közötti csomópont-kommunikációban. Mérje meg ennek az architekturális döntésnek a számítási feladatra gyakorolt hatását.

Tesztelés szimulációkkal és kényszerített feladatátvétellel

A megoldás megbízhatóságának tesztelése kényszerített feladatátvételi teszteléssel szimulált leállások esetén. A szimulációk magukban foglalhatják egy csomópont leállítását, egy adott zónában lévő összes AKS-erőforrás leállítását egy zonális hiba szimulálásához, vagy külső függőségi hiba meghívását. Az Azure Chaos Studio használatával különböző típusú kimaradásokat szimulálhat az Azure-ban és a fürtön.

További információ: Chaos Studio.

Metrikák monitorozása és gyűjtése

Javasoljuk, hogy az Azure Monitor tárolóelemzései monitorozzák a tároló számítási feladatainak teljesítményét, mert valós időben tekintheti meg az eseményeket. Rögzíti a tárolónaplókat a futó podokból, és összesíti őket megtekintésre. Emellett adatokat gyűjt a Metrics API-ból a memória- és processzorhasználatról az erőforrások és számítási feladatok állapotának figyelése érdekében. A tárolóelemzésekkel a podok méretezése során is figyelheti a teljesítményt. Olyan telemetriai adatokat tartalmaz, amelyek kritikus fontosságúak az összegyűjtött adatok monitorozásához, elemzéséhez és vizualizációihoz. A Container Insights azonosítja a trendeket, és lehetővé teszi a riasztások konfigurálását, hogy proaktív értesítéseket kapjon a kritikus problémákról.

A podokban üzemeltetett számítási feladatok többsége Prometheus-metrikákat bocsát ki. A tárolóelemzések integrálhatók a Prometheussal. Megtekintheti a csomópontokból és a Kubernetesből gyűjtött alkalmazás- és számítási feladatok metrikáit.

Egyes nem Microsoft-megoldások integrálhatók a Kubernetes szolgáltatással, például a Datadog, a Grafana vagy a New Relic használatával. Így ha szervezete már használja ezeket a megoldásokat, kihasználhatja azokat.

Az AKS-sel az Azure felügyeli az alapvető Kubernetes-szolgáltatásokat. Az Azure erőforrásnaplóként implementálja az AKS vezérlősík-összetevőinek naplóit. Javasoljuk, hogy a legtöbb fürtön engedélyezze az alábbi beállításokat. A lehetőségek segíthetnek a fürtproblémák elhárításában, és viszonylag alacsony a naplósűrűségük.

• ClusterAutoscaler: a naplózással megfigyelhetővé válnak a skálázási műveletek. További információ: A fürt automatikus skálázási naplóinak és állapotának lekérése.
• KubeControllerManager: megfigyelheti a Kubernetes és az Azure vezérlősík közötti interakciót.
• kube-audit-admin: megfigyelhetővé válnak a fürtöt módosító tevékenységek. Nincs ok arra, hogy mindkettő kube-audit kube-audit-admin engedélyezve legyen. kube-audit a nonmodify (olvasási) műveleteket is magában foglaló szuperhalmaz kube-audit-admin .
• guard: rögzítse a Microsoft Entra-azonosítót és az Azure RBAC-auditokat.

Hasznos lehet, ha más naplókategóriákat is engedélyez, például KubeScheduler kube-audita fürt vagy a számítási feladatok életciklusának korai fejlesztése során. A hozzáadott fürt automatikus skálázása, a podok elhelyezése és ütemezése, valamint a hasonló adatok segíthetnek a fürt- vagy számítási feladatok üzemeltetési problémáinak elhárításában. Ha azonban a kiterjesztett hibaelhárítási naplókat a hibaelhárítási igények befejeződése után teljes munkaidőben tartja, előfordulhat, hogy szükségtelen költségekkel jár az adatok betöltése és tárolása az Azure Monitorban.

Bár az Azure Monitor számos meglévő napló lekérdezést tartalmaz, amelyekből kiindulhat, alapként is használhatja őket a saját lekérdezések létrehozásához. A tár növekedésével egy vagy több lekérdezéscsomag használatával mentheti és újra felhasználhatja a napló lekérdezéseit. A lekérdezések egyéni tára jobban megfigyelhetővé teszi az AKS-fürtök állapotát és teljesítményét. Támogatja az SLO-k elérését.

Az AKS monitorozási ajánlott eljárásairól további információt az AKS monitorozása az Azure Monitorral című témakörben talál.

A Windows-specifikus figyelési szempontokról további információt az AKS-en futó Windows-tárolókban talál.

Hálózati metrikák

Az alapszintű, fürtszintű hálózati metrikák natív platformon és Prometheus-metrikákon keresztül érhetők el. A Network Observability bővítményt a hálózati metrikák csomópontszinten való megjelenítéséhez is használhatja. A legtöbb fürtnek a Hálózatmegfigyelési bővítményt kell használnia, hogy további hálózati hibaelhárítási képességeket biztosítson, és észlelje a nem várt hálózati használatot vagy problémákat a csomópont szintjén.

Az átviteli vezérlési protokollra (TCP) vagy a User Datagram Protocolra (UDP) vonatkozó csomagvesztésre, késésre vagy DNS-nyomásra rendkívül érzékeny számítási feladatok esetében a podszintű hálózati metrikák fontosak. Az AKS-ben ezt a részletességi szintet az Advanced Network Observability funkcióval találja meg. A legtöbb számítási feladathoz nincs szükség ilyen mélységű hálózati megfigyelhetőségre. Csak akkor telepítse az Advanced Network Observability bővítményt, ha a podok nagy mértékben optimalizált hálózatot igényelnek, és a csomagszintig bizalmasak.

Öngyógyítás engedélyezése

A podok állapotának monitorozása élő és készültségi mintavételek beállításával. Ha a Kubernetes nem válaszoló podot észlel, újraindítja a podot. Az élőség-mintavétel meghatározza, hogy a pod kifogástalan állapotban van-e. Ha a Kubernetes nem válaszoló podot észlel, újraindítja a podot. A készültségi mintavétel meghatározza, hogy a pod készen áll-e a kérések és a forgalom fogadására.

AKS-fürtök rutinfrissítései

A Kubernetes-fürtök 2. napi műveleteinek része a rutinplatform- és operációsrendszer-frissítések végrehajtása. Minden AKS-fürtön három frissítési réteget kell kezelni:

• A Kubernetes-verzió (például a Kubernetes 1.30.3–1.30.7 vagy a Kubernetes 1.30.7–1.31.1), amely a Kubernetes API módosításaival és elavulásaival járhat. A réteg verzióváltozásai a teljes fürtöt érintik.
• A virtuális merevlemez (VHD) lemezképe minden csomóponton, amely egyesíti az operációs rendszer frissítéseit és az AKS-összetevők frissítéseit. Ezeket a frissítéseket a rendszer a fürt Kubernetes-verzióján teszteli. A réteg verzióváltozásai a csomópontkészlet szintjén lesznek alkalmazva, és nem érintik a Kubernetes-verziót.
• Az operációs rendszer saját natív frissítési folyamata, például a Windows Update vagy apta . Az operációs rendszer szállítója közvetlenül látja el ezeket a frissítéseket, és nem teszteli őket a fürt Kubernetes-verzióján. A réteg verzióváltozásai egyetlen csomópontot érintenek, és nem érintik a Kubernetes-verziót.

Ezek a rétegek egymástól függetlenül vannak vezérelve. Ön dönti el, hogy az egyes rétegek hogyan lesznek kezelve a számítási feladat fürtöihez. Adja meg, hogy az egyes AKS-fürtök, csomópontkészletei vagy csomópontjai milyen gyakran frissülnek (az ütemezés). Azt is meg kell adni, hogy milyen napok vagy időpontok vonatkoznak a frissítésekre (a karbantartási időszakra). Adja meg, hogy a frissítések manuálisan vagy automatikusan telepíthetők-e, vagy egyáltalán nem. Ugyanúgy, mint a fürtön futó számítási feladatnak is szüksége van egy biztonságos üzembehelyezési gyakorlatra, a fürtök frissítéséhez is.

A javítással és frissítéssel kapcsolatos átfogó perspektíváért tekintse meg az AKS-javítással és a frissítéssel kapcsolatos útmutatót az AKS 2. napjának üzemeltetési útmutatójában. Az architektúrával kapcsolatos alapkonfiguráció-javaslatokhoz használja az alábbi információkat.

Nem módosítható infrastruktúra

Az AKS-fürtöket nem módosítható infrastruktúraként üzemeltető számítási feladatok nem frissítik automatikusan vagy manuálisan a fürtöket. Állítsa be a csomópont lemezképének frissítését , none és a fürt automatikus frissítését a következőre none: . Ebben a konfigurációban kizárólag Ön felelős az összes rétegben történő frissítésért. Amikor elérhetővé válik egy kívánt frissítés, tesztelnie kell a frissítést egy előkészületi környezetben, és értékelnie kell annak kompatibilitását egy új fürtön. Ezután helyezzen üzembe egy éles replikabélyeget, amely tartalmazza a frissített AKS-verziót és a csomópontkészlet virtuális merevlemezeit. Amikor az új éles fürt készen áll, a régi fürt le lesz ürítve, és végül leszerelésre kerül.

Az új infrastruktúra rendszeres üzembe helyezésével nem módosítható infrastruktúra az egyetlen olyan helyzet, amikor egy éles fürtre nem alkalmazható helyszíni frissítési stratégia. Minden más fürtnek helyben történő frissítési stratégiával kell rendelkeznie.

Helyszíni frissítések

Az AKS-fürtöket nem módosítható infrastruktúraként üzemeltető számítási feladatoknak rendszeresen frissíteniük kell a futó fürtöket, hogy mind a három réteget kezelni tudják. A frissítési folyamat igazítása a számítási feladat követelményeihez. A rutinfrissítési folyamat megtervezéséhez használja az alábbi javaslatokat.

• Ütemezze az AKS tervezett karbantartási funkcióját, hogy szabályozhassa a fürt frissítéseit. Ez a funkció lehetővé teszi a frissítések, egy eredendően kockázatos művelet, szabályozott időben történő végrehajtását, hogy csökkentse a váratlan hibák hatását.
• Konfiguráljon podkimaradási költségvetéseket , hogy az alkalmazás stabil maradjon a működés közbeni frissítések során. Ne konfigurálja azonban úgy a költségvetéseket, hogy olyan agresszívak legyenek, hogy megakadályozzák a csomópontok frissítését, mert a legtöbb frissítéshez kordon és leeresztési folyamat szükséges minden csomóponton.
• Ellenőrizze az Azure-erőforráskvótát és az erőforrások rendelkezésre állását. A helyszíni frissítések a régi csomópontok eltávolítása előtt üzembe helyezik a csomópontok új példányait, más néven túlfeszültség-csomópontokat. Ez azt jelenti, hogy az Azure-kvótának és az IP-címtartománynak elérhetőnek kell lennie az új csomópontokhoz. A 33%-os túlfeszültség jó kiindulópont a legtöbb számítási feladathoz.
• Tesztelje az eszközökkel való kompatibilitást, például a fürthöz hozzáadott szolgáltatáshálókat vagy biztonsági ügynököket. Tesztelje a számítási feladat összetevőit, például a bejövőforgalom-vezérlőket, a szolgáltatáshálókat és a számítási feladat podjait. Teszteket hajt végre egy előkészületi környezetben.

Csomópontok helyszíni frissítései

Használja az automatikus frissítési NodeImage csatornát a csomópont operációsrendszer-lemezképeinek frissítéséhez. Ez a csatorna úgy konfigurálja a fürtöt, hogy minden csomóponton frissítse a VHD-t csomópontszintű frissítésekkel. A Microsoft teszteli a frissítéseket az AKS-verzión. Windows-csomópontok esetén a frissítések havonta körülbelül egyszer történnek. Linux-csomópontok esetén ezek a frissítések hetente körülbelül egyszer történnek.

• A frissítések soha nem módosítják az AKS- vagy a Kubernetes-verziót, így a Kubernetes API kompatibilitása nem okoz gondot.
• Ha frissítési csatornaként használja NodeImage , az tiszteletben tartja a tervezett karbantartási időszakot, amelyet hetente legalább egyszer be kell állítania. Állítsa be, függetlenül attól, hogy milyen csomópontrendszerkép-operációs rendszert használ az időben történő alkalmazás biztosításához.
• Ezek a frissítések közé tartoznak az operációs rendszerszintű biztonsági, kompatibilitási és funkcionális frissítések, az operációs rendszer konfigurációs beállításai és az AKS-összetevők frissítései.
• A rendszerkép-kiadásokat és azok összetevőinek verziószámait az AKS kiadáskövetésével követjük nyomon.

Ha a fürt biztonsági követelményei agresszívebb javítási ütemet igényelnek, és a fürt el tudja viselni a lehetséges megszakításokat, használja inkább a frissítési SecurityPatch csatornát. A Microsoft ezeket a frissítéseket is teszteli. A frissítések csak akkor jelennek meg, ha vannak olyan biztonsági frissítések, amelyeket a Microsoft elég fontosnak tart ahhoz, hogy a csomópont következő ütemezett lemezképének frissítése előtt megjelenjenek. A csatorna használatakor SecurityPatch a csatorna által kapott frissítéseket NodeImage is megkapja. A SecurityPatch csatornabeállítás továbbra is tiszteletben tartja a karbantartási időszakokat, ezért a váratlan biztonsági frissítések támogatásához győződjön meg arról, hogy a karbantartási időszak gyakoribb (például napi vagy kétnapos) hiányosságokkal rendelkezik.

A legtöbb helyszíni frissítést használó fürtnek kerülnie kell a csomópont lemezkép-frissítési None Unmanaged csatornájának beállításait.

A fürt helyszíni frissítései

A Kubernetes egy gyorsan fejlődő platform, és a rendszeres frissítések fontos biztonsági javításokat és új képességeket hoznak létre. Fontos, hogy a Kubernetes-frissítések naprakészek maradjanak. A két legújabb verzióban vagy az N-2-ben kell maradnia. Kritikus fontosságú, hogy a Kubernetes legújabb verziójára frissítsen, mert az új verziók gyakran jelennek meg.

A legtöbb fürtnek elegendő óvatossággal és szigorúsággal képesnek kell lennie a helyszíni AKS-verziófrissítések végrehajtására. A helyszíni AKS-verziófrissítések kockázatának mérséklése többnyire a megfelelő előkészületi teszteléssel, a kvótaérvényesítéssel és a podkimaradás költségvetésének konfigurálásával csökkenthető. A helyszíni frissítések azonban váratlan viselkedést eredményezhetnek. Ha a helyszíni frissítések túl kockázatosnak minősülnek a számítási feladat számára, javasoljuk, hogy a fennmaradó javaslatok követése helyett az AKS-fürtök kék-zöld üzembe helyezését használja.

Javasoljuk, hogy kubernetes-fürt első üzembe helyezésekor kerülje a fürt automatikus frissítési funkcióját. Használjon manuális megközelítést, amely lehetővé teszi az AKS-fürt új verziójának tesztelését az üzem előtti környezetekben, mielőtt a frissítések az éles környezetbe érnek. Ez a megközelítés a kiszámíthatóság és az ellenőrzés legnagyobb szintjét is eléri. Azonban szorgalmasnak kell lennie a Kubernetes platform új frissítéseinek figyelése és az új verziók gyors bevezetése során. Jobb, ha hosszú távú támogatási megközelítéssel "naprakész" gondolkodásmódot vezet be.

Ha új AKS-verzió érhető el a fürthöz, az Azure Event Grid AKS rendszertémakörével értesítést kaphat. A referencia-implementáció telepíti ezt az Event Grid rendszertémakört, hogy az eseményre előfizethesse az eseményt az Microsoft.ContainerService.NewKubernetesVersionAvailable eseménystream értesítési megoldásából. Tekintse át az AKS kibocsátási megjegyzéseit a kompatibilitással kapcsolatos konkrét problémákról, a viselkedés változásairól vagy a funkciók elavulásáról.

Végül a Kubernetes-kiadásokkal, az AKS-kiadásokkal, a fürttel, a fürtszintű összetevőkkel és a számítási feladattal kapcsolatos megbízhatósági pontot érhet el az automatikus frissítési funkció megismeréséhez. Az éles rendszerek esetében ritkán lépnénk túl patch. Emellett az AKS-verzió automatikus frissítésekor ellenőrizze az infrastruktúrát is a fürt kód (IaC) AKS-verzióbeállításaként, hogy ne legyenek szinkronizálva. Konfigurálja a tervezett karbantartási időszakot az automatikus frissítési művelet támogatásához.

Biztonsági felügyelet

A tárolóinfrastruktúra figyelése az aktív fenyegetések és a potenciális biztonsági kockázatok szempontjából is. Íme néhány erőforrás:

• A Microsoft Defender for Containers segítségével azonosíthatja és szervizelheti Felhőhöz készült Defender tárolólemezképekre vonatkozó javaslatait.
• A Defender for Containers rendszeresen ellenőrzi a tárolólemezképeket a biztonsági rések keresése érdekében.
• A Defender for Containers valós idejű biztonsági riasztásokat is generál a gyanús tevékenységekhez.
• Az alkalmazások és fürtök AKS-biztonsági fogalmai részletesen ismertetik , hogyan védi a tárolóbiztonság a teljes teljes folyamatot a buildeléstől az AKS-ben futó alkalmazásterhelésekig.

Fürt- és számítási feladatok műveletei

A fürt- és számítási feladatok üzemeltetésével (DevOps) kapcsolatos szempontokért tekintse meg az Operational Excellence tervezési alapelveinek pillérét.

Fürt rendszerindítása

A kiépítés után egy működő fürtje van, de előfordulhat, hogy a számítási feladatok üzembe helyezése előtt még rendelkezik néhány szükséges lépéssel. A fürt előkészítésének folyamatát bootstrappingnek nevezzük. A rendszerindítás feltételes rendszerképek fürtcsomópontokon való üzembe helyezéséből, névterek létrehozásával és a szervezet használati esetének követelményeinek megfelelő egyéb feladatok elvégzéséből állhat.

A kiépített fürt és a megfelelően konfigurált fürt közötti szakadék csökkentése érdekében a fürtüzemeltetőknek át kell gondolniuk, hogyan néz ki az egyedi rendszerindítási folyamatuk. Előzetesen elő kell készíteniük a vonatkozó eszközöket. Ha például fontos, hogy a Kured minden csomóponton futjon az alkalmazás számítási feladatainak üzembe helyezése előtt, a fürt operátorának ellenőriznie kell, hogy a cél Kured rendszerképet tartalmazó Container Registry-példány már létezik-e a fürt kiépítése előtt .

A rendszerindítási folyamatot az alábbi módszerek egyikével konfigurálhatja:

• GitOps Flux v2 fürtbővítmény
• Pipelines
• Önkonfigurálás Flux vagy Argo CD-vel, például

Az AKS-hez készült GitOps Flux v2 fürtbővítmény használatának egyik fő előnye, hogy gyakorlatilag nincs különbség a kiépített fürt és a boottrapped fürt között. A jövőben szilárd felügyeleti alapokkal állítja be a környezetet, és azt is támogatja, hogy a rendszerindítást erőforrássablonokként használja az IaC-stratégiához való igazodáshoz.

Végül a bővítmény használatakor a kubectl nem szükséges a rendszerindítási folyamat egyik szakaszához sem. A kubectl-alapú hozzáférést vészhelyzeti törésjavítási helyzetekben is fenntarthatja. Az Azure-erőforrásdefiníciók sablonjai és a jegyzékek GitOps-bővítményen keresztüli rendszerindítása között a kubectl használata nélkül is elvégezhet minden normál konfigurációs tevékenységet.

Számítási feladatok elkülönítése

Ossza el a számítási feladatot csapatok és erőforrástípusok szerint az egyes részek egyenkénti kezeléséhez.

Kezdje egy alapszintű számítási feladattal, amely tartalmazza az alapvető összetevőket, és építsen rá. A kezdeti feladat a hálózatkezelés konfigurálása. Virtuális hálózatok kiépítése a központ és küllők számára, valamint alhálózatok kiépítése ezeken a hálózatokon belül. Egy küllő például külön alhálózatokkal rendelkezik a rendszer- és felhasználói csomópontkészletekhez, valamint a bejövő erőforrásokhoz. Helyezzen üzembe egy alhálózatot az Azure Firewallhoz a központban.

Egy másik feladat az alapszintű számítási feladat integrálása a Microsoft Entra-azonosítóval.

IaC használata

Lehetőség szerint válasszon egy idempotens deklaratív módszert egy imperatív megközelítésen keresztül. A konfigurációs beállításokat megadó parancsok sorozatának írása helyett használjon deklaratív szintaxist, amely leírja az erőforrásokat és azok tulajdonságait. Használhat Bicep-, Azure Resource Manager-sablonokat (ARM-sablonokat) vagy Terraform-sablonokat.

Ügyeljen arra, hogy a szabályozási szabályzatok alapján erőforrásokat építsen ki. Ha például a virtuálisgép-méreteket választja ki, a költségkorlátozásokon és a rendelkezésre állási zónákon belül kell maradnia, hogy megfeleljenek az alkalmazás követelményeinek. Az Azure Policy használatával is kikényszerítheti a szervezet szabályzatait ezekre a döntésekre.

Ha parancssorozatot kell írnia, használja az Azure CLI-t. Ezek a parancsok számos Azure-szolgáltatást fednek le, és szkriptekkel automatizálhatók. A Windows és a Linux támogatja az Azure CLI-t. Egy másik platformfüggetlen lehetőség az Azure PowerShell. A választás az előnyben részesített képességkészlettől függ.

Tárolja és verziószámozza a szkripteket és sablonfájlokat a forrásvezérlő rendszerben.

Számítási feladat CI/CD

A munkafolyamatokhoz és az üzembe helyezéshez szükséges folyamatoknak folyamatosan képesnek kell lenniük alkalmazások létrehozására és üzembe helyezésére. A frissítéseknek biztonságosan és gyorsan kell üzembe helyezni, és vissza kell állítaniuk, ha problémák merülnek fel.

Az üzembehelyezési stratégiának megbízható és automatizált folyamatos kézbesítési folyamatot kell tartalmaznia. A számítási feladatok tárolólemezképeinek módosításait automatikusan üzembe helyezheti a fürtön.

Ebben az architektúrában a GitHub Actions kezeli a munkafolyamatot és az üzembe helyezést. Más népszerű lehetőségek közé tartozik az Azure DevOps és a Jenkins.

Fürt CI/CD

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

A kubectlhez hasonló imperatív megközelítés helyett használjon olyan eszközöket, amelyek automatikusan szinkronizálják a fürtöt és az adattár módosításait. A munkafolyamat kezeléséhez, például egy új verzió kiadásához és az adott verzió érvényesítéséhez az éles üzembe helyezés előtt fontolja meg a GitOps-folyamatot.

A CI/CD-folyamat alapvető része egy újonnan kiépített fürt indítása. A GitOps-megközelítés azért hasznos, mert lehetővé teszi, hogy az operátorok deklaratív módon definiálják a rendszerindítási folyamatot az IaC-stratégia részeként, és automatikusan lássák a fürtben tükröződő konfigurációt.

A GitOps használatakor a rendszer egy ügynököt helyez üzembe a fürtben, hogy meggyőződjön arról, hogy a fürt állapota a privát Git-adattárban tárolt konfigurációval van összehangolva. Az egyik ilyen ügynök a fluxus, amely a fürt egy vagy több operátorát használja a Kubernetesen belüli üzembe helyezések aktiválásához. A Flux a következő feladatokat végzi el:

• Figyeli az összes konfigurált adattárat.
• Új konfigurációmódosításokat észlel.
• Központi telepítéseket indít el.
• A módosítások alapján frissíti a kívánt futó konfigurációt.

Beállíthat olyan szabályzatokat is, amelyek szabályozzák a módosítások üzembe helyezését.

Az alábbi példa bemutatja, hogyan automatizálhatja a fürtkonfigurációt a GitOps és a Flux használatával:

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

1. A fejlesztő véglegesíti a forráskód módosításait, például a Git-adattárban tárolt konfigurációs YAML-fájlokat. Ezután a rendszer leküldi a módosításokat egy Git-kiszolgálóra.

2. A Flux egy podban fut a számítási feladat mellett. A Flux írásvédett hozzáféréssel rendelkezik a Git-adattárhoz, így meggyőződhet arról, hogy a Flux csak a fejlesztők által kért módosításokat alkalmazza.

3. A Flux felismeri a konfiguráció változásait, és kubectl-parancsokkal alkalmazza ezeket a módosításokat.

4. A fejlesztőknek nincs közvetlen hozzáférésük a Kubernetes API-hoz a kubectlen keresztül.

Rendelkezhet ágszabályzatokkal a Git-kiszolgálón, így több fejlesztő is jóváhagyhatja a módosításokat egy lekéréses kérelemben, mielőtt a módosítás éles környezetben alkalmazva lenne.

Bár manuálisan is konfigurálhatja a GitOpst és a Fluxot, az AKS-hez a Flux v2 fürtbővítményt javasoljuk.

Számítási feladatok és fürtök üzembe helyezési stratégiái

Helyezzen üzembe minden módosítást, például az architektúra összetevőit, a számítási feladatokat és a fürtkonfigurációt legalább egy előre elkészített AKS-fürtön. Ez szimulálja a módosítást, és azonosíthatja a problémákat, mielőtt üzembe helyezné őket az éles környezetben.

A következő lépés előtt minden szakaszban futtassa a teszteket és az érvényesítéseket. Segít biztosítani, hogy a frissítéseket szigorúan ellenőrzött módon küldje le az éles környezetbe, és minimalizálja a váratlan üzembe helyezési problémák miatti fennakadásokat. Az üzembe helyezésnek az éleshez hasonló mintát kell követnie ugyanazzal a GitHub Actions-folyamattal vagy Flux-operátorokkal.

A fejlett üzembehelyezési technikák, például a kék-zöld üzembe helyezés, az A/B-tesztelés és a kanári-kiadások további folyamatokat és esetleg további eszközöket igényelnek. A Flagger egy népszerű nyílt forráskódú megoldás, amely segít megoldani a speciális üzembe helyezési forgatókönyveket.

Költségkezelés

Első lépésként tekintse át a költségoptimalizálás tervezési ellenőrzőlistáját és az AKS-hez készült Well-Architected Frameworkben ismertetett javaslatok listáját. Az Azure díjkalkulátorával megbecsülheti az architektúrában használt szolgáltatások költségeit. További ajánlott eljárásokért tekintse meg a Költségoptimalizálás című témakört.

Fontolja meg az AKS-költségelemzés használatát a kubernetes-specifikus szerkezetek részletes fürtinfrastruktúra-költségfelosztásához.

A Windows-specifikus költségkezelési szempontokról további információt az AKS-en futó Windows-tárolókban talál.

Üzembe helyezés

• Ismerje meg, hogy honnan származnak a költségek. Az AKS-hez minimális költségek tartoznak a Kubernetes-fürt üzembe helyezése, kezelése és üzemeltetése során. A költségekre a fürt által felhasznált virtuálisgép-példányok, tárhelyek, naplóadatok és hálózati erőforrások lesznek hatással. Érdemes lehet olcsóbb virtuális gépeket választani a rendszercsomópont-készletekhez. A DS2_v2 sorozat a rendszercsomópontkészlet tipikus virtuálisgép-típusa.

• A fejlesztési/tesztelési és éles környezetekhez nem ugyanazzal a konfigurációval rendelkezik. Az éles számítási feladatok extra követelményeket támasztanak a magas rendelkezésre álláshoz, és általában drágábbak. Ez a konfiguráció nem szükséges a fejlesztői/tesztelési környezetben.

• Adjon hozzá egy üzemidős SLA-t az éles számítási feladatokhoz. Vannak azonban megtakarítások a fejlesztési/tesztelési vagy kísérleti számítási feladatokhoz tervezett fürtök esetében, ahol a rendelkezésre állás nem szükséges. Az SLO például elegendő. Emellett, ha a számítási feladat támogatja, fontolja meg a kihasználatlan virtuális gépeket futtató dedikált kihasználatlan csomópontkészletek használatát.

  Az Azure SQL Database-t vagy Azure-alkalmazás szolgáltatást az AKS számítási feladatarchitektúrájának részeként tartalmazó nem gyártási számítási feladatok esetén értékelje ki, hogy jogosult-e az Azure Dev/Test-előfizetések használatára a szolgáltatáskedvezmények igénybevételéhez.

• Hozzon létre egy fürtöt a csomópontok minimális számával, és engedélyezze, hogy a fürt automatikus skálázója monitorozza és méretezési döntéseket hozzon ahelyett, hogy túlméretezett fürttel kezdené a skálázási igényeket.

• Állítsa be a podkérelmeket és a korlátokat, hogy a Kubernetes nagyobb sűrűségű csomópont-erőforrásokat foglaljon le, hogy hardvert használjon a kapacitáshoz.

• Vegye figyelembe, hogy a fürt diagnosztikáinak engedélyezése növelheti a költségeket.

• Kötelezze el magát egy vagy hároméves fenntartott Azure-beli virtuálisgép-példányok mellett, hogy csökkentse a csomópont költségeit, ha a számítási feladatnak hosszú ideig kell léteznie. További információ: Költségek mentése fenntartott Azure-beli virtuálisgép-példányokkal.

• Csomópontkészletek létrehozásakor használjon címkéket. A címkék segítenek egyéni jelentések létrehozásában a felmerülő költségek nyomon követéséhez. Címkékkel nyomon követheti a teljes költségeket, és leképzheti a költségeket egy adott erőforrásra vagy csapatra. Ha a fürtöt megosztották a csapatok között, a megosztott felhőszolgáltatások forgalmi díjas költségeinek azonosítása érdekében fogyasztónkénti költségtérítési jelentéseket készíthet. További információ: A csomópontkészletek szennyezettségének, címkéjének vagy címkéjének megadása.

• További sávszélesség-költségekkel számolhat, ha a számítási feladatok többrégiósak, és régiók között replikálja az adatokat. További információ: Sávszélesség díjszabása.

• Költségvetéseket hozhat létre, hogy a szervezet által meghatározott költségkorlátokon belül maradjon. Költségvetéseket a Microsoft Cost Management használatával hozhat létre. Riasztásokat is létrehozhat, hogy értesítéseket kapjon bizonyos küszöbértékek túllépésekor. További információ: Költségvetés létrehozása sablonnal.

Monitor

A teljes fürtöt és a számítási, tárolási, sávszélességi, napló- és tűzfalköltségeket figyelheti. Az Azure a következő lehetőségeket kínálja a költségek monitorozásához és elemzéséhez:

• Azure Advisor

• Microsoft Cost Management

Ideális esetben valós időben vagy legalább rendszeres ütemben monitorozza a költségeket. Ezután a hónap vége előtt is elvégezheti a műveletet, amikor a költségek már ki vannak számítva. Emellett figyelje a havi trendeket az idő függvényében, hogy a költségvetés maradjon.

Az adatvezérelt döntések meghozatalához pontosan meg kell határozni, hogy melyik erőforrás esetében merül fel a legtöbb költség. Emellett jól ismeri az erőforrás-használatot kiszámító mérőeszközöket. A metrikák elemzésével például meghatározhatja, hogy a platform túlméretezett-e. A használati mérőszámok az Azure Monitor-metrikákban láthatók.

Optimalizálás

Az Azure Advisor által biztosított javaslatokra vonatkozó lépések. Az optimalizálásnak más módjai is vannak:

• Engedélyezze a fürt automatikus skálázójának, hogy észlelje és eltávolítsa a csomópontkészletben lévő kihasználatlan csomópontokat.

  Fontos

  A fürt automatikus skálázási beállításainak( például a csomópontkészlet minimális és maximális csomópontbeállításainak) agresszív módosítása a költségek befolyásolása érdekében kontraproduktív eredményt eredményezhet. Ha például scale-down-unneeded-time 10 percre van állítva, és a minimális és maximális csomópontbeállítások öt percenként módosulnak a számítási feladatok jellemzői alapján, a csomópontok száma soha nem csökken. Ennek az az oka, hogy az egyes csomópontok szükségtelen idejének kiszámítása a fürt automatikus skálázási beállításainak frissítése miatt alaphelyzetbe áll.

• Válasszon alacsonyabb termékváltozatot a csomópontkészletekhez, ha a számítási feladat támogatja.

• Ha az alkalmazás nem igényel kipukkanási skálázást, fontolja meg a fürt megfelelő méretre való méretezését a teljesítménymetrikák időbeli elemzésével.

• Ha a számítási feladat támogatja, skálázza a felhasználói csomópontkészleteket 0 csomópontra , ha nem várható, hogy futnak. Ha a fürtben nincsenek ütemezetten futtatandó számítási feladatok, fontolja meg az AKS indítási/leállítási funkciójának használatát az összes számítás leállításához, amely magában foglalja a rendszercsomópontkészletet és az AKS-vezérlősíkot.

További költségekkel kapcsolatos információkért lásd az AKS díjszabását.

Következő lépések

• Speciális AKS-mikroszolgáltatás-architektúra
• AKS-alapkonfiguráció többrégiós fürtökhöz
• AKS-szabályozott fürt a PCI-DSS 3.2.1-hez
• Windows-tárolók az AKS alapkonfigurációs architektúráján

Kapcsolódó erőforrások

• AKS-ütemterv a GitHubon
• Bevezetés a Kubernetesbe
• Alkalmazások fejlesztése és üzembe helyezése a Kubernetesen
• Jól kiépítésű keretrendszer áttekintése az AKS-hez
• AKS célzónagyorsító
• Az AKS 2. napjának üzemeltetési útmutatója
• Mikroszolgáltatás-architektúra az AKS-en
• AKS-fürt védelme az Azure Firewall használatával
• Git-műveletek az AKS-hez
• Adatstreamelés az AKS-sel